VPN speed test lies: how 'fastest' marketing works

The "fastest VPN" marketing claims are nearly universal in this industry. They are also nearly always misleading. The mechanics of how the marketing works, why the claims do not match what users see, and what an honest comparison looks like.

This is the version that calls out specific tricks. We sell a VPN. We benefit if users distrust competitors' speed claims. We are biased; the bias is disclosed; the technical observations are independently verifiable.

The basic dishonesty

Most "fastest VPN" claims rely on cherry-picked data from controlled test environments. The pattern:

Test 500-1000 servers across the provider's fleet
Note which servers achieved the highest speeds in the test
Publish "Up to 950 Mbps!" headlines
Decline to publish the median or average across the fleet, the test methodology, or the conditions

The cherry-picked top result is real arithmetic — the test happened, the speed was measured. It is also unrepresentative of typical user experience because most users do not connect to the cherry-picked server under cherry-picked conditions.

A median or average across the fleet would be more honest. Few providers publish this. The ones who do are usually the smaller providers with less to hide.

The specific tricks

Worth understanding because they appear repeatedly:

1. Testing on 10Gbps connections. VPN benchmarks often run on enterprise-grade test connections. Real users have 100Mbps or 1Gbps residential connections. The "VPN can sustain 950 Mbps!" headline assumes a 1Gbps source connection that most users do not have.

2. Cherry-picking test servers. Provider has 5,000 servers. Provider tests all 5,000. Provider publishes the top result. "Our network achieved 950 Mbps!" is technically true and operationally misleading.

3. Not disclosing protocol. WireGuard is faster than OpenVPN by a meaningful margin. A test on WireGuard ranges from "Up to X" with no mention that the default might be OpenVPN, where speeds are 30% lower.

4. Testing at off-peak times. 3am Tuesday in your local timezone has different network conditions than 8pm Saturday. Off-peak testing produces better numbers; marketing publishes the better numbers.

5. Testing from the same datacenter as the VPN server. If the VPN server is in AWS US-East-1 and the test client is also in AWS US-East-1, latency is extremely low and throughput is ideal. Real users live further from datacenters.

6. Speedtest.net partnerships. Some VPN providers have partnerships with Ookla (Speedtest.net) that provide them with test infrastructure. The speedtest.net result becomes the marketing number; it does not generalise.

7. Single-thread vs multi-thread testing. TCP-based protocols hit single-thread bottlenecks; multi-thread testing produces higher numbers. Marketing typically uses multi-thread; real-world streaming and file-transfer is often single-thread.

8. Comparing to "no VPN" rather than "to other VPNs". The honest comparison is "fastest among VPNs that maintain X privacy guarantees." The marketing comparison is often vs the no-VPN baseline, which is unhelpful because everyone slows down when adding VPN; the question is which adds least.

What actually determines VPN speed

The factors, in rough order of impact:

1. Distance to the VPN server. Connecting from London to a London VPN server adds ~5-10ms latency and minimal throughput overhead. Connecting from London to a Tokyo VPN server adds ~250ms latency and substantial throughput overhead due to TCP window limitations on long paths.

2. Protocol choice. WireGuard adds ~5-10% throughput overhead. OpenVPN adds ~15-25%. VLESS Reality is in the middle (~10-15%). The protocol matters significantly more than the VPN provider.

3. Server load. A server serving 50 users at 100Mbps each is different from a server serving 10 users at 100Mbps each. Load varies by time of day and by server location.

4. ISP routing to the VPN. Your ISP's peering to the VPN provider's network. Some ISPs route well to specific VPN providers; some route badly. Different ISPs see different speed profiles for the same VPN.

5. Encryption CPU overhead. AES-NI acceleration on modern CPUs makes encryption nearly free. Older or low-power devices have meaningful CPU overhead from encryption.

6. MTU and fragmentation. Misconfigured MTU causes packet fragmentation, which kills throughput. Most modern clients handle this well; misconfiguration produces 70%+ throughput losses on otherwise-fast connections.

7. The VPN provider's actual infrastructure. Server hardware, network interface speeds, peering arrangements, datacentre quality.

For most users, factors 1, 2, and 3 dominate. Server distance + protocol choice + load determine 80% of the experienced speed. The provider's overall infrastructure quality matters but at the margins.

How to test honestly yourself

The protocol that produces meaningful comparisons:

1. Same test target. Use Cloudflare's speed test (speed.cloudflare.com) or the same Speedtest.net server for direct and VPN tests. Cross-test variation is reduced when the destination is identical.

