Network Leak Detection 2026: DNS, WebRTC, IPv6 Testing Guide

A VPN changes your exit IP. By default, it does not seal every path through which your real identity leaks. DNS queries, WebRTC peer discovery, and IPv6 packets are three distinct channels. Each one bypasses or pre-dates typical VPN setups. This guide gives you a reproducible testing protocol. It also covers the technical background, so you understand what each leak type exposes and how to close each gap.

1. Why network leaks persist in 2026

The internet was not designed with tunnel enforcement in mind. When you connect to a VPN, the client usually does three things. It creates a virtual network interface, installs routing rules, and updates the system DNS configuration. Each of these steps can fail — and failure is common.

Three threat actors hold most of the real risk. They matter for users who run a VPN mainly to protect their privacy:

ISP-level surveillance. Your ISP can watch your DNS queries at their recursive resolver. They can do this unless you route DNS inside the VPN tunnel. On residential connections, they see a log of every hostname you access. Some places have data retention laws (EU Directive 2006/24 successors, UK IPA 2016, Australia TSSR). There, ISPs store this data for months to years. A DNS leak hands them this ability for the entire session.

Public Wi-Fi and captive portals. Managed Wi-Fi at hotels, airports, and coworking spaces often intercepts traffic before VPN negotiation completes. DHCP assigns a gateway address. Until the VPN tunnel is up, all traffic flows over the captive network. That includes DNS and WebRTC. Some captive portals actively block VPN protocols to stop bypass. This forces reconnection attempts, which create repeated exposure windows.

In-browser tracking at scale. Analytics and advertising scripts load on ordinary commercial websites. They can run WebRTC code to gather IP candidates, and they ask for no permissions. In 2026, at least 340 of the top 10,000 websites by Alexa rank load such a third-party script. Each one probes RTCPeerConnection. For users under a VPN, this exposes the local network address. Sometimes it also exposes the public address the ISP assigned. That data can tie back to a household-level identity, even without the exit IP.

To know which channel leaks, you must test each one on its own. Combined "am I leaking?" pages mix the results together and often miss edge cases. A structured test protocol — documented in section 5 — gives you reliable coverage.

For context on how leak exposure fits into the broader browser privacy landscape, see the State of Browser Privacy 2026 overview from PrivSec Lab. To test your canvas and WebGL fingerprint exposure in parallel, use our interactive browser fingerprint test tool.

What is a DNS leak and how do you detect it?

A DNS leak occurs when your DNS queries bypass your VPN tunnel and reach your ISP's resolver instead. It exposes every hostname you visit, despite the VPN. It happens because VPN clients often fail to override all system DNS paths. This includes browser-level DoH and secondary network adapters. To detect it, run dnsleaktest.com's extended test. Then check whether the shown resolver ASN matches your VPN provider, not your ISP.

DNS leaks — mechanism and detection

DNS resolution follows a priority order set by the operating system. On Linux, /etc/nsswitch.conf and /etc/resolv.conf govern this. On Windows, the DNS client queries each adapter's configured resolver in order. It uses NRPT (Name Resolution Policy Table) rules for domain-specific overrides. On macOS, the resolver config in /etc/resolver/ and the scutil --dns output set the behavior.

A VPN client that correctly prevents DNS leaks must override all of these paths. The common failure modes are:

System resolver not fully replaced. Some VPN clients update the primary adapter's DNS setting. But they leave secondary adapters pointing at the ISP resolver — Ethernet while on Wi-Fi, for example. Queries may route through either interface, depending on network conditions.

Browser DoH bypass. Chrome and Firefox implement DNS-over-HTTPS (RFC 8484) on their own, apart from the operating system. Say the browser's built-in DoH is on and pointed at a public resolver (Cloudflare 1.1.1.1, Google 8.8.8.8). Those queries skip the VPN DNS entirely and go straight over HTTPS to the external resolver. The resolution then happens outside the VPN tunnel, though the HTTPS connection is itself encrypted.

DNS prefetch and speculative resolution. Browsers send speculative DNS queries for links on the current page, before the user navigates. These use the browser's DNS stack, which may invoke DoH or the system resolver. Extensions that disable <link rel="dns-prefetch"> tags shrink this surface. But they do not stop background resolution entirely.

Testing DNS leaks:

1. dnsleaktest.com — run both standard and extended tests. The extended test sends 30+ queries to force use of any secondary resolver paths. Compare the ASN (Autonomous System Number) and IP of the resolvers shown against what your VPN provider documents.
2. ipleak.net — shows IP, DNS resolvers, and WebRTC candidates at once on one page. It is handy for a quick cross-channel snapshot, but less granular than a dedicated DNS test.
3. Cloudflare 1.1.1.1/help — shows which resolver your browser's current DNS stack uses. It also tells you whether DoH is active and pointing at Cloudflare's endpoint. Use it to verify browser-level DNS config apart from the OS.

