Why “Layer by Layer” Is the Right Mental Model
Every internet connection is a stack of layers, and a failure at any layer looks like a general “internet problem” from the user's perspective. The browser cannot load the page — is that a DNS failure, a routing failure, a TCP connection failure, a Wi-Fi signal issue, or a server outage? Without working through the layers methodically, all of those possibilities remain open, and fixing the wrong one wastes time.
Layer-by-layer troubleshooting is the practice of testing each layer in sequence, from the physical connection closest to you outward to the remote service, eliminating each layer before moving to the next. It is slower to start and much faster to resolve than random attempts.
The Layers and How to Test Them
| Layer | What Can Fail | Test | Pass Condition |
|---|---|---|---|
| Physical / Link | Ethernet cable unplugged, bad coaxial connection, fiber LOS, modem not synced | Check link lights on modem and router; check modem status page at 192.168.100.1 | Modem shows “online” or “operational”; router shows WAN IP assigned |
| IP / LAN | DHCP failure, IP conflict, wrong subnet, router misconfiguration | ipconfig (Windows) or ifconfig / ip a (Mac/Linux) — verify you have a non-169.x.x.x IP | Device has a valid private IP from the router (192.168.x.x or 10.x.x.x) |
| Routing / Gateway | Router not passing traffic to WAN, NAT failure, default gateway missing | Ping your router's IP (ping 192.168.1.1), then ping a public IP (ping 1.1.1.1) | Router responds to ping; 1.1.1.1 responds to ping with stable latency |
| DNS | DNS server unreachable, slow DNS, wrong DNS settings, ISP DNS blocking | Compare ping 1.1.1.1 (works) vs ping cloudflare.com (fails or times out) | Both succeed; if IP ping works but domain ping fails, DNS is the layer that failed |
| Transport / Application | Firewall blocking ports, ISP filtering specific protocols, application-level problems | Try the same action in a different browser, over a VPN, or on cellular data | Works in another browser or on cellular; if so, the problem is application-specific or ISP protocol filtering |
| Remote service | Server outage, CDN failure, peering congestion to that destination | Check downdetector.com for the service; try the same site on a different network | Site works on cellular or at a different location; confirms the problem is at the remote end or on the path to it |
Working Through the Stack: A Step-by-Step Sequence
- Confirm physical connectivity: look at the LEDs on your modem and router. An unlit WAN light, a blinking DS/US light on a cable modem, or a solid red light usually indicates the modem has not registered. Check the modem's status page at 192.168.100.1 before proceeding.
- Verify IP assignment: open a terminal and check your IP address. An address starting with 169.254.x.x means DHCP failed — your device cannot reach the router. Reboot the router and check the connection between your device and the router first.
- Test the gateway: ping your router's IP address (usually 192.168.1.1 or 192.168.0.1). If the router responds, your LAN is working. Then ping 1.1.1.1. If 1.1.1.1 responds, routing from your device to the public internet is functioning.
- Test DNS specifically: if ping to 1.1.1.1 works but you cannot load websites, run
nslookup google.comordig google.com. If it fails or is very slow, DNS is the broken layer. Switch to a public DNS server (1.1.1.1 or 8.8.8.8) as a test. - Test the transport layer: if DNS resolves but web pages still fail, try telnet or curl to port 80 or 443 of a major server. A firewall or ISP filtering blocking specific ports can pass DNS but drop HTTP/HTTPS traffic.
- Test the remote service: if everything appears to work to 1.1.1.1 but one specific service is broken, the problem is at the destination or on the ISP's peering path to that destination. Test from cellular to confirm.
When the Layer Model Points to the ISP
If you reach step 3 and ping to 1.1.1.1 fails or shows packet loss — but your router responds fine — the problem is between your modem and the ISP's network. At this point, move to modem signal level inspection (192.168.100.1) and MTR testing before calling the ISP. Going to step 3 cleanly eliminates your entire home network as the source of the problem, which makes the ISP conversation straightforward: “I can reach my router at 2 ms, but I cannot reach 1.1.1.1 reliably — my modem event log shows T3 timeouts at 8 PM.”
Frequently Asked Questions
Is layer-by-layer troubleshooting the same as the OSI model?
It borrows the concept but is not rigidly the OSI model. The OSI model has 7 layers (physical, data link, network, transport, session, presentation, application). For home internet troubleshooting, the relevant layers collapse into 4–5 testable steps: physical/link, IP/LAN, routing, DNS, and application/remote service. You do not need to memorize OSI; you need to test in order from the closest layer to you outward, which is what this guide covers.
Does the order of testing matter?
Yes. Testing DNS before confirming the gateway works is wasted effort — if the gateway is broken, DNS will also fail as a consequence. Testing the remote service before testing DNS is even more wasteful. The inner-to-outer sequence matters because each layer depends on the one below it. A failure at layer 2 causes failures at layers 3, 4, and 5. Confirming each inner layer clears it from suspicion and focuses your investigation on the actual fault.
What if multiple layers appear broken at once?
Usually this means the innermost failure is the cause and the others are consequences. If your IP address is 169.254.x.x (DHCP failure), DNS and routing will also fail — but fixing the DHCP failure fixes everything. Diagnose the innermost broken layer, fix it, and re-test from that point rather than trying to fix every apparent symptom simultaneously.