Troubleshooting, step by step

Most people troubleshoot by guessing: restart the router, turn Wi-Fi off and on, try again, restart the router again. Sometimes that works, and nobody learns why. Three habits replace the guessing:

1. Find out who's affected before touching anything. One device, every Wi-Fi device, the whole house, or everyone in the world? The answer rules out most causes at once (Step 02).
2. Test from the bottom up, and stop at the first failure. A network is layers, each depending on the one below (the Introduction's Step 05). If there's no address, there's no point testing DNS. The lowest thing that's broken is the thing to fix (Steps 03–07).
3. Change one thing at a time, and write it down. If you change three settings and it starts working, you don't know which one fixed it, or whether the other two broke something else.

And one question to ask before all of them: what changed? A network that worked yesterday and doesn't today almost always has a cause that happened in between: a new router, a software update, a moved cable, a changed password, a provider outage.

Before any command, spend thirty seconds on questions. Each one uses a second device or a second connection to rule out a whole area:

• Only one website broken? Try it on your phone with Wi-Fi turned off. If it fails there too, the site is down for everyone and there's nothing to fix at your end.
• Every device in the house? The fault is shared: router, modem or provider. Your laptop is fine; skip to rungs 3–4.
• Only wireless devices? It's the Wi-Fi: signal, band or channel. Everything in the Wi-Fi guide applies.
• Only this device? It's this device's settings, driver or software. Restarting it is a reasonable first step here, and only here.

Here's the whole method on one page. Each rung is one test from the earlier guides. Climb from the bottom and stop at the first rung that fails:

And here's the same ladder laid along the path your packets travel, showing which part of the path each test actually checks:

Rung 1: is there a connection at all?

On a cable: is the port light on at both ends? On Wi-Fi: netsh wlan show interfaces (Windows), Option-click the Wi-Fi icon (Mac), or nmcli dev wifi list (Linux), as in the Wi-Fi guide. You want State: connected and a signal better than about −70 dBm (Windows: above about 60%). If the signal is weak, move closer before testing anything else; every later test will give strange, intermittent results over a bad link.

Rung 2: did it get a proper address?

ipconfig

Read three lines, as in the Introduction's Step 03:

• IPv4 Address starts with 169.254.: the device asked for an address and nobody answered. DHCP failed. That usually means the router's DHCP is stuck, or on Wi-Fi the join didn't complete properly.
• An address on the wrong street, for example 192.168.0.x when the router is 192.168.1.1: a leftover manual setting, or you're on a different network than you think. The subnetting guide explains why two streets can't talk directly.
• No Default Gateway: the device can talk to its own street but has no way off it.

The fix for a missing or odd address is to ask again:

ipconfig /release
ipconfig /renew

Mac: System Settings → Network → your connection → Details → TCP/IP → Renew DHCP Lease. Linux: nmcli con down id "HomeNet" then nmcli con up id "HomeNet", using your connection's name. If it still comes back as 169.254.x.x, and other devices are also failing to connect, the router's DHCP server is the problem, and restarting the router is justified.

Rung 3: can you reach your own router?

Ping the Default Gateway from ipconfig:

ping 192.168.1.1

Replies mean your device, its connection and your local network all work. If this fails but you do have an address, suspect the Wi-Fi link (rung 1 again, especially signal), a wrong subnet mask, or a router that has frozen: its Wi-Fi light may still be on while its brain isn't answering.

Rung 4: can you reach the Internet, by number?

ping 1.1.1.1

This is the most important single test on the page. It goes past your router, through your provider and out to a public server, without using DNS, because you gave it a number. If rung 3 passed and this fails, the fault is between your router and the Internet: the router's connection to the modem, the modem itself, or your provider. Every device in the house will be affected, which Step 02 should already have told you.

To see where the path stops, trace it:

tracert -d 1.1.1.1

Hop 1 answers (your router) and nothing after it does: your provider's side is down or your router isn't connected to it. Compare that with the Introduction's healthy trace, where hop 2 was your provider. (A single * line in the middle of an otherwise working trace is normal, as the Introduction explained; many routers ignore traceroute. What matters is whether anything answers after it.) If you have IPv6, ping -6 2606:4700:4700::1111 tests the same path over IPv6. Occasionally one works when the other doesn't, which is worth telling your provider.

If ping 1.1.1.1 works but websites won't load, it's DNS far more often than anything else. Test it:

nslookup bozcode.com

If that times out or says it can't find the name, ask a different DNS server directly. Put its address after the name:

nslookup bozcode.com 1.1.1.1

This is the key comparison. If the second command works and the first doesn't, the name is fine and so is your Internet connection; your usual DNS server is the problem. That's usually your router passing questions to your provider. Restart the router, or set your device (or the router's DHCP settings) to use 1.1.1.1 and 8.8.8.8. If both fail for this name but work for others, the name itself has a problem, which is the site's to fix.

Devices also remember recent answers. If a site moved or DNS was just fixed, clear the old answers:

If the name resolves and the Internet works, but one site or app still fails, test the service directly. Browsers hide what went wrong; these commands show it. curl is built into Windows 10 and 11, Mac and Linux:

curl -I https://bozcode.com

On Windows, type curl.exe instead of curl. In Windows PowerShell, plain curl is a nickname for a different command, and -I will confuse it.

The first line is the answer. 200 means the site is working and the problem is in your browser: an extension, the cache, a proxy setting. Try a private window. Other numbers tell you where the fault is:

For an app that isn't a website, test whether its port is reachable at all (ports are in the Introduction's Step 05):

Test-NetConnection bozcode.com -Port 443

Mac and Linux: nc -vz bozcode.com 443 prints succeeded or refused. False or a timeout from your network, but success from your phone on mobile data, means something between you and the site is blocking that port: a work network's firewall, a school filter, or occasionally your provider.

Restarting is a legitimate step, not a failure, as long as you know what it fixes. Restarting a device asks for a fresh DHCP lease, clears its DNS cache and resets its network driver. Restarting a router clears a stuck DHCP server, a full connection table, or a router whose software has hung. Restarting a modem makes it re-establish the link to your provider. Unplug it, wait 30 seconds, and give it a few minutes to come back.

Do them in the order the ladder points to, not all at once. Restart the router only if the ladder says the router is at fault. Then run the ladder again, so you know the restart actually fixed it rather than coinciding with it.

When it's your provider

The ladder tells you with confidence: rung 3 passes and rung 4 fails, on every device, including one on a cable, after a modem restart. Before you call, check your provider's outage page from your phone. When you do call, what you've already tested will skip most of the script:

Each case is one that happens in real homes and offices. Decide which rung failed and what you'd do before opening the answer.

1. A laptop shows “No Internet”. ipconfig says its IPv4 address is 169.254.77.12. Every other device is fine.

   Show the answer

   Rung 2: no address. A 169.254.x.x address means DHCP didn't answer this device. Since everything else is fine, the router's DHCP works, so this device is the problem. Run ipconfig /release and /renew. If that doesn't work, forget the Wi-Fi network and join it again (a wrong saved password can fail quietly), then restart the laptop.

2. Nothing in the house can load anything. On a wired laptop, ping 192.168.1.1 gets replies; ping 1.1.1.1 times out.

   Show the answer

   Rung 4: the router can't reach the Internet. The local network is fine (rung 3 passed on a cable, so it isn't Wi-Fi). Check the modem's lights, restart the modem and then the router, and run the ladder again. If it still fails, check the provider's outage page from your phone on mobile data and call them with exactly these results.

