Seven checks that prove your VPN is working

The client says connected. That means a handshake completed at some point. It does not mean traffic is entering the tunnel, that name resolution changed, or that anything will be blocked when the tunnel drops. These seven checks take about five minutes and cover the gap.

Check one: the exit address

Open what is my IP. The address shown should be the server's, and the country should be the one you chose.

If it shows your own address, the tunnel is not carrying traffic regardless of what the client says. That is the single most important check and it is the one most often skipped.

Check two: DNS

Run the DNS leak test. Every resolver that answers should belong to the operator the tunnel configures. None should belong to your internet provider.

Several addresses from one operator is normal — large resolvers run anycast pools, so one configured server answers from many addresses. What matters is who owns them.

A resolver you have never configured anywhere usually means the browser is using its own encrypted DNS, or Android's Private DNS is set.

Check three: WebRTC

Run the WebRTC leak test. The browser asks a STUN server what address it appears to come from, and any page can read the answer with no prompt.

A system VPN changes where traffic exits; it does not change what the browser reports about its own interfaces. Addresses ending in .local are the browser's mDNS protection working. A public address that is not the VPN's is the finding that matters.

Check four: IPv6

The quietest failure of all. A tunnel routing only IPv4 leaves every IPv6 destination outside it, and since most large sites publish both records and most clients prefer IPv6, that can be the majority of your traffic.

curl -4 https://vpnmine.com/api/tools/ip
curl -6 https://vpnmine.com/api/tools/ip

Both should return the server's address. If the second returns something else, IPv6 is going around the tunnel.

Check five: the kill switch

Test it by simulating a failure rather than by clicking disconnect, because an orderly disconnect gives the switch every opportunity to engage.

Start a continuous ping or open an auto-refreshing page, then kill the VPN process. Traffic should stop immediately and completely, IPv6 included. Anything that continues for more than a moment is a gap.

Check six: the exit country, not just the address

Address geolocation is imperfect. A server's address may be registered in one country and physically located in another, and commercial databases disagree with each other.

If the country matters — because you are matching an account's region, or avoiding a jurisdiction — check with more than one source, and prefer latency as corroboration. A server 20 milliseconds away is not on another continent whatever a database says.

Check seven: the cost

Run the speed test with the tunnel down, then up. A loss of ten to thirty percent on a nearby server is normal. Much worse than that points at distance, a congested server or an MTU problem, and it is worth knowing your baseline so you can tell when something has changed.

When to re-run them

• After changing any VPN setting.
• After a major operating system update.
• After installing anything that touches networking, including ad blockers and antivirus.
• After switching to a new server or a new protocol.
• Occasionally, for no reason, because the failure mode of all of this is silence.

The one that catches the most

If you only do one, do the first. An enormous proportion of "my VPN is not working" turns out to be a tunnel that is up at the interface level and carrying nothing, and thirty seconds on the address page identifies it immediately.

If you do two, add the DNS test. Encrypted traffic to a site your provider already watched you look up protects considerably less than it appears to.

What each check would miss on its own

The reason there are seven rather than one is that each covers a different layer, and a device can pass any single test while failing badly elsewhere.

The address check proves traffic is routed and says nothing about DNS. The DNS test proves lookups are tunnelled and says nothing about IPv6. The IPv6 check proves both families are covered and says nothing about what happens when the tunnel drops. The kill switch test covers that and says nothing about whether the browser is volunteering your address through WebRTC.

They are not redundant, and a provider or an article that offers one of them as proof of a working VPN is offering a quarter of the picture.

Automating the boring parts

If you check often, two commands cover the first and fourth checks in a second:

curl -s -4 https://vpnmine.com/api/tools/ip
curl -s -6 https://vpnmine.com/api/tools/ip

Put them in a shell alias with the expected address, and a change becomes something you notice rather than something you have to remember to look for.