Is My VPN Working? 7 Easy Tests to See If It Isn't

Connected Is a Claim About the App, Not About Your Traffic

A VPN client reports on its own state. It negotiated a tunnel to a server, the tunnel is up, so it draws a green icon. That is the whole meaning of the icon.

What the client does not independently verify is the chain of things that must all be true for that tunnel to matter: that your operating system is routing traffic into it, that DNS lookups go through it, that IPv6 is either tunnelled or blocked, and that no per-application exception is sending something around the outside.

Every failure described below is silent. None of them raises an error, because from the client's point of view nothing has gone wrong. That is exactly why the check has to be made from outside the app — on the open internet, looking back at yourself.

Test 1: The IP Check, and What a Pass Actually Proves

Note the address a reflector site shows you with the VPN off. Connect, reload, and compare. If the address changed, the tunnel is carrying this browser's web traffic.

That is a genuine pass, and it is a narrow one. It proves that this browser, on this network, at this moment, reached that one site through the VPN. It proves nothing about your DNS, your other applications, or IPv6.

Two results are routinely misread. The false pass is testing in the browser you live in and concluding the machine is covered — it is not, and Test 5 is why. The false fail is a changed address whose reported country looks wrong: commercial IP-geolocation databases are estimates that lag reassignments by weeks, so a Netherlands exit can show as Germany while the tunnel is perfectly healthy. The address is the fact; the flag next to it is a guess.

Test 2: DNS, the Leak That Survives a Correct IP

Your device asks a resolver to turn a name into an address before it connects to anything. If that question goes to your internet provider's resolver while everything else goes through the tunnel, the provider still learns the name of every site you visit — the destination it was supposedly no longer able to see.

This is the single most common way a VPN passes Test 1 and fails to deliver what people bought it for. It is also the least visible, because nothing about your browsing changes.

A DNS test lists the resolvers that answered. The pass condition is not that the list looks technical; it is that the resolvers belong to your VPN provider rather than to your ISP. Two specific traps: a router configured with a hard-coded public resolver will keep answering for the whole network, so the leak follows every device on it; and a browser with its own encrypted-DNS setting can bypass the system resolver entirely, which is fine for privacy from your ISP but means the test result you are reading describes the browser, not the machine. Our DNS and WebRTC leak explainer covers the mechanism in full.

Test 3: WebRTC, Where the Browser Goes Round the Tunnel

WebRTC is the browser feature that makes in-page voice and video calls work. To connect two people directly it needs to discover the addresses their machines can be reached on, and it asks the operating system for them — bypassing the network stack the browser normally uses.

That is not a bug in your VPN. It is a browser capability doing exactly what it was designed to do, and it is why a VPN cannot switch it off for you.

What you are looking for on a leak test is your real public address appearing in the WebRTC section while the VPN is connected. A private-range address that starts with 192.168, 10. or 172.16 is not a leak — that is your local network address, it is visible to nothing outside your home, and people report it as a failure constantly. If a real public address does appear, the fix is at the browser: a reputable extension that blocks it, or the browser's own setting where one exists.

Test 4: IPv6, the Half-Protected Connection

Many home connections now carry both IPv4 and IPv6. If a VPN tunnels the first and ignores the second, then any site reachable over IPv6 gets your real address while every IPv4 site sees the tunnel. Half your traffic is protected and half is not, and nothing on screen distinguishes them.

The honest position is that credible providers handle this in one of two acceptable ways: they carry IPv6 inside the tunnel, or they block it outright while connected. Both are fine. What is not fine is leaving it running untouched.

Test it specifically, because a general leak test that only reports IPv4 will show a clean result on a connection that is leaking. If your provider has an IPv6 leak-protection toggle, that toggle existing is not the same as it being on.

Test 5: Split Tunnelling, the Setting That Excludes the App You Are Testing In

Split tunnelling lets you nominate applications that bypass the VPN. It is a legitimate feature — people use it to keep a banking app on the home connection, or to stop a work tool tripping over a foreign exit address.

It is also the reason a machine can pass every browser test and still leak the traffic you cared most about. The tests run in a browser. The excluded application is not a browser. Nothing you do in one tells you anything about the other.

So open the setting and read the list rather than trusting your memory of it. Then check the same thing on the mobile app, where the equivalent feature is often on a different screen with a different name. The rule worth adopting: any application on that list is an application with no VPN at all, and it should be there because you decided it should, not because a setup wizard suggested it.

Test 6: The Kill Switch, Tested Rather Than Trusted

A kill switch blocks traffic when the tunnel drops. It exists because the dangerous moment is not the steady state, it is the two seconds after a laptop wakes or a phone changes network — the window where the app is reconnecting and the operating system has already resumed sending.

Almost nobody tests it, and it is the easiest test on this page. With the VPN connected and a download or stream running, quit the VPN application without disconnecting first. If the transfer stalls, the switch works. If it carries on, it did not.

There are two kinds and the difference matters. An application-level switch kills the apps you nominated. A system-level switch blocks the whole network interface. Only the second protects the things you forgot to nominate. Our kill switch guide covers which providers implement which.

Test 7: The Device You Set Up Once and Never Retested

The last test is not technical. Almost everyone runs the whole battery on the laptop they configured first and never again on the phone, the tablet, the second browser or the router.

Those are the devices where the failures actually live, because they are the ones that changed without you: a mobile operating system upgrade that reset a per-app permission, a browser that gained its own DNS setting in an update, a router reflashed by an engineer visit.

The practical version of this is a habit rather than a chore. Retest after a major operating-system update, after any change to your router, after switching internet provider, and on any device you have not checked since you bought the subscription. That is a handful of minutes a year, and it is the difference between believing you are covered and knowing it.

How to Read the Results Without Fooling Yourself

Three rules turn a wall of technical output into an answer.

Compare against a baseline. Note what every test shows with the VPN off before you connect. A result you cannot compare is a result you cannot interpret, and this is what separates a real pass from a page that simply looks reassuring.

A pass is scoped to what you tested. One browser, one device, one moment. Say the sentence out loud — this browser on this laptop is currently protected — and you will hear immediately how much it does not cover.

Treat a single anomaly as a question, not a verdict. Reflector sites disagree with each other, geolocation lags, and a single reload can catch a reconnection. Repeat the test, on a second tool, before you conclude anything. Two tools agreeing is evidence; one tool asserting is not.

And if a result changes only when you switch server, the variable is the exit rather than your setup — choosing a VPN server location covers what moving it actually changes.

What These Tests Cannot Tell You

It is worth being blunt about the ceiling here, because the tests are good at what they do and people extend them well past it.

They confirm that traffic is going through the tunnel. They cannot confirm what the provider does with it at the other end. No client-side test can: whether a provider keeps logs is a question about its systems and its jurisdiction, answered — imperfectly — by independent audits and by legal cases, which is the subject of our no-logs policy guide.

They also say nothing about who you are. A VPN moves the address sites see; it does not remove cookies, log-ins, or browser fingerprinting, so a passing leak test and a signed-in account are entirely compatible. A VPN does not make you anonymous and it does not defeat an adversary with legal reach over the provider. What it reliably does is stop the network you are on from reading your traffic and stop sites from seeing your home address. What a VPN actually protects draws the line properly.

Finally, none of this is a speed test. If your connection feels slow, that is a separate question with separate causes, and how to read VPN speed claims covers why almost every published figure is unusable.

Frequently Asked Questions