3. Websites won't load on any device, but WhatsApp messages still arrive. ping 1.1.1.1 works. nslookup bozcode.com times out, but nslookup bozcode.com 1.1.1.1 works.

   Show the answer

   Rung 5: DNS. The Internet works, and the name is fine when asked of a working server, so your usual DNS server (the router, and the provider's servers behind it) is failing. Some apps keep working because they already know the addresses they need. Restart the router; if it recurs, set the router's DNS to 1.1.1.1 and 8.8.8.8.

4. A new network printer was set up by hand as 192.168.2.50, mask 255.255.255.0. The home network is 192.168.1.0/24. The printer's Wi-Fi light is on, but no computer can find it.

   Show the answer

   Rung 2/3: wrong street. The printer is connected, but it thinks it lives on 192.168.2, while everything else is on 192.168.1. With a /24 mask those are different streets, so nothing can reach it directly (the subnetting guide's practice problem 5). Set it to DHCP, or give it an address like 192.168.1.50. Pick one outside the router's DHCP range so it never clashes with another device.

5. Video calls freeze in the back bedroom but are perfect in the living room. A Mac in the bedroom shows RSSI −78 dBm.

   Show the answer

   Rung 1: weak signal. −78 is well below the −67 usually needed for calls (the Wi-Fi guide's Step 04). The network is fine; the radio link isn't. Move the router to a more central spot, use 2.4 GHz for range, run a cable, or add a mesh or wired access point near the bedroom. A single-radio plug-in extender may raise the bars and still not fix the calls.

6. One work app won't connect from home, but everything else works. On mobile data it connects fine. Test-NetConnection to its server on port 8443 shows TcpTestSucceeded : False from home.

   Show the answer

   Rung 6: a port is blocked on the way. The app, its server and your Internet all work (mobile data proves it). Something on your home path is blocking port 8443: a security feature on the router, security software on the laptop, or less often the provider. Check the router's firewall and parental-control settings, and the laptop's security software, one at a time. Tell the app's support team exactly what you found.

That's the Networking Basics series. You know what a network is and how a packet crosses the Internet. You can subnet by hand, read Wi-Fi like an engineer and decode IPv6, and now you can find what's broken in any of it. This guide was the other four put to work: every rung of the ladder is an idea from one of them.

Check yourself

• You ask “who's affected?” and “what changed?” before touching anything
• You can name the six rungs in order, with the command for each
• You know what a 169.254.x.x address means
• You can tell an Internet fault from a DNS fault with two commands
• You can read a traceroute that stops, and say where
• You can describe a provider fault in one sentence of evidence

Where to go next