How to Prove Your ISP Is Throttling You — With Real Data

You feel your ISP is throttling you. The streaming buffers. The download crawls. But every time you actually run Speedtest, the number looks fine. What gives?

Either your ISP isn’t throttling and the bottleneck is elsewhere, or it is throttling and Speedtest is exactly the wrong tool to catch it. Real ISPs that throttle do it selectively: certain protocols, certain destinations, certain times of day. They tend not to throttle Speedtest. That’s the whole point of throttling — discriminate by what the traffic looks like, while keeping the benchmark number clean.

This post is about gathering evidence good enough to be useful — to file a complaint, to switch providers, or to confirm to yourself that the problem really is the ISP and not your router.

What “throttling” actually looks like

Before testing, know what you’re looking for. Three patterns are common:

1. Time-of-day caps. Throughput is fine at 03:00, terrible at 20:00. This usually isn’t deliberate throttling — it’s an oversubscribed link congesting at peak hours.
2. Per-destination caps. Speedtest shows full speed; downloads from a specific CDN (Netflix, YouTube, a game launcher) crawl. This is typically a peering or transit dispute, not classical throttling.
3. Per-protocol caps. TCP works fine, UDP gets shaped. Or HTTP works, BitTorrent doesn’t. Modern home ISPs do this less than they used to, but it still happens.

Speedtest can’t catch any of these because it tests one specific destination, over TCP, on demand. It is a single data point that the ISP knows is being measured.

What iPerf3 measures differently

Compared to Speedtest, iperf3 has two properties that matter for throttling investigations:

• You control both endpoints. No assumption that the ISP routes “good” traffic to the Speedtest server.
• You can vary the test. TCP and UDP, different durations, different times of day, different remote endpoints. A single tool that flexes across many shapes of traffic.

Used carefully, that lets you gather evidence of the patterns Speedtest can’t see.

A minimum credible setup

For an investigation, you need:

1. A remote iperf3 server you trust — not the ISP’s own. Three reasonable options:
   • Rent a $5/month VPS (Linode, Hetzner, DigitalOcean) and run iperf3 on it.
   • Use a friend’s home server in a different city, on a different ISP.
   • Use one of the public iperf3 servers listed in the directory inside the app (filter by region).
2. A test device that can reach that server. Phone, laptop, or a wired box behind the same router as everything else in the house.
3. A schedule. Throttling investigations need more than one data point. One bad result at 21:00 means nothing without ten good ones at 03:00.

A VPS is the gold standard because you can confirm the server isn’t itself the bottleneck (a $5 VPS will easily push 1 Gbps).

What to run, in what order

The investigation pattern is “narrow down what changes the result”:

1. Baseline. TCP, 30 seconds, 4 parallel streams, against your trusted remote endpoint, in the middle of the night when the network should be uncongested. Record the number.
2. Same test, peak hours. 20:00 or whenever the issue actually shows up. Look for a delta from baseline.
3. UDP instead of TCP. Same endpoint, same time. If UDP throughput is wildly lower than TCP, that’s a signal of protocol shaping.
4. Different endpoint. Same time, different remote server. If one server is fine and another isn’t, the issue is on the path to that specific destination, not blanket throttling.
5. VPN comparison. Connect a commercial VPN, repeat the test. If results jump up through the VPN, that’s strong evidence of ISP-side traffic shaping — the ISP can’t classify what’s inside the encrypted tunnel.

The VPN test is the most decisive. If the throughput through a VPN is meaningfully higher than without, you have a positive signal of differential treatment by the ISP. There aren’t many other explanations.

Documenting the results

For a complaint that anyone will take seriously:

• Timestamps for every test. The app saves them automatically; don’t strip them on export.
• Source IP (your home WAN IP at test time). Helps the ISP confirm which subscriber you are.
• Destination IP and port of the test server. Same reason.
• TCP retransmit count and RTT. These appear in the detailed result view. Retransmits climbing suggest packet loss on the path, which is a stronger signal than bandwidth alone.
• Raw iperf3 JSON output if available. The app exports it. Engineers will respect raw output more than screenshots.

Export the full set of sessions as JSON or CSV. Attach it to whatever you file. Most ISP complaint processes don’t ask for this much detail; the ones that do (regulators, consumer-protection bodies) will weight it heavily.

Common false positives

Things that look like throttling but aren’t:

• Your Wi-Fi. Test on Ethernet first to remove this variable. If results are 700 Mbps on Ethernet and 200 Mbps on Wi-Fi, blame Wi-Fi, not the ISP.
• Your router CPU. Old or low-end routers can’t push more than 300–500 Mbps regardless of what your plan is. Bypass with a direct modem connection if possible.
• The test server being overloaded. Public iperf3 servers, especially free ones, get hammered. Always confirm a baseline with the server before drawing conclusions.
• A single bad measurement. Networks are noisy. One throttled-looking result amid ten clean ones is not a pattern — it’s just noise.

The discipline is to eliminate everything you control before pointing at the ISP. If you can show clean results from your laptop, on Ethernet, at 03:00, against three different remote endpoints — then point to the bad results at peak hours with the same setup, your evidence is taken seriously. If you can only produce “Speedtest sucks at night,” it isn’t.

Practical timeline

A real investigation looks like this:

• Week 1. Stand up a remote iperf3 endpoint. Run baseline tests three times a day for a week. Build up your “normal” pattern.
• Week 2. Add the variations — UDP, different endpoints, VPN comparison — at the same times of day. Look for which variations change the result.
• Week 3. Repeat the strongest signal three more times to confirm it’s reproducible.
• End of week 3. You either have a clear pattern or you don’t. If you do, package the data with timestamps and IPs. If you don’t, the bottleneck is somewhere else in your network — usually Wi-Fi.

This is more work than running Speedtest, but it’s the only investigation that actually answers the question.

Bottom line

Most “my ISP is throttling me” complaints turn out to be Wi-Fi, an old router, or peak-hour congestion that isn’t deliberate. The minority that are throttling can almost always be demonstrated with a structured iperf3 investigation against a server the ISP isn’t optimising for. If you have the data, you have a case. If you only have Speedtest screenshots, you have neither.