My bufferbloat test gave an A+ to a line it never loaded

Some users of my network diagnostics app were getting an A+ bufferbloat grade on connections that, during the test, moved a few kilobits per second. The line was not perfect. The test had simply never loaded it.

Here is how that happens, and the check that was missing.

How a bufferbloat test works

Bufferbloat is what makes a video call stutter while someone else in the house downloads a big file: a buffer in the router or at the provider fills up, and every packet waits in that queue.

A test for it is simple on paper. Measure latency while the line is idle. Then saturate the line with a download and an upload, and see how much latency rises. A small rise is a good grade. A big one means a queue somewhere is soaking up your packets.

There is a quiet assumption inside that: that the load actually happened. If the test server never sends any real data, latency stays flat, the rise is near zero — and the line gets an A+.

The 16 KB problem

According to Cloudflare's own write-up, since 9 June 2025 Russian ISPs have been throttling connections to Cloudflare so that only about the first 16 KB of each response gets through. The connection opens, the HTTP status is 200, a few kilobytes arrive, and then nothing.

My load phase downloads from speed.cloudflare.com for 10 seconds and uploads for 10 more. In parallel it pings the gateway (your router) and an internet host, to see how latency changes under load. On a throttled network the result looked like this:

• download: a few kilobytes, then nothing
• latency under "load": flat, because there was no load
• grade: A+, Clean

Every request "succeeded", so nothing raised an error. The test just never tested anything.

The check that was missing

The fix is to refuse to grade a load that did not happen. It takes two conditions together:

1. Neither direction moved a meaningful amount of data. I use 1 Mbps for the download and 0.5 Mbps for the upload over the 10-second window.
2. Latency stayed flat: the worst spike was under 30 ms.

The second condition matters. A genuinely slow line — old DSL, a weak LTE cell — can also move less than 1 Mbps. But a slow line that is actually loaded builds a queue, and the latency rise gives it away. A line that was never loaded shows no rise at all.

// minLoadMbps = 1.0: download needs 1 Mbps, upload 0.5 Mbps
let downReached = (downloadMbps ?? 0) >= Self.minLoadMbps
let upReached   = (uploadMbps ?? 0) >= Self.minLoadMbps / 2
if !downReached && !upReached && (result.worstSpikeMs ?? 0) < 30 {
    result.grade = .ungraded
    result.verdict = .cannotGrade
    result.loadNotReached = true
    result.downloadMbps = nil
    result.uploadMbps = nil
}

The user now sees "the test server could not be loaded from this network" instead of a clean grade. The overall network score leaves the load and speed points neutral instead of counting them as perfect.

The general lesson

The bug had a simple shape: the test trusted an external server it never validated. A 200 response is not proof of a download. If a measurement depends on a third party behaving normally, the code should check that it did before turning the result into a verdict.

---

The fix is in NetDiag+, my network toolkit: 1.4.10 on iPhone and 1.0.3 on Android. It tries to tell whether a slow connection is the Wi-Fi, the router or the provider. If you want the background on bufferbloat itself, I keep a plain-language guide that now also covers how to read a run that never loaded the line.

Have you seen a network test pass because the thing it measured never happened — a server that returns 200 and then stalls, a proxy that quietly caps a download, something else? I'd like to hear about it in the comments. And if 1 Mbps and 30 ms look like the wrong thresholds to you, tell me why.