It won’t load: the ladder (network debugging)

One parcel tracked from a laptop to example.com, hop by hop. This lesson is about the day the parcel never arrives, and the five questions that find out where it stopped.

Before you start. One click, every layer (what happens when you load a page) walked one page load through five stops: the concierge turns a name into a number (DNS Resolution), depots pass the parcel one hop closer, each reading only its own list of rows (How a parcel finds any house on earth), the phone call opens on a numbered door called a port (TCP vs UDP, and the 3-way handshake), the whisper code checks the site’s ID card and makes the line private (The whisper code (how a call goes private)), and the order goes in and the reply comes back (What a request actually says (HTTP)). This lesson asks the same five stops as questions, for the day one of them fails.

The idea in 30 seconds

A page that won’t load is debugged in a fixed order: name, route, port, TLS (the whisper code), HTTP. Each question only makes sense once the one before it has passed.
dig answers the name question; read its status and the SERVER line, because asking the wrong resolver is as common as asking about the wrong name.
A default route that points at a missing router makes every address beyond your own network unreachable, and ping reports it from your own address.
“Connection refused” in an instant means the house answered and nobody listens on that port; a timeout means something dropped your knock without a word, usually a firewall.
openssl s_client ends in one line, Verify return code, that names a wrong-name, expired or untrusted certificate outright.
When small replies arrive and large ones hang, suspect a smaller MTU in the middle whose “too big” notes are being thrown away: the route rung, failing at the top.

Read the story · Skip to the numbers