VPN DNS leaks, WebRTC and IPv6 leaks: how to test

A VPN leaks when some of your traffic goes around the tunnel instead of through it. The three leaks worth testing for are DNS (your lookups still go to your ISP or the local network's resolver), IPv6 (the tunnel carries IPv4 while your device happily uses its own IPv6 address) and WebRTC (a browser reveals an address through the calls and peer-to-peer feature it uses for video). Testing takes five minutes: connect, open a DNS leak test and run the extended check, open an IPv6 test page, open a WebRTC test page, and look for anything that belongs to your own network. If something does, the fix is almost always a client setting, not a new VPN.

The detail matters, because "my DNS leak test shows Google" is not a leak, while "my browser works but my game does not use the tunnel" is one, and the tests only help if you know what you are looking at.

What a leak is and why it matters#

When you type a name into a browser, your device asks a DNS resolver for its address. Whoever runs that resolver gets a list of every name you look up, with times, and whoever sits on the path to it can read and alter the queries unless they are encrypted. Without a VPN, that resolver is normally your ISP's or the one the local network hands out.

A full-tunnel VPN should send those queries through the tunnel to a resolver at the far end. A DNS leak is the case where the tunnel is up, your browsing goes through it, and the lookups still go to the local resolver. The pages are hidden; the list of what you visited is not.

IPv6 and WebRTC leaks are worse in one respect: they reveal your real address, not just your lookups. That matters if the point of the VPN was to keep a service from seeing where you are connecting from.

How DNS leaks happen#

The operating system asks every resolver it knows. Windows, since Windows 8, uses smart multi-homed name resolution: it can send a query out through every network adapter and take the first answer. With a VPN adapter and a wifi adapter both up, that sends your lookups to the wifi network's resolver as well as the tunnel's. OpenVPN's block-outside-dns option exists precisely to stop this, by adding firewall rules that drop DNS on other adapters while the tunnel is up.

The client is a proxy, not a VPN. Many VLESS clients on desktop default to a system proxy mode. An application that honours the proxy sends the hostname to the proxy, which resolves it at the far end - no leak. An application that ignores the proxy resolves the name locally and connects directly. Both its DNS and its traffic leak, which is a bigger problem than a DNS leak.

IPv6 resolvers. On a dual-stack network your device learns IPv6 resolvers from router advertisements. If the VPN only reconfigures IPv4 DNS, queries can go to the IPv6 resolver of the local network.

Encrypted DNS configured on the device. Android's Private DNS setting, or secure DNS in a browser, sends queries to the provider you chose. Inside a full tunnel those encrypted queries travel through the tunnel and reveal nothing to the local network; the provider still sees them. In a split or proxy setup they may go direct.

Cached answers and early lookups. Names looked up before the VPN connected stay in the cache, and apps that start syncing the moment a network appears do their lookups before the tunnel is up. That is a timing leak, and it is what a kill switch addresses.

How proxy clients handle DNS#

Xray-based clients have more moving parts than a WireGuard app, so it helps to know the modes.

In SOCKS mode, Firefox has a specific setting, "Proxy DNS when using SOCKS v5", in its connection settings; with it off, Firefox resolves names locally and only the connections go through the proxy. Chrome sends hostnames to a SOCKS5 proxy for remote resolution by default.

In VPN or TUN mode, clients built on sing-box or Xray intercept DNS on the virtual interface. Some use a "fake IP" scheme: the client answers each lookup instantly with a placeholder address from a reserved range such as 198.18.0.0/15, then resolves the real name at the server when the connection is made. If you see addresses in that range in nslookup output while connected, that is the client working as designed, not a fault.

The clients also have DNS settings of their own - a remote DNS used for traffic through the tunnel and a direct DNS used for traffic routed around it. The remote one should be a resolver reached through the server. If you have set up rules that send local sites direct, their lookups going to your local resolver is expected; split tunnelling explained covers how routing and DNS rules interact.

Testing for DNS leaks#

Connect the VPN, then use any of the well-known test sites - dnsleaktest.com, browserleaks.com or ipleak.net. They work by making your browser look up a series of random, unique names under a domain they control and recording which resolvers ask their authoritative servers for them.

What to look for in the results:

• Good: resolvers in the VPN server's country or belonging to a public resolver (Google, Cloudflare, Quad9) that your client is configured to use through the tunnel.
• Leak: any resolver operated by your home ISP, your mobile carrier or the hotel network, or any resolver in your own country when the server is somewhere else.

Run the extended test, not the standard one. The standard test makes a handful of lookups and can miss an adapter that only answers sometimes, which is exactly how Windows multi-homed resolution behaves.

You can do the same from a terminal. Several DNS operators answer a special name with the address of the resolver that asked:

$ dig +short whoami.akamai.net$ dig +short TXT o-o.myaddr.l.google.com

On Windows without dig:

nslookup whoami.akamai.net

The address printed is the resolver's outgoing address as Akamai or Google saw it. It should belong to the VPN's side, not your ISP's. This also tests applications other than the browser, because it uses the system resolver.

IPv6 leaks#

Many VPN setups carry only IPv4. If your network gives your device an IPv6 address and the tunnel does nothing about IPv6, every site reachable over IPv6 is reached directly, with your real address, while IPv4 sites go through the tunnel. Google, Facebook, Netflix, Cloudflare-fronted sites and much of the big web are reachable over IPv6, so this is not a corner case.

Test it with an IPv6 test page (test-ipv6.com is the standard one) or from a terminal:

$ curl -4 https://ifconfig.me   # should print the VPN server's address$ curl -6 https://ifconfig.me   # should fail, or print an address not your own

The fixes, in order of preference:

1. A client that routes IPv6 into the tunnel. A VPN that has IPv6 at the far end carries it; one that does not should still capture ::/0 and drop it, so applications fall back to IPv4 through the tunnel.
2. A client setting for IPv6. Several VLESS clients have an option controlling whether IPv6 is used; set it so IPv6 is either tunnelled or blocked.
3. Turning off IPv6 on the adapter you use with the VPN. On Windows, untick Internet Protocol Version 6 (TCP/IPv6) in the network adapter's properties. Crude, but effective, and easy to undo.

IPv6 and game servers has more on how dual-stack networks pick between the two.

WebRTC leaks#

WebRTC is what browsers use for video calls and peer-to-peer connections. To set up a call, the browser gathers candidate addresses: its local ones, and its public one as seen by a STUN server. A web page can trigger that gathering with a few lines of JavaScript and read the results, without a call ever being made.

Modern browsers hide the local addresses behind random .local names (mDNS), so the old trick of reading your private 192.168.x.x address mostly no longer works. The public candidate is still there. With a full-tunnel VPN, the STUN request goes through the tunnel and reports the VPN server's address, which is fine. The leak happens when the STUN request does not go through the tunnel: in proxy mode, because WebRTC uses UDP and often ignores the proxy, or over IPv6 that bypasses the tunnel.

Test with browserleaks.com's WebRTC page or ipleak.net while connected. If your real public address appears, fix the cause (use VPN mode rather than proxy mode, close the IPv6 gap) or restrict WebRTC in the browser:

Disabling WebRTC breaks in-browser video calls. Restricting the handling policy is a gentler middle ground.

A five-minute test routine#

Do this once per device, after any client update, and on any new network you plan to rely on.

1. Disconnect the VPN and note your real public IPv4 and IPv6 addresses and your ISP's resolver from a leak test page.
2. Connect the VPN.
3. Run the extended DNS leak test. No ISP or local-network resolvers.
4. Run the IPv6 test. Either no IPv6, or not your real one.
5. Run the WebRTC test. No real public address.
6. From a terminal, run dig +short whoami.akamai.net to check the system resolver too.
7. Open an application that is not a browser - a game launcher, a mail client - and check that it works with the VPN on. If it stops working in proxy mode, it was never using the proxy.

On Windows, after changing settings, flush the cache so old answers do not confuse the result:

ipconfig /flushdns

Fixes by platform#

VPN kill switch and always-on covers the timing leaks - what slips out while the VPN reconnects - which a leak test taken at a quiet moment will never show.

Leaks and a private server#

On a private server you run, the "resolver at the far end" is whatever your server uses, and the address sites see is your server's. On RE:NODE's private VPN line, the server runs Xray with VLESS and Reality, has its own address and key with nobody else on it, and is in Germany - so a correct test result shows a German address and no resolvers from your own ISP. The Windows Renode VPN app connects with the link the server prints; on phones and Macs the same link goes into v2rayNG, Hiddify, Streisand or Shadowrocket, and the leak tests above apply to each of them in the same way. The VLESS client setup guide covers the modes in each client.

FAQ#

My DNS leak test shows Cloudflare or Google resolvers. Is that a leak?

Not by itself. It is a leak if those resolvers are reached directly from your network instead of through the tunnel. If the test shows them in the VPN server's region, or your client is configured to use them as its remote DNS, that is the tunnel working.

Can a website see my real IP through WebRTC with a VPN on?

Only if WebRTC's traffic bypasses the tunnel, which happens in proxy-only modes and with untunnelled IPv6. With a full tunnel the address it finds is the VPN server's. Test it rather than assuming.

Does encrypted DNS replace the need to check for leaks?

No. Encrypted DNS hides the content of lookups from the local network, but if it goes around the tunnel it still reveals your real address to the DNS provider, and it does nothing for IPv6 or WebRTC. Test with it on.

Why does my leak test pass at home and fail in a hotel?

Different networks hand out different resolvers and different IPv6 setups. A hotel with IPv6 exposes an IPv6 leak your IPv4-only home network never showed. Test on each network you depend on.

Should I just turn IPv6 off everywhere?

Only on the devices and adapters where your VPN cannot handle it. IPv6 is not the problem; a tunnel that ignores it is. A client that captures or blocks IPv6 inside the tunnel is the cleaner fix.