What is VPN speed throttling?

VPN speed throttling is any reduction in throughput or increase in latency that a household experiences while the VPN tunnel is active, compared to the throughput and latency on the same household's internet connection without a VPN. Throttling can come from the VPN server (finite bandwidth, finite CPU, oversubscribed server), from the encryption and decryption cost of the protocol, from the distance between the user and the server, from the time of day, from the VPN provider's per-server or per-account throughput caps, and from the user's own ISP shaping encrypted traffic. Each source shaves the working speed by a different amount, and the cumulative effect is usually 30% to 70% of the household's base upstream and downstream.

How much speed does a VPN typically lose on a modern plan?

A modern consumer VPN on WireGuard typically retains 70% to 90% of the base connection's speed on a nearby server during off-peak hours, and 40% to 70% on a distant server during peak hours. OpenVPN typically retains 30% to 60% of the base speed on a nearby server, and 15% to 40% on a distant server during peak hours. The exact retention depends on the provider's server fleet, the user's base connection, the protocol, the encryption cipher, and the activity mix. The honest working speed on a 100 Mbps connection is usually 40 to 70 Mbps on WireGuard, and 20 to 50 Mbps on OpenVPN, before the household's own contention kicks in.

Why does my VPN slow down during peak hours like 8 PM to 11 PM?

VPN speed drops during peak hours for two reasons. First, the VPN server is shared across many users at the same time, so the server's bandwidth and CPU are spread thinner. A server that delivers 80 Mbps per user at 2 PM may deliver 30 Mbps per user at 9 PM, because the number of concurrent users has multiplied. Second, the path between the user and the server is shared with more traffic on the wider internet during peak hours, so the path itself is more congested. The combined effect is that throughput drops 40% to 60% from off-peak to peak on the same plan, with no change to the plan, the protocol, or the server.

2026-07-08VPN · Speed Throttling Cost⏱ 9 min read

VPN Speed Throttling Real Impact: What Reduced Speed Actually Costs You

Q: What does reduced VPN speed actually cost a household?

Reduced VPN speed costs the household in four measurable ways. First, streaming quality drops: a 4K stream needs 25 Mbps sustained, an HD stream needs 5 to 8 Mbps, and a SD stream needs 1 to 3 Mbps. If the working speed drops below 25 Mbps during peak hours, the stream downshifts to HD or SD, which is a quality cost. Second, download time grows: a 10 GB download that takes 15 minutes at 80 Mbps takes 40 minutes at 30 Mbps, and 80 minutes at 15 Mbps. Third, video calls drop frames: Zoom, Teams, and Meet need 3 to 5 Mbps sustained upstream and downstream for a stable 1080p call; below that, the call drops to 720p or freezes. Fourth, battery drain on phones and laptops increases, because the radio stays active longer to push the same amount of data through a slower tunnel.

Q: Does the VPN protocol really change the working speed that much?

Yes. WireGuard uses modern cryptography (ChaCha20 for symmetric encryption, Curve25519 for key exchange) and runs in the kernel on most platforms, so the encryption and decryption cost is roughly a third of OpenVPN's. On the same server, same base connection, same time of day, WireGuard typically delivers 30% to 80% higher throughput than OpenVPN. IKEv2 sits between WireGuard and OpenVPN. The protocol choice is the single most underweighted variable in the working-speed conversation, and switching from OpenVPN to WireGuard often doubles the working speed with no plan change.

Q: Can my ISP throttle VPN traffic on top of the VPN server's own slowdown?

Yes. Some ISPs apply traffic-shaping rules to encrypted traffic patterns, especially when the encrypted traffic is sustained at high throughput for long periods (large downloads, 4K streaming, peer-to-peer). The shaping is hard to detect from the user side, because the throughput drops without an obvious error message, but the pattern is consistent: throughput drops to a fixed ceiling (often 30% to 50% of the unshaped speed) for the duration of the high-throughput activity. Obfuscated servers, multi-hop, and switching protocols can sometimes recover the lost throughput, but the only sure way to confirm ISP shaping is to run the same workload through a different ISP or through a mobile hotspot and compare the throughput.

