VPN leak tests
Six measurements, run against named clients on named platforms, with the date and the client version recorded next to every result. The method is below. The results table is empty, because the runs have not happened yet, and an empty cell is more honest than a number nobody measured.
What gets tested
Each check answers one question and is worth a fixed number of points out of 100. Points are not opinions about a provider: they are the weight of the exposure the check finds.
IPv4 egress
25 pts- Measures
- Whether the address a server sees over IPv4 belongs to the provider rather than to the subscriber line.
- How it is run
- Load /json with the client connected. Compare the address and the autonomous system with the same reading taken before the tunnel came up.
- Counts as a leak when
- The ASN still belongs to the access network, or the address is unchanged.
IPv6 egress
20 pts- Measures
- Whether IPv6 leaves through the tunnel, is blocked outright, or escapes to the native connection while IPv4 is tunnelled.
- How it is run
- Request v4.whatsmyip.fyi/json and v6.whatsmyip.fyi/json on a dual-stack line. Compare the two autonomous systems.
- Counts as a leak when
- IPv6 answers on the access network ASN while IPv4 answers on the provider ASN. Blocking IPv6 outright is a pass.
WebRTC candidates
20 pts- Measures
- Whether the browser hands a page a public address that the tunnel was supposed to hide.
- How it is run
- Gather ICE candidates against two STUN servers for five seconds in Chrome, Firefox and Safari. Compare every server-reflexive candidate with the tunnel address.
- Counts as a leak when
- A candidate carries a public address that is not the tunnel exit.
DNS resolvers
20 pts- Measures
- Which resolvers actually answer while the tunnel is up.
- How it is run
- Run the /dns-leak-test session, which issues six single-use names under our own authoritative zone and records the address of every resolver that asks for them.
- Counts as a leak when
- A resolver on the access network answers, or on any network the provider does not operate or name.
Kill switch
10 pts- Measures
- What reaches the network in the seconds between the tunnel dropping and the client noticing.
- How it is run
- Drop the tunnel at the interface while a one-request-per-second poll of /json is running. Count the requests that answer with the subscriber address before traffic stops.
- Counts as a leak when
- Any request answers with the subscriber address, or traffic continues after the tunnel is gone.
Protocols offered
5 pts- Measures
- Which transport the client negotiates by default, and what it falls back to.
- How it is run
- Read the client log and the interface configuration on a fresh install with default settings.
- Counts as a leak when
- The default is a protocol with no current public audit, or the fallback is weaker than the default without saying so.
The six checks add up to 100 points. Each run is repeated on 5 platforms (Windows 11, macOS 26, Ubuntu 26.04, Android 16, iOS 26) and, for the browser checks, in Chrome, Firefox, Safari. A provider scores the worst result it produced, not the average, because a leak on one platform is a leak.
Scoring rubric
| Score | Band | What it means |
|---|---|---|
| 90–100 | No leak found | Every measured path stayed inside the tunnel on every platform we ran, with the client as it ships. |
| 70–89 | Leaks only when configured badly | The defaults hold, but at least one setting a person might reasonably change opens a path outside the tunnel. |
| 40–69 | Leaks on at least one platform | A measured path escaped the tunnel with the client as it ships, on at least one of the platforms tested. |
| 0–39 | Leaks by default | A measured path escaped the tunnel with the client as it ships, on every platform tested. |
A run that cannot complete is recorded as incomplete, never as a pass. If the DNS check receives nothing at all, that is "no resolver reached our server", which is a broken measurement and not a clean result.
Results
| Provider | Jurisdiction | Tested on | Client | IPv4 egress | IPv6 egress | WebRTC candidates | DNS resolvers | Kill switch | Protocols offered | Score |
|---|---|---|---|---|---|---|---|---|---|---|
| ExpressVPN | British Virgin Islands | — | — | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested |
| NordVPN | Panama | — | — | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested |
| Surfshark | Netherlands | — | — | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested |
| Proton VPN | Switzerland | — | — | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested |
| Mullvad | Sweden | — | — | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested |
| IVPN | Gibraltar | — | — | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested | not yet tested |
- ExpressVPNNot yet tested.
- NordVPNNot yet tested.
- SurfsharkNot yet tested.
- Proton VPNNot yet tested.
- MullvadNot yet tested. Runs no affiliate programme, so it can never earn this site anything.
- IVPNNot yet tested. Runs no affiliate programme, so it can never earn this site anything.
How we test
Every check on this page is a tool on this site, run by hand against a real client on a real connection. There is no laboratory and no automation that pretends to be one, because no stub can route real packets: a test harness that mocks the tunnel proves the wiring and nothing about the tunnel.
The run starts with a reading taken before the client connects, so there is something to compare against. The physical line is recorded with /json: address, autonomous system, ISP and connection type. Then the client connects in the same browser tab and /vpn-check is reloaded. That page combines the address reading, the WebRTC candidates, the DNS resolver session, the IPv6 egress comparison and the reputation flags into one verdict, and it is the page the score is read from.
Each leak is then forced on purpose, one at a time, so a passing row means something. IPv6 leak protection is switched off on a dual-stack line. The system resolver is forced back to the ISP. The browser is excluded from the tunnel through split tunnelling. Each of those must break exactly one row and no others. A check that stays green while its path is deliberately broken is a broken check, and it is fixed before any provider is scored with it.
Two cases are documented as caveats rather than faults. Browser secure DNS moves lookups to the browser's own resolver and hides what the client is doing, so it is tested separately and never counted as a leak: it changes who sees your lookups, not who sees your address. iCloud Private Relay can leave the resolver list empty, and an empty list is reported as untested, never as clean.
The full procedure, including the failure states we confirm on purpose and the table each run is recorded in, lives in docs/VPN-CHECK-TESTING.md in the repository. It is written so that someone with a different client and a different line can repeat it and get a comparable answer.
Questions people ask
- Why are there no scores yet?
- Because we have not run the tests yet. Publishing a table of numbers before the runs happen would be inventing them. The method is published first so it can be read and argued with before any result exists, and so a later result cannot be quietly fitted to a conclusion.
- Do the affiliate links change the results?
- They cannot, because there are no results yet. When there are, the table will carry the same numbers whether a provider pays a commission or not, and two providers in the table run no affiliate programme at all so they can never earn this site anything. The affiliate call to action renders only next to a provider with a published test run.
- Can I run these tests myself?
- Yes, and that is the point. Every check is a page on this site that you can open with your own client connected. The procedure, including the deliberate failure cases, is written up in the repository as VPN-CHECK-TESTING.md. Nothing here needs our hardware.
- Why is blocking IPv6 a pass?
- Because a client that refuses to carry IPv6 and blocks it at the interface leaks nothing. It is a worse product than one that tunnels IPv6 properly, but it is not a leak. What fails is the third option: tunnelling IPv4 while letting IPv6 out on the native connection, which quietly exposes the subscriber on every dual-stack site.
Affiliate disclosure
Four of the six providers listed above run affiliate programmes that this site is eligible to join, and two do not. If a commercial link ever appears on this page it will be marked, it will carry the rel attributesponsored nofollow noopener, and it will sit below the results rather than above them.
No link appears today, because no provider on this page has a published test run and the call to action is wired to render only for a provider that does. A commission never changes a measured result, and a provider that leaks will be published as leaking whether or not it pays. The full terms are on thedisclosure page.
Last reviewed 2026-09-05.