How to Tell Real Downtime From Your Own Network Problems
If your site is unreachable from your browser, the odds are roughly even that the fault is on your side of the internet rather than the server's. The question "is my site down or is it my internet" has a definite answer, and you can get it in under a minute by testing from a path that does not share your connection: a different network, a remote host, or a public resolver. Everything below is about isolating which layer is actually broken.
Start With DNS, Because That Is Where Most False Alarms Live
A browser shows the same generic failure page whether DNS failed, TCP failed, or TLS failed. The first split is therefore between name resolution and everything after it. Run a query against a resolver you do not control, and compare it with your local resolver.
dig +short example.com @1.1.1.1
dig +short example.com
If the public resolver returns an address and your local one returns nothing, the problem is your resolver, your router, or a VPN client that rewrote /etc/resolv.conf. Your site is not down. If both return the same address, DNS is fine and you move on. If both return SERVFAIL or an empty answer, the authoritative nameservers for the zone are the suspect, and that is a real outage worth reporting.
One subtlety: a stale negative cache. If you changed a record recently and your resolver cached the old NXDOMAIN, you will keep seeing failure while the rest of the world sees the new address. Query the authoritative server directly, the one listed in the zone's NS records, and ask it without recursion.
dig example.com @ns1.example.com +norecurse
An ANSWER section here means the zone is serving correctly. That result alone rules out a large class of outages.
Separate TCP From HTTP
Once the name resolves, you need to know whether the connection is being refused, dropped, or accepted and then mishandled. Those three look different at the socket level and point at different culprits.
curl -v --connect-timeout 5 https://example.com/ 2>&1 | head -20
Read the output in order. If you see Trying 203.0.113.10... followed by Connection refused, something is listening on that address and actively rejecting you, which usually means the service is not bound to that port or a firewall is sending resets. If it hangs at Trying until the timeout, packets are being silently dropped, which is the signature of a firewall rule or a routing problem rather than a crashed process. If it gets to TLS handshake and then fails, the listener is up and the certificate or the TLS configuration is the issue.
A successful curl from your machine while your browser still fails tells you the problem is local to the browser: a stale HSTS entry, a proxy setting, an extension, or a cached redirect. Try the same URL in a private window and in a second browser before you do anything else.
Check What Your Own Machine Is Doing
Before blaming the host, confirm your traffic is leaving the way you think it is. A VPN or a corporate proxy can route your requests through an egress point that is itself blocked or that the origin is deliberately rejecting. Ask the origin what it thinks your address is.
curl -s https://example.com/cdn-cgi/trace | grep -E '^(ip|loc|warp)='
The exact endpoint depends on the provider in front of the site, so check your provider's documentation for an equivalent echo service. If the address you see is not the one your ISP assigned you, your traffic is being proxied and any IP based access rule on the origin is evaluating the proxy, not you.
Also check the Host header path. If you are testing by IP address rather than by hostname, a virtual host setup will serve the wrong site or a default page, and you will misread that as an outage.
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: example.com' http://203.0.113.10/
A 200 here while the hostname fails means the server is healthy and the problem is in name resolution or in the path between your resolver and the client.
Use an Outside Vantage Point
The single most useful move is to stop testing from the affected network. Anything you run on your own laptop shares your ISP, your router, your DNS resolver, and your local firewall, so a failure there is ambiguous by construction. A remote shell on a machine in a different network, or a third party reachability checker, removes that ambiguity.
From a remote host, run the same curl -v you ran locally and compare. If the remote host succeeds and you fail, the site is up. If both fail identically, the site is down or the path to it is broken for everyone, and that is a support ticket with evidence attached.
When you do open a ticket, include the outputs, not a description. Paste the dig answer, the first lines of curl -v, the HTTP status code, the timestamp in UTC, and the source address you tested from. Support engineers can act on that immediately and cannot act on "it is down for me".
Watch For Partial Failures
Not every outage is total. A site can serve static assets from a cache while the origin is unreachable, so the page loads but forms and logins fail. A load balancer can have one unhealthy backend out of several, so you fail intermittently and your colleague does not. Test more than once, and test a dynamic endpoint rather than the home page.
for i in 1 2 3 4 5; do
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/api/health
done
A spread of status codes or wildly varying times points at a backend problem rather than your connection, because a local network fault tends to fail consistently rather than intermittently. Consistency is the tell: local problems are usually deterministic, and server side problems often are not.
What To Do Next
Work outward from your own machine only after you have ruled out the server, because the cheap tests are the remote ones. Resolve the name from a public resolver, connect from a host that is not on your network, and read the curl -v output line by line before you conclude anything. If the remote test succeeds, restart your resolver or your router, clear the browser cache, and disable any VPN or proxy for a single request. If the remote test fails too, stop debugging your side and file a ticket with the raw command output, the UTC time, and the address you tested from. That evidence is what turns a vague complaint into something an engineer can act on.
