How to Prove Your ISP Is Throttling You (Not Just Congesting Your Network)

Your ISP can legally slow down your Netflix, YouTube, or gaming traffic without telling you. And as of 2025, in the United States, there is no federal rule stopping them — net neutrality protections have been repealed, restored, and struck down again, leaving consumers with almost no regulatory recourse. Suspecting your ISP is throttling you is one thing. Proving it is another entirely. This guide walks you through a methodical, evidence-based 3-step approach so you can move from "something feels wrong" to a documented paper trail you can actually use. Start with the speed test on whatsmy.fyi to establish your baseline, then follow the steps below.

What Is ISP Throttling?

Bandwidth throttling is the intentional slowing of internet traffic by your Internet Service Provider. The key word is "intentional" — this is not a side effect of a busy network. It is a deliberate policy decision made at the ISP level, applied selectively to specific types of traffic or specific services.

The technology that makes targeted throttling possible is Deep Packet Inspection (DPI). Think of ordinary packet routing like a postal system that reads only the address on the envelope to decide where to send it. DPI is like opening the envelope and reading the contents. ISP-level DPI gear sits in the network path between your home and the rest of the internet, inspecting each packet to identify what application or service it belongs to — Netflix, YouTube, BitTorrent, a gaming server, a video call — and then applying different handling rules depending on what it finds.

This is not theoretical. Commercial DPI hardware is sold specifically to telecoms for "traffic management" purposes, a term the industry prefers to the more accurate "selective speed reduction." A DPI-equipped ISP can identify a Netflix stream by its TLS certificate fingerprint, the IP ranges it connects to, or the pattern of packets even when the content itself is encrypted. Once identified, that traffic class can be rate-limited to a fraction of the bandwidth your plan nominally provides.

Throttling vs Network Congestion: The Key Differentiator

Most people conflate these two things, and ISPs are not in a hurry to clarify the distinction. They are genuinely different problems with different causes, different patterns, and different remedies. Getting this wrong means spending a week chasing a problem that does not exist — or missing a real one.

Congestion is a shared infrastructure problem. When too many people in your neighbourhood are using the network simultaneously, the available capacity is divided between them. Congestion:

• Affects all traffic types equally — Netflix and email slow down together
• Follows predictable time-of-day patterns (evenings on weekdays, weekend afternoons)
• Affects your entire neighbourhood — your neighbours on the same ISP will notice it too
• Varies day to day depending on how many people are home
• Disappears at off-peak hours like late night or early morning

Throttling is a policy decision applied to your specific traffic class. Throttling:

• Affects specific services while others run fine on the same connection
• Is consistent regardless of time of day — the same service is slow at 2am and 8pm
• Does not depend on neighbourhood load — you may experience it when your neighbours do not
• Is reproducible across multiple days and weeks
• Often does not appear on ISP-hosted speed tests, because those tests are sometimes exempt from throttling

Here is the most practical test: if Netflix is buffering on a Tuesday at 11pm but your ISP's own speed test is showing your full advertised speed at the same moment — that discrepancy is almost certainly throttling, not congestion. A genuinely congested network would slow the speed test too. The fact that the ISP's own test runs fast while a third-party streaming service runs slow points directly at selective treatment of specific traffic types.

Real Cases: When ISPs Were Caught

Before you assume this is theoretical, here are three documented cases where ISPs were caught doing exactly this — and where the evidence was assembled through the same methods this guide describes.

AT&T and FaceTime (2012). AT&T restricted FaceTime over cellular data to customers who had unlimited data plans, blocking it entirely for customers on tiered plans unless they upgraded. This was not disclosed at the point of sale and was not network management — it was a business decision to push customers toward more expensive plans. The FCC received complaints and AT&T eventually reversed the restriction after public pressure, but the episode was an early documented example of an ISP blocking a competing communication service.

