Which Layer Failed
One page load, six places it can go wrong, and how to tell them apart
Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.
What you'll be able to do
- ▸Name the six layers a page load depends on, in the order they must succeed
- ▸Map a symptom to the layer that produced it
- ▸Say what a working capture proves, so an absence becomes evidence
Before this lesson — it builds directly on:
"The site is down" is not a diagnosis, and neither is "it must be the network". Both are places to start guessing.
A page load is six things in a fixed order, and the order is what turns a symptom into a search. Find the deepest one that succeeded and everything below it is proven — not assumed, proven, by the packets. What remains is a much smaller problem.
That is the whole method, and it is worth more than any individual protocol fact in this course.
Watch these fields in the lab: tcp.destPort · ipv4.destIp
- 1DHCP — no address, no gateway, no resolver. Symptom: nothing works at all, and a 169.254 address is the giveaway.
- 2ARP — the gateway's MAC is unknown or wrong. Symptom: the LAN works and nothing beyond it does.
- 3DNS — the name does not resolve. Symptom: one site fails instantly while others are fine.
- 4TCP — the connection does not open. Symptom: RST means refused within a round trip; silence with retransmissions means filtered.
- 5TLS — identity or negotiation fails. Symptom: a warning before any content, or a failure before any certificate appears.
- 6HTTP — the application answers badly. Symptom: a page loads, and it is an error page.
✓ Concept check — before you open the packets
These test the idea, not the trace. You should be able to answer them from the explanation above.
Now that you understand the concept, observe how it appears in the packet exchange.
The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.