A VPN can be connected, showing a green tick, reporting a foreign IP address — and still be telling your internet provider every website you visit. That is what a DNS leak is, and it is the single most common reason a subscription quietly does nothing.
Here is how to test properly, on each platform, and how to fix what you find.
The three leaks worth testing
- DNS leak. Your traffic goes through the tunnel, but the lookups that translate example.com into an address go to your ISP’s resolver. They see every domain you visit, in order, with timestamps.
- IPv6 leak. Your tunnel carries IPv4 only, your connection also has IPv6, and IPv6-capable sites are reached directly — outside the tunnel, with your real address.
- WebRTC leak. A browser feature for video calls asks your operating system for local and public addresses and hands them to any page that asks. It bypasses the tunnel entirely because it happens above it.
How to test in five minutes
- Record your baseline. With the VPN off, note your IP address and which DNS resolvers appear on a leak-test site. This is what a leak looks like.
- Connect the VPN, then reload the same test. The IP should change and every resolver listed should belong to the VPN, not your ISP.
- Run an extended test, which performs many lookups rather than one — intermittent leaks only show up across a larger sample.
- Check IPv6 separately. If a test reports an IPv6 address that is not your provider’s, that traffic is outside the tunnel.
- Check WebRTC in every browser you use. Results differ between Chrome, Firefox and Safari on the same machine.
- Repeat after failure. Disable your network adapter for ten seconds mid-test and re-check when it returns. Leaks appear during reconnection far more often than during steady state.
Testing once, on one browser, on one device, tells you almost nothing. Leaks are a reconnection and a per-platform problem.
Fixing a DNS leak
- Use the provider’s own app rather than the operating system’s built-in VPN client where possible — the OS clients frequently ignore pushed DNS settings.
- Set DNS explicitly. In a WireGuard profile that means a
DNS =line in the[Interface]section; without it, nothing changes your resolver. - Windows: disable “Smart Multi-Homed Name Resolution”, which deliberately queries every adapter at once and is a leak by design.
- Browser DNS-over-HTTPS can override system settings in both directions. Decide deliberately whether it is on, and test the result.
Fixing an IPv6 leak
Two acceptable outcomes: the tunnel carries IPv6 properly, or IPv6 is disabled on the device while the VPN is connected. Anything in between leaks. If your provider does not support IPv6 and does not block it, that is a serious deficiency, not a minor one — and worth switching over.
Fixing a WebRTC leak
In Firefox, set media.peerconnection.enabled to false in about:config if you do not use browser video calls. In Chromium browsers, use a reputable WebRTC-limiting extension, since there is no built-in switch. Retest afterwards — some extensions only mask the local address and still expose the public one.
Kill switches: test them, do not trust them
A kill switch is supposed to block all traffic if the tunnel drops. Many implementations only react to the VPN process exiting, not to the tunnel silently failing while the process keeps running.
Test it honestly: start a large download through the tunnel, then kill the network interface or the VPN process without a clean disconnect. If the download continues for even a few seconds after the tunnel is gone, traffic escaped, and it will escape again on every unstable connection.
Build it into a routine
Test on installation, after any operating-system update, after any VPN client update, and whenever you add a device. It takes five minutes and it is the only way to know that the thing you are paying for is doing the job.
If you would rather not depend on a provider’s implementation at all, our self-hosted WireGuard guide sets DNS explicitly and leaves nothing to guess.