A VPN can protect DNS traffic only when the device sends those requests through the intended resolver and route. A client may say “Connected” while an operating system, browser, IPv6 connection, or split-tunnel rule sends some lookups elsewhere. A DNS leak test can help identify that mismatch, but the result needs context: seeing a resolver name you do not recognize is not, by itself, proof of a leak.
What a DNS leak test can tell you
DNS, or the Domain Name System, translates a domain name into information a device can use to connect to a service. When you visit a site, an app may ask a DNS resolver to look up its domain. A VPN connection can carry those requests through the tunnel to a resolver selected by the VPN service, or it may use another resolver according to the client, operating system, or browser settings.
A DNS leak occurs when DNS requests that you expect to travel through the VPN instead go through a network path outside it. This can reveal the resolver handling a lookup and, depending on the circumstances, information about the network or internet provider associated with that resolver. It is separate from the public IP address shown by an IP-check page. Checking both can give a more complete view of the connection, but neither test proves that every app handles traffic in the same way.
To test, connect the VPN, open a reputable DNS leak testing page in the browser you normally use, and run its standard test. Review the resolver names, organizations, and locations it reports. Then compare the result with a test taken while the VPN is disconnected. A changed result may be expected, but the display is an interpretation of observed requests, not a direct inspection of your VPN tunnel.
Resolver databases can be incomplete or out of date. A resolver may be operated by a third party, use a name associated with a different company, or appear to be in a location that does not match its physical infrastructure. Focus on whether requests appear to use the expected VPN-side resolver or your local internet provider’s resolver, and repeat the test before drawing a conclusion.
Reading the result: Compare the connected and disconnected tests, check the resolver organization as well as its displayed location, and treat one unfamiliar label as a clue to investigate—not a final diagnosis.
Check the whole connection, not just one browser result
Start with a simple, controlled test. Close other VPN or proxy applications, connect the client, wait until it reports an active connection, and open the DNS test in a private browser window. If the page offers more than one test mode, begin with its standard option. Some extended tests generate additional requests or take longer; use them only if the page explains what they measure.
Record the result without sharing sensitive account details. Note the browser, VPN state, network type, and resolver information shown. Then disconnect the VPN and run the same test again. Keeping the browser and test method the same makes the comparison more useful. If the resolver result changes in a way that matches the expected VPN route, that is reassuring, but it does not rule out a leak in another app or under another network condition.
For an additional check, use a second reputable test page or a different browser. Different pages may use different methods, and a browser can have its own DNS settings. A disagreement between tests does not automatically mean one is false; it may point to differences in browser configuration, cached results, or how the test detects resolvers. Clear the browser’s DNS cache where that option exists, close and reopen the browser, and repeat the comparison.
Also check your public IP address while connected. If the address appears to belong to your ordinary network, first verify that the client is connected and that the browser is not bypassing the VPN. A DNS test and an IP test answer different questions: the first observes name-resolution behavior, while the second reports the address used for a web request.
- ✅ Run the same DNS test with the VPN connected and disconnected.
- ✅ Compare resolver organization and network context, not only the displayed city or country.
- ✅ Repeat in another browser if the result is unexpected.
- ❌ Do not assume that a single test page can verify every application on the device.
Common causes of DNS exposure
IPv6 routing that does not match the VPN
Some networks and devices can use IPv4 and IPv6 at the same time. If the VPN protects IPv4 traffic but the device sends IPv6 traffic outside the tunnel, a test or app may still reach a resolver through the local connection. This depends on the VPN client, operating system, network, and configuration; the presence of IPv6 alone does not prove there is a leak.
Check the VPN client’s documentation for IPv6 support or an option to block IPv6 traffic when it is not routed through the tunnel. If the client provides a supported setting, use that rather than changing system networking blindly. Disabling IPv6 across the operating system may disrupt local services or other network functions, so treat it as a temporary diagnostic only when the client’s instructions recommend it. After any change, reconnect the VPN and repeat both DNS and IP checks.
Browser Secure DNS and encrypted DNS
Many browsers can use a DNS-over-HTTPS service, often labeled “Secure DNS” or “Use secure DNS.” This encrypts DNS queries between the browser and the selected resolver, but it does not automatically mean the requests use the VPN service’s resolver. The browser may send them to a resolver configured separately from the operating system. That can produce a different result from system-level DNS testing and may not match the privacy behavior you intended.
Review the browser’s Secure DNS setting and decide whether it should follow the operating system or use a chosen provider. If you select a provider, understand that the browser will send DNS requests to that provider. When diagnosing an unexpected result, temporarily returning the setting to its default or system-managed mode can help isolate the cause. Re-enable your preferred configuration after testing, then confirm the outcome.
Split tunneling, proxies, and overlapping network tools
Split tunneling can intentionally send selected apps or destinations outside the VPN. A browser excluded from the tunnel may use the local network’s resolver, even while other apps use the VPN. System proxies, security software, custom DNS utilities, and a second VPN can also affect routing or name resolution. Their effects differ by platform, so do not assume that changing the VPN server alone will correct the issue.
For diagnosis, disable only nonessential routing or proxy tools that you recognize and can safely restore. Check whether the test browser is included in the VPN route. Avoid running two VPN clients simultaneously: they may compete to manage routes, DNS settings, or virtual adapters. If an app is deliberately excluded, a local DNS result for that app may be consistent with the configured split-tunnel policy rather than a client malfunction.
Step-by-step: fix the likely cause and retest
Work from the least disruptive checks to the more specific settings. Change one thing at a time, keep track of what you changed, and repeat the same test after each adjustment. This makes it easier to identify the setting responsible for the result and to undo a change that causes another problem.
- Confirm the VPN session. Check that the client shows an active connection and has not paused or disconnected. Disconnect and reconnect using the client’s normal controls, then wait for its status to update.
- Remove competing routes temporarily. Quit any other VPN or proxy client. If you use split tunneling, make sure the browser used for testing is included in the VPN route. Restore your preferred exclusions after you have isolated the issue.
- Review DNS-related settings. Check the VPN client for DNS protection, custom DNS, or leak-prevention options and follow its instructions. In the browser, inspect Secure DNS. If it is set to a separate provider, test with the browser following the system setting, then compare results.
- Check IPv6 handling. Look for the client’s stated IPv6 behavior. If IPv6 is unsupported or not routed through the tunnel, use a documented client option to block it while connected, if available. Avoid making broad system changes without guidance.
- Refresh the test conditions. Close and reopen the browser, clear its DNS cache if the browser provides that control, and run the same test again. If the result remains unclear, test with another browser and note whether the behavior differs.
- Verify after reconnecting. Disconnect and reconnect the VPN after making a change. Check DNS and public IP results again, then test the apps you actually use. A browser result cannot establish how a separate game, messaging app, or system service routes its requests.
If you need to review the service’s client and setup guidance, VPNSR provides the starting point for its VPN information. Follow the instructions for your platform instead of importing settings intended for a different client. Keep subscription links and configuration details private; a DNS test does not require posting those credentials or sharing a full client screenshot.
Change one setting at a time. If a retest improves after a specific change, reconnect once more and verify that the result persists before treating the issue as resolved.
When a result needs more investigation
If the DNS test still shows a resolver associated with your local provider while the VPN is connected, repeat it after restarting the VPN client and browser. Check whether the browser is excluded from the tunnel, whether its Secure DNS setting selects another provider, and whether IPv6 is handled by the client. If possible, repeat on a different network. A result that follows one Wi-Fi network but not another may indicate a network-specific setting or route.
If only one browser reports the unexpected resolver, compare its DNS settings with another browser before changing the whole device. If several apps show different behavior, review split tunneling and system-level DNS settings. If every browser shows the same result across repeated tests, collect the test conditions and the non-sensitive resolver details, then consult the client’s documentation or support channel.
WebRTC checks are sometimes presented beside DNS tests, but they measure a different behavior related to browser communication features. A result shown by a WebRTC test should not be described as a DNS leak without identifying what the test actually observed. Likewise, a DNS result does not show whether a website’s account activity, cookies, or browser fingerprint can identify you.
Keep the limits in mind: DNS tests observe requests generated in particular test conditions. They cannot guarantee that every request from every app is routed as expected, and a normal result does not eliminate other privacy risks. Use them as one verification step alongside the VPN client’s status, routing settings, and the behavior of the apps you rely on.
Practical conclusion: A reliable check combines repeated DNS results, an IP check, and a review of IPv6, browser DNS, and split-tunnel settings. If those checks disagree, isolate the browser or network layer before changing system-wide settings.
DNS leak test FAQ
Does an unfamiliar resolver name mean my VPN is leaking DNS?
Not necessarily. Resolver ownership and location labels can be incomplete, and VPN services may use third-party DNS infrastructure. Compare the result with a disconnected test and check whether the resolver is associated with your ordinary internet provider. Repeat with another test page before deciding that the connection is exposed.
Should I turn off Secure DNS in my browser?
Not automatically. Secure DNS can encrypt browser queries to the provider you select, but that provider may differ from the VPN’s resolver. Review the browser’s setting and choose an arrangement that matches your needs. During troubleshooting, temporarily using the system-managed setting can help identify whether browser-level DNS is causing the difference.
Can a DNS test confirm that every app is protected?
No. A browser-based test observes requests made under its own conditions. Other apps may use different DNS methods, be excluded by split tunneling, or follow platform-specific network settings. Check the VPN client’s routing configuration and test the apps that matter to you.
How often should I repeat the test?
Repeat it when you change VPN or browser settings, switch networks, install another routing tool, or notice unexpected location or access behavior. There is no need to treat a single test as a permanent guarantee; use consistent conditions and investigate changes that persist across repeated checks.