Reading what a browser error is actually telling you
A browser tells you more than "the site is down". The exact way it fails records how far your request travelled before it stopped, and everything up to that point is proven to have worked. Read the failure for its depth first, then investigate only the layer it stopped on. Most wasted diagnostic hours are spent below the line the error already cleared.
The rule that saves the most time
Every failure marks a boundary. If a page came back with an HTTP status code, the name resolved, a connection opened and, on https, the certificate was accepted. If you got a certificate warning, the connection opened. If you got a connection error, the name resolved. The deepest working layer is not something you have to guess at. The error states it.
Symptom to layer
| What the browser shows | What already worked | Where to look | What to leave alone |
|---|---|---|---|
ERR_NAME_NOT_RESOLVED, DNS_PROBE_FINISHED_NXDOMAIN | Nothing past the resolver | Delegation, zone contents, registrar status of the domain | Web server config, files, certificates, application logs |
ERR_CONNECTION_REFUSED | Name resolved to an address | A machine answered and declined: service stopped, wrong port, or the record points at an address that is not your host | DNS records themselves, site code |
ERR_CONNECTION_TIMED_OUT | Name resolved | Packets are being dropped silently: firewall rule, IP-level block, stale address still in the zone | Application config, certificate |
| Certificate warning | DNS, routing and the TCP connection | Certificate lifecycle or which site the request landed on (see below) | Anything below the handshake |
403, 404 | Everything through TLS | Permissions, document root, rewrite rules, path case | DNS, firewall, network |
500, 502, 503 | Everything through TLS | Application error log for 500; the worker process or upstream service for 502 and 503 | DNS, certificates, the browser |
| Blank page, no error | The entire stack | Response body and browser console | Anything network shaped |
Refused is not the same as timed out
Refused arrives instantly, because something at that address actively answered. That is almost always a stopped service or a request arriving on the wrong port. Timed out hangs for many seconds, because nothing answered at all. That is a firewall, a block, or an address in DNS that no longer belongs to you. The speed of the failure is the clue, and it is free to observe.
Two certificate warnings, two unrelated causes
An expiry warning such as NET::ERR_CERT_DATE_INVALID is a lifecycle failure: renewal did not run, or the renewed certificate was issued but never installed on the running service. A name mismatch such as NET::ERR_CERT_COMMON_NAME_INVALID is usually not a certificate problem at all. It means your request was served by a different site than you expected, or by the host default, so the certificate you were handed belongs to somebody else. Check which virtual host answered before you reissue anything, and see the SSL certificate page for what a certificate covers.
A page that loads but shows nothing
A blank page with status 200 means the whole delivery chain succeeded and the content is the problem. Three causes cover nearly all of it: a server-side fatal error with error display switched off; a client script that threw before rendering; or markup that rendered but is hidden. Look at the response size first. Zero bytes points at the server. Full bytes with an empty screen points at the browser console. The full status list is documented at MDN.
Before you trust any of it
- Test from a second network and a second device. A fault only you can see is usually a cached record or a local block, not a server.
- Try the address directly as well as the hostname. If the address works and the name does not, the fault is above the server.
- Note whether the failure is identical on
httpandhttps. A difference isolates the fault to the TLS layer.
Other symptom-driven walkthroughs are collected under diagnostics. If the layer you have narrowed to is one you do not control, bring the exact error string and the time it happened to support; that pair usually replaces an hour of back and forth.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.