Is Your ISP Throttling You, or Is It Just Busy?

Throttling and congestion feel identical and need completely different responses. Here is how to tell them apart with evidence, and what to do once you know.

Everything is slow in the evening. Streaming drops to a lower resolution, downloads crawl, and by morning it is fine again.

That pattern has three quite different explanations, and they look identical from your sofa:

• Throttling — your ISP is deliberately limiting something.
• Congestion — the network is oversubscribed and everyone is slow at once.
• A fault at your end — Wi-Fi, an old router, a saturated uplink.

They demand completely different responses. Throttling is a policy question. Congestion is a capacity complaint. A local fault is yours to fix. Guessing wrong wastes weeks, so it is worth being systematic.

Establish a baseline first

The connection test records loss, jitter and latency with a shareable result link. Comparing runs at different times is what turns a complaint into evidence.

Run the connection test →

The 60-second version

If you only do one thing, do this — during a slow period, and within a few minutes:

1. Test a large download from one provider.
2. Test a video stream from a different provider.
3. Run the connection test.

All three slow → congestion. One slow while the others are fine → something is treating that traffic differently, which is either selective shaping or a path problem. The rest of this article is how to tell those two apart and build evidence.

What throttling actually is

Deliberate rate-limiting applied by your provider. It comes in a few forms, and they are not equally common:

Plan-level shaping. You bought a 100 Mbps service; you get 100 Mbps. Not throttling in any meaningful sense, though it gets called that.

Data-cap throttling. You passed an allowance and your speed drops for the rest of the billing period. Common on mobile and some fixed-wireless plans. Usually disclosed, usually obvious — it starts abruptly and does not recover until the cycle resets.

Application or protocol shaping. Specific traffic is limited — historically peer-to-peer, sometimes video. Less common than it once was on fixed lines, still present on some mobile plans where "unlimited" video is delivered at a capped resolution by design.

Congestion management. Under load, some traffic classes are deprioritised. Whether you call this throttling is partly semantic; the practical effect is that it only appears at peak times.

That last category is particularly hard to separate from ordinary congestion, because both become visible mainly at peak.

For the rest of this article, the form of throttling worth testing for is selective rate-limiting — where traffic to one service, protocol or class is treated differently from the rest. That is the version you can actually detect from your side.

The distinction that matters

Throttling is selective. Congestion is not.

Congestion slows everything. If the link is oversubscribed at 9pm, your video, downloads, games and calls all degrade together.

Throttling targets something specific — a protocol, a service, a traffic class — while leaving the rest alone. That selectivity is the fingerprint, and it is what you are testing for.

So the diagnostic question is not "am I slow?" It is: am I slow at some things and not others, at the same moment?

A test sequence that separates them

Each step changes one variable. Do them in order.

1. Rule out your own network first

Before anything else, test wired, with nothing else running. Wi-Fi contention and bufferbloat produce evening slowdowns that look exactly like ISP behaviour, because evenings are when your household uses the connection.

If Ethernet fixes it, stop. It was never your ISP — see what Wi-Fi costs you.

2. Build a time profile

Test at three points across several days: morning, late afternoon, and peak evening. Record every result.

• Consistently slow at all hours → not congestion, and probably not peak-time throttling either. Look for a fault, or a plan that is simply slower than you think.
• Slow only at peak → congestion or congestion-management. Continue.
• Slow starting at a fixed date each month → a data cap. Check your allowance.

3. Test different services simultaneously

This is one of the most useful tests for separating selective treatment from general congestion, and the one most people skip.

During a slow period, test several different things within a few minutes of each other:

• A large download from one provider
• A video stream from another
• The connection test here
• A hop-by-hop MTR to a few different networks

Everything slow together → congestion. One service slow while others are fine → something is treating that traffic differently. That could be shaping, a congested interconnect, or a problem at the far end — one slow destination on its own does not identify which. Test a second source from the same provider before drawing conclusions.

4. Use a VPN as a control

This is the strongest control test available to a consumer — though, as below, not conclusive on its own.

Run the slow service, note the result. Connect to a VPN, run it again immediately.

• Faster over the VPN → your ISP is treating that traffic differently, or routing to it badly. A tunnel hides the inner traffic, so shaping that depends on inspecting or identifying the service no longer has anything to work with. Note the ISP can still see the VPN connection itself, its endpoint and your total volume, and can apply policy to that — so a VPN removes one classification method rather than making you invisible.
• Same or slower → not selective shaping. A VPN adds overhead and distance, so "same speed" already tells you something. This is expected behaviour and covered in why a VPN slows things down.

One important caveat: a VPN also changes your entire route. Faster over a VPN can equally mean your ISP has a congested path to that particular destination rather than a policy against it. Which brings us to the next step.

5. Compare like with like

