How to Tell If Your VPN Is Actually Working

The word “Connected” in a VPN client means a handshake completed with a server. It says nothing about whether your browser is using the tunnel, where your domain lookups are going, or whether IPv6 traffic walked straight past the whole arrangement.

Four checks take about two minutes and tell you what is actually happening. Do them after any change to the client, the operating system or the router, and not otherwise.

Before you start: a baseline

Turn the VPN off and note two things: the IP address an IP-checking site reports, and the resolvers a DNS leak test lists.

Those are the values that must not reappear once the tunnel is up. Without the baseline, a leak test result is a list of names you cannot evaluate.

Check 1 — Your apparent IP address

Load any IP-checking site, or search for “what is my IP”.

If it shows your real location while the client says connected, the usual causes are a split tunnel rule that includes your browser, a browser proxy extension overriding system routing, or a stale route from a client that crashed. The connected-but-blocked triage works through each.

Do this check in the browser you actually use. A browser with its own proxy extension can produce a different result from the rest of the system.

Check 2 — DNS

This is the check people skip and the one that matters most for privacy.

Your device turns domain names into addresses before connecting. If those lookups go to your internet provider’s resolvers, your provider has a complete list of every site you visited, regardless of how encrypted the traffic afterwards was.

Run a DNS leak test, several sites offer one, and read the list of resolvers that answered.

• Resolvers belonging to your VPN provider: correct.
• Resolvers belonging to your internet provider: a leak, and the one worth fixing today.
• A third party such as a public resolver: acceptable if you configured it deliberately, suspicious if you did not.

Four fixes, in the order worth trying:

1. Enable DNS leak protection in the client. Present in most, sometimes off by default.
2. Check your browser’s secure DNS setting. Chrome and Firefox can use their own DNS-over-HTTPS resolver, bypassing whatever the VPN set. Chrome: Settings → Privacy and security → Security → Use secure DNS. Firefox: Settings → Privacy & Security → DNS over HTTPS. Set to off or to the provider’s resolver while using a VPN.
3. Check Android’s Private DNS. Settings → Network & internet → Private DNS. A hostname here overrides the VPN’s DNS; set it to Automatic.
4. On a router VPN, set the DNS explicitly in the router’s WAN settings. Routers commonly keep handing out the internet provider’s resolvers over DHCP while reporting a healthy tunnel.

Point 2 catches more people than it should, because the browser setting is presented as a privacy feature while quietly undermining the one you are paying for.

Check 3 — IPv6

Many VPN clients tunnel IPv4 and leave IPv6 alone. If your connection has IPv6 and the site you visit supports it, your browser prefers IPv6 and goes straight out with your real address attached.

Leak test sites report IPv6 separately. You want either no IPv6 address reported, or one belonging to the VPN.

Fixes:

• Enable IPv6 leak protection or Block IPv6 in the client. Most have it.
• Where the client does not, disable IPv6 on the network adapter. Windows: Network & internet → the adapter → Edit IP assignment, or the adapter’s properties. This breaks IPv6 for everything, including when the VPN is off, so turn it back on afterwards if you rely on it.

This is a common cause of streaming blocks that appear while the VPN seems to be working perfectly. Why streaming platforms block VPNs covers that case.

Check 4 — WebRTC

A browser feature for real-time calls that can expose IP addresses to a web page independently of system routing. Leak test sites include a WebRTC section.

Seeing a private address like 192.168.x.x is harmless; that is your local network address and reveals nothing. Seeing your real public address is the problem.

Browsers have narrowed this considerably compared to a few years ago, and it only ever affected browsers rather than the whole system. Fix it with a browser extension that restricts WebRTC, or in Firefox by setting media.peerconnection.enabled to false in about:config. That will break video calls in that browser, so do it in a secondary browser rather than your main one.

Checking the whole device, not just one browser

All four checks above run in a browser, which tests one application. A VPN is supposed to cover everything, and the gap between those two statements is where people get caught.

The quick version: open an IP-checking site in a second browser, ideally one with no extensions. A different answer from the two means something browser-specific is routing independently, usually a proxy extension or a per-browser DNS setting.

For a system-level answer, check which interface your traffic actually uses:

• Windows — Terminal: route print and look at the default route. With a tunnel up, the lowest-metric default route should point at the VPN’s adapter, not your Wi-Fi.
• macOS and Linux — Terminal: netstat -rn | grep default, which should show a utun or similar tunnel interface first.

You can also check ipconfig /all on Windows or your network settings on macOS and confirm the DNS servers listed for the active adapter are the provider’s. Where the adapter still lists your internet provider’s resolvers, that is the leak from check 2 showing up at its source.

What these checks cannot tell you

Worth being clear about the limits, because leak tests get treated as a verdict on the whole arrangement.

They show what third parties on the network path can observe. They say nothing about:

• Whether your provider logs. Unverifiable from your side. Independent audits are the only external evidence, and an audit is a snapshot.
• Whether you are identifiable. Logging into an account identifies you regardless of your IP address, as do cookies and browser fingerprinting. What a VPN actually does covers the gap between encrypted and anonymous.
• Whether the encryption is implemented correctly. You are trusting the client’s code.

A clean leak test means your traffic is going where you configured it to go. It does not mean you are anonymous, and those two claims get conflated constantly by people selling subscriptions.

Realistic expectations

On a correctly configured client, all four checks pass and you will not need to look again until something changes.

The two that fail most often in practice are DNS, usually because of a browser’s own secure DNS setting, and IPv6, usually because the client tunnels IPv4 only. Both are fixed in under a minute once you know which one it is.

Recheck after client updates, major operating system updates and router firmware updates. Those are the three events that quietly reset routing and DNS settings, and none of them announce that they have done it.