The throughput number on a VPN pricing page is the second most oversold number in the consumer VPN market, after the simultaneous connection count. The plan advertises "lightning-fast" or "unlimited bandwidth" or a specific megabits-per-second figure, and the buyer assumes the whole household will run at the marketed speed at the same time, every day, for the life of the plan. In practice, the working speed is meaningfully lower than the marketed speed because the server's bandwidth and CPU are shared across every active connection, the encryption and decryption cost adds 5% to 60% of overhead on top, the distance to the server adds 10% to 40%, peak-hour load adds another 30% to 60%, and the household's own upstream is shared across every device. This guide walks through what VPN speed throttling actually is, where the throughput goes, what reduced speed costs in streaming quality, download time, video-call frames, and battery, and the cheapest way to find the real working speed on a plan before committing to a multi-year term.

Summary

VPN speed throttling is any reduction in throughput or increase in latency while the tunnel is active, compared to the household's base connection without a VPN.
The honest working speed on a modern plan is 40% to 90% of the base connection on a nearby server during off-peak hours, and 15% to 70% during peak hours or on a distant server.
Protocol choice is the single most underweighted variable: WireGuard typically delivers 30% to 80% higher throughput than OpenVPN on the same server, same plan, same time of day.
Reduced speed costs the household in streaming quality (4K drops to HD or SD), download time (a 10 GB file takes 2x to 5x longer), video-call frames (drops to 720p or freezes), and battery drain on phones and laptops.
ISPs can shape encrypted traffic on top of the VPN server's own slowdown, capping throughput at 30% to 50% of the unshaped speed for sustained high-throughput activities.
The cheapest way to find the real working speed is to run a household speed test during the 30 to 45 day money-back window, comparing nearby vs distant servers, WireGuard vs OpenVPN, and off-peak vs peak hours.

Short answer

VPN speed throttling is the reduction in throughput and the increase in latency that a household experiences while the VPN tunnel is active, and it stacks from five sources: the VPN server's bandwidth and CPU, the encryption and decryption cost of the protocol, the distance between the user and the server, the time of day, and the user's own ISP shaping encrypted traffic. On a 100 Mbps base connection, the honest working speed is 40 to 70 Mbps on WireGuard and 20 to 50 Mbps on OpenVPN during off-peak hours, dropping to 15 to 40 Mbps during peak hours or on a distant server. Reduced speed costs the household in streaming quality (4K drops to HD or SD), download time (a 10 GB file takes 2x to 5x longer), video-call frames (drops to 720p or freezes), and battery drain (radios stay active longer). The cheapest way to find the real working speed is to run a household speed test during the 30 to 45 day money-back window, comparing nearby vs distant servers, WireGuard vs OpenVPN, and off-peak vs peak hours, and to switch providers inside the window if the working speed is too low.

What VPN speed throttling actually is

The word throttling on a VPN pricing page is one of the most consistently misread words in the consumer subscription market, and the misreading shows up in three different ways. First, throttling is not the same as a hard cap. Most consumer VPN plans do not impose a hard throughput cap; they advertise unlimited bandwidth and rely on the network and the server to deliver whatever speed the household can sustain. The reduction in throughput comes from the network and the server's constraints, not from a deliberate cap. Second, throttling is not the same as throttling by the ISP. Some ISPs shape encrypted traffic on top of the VPN server's own slowdown, but most of the speed reduction a household sees is from the VPN side, not the ISP side. Third, throttling is not constant. The working speed varies by server, protocol, time of day, and household contention, so a single speed test does not predict the household's real working speed.

The clarifications below are worth stating explicitly because they shape the buyer's mental model of the working speed.

