A VPN icon showing "connected" does not mean every lookup your device performs is actually passing through the encrypted tunnel. Domain-name resolution often travels along its own path, shaped by browser settings, operating-system defaults, and client configuration that may diverge from the rest of your traffic. When that happens, a resolver outside the VPN's intended route can see which domains you are querying, even if your browsing data itself stays encrypted.
This gap exists because DNS was never designed with privacy as a primary goal. The protocol is decades old, built for speed and reliability on a trusting network, not for concealment. Modern privacy tools have layered encryption and tunneling on top of that old foundation, but the seams between browser, system, and VPN client are exactly where leaks tend to appear. Anyone running a VPN across multiple devices should also think about whether every device needs its own app, since inconsistent configurations across a phone, laptop, and router are a common source of these mismatches.
What a Leak Test Actually Measures
A DNS leak test works by triggering lookups for test domains and reporting which resolvers answered them. If the VPN is supposed to handle DNS and the connected test still shows a resolver tied to your home network or internet provider, that is worth investigating. But the test has limits. It does not reveal your full browsing history, does not confirm identity exposure, and does not test IP leakage or browser-level tracking. A resolver's displayed name or country is also not definitive proof of ownership or location, since infrastructure is frequently shared or mislabeled. Treat a single result as a clue, not a verdict.
Reliable testing means comparing a disconnected baseline against a connected result, using the same browser and network each time, and repeating the connected test rather than trusting one run. Checking both IPv4 and IPv6 matters too, since many VPN configurations handle them differently, and a setup that looks secure on IPv4 can still expose IPv6 traffic.
Why the Leak Happens in the First Place
Several mechanisms can pull DNS traffic outside the tunnel. Browsers increasingly ship with encrypted DNS features of their own, sending queries directly to a provider the browser selected rather than through the system resolver the VPN expects to control. Operating systems may retain a cached or network-assigned resolver during a brief reconnection window. Some VPN clients offer split tunneling or custom DNS options that, if misconfigured, exclude DNS traffic from protections applied to everything else. None of this means the protocol itself - WireGuard, OpenVPN, IKEv2 - is to blame; the outcome depends on how the client routes and handles DNS, not the protocol's name.
Fixing It Without Breaking Something Else
The sensible approach is incremental: change one setting, then retest, rather than adjusting several things simultaneously. Check whether the browser's secure DNS feature is intentional and compatible with the VPN, review the client's DNS leak protection or "use VPN DNS" options, and confirm how IPv6 is handled. A kill switch can help during tunnel drops, but its coverage varies by platform and should not be treated as a guarantee against every leak, especially during network transitions like switching from Wi-Fi to mobile data.
None of this diminishes the value of a VPN as a privacy and security tool. It simply means that encryption of your traffic and protection of your DNS queries are related but separate guarantees, each requiring its own verification rather than blind trust in a single "connected" indicator.