How to Check That Your VPN Is Working

A connected client tells you almost nothing. It reports success when a handshake completed, which is a much smaller claim than “my traffic is inside this tunnel”. Four things can keep leaking while the app shows a green tick, and the most popular tool for checking them cannot reliably detect one of the four.

Short answer#

Check four things separately: the address websites see, the resolver answering your DNS queries, whether IPv6 is inside the tunnel, and whether WebRTC can read your real address. Two of the four need a terminal.

Check 1: is the tunnel carrying your traffic#

The simplest test and the one everything else assumes. Load a page that reports the address it was reached from, with the VPN connected. If the address shown belongs to your network rather than your provider, the tunnel is not carrying browser traffic.

A more precise version catches split tunnelling and apps that report connected while the system route never changed: compare the country the page reports against the location you selected in the client. Both should agree.

Check 2: where your DNS queries are going#

This is the check most tools get wrong, and it is worth understanding why.

Name resolution is the first thing your device does for every hostname. If those lookups are answered by your network’s resolver instead of one inside the tunnel, the names you visit are exposed even though the traffic afterwards is not.

A browser cannot observe this. The page you are visiting sees only the result, not who returned it, which is why honest leak testers state that verifying DNS “needs an authoritative nameserver we control”. Anything a browser reports about your resolver is inference.

From a terminal, with the VPN connected:

nslookup -type=txt whoami.cloudflare 1.1.1.1
dig +short myip.opendns.com @resolver1.opendns.com

The first returns the resolver address Cloudflare saw querying. If that address belongs to your network while the VPN is on, DNS is leaking. Most clients have a setting along the lines of using the VPN’s own resolver or blocking outside DNS, and that setting is the actual fix.

Check 3: IPv6#

Browsers prefer IPv6 when a device has it. Many VPN clients tunnel IPv4 only, so a working IPv6 address bypasses the tunnel entirely and lands you at websites with your real one.

A passing check here is weak evidence, because a device that has IPv6 but happened to connect over IPv4 reads as a pass. Test it deliberately: confirm the address your client shows you is an IPv6 address, then confirm what sites see.

The fix is to disable IPv6 on the adapter, or to use a provider that tunnels it.

Check 4: WebRTC#

WebRTC lets browsers open peer-to-peer connections directly, and it discovers your public address to do it. A page can trigger that and read the result, which is how the original leak worked: Mullvad warned about it in 2015, describing a browser that exposes the real public IP of anyone connected through a VPN.

Firefox is the only mainstream browser that can fully disable it, via media.peerconnection.enabled set to false in about:config. Chrome on desktop offers no such control at all.

Brave is the partial answer, and it is closer than most pages admit. Brave exposes a WebRTC IP handling policy in chrome://settings/privacy, and its own documentation describes four settings rather than an on/off switch. “Default Public Interface Only” and “Disable Non-Proxied UDP” both mean local addresses are not exposed, and “Disable Non-Proxied UDP” is the default when Fingerprinting Protection is on. What Brave does not offer is a way to turn WebRTC off; it reduces what WebRTC can reveal, following the framework in RFC 8828, which explicitly recommends against blunt disabling because it breaks applications.

For the specific risk this check exists to catch, a Brave user with Fingerprinting Protection on is in reasonable shape. The distinction is that reduced exposure and no WebRTC are different things, and only Firefox offers the second.

What still leaks when every check passes#

Green results are worth something. They are not a guarantee.

Mullvad’s 2024 application audit, carried out by X41, recorded a finding for exactly this case. On Linux and Android, the kernel replies to ARP requests for any local address, so an attacker on the same local network can learn the address of your tunnel interface, and because that address rotates monthly, potentially identify the device over time. Mullvad rated it medium severity, noting it discloses little about the user, and cited its padding and noise packets as partial mitigation.

A local network observer can tell you are running a VPN even with all four checks green.

Reading the results#

A leak is not automatically a failure of your provider. It is more often a configuration problem, and the check tells you which one.

Real address showing means the route did not change. Local resolver showing means the client’s DNS setting is off or unsupported. IPv6 showing means the tunnel does not cover it. WebRTC showing means the browser needs a policy change.

Common misconceptions#

“A green check proves the VPN works.” It proves the check you ran passed. Different tools check different subsets, and browser-only DNS tests check something a browser cannot actually observe.

“Leak tests are objective.” Most are third-party pages reading what your browser exposes to a stranger. That is useful signal and not a security boundary.

“Disabling WebRTC is the only fix.” It addresses one path. IPv6 and DNS leaks reach the same places without WebRTC being involved at all.

“A passing test means nobody can tell.” The operator and the datacentre can still reach things your test cannot see.

Related#

• What Is a VPN?: what the tunnel changes, which is what these checks confirm
• What Should You Look for in a VPN?: choosing something worth testing
• Who Controls the Infrastructure?: the checks above do not cover the operator

Last reviewed October 8, 2026. Corrections and additions are welcome.