In short. When a site won't open, work from the outside in: first find out whether the problem is only yours or everyone's (open it on your phone over mobile data), then check DNS, then TCP connectivity and SSL, and only at the end the server and the application itself. Nine times out of ten the cause is DNS, an expired certificate, a downed origin, a firewall/Cloudflare block, or simply an expired domain. This 10-step checklist with ready commands narrows the cause in a few minutes — and separately covers what to do when the site fails only for you.
Steps 1–2. Just you or everyone? Check DNS
Step 1. Determine the scope. Open the site on your phone over mobile data (not home Wi-Fi) and check it from the outside via an availability check. If the site responds from outside but not for you, the problem is your network, cache, or DNS resolver — not the site. A detailed breakdown of this fork is in the article "is the site down: everyone or just me".
The first question is always one: "is it me or everyone?" Don't waste time on the server if the outage is visible only from your point — and vice versa.
Step 2. Check DNS — does the domain resolve to an IP:
dig example.com +short # should return an IP
nslookup example.com
# empty or NXDOMAIN — a problem with the DNS recordsNo IP — go to the DNS check and the domain won't resolve breakdown. If there is an IP but the site fails only for you, a DNS cache is almost certainly to blame (see "If it's only you" below).
Steps 3–4. TCP connectivity and the SSL certificate
Step 3. Check connectivity:
ping example.com # does the host answer ICMP
curl -Iv --connect-timeout 10 https://example.comIf ping works but curl hangs on "Connected" with no reply, the origin or app isn't responding. If ping fails too, it's a network problem or the server is fully unreachable.
Step 4. Check the SSL certificate and expiry:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates
# notAfter in the past = the certificate is expiredAn expired certificate is one of the most common causes of "the site won't open" with a red browser warning. Faster to check via the SSL inspector: it shows the expiry, the issuer, and whether the server sends the whole chain. On fixing it — the expired-certificate breakdown.
Step 5. Look at the response code
The HTTP response code immediately narrows which side the problem is on:
| Code | What it means | Where to dig |
|---|---|---|
| NXDOMAIN | DNS won't resolve | DNS Lookup, registrar, domain expiry |
| 522 / 521 | Cloudflare couldn't reach the origin | Origin down, firewall blocking Cloudflare |
| 525 / 526 | SSL between Cloudflare and origin | Origin cert, SSL mode in CF |
| 1020 | Cloudflare WAF/Firewall block | Security rules, your IP banned |
| 403 / 429 | Access denied / rate limit | Permissions, rate limit, anti-bot |
| 500 / 502 / 503 | App/backend error | App logs, PHP/DB — see 502 |
| Timeout | Server not responding | Load, network, origin down |
Steps 6–7. Origin behind CDN and firewall
Step 6. Check the origin bypassing the CDN. If Cloudflare or a CDN sits in front, hit the origin's real IP directly, bypassing the proxy:
curl -Iv --resolve example.com:443:203.0.113.10 https://example.comOrigin answers directly but not through the CDN? The problem is the CDN (or its block of your IP). Neither answers — fix the server.
Step 7. Check the firewall and blocks:
- Has fail2ban banned your IP or Cloudflare's addresses?
- Are ports 80/443 open in ufw/iptables/security group? Check a port from outside with a port check.
- Did a rate limit trip on the app or proxy side?
Steps 8–9. Web server, application, and domain expiry
Step 8. Check the web server and app:
- Is nginx/Apache running:
systemctl status nginx. - Is it listening on the ports:
ss -tlnp | grep -E ':80|:443'. - What's in the logs:
tail -n 50 /var/log/nginx/error.log. - Is the database alive and are the PHP-FPM workers not exhausted (a common cause of 502/503 under load).
Step 9. Check the domain expiry and hosting payment. A banal but regular cause: the domain registration expired or hosting went unpaid — and the site was simply switched off. Look at the date in WHOIS and emails from the registrar and host. To prevent a repeat — put the domain on expiry monitoring.
Step 10. Check from several regions
A site can be down only from one country — a regional ISP outage, geo-blocking, or a routing problem. A check from several regions shows the scope. If it opens from the US but not from Russia, it's not "the site is down" but a network or geo problem between you and the server; for a Russian audience, separately see availability from Russia. Major Runet-service outages are visible on the outages page.
If the site fails only for you
The site returns 200 from outside but not for you — so it's your side that needs fixing. In order:
- Incognito and another browser. Opens in incognito — cache or an extension is to blame; clear the browser cache.
- Flush the system DNS cache: Windows —
ipconfig /flushdns; macOS —sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder; Linux — restartsystemd-resolved. More in the DNS cache flush guide. - Switch the DNS server to a public one if the ISP's resolver returns a stale or blocked address.
- Disable VPN, proxy, and extensions. A common source of "won't open only for me."
- Check the date and time on the device — a wrong clock breaks SSL certificate verification.
How enterno.io speeds up diagnosis
enterno.io gathers most of this checklist onto one screen. The HTTP checker shows the response code and headers, the DNS check the records, the SSL inspector the certificate and expiry, WHOIS the domain expiry. Uptime monitoring checks the site every minute (30 seconds on higher plans) from several regions and sends an alert to Telegram, Slack, email, or a webhook before you notice the outage — and the multi-region check answers "down globally or locally" at once. The free plan has 10 monitors and 48+ diagnostic tools. enterno.io diagnoses and warns; the owner does the fixing on the server.
Frequently asked questions
Where to start if nothing is clear?
With step 1: open the site on your phone over mobile data and check it from outside. That instantly splits the problem into "local" and "global" and saves hours: in one case you fix your side, in the other the server.
The site opens for me, but a client complains?
Check from several regions and resolvers. The client may have a stale DNS cache, geo-blocking, a regional ISP outage, or DNS that hasn't updated yet after a site move.
How to tell a DNS problem from a server problem?
If dig returns no IP — it's DNS. If there is an IP but curl hangs or returns 5xx — it's the server or app. The in-between case (522/525) is a problem between the CDN and origin.
What to do if outages are short and elusive?
Set up monitoring at a 1-minute interval — it catches what a manual check misses. How to diagnose flapping availability is in the article on intermittent downtime.
Next step: run the site through the HTTP checker, DNS, and SSL, then enable monitoring. See also the website monitoring guide.