Confirming Your VPN Is Working, in the Right Order

A VPN client showing “connected” is reporting one fact: it established a session with a server. It is not reporting that your traffic is using that session, that your name lookups are, or that every address family on your device is. Those are separate things, and each has its own observation.

Six observations, taken in order from your own machine outward, cover the whole claim. The first two need nothing but the device itself; the rest need one lookup each.

Start on the device, not on a website

Every check that involves loading a page is downstream of the ones you can make locally, so make the local ones first.

The reason is diagnostic economy. If the virtual interface does not exist, no web page can tell you why — you will just see your own address and be no wiser. If the interface exists but the routes point elsewhere, a result showing your real address looks like a leak when it is really a tunnel sitting idle. Both cases are visible in a few lines of local output and neither is visible from outside.

So the sequence runs: interface, routes, exit address, resolver, address family, failure behaviour. Stop at the first one that disagrees with what you expect, because everything after it inherits the problem.

One: the virtual interface exists and holds an address

Connecting should add an interface, and it should have an address from the provider’s internal range.

An interface listed but with no address means the client got partway and stopped — the session negotiated, the configuration did not arrive. An interface that is absent entirely means the client never created it, which points at permissions or at the client itself rather than at the network.

The address itself will be a private one, because it identifies you inside the provider’s network rather than on the internet. Which fields to read and where each platform hides them is covered in reading your own network settings.

Two: default traffic prefers that interface

An idle tunnel is indistinguishable from a working one until you look at the routing table.

You are looking for a default route pointing at the virtual interface, plus a narrow exception for the VPN server’s own address so the encrypted packets themselves can still get out over the physical interface. That exception is normal and its absence would be the bug.

Two other entries are worth noting while you are there: whether a route still exists for your own local network, which determines whether printers and media devices remain reachable, and whether any specific destinations have been routed outside the tunnel, which is how split tunnelling shows up in practice.

There is also a way to see the routing rather than read it. Tracing the path to a destination with the tunnel up should show the tunnel endpoint and then the provider’s onward network, with your own internet provider’s hops absent.

Three: the address the internet sees is not yours

This is the check most people start with, and it belongs third because it only means something once the first two pass.

You want to see an address that is not the one your connection normally presents, and ideally one whose ownership records name a hosting or VPN network rather than a consumer internet provider. Reading those records is a small skill that turns a number into a statement about who is carrying your traffic; finding and interpreting the exit address goes through it.

Compare against a value you noted with the tunnel down. Doing it from memory is how people convince themselves a working tunnel is broken.

Four: name lookups use the same path

A correct exit address says nothing about where your hostnames are going.

The observation you want is which resolvers answer for you while connected. They should be the provider’s, or whatever you deliberately configured — not the resolver your router advertised. Any test that reports the resolver seen at the far end will do; what matters is that you compare it against the resolver you expect rather than simply noting that a result appeared.

Two things routinely muddy this. Answers cached before you connected are served from your own machine and never reach any resolver, so clear the cache before testing. And a browser with its own encrypted DNS enabled bypasses the system resolver entirely, so a test run inside it reports the browser’s choice rather than your device’s.

Five: both address families are covered

A tunnel can carry one address family and leave the other running in the open.

If your network has working IPv6 and your tunnel does not, a meaningful share of destinations will be reached outside it with your real address attached, while every check above still passes. The specific mechanism, and how to establish whether your network has IPv6 at all, is in why IPv6 is the leak people forget.

The practical note for this sequence: a check that reports a single address has probably told you about one family only. Prefer one that reports both, or run the comparison twice.

Six: what happens when it stops

A tunnel is also defined by its behaviour when it fails, and that is the one observation you have to provoke.

Disconnect deliberately, or let the client lose its server, and watch whether traffic continues to flow. If pages keep loading with your ordinary address, the device fell back to the open path — which is the correct default behaviour for a network stack and the wrong outcome for a VPN. Preventing it is what a kill switch does, generally with firewall rules rather than by watching for the drop.

Test it while nothing important is happening, and test it on each device separately. A setting enabled on a laptop says nothing about a phone.

When to repeat this

After anything that changes the shape of the connection. A client update, a protocol change, a new server location, a different network, a new device, or an operating system upgrade — all of them have plausible reasons to alter one of the six answers without altering any of the others.

What this does not establish

It confirms placement, not privacy. Passing all six means your traffic and lookups travel through the provider’s network and emerge from its address. It does not mean you are anonymous: you are still signed into accounts, still carrying cookies, and still identifiable by your browser’s characteristics. It says nothing about what the provider records either — that is a question about documents and operators, not about your own device.

And it is a snapshot of the moment you looked, which is exactly why the sixth check matters more than it first appears.