DNS Leak Test: How to Check Your VPN Isn't Exposing Your Traffic
A DNS leak test takes about ten seconds to run, yet most people who use a VPN have never done it once. That gap matters: according to VPNTesting.com’s live leak-test data (June 2026), 8.2% of 471 tested connections showed at least one leak, and a separate audit spanning 74 VPN services found 15 of them — about 21% — leaking DNS traffic outright. If your VPN is one of them, your provider looks encrypted from the outside while your browsing history still lands on your ISP’s DNS logs.
What Actually Happens When You Type a URL
Every time you open a site, your device first asks a DNS resolver “what server does this name point to?” before it sends a single encrypted packet. A VPN is supposed to carry that question through the same tunnel as everything else. When it doesn’t, the DNS request slips out over your regular network connection — visible to your internet provider even though the rest of your traffic looks protected. This is the core reason DNS leak checks exist: encryption on the data doesn’t guarantee encryption on the lookup that precedes it.
The Three Leak Types: DNS, IPv6, and WebRTC
A “DNS leak test” on most sites actually checks three separate things:
- DNS leak — your device sends name-resolution queries to your ISP’s resolver instead of your VPN’s, revealing which sites you visit even if the content itself stays encrypted.
- IPv6 leak — many VPN apps tunnel IPv4 only. If your device also has a live IPv6 address, dual-stack websites can see your real IPv6 address running in parallel with the protected IPv4 one.
- WebRTC leak — browsers use STUN/TURN protocols for real-time features like video calls, and these can query your local network directly, exposing your actual public IP outside the VPN’s routing table entirely.
A single clean result isn’t proof of anything permanent. Leaks often reappear right when your laptop wakes from sleep, switches Wi-Fi networks, or the VPN briefly reconnects — test again after any of those events, not just once at setup.
How to Run a DNS Leak Test in 5 Minutes
- Disconnect your VPN and run a leak test to see your baseline — note the resolver name your ISP uses.
- Connect to your VPN and choose the server you’d normally use day to day.
- Open a private/incognito browser tab (this avoids cached DNS results skewing the test) and run the leak test again.
- Compare resolver ownership, not just the IP number — a leak test shows who operates each resolver, and it should match your VPN provider, not your home ISP.
- Run the extended test option if the site offers one; it fires several queries against different resolvers and catches leaks that a single quick check misses.
Why VPNs Leak in the First Place
DNS leaks are rarely intentional — they’re almost always a side effect of how operating systems and network stacks are built:
- Split-DNS misconfiguration: the OS routes app traffic through the tunnel but keeps resolving names on the original network adapter.
- The IPv6 blind spot: the VPN client only handles IPv4, so a dual-stack connection quietly leaks over IPv6 in the background.
- Browser-level WebRTC: real-time browser APIs can reach the local network directly, bypassing the system’s VPN routing rules.
- Network switching: laptops that hop between Wi-Fi networks sometimes briefly fall back to the previous network’s DNS before the VPN client catches up.
An older but still widely cited academic audit of Android VPN apps found that 84% leaked users’ real IP address under some condition, and 18% of the free apps tested didn’t encrypt traffic at all — a reminder that “has a VPN icon in the app store” and “actually protects your DNS queries” are two different claims.
What “Protected” Actually Looks Like
| Signal checked | Leak (bad) | Protected (good) |
|---|---|---|
| DNS resolver owner | Shows your ISP’s name | Shows your VPN provider’s resolver |
| IPv6 address | Same public IPv6 as before connecting | Not shown, or owned by the VPN |
| WebRTC IP | Your home/local public IP is visible | Only the VPN’s exit IP is visible |
| Consistency across retests | Different resolver owners each time | Same owner every single time |
How RunVPN Handles DNS Under the Hood
RunVPN routes DNS resolution through the same encrypted tunnel as the rest of your traffic, running on AmneziaWG by default or VLESS-Reality (XTLS-Vision on the Xray engine) for a stable connection that’s resistant to throttling and deep packet inspection. There’s no manual configuration step involved: you sign in with Google, email, or Telegram, tap connect, and the app fetches its setup automatically — nothing to import, no config files to paste. RunVPN does not store websites, DNS queries, traffic destinations, or traffic content; limited connection records are retained for 30 days., and one account covers up to 5 devices. Android is live today; iOS and desktop support is coming soon.
FAQ
Is a DNS leak the same thing as an IP leak? No. A DNS leak exposes which domain names you’re looking up, even if your actual browsing traffic stays encrypted. An IP leak (via IPv6 or WebRTC) exposes your real device address directly, which is a more complete exposure.
Can a DNS leak test give a false negative? Yes — a single quick test only fires one or two queries. Running the extended test option, and repeating the check after your device sleeps or switches networks, catches leaks that only appear under those conditions.
Do I need to test every time I connect? Not every session, but it’s worth checking after installing a new VPN app, after an OS update, and periodically on a device you rely on for anything sensitive — leak behavior can change silently after updates on either end.
Does using a VPN automatically protect against WebRTC leaks? Not always. WebRTC leaks depend on how the browser and VPN client interact at the network-routing level, which is a separate mechanism from DNS resolution — that’s why a full leak test checks both, not just one.
Want DNS handled inside the tunnel automatically, with no configuration to get wrong? Download RunVPN and see your connection status at runvpn.app/trust.