PRIVACY / LEAK CHECKS

VPN leak tests: what DNS, IPv6 and WebRTC can reveal

A changed public IP is useful, but it does not prove that every DNS query, browser address or application route stays inside the intended tunnel.

Quick overview

Different leak tests investigate different network paths.

Know which path is being checked

DNS queries can sometimes use resolvers outside the intended VPN configuration. IPv6 may use a different route if the VPN or operating system does not handle it as expected.

WebRTC address exposure depends on browser, configuration and whether the observed address is actually public or local. Interpret findings before calling them a leak.

A careful checklist

Compare public IPs with and without the VPN, then inspect DNS resolvers, supported IP families and configured browser behavior.

Start at the privacy tools hub. We label a feature as a working leak-test tool only after implementation and validation.

Start by defining the expected route

A leak test is meaningful only when you know what behavior should happen. Record the public IP and DNS resolver before enabling the VPN. Then connect to a specific exit, refresh the checks, and compare the observed results to the expected VPN route. Avoid treating every unfamiliar IP address as a leak. A VPN provider can operate or contract several exit and resolver networks, and geolocation databases can disagree about their locations.

Use more than one measurement source when possible. A browser-based check sees the network path used by that browser; it may not represent every background service on the device. Repeat the test after reconnecting and after switching networks. Document the client platform and protocol, because a result on a desktop does not automatically describe a phone or router.

How to interpret DNS results

DNS translates hostnames into addresses. Ideally, DNS queries used by VPN-routed applications follow the privacy model you expect from the VPN, but system settings, secure-DNS modes, and split tunneling can change which resolver answers. Seeing a resolver owned by a third party is not always proof of a failure; some VPNs rely on external resolution infrastructure, and browser-level DNS-over-HTTPS can deliberately choose a resolver independent of the operating system.

Investigate whether a query escaped the intended tunnel, not simply whether a resolver name looks unfamiliar. Compare DNS behavior while disconnected, connected, and after a tunnel interruption. If you use customized DNS settings, temporarily document them rather than changing several variables at once.

IPv6 and WebRTC require separate interpretation

An IPv6 leak concern arises when a device sends traffic along an IPv6 path outside the intended VPN routing policy. Some VPNs route IPv6 natively; others block it or handle it differently. Test whether the public address returned over IPv6 is the expected exit and whether a direct path remains available. Do not disable IPv6 as the first troubleshooting step unless you understand the impact on your network.

WebRTC can expose network candidates as part of real-time communication setup. Modern browsers have privacy controls that may obscure local addresses, and a listed private address is not the same as a globally reachable public IP. Distinguish local, public and VPN-exit candidates before concluding that a privacy failure has occurred. Browser and operating-system versions can change the behavior.

Make the test repeatable

For each test, capture the time, device, operating system, VPN protocol, selected exit location, and whether split tunneling or custom DNS was enabled. Test a steady connection, a deliberate disconnect, and a reconnect. If you see an unexpected address, reproduce it before reporting a leak and check whether the VPN configuration intentionally excludes the application.

Leak testing does not measure all privacy risks. It does not establish the VPN provider's logging behavior, validate its ownership, or remove trackers and account identifiers. Combine routing checks with software update practices, application permissions, and review of provider documentation for a more complete assessment.

Practical checklist

DNS: Which resolver receives queries?
IPv6: Which address family uses the tunnel?
WebRTC: Check address type and exposure.

Frequently asked questions

Does changing IP mean no DNS leak?

No. DNS behavior requires a separate check.

Is every local WebRTC address a privacy leak?

Not necessarily. Local addresses and public exposure are different.

Is this page an automatic test?

No. It is guidance on how such tests should be interpreted.

Does an unfamiliar DNS server always mean a leak?

No. Confirm the expected DNS policy and whether the query actually bypasses the tunnel. Some providers and browser settings legitimately use third-party resolvers.

Is a local WebRTC address the same as exposing my public IP?

No. Private local addresses and globally routable public addresses are different. Interpret candidates using their address type and your expected route.

Should I just switch IPv6 off?

Not automatically. First check whether the VPN supports or blocks IPv6 and whether any direct traffic exists outside the tunnel; disabling IPv6 can affect other network functions.

More Secure-VPN guides

Independent editorial guidance; supplemental explanations do not claim new first-party measurements. For measured performance, see our methodology and analytics.