How to Check If a Website Is Down

Is the Website Down for Everyone or Just You?

The single most useful first move is testing from a network that isn't yours. Your browser, your operating system's DNS cache, your router, and your ISP each sit between you and the site — any one of them can fake an "outage" that nobody else sees.

Run these checks in order; stop at the first one that disagrees with your browser:

1. Switch networks. Load the site on your phone with Wi-Fi turned off (mobile data only). If it loads, the site is up and the problem is inside your network or device.

2. Check DNS from multiple global locations. Enter the domain in the DNS Propagation Checker. If resolvers worldwide return an IP address, DNS is healthy globally. If they all return nothing, the domain itself is the problem — expired registration, deleted zone, or nameserver outage.

3. Test reachability of the resolved IP. Use the Ping Test against the domain. A response proves the server (or its CDN edge) is reachable; no response means the host is down or blocking ICMP — which is why ping alone is never conclusive and you continue to the HTTP check below.

4. Request the page over HTTP from a neutral vantage point. The HTTP Headers Check fetches the URL from DNSnexus infrastructure and shows the actual status code. A 200 here while your browser fails is definitive proof the outage is local to you.

If steps 2–4 all fail from outside your network too, the site is down for everyone. Nothing on your side will fix it — but if it's your site, skip to What to Do When It's Your Own Website.

The 4 Layers Where a Website Can Fail

Every "site is down" symptom maps to a failure in one of four layers, and each layer produces a distinct browser error. This table is the fastest way to translate what you see into where the failure is.

Read the table top-down: a failure at any layer prevents all layers below it from running. NXDOMAIN means the request never reached a server at all; a 503 means DNS, TCP, and TLS all worked and the web server itself answered — it just answered with a failure.

NXDOMAIN is the DNS response code meaning the name does not exist in the zone, defined in RFC 1035 §4.1.1 as RCODE 3 ("Name Error").

How to Check Website Status from the Command Line

Three commands walk all four layers in under a minute. Run them in this order and the first failure tells you the layer.

Step 1 — DNS. Resolve the name:

dig example.com A +short

93.184.215.14

An IP back means layer 1 is fine. An empty response or status: NXDOMAIN in full dig output means the failure is DNS — verify what the rest of the world sees with the DNS Lookup tool. If external resolvers succeed while your machine fails, your local cache is stale; see How to Flush DNS Cache.

Step 2 — TCP + TLS + HTTP in one request. Fetch only the headers:

curl -sIL https://example.com --max-time 10

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=3055

Any HTTP status line back — even 503 — proves layers 1–3 all work. The failures look like this instead:

curl: (7) Failed to connect to example.com port 443: Connection refused   ← layer 2 (TCP)
curl: (28) Connection timed out after 10005 milliseconds                  ← layer 2 (TCP)
curl: (60) SSL certificate problem: certificate has expired               ← layer 3 (TLS)

Step 3 — isolate a TLS failure. If curl exits with error 60 or 35, inspect the certificate with the SSL Checker, or locally:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

notBefore=Jan 15 08:21:11 2026 GMT
notAfter=Apr 15 08:21:10 2026 GMT

If notAfter is in the past, the certificate expired — a site that is "up" but unreachable by every browser. Expired certificates are one of the most common self-inflicted outages; the fixes are covered in Common SSL Errors and How to Fix Them.

What Do 502, 503, and 504 Errors Mean?

A 5xx status code means the site is down for everyone — but the web server or proxy in front of it is still alive. These codes are defined in RFC 9110 §15.6, and each one points at a different failure behind the proxy.

In practice: 502/504 mean the CDN or load balancer is fine and the origin behind it is dead — as a visitor you can only wait, but as the site owner these codes tell you exactly which machine to look at. Codes 521–523 are Cloudflare's origin-error range, documented in Cloudflare's troubleshooting docs.

Check which code a site is returning right now — without a browser cache in the way — using the HTTP Headers Check.

Why Is a Website Not Loading Only for You?

If external checkers say the site is up but your browser disagrees, one of these local causes is responsible. They're ranked by how often they're the culprit:

1. Stale local DNS cache. Your OS cached an old or negative DNS answer. Flush it (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder on macOS) — full per-OS steps in How to Flush DNS Cache.

2. Your configured DNS resolver is failing. If no sites load by name but IPs work, your resolver is down, not the website. Diagnosis and fixes: DNS Server Not Responding.

3. VPN or proxy. VPNs route your DNS and traffic through their own exit; a blocked exit IP or a VPN-side DNS failure looks identical to a site outage. Disconnect and retest.

4. Browser cache or extensions. Test in a private window first — it bypasses cache and most extensions in one step. A site that loads privately but not normally is a cache/extension problem.

5. ISP or national-level blocking. Some ISPs block domains at the resolver. If switching your resolver to 1.1.1.1 or 8.8.8.8 makes the site load, that's the confirmation.

6. hosts file override. A leftover entry in /etc/hosts (or C:\Windows\System32\drivers\etc\hosts) pins the domain to a dead IP. Check with cat /etc/hosts | grep example.com.

The pattern "website works on phone but not computer" is almost always cause 1, 4, or 6 — the phone uses a different DNS cache and browser profile, so it never sees your machine's stale state.

What to Do When It's Your Own Website

When the site that's down is yours, run the same four-layer check — but each failing layer now maps to an action instead of a wait:

• DNS fails globally: check the domain hasn't expired (registrar dashboard, or a WHOIS lookup shows the expiry date) and that the nameservers are correct. If you changed DNS recently, propagation delay may be the whole story — see DNS Propagation Taking Too Long.
• TCP fails: your server process or the host itself is down. Check the hosting provider's status page, then restart the web server (systemctl status nginx).
• TLS fails: renew the certificate. If you use Let's Encrypt, certificates expire after 90 days and renewal automation failing silently is the classic cause.
• HTTP 5xx: read the origin server's error log — a 502 from your CDN means the backend process crashed; a 504 means it's hung.

Stop checking manually. DNSnexus Monitor watches your DNS records, SSL expiry, email auth, and blacklist status — and alerts you before things break. Free tier covers one domain.

Key Takeaways

• ✓ Test from outside your own network first — a phone on mobile data settles "everyone or just me" in ten seconds.
• ✓ Every outage fails at exactly one of four layers: DNS, TCP, TLS, or HTTP — and each layer has a distinct error string.
• ✓ dig example.com +short plus curl -sIL https://example.com walks all four layers in two commands.
• ✓ Any 5xx status code (RFC 9110 §15.6) means the site is down for everyone — DNS, TCP, and TLS all worked.
• ✓ 502/504 mean the proxy is alive but the origin behind it is dead; 503 is overload or maintenance and often clears in minutes.
• ✓ "Works on my phone but not my computer" is almost always local DNS cache, browser cache, or a hosts-file entry.

Frequently Asked Questions

Next Steps

Bookmark the two tools that answer this question fastest: the HTTP Headers Check for "what status code is it actually returning," and the DNS Propagation Checker for "does the domain resolve globally." Run a quick Ping Test when you need raw reachability, and inspect certificates with the SSL Checker whenever the failure is at the TLS layer.

Related Guides

• DNS Server Not Responding: 9 Fixes That Actually Work
• How to Flush DNS Cache on Any Device
• Common SSL Errors and How to Fix Them
• DNS Propagation Taking Too Long? Here's Why