2. Same time of day. Network conditions vary; test at the same time on both runs.

3. Same protocol. Test WireGuard direct vs WireGuard through VPN, or compare protocol choices explicitly.

4. Multiple runs. Single test results are noisy. Run 3-5 tests and use the median.

5. Same network. Same Wi-Fi or wired connection; do not test on different connections.

6. Document conditions. What time, what network, what protocol, what server. Document so you can compare future tests.

The result is a meaningful number. "Direct connection: 450 Mbps median. Fexyn Bolt to Frankfurt: 410 Mbps median (-9%). Fexyn Stealth to Cyprus: 360 Mbps median (-20%)." That tells you what protocol overhead actually costs on your specific setup.

Fexyn's actual benchmarks

Honesty disclosure. Tests run from a 1 Gbps fibre connection in Berlin, Germany (relevant for European users; less relevant for users elsewhere).

Test	Direct	Fexyn Bolt (WireGuard)	Fexyn Stealth (Reality+Vision)
Frankfurt server (~600km)	940 Mbps	891 Mbps (-5.4%)	824 Mbps (-12.5%)
Helsinki server (~1100km)	940 Mbps	845 Mbps (-10.1%)	760 Mbps (-19.1%)
Cyprus server (~2700km)	940 Mbps	720 Mbps (-23.4%)	610 Mbps (-35.1%)
Ashburn server (~6300km)	940 Mbps	480 Mbps (-49.0%)	380 Mbps (-59.6%)

The pattern: same protocol across distances; throughput degrades with distance because of TCP window limits and added latency, not because the protocol is "slower."

This is one specific test environment. Different ISPs, different starting bandwidth, different times of day produce different numbers. We are not claiming 891 Mbps universally; we are claiming this is what we measured under these conditions, and the methodology is reproducible.

The "fastest VPN" claim is structurally dishonest

Even if a provider were genuinely the fastest in some specific test, "fastest VPN" as a generic marketing claim does not hold up because:

Speed depends heavily on distance to server (provider with US servers is faster for US users; provider with EU servers is faster for EU users)
Speed depends on protocol (default protocol varies; same provider has different speed depending on which protocol the user runs)
Speed depends on load (server with 50 users is slower than the same server with 5 users)
Speed varies day-to-day with network conditions

A provider that publishes "fastest VPN" without methodology is selling a feeling, not a measurement. The honest providers acknowledge that "fastest" is situational.

What to actually look for

If speed matters to your VPN choice:

Server proximity to your location. A provider with servers near you wins; a provider with servers across the planet does not.
Protocol support. WireGuard support is table stakes in 2026.
Reasonable per-server load. A provider that publishes server load (Mullvad does) is more honest than one that does not.
Test it yourself. 30-day refund windows (or our 7-day free trial) let you test under real conditions before committing.

Frequently asked

Is NordVPN actually faster than ExpressVPN?

Maybe, maybe not. Both publish marketing claims that are individually true under cherry-picked conditions. For most user setups, the difference is small. Test on your specific connection.

Why does my VPN slow my internet?

VPN adds protocol overhead (5-25% depending on protocol) plus distance overhead (varies by server choice) plus encryption overhead (minimal on modern hardware). Total is typically 5-15% on a nearby server with WireGuard, more for distant servers or older protocols.

Should I expect my VPN to be slower than my home internet?

Yes, slightly. Expecting equal speed is unrealistic. Expecting catastrophic slowdown (50%+ on a nearby server with modern protocol) suggests something is wrong; investigate.

Will WireGuard always be faster than OpenVPN?

In 2026, yes for nearly every realistic test. WireGuard's lower per-packet overhead and simpler protocol math make it faster across most conditions. OpenVPN's strengths are configurability and TCP support for firewall bypass; speed is not its strength.

Is the "fastest VPN" claim ever honest?

Rarely. Most are marketing copy assembled from cherry-picked test data. A few smaller providers publish their methodology and acknowledge limits; those claims are more credible.

How can I tell if a VPN provider is honest about speed?

They publish methodology. They show median or average results, not just peak. They acknowledge that speed varies by protocol, distance, and time. They do not claim to be "fastest" without conditions. They run on hardware they describe rather than vague "5,000 servers" marketing.

Try Fexyn free for 7 days — we publish our actual benchmark numbers above, with full methodology. Does VPN slow internet covers protocol overhead in detail; How to choose a VPN covers the broader honest buying framework.

Last reviewed 2026-05-09.