How to test a VPN
Updated 21 September 2026 · How we research
You do not need specialist tools to check whether a VPN is doing its job. These checks take about fifteen minutes, and repeating them after any settings change is the single most useful habit in this area.
Record a baseline first
Before connecting, note your real IP address, your ISP's name, your DNS resolvers and an unloaded speed measurement. Without a baseline you cannot tell whether anything changed.
1. Address and DNS
- Connect to a server in a different country.
- Check your public IP address. It must be the VPN's, not yours.
- Run a DNS leak test. Every resolver listed should belong to the VPN.
- Check for an IPv6 address. Either none should appear, or it should be the VPN's.
- Run a WebRTC check in each browser you use; results differ between them.
2. Kill switch
- Start a continuous ping to a public address so you can see traffic flowing.
- Kill the VPN client process from the task manager rather than disconnecting cleanly.
- The ping must fail immediately. If replies continue, the kill switch is not protecting you.
- Repeat by disabling the network adapter, and again after sleep and wake.
3. Protocol comparison
- Pick one server and keep it fixed.
- Measure with WireGuard, then OpenVPN UDP, then OpenVPN TCP.
- Run each measurement three times and keep the median, because single runs are noisy.
- Repeat at a busy time of day. Congestion changes the ranking more than the protocol does.
4. Reconnection behaviour
- Switch from Wi-Fi to cellular on a phone and watch whether the tunnel survives.
- Change server inside the app and look for a gap in protection during handover.
- Reboot with autostart enabled and check whether anything escapes before the tunnel is up.
Recording results honestly
This is the standard we hold ourselves to. Where we have not run a test, we say so rather than publishing a number.
| Record | Why it matters |
|---|---|
| Date and time | Network conditions change; an undated result is not a result |
| Server location and protocol | Without these the number cannot be reproduced |
| Your baseline | A speed figure without a control tells you nothing |
| Number of runs and the median | Single measurements are dominated by noise |
| What you did not test | The most honest part of any test record |
Why you will not find speed charts on this site
Reproducible throughput testing needs controlled conditions, repeated runs and a documented setup. We have not carried out that programme, so we publish no speed figures, scores or rankings derived from them. The methods above let you measure your own connection, which is more useful than someone else's numbers from a different continent.
Independent tools for each check
None of these are ours and none are affiliate links. They are the public tools the checks above are usually run with, so you can reproduce any result on this page yourself rather than taking it on trust.
Independent testing tools, grouped by what they answer.
| What you are checking | Tool | What it tells you |
|---|---|---|
| DNS leak | dnsleaktest.com | Which resolvers answered your queries. Run the extended test: the standard test can miss a resolver that only appears under load. |
| DNS resolver detail | BrowserLeaks DNS | The resolver's owner and location, which is what tells you whether it belongs to the VPN or to your ISP. |
| WebRTC leak | BrowserLeaks WebRTC | Whether the browser exposes a local or public address through WebRTC. Repeat in every browser you use - results differ between them. |
| Public IP and geolocation | BrowserLeaks IP | The address sites actually see, with the IPv4 and IPv6 answers separated. |
| IPv6 and torrent address | ipleak.net | Both stacks on one page, plus a torrent address check that reports the IP your BitTorrent client announces - not the one your browser uses. |
| Throughput and latency | Speedtest by Ookla | Download, upload and ping against a server you pick, so the route is known. Take the median of several runs. |
| Streaming-oriented throughput | Fast.com | A Netflix-run test that reports loaded as well as unloaded latency, which is the number that predicts buffering. |
| What the protocol should do | WireGuard | The protocol's own specification and papers, for checking a vendor's claims against the design rather than against marketing. |
| OpenVPN behaviour | OpenVPN | Official documentation for the UDP and TCP transports, including the reconnection behaviour that matters for a kill switch. |
| Verifying the tunnel yourself | Wireshark | Packet capture, for confirming that traffic really leaves on the tunnel interface and that nothing is bypassing it. |
Frequently asked questions
How do I know if my VPN is actually working?
Check three things, not one. Your public address should have changed; every DNS resolver reported should belong to the VPN rather than your ISP; and no IPv6 address from your own connection should be visible. A changed IP alone is the weakest of the three, because DNS and IPv6 leak independently of it and are the two that quietly undo the rest.
How do I test a kill switch?
Start a continuous ping to an address you control, then end the VPN client process from the task manager rather than disconnecting through the interface. The ping should fail immediately. Disconnecting cleanly tests the happy path, which is not the case a kill switch exists for; killing the process is what reproduces a crash.
Why do my speed results vary so much?
Server load, time of day, routing and your own local network all change between runs, and any one of them can move a result more than the VPN does. Fix the server, take at least three measurements, use the median rather than the best, and repeat once at a busy hour. A single reading describes a moment, not a connection.
How often should I re-test?
After anything that changes the path: a client update, an operating system update, a new server or a new network. Leaks cluster around reconnects and configuration changes rather than appearing spontaneously, so the useful moment to test is right after something moved.
What should I test that most guides skip?
The transition. Most checks are run while the tunnel sits idle and connected, which is the state least likely to fail. Force a reconnect, put the machine to sleep and wake it, switch between Wi-Fi and mobile data, and watch what happens in those few seconds - that is where leaks actually occur.