Protocol distinction matters: plain UDP/53 queries are unencrypted. Anyone can intercept them at any network hop. DNS-over-TLS (RFC 7858) encrypts queries to the resolver, but the resolver still sees all queries in plain text. DNS-over-HTTPS (RFC 8484) wraps queries in HTTPS. This makes them look like regular web traffic and resists interception at intermediate network nodes. Neither DoT nor DoH stops the resolver itself from logging queries.

For a deep technical comparison of DoH implementations across browsers and operating systems, see our DNS-over-HTTPS implementations 2026 analysis.

3. WebRTC leaks — STUN, ICE, and JavaScript exposure

WebRTC (Web Real-Time Communication) is a browser API. It enables peer-to-peer audio, video, and data channels. To set up the connection, it uses ICE (Interactive Connectivity Establishment). ICE in turn uses the STUN protocol defined in RFC 5389.

How STUN exposes IP addresses:

When a browser creates an RTCPeerConnection, it starts gathering ICE candidates. These are a list of network addresses through which it can receive peer connections. The gathering process involves:

1. Host candidates: local interface IP addresses (LAN IPs, loopback) collected directly from the OS network stack.
2. Server-reflexive candidates: the public IP as seen by a STUN server. The browser sends a UDP Binding Request to a STUN server. The server replies with the client's source IP and port (the Mapped Address attribute in the STUN response). This is the external IP — the one your router NAT exposes to the internet.
3. Relay candidates: TURN server addresses used when direct connectivity fails.

Here is the critical issue. This gathering happens synchronously the moment RTCPeerConnection is created. It runs before any user interaction or permission grant. A script can run:

const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('');
pc.onicecandidate = e => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createOffer().then(o => pc.setLocalDescription(o));

This outputs all gathered candidates to the console. It can also send them to a remote server, if the callback uses fetch. No camera permission. No microphone permission. No user alert.

Browser mitigations:

• Firefox: set media.peerconnection.enabled in about:config to false. This fully disables WebRTC. It stops all leaks, but it also breaks any WebRTC-based application. A more targeted option: set media.peerconnection.ice.default_address_only to true. This limits ICE gathering to the default interface only. It blocks local LAN IP exposure while keeping WebRTC working.
• Chrome/Chromium: the legacy flag chrome://flags/#enable-webrtc-hide-local-ips-with-mdns replaces local IPs with mDNS hostnames (e.g., a1b2c3d4.local) in ICE candidates. This stops JavaScript from reading the actual LAN address. It is now the default behavior in Chrome 75+. But server-reflexive candidates (public IP) are still exposed if a STUN server is configured.
• Brave: Brave's fingerprinting protection at "Standard" level blocks cross-site WebRTC leaks. At "Strict" level, WebRTC is disabled entirely for third-party frames. This stops analytics and ad-network STUN probes. It still allows first-party WebRTC in the top frame — for example, video conferencing on meet.example.com.
• uBlock Origin: turn on "Prevent WebRTC from leaking local IP addresses" in uBlock Origin's dashboard (under the Privacy tab). It intercepts RTCPeerConnection construction. It then overrides the ICE configuration so third-party scripts cannot use a STUN server.

Testing WebRTC leaks:

browserleaks.com/webrtc runs a full ICE gathering sequence. It then displays all collected candidates: local addresses, server-reflexive addresses, and the public IP seen by their STUN server. Compare the displayed public IP against your VPN exit IP. A mismatch confirms a WebRTC leak — especially if the leaked IP is in your ISP's ASN.

For how WebRTC and fingerprinting vectors interact, see our Privacy Browsers 2026 comparative analysis.

4. IPv6 leaks — dual-stack failures and VPN blind spots

IPv6 adoption reached about 45% of global internet traffic by late 2025, according to APNIC statistics. Most residential ISPs in North America, Western Europe, and major Asian markets now set up dual-stack connections by default. So your router and devices receive both IPv4 and IPv6 global addresses.

How IPv6 leaks happen:

A VPN creates a tunnel interface. In the past, most consumer VPN implementations created an IPv4 tunnel (tun0 or similar). They did not set up an IPv6 tunnel. When you connect to a dual-stack server, the OS chooses between IPv4 and IPv6 routes. Say IPv6 is reachable natively, via your ISP's native IPv6 prefix, and there is no VPN route for IPv6. Then the OS sends IPv6 packets straight through the native interface. They bypass the VPN entirely.

The result: your IPv6 traffic reveals your ISP-assigned global IPv6 address. That address is both unique and persistent, since ISPs usually assign stable prefixes to residential customers. It links to your account, your household, and your billing information at the ISP level.

Configurations that create IPv6 leaks:

• VPN clients that only create IPv4 tunnels and do not block or route IPv6
• Split-tunnel VPN configurations that route only specific IPv4 subnets through the tunnel
• VPN protocols (especially older IKEv2 configs) deployed without IPv6 policy routing rules
• Mobile devices that pick up IPv6 addresses via SLAAC after VPN connection, before the VPN client updates routing

Testing IPv6 leaks:

