A “VPN leak” is traffic or identifying network information that follows a route the user did not intend while the VPN is expected to protect it. The phrase can refer to public IP exposure, DNS queries sent to the wrong resolver, IPv6 traffic bypassing an IPv4-only tunnel, or applications reconnecting outside the tunnel after failure. Browser test pages may also report local addresses or device signals that are not equivalent to internet traffic escaping.
Testing should answer a defined question. Which traffic should use the tunnel? Which DNS resolver should answer? What should happen if the tunnel drops? Without that baseline, a test page can create false alarms by showing a shared VPN address, a resolver in another region, or a private local address that is not globally reachable. Methodical comparison is more useful than a red “leak” label.
Establish the expected route first
Write down whether the configuration is full tunnel, split tunnel, per-app, browser-only, or enterprise remote access. A split-tunnel policy intentionally leaves some destinations outside the VPN, so a direct route is not automatically a defect. A browser extension may protect Chrome while a command-line test uses the normal network. The test method must run inside the scope you intend to evaluate.
Record the expected VPN endpoint region and the expected DNS behavior from the provider’s documentation. Some services use provider-operated resolvers; others securely direct queries to a third party. Enterprise VPNs may use split DNS so internal names go to corporate resolvers while public names use another path. The correct result is the documented policy, not necessarily one resolver name or country.
Public IP testing
Before connecting, note the public IPv4 and IPv6 addresses reported by a reputable test. Then connect the VPN and repeat in the same browser profile. A full-tunnel consumer VPN should normally show the endpoint’s public address rather than the underlying connection’s address. If IPv6 remains unchanged while IPv4 changes, determine whether the provider supports IPv6, disables it during the tunnel, or expects the operating system to route it.
Do not publish screenshots containing full addresses, account identifiers, or diagnostic tokens. Compare privately. If the service uses carrier-grade translation or shared endpoints, the reported address may differ between tests. The key question is whether the underlying public address appears where the VPN claims to cover that protocol.
DNS leak testing
DNS translates names into addresses. A DNS leak occurs when queries that should follow the VPN’s resolver policy are sent elsewhere, potentially revealing requested domains to the local network or internet provider. Test after the tunnel is stable and repeat after a network handoff. Results may list the resolver operator, an anycast location, or a cloud host that does not match the VPN server city. Geographic mismatch alone is not proof of leakage.
Check whether the listed resolver belongs to the VPN provider, a documented partner, the enterprise, or a secure DNS service you configured in the browser or operating system. Browser secure-DNS settings can override or compete with the VPN’s resolver plan. If results are unexpected, return the browser to its default resolver behavior, reconnect, and test again before changing system settings.
Do not “fix” DNS blindly
Randomly entering a public resolver can defeat enterprise split DNS, break local services, or move trust to a new operator. Identify the intended policy first, then correct the component that violates it.
IPv6 bypass and dual-stack networks
Many networks support both IPv4 and IPv6. A VPN that handles only IPv4 must either block IPv6, route it through the tunnel, or clearly document that IPv6 uses the normal path. Silent bypass is the risky outcome when the user expects full-device coverage. Test both address families on Wi-Fi and cellular because support can differ.
The durable fix belongs in the VPN client or network policy. Manually disabling IPv6 may be an emergency diagnostic step, but it can break applications and is not a substitute for a maintained dual-stack design. Report the operating system, network type, protocol, and test result to the provider. On managed devices, do not alter IP settings outside organizational policy.
WebRTC and browser-reported addresses
WebRTC enables real-time browser communication and can expose candidate network addresses to support peer connectivity. Modern browsers and networks may show private local addresses, masked hostnames, or the VPN address. A private address such as one used only inside the home or hotel is not the same as the public ISP address leaking to the internet. Interpret the result carefully.
If a browser reveals the underlying public address while a full-device VPN claims to cover browser traffic, update the browser and VPN client, disable conflicting extensions, and retest. Avoid installing an unknown “leak blocker” with broad access. Browser privacy controls and a properly routed system VPN are preferable to a stack of opaque extensions. Video calls may use direct or relayed paths, so verify functionality after any restriction.
Kill-switch and failure testing
A kill switch or lockdown control is intended to block traffic when the tunnel fails. Test it on a trusted network with non-sensitive activity. Start a continuous connection such as a harmless download or network monitor, then disconnect the VPN process, switch networks, or briefly enable airplane mode. Observe whether traffic pauses until the tunnel returns. Repeat after sleep and after reboot if the feature claims to persist.
Distinguish graceful disconnection from unexpected failure. Some clients treat a user pressing “disconnect” as permission to restore normal routing, while they block only unplanned drops. Read the documentation. Also test local network access if you need printers or casting; some blocking modes intentionally prevent it. A control that surprises the user will eventually be disabled, so document the expected behavior.
A repeatable test matrix
- Record baseline IPv4, IPv6, and DNS results with the VPN off.
- Connect using the normal protocol and a nearby endpoint; repeat the same tests.
- Switch from Wi-Fi to cellular or another Wi-Fi network and repeat.
- Test the browser and one non-browser application to confirm scope.
- Trigger a controlled tunnel failure and observe whether traffic blocks.
- Restart the device and verify auto-connect or always-on behavior.
- Change only one setting when troubleshooting and preserve screenshots privately.
Run the matrix after a major operating-system update, VPN client update, or configuration change. There is little value in testing every day when nothing changes, but there is also little value in relying on a result from a year ago. A concise record helps support teams reproduce issues and prevents circular troubleshooting.
DNS is infrastructure, not a magic privacy switch
Primary source: The NIST Secure Domain Name System Deployment Guide describes DNS roles, secure deployment, encrypted DNS, and protective DNS in a defense-in-depth model. Its scope is broader than consumer leak tests, but it reinforces that resolver security and routing require deliberate architecture.
Encrypted DNS protects queries between the client and resolver; it does not make the resolver unaware of the query. A VPN may protect DNS on the path to its endpoint and then use a chosen resolver. Evaluate who operates each layer and what policy applies. “No DNS visible anywhere” is not a realistic model because a resolver must ultimately answer the request.
Common false positives
- A resolver location differs from the VPN server because anycast or cloud infrastructure routes it elsewhere.
- A private local address appears in a browser test but is not globally routable.
- A split-tunnel application intentionally uses the normal connection.
- A browser secure-DNS setting uses a documented third-party resolver.
- An enterprise split-DNS policy sends only internal names through the corporate resolver.
- A cached result remains briefly after reconnecting; repeat after clearing the session or waiting.
False positives do not mean every result should be dismissed. They mean the tester should compare against a stated policy and reproduce the behavior. When the underlying public address or local ISP resolver appears unexpectedly in a full-tunnel configuration, collect evidence and treat it as a real issue until explained.
Conclusion: test the promise, not the label
VPN leak testing is a verification discipline. Define the intended scope, establish a baseline, compare IPv4, IPv6, and DNS routes, and test failure behavior across network changes. Interpret browser signals with care and avoid random configuration changes that create new trust relationships. A trustworthy setup produces results consistent with its documentation and gives you a clear path to diagnose exceptions.
