Troubleshooting is hypothesis testing. Start with the smallest claim that explains the symptom, choose a tool that can test that claim, interpret the evidence, and move to the next layer only when appropriate. The goal is to avoid changing five things at once and then forgetting which change fixed the problem.
Remember the shape, not the sentence
“Treat debugging like a detective tree, not a checklist. Every command should answer one question.”
Bottom-up
A common approach is physical/link → IP → routing → transport port → application/DNS. Bottom-up reduces the chance of debugging HTTP when the interface has no link.
Divide by observable evidence
Ping a known reachable IP, inspect the local address, check the default route, test a specific port, resolve the name, then inspect the application. Each step narrows the failure domain.
Avoid false certainty
One successful ping proves less than people think. ICMP may be filtered, a host may be reachable while the target application is not, or DNS may work while TLS/HTTP fails.
See the mechanism before you memorize it
One diagram, one causal story, one reconstruction task.
Interactive: layer-by-layer troubleshooting scenarios — causal map
L1/L2
Link state, interface, VLAN, ARP/neighbor state.
L3
Address, subnet, gateway, route and ICMP reachability.
L4
Port listening, firewall rules, handshake success.
L7
DNS, TLS, HTTP/application semantics.
Draw the idea yourself
Rebuild the core flow on a real canvas before moving to the worked walkthrough.
Walk the system
L1/L2
Link state, interface, VLAN, ARP/neighbor state.
L3
Address, subnet, gateway, route and ICMP reachability.
L4
Port listening, firewall rules, handshake success.
L7
DNS, TLS, HTTP/application semantics.
Confirm
Reproduce after the smallest corrective action and document the evidence.
Decision tree
This is a reasoning scaffold. Real incidents may jump layers, but the tree stops you from guessing blindly.
Link up? no → fix interface/cable/VLAN
IP configured? no → DHCP/static config
Gateway reachable? no → L2/L3 path
Port open? no → service/firewall
Name works? no → DNS
HTTPS works? no → TLS/HTTP/applicationWhat usually goes wrong
Close the tab. Rebuild it from memory.
Read the question, answer aloud, then reveal.
Why is 'ping works but website does not' useful?Reveal answer
It suggests some lower-layer path is functioning, but it does not prove the target TCP port, TLS handshake, DNS or HTTP application path is healthy.
What makes a troubleshooting command good?Reveal answer
It tests a specific hypothesis with an interpretable result and minimal ambiguity.
Why change one thing at a time?Reveal answer
It preserves causal information so you know which change affected the failure.
Make this idea travel.
Connect it next to: network-toolkit • wireshark • devtools.