The weakness of the VPN test is that it changes several things at once. A tighter comparison keeps the destination fixed and varies only the traffic:

• Two large downloads from different providers, to see whether it is one provider or all of them.
• The same file over two different sources where possible — one from the service you suspect, one from a general-purpose host.
• A TCP transfer against a UDP-based test to the same region, since shaping is sometimes applied per protocol.

The more of the setup you hold constant, the more a difference actually means something. "VPN is faster" changes route, endpoint and classification simultaneously, which is why it suggests rather than proves.

6. Check whether it is peering

A congested interconnect between your ISP and one specific provider produces symptoms indistinguishable from throttling: one service is bad, everything else is fine.

An MTR during a slow period, compared against a good period, usually shows where. Look for loss or latency that begins at a hop and continues to the destination — mid-path loss that clears afterwards is not a fault.

If the degradation starts at the boundary between your ISP and a transit provider, that points at an interconnection or routing problem rather than evidence of deliberate throttling. The measurement shows where performance degrades, not who intended it. The distinction matters when you report it, because ISPs will reject a throttling accusation and may act on a routing one.

The whole sequence, as a decision tree

Internet feels slow
        │
        ▼
Rule out Wi-Fi and local equipment      → fixed? stop, it was never the ISP
        │
        ▼
Build a time profile (3 points, several days)
        │
        ├── Slow at all hours ─────────► fault, plan, or equipment
        │
        └── Slow only at peak
                    │
                    ▼
        Test several services within minutes
                    │
        ┌───────────┴────────────┐
        │                        │
  Everything slow          One service slow
        │                        │
   Congestion            Selective treatment
                          OR peering
                          OR the far end
                                 │
                                 ▼
                   VPN comparison + like-for-like test
                                 │
                                 ▼
                          MTR to affected and
                          unaffected destinations
                                 │
                                 ▼
                             Evidence

What the evidence should look like

If you conclude you are being throttled, this is what makes the case:

Slow is not the same as throttled

Without evidence of selectivity — one thing degraded while others were fine at the same moment — you have measured poor performance, not demonstrated throttling.

Without that comparison you do not have a throttling case; you have a slowness complaint, which is a different conversation. The guide to proving packet loss covers how to assemble and present this.

Things that look like throttling and are not

Worth ruling these out before making the accusation, because support will check them first.

The far end is the bottleneck. Slow downloads from one site are frequently that site's problem. Test a second source before concluding anything.

Your own equipment. An older router can be the ceiling, particularly with several devices active. Some cannot sustain their rated throughput while also handling NAT for a busy household.

Wi-Fi. Again. It is a common source of apparent ISP problems and worth ruling out first.

CGNAT relay paths. If you are behind carrier-grade NAT, some peer-to-peer traffic falls back to relays, adding latency that has nothing to do with shaping.

DNS. Slow name resolution feels like a slow connection because every page waits on it first. It affects how quickly connections start rather than throughput, so compare raw IP connectivity against lookup timing before blaming the ISP — a separate and easily tested problem.

Buffering that is not bandwidth. Video dropping resolution can be jitter rather than throughput.

Frequently asked questions

How can I tell if my ISP is throttling me?

Test several different services within a few minutes of each other during a slow period. Congestion slows everything at once; throttling is selective. If one service is slow while others are fine — and a VPN makes that one faster — you have evidence of selective treatment.

Does a VPN stop ISP throttling?

It stops shaping that depends on identifying the application or service, because encrypted traffic cannot be classified that way. It does not stop congestion, plan-level limits, or data-cap throttling, since those apply to all your traffic regardless of what it contains.

Can a VPN prove my ISP is throttling me?

No — it is a useful comparison, not proof. A VPN changes the route, the endpoint and how your traffic can be classified, all at the same time, so a faster result could equally mean your ISP has a congested path to that destination. Reproduce it across several runs, and pair it with a like-for-like test that holds the destination fixed.

Is it throttling if my internet is only slow in the evening?

Usually not — that is the classic signature of congestion, where more subscribers share the same capacity at peak. It only becomes a throttling case if specific services are slow while others are fine at that same moment.

Why is my internet slow only for one website?

Often a congested interconnect between your ISP and that provider, or a problem at the provider or its CDN. A single slow destination is the weakest possible throttling evidence, because so many other things produce it. An MTR during a bad period shows where the degradation starts, and testing a second service from the same provider separates the provider from the path.

Can my ISP throttle me without telling me?

Policies are generally disclosed somewhere in the terms of service, though rarely prominently. Congestion-management practices in particular are often described in general language that is hard to map onto what you are experiencing. Documented measurements are more useful than the policy text.

Will complaining to my ISP actually help?

It depends entirely on what you bring. "My internet is slow" gets a router reboot script. Timestamped measurements showing a specific service degraded while others were fine, tested wired, reproduced across days, gets escalated to someone who can look at the network.