Verizon and Netflix (2014). This case is significant because it was exposed by data, not just complaints. M-Lab researchers published measurements showing that connections between Verizon's network and Netflix's content delivery network had degraded to the point where video was unwatchable, while Verizon-owned content and other services ran normally. The degradation was consistent over months and correlated precisely with the Verizon-Netflix interconnection points. Verizon disputed the framing, calling it an "interconnection" dispute rather than throttling — but to the end user, the result was identical. Netflix ultimately paid Verizon for a direct connection, after which speeds immediately recovered.

Verizon and the Santa Clara County Fire Department (2018). This case became public during the Mendocino Complex Fire — at the time the largest wildfire in California history. The Santa Clara County Fire Department was using Verizon's network for command and communication during active firefighting operations. Verizon throttled their mobile hotspot data from 50 Mbps to under 1 Mbps mid-fire, citing a data plan limit. Fire personnel tried to reach Verizon to lift the throttle during an active emergency and were told to upgrade to a more expensive plan. The Electronic Frontier Foundation documented this extensively and noted that because net neutrality rules had already been repealed, Verizon faced no regulatory penalty. This case demonstrated clearly that automated throttling systems do not distinguish between a teenager watching YouTube and emergency responders in the field.

The 3-Step Methodical Test

Anecdotes are not evidence. "My Netflix was slow last night" is not something you can file a complaint with. What follows is how you build a case that is based on reproducible, timestamped measurements across multiple days and multiple testing methodologies.

Step 1 — Establish a Baseline

Before you can prove anything is wrong, you need to know what "normal" looks like on your connection. This requires running speed tests at different times over several days and recording the results.

Run a speed test at three different time windows, every day, for at least three days (ideally seven):

• Morning (7–9am): Low-demand period, minimal neighbourhood load
• Evening peak (7–10pm): Maximum residential demand
• Late night (12am–2am): Near-zero load, your connection in isolation

Use the whatsmy.fyi speed test and record download speed, upload speed, and latency in a spreadsheet alongside the exact time. Screenshot each result — the timestamp matters. For the most accurate results: use a wired Ethernet connection rather than Wi-Fi (Wi-Fi introduces its own variability), test from the same device each time, and close other applications using the network during the test.

After three to seven days, look at the pattern. If your evening speeds are consistently 50–80% lower than your late-night speeds, you have evidence of something systematic. If the drop is consistent every evening regardless of day of week — that rules out a temporary outage. If speeds at late night match your advertised plan speed but evenings never do, you have a strong case either for throttling or severe congestion. The next steps distinguish between them.

Critical note: if you are testing a service-specific problem (Netflix is slow but nothing else seems to be), also run the speed test during a Netflix-buffering episode. If the speed test shows full speed while Netflix is simultaneously struggling — you have your throttling indicator right there.

Step 2 — Protocol-Specific Detection with Wehe

A generic speed test cannot tell you whether your ISP is throttling specific applications. For that, you need a tool designed specifically to detect application-level traffic differentiation. Wehe is a free app built by researchers at Northeastern University, funded by the National Science Foundation. It is the most technically rigorous tool available for detecting this specific type of throttling.

Here is how Wehe works, because understanding the methodology is important for interpreting its results. When you run a test for, say, YouTube, Wehe sends two parallel streams of data to its servers:

1. A replay stream that mimics real YouTube traffic as precisely as possible — it uses the same IP addresses, the same TLS fingerprint, the same traffic patterns that a genuine YouTube session would produce. Your ISP's DPI system sees this and classifies it as YouTube.
2. A randomised stream of the same data volume, sent over the same path, but structured in a way that DPI cannot classify it as any known application. Your ISP sees encrypted noise, not YouTube.

If both streams get the same throughput — there is no differentiation. If the YouTube-like stream is measurably slower than the randomised stream — that is statistically strong evidence that your ISP is applying application-specific throttling. Wehe has run millions of tests across dozens of ISPs globally and has identified over 30 ISPs that throttle specific video services. The app exports test results that you can save and reference in a complaint. Wehe is available on both iOS and Android.