Throttling is a reduction, not a cap: most consumer plans do not impose a hard throughput cap. The reduction comes from shared bandwidth, shared CPU, encryption overhead, server distance, peak-hour load, and ISP shaping. Each source shaves the working speed by a different amount.
Throttling stacks from multiple sources: the working speed is the result of five constraints, and each constraint shaves a different fraction of the base speed. A nearby server on WireGuard during off-peak hours loses 10% to 30%; a distant server on OpenVPN during peak hours loses 60% to 85%.
Throttling varies by time of day: throughput on the same server, same protocol, same base connection typically drops 40% to 60% from off-peak to peak. A plan that delivers 80 Mbps at 2 PM may deliver 30 Mbps at 9 PM, with no change to the plan, the protocol, or the server.
Throttling varies by server: nearby servers (under 500 km) typically deliver 30% to 80% higher throughput than distant servers (over 3,000 km) on the same plan. The user's city-to-server distance is one of the largest variables in the working-speed equation.
Throttling varies by protocol: WireGuard on the same server typically delivers 30% to 80% higher throughput than OpenVPN. The protocol choice is the single most underweighted variable in the working-speed conversation.
ISP shaping is a separate variable: some ISPs cap encrypted traffic during sustained high-throughput activities (large downloads, 4K streaming). The cap is hard to detect from the user side, but the pattern is consistent and recoverable only by changing protocols, using obfuscated servers, or switching networks.

These clarifications are not hidden, but they are usually buried in the FAQ or the support knowledge base rather than on the pricing page. The pricing page says "lightning-fast," and the buyer assumes the whole household runs at full speed every day, which is rarely what the plan actually delivers.

The line items that make up the real cost of speed throttling

The price comparison "unlimited bandwidth for $4 per month" hides a much longer list of line items that affect what the household actually gets. The table below lines up the line items, what each one typically looks like, and what it is really worth in throughput, latency, or working hours. Numbers are illustrative ranges across common consumer VPN providers; verify the actual throughput, server list, supported protocols, and per-server bandwidth on the provider's pricing or support page before signing up.

Cost line item	Typical behavior	What it is really worth
Base connection speed	100 Mbps typical for a home fiber or cable connection; 500 Mbps to 1 Gbps on premium plans	The reference speed without the VPN; the working VPN speed is a fraction of this number
Working speed on nearby server, WireGuard, off-peak	70% to 90% of base; 70 to 90 Mbps on a 100 Mbps connection	The realistic best-case working speed on a modern plan with the right protocol and server
Working speed on nearby server, OpenVPN, off-peak	30% to 60% of base; 30 to 60 Mbps on a 100 Mbps connection	OpenVPN adds more overhead than WireGuard, so the working speed is lower at the same conditions
Working speed on distant server, WireGuard, off-peak	40% to 70% of base; 40 to 70 Mbps on a 100 Mbps connection	A 3,000 km server adds 10% to 40% throughput loss compared to a 200 km server on the same protocol
Working speed on nearby server, WireGuard, peak hour (8 PM to 11 PM)	40% to 70% of base; 40 to 70 Mbps on a 100 Mbps connection	Server load during peak hours cuts the working speed by 30% to 50% even with no other change
Working speed on distant server, OpenVPN, peak hour	15% to 40% of base; 15 to 40 Mbps on a 100 Mbps connection	The worst-case realistic working speed; this is what a household sees during evening streaming hours on a long-distance server
Protocol overhead (WireGuard vs OpenVPN)	WireGuard uses ~30% of OpenVPN's CPU; ~30% to 80% higher throughput on the same server	Switching protocol is the single cheapest working-speed upgrade; it costs nothing and often doubles the working speed
Encryption cipher overhead (AES-256-GCM vs ChaCha20)	AES-256-GCM is the default on OpenVPN; ChaCha20 is the default on WireGuard; ChaCha20 is faster on devices without AES-NI	The cipher choice matters more on phones and older laptops than on desktop CPUs with hardware AES acceleration
ISP shaping of encrypted traffic	Some ISPs cap encrypted traffic at 30% to 50% of unshaped speed for sustained high-throughput activities	The cap is hard to detect from the user side; the only sure way to confirm is to compare throughput on a different ISP or a mobile hotspot
Multi-hop or double-VPN cost	Halves the effective working speed because every byte is encrypted twice; doubles the latency	Multi-hop is rarely worth the throughput hit unless the threat model requires it; the working speed drops to 10 to 25 Mbps on a 100 Mbps connection
Server distance impact	A 5,000 km server typically adds 80 ms to 150 ms of latency vs a 200 km server's 10 ms to 30 ms	Latency-sensitive activities (gaming, video calls, SSH) suffer most; throughput-sensitive activities (file downloads, video streaming) suffer less
Per-server load impact	A server at 80% utilization typically delivers 50% to 70% of the throughput of the same server at 30% utilization	The provider's server-load dashboard (sometimes public, sometimes in the app) is the cheapest way to find an under-loaded server
Money-back window for speed testing	30 to 45 days on most consumer plans; 7 to 14 days on monthly plans	The window for running a household speed test across servers, protocols, and time of day before committing
Plan upgrade for higher working speed	$2 to $6 per month more for a higher tier that includes dedicated bandwidth or premium servers	The cleanest single purchase for a household that is consistently below the working-speed floor; the working speed typically rises by 20% to 50% on the upgrade
Split tunneling impact on working speed	Routes non-VPN traffic outside the tunnel, freeing bandwidth for VPN traffic	Split tunneling effectively raises the working speed by 20% to 50% on heavy-traffic devices, because non-VPN traffic stops competing for the tunnel

