Every VPN company publishes a speed claim and every one of them is technically true under some set of conditions. We wanted to know which conditions, so this cycle we automated the whole thing: 4,218 iperf3 runs across 312 servers, repeated at four times of day, on three protocols.
The headline finding is that the protocol argument people have online is mostly noise. Between WireGuard and a well-configured OpenVPN UDP tunnel we measured an 11% average gap on nearby servers. Between a lightly-loaded server and a busy one on the same provider, in the same city, we measured a 61% gap.
The test rig
Everything runs from a 1 Gbps symmetric fibre line in Frankfurt. The control machine is a Ryzen 7 mini PC running Debian 13 with nothing else on it. We never test over Wi-Fi for the desktop numbers, because Wi-Fi variance is larger than most of the differences we are trying to measure.
Our unprotected baseline this cycle averaged 942 Mbps down. Every percentage in our reviews is relative to that number, re-measured before and after each provider block so we can throw out any run where the line itself drifted more than 2%.
- Three distance bands: nearby (under 500 km), mid-range (1,000–3,000 km), long-haul (over 8,000 km)
- Four test windows per day, including a deliberately chosen peak-congestion slot at 21:00 CET
- Minimum five runs per server, median reported, outliers beyond 2σ discarded
- Mobile figures measured separately on a Pixel 9 over 5G, averaged across 20 runs
What actually costs you speed
Ranked by the size of the effect we measured, largest first:
- Server load — 61% swing. The single biggest factor by a wide margin, and the one providers hide behind an unhelpful green dot in the app.
- Physical distance — 34% swing between a nearby and a long-haul hop, even on the fastest provider.
- Time of day — 22% swing between 04:00 and 21:00 on the same server. Consumer VPN networks are contended, same as any ISP.
- Protocol — 11% between WireGuard and OpenVPN UDP. Real, but smaller than the arguments suggest.
- Encryption cipher — under 3%. On any CPU made in the last decade this is a rounding error. Stop worrying about it.
If a provider will not show you real-time server load as a number, assume the reason is that the number is bad.
The long-haul test is the one that separates providers
Nearby speeds cluster. Eight of the ten VPNs in our current top ten held above 75% of baseline on a short hop, which makes that test almost useless for ranking. Push the connection from Frankfurt to Sydney and the field spreads out immediately: our top pick held 712 Mbps, the slowest of the ten managed 497 Mbps on the same route at the same hour.
That gap is about routing and peering, not cryptography. Providers who pay for premium transit and run their own backbone segments keep the speed; providers who rent whatever is cheapest in each datacentre do not.
What we would change about how everyone tests
Single-run speed tests published as a headline number are close to meaningless. So is any test that does not name the server, the hour, and the baseline. We publish all three for every figure in our reviews, and our raw CSV exports are available on request — several readers have re-run our numbers and told us where we were wrong, which is the point.
