How we test
This method is published before the results exist. That order matters: a method written after the numbers can be shaped to fit them.
Why most VPN speed numbers are meaningless
A VPN speed figure without a baseline tells you about the reviewer’s internet connection, not the VPN. A 300 Mbps result sounds excellent until you learn the unencrypted line was also 300 Mbps — or terrible until you learn the line caps at 320 Mbps. Retention of the baseline is the only figure that transfers to your situation, so every result we publish reports the unencrypted line speed measured in the same session, and the percentage retained.
The second problem is run count. A single test captures one moment on one route through one server. Providers rotate load continuously, so a single run says almost nothing. We average a minimum of five runs per server per protocol and publish the run count with the figure.
Speed method
- Baseline measured immediately before each VPN run, on the same client and line
- Minimum five runs per server per protocol, averaged, with the run count published
- Wired connection only — Wi-Fi variance is larger than the differences being measured
- Same client hardware for all providers in a comparison round
- Client location and server location both published, since distance dominates the result
- Protocol stated, because WireGuard and OpenVPN are not comparable figures
A run is discarded and repeated if the baseline moves more than 10% between the start and the end of the session, because that means the line changed rather than the VPN.
Leak method
A leak test checks whether traffic that should be inside the tunnel travels outside it. Four checks run against each provider:
- DNS. Whether name resolution reaches the provider’s resolver or the ISP’s
- IPv6. Whether an IPv6 address is exposed when the tunnel carries only IPv4
- WebRTC. Whether the browser exposes the local address through peer connection candidates
- Kill switch. Whether traffic stops when the tunnel is dropped abruptly, tested by killing the process rather than clicking disconnect
The kill-switch check is the one most reviews skip, because a graceful disconnect is not the failure mode that matters. What matters is an unexpected drop, so we terminate the process.
What we will not claim
- That a provider is “fastest”. Speed depends on your line, your distance to the server and the hour. We publish retention against baseline on a stated route.
- That a provider works with a named streaming service. Blocking changes weekly and any such claim is stale before it is indexed.
- That a no-logs policy is true. Nobody outside the company can verify that. We report whether an independent firm examined it, when, and what scope.
Current status
No measurements have been published yet. Provider pages say “not yet measured” instead of printing an estimate. When the first round is complete, results appear on the lab page and in the lab section of each review, each with its test date.