The cheapest way to read this table is to assume the marketed speed covers only the best case (nearby server, WireGuard, off-peak), and that the working speed is a fraction of the marketed speed once server distance, protocol choice, encryption overhead, peak-hour load, ISP shaping, and household contention are factored in. The right answer depends on which constraint binds first for the household in question.

Why protocol choice is the single biggest working-speed variable

Protocol choice is the most underweighted variable in the working-speed conversation, and it is the one most likely to swing the working speed by 30% to 80% without changing the plan or the price. The three protocols most consumer VPN providers support are WireGuard, OpenVPN, and IKEv2, and they differ in CPU cost, throughput, and latency in ways that matter for the working speed.

WireGuard is the most efficient. It uses modern cryptography (ChaCha20 for symmetric encryption, Curve25519 for key exchange) and runs in the kernel on most platforms, which means the encryption and decryption cost is roughly a third of OpenVPN's. On the same server, same base connection, same time of day, WireGuard typically delivers 30% to 80% higher throughput than OpenVPN, and the latency is roughly half. The trade is that WireGuard is newer, has fewer configuration options, and is not supported on every server or every router.

OpenVPN is the most widely supported. It runs in user space, which makes it portable across routers, NAS devices, and embedded platforms, but the user-space execution path adds CPU overhead. AES-256-GCM is the default cipher, and the throughput drop compared to WireGuard is roughly 30% to 80% on the same hardware. OpenVPN is also more configurable, which is why it remains the default on many router apps. On devices without hardware AES acceleration (older laptops, low-end phones), OpenVPN can drop to 15% to 30% of the base speed, while WireGuard holds 50% to 70%.

IKEv2 sits between WireGuard and OpenVPN. It is mobile-friendly (it survives network changes like switching from Wi-Fi to cellular without dropping the tunnel), and the CPU cost is closer to WireGuard than to OpenVPN. The downside is that IKEv2 is less widely supported on consumer routers, and the configuration is less well documented.

The protocol choice is not always available on every server, and the router app may default to OpenVPN for compatibility reasons. The cheapest way to get the most working speed from a plan is to set the protocol to WireGuard on every device that supports it, and to verify the setting in the app or the router admin panel. The change is free, and the working speed typically rises by 30% to 80%.

What reduced speed actually costs a household