Run Wehe tests for every service you suspect is being throttled — Netflix, YouTube, Amazon Prime, Skype. Run each test at multiple times of day and on multiple days. Consistent results showing differentiation across multiple days are far stronger evidence than a single test.

Step 3 — M-Lab NDT7 and Bufferbloat

The third tool in your arsenal is Measurement Lab (M-Lab), a non-profit open internet measurement platform supported by Google, Mozilla, and the Internet Society. Its NDT7 (Network Diagnostic Tool) measures more than raw speed — it also measures bufferbloat, which is one of the more revealing indicators of active traffic shaping.

Bufferbloat is what happens when your connection is saturated and packets queue up in network buffers, adding significant latency. Under genuine congestion, bufferbloat increases roughly in proportion to how loaded the network is. Under deliberate traffic shaping, the pattern is often different — latency spikes can appear even when throughput is relatively low, because the shaping mechanism itself introduces queuing. Unusually high latency during streaming that does not correlate with load on other traffic is a meaningful data point.

Beyond the individual test, M-Lab's real value is aggregate data. M-Lab maintains a public database of historical ISP performance measurements from users around the world. If users on your ISP in your area are consistently under-performing their advertised speeds compared to users on other ISPs in the same region — that aggregate pattern is compelling evidence of systematic under-delivery. You can query this data directly through M-Lab's public BigQuery datasets. A single user having a bad day proves nothing; thousands of users on the same ISP consistently getting 40% of their advertised speed tells a different story.

The CGNAT Caveat

Before you draw conclusions from your tests, there is one infrastructure reality you should check first: Carrier-Grade NAT (CGNAT). As the IPv4 address space has been exhausted, many ISPs have moved to placing hundreds or thousands of residential customers behind a single shared public IP address. You get a private IP inside the ISP's network, and that entire block of customers shares one public IP for outbound traffic.

CGNAT affects your throttling investigation in two specific ways. First, M-Lab's historical performance data is indexed by IP address — if you share an IP with a thousand other customers, the historical data for "your" IP reflects the aggregate behaviour of all of them, not yours specifically. Second, some speed test servers apply geo-based routing or peering rules based on IP address, which can affect results in ways that have nothing to do with throttling.

You can check whether you are behind CGNAT right now on whatsmy.fyi. The IP address displayed on the site is the public IP your traffic appears to come from — the one the internet sees. Log into your router's admin panel (usually 192.168.1.1 or 192.168.0.1) and find the WAN IP address — the IP your router received from your ISP. If the IP on whatsmy.fyi and the WAN IP in your router are different, you are behind CGNAT. Your router has a private address inside the ISP's network, and the public IP you see on whatsmy.fyi belongs to the ISP's NAT gateway. Cloudflare has written about how to detect CGNAT and why it matters for accurate network diagnostics. CGNAT does not prevent you from detecting throttling, but it is context you should include when interpreting aggregate data.

How to Document Your Evidence

Gathering data is only half the job. If you want to file a complaint with a regulator, escalate to your ISP's retention department, or simply have a documented record if things escalate — you need to organise what you have collected.

For each test, capture the following:

• Screenshot of the result with the time and date visible (or manually note it on the screenshot)
• The specific service you were testing (speed test, Wehe Netflix test, M-Lab NDT7)
• Your connection type at the time (wired or Wi-Fi, which device)
• What you were doing when a problem was noticed (which service was slow, what the symptom was)

Export Wehe test results — the app provides a way to share or export the raw result data. Save M-Lab test URLs (each test has a permanent result URL). Keep your speed test screenshots organised by date and time of day.

After one to two weeks of testing, you should have: a table of speed test results across morning, evening, and late-night windows; Wehe test results for the specific services you suspect are throttled; M-Lab NDT7 results; and a written log of specific incidents (what you were doing, what happened, what time it was).

This package is what you need to file a formal complaint with the FCC (United States), the national regulatory authority overseen by BEREC (European Union), or your national telecoms regulator. Regulators respond to evidence, not frustration. The more systematically you have documented the problem, the harder it is to dismiss.

