Wi-Fi, router or ISP? Two pings tell you whose problem it is

"The internet is slow" has three suspects, and each one has a different owner:

• the Wi-Fi link between your device and the router — yours to fix: move closer, change the channel or add an access point;
• the router itself, most often its upload buffer — also yours, often with a single setting if your router has it;
• everything past the router — your provider's, and the only one worth a support call.

Call your ISP about a weak Wi-Fi signal and you can spend an hour on hold, only to hear "please restart your router". Change router settings while the provider's network is congested, and nothing improves. So it pays to know which of the three it is before you touch anything. Two pings, run at the same time, get you most of the way.

Ping the router, not just the internet

Most people ping 8.8.8.8 or a game server and look at one number. That number is the sum of every step along the path, so it cannot tell you where the delay comes from.

Add a second target: your default gateway, which on a home network is your router. The router answers that ping itself, so the round trip covers one hop only — the radio link between your phone and the router, plus the router's own time to reply (more on that in the caveats). Whatever the internet ping adds on top of that happened somewhere past the router.

On a healthy Wi-Fi link the router usually answers within a few milliseconds. My implementation flags the idle router ping as suspect from 30 ms median or 15 ms jitter (jitter is how much the ping times vary from one packet to the next), and as at fault from 60 ms or 30 ms. The idle internet check then looks at latency, jitter and packet loss to public servers. If packets are lost while the router answers cleanly, the loss is put on the path, not on your Wi-Fi.

Then do it again while the line is busy

Idle numbers miss the most common complaint: "it is fine until someone starts a download". That is bufferbloat: under load, a buffer somewhere on the path fills up, and every packet waits in the queue behind it. To find out where that queue is, keep both pings running while you load the line, first with a download and then with an upload. In my implementation that is 5 seconds idle, 10 seconds of download and, after a short pause, 10 seconds of upload.

Then the comparison names the queue:

• The router ping climbs too (by more than about 30 ms, in either direction): the queue forms between the phone and the router. That means Wi-Fi congestion, a weak signal, or the phone's own radio. This check runs first and overrides everything else, because no provider can fix the radio in your living room.

If the router ping stays flat, the line gets a grade from A+ to F, based on how much latency rises under load. A+ to B counts as clean, and there is nothing to attribute. From C down, the two directions are compared:

• Upload is at least twice as bad as download: the upload buffer in your own router or modem. This is the case smart queue management (SQM) on the router is designed for.
• Download is at least twice as bad as upload: the queue is most likely in your provider's network. You cannot fix it at home, but you can document it.
• Both directions are bloated: the modem, or the line between it and the provider.

The core of it is small enough to read in one go. Here is the attribution step from my implementation, trimmed to the logic:

var wifi: Attribution = .ok, router: Attribution = .ok, isp: Attribution = .ok

// 1. Idle router ping: is the Wi-Fi hop itself healthy?
if !onCellular, let m = gatewayMs {
    let j = gatewayJitterMs ?? 0
    if m >= 60 || j >= 30 { wifi = .faulty }
    else if m >= 30 || j >= 15 { wifi = .suspect }
}

// 2. Under load: where did the queue form?
switch verdict {
case .localWifi:     wifi = .faulty      // router ping rose with the internet's
case .uplinkQueue:   router = .faulty    // upload ≥ 2× download, router flat
case .modemOrLine:   router = grade == .c ? .suspect : .faulty
case .ispDownstream: isp = .faulty       // download ≥ 2× upload, router flat
case .carrierSide:   isp = (grade == .d || grade == .f) ? .faulty
                         : (grade == .c ? .suspect : .ok)
case .clean, .cannotGrade: break
}

// 3. Idle loss with a healthy router is on the path.
if let loss = baselineLossRate, loss > 0, wifi == .ok {
    isp = loss > 0.05 ? .faulty : max(isp, .suspect)
}

The order matters, and Wi-Fi gets the first word. A router ping that rises under load makes the verdict "Wi-Fi" before the provider is even considered, and idle loss is blamed on the path only when the Wi-Fi hop looked healthy. A bad radio link spoils every number measured through it, so a provider verdict built on top of it would blame the wrong owner.

Where this breaks

Two pings are a strong signal, not a proof. Cases worth knowing:

• Many routers answer pings with their CPU, not their forwarding hardware. A busy or cheap router can be slow to answer its own pings while it forwards your traffic just fine. So a slow router ping is a reason to test again next to the router, or over a cable, before you buy a mesh system.
• On mobile data there is no router of your own. The first hop is a private address inside the carrier's network (CGNAT), and its latency is not a useful reference. So on cellular the split is skipped, and any queue is reported as being on the carrier's side.
• A target that never answers is not packet loss. Some networks block ping to public servers altogether. Earlier versions of my app averaged those silent targets into the loss figure and could flag the provider because of it. Since 1.4.11 on iOS and 1.0.4 on Android, only targets that answered count towards loss.
• On a phone, a sparse ping can catch the radio asleep. Between packets the phone's Wi-Fi radio dozes to save power. A reply that arrives while it is asleep waits at the router until the next beacon, and beacons usually go out about every 100 ms. The router's own reply is back within a few milliseconds, before the radio dozes, so the router ping stays honest; replies from the internet take longer and can pick up a random extra delay. That delay is the phone, not your provider. To keep the radio awake, my app pings the router every 50 ms while it measures latency, runs traces or tests bufferbloat.
• The test has to actually load the line. If the test server never delivers data, latency stays flat and every verdict above reads "clean". I wrote about that trap separately: My bufferbloat test gave an A+ to a line it never loaded.
• One run is a snapshot. Home lines are busiest in the evening. A clean run at noon says nothing about 21:00, so the useful evidence is a few runs at different times of day, side by side.
• The thresholds are my own choice. 30 and 60 ms for a router ping are where I draw the line; you may draw it elsewhere.

Try it without any app

You can do the manual version on any laptop:

# terminal 1: your router. 192.168.1.1 is only an example; find yours with
# `ip route` (Linux) or `route -n get default` (macOS)
ping 192.168.1.1

# terminal 2: the internet
ping 1.1.1.1

# terminal 3: load the line, e.g. a large download, then a large upload

On Windows, ipconfig shows the router as "Default Gateway", and ping -t keeps pinging until you stop it.

Watch both windows while the load runs. If the router ping stays at a few milliseconds while the internet ping jumps by hundreds, the queue is not on your Wi-Fi. If that happens mainly during the upload, look at your own router or modem; if mainly during the download, at your provider.

I built this into NetDiag+, my network diagnostics app for iPhone and Android. It runs the whole sequence in about 40 seconds and shows the result as a score with separate Wi-Fi, router and ISP rows. After a few runs it can also put them into a report for your provider. If you would rather collect the evidence by hand, I keep a plain-language guide on what a provider actually needs to see: https://netdiag.online/guides/isp-complaint-evidence/

Have you seen a case where the router ping lied — a fast router ping over broken Wi-Fi, or the other way round? I'd like to hear what your setup was. And if you think 30 ms is the wrong line for a router ping, tell me where you would draw it.