Reduced VPN speed is not abstract. It shows up in four measurable places in the household: streaming quality, download time, video-call frames, and battery drain. Each one has a real cost in money, time, or quality, and the cumulative effect is what most buyers underestimate when they sign up for a plan.

Streaming quality: the four common streaming tiers and the sustained throughput they need are 4K at 25 Mbps, 1080p HD at 5 to 8 Mbps, 720p at 3 to 5 Mbps, and 480p SD at 1 to 3 Mbps. If the working VPN speed drops below 25 Mbps during peak hours, the 4K stream downshifts to 1080p, which is a visible quality cost on a large TV. If the working speed drops below 5 Mbps, the stream downshifts to 480p, which is unwatchable on most modern TVs. The honest working speed for a household that wants 4K streaming on multiple TVs at the same time is 50 to 75 Mbps sustained, which means a base connection of at least 100 Mbps on WireGuard, or 150 Mbps on OpenVPN.

Download time: a 10 GB file that takes 15 minutes at 80 Mbps takes 40 minutes at 30 Mbps, and 80 minutes at 15 Mbps. The growth is linear, not exponential, but the time cost is real. A household that regularly downloads large files (game installers, OS updates, video assets, backups) loses hours per month to throttling that the pricing page does not mention. The honest working speed for a household that runs large downloads regularly is 30 to 50 Mbps sustained, which means a base connection of at least 50 Mbps on WireGuard, or 100 Mbps on OpenVPN.

Video-call frames: Zoom, Teams, Meet, and similar tools need 3 to 5 Mbps sustained upstream and downstream for a stable 1080p call, and 1 to 3 Mbps for a 720p call. Below 1 Mbps sustained, the call drops frames, freezes, or falls back to audio-only. The honest working speed for a household that runs video calls from home is 5 to 10 Mbps sustained upstream, which means a base connection of at least 25 Mbps upstream on WireGuard, or 50 Mbps upstream on OpenVPN. The upstream constraint is often tighter than the downstream constraint, because most home connections are asymmetric.

Battery drain: a phone or laptop radio that is pushing data through a slower tunnel stays active longer to deliver the same amount of data, and the longer active time costs battery. The cost is meaningful on phones (10% to 30% faster drain during sustained VPN use) and on laptops (15% to 40% faster drain during sustained VPN use). For a household that runs the VPN on phones during a workday, the battery cost is real, and the cheapest mitigation is to use split tunneling so the radio does not push background traffic through the tunnel.

ISP shaping on top of the VPN's own slowdown

Some ISPs apply traffic-shaping rules to encrypted traffic patterns, especially when the encrypted traffic is sustained at high throughput for long periods. The shaping is hard to detect from the user side, because the throughput drops without an obvious error message, but the pattern is consistent: throughput drops to a fixed ceiling (often 30% to 50% of the unshaped speed) for the duration of the high-throughput activity, and recovers when the activity stops.

