When a page load fails
A browser has roughly three error pages and they cover dozens of causes. Underneath, each failure stops at a specific stage — and the stage it stopped at is usually recoverable from how long it took.
The first one fails before anything is sent anywhere at all.
Failing fast is a good sign
NXDOMAIN is not a failure to get an answer. It is an answer: the hierarchy was walked, an authoritative server was reached, and it said the name does not exist. That is why it comes back in milliseconds — somebody was there to say no.
The result is negatively cached too, so the second attempt is faster and equally wrong. Contrast that with a name that resolves perfectly to an address where nothing answers:
A refusal is not a breakage
The third failure gets further than either: the name resolved, the connection opened, and the server answered. The browser then read the certificate and stopped.
Four of the five certificate checks passed. The chain was well-formed, trusted, and issued for this exact hostname — it simply expired three days ago. The alert the client sends is a real message on the wire, not a browser invention, and no application data is ever exchanged. There is no such thing as a partially secure connection.
Key takeaways
- Every page-load failure stops at a specific stage, and identifying the stage is most of the diagnosis.
- Fast failures are answers: NXDOMAIN, a reset, an HTTP error code. Something replied.
- Slow failures are silences. Nothing answered, so a timer had to expire before anything could be concluded.
- NXDOMAIN is a definite negative result, cached like any other, which is why the second attempt is quicker and equally wrong.
- A certificate interstitial is a refusal, not a breakage — one check of five failed and the client stopped before sending anything.