Quick Summary
- Always troubleshoot bottom-up: physical layer first, then IP, then connectivity, then DNS, then application
- Each step has a specific tool: check cables, ip addr, ping gateway, ping 8.8.8.8, nslookup
- Most network problems are at the bottom two layers -- physical connections and IP configuration
Stop Guessing, Start Diagnosing
When a network breaks, the natural reaction is to start guessing. Maybe it is the router. Maybe the ISP is down. Maybe the cable is bad. This approach wastes time and leads you in circles. Professional network engineers use a systematic, bottom-up methodology that isolates the problem in minutes, not hours.
The idea is simple: networks are built in layers, and each layer depends on the one below it. If the physical cable is unplugged (Layer 1), nothing else matters -- DNS, routing, and applications all fail. If your IP address is wrong (Layer 3), you cannot reach anything even though the cable is fine. By testing each layer in order, you quickly narrow down where the problem actually is.
This five-step process works for most network problems you will encounter, whether you are debugging a home WiFi issue, a server that lost connectivity, or a complex enterprise network. Each step tells you something specific, and the result determines whether you move to the next step or have found your problem.
The Troubleshooting Stack
Each layer builds on the one below it. A failure at any layer breaks everything above:
Try It Yourself: Troubleshooting Simulator
A user reports: "I can't browse the internet!" Work through the diagnostic steps to find the problem.
Click each button in order, just like a real network engineer would:
The 5 Steps in Detail
Follow these steps in order. If a step fails, you have found your problem -- fix it before moving on.
Check Physical and Link Layer
Before you touch any software, check the physical connection. Is the Ethernet cable plugged in at both ends?
Is the WiFi connected? Are the link lights on the switch port lit up? Run ip link show (Linux) or
check your network adapter status (Windows/Mac). Look for "state UP" -- if the interface shows "state DOWN,"
the problem is physical. Check the cable, try a different port on the switch, or reconnect to WiFi. This step
catches about 30% of all network problems. It sounds basic, but even experienced engineers have spent an hour
debugging routing only to discover an unplugged cable. On virtual machines, check that the virtual network
adapter is attached and the bridge or NAT configuration is correct.
Check IP Configuration
Run ip addr show (Linux) or ipconfig (Windows) to see your IP address, subnet mask,
and whether your interface has an address at all. If you see a 169.254.x.x address (APIPA), your DHCP server
is not responding and your computer assigned itself a useless address. If you see no IP address, DHCP has not
worked or the static configuration is missing. Check ip route to verify you have a default gateway.
A missing or incorrect gateway means your traffic has nowhere to go beyond your local network. Also verify the
subnet mask -- an incorrect mask can make your computer think the gateway is on a different network, silently
breaking all outbound traffic.
Check Local Connectivity (Ping Your Gateway)
Run ping followed by your default gateway IP (for example, ping 192.168.1.1). If this
fails, you cannot reach your own router. The problem is between your device and the gateway -- likely a VLAN
mismatch, a bad cable, WiFi interference, or a firewall on the router itself. If this succeeds, your local
network is working fine. Try pinging another device on your LAN to confirm. If you can reach the gateway but not
other local devices, there may be client isolation enabled on the access point (common on guest WiFi networks).
On Linux, use arping to test Layer 2 reachability separately from Layer 3.
Check Remote Connectivity (Ping 8.8.8.8)
Now test if you can reach the internet. Run ping 8.8.8.8 -- this is Google's public DNS server and
it is almost always up. If this fails but your gateway ping succeeded, the problem is upstream: your router cannot
reach the internet, your ISP has an issue, or there is a routing problem between you and the destination. Run
traceroute 8.8.8.8 (Linux/Mac) or tracert 8.8.8.8 (Windows) to see exactly where
packets stop. Traceroute shows every hop your packets take and where the chain breaks. If you see timeouts
starting at hop 2 or 3, the problem is at your ISP or upstream. If the first hop fails, revisit step 3.
Check DNS Resolution
If you can ping 8.8.8.8 but cannot load websites, DNS is the most likely culprit. Run
nslookup google.com or dig google.com. If this fails or times out, your DNS server is
unreachable or misconfigured. Fix it by changing your DNS settings to a public resolver like 8.8.8.8 (Google) or
1.1.1.1 (Cloudflare). On Linux, check /etc/resolv.conf. On Windows, change DNS in your network
adapter's IPv4 properties. If nslookup works but browsing still fails, the problem is at the application layer --
check browser proxy settings, firewall rules blocking ports 80/443, or try a different browser. This final step
catches the remaining issues that the lower layers did not explain.
Essential Troubleshooting Tools
Every network engineer keeps these tools in their mental toolkit. Each one tests a specific thing:
ping
Sends ICMP echo requests to test if a host is reachable and how long the round trip takes. The most basic
connectivity test. Use ping -c 4 8.8.8.8 to send exactly 4 packets. Watch for packet loss and
high latency.
traceroute / tracert
Shows every router (hop) between you and the destination. Invaluable for finding where packets get dropped or delayed. Each line shows a hop with its IP and response time. Stars (*) mean that hop did not respond.
nslookup / dig
Queries DNS servers directly. nslookup google.com shows which DNS server answered and what IP it
returned. dig provides more detail including TTL and record type. Essential for DNS debugging.
ip addr / ifconfig
Shows your network interface configuration: IP address, subnet mask, MAC address, and link state. On modern
Linux, use ip addr show. On older systems and Mac, ifconfig still works.
curl
Makes HTTP/HTTPS requests from the command line. curl -v https://google.com shows the complete
connection process: DNS resolution, TCP connect, TLS handshake, and HTTP response. More thorough than ping.
ss / netstat
Shows active network connections and listening ports. ss -tlnp lists all TCP ports a server is
listening on. Essential for verifying that services are actually running and bound to the correct interface.
Common Troubleshooting Mistakes
Avoid these pitfalls that waste time and lead you in the wrong direction:
Starting at the Top
Jumping straight to application-level debugging (restarting the web server, clearing browser cache) before checking basic connectivity wastes time. Always start at the bottom layer and work up.
Assuming Ping = Everything Works
Ping only tests ICMP reachability. It does not test DNS, specific TCP ports, or application services. A host can respond to ping while its web server is down, its firewall blocks HTTP, or DNS is broken.
Changing Multiple Things at Once
If you change the DNS server, the gateway, and a firewall rule all at once, you will not know which change fixed the problem. Change one thing at a time, test, and then move to the next change.
Putting It All Together: A Real Scenario
Imagine a user reports "the internet is down." Here is how you would work through the five steps. First, you check
the physical connection -- the Ethernet cable is plugged in and link lights are on. Step 1 passes. You run
ip addr show and see the interface has IP 192.168.1.50 with a /24 mask. You check ip route
and see a default gateway of 192.168.1.1. Step 2 passes.
You ping 192.168.1.1 and get replies. Step 3 passes. You ping 8.8.8.8 and get replies. Step 4 passes. You run
nslookup google.com and it times out with no response. Step 5 fails -- you have found the problem.
The DNS server configured on this machine is not responding. You check /etc/resolv.conf and see it
points to 192.168.1.1 -- the router is supposed to forward DNS queries but is not doing so. You change DNS to
8.8.8.8, run nslookup again, and it works. Browsing resumes. Total diagnosis time: about two minutes.
Without this systematic approach, you might have spent twenty minutes rebooting the router, checking ISP status pages, and swapping cables -- all of which were perfectly fine. The five-step method pointed you directly at the one thing that was broken.
Frequently asked questions about network troubleshooting
How do I troubleshoot a network problem step by step?
Work bottom up: check the physical link and IP config, ping your gateway, ping a public IP like 8.8.8.8, then test DNS with nslookup or dig, and finally test the application with curl or a browser. The first step that fails is where to focus.
What does it mean when ping works but websites won't load?
It usually means your underlying connectivity is fine but DNS or the application layer is broken. Try ping 8.8.8.8 (works) then nslookup google.com — if that fails, your DNS resolver is misconfigured or unreachable. Switch to 1.1.1.1 or 8.8.8.8 as a quick fix.
What is the difference between ping and traceroute?
ping tells you whether a destination is reachable and the round-trip latency. traceroute shows every hop along the path with per-hop latency, which lets you see exactly where packets are dropped or delayed. Use ping first, then traceroute to localize a failure.
What is an APIPA address (169.254.x.x)?
An APIPA address is one your operating system assigns itself when no DHCP server replies. It looks like 169.254.x.x and means the device couldn't get a real IP. Check the cable, the DHCP server, the VLAN config, or the WiFi association — DHCP isn't working.
Should I always start by rebooting the router?
No. A reboot is a sledgehammer that hides the cause. Diagnose first: ip addr, ping gateway, ping 8.8.8.8, nslookup. Only reboot when you have a specific reason or as a last resort. Otherwise you fix nothing and learn nothing.
Take the troubleshooter challenge
You just learned the 5-step bottom-up method. Now apply it to a pre-broken network: three bugs on three devices, each found with a trace and a console command and fixed one at a time until the page loads.
Launch the troubleshooter lab →