What We Measure Ourselves
One machine, one connection, the same battery of tests through one provider after another, on a schedule. No vendor feed, no press release, and nobody's opinion - including ours.
Measured Performance
Median across cycles. A provider appears after 10 complete cycles, because one cycle of this battery repeats within about ten per cent - wider than the gap between two good providers.
| Provider | Asked for | Cycles | Through the tunnel | Share of our line lost | Latency | Connect | Carries IPv6 |
|---|---|---|---|---|---|---|---|
| Mullvad | NL | 197 | 593.9 Mbps | 72.2% | 90.4 ms | 8 s | not tested |
| ProtonVPN (free servers) | NL | 219 | 581.6 Mbps | 74.5% | 91.6 ms | 13 s | not tested |
⚖️ Side by side, with the exit networks and DNS: ProtonVPN vs Mullvad.
Read the first speed column, not the second. Our line runs at about 2,228 Mbps from Kamatera, Toronto to a test server nearby, and the tunnel runs go much further, to the provider’s servers. So the percentage is the share we lost on this line and this route - not what you would lose on yours. What does carry over is the first column, read across the rows: every provider is measured the same way on the same line, minutes apart. It is one connection over one route from our server, so it ranks the providers against each other - it is not the most any of them can deliver.
“Not tested” means exactly that. The machine the stand runs on has no IPv6 connection of its own, so we cannot tell a provider that carries IPv6 inside the tunnel from one that blocks it. An IPv6 leak is something the stand can never measure: its firewall drops anything outside the tunnel by design. Whether IPv6 leaks on your own connection is what the leak test checks.
What Changed in the Last 30 Days
Each week below is the median of that week's runs. A change is a week that moved at least 10% against the one before, and by a real amount, not one tick of the instrument; an exit network that is new after the first week or has not been seen for 7 days; or the share of exits flagged as a proxy moving 25 points.
The bars are single days, drawn from zero. They wobble by several per cent on a line that has not changed at all, which is why a day is never called a change here.
Mullvad
- 2026-09-14 - Exit network Mullvad VPN AB (AS43357) last seen on 2026-09-14, not in the 44 days since.
- 2026-10-08 - Time to connect moved from 8 s to 13 s (+62%) against the week before.
- 2026-10-15 - Time to connect moved from 13 s to 7.5 s (-42%) against the week before.
Download through the tunnel, median per day, 2026-09-29 to 2026-10-28, from the speed series that began on 2026-10-05.
| Week | Runs | Download | Latency | Connect | Flagged as proxy |
|---|---|---|---|---|---|
| 10-01 - 10-07 | 28 | 589 Mbps | 91 ms | 8 s | 79% |
| 10-08 - 10-14 | 22 | 589 Mbps | 91 ms | 13 s | 77% |
| 10-15 - 10-21 | 28 | 601 Mbps | 90 ms | 8 s | 89% |
| 10-22 - 10-28 | 25 | 592 Mbps | 91 ms | 8 s | 84% |
ProtonVPN
Nothing moved beyond the lab's noise in the last 30 days.
Download through the tunnel, median per day, 2026-09-29 to 2026-10-28, from the speed series that began on 2026-10-05.
| Week | Runs | Download | Latency | Connect | Flagged as proxy |
|---|---|---|---|---|---|
| 10-01 - 10-07 | 28 | 770 Mbps | 92 ms | 13 s | 100% |
| 10-08 - 10-14 | 28 | 577 Mbps | 92 ms | 13 s | 100% |
| 10-15 - 10-21 | 28 | 587 Mbps | 92 ms | 13 s | 100% |
| 10-22 - 10-28 | 25 | 573 Mbps | 92 ms | 13 s | 100% |
How These Numbers Are Made
- One machine, one line. Every provider is measured from the same host in Kamatera, Toronto, so what differs between two rows is the provider and not the tester.
- A baseline every cycle. The battery runs with no tunnel first, then through each provider minutes later. Overhead is always against that run, never against yesterday's.
- Best of three transfers. A single transfer measures one second of a network's life: two consecutive runs on an idle line disagreed by 38% while this was being built. Throughput is capped by capacity and only dragged down by congestion, so the best sample is the closest to what the link can do.
- DNS is measured, not inferred. The probe resolves names in a zone our own nameserver is authoritative for, so the resolvers that answer are observed arriving rather than guessed from who owns the exit address.
- A failed connection writes nothing. A tunnel that never came up says nothing about that provider's speed, and a zero would say something false.
- Our own firewall is tested too. We forced the tunnel down mid-run 143 times and watched for traffic leaving outside it: none did. We also timed how long each provider took to come back, and then withdrew that figure - a controlled drop showed about 52 of the 58 seconds were our client waiting for its next health check, not the provider's network. A number that describes our tools does not belong in a column about theirs.
- Our instrument's limits are part of the record. For its first month the stand's own TCP settings capped every speed through the tunnel at about 275 Mbps: one connection carries at most one receive window per round trip, and the default window over the 91 ms from Toronto through the Netherlands comes to about that. Both providers' best runs stopped there. We found it on 5 October 2026 while writing up the first comparison, raised the setting, and now record it with every run; speeds taken under different settings are never put in one median.
Last cycle aggregated 5 hours ago.
This Is Not the Same Data as the Results Database
/vpn-results/ aggregates tests visitors chose to share: many machines, many countries, many connections - and a sample that skews toward people who already suspected something was wrong. This page is one machine running a fixed battery on a timer.
Both are honest and they answer different questions. Visitor data says what happens in the wild; the lab says what happens under identical conditions. We keep them in separate stores and publish them as separate figures, because an average of the two would answer neither question and read as though it answered both.
🧰 Measure Your Own Connection
The tests run in your browser. Where one needs to know whose network an address is on, our server looks it up and keeps no address. Nothing is stored unless you choose to share the result.
📚 Read next
The longer version: what this test is looking for, and what to do with the answer.
The Measurement Lab - FAQ
What the stand does, what it cannot do, and why the numbers are kept apart from the ones visitors send.
Where does the lab run?
On a virtual server we rent in Kamatera, Toronto, in a datacentre - not on a home connection. That matters when reading the absolute speeds: they describe our line and our route to the provider’s servers, and yours can come out lower or higher - a slower line reads lower, and a fast one closer to the server can read higher. They still compare providers fairly, because every one is measured on the same line minutes apart, which is why the table leads with the speed through the tunnel. The percentage lost is a share of our line, not what you would lose at home.
Why so few providers?
Each one needs a subscription and a slot in the schedule, and a provider is not published until it has enough cycles behind it. ProtonVPN is measured on its free servers - marked as such in the table - and the others on paid plans. We would rather show two providers with real medians than twenty with a number each taken from one afternoon.
Can a provider pay to look better here?
No, and there is nothing to sell. The stand does not know which provider it is measuring beyond the credentials it was handed, the battery is identical for all of them, and the thresholds were set before the first result existed. If we ever take money from a provider, it will be disclosed on the page in question and it will not touch these numbers.
Why is a provider missing a figure?
Because that particular reading failed and we store nothing when it does. A missing overhead means the cycle had no baseline with a completed download to compare against, or the run through the tunnel did not complete its own; a missing speed means the transfer did not complete. Both are shown as a dash rather than filled in with a zero, which would quietly drag an average down.
Does the lab test the same things as the browser tests?
The overlapping parts use the same methods on purpose - the same speed endpoints, the same DNS measurement against our own nameserver, the same ASN mapping for attributing an exit. What the browser can do that the stand cannot is test the machine you are actually using, which is why the tools exist and why this page ends with a link to them.