When a VPN Actually Helps — and When It Does Not

A VPN encrypts all of your traffic and tunnels it through a server operated by the VPN provider. From your ISP's perspective, they see one encrypted stream going to the VPN server — they cannot see whether the underlying content is Netflix, YouTube, gaming traffic, or a video call. DPI-based throttling that identifies traffic by application fingerprint cannot work against an encrypted VPN tunnel, because there is no application fingerprint to read.

If you turn on a VPN and your speeds immediately improve on the services you suspected were being throttled — that is itself strong evidence of DPI-based throttling. The speed improvement is the test result. Document it the same way you documented everything else: note the time, the service, the speed before and after, and whether the improvement was consistent.

However, a VPN will not help in several situations. If your ISP throttles total bandwidth regardless of content type — applying a speed cap to your entire connection rather than to specific services — encrypting your traffic changes nothing because the cap applies to everything. Similarly, if the slowdown is genuine network congestion rather than intentional throttling, a VPN adds overhead that will make things slightly worse, not better. A VPN also adds inherent latency because your packets travel to the VPN server before reaching their destination.

The definitive way to use a VPN as a diagnostic tool: run the same Wehe tests with and without the VPN active, on the same day, at the same time of day. If Wehe shows traffic differentiation without the VPN and none with the VPN — you have very clean evidence that the differentiation is DPI-based and application-specific.

FAQ

Is ISP throttling legal?

In the United States, the answer is currently yes — with no meaningful restrictions. The FCC established net neutrality rules in 2015 that prohibited ISPs from throttling specific applications or services. Those rules were repealed in 2017. The FCC restored them in 2024. The Sixth Circuit Court of Appeals struck them down again in January 2025. As of this writing, US ISPs can legally throttle Netflix to 1 Mbps while your ISP-hosted content runs at full speed, and there is no federal rule prohibiting it. State-level rules exist in California and a few other states, but enforcement is inconsistent.

In the European Union, the situation is different. EU Regulation 2015/2120 established net neutrality as binding law across all member states, and BEREC (the Body of European Regulators for Electronic Communications) provides guidelines for national regulators to enforce it. Discriminatory throttling of specific services — intentionally degrading traffic to one video platform while treating another differently — is prohibited. However, enforcement is by national authorities and varies significantly by country. If you are in the EU and you have documented evidence of application-specific throttling, your national telecoms regulator is your first stop.

What if my ISP throttles everything, not just specific services?

This is usually a data cap issue rather than discriminatory throttling. Many ISPs — particularly mobile carriers and some cable providers — include a "fair use" or "data deprioritisation" policy in their contracts: after you consume a certain amount of data in a billing period, all of your traffic is slowed, not just specific services. This is legally distinct from application-specific throttling and is almost always disclosed somewhere in your contract, typically in the fine print of the terms of service.

Check your monthly usage through your ISP's account portal. If you are consistently hitting the threshold before the end of the month, the slowdown you are experiencing may be exactly what your contract describes. The remedy here is a different plan rather than a regulatory complaint. The key diagnostic question is: are specific services slow while others are fast, or is everything slow uniformly? If it is uniform, check your data usage first.

How long do I need to test before my evidence is meaningful?

A single slow evening proves nothing. Your ISP can point to any number of plausible explanations for a single bad data point — a temporary maintenance window, unusual network load, a problem with the specific server your test reached. To build evidence that is hard to dismiss, you need volume and consistency.

The minimum useful dataset is: one week of time-of-day-stamped speed tests (morning, evening, late night) from the same device on the same connection, plus Wehe test results on at least three separate days, plus M-Lab NDT7 results on at least three separate days. Two weeks is better. A month is compelling.

The pattern you are looking for is reproducibility — the same service is slow at the same times in the same way, consistently, regardless of day of week or other variables you control. A consistent pattern over seven or more days across multiple testing methodologies is the kind of evidence that gets taken seriously by regulators and makes ISP customer service representatives escalate your case internally rather than reading from a script.