0 measured · 4 pending
The lab
Has KotoVPN measured VPN speeds itself?
Not yet. No speed or leak result on this site was taken by us, and none of the rubric scores depend on one. The test method is published in advance at /how-we-test/ so it cannot be adjusted to fit results afterwards, and provider pages say "not yet measured" rather than printing an estimate.
Everything on this page is a measurement someone actually took, with the date, the client location, the baseline line speed and the number of runs. Nothing here is estimated, interpolated or taken from a provider’s marketing page.
Status
No measurements published yet
The scoring rubric currently runs on documented facts alone — audits, jurisdiction, protocols, published terms. Speed and leak results are not in it, because we have not run them, and adding a number nobody measured would defeat the point of the site.
The method is already published, in full, at how we test. It was written before the results exist so it cannot be adjusted to fit them afterwards.
Queue
Providers awaiting a first measurement. Their review pages state this rather than filling the gap with a figure.
Why an empty lab is on the site at all
Most VPN sites publish speed tables from day one. Very few publish the client hardware, the baseline or the run count, which is what would let a reader check the numbers. We would rather show an empty table with a published method than a full table with an unpublished one. When the results arrive they will be checkable against the method above, including by people who want to prove us wrong. In the meantime, the measurements other laboratories have published are collected on the independent tests page, with the funding behind each one disclosed.
What a VPN speed number can and cannot tell you
A single throughput figure is the least transferable measurement in this category, and it is the one every review leads with. The number depends on the tester’s line speed, their distance to the exit server, the time of day, the protocol, the client CPU, and how loaded that particular server was in that particular minute. Change any one of those and the figure moves by more than the gap most reviews use to rank providers.
This is why our method fixes the variables it can and publishes the rest. A result of “412 Mbps” means nothing. A result of “412 Mbps on a 500 Mbps line, WireGuard, London client to Amsterdam exit, median of five runs at 20:00 UTC” is something you can compare against your own connection and against the same test run on a different provider.
Even then, the honest reading is narrow. It tells you the protocol implementation is not leaving throughput on the table on that route at that hour. It does not tell you what you will get on your line, in your city, on the server you actually connect to. Anyone presenting a speed table as a ranking of providers is overstating what the test supports.
What leak testing actually checks
A leak test is worth more than a speed test and gets a fraction of the attention, because it produces a pass or fail rather than a number to put in a table. The checks that matter: whether DNS queries resolve inside the tunnel or fall back to the local resolver, whether WebRTC exposes the real address to a page that asks for it, whether IPv6 traffic escapes when the provider only tunnels IPv4, and whether the kill switch actually holds when the tunnel drops rather than reconnecting quietly with traffic flowing in the gap.
That last one is the failure people notice least and should care about most. A kill switch that fails open during a reconnect can expose traffic for several seconds, repeatedly, on an unstable connection — and nothing in the interface tells you it happened. It is testable by forcing the drop rather than waiting for one, which is what the method above describes.
How to read our results when they land
Every record will carry the date, the client location, the exit location, the protocol, the baseline line speed and the number of runs. If a figure appears here without all six, that is a defect and we would rather you reported it than assumed there was a reason. Results will not be back-filled: a test not run is a blank, permanently, until it is run.