1. ipv6-test.com — shows your current IPv6 address and prefix if reachable. If the address shown is in your ISP's prefix (not your VPN provider's), you have an IPv6 leak.
2. test-ipv6.com — runs a sequence of tests. These include IPv6 reachability, DNS-via-IPv6, and fallback behavior. The "IPv6 without DNS" test is especially useful. It separates transport leaks from resolver leaks.
3. ipleak.net — shows IPv6 address alongside IPv4 and DNS, allowing comparison of all three in one view.

Mitigations:

• Use a VPN client that either routes IPv6 inside the tunnel or disables IPv6 on all interfaces while the tunnel is active. The second option is the more common one.
• On Linux, you can disable IPv6 with sysctl -w net.ipv6.conf.all.disable_ipv6=1 before connecting. It is better to set this in the VPN client's up/down scripts.
• On Windows, go to Network Adapters → Properties. Uncheck "Internet Protocol Version 6" per adapter. Or configure VPN adapter binding to handle both stacks.
• Check that your VPN provider's knowledge base documents IPv6 handling. Missing documentation is itself a signal.

How do you run a complete VPN leak test?

A reliable VPN leak test requires five steps:

1. Baseline — document your ISP's DNS resolvers and public IPs before connecting VPN
2. Post-connection test — connect, wait 30 seconds, then run dnsleaktest.com (extended), browserleaks.com/webrtc, and ipv6-test.com
3. Kill switch test — abruptly disconnect VPN while a continuous DNS test runs; queries must stop, not fall back to ISP
4. Sandboxed browser test — repeat in a clean browser profile with no extensions, to reveal raw browser behavior
5. Browser DoH test — enable browser-level DoH with a public resolver; if the shown DNS resolver changes away from your VPN's, browser DoH is bypassing your tunnel

Reproducible test protocol

A one-time test at VPN setup is not enough. Network state changes on sleep/wake, DHCP renewal, captive portal re-authentication, and OS updates. The protocol below sets a baseline and covers these state transitions.

Setup: define your baseline

Before any VPN connection, document:

• Your ISP's DNS resolver IP(s) from nslookup -type=ns google.com or dig @8.8.8.8 google.com
• Your public IPv4 from a plain HTTP endpoint (curl http://ipinfo.io/ip)
• Your public IPv6 if present (curl -6 http://ipv6.icanhazip.com)
• Your browser's DNS resolver from Cloudflare 1.1.1.1/help

Step 1: Pre-VPN snapshot

With VPN disconnected, run all four test tools and record:

• DNS resolvers shown on dnsleaktest.com (extended test)
• WebRTC candidates on browserleaks.com/webrtc
• IPv4 and IPv6 addresses on ipv6-test.com
• Browser DNS on 1.1.1.1/help

Step 2: Post-VPN connection test

Connect VPN. Wait 30 seconds for routing tables to settle. Repeat all four tests. Here are the expected results if the VPN is correctly configured:

• DNS resolvers should be in the VPN provider's ASN or a trusted resolver (Cloudflare, Mullvad's own resolver)
• WebRTC server-reflexive candidates should show only the VPN exit IP
• IPv6 should show either the VPN's IPv6 exit or "no IPv6 connectivity". Both are fine if the VPN does not provide IPv6.
• Browser DNS should use the VPN's configured resolver

Step 3: Kill switch test

Keep the VPN active. Open a browser tab running continuous DNS queries (dnsleaktest.com extended test on repeat). Now disconnect the VPN client abruptly. Do not use the graceful disconnect button. Instead, disable the VPN adapter or block it at the firewall level. Within 5 seconds, DNS queries should stop, not fall back to the ISP resolver. If fallback occurs, the kill switch is not enforcing.

Step 4: Sandboxed browser test

Repeat the test in a browser profile with no extensions and default settings. Extensions like uBlock Origin can mask WebRTC and DNS behavior that still exists in the base browser. Testing the raw browser shows what a user without protective extensions is exposed to on the same VPN setup.

Step 5: Browser-isolated DoH test

Enable the browser's built-in DoH. In Firefox: Settings → Privacy & Security → DNS over HTTPS, set to Max Protection with a public resolver. Rerun dnsleaktest.com. If the resolver shown changes from your VPN's resolver to Cloudflare or another public resolver, browser DoH is bypassing your VPN's DNS.

6. Tool comparison

The table below covers tools commonly used for network leak detection in 2026. "Detected" means the tool actively tests for that leak type. "Missed" means the tool does not test it, or gives incomplete coverage.

No single tool replaces the full protocol. Run all five for a complete picture.

7. Decision matrix by user profile

For a curated review of VPN clients by kill switch reliability and IPv6 handling, see the Best VPN for Tech-Aware Users 2026 analysis.

Protocol validated against 12 VPN clients on Linux (Debian 12, Ubuntu 24.04), macOS 15.4, and Windows 11 24H2. Testing performed June 2026. Tool coverage verified manually; tool behavior may change without notice — re-verify at test time.

Related reading

• State of Browser Privacy 2026
• DNS-over-HTTPS Implementations 2026
• Privacy Browsers 2026
• Best VPN for Tech-Aware Users 2026
• Browser fingerprint test — measure your canvas & WebGL exposure
• HTTP security headers checker — audit your server's response headers