How the measurements work
This page describes how VPNTest.org measures VPN services. It is published before any results, so the method can be read and questioned first.
Last updated .
What exists so far
There are no provider results on this site yet. One measurement node is running: a residential vantage in Asia. Results will appear once it has run long enough to be worth reading.
Residential and data center vantages
Every node is one of two kinds, and the difference matters more than it might sound.
A data center node sits on a hosted server with a fast, uncontended uplink. It is the only kind of vantage other comparison sites use, and it shows a VPN at its best.
A residential node sits on an ordinary domestic connection — the kind the people reading this actually use. It is slower, and it has its own bad evenings. It is also the only way to see some things at all: streaming services, banks and fraud systems treat traffic from data center address ranges differently from traffic that appears to come from a home, so a result measured in a data center can say very little about what someone at home would experience.
Neither is the real one. They answer different questions, so every figure on this site is labelled with the vantage it came from.
Numbers are never compared across vantages. A residential line has a ceiling that applies equally to every provider measured through it, so comparing providers within that vantage is fair. Comparing a residential measurement against a data center one would not be, and the site will not show a figure that mixes the two.
The nodes
Measurements come from nodes: machines running identical software, named for where they are and what kind of connection they sit on — Asia Residential, USA Data Center, and so on. The aim is several of each, so the same provider server can be measured from more than one continent and from both kinds of vantage.
Each node holds many WireGuard tunnels open continuously — one for each VPN server under test — using subscriptions bought anonymously at the retail price.
One network namespace per tunnel
Each tunnel lives in its own Linux network namespace: an isolated copy of the network stack, with its own interfaces and routes. Inside a namespace the only way out is the tunnel.
That matters because the most misleading failure in VPN testing is a check that passes over the machine's own internet connection while the VPN is actually down. Here, if a tunnel drops, traffic in its namespace has no route anywhere. It cannot quietly fall back to the host connection, so a dead tunnel shows up as a failed check — an outage, recorded as one.
What is checked, and how often
| Check | How often |
|---|---|
| Quick check (uptime, latency) | Every 5 minutes, every tunnel |
| Full check | Every 4 hours, each tunnel |
| Speed test | Once a day, each tunnel (the first full check after 23 hours without one) |
The node checks one tunnel at a time, so one test never disturbs another. Only the checks below are run; this page does not describe anything that is not running.
Every 5 minutes: uptime
A quick check that each tunnel is up and passing traffic. Every tunnel runs with a WireGuard keepalive of 25 seconds, so a check measures a tunnel that is already awake rather than one that first has to renegotiate, and its latency and jitter are not inflated by a cold start. It records whether the tunnel's last handshake is recent, the latency, jitter and packet loss of a short ping through the tunnel, and the bytes sent and received.
Every 4 hours: the full check
The full check adds the tests below to a quick check, in this order. Each one is run from inside the tunnel, so an outside service sees only the VPN server's own public address, never anything about a person. A test that fails leaves its own results empty and records why. It is never stored as zero, and it does not stop the others.
MTU
- Measures
- The largest packet that really gets through the tunnel, next to the size the tunnel is set to.
- Asks
- No outside service. It pings the same address as the quick check.
- Stored
- The tunnel's configured MTU and the largest size that got through. If the tunnel does not answer even a small ping, the second is left empty, never a small number.
- Size and limits
- About a dozen short tests of two pings each, with the do-not-fragment flag set: roughly 15 to 25 seconds per tunnel.
- Runs
- Every full check (4 hours).
Mullvad: where is this address?
- Measures
- The exit address and where Mullvad's database places it.
- Asks
- Mullvad, at
am.i.mullvad.net. - Stored
- The exit address, country, city, who owns the address, and whether it is on a blocklist (“not on one” is a reading, not a gap). Spelled as Mullvad spells them.
- Size and limits
- One small request. A network error is tried once more after 2 seconds; a refusal is not.
- Runs
- Every full check (4 hours).
ipinfo: the same question, a second opinion
- Measures
- Where ipinfo's database places the same exit address, so two sources can be compared.
- Asks
- ipinfo, at
ipinfo.io, without an account. - Stored
- Country (as a two-letter code), city, and who owns the address, with its network number. Spelled as ipinfo spells them, so “US” here and “United States” from Mullvad are the same answer.
- Size and limits
- One small request. The free plan has a limit shared by everyone using the same VPN server address; a refusal is recorded and not retried. A network error is tried once more after 2 seconds.
- Runs
- Every full check (4 hours).
Netflix: which Netflix server answers
- Measures
- Which Netflix machine answers a request made through the tunnel. Its name carries a site code, so it hints at where Netflix thinks the tunnel comes out.
- Asks
- Netflix, at
www.netflix.com. - Stored
- Netflix's own “via” header, exactly as sent. Nothing about whether a show would play: that goes out of date within weeks.
- Size and limits
- One request for the front page, which is thrown away; only the header is kept.
- Runs
- Every full check (4 hours).
Cloudflare: which Cloudflare site answers
- Measures
- Which Cloudflare data center answers a request made through the tunnel.
- Asks
- Cloudflare, at
1.1.1.1/cdn-cgi/trace. It uses an address, not a name, so a slow name lookup inside a tunnel cannot slow it. - Stored
- The data center's airport-style code (for example LAX). The address and country in the same reply are not kept.
- Size and limits
- One tiny request. A network error is tried once more after 2 seconds.
- Runs
- Every full check (4 hours).
Baseline: the node's own line
- Measures
- What the node's own internet line can do, outside every tunnel, using the same two transfers as the speed test and a ping. It is taken just before a tunnel's speed test, so the tunnel's result can be read beside what the line could do at that moment.
- Asks
- Cloudflare's speed-test server,
speed.cloudflare.com. - Stored
- Download speed, upload speed and latency of the line.
- Size and limits
- The same as the speed test below: 50 MB down and 15 MB up, one connection each way.
- Runs
- Together with each tunnel's speed test, once a day.
Speed test
- Measures
- How fast data moves through the tunnel, down and up.
- Asks
- Cloudflare's speed-test server,
speed.cloudflare.com. Cloudflare answers from a site near where the request comes from, so a tunnel is measured against a server near its exit. - Stored
- Download speed and upload speed in megabits per second, and how many seconds each transfer ran. If the tunnel did not answer its pings the test is skipped and says so.
- Size and limits
- One connection each way. The download is 50 MB (52,428,800 bytes) and the upload is 15 MB (15,728,640 bytes). Each is timed from the first byte received, or from the end of the handshake for the upload. A transfer is cut off 20 seconds after it starts, and the speed is worked out from what arrived. Each command is stopped after 60 seconds whatever it is doing. The server's address is looked up first, on its own, so a slow name lookup is never counted as a slow tunnel.
- Runs
- Once a day per tunnel.
What a speed test does and does not show
Each speed test moves a fixed amount of data once. Over a long distance a single transfer of that size cannot fill the line, so it reports less than the line can do. The numbers are good for comparing tunnels tested the same way. They are not a top speed, and you should not compare them with a speed test run in your browser.
Known limits
- The Netflix header is a weak location signal. Netflix may answer a Los Angeles tunnel from Newark. A disagreement with the other sources is a reading, not a fault.
- The location sources are kept as each one wrote them, and they are expected to disagree. Each has its own database, spelling and idea of a city. We store every answer and do not pick a winner.
- A slow name lookup inside a tunnel is not counted as slow speed. The speed test looks the server up first and times only the transfer.
- A failed test is stored as empty, with the reason, never as zero. Zero would look like a measurement.
- One speed reading a day is noisy. The hourly and daily summaries are what smooth it; the raw readings are kept.
- A shared server address can be refused. The free plans of the location services limit requests per address, and other customers of the same VPN server share that address. A refusal is recorded with its reason.
The node's own load, on every row
Every result also records how busy the node itself was at the moment of the test. A slow result could mean a slow VPN, or a strained measuring machine. Publishing the node's load beside every number lets anyone check which it was, instead of taking our word for it.
Bad readings are kept
A failed check, a timeout or a terrible speed is stored exactly as measured. Nothing is smoothed over or quietly dropped: an outage is data.
How results reach the site
Each node stores its results locally first, then sends them to the site in batches. Nodes never accept incoming connections, and a batch that fails to send is kept and sent again, so a network hiccup does not lose measurements. Charts will be drawn from hourly and daily summaries of the raw results, and the raw results themselves will be published too.
What is not measured
Company information: where a provider is incorporated, who owns it, what its privacy policy says. See the principles for why.