Network Troubleshooting Checklist
This checklist gives you a repeatable, bottom-up way to find network faults instead of guessing. It follows the OSI model from cables and link lights through switching, IP addressing, DNS and ports to the application, with Windows and Linux commands for each step. It is for students, help desk staff and junior network engineers. Confirm each layer works before moving up, and write down what you find as you go.
How to use this checklist
- Define the problem. Ask who is affected, what exactly fails, since when and what changed. One user or everyone is the first big clue.
- Work from Layer 1 upwards. Confirm the physical link, then switching, IP, DNS, ports and finally the application, ticking off each check.
- Change one thing at a time. Test after every change so you know which fix worked.
- Document the fix. Record the cause, the fix and how you verified it, so the next person solves it faster.
0 of 48 checked
Before you start
Layer 1: physical
Layer 2: data link
Layer 3: network
DNS
Layer 4: transport and ports
Application and wireless
Documenting and closing
Frequently asked questions
Why troubleshoot from the bottom of the OSI model?
Each layer depends on the ones below it, so confirming the physical link, switching and IP first stops you wasting time on DNS or applications when a cable is the real fault.
What does a 169.254.x.x address mean?
It is a link-local address the device gave itself because it could not get a lease from a DHCP server. Check the cable, VLAN and DHCP server.
Ping works by IP but not by name. What is wrong?
Almost certainly DNS. Check which DNS servers the device uses, try another server with nslookup or dig, and clear the DNS cache.
How do I test a port without telnet?
On Windows use Test-NetConnection host -Port 443 in PowerShell. On Linux use nc -zv host 443.