VPN Leaks Explained: DNS, WebRTC, and IPv6 Leaks (and How to Actually Test for Them)

Your VPN app says Connected. That single word feels like a guarantee, but it only means your device has established an encrypted tunnel to the VPN server. It says nothing about whether every piece of identifying traffic is actually using that tunnel. Three common failure modes — DNS leaks, WebRTC leaks, and IPv6 leaks — can each expose your real IP address or browsing activity while the app sits there showing a reassuring green checkmark.

This guide does three things that single-leak, buy-this-VPN pages never do. First, it explains the actual mechanism behind each leak so you understand why a connected VPN can still betray you. Second, it walks you through a self-test using free, independent tools you don't have to trust a vendor for. Third, it gives you the exact fixes per operating system, browser, and router — and the re-test discipline that confirms the fix held. No brand pitch, no affiliate links, just the mechanics.

What a VPN leak actually is

A leak is any traffic that should travel through the encrypted tunnel but instead goes out over your normal internet connection, revealing information the VPN was supposed to hide. The three leaks in this guide expose two different things. A DNS leak reveals the websites you look up to your ISP (or whoever runs the resolver you're accidentally using). A WebRTC leak and an IPv6 leak can reveal your real IP address — your actual location and identity online — directly to websites you visit.

The most important thing to understand up front: these are separate problems with separate causes and separate fixes. Competitors bury this because it's inconvenient for a one-click sales narrative, but it's the whole game. You can plug a DNS leak and still leak your IP over WebRTC. You can harden WebRTC in your browser and still leak over IPv6. Closing one tells you nothing about the other two. That's why a real leak test checks all three, every time.

How each leak happens (the mechanism)

DNS leaks: lookups escaping the tunnel

Before your device loads example.com, it asks a DNS resolver to translate that name into an IP address. When the VPN is configured correctly, that DNS query travels inside the tunnel to a resolver the VPN controls. A DNS leak happens when the query instead goes to your ISP's resolver (or a resolver pushed by your router) over the open connection. Even though the page content may still flow through the tunnel, the lookup itself reveals every domain you visit to a third party — and ties it to your real IP.

The usual culprits are an operating system that ignores the VPN's DNS settings, a hardcoded resolver (such as a manually set 8.8.8.8 or 1.1.1.1) that bypasses the tunnel, or split-tunnel rules that route DNS outside the VPN. On Windows specifically, a feature called smart multi-homed name resolution can fire DNS queries out of every network interface at once and use whichever answers first — frequently your ISP's.

WebRTC leaks: the browser handing out your IP

WebRTC (Web Real-Time Communication) is the browser technology behind in-page video calls, voice chat, and peer-to-peer file transfer. To connect two peers directly, WebRTC needs to discover the device's own IP addresses. It does this with STUN servers, which reply to the browser with the public IP they see, and it also enumerates local network addresses. A web page can read these ICE candidates through a JavaScript API — without any permission prompt and without you clicking anything.

Here's the catch that makes WebRTC dangerous even with a working VPN: this discovery can happen outside the proxy path your browser uses for normal page loads. The page can end up seeing the public IP your operating system considers real, which may be your true address rather than the VPN's. A WebRTC leak is a browser problem. It is not fixed by your VPN's DNS settings or its kill switch, which is exactly why people who fixed their DNS leak are stunned to find their IP still showing.

IPv6 leaks: traffic on a road the tunnel never paved

Many VPN tunnels carry only IPv4 traffic. If your ISP and home network also provide IPv6 connectivity — increasingly the default — then any request to an IPv6-capable destination can travel over your native IPv6 connection, completely outside the IPv4-only tunnel. The website sees your real IPv6 address. The VPN never touched that traffic and often never even noticed it, because it was only ever watching the IPv4 side.

This is why an IPv6 leak is so quietly common: nothing breaks, nothing looks wrong, and the VPN reports success. The fix is either to disable IPv6 on the device or network, or to use a VPN that explicitly tunnels IPv6 or blocks it while connected. Hoping your provider handles it silently is not a strategy — you test for it.

Run the test: free tools and how to read them

Use independent, third-party tools rather than the 'your IP is hidden' page your VPN provider shows you — a vendor has every incentive to report success. Do every test with the VPN connected, in the same browser and on the same device you actually use. As a baseline, it's worth running them once with the VPN off first so you know what your real IP and ISP look like; then turn the VPN on and confirm those values disappear.

Step 1 — DNS leak test

Open dnsleaktest.com and run the Extended test. It loads a series of unique hostnames and reports which DNS servers resolved them. A clean result shows resolvers belonging to your VPN provider (or a privacy resolver the VPN uses), and crucially does not list your ISP's name or your home country if you connected to a server elsewhere. A leaking result shows your ISP's resolver, or servers in your real location that you didn't expect. ipleak.net shows the same DNS information alongside your IP, which is handy for cross-checking.

Step 2 — WebRTC leak test

Open browserleaks.com/webrtc. Look at the Public IP Address it discovers via WebRTC. A clean result shows either no public IP, or only the VPN server's IP. A leaking result shows your real public IP in the WebRTC section even though the page header (which uses a normal HTTP request) shows the VPN IP — that mismatch is the classic WebRTC leak signature. Local addresses in the 10.x, 172.16–31.x, 192.168.x, or .local mDNS ranges are generally harmless; the real danger is your genuine public IP appearing.

Step 3 — IPv6 and overall IP test

Open ipleak.net. It shows your IPv4 address, any IPv6 address, and your DNS servers on one page. A clean result shows only the VPN's IP (matching the country you chose) and either no IPv6 address or an IPv6 that also belongs to the VPN. A leaking result shows an IPv6 address from your ISP, or an IPv4/IPv6 pair pointing to two different locations. If you see a real IPv6 alongside a VPN IPv4, that is a textbook IPv6 leak.

A VPN that hides your IPv4 but exposes your IPv6 hasn't half-protected you — to any IPv6-aware site, you're simply not using a VPN at all.

The exact fixes, per OS, browser, and router

Fix DNS leaks

• In the VPN app: enable any 'Use VPN DNS only', 'DNS leak protection', or 'block non-VPN DNS' option. Many apps have this on by default, but third-party OpenVPN/WireGuard configs often don't.

• Windows: disable smart multi-homed name resolution, which scatters DNS across interfaces. On Windows Pro you can set the Group Policy 'Turn off smart multi-homed name resolution' to Enabled; otherwise prefer a VPN client that sets DNS and blocks other resolvers. Remove any manually configured public DNS (8.8.8.8, 1.1.1.1) from your adapters while testing.

• macOS / Linux: ensure no resolver is hardcoded in network settings or /etc/resolv.conf that bypasses the tunnel; let the VPN client manage DNS. On Linux with systemd-resolved, confirm the VPN sets a domain route so queries go to its resolver.

• Router: if you run the VPN on the router, set the router's DNS to the VPN's resolver and disable any ISP-assigned DNS. Also disable router features that intercept or redirect DNS (some 'parental control' or 'DNS rebind protection' settings).

Fix WebRTC leaks (browser only)

• Firefox: type about:config in the address bar, accept the warning, search for media.peerconnection.enabled, and set it to false. This disables WebRTC entirely. If you need WebRTC for calls, leave it on but rely on a VPN/extension that masks the discovered IP, and re-test.

• Chrome / Edge: there is no built-in toggle to fully disable WebRTC. Be aware that uBlock Origin's old 'Prevent WebRTC from leaking local IP addresses' option was removed from the desktop extension back in 2021, and even when it existed it only masked local/LAN addresses — it never stopped the public-IP disclosure that actually exposes you, so it was never the fix people assumed. Modern Chromium already obfuscates local IPs using mDNS (you can confirm the 'Anonymize local IPs exposed by WebRTC' flag at chrome://flags). To control public-IP exposure, use a dedicated WebRTC-control extension and then verify on a leak test, since extensions vary in how completely they block it.

• Safari: WebRTC exposure is more limited by default, but still test. You can disable it via the Develop menu's experimental/WebRTC features if you don't need it.

• Reality check: disabling WebRTC can break Google Meet, Discord-in-browser, Jitsi, and similar tools. If you need those, the practical path is a browser/extension that hands out only the VPN IP rather than killing WebRTC outright — confirmed by re-testing.

Fix IPv6 leaks

• Best option: use a VPN that explicitly offers IPv6 leak protection (it blocks or tunnels IPv6 while connected). Turn that setting on and re-test.

• Windows: disable IPv6 on the active adapter (Network adapter Properties, uncheck Internet Protocol Version 6), or use the VPN's IPv6 blocking. Re-enable it when you stop using a VPN that can't handle it.

• macOS: in System Settings, set the network service's Configure IPv6 to Link-local only (or Off via the command line) if your VPN can't tunnel it.

• Linux: disable IPv6 per-interface or system-wide via sysctl (for example net.ipv6.conf.all.disable_ipv6=1) if the tunnel is IPv4-only.

• Router: if you run the VPN at the router, disable the router's IPv6/WAN IPv6 so no device on the network can leak over it. This is the cleanest fix for a whole household.

Why a 'connected' VPN still leaks

Even after you've passed all three tests once, the protection is not permanent — it's a state that can silently break. These are the moments where a 'connected' VPN quietly starts leaking:

• Network changes: moving from Wi-Fi to Ethernet, switching access points, or your phone flipping between Wi-Fi and cellular can momentarily route traffic outside the tunnel before the VPN re-establishes its rules.

• Sleep and wake: when a laptop wakes from sleep, the network often comes back before the VPN reconnects. For a few seconds, traffic uses the bare connection — long enough for background apps to phone home with your real IP.

• Reconnects and drops: any time the tunnel drops and re-dials, there's a window where traffic can escape unless a kill switch blocks it.

• Captive portals: hotel, airport, and cafe Wi-Fi require you to load a login page before internet works. That page loads outside the VPN by design, and some setups stay leaky until you manually reconnect afterward.

• Split tunneling: if you've excluded certain apps — or DNS — from the VPN, those exclusions are leaks by configuration. Double-check that DNS isn't quietly in the 'bypass' list.

• IPv6 coming back: an OS update or network reset can silently re-enable IPv6 you previously disabled, reopening that path without warning.

Kill switches and leak-protection settings — and how they fail silently

A kill switch is a safety net for the drop-and-reconnect problem: when the tunnel goes down, it blocks all internet traffic until the VPN is back, so nothing escapes in the gap. Built-in leak protection (DNS leak protection, IPv6 blocking, network-lock features) enforces that DNS and IPv6 only ever use the tunnel. Turn both on — they handle the failure windows you can't watch manually.

But understand their silent failure modes. A kill switch only acts when the app detects the tunnel is down; if the tunnel is technically up but DNS or IPv6 is leaking around it, the kill switch sees no problem and does nothing. App-level kill switches only protect the VPN app's own traffic, not the whole system. Some kill switches don't engage during the sleep/wake window or before login on boot. And a 'firewall-style' kill switch that fully blocks traffic when off can be confused for an internet outage, tempting people to disable it. The lesson: a kill switch reduces risk, it does not replace testing. The only proof your settings work is a passing test.

Benign result vs. genuine privacy failure

Not every unfamiliar entry on a leak-test page is a disaster. Knowing the difference keeps you from chasing ghosts — or ignoring a real exposure.

• Benign: WebRTC showing only local/private addresses (10.x, 172.16–31.x, 192.168.x) or an mDNS .local hostname. These don't identify you to a website.

• Benign: DNS resolvers that belong to your VPN provider or a privacy resolver it uses, even if they're in a different city than your VPN server — providers run resolver fleets.

• Benign: no IPv6 address at all when you've disabled IPv6. That's the goal, not a failure.

• Genuine failure: any test showing your real public IP (IPv4 or IPv6), your real city/ISP, or your home country when you deliberately connected elsewhere.

• Genuine failure: DNS results naming your actual ISP, or an IPv4 and IPv6 that resolve to two different locations.

• Genuine failure: the page header showing the VPN IP while the WebRTC section shows your real one — the mismatch is the leak.

Rule of thumb: a public IP or your ISP's name appearing where it shouldn't is a real failure. Private/local addresses and provider-owned resolvers are noise.

Re-test discipline: the habit that actually protects you

A leak test is a snapshot, not a certificate. Because the protective state breaks at network changes, sleeps, reconnects, and captive portals, the test is only meaningful for the conditions you tested under. Build the habit:

1. Re-test after every fix — change one setting, then confirm that specific leak is closed before moving on. Fixing all three at once and testing once hides which change worked.

2. Re-test after every network change — new Wi-Fi, switching to cellular, plugging in Ethernet, or after a captive-portal login.

3. Re-test after waking from sleep and after a VPN reconnect, since those are the highest-risk windows.

4. Re-test after OS and app updates, which can quietly re-enable IPv6 or reset DNS behavior.

5. Run all three tests together each time — DNS, WebRTC, and IPv6 are independent, and a clean result on one tells you nothing about the others.

Practical takeaway

'Connected' is a starting point, not proof of privacy. Test all three leaks with independent tools — dnsleaktest.com for DNS, browserleaks.com/webrtc for WebRTC, and ipleak.net for IPv6 and your overall IP. Treat them as separate problems: force VPN DNS at the OS or router, neutralize WebRTC in the browser, and block or tunnel IPv6. Turn on your kill switch and built-in leak protection for the gaps you can't watch, but never trust them blindly. Then re-test after every fix and every network change. Ten minutes of testing tells you more about your real exposure than any provider's marketing page ever will.

Frequently Asked Questions

What is a VPN leak test and how do I run one?

A VPN leak test checks whether any traffic is escaping your encrypted tunnel and exposing your real IP address or DNS lookups while the VPN is connected. Run one by connecting your VPN, then visiting independent tools like dnsleaktest.com, browserleaks.com/webrtc, and ipleak.net. If any of them show your real public IP, your ISP, or your home location, you have a leak.

How does a DNS leak test work and what counts as a pass?

A DNS leak test loads unique hostnames and reports which DNS servers resolved them. You pass if the resolvers belong to your VPN provider and your own ISP is not listed. You fail if your ISP's resolver appears or the servers are in your real location when you connected somewhere else.

How do I fix a DNS leak?

First enable 'DNS leak protection' or 'use VPN DNS only' in your VPN app. On Windows, also disable smart multi-homed name resolution and remove any manually set public DNS like 8.8.8.8 from your adapter. On a router running the VPN, point the router's DNS at the VPN resolver and disable ISP-assigned DNS, then re-test.

What is a WebRTC leak and does my VPN stop it?

A WebRTC leak is when your browser's real-time communication feature discovers and exposes your real IP address to a web page, even with the VPN connected. Most VPNs do not stop it because it's a browser behavior, not a network one. Fix it in Firefox by setting media.peerconnection.enabled to false in about:config. Chrome and Edge have no built-in switch to disable WebRTC, so use a dedicated WebRTC-control extension and re-test — don't rely on uBlock Origin's old local-IP toggle, which was removed from the desktop extension and never blocked public-IP exposure anyway.

What is an IPv6 leak and how do I prevent it on my VPN?

An IPv6 leak happens when your IPv4-only VPN tunnel ignores IPv6 traffic, letting it travel over your ISP connection and expose your real IPv6 address. Prevent it by enabling IPv6 leak protection in your VPN, or by disabling IPv6 on your device or router. After changing the setting, confirm on ipleak.net that no ISP IPv6 address appears.

Does a kill switch prevent DNS and WebRTC leaks?

Not reliably. A kill switch only blocks traffic when it detects the tunnel has dropped, so it does nothing about DNS or WebRTC leaks that occur while the tunnel is still up. You need separate DNS leak protection and browser-side WebRTC hardening, with the kill switch as a backstop for reconnects and drops.

How often should I run a VPN leak test?

Test after every configuration change, and re-test after every network change, sleep/wake cycle, VPN reconnect, captive-portal login, and major OS or app update. Each of those moments can silently reopen a leak. Always run all three tests together, since DNS, WebRTC, and IPv6 are independent problems.