Start With the Uncomfortable Answer

Your ISP is probably not throttling your games. Per-application throttling of game traffic is rare, because game traffic is tiny: a typical online match uses well under 1 Mbps in each direction. There is nothing to gain by shaping it, and shaping specific applications requires equipment and effort that produce no bandwidth savings. What people call throttling is nearly always one of four other things, three of which you can identify from home in an evening, and only one of which is genuinely deliberate.

What Throttling Means, Precisely

Throttling is the deliberate reduction of speed for particular traffic, particular customers, or particular times. It is a policy decision implemented in the ISP's network. That is a narrower category than most people use the word for, and keeping it narrow is what makes the diagnosis possible.

Congestion is not throttling. It is demand exceeding capacity on a shared segment, and it looks bad in identical ways without anyone having decided anything. Bufferbloat is not throttling either; it is queueing behaviour, usually in your own equipment. Bad peering is not throttling; it is a routing and capacity relationship between two networks. All three degrade games. None of them are a policy aimed at you, and all three call for a different response.

Four Things Mistaken for Throttling

Cause	Signature	Who Can Fix It
Local bufferbloat	Latency multiplies whenever anyone in the house uploads or downloads; instantly normal again when transfers stop	You, with queue management on your router
Peak-hour congestion	Fine at midday, degrades from roughly 7pm to 11pm, affects every destination equally, follows a daily and weekly rhythm	Your ISP, through capacity upgrades
Peering or transit saturation	One destination or game publisher is bad while others on the same connection are perfect, at the same moment	Your ISP and the network it exchanges traffic with
Data cap enforcement	Speed drops sharply after a specific usage threshold and recovers at the start of the billing cycle; ping usually normal, throughput low	You, by changing plan; it is disclosed policy, not a fault

Bufferbloat First, Always

Rule this out before you accuse anyone of anything, because it is the most common cause and it is entirely inside your house. Oversized buffers in routers and modems mean a single saturating transfer can push your latency from tens of milliseconds into the hundreds, and it recovers the moment the transfer ends. The result feels exactly like an ISP deprioritising your game traffic during busy periods, because your own busy periods correlate with everyone else's.

The test takes two minutes and the fix takes ten. Enabling Smart Queue Management, sometimes labelled fq_codel, cake, or adaptive QoS, resolves it on most modern routers. Full method in our bufferbloat guide. If your latency stays flat under load after this change, you have eliminated the single most likely explanation and everything you measure afterwards is more trustworthy.

The Measurement Protocol

Evidence beats impressions. Anecdotes about last night get nowhere with support; a consistent log across days and destinations gets escalated. Follow this and keep the numbers.

Wire the test machine. Wi-Fi variance will contaminate every reading and give support an easy reason to close your ticket. Use Ethernet for all diagnostics, even if you normally play wireless.
Establish an idle baseline. With the network quiet, run a ping and jitter test and record average latency and jitter. This measures HTTPS round-trips to nearby cloud endpoints, a consistent real-world proxy rather than in-game packets, which is exactly what you want for repeatable comparisons.
Test at four times of day. Morning, early afternoon, 8pm, and after midnight. Same machine, same method, same targets. A clean overnight result with a poor 8pm result is the classic congestion fingerprint.
Test multiple destinations. Compare at least three: a nearby endpoint, one in a distant region, and the game region you actually play on. If one is bad and the others are fine simultaneously, you are looking at a route problem, not a throttle.
Test loaded as well as idle. Repeat the measurement while a large download runs. Note both numbers every time. Loaded latency is the number that reflects real play conditions.
Run a traceroute during a bad period. Not after. The path and the point of degradation both matter, and a trace taken while everything is fine proves nothing.
Log at least a week. Date, time, wired or wireless, idle and loaded latency, jitter, destination, and any traceroute output. Seven days of this is the difference between a support script and an engineer looking at your line.

Reading the Traceroute

A trace shows you where degradation begins, which is the single most useful piece of evidence you can gather. Latency should climb gradually across hops. What matters is a step change: a hop where latency jumps sharply and stays elevated for every hop after it. That is where the problem lives.

Two common misreadings waste enormous amounts of time. First, a middle hop showing high latency or dropped responses while every later hop is fine is not a fault; that router is simply deprioritising the diagnostic traffic it was asked to reply to, which is normal behaviour. Only degradation that persists to the destination counts. Second, the first hop beyond your modem being slow points at your own line or local segment, whereas degradation appearing several hops out, at an exchange point or a network boundary, points at peering. Our traceroute guide walks through real output and how to identify network boundaries.

Distinguishing Peering Problems From Everything Else

Peering is where two networks exchange traffic. When that link is saturated, the symptom is unmistakable once you know to look for it: your connection is excellent to most of the internet and poor to one specific destination, at the same moment, on the same test run. One game publisher is unplayable while every other game is fine. One streaming service buffers while others do not.

This is not throttling and telling support it is throttling will get you nowhere. What works is describing it as a routing or peering issue toward a named destination, with traceroutes showing where the path degrades. It is also the one category that a VPN can sometimes genuinely help with, not by making anything faster, but by routing around the congested exchange. That is a workaround, not a fix, and it costs you latency in exchange for consistency.

Time-of-Day Congestion

If everything degrades together in the evening and recovers overnight, your local segment is oversubscribed. This is most visible on shared-medium technologies where a neighbourhood shares capacity. It is not personal, it is not aimed at gamers, and it affects every service you use. It is also legitimately your ISP's problem to solve, and a documented pattern across several weeks is what triggers a capacity review rather than a scripted reboot suggestion. Background on why evenings are worst is in why is my ping high at night.

Data Caps and Speed Reduction

Some plans reduce your speed after a usage threshold. This one is real throttling, it is in your contract, and it is trivially confirmable: check usage in your account portal and see whether the degradation started at a threshold and ends with the billing cycle. The signature is reduced throughput with roughly normal latency, which is the opposite of the congestion pattern. Note that reduced throughput alone will not ruin a game, since games need very little bandwidth, but it will make the connection feel broken during downloads. If you suspect this, measure throughput properly rather than trusting a single browser test, using the method in how to test internet speed correctly.

What Evidence an ISP Will Actually Act On

Wired results only. Any wireless data in your report gives support a reason to stop reading.
Repeated measurements with timestamps. One bad night is noise. A pattern across a week is a signal.
Comparative destinations. Showing that one path is bad while others are good is far more compelling than showing that one path is bad.
Traceroutes captured during the fault. Include the hop where degradation begins and state it explicitly rather than pasting raw output and hoping.
Precise language. Say sustained packet loss beginning at a specific hop, or latency rising from a baseline to a peak-hour figure on a wired connection, rather than saying the internet is bad. Vague reports get vague responses.

Ask for line signal levels and error counters to be checked, and ask whether your segment has known utilisation issues. Those are questions their tooling can answer. If a documented pattern persists across weeks with no remediation, the honest conclusion is that the capacity is not there and no amount of home configuration will change it.