The shaping is most aggressive on peer-to-peer traffic (torrents, large file transfers) and on sustained 4K streaming, and least aggressive on bursty traffic (browsing, email, short video clips). The shaping is hard to confirm from the user side because the user sees the combined effect of the VPN server's slowdown and the ISP's shaping. The cheapest way to confirm ISP shaping is to run the same workload through a different ISP (a mobile hotspot, a friend's connection, a different home network) and compare the throughput. If the throughput is meaningfully higher on the alternative network, the original ISP is shaping.

The mitigations vary. Some providers offer obfuscated servers that disguise VPN traffic as regular HTTPS traffic; the obfuscation sometimes bypasses the shaping. Multi-hop routes the traffic through two servers, which can sometimes bypass per-flow shaping. Switching protocols (WireGuard to OpenVPN or vice versa) can sometimes recover the lost throughput, because some shaping rules are protocol-specific. The only sure way to bypass ISP shaping is to switch ISPs or to accept the shaped throughput as the household's working speed.

Three household scenarios and the working speed on each

The example below compares three household working-speed scenarios using the same cost assumptions across each. The numbers are illustrative, but the structure of the trade shows up across most households.

Scenario A: solo user, browsing and email, on a 100 Mbps base connection. A single user who browses, emails, and occasionally streams a 1080p video needs 5 to 10 Mbps sustained. WireGuard on a nearby server delivers 70 to 90 Mbps during off-peak and 40 to 70 Mbps during peak. OpenVPN on the same server delivers 30 to 60 Mbps during off-peak and 20 to 40 Mbps during peak. Either protocol comfortably covers the household need, and the cheapest answer is the cheapest plan tier with WireGuard enabled.

Scenario B: two-adult household with 4K streaming, on a 200 Mbps base connection. Two adults, each streaming 4K on a different TV at the same time, plus background browsing and email. The household needs 50 to 60 Mbps sustained for the two 4K streams alone, plus 5 to 10 Mbps for background use. WireGuard on a nearby server delivers 140 to 180 Mbps during off-peak and 80 to 140 Mbps during peak. OpenVPN delivers 60 to 120 Mbps during off-peak and 40 to 80 Mbps during peak. WireGuard comfortably covers the household; OpenVPN covers off-peak but may drop below the household need during peak hours on a distant server.

Scenario C: family with home office and 4K streaming, on a 500 Mbps base connection. Two adults streaming 4K, a work video call on a third device, and a download running on a fourth device. The household needs 50 to 60 Mbps for streaming, 5 Mbps for the video call, and 30 Mbps for the download — roughly 90 Mbps sustained, with tight latency constraints on the video call. WireGuard on a nearby server delivers 350 to 450 Mbps during off-peak and 200 to 350 Mbps during peak. OpenVPN delivers 150 to 300 Mbps during off-peak and 100 to 200 Mbps during peak. WireGuard on a nearby server covers the household; OpenVPN covers off-peak but may drop the video call below usable quality during peak hours or on a distant server.

The pattern across the three scenarios is that the working speed is bounded first by server distance, then by protocol choice, then by peak-hour load, and finally by ISP shaping. The right answer for a household depends on which constraint binds first, and the cheapest way to find the real constraint is to run a household speed test across all four variables during the money-back window.

Affiliate-aware note: CJ-partner providers and working speed

PriceGap currently does not claim current advertiser approval with any VPN provider, and this article contains no advertiser checkout links. For context, providers that PriceGap tracks as potential CJ advertiser candidates — such as NordVPN — are part of a separate advertiser-application workflow. If a future affiliate link is added to this page, it would be a tracked link to a specific provider's pricing or deal page, and it would be labeled accordingly in the disclosure. The decision about whether a VPN plan delivers the working speed a household needs should be based on your own household speed test, your own base connection, your own server distance, and your own activity mix during the money-back window, not on which provider pays a commission.

Common speed-throttling mistakes to avoid

The pattern of mistakes below shows up repeatedly in user reports and support tickets. They are listed here because each one is cheap to avoid once you see it.

Trusting the advertised speed number. Consumer VPN pricing pages rarely quote a specific throughput; when they do, it is usually the best-case number on a nearby server during off-peak. The honest working speed is 40% to 90% of the base connection on WireGuard, and 15% to 60% on OpenVPN. Verify the working speed on the household's own connection during the money-back window.
Leaving the protocol on OpenVPN when WireGuard is available. WireGuard is 30% to 80% more efficient on the server and on the client than OpenVPN, which means the working speed often doubles with no plan change. Check the protocol setting on every device and on the router, because the router app sometimes defaults to OpenVPN for compatibility reasons.
Testing the plan during off-peak and assuming peak performance. A plan that delivers 80 Mbps at 2 PM may deliver 30 Mbps at 9 PM, because the server is shared with more users during peak hours. Test during the household's busiest hour, not during off-peak.
Using a distant server when a nearby server is available. A 5,000 km server typically delivers 30% to 80% lower throughput than a 200 km server on the same plan, same protocol, same time of day. Use the closest server that meets the household's geo-location need.
Ignoring upstream speed. The household's upstream is often tighter than the downstream, and the upstream matters most for video calls, cloud backups, and uploads. A plan that delivers 80 Mbps downstream may deliver only 10 Mbps upstream, which is below the floor for a stable 1080p video call. Test the upstream separately.
Skipping the money-back window speed test. The 30 to 45 day money-back window is the cheapest opportunity to find the real working speed. Buyers who skip the test often discover the working speed is too low for the household at the renewal moment, when the refund window has closed.

Buyer checklist: matching the VPN plan to your real working speed

Measure the household's actual base connection speed (upstream and downstream) before signing up. Run the test on a wired connection if possible, because Wi-Fi variability can hide the real base speed. The VPN working speed is a fraction of this number, and the base speed is the upper bound.
Set the protocol to WireGuard on every device that supports it. WireGuard uses roughly a third of the CPU of OpenVPN, which raises the working speed by 30% to 80% with no plan change. Verify the setting in the app and on the router, because the router app sometimes defaults to OpenVPN for compatibility reasons.
Test the plan during the household's busiest hour, not during off-peak. Run a speed test at 2 PM and at 9 PM on the same server, same protocol, same device. The lower of the two readings is the realistic working speed during peak hours, which is when most households actually use the VPN.
Compare a nearby server against a distant server on the same plan. The difference between a 200 km server and a 5,000 km server is typically 30% to 80% of the throughput, plus 80 ms to 150 ms of latency. Use the closest server that meets the household's geo-location need.
Test the upstream speed separately from the downstream speed. The upstream is often tighter than the downstream, and the upstream matters most for video calls, cloud backups, and uploads. A plan that delivers 80 Mbps downstream may deliver only 10 Mbps upstream, which is below the floor for a stable 1080p video call.
Run a 10 GB download through the VPN during the money-back window. The download time is the most honest measure of working speed, because it averages throughput over a sustained period and exposes the throttling that short speed tests miss. Compare the download time with and without the VPN to quantify the throttling.
If the working speed is consistently below the household's speed floor (25 Mbps for 4K streaming, 5 to 10 Mbps for video calls, 1 to 3 Mbps for browsing), request a refund inside the money-back window and switch providers. The money-back window is the cheapest moment to discover the working speed, and a buyer who skips the test often discovers the limit at the renewal moment, when the refund window has closed.
Re-test the working speed every six months. Server load shifts, the household adds new devices, the base upstream may change, and the provider's server fleet may grow or shrink. The working speed is not a fixed property of the plan; it is a snapshot of the household's traffic, the provider's server fleet, and the time of day. Re-test before the next renewal to confirm the plan still meets the household's working speed.

Use this VPN speed throttling checklist

Affiliate disclosure: PriceGap is an independent buyer-education site. This article contains no advertiser checkout links, does not claim a current sponsor relationship with any VPN provider, and does not quote fixed live throughput numbers, server lists, protocol support, or money-back window lengths. Working speed, server load, protocol overhead, ISP shaping, and money-back window terms change frequently; verify current terms, supported protocols, refund windows, and your own household speed directly with the provider before signing up, upgrading, or switching protocols.

Related price gap guides

VPN simultaneous connections: how many devices work — the same "advertised capacity vs working capacity" pattern applied to the simultaneous connection cap and the working device count.
VPN device limit real cost: how many devices you get — the per-slot math on consumer plans, where the device count determines how many devices share the working throughput.
VPN annual vs monthly real cost — the billing-cycle math once the working speed and the plan tier are decided, including renewal differences between monthly and multi-year terms.
Hosting renewal price: why year two costs more — the same "promotional speed vs renewal speed" pattern applied to hosting bandwidth and CPU allocations, where the renewal price buys less working capacity than the first year.
SaaS overage fees: what you pay when you go over usage limits — the per-unit overage math on usage-based SaaS, where the working capacity above the plan tier follows the same line-item pattern as VPN throttling above the plan limit.