A checking order for when the connection is bad

Work outward from your own machine instead of guessing. Six checks in order, each one ruling out a layer, so you stop at the first that fails.

Updated Sep 21, 20264 min read

Before you run anything

These guides are reference material, not instructions for your particular network. Run commands only against networks you own or have explicit permission to examine — in many countries probing a network you are not authorised to touch is a criminal offence regardless of intent. Everything here is provided without warranty: you are responsible for what you run and for its effect on your systems.

“The internet is slow” describes a symptom with at least six possible causes, and the usual response — rebooting the router and hoping — fixes one of them. Working outward in order costs a few minutes and tells you which of the six it is, which matters because five of them are not the router.

Stop at the first check that fails. Everything after it will look wrong regardless.

1. Is it everything, or one thing?

Before touching anything, open something completely unrelated to whatever is failing. A different site, on a different service.

If only one site is slow, it is that site, and nothing you do locally will help. Their servers, their CDN, their region. This is by far the most common answer and the most commonly skipped check.

If everything is slow, continue.

2. Is it this device?

Try a second device on the same network. A phone will do.

If the phone is fine and the laptop is not, the network is fine and the laptop is the problem. Most likely causes, in order: something is saturating the link (a backup, a sync client, an OS update), a VPN is routing everything through a distant server, or wifi on that particular machine has negotiated a poor rate.

Look at what is using the network before blaming anything else:

nettop -m tcp                   # macOS
ss -tunp                        # Linux
netstat -b                      # Windows, needs administrator

A single process at the top of that list is your answer.

3. Is it wifi, or the connection?

Plug in a cable if you can. If a cable fixes it, you have a wifi problem, not an internet problem — and wifi problems are their own investigation: distance, interference from neighbouring networks, a congested channel, or an old device forcing the access point to a slower rate.

No cable available? Stand next to the router and retest. If it improves dramatically, it is signal.

Check what your link actually negotiated:

wdutil info                     # macOS, needs sudo
iw dev wlan0 link               # Linux
netsh wlan show interfaces      # Windows

A receive rate far below what the hardware supports, or an RSSI worse than about −70 dBm, points at signal rather than the connection behind it.

4. Is your own network reaching the router?

Ping the gateway — your router’s address on your network:

ping -c 20 192.168.1.1

Substitute your own gateway; find it with netstat -rn | grep default on macOS, ip route | grep default on Linux, or ipconfig on Windows.

You are looking for two things. Packet loss should be zero. Any loss here is a local problem: cable, wifi, or a failing router. And latency should be a millisecond or two, and steady. Times that swing between 2 ms and 300 ms mean something on your own network is saturating the link — which brings you back to step 2, with a different culprit.

If the gateway does not respond at all and your address starts 169.254, see private and public addresses — you have a DHCP failure, not a slow connection.

5. Is it DNS rather than the connection?

DNS failures impersonate slowness convincingly. Pages hang for seconds before loading, then load instantly once they start, because the wait was name resolution rather than transfer.

Compare resolving a name against reaching an address directly:

ping -c 5 1.1.1.1
dig example.net

If the address pings fine but name lookups are slow or fail, your connection is healthy and your resolver is the problem. Try a different one temporarily — 1.1.1.1 or 8.8.8.8 — and if that fixes it, your ISP’s resolver or your router’s DNS forwarder is at fault.

Time the lookup to be sure:

dig example.net | grep "Query time"

Under about 50 ms is normal for a cached answer. Consistently over 500 ms is a resolver problem.

6. Where does it degrade on the way out?

Only now is traceroute worth running, and only because the previous five checks have ruled out everything closer to you:

mtr 1.1.1.1

Let it run for a minute. You are looking for loss or latency that starts at one hop and continues through every hop after it. A single bad hop with healthy hops after it is almost always the router deprioritising replies rather than a fault — reading traceroute covers why in detail.

If degradation begins at hop 2 or 3 and persists, that is your ISP’s network and you have something concrete to report.

What to send when you escalate

Vague reports get vague responses. Include:

When it happens. Constant, or particular times of day? Time of day strongly suggests congestion rather than a fault.
What still works. “Everything is slow but 1.1.1.1 pings at 12 ms with no loss” is far more useful than “internet is broken”.
Three separate mtr or traceroute runs, with timestamps.
A comparison to a destination that behaves normally.
Your public address and ISP, which the network report collects for you with the address masked if you prefer.

Roughly: steps 1–3 are yours to fix, step 4 is your hardware, step 5 is your resolver, and step 6 is the only one that is genuinely your provider’s. Knowing which before you call saves the twenty minutes they would otherwise spend asking you to reboot the router.

All guides