A DNS leak test checks which DNS resolvers appear to handle name lookups while your VPN is connected. It can help identify a routing or configuration mismatch, but a single result is not a complete privacy audit. Resolver names may be unfamiliar, browser features can use a separate DNS path, and a test page can only observe the requests it can trigger. To interpret the result, compare it with your normal connection, check the browser and device settings that affect DNS, and repeat the test after changing one thing at a time.
Bottom line: Look for a consistent difference between the VPN-off and VPN-on tests, then investigate any resolver that appears unexpectedly. A result showing your VPN provider’s resolver is not proof that every app uses the VPN, and a resolver with an unfamiliar name is not automatically evidence of a leak.
What a DNS leak test can and cannot show
DNS, or the Domain Name System, helps translate a domain name such as an example website address into information a device can use to connect. A lookup may be handled by a resolver selected by your operating system, router, internet provider, VPN app, browser, or another network service. Which resolver is used depends on the device, software, network, and settings.
A browser-based test typically asks your browser to make requests to domains controlled by the test service. The service then reports the public addresses or resolver information it observes for those lookups. The result can help reveal whether DNS requests appear to use the expected path, but it does not inspect every connection made by every application. A browser test cannot by itself confirm that mail, games, command-line tools, background services, or another browser profile use the same DNS configuration.
Also distinguish a DNS resolver from your VPN exit address. A resolver handles name lookups; an exit address is the public address websites may see for other traffic. The two can belong to different organizations without that difference alone proving a problem. Some resolvers use shared infrastructure or anycast, where a single service address may be handled at different locations. Test pages may identify a provider by network ownership or database records, and those labels can be incomplete or out of date.
When a test shows an internet provider’s resolver while the VPN is active, treat it as a reason to investigate. It may indicate that DNS is taking a route outside the tunnel, but first rule out a browser’s independent encrypted-DNS setting, a stale test result, or a resolver that is being identified imprecisely. Conversely, seeing a VPN-associated resolver does not prove that all traffic is protected or that your device has no other privacy issues.
Compare results before changing settings
Start with a baseline. On the same device and in the same browser, run a reputable DNS test with the VPN disconnected, note what it reports, and then connect the VPN and run the test again. If possible, keep the network unchanged between these checks. Switching from home Wi-Fi to mobile data at the same time as connecting the VPN makes it harder to tell which change affected the result.
Record the resolver names or addresses shown, the VPN connection state, the browser used, and whether a secure-DNS feature is enabled. Do not assume that a test result is meaningful just because it displays many entries. Some test sites generate multiple lookups to make resolver discovery easier; the number of entries is not a security score. If the page reports only a provider name, look for the resolver addresses and test details before drawing conclusions.
The result may be different across browsers or networks. That is useful information, not necessarily a contradiction: browsers can have separate DNS settings, and networks can provide different default resolvers. Run the test more than once after allowing the page to finish, then compare patterns rather than relying on one transient entry. Avoid entering account credentials or other sensitive information on an unfamiliar test site; an ordinary DNS test should not need them.
| Observation | Possible explanation | Next check |
|---|---|---|
| The resolver differs with the VPN connected | The VPN may be directing DNS to a different resolver, or the network path may have changed | Compare the VPN-on and VPN-off results on the same browser and network |
| An internet provider appears during the VPN test | A DNS request may be using the network’s default resolver, or the test may be identifying shared infrastructure | Check browser secure-DNS settings, VPN DNS options, and repeat the test |
| Different browsers show different resolvers | Browser-specific secure DNS or proxy settings may be in use | Review each browser’s DNS and proxy configuration separately |
| No unexpected resolver appears | The test’s lookups followed an expected path at that time | Check the apps and networks you actually use; the result does not cover every connection |
Check the browser and device settings
Before changing VPN settings, check whether the browser is using its own secure DNS, sometimes called DNS over HTTPS. This feature sends DNS lookups to a chosen provider through an encrypted HTTPS connection. Encryption protects the lookup between the browser and that resolver, but it does not automatically mean the lookup uses the VPN’s DNS service. Depending on the browser and system configuration, secure DNS can use a different resolver or route than the operating system.
Review the browser’s privacy or security settings for secure DNS, encrypted DNS, or a custom DNS provider. Names and menu locations vary by browser version. If you intentionally use a browser-specific provider, decide whether that is consistent with your privacy requirements; do not disable it merely because its name differs from the VPN provider. If you change the setting for diagnosis, note its original state so you can restore it if needed.
Next, check the VPN app for options related to DNS, leak protection, or routing. Some clients offer a choice of DNS behavior, while others manage it automatically. Use the app’s own documentation for the current version rather than copying a setting intended for a different client or protocol. A custom DNS address entered in the wrong field may have no effect, and manually forcing a resolver can cause failures on networks that require their own configuration.
Operating systems also differ. Windows, macOS, Android, iOS, and Linux provide different ways for applications and network interfaces to select DNS. Some devices can have multiple active network interfaces, such as Wi-Fi and mobile data; a change in the preferred interface can affect lookups. On Linux, local resolver managers and network tools may control DNS independently of the VPN application. On mobile devices, a private-DNS feature, configuration profile, or another VPN-style app may also influence the result. Check the active settings and app permissions on your own device rather than assuming that one operating system’s steps apply to another.
For a general overview of the service and its available platforms, see Q8VPN. For DNS troubleshooting, however, prioritize the settings and documentation for the specific operating system, browser, and client you are testing.
Step-by-step: test, change, and verify
Use a controlled sequence so you can identify which setting makes a difference. The following workflow applies to desktop and mobile devices, although the names of controls vary. If the device is managed by an employer, school, or another administrator, do not override its network policy without permission.
- Choose one test environment. Select a device, browser, and network. Close other VPN or proxy apps that could change routing, unless you need to test their interaction specifically. Note any browser secure-DNS setting that is already enabled.
- Run a disconnected baseline. Disconnect the VPN and use a browser-based DNS test. Record the resolver information and the browser setting. This shows what the device appears to use on that network without the VPN; it is a comparison point, not a privacy rating.
- Connect the VPN and repeat. Wait for the client to report a connection, then reload the same test page. Compare the resolver information with the baseline. If the VPN changes the network, allow the connection to settle before interpreting the result.
- Check for conflicting DNS controls. Review browser secure DNS, system private-DNS options, manually configured network DNS, and any other proxy or VPN software. Change only one setting at a time. If you are unsure what a setting does, note it and consult the relevant device or client documentation before changing it.
- Retest after each change. Keep the browser, test page, and network the same. If the result changes, repeat the test to see whether the behavior is consistent. Restore settings that were unrelated to the problem rather than leaving diagnostic changes in place without understanding them.
- Check the apps that matter. A browser test only exercises the browser’s requests. If a particular application is important, check its own connection behavior and any proxy or DNS controls it provides. For command-line programs, remember that their network configuration may differ from the browser’s.
If an unexpected resolver remains, disconnect and reconnect the VPN, then check for client updates and review the provider’s current guidance. You can also test on another trusted network to determine whether the behavior is tied to a particular router or access point. Do not install unknown certificates, configuration profiles, or “DNS repair” utilities to make a test result look different. If you cannot identify the cause, save the relevant settings and test observations and contact the VPN provider or device administrator for help.
- ✅ Compare VPN-off and VPN-on results on the same device, browser, and network.
- ✅ Treat an unexpected resolver as a clue to investigate, not as proof of a specific cause.
- ✅ Change one DNS or browser setting at a time and retest before making another change.
- ❌ Do not assume a browser result covers every application or every network connection.
- ❌ Do not enter credentials or install unknown software on a DNS test page’s instructions alone.
Common causes and practical responses
An apparent leak can have several causes. A browser may use its own encrypted-DNS provider; the VPN client may be set to allow local DNS; a second network tool may be active; or the device may have manually configured DNS that takes precedence in a particular situation. A VPN connection can also be interrupted or reconnect while the browser is making requests. These possibilities call for different responses, so avoid applying a generic “fix” before identifying the likely source.
If the browser’s secure-DNS setting appears to be responsible, decide whether to keep that feature or use the DNS behavior managed by the VPN. Either choice should be intentional. If the VPN client has a documented DNS or leak-protection setting, follow the instructions for that client and verify the result afterward. If another VPN or proxy application is running, test with only one active connection; two tools can compete to control the system route or DNS settings.
If the issue appears only on one Wi-Fi network, check whether the same device behaves differently on another trusted connection. A router may advertise DNS settings to connected devices, and a network administrator may enforce particular choices. Do not change router settings on a network you do not own or administer. On a work or school device, ask the administrator before changing managed DNS, proxy, or VPN controls.
Some test pages show resolver organizations that do not match the VPN brand. That can happen when a service uses a third-party resolver or shared network infrastructure. Compare the displayed address and provider information with the VPN client’s documentation, and consider that IP ownership databases can label addresses broadly. A name mismatch alone is not enough to conclude that DNS bypassed the tunnel. Likewise, if the test consistently shows the expected resolver, still remember that other applications may have different network settings.
Finally, DNS is only one part of network privacy. A DNS test does not establish whether a website account identifies you, whether browser cookies or device identifiers are present, or whether every application uses the VPN. It does not test all forms of traffic routing or prove that a device is free of unwanted software. Use the result narrowly: it helps answer what happened to the test’s DNS lookups under the conditions you tested.
Frequently asked questions
Does a different DNS provider mean my VPN is leaking?
No. A provider name that differs from the VPN brand is a reason to check the route and settings, but it is not conclusive by itself. A VPN may use a third-party resolver, and a test may identify shared infrastructure by its network owner. Compare the full resolver details with the VPN client’s documentation and repeat the test under consistent conditions.
Should I turn off secure DNS in my browser?
Not automatically. Browser secure DNS can encrypt lookups between the browser and its selected resolver, but it may use a resolver or route separate from the VPN’s DNS handling. Review the setting, decide which DNS service you intend to use, and test before and after any change. Restore the original choice if the change does not address the issue or causes other problems.
Why do different test sites show different results?
Test sites can use different methods, trigger different lookups, and rely on different databases to identify resolver networks. Browser settings, cached information, network changes, and timing can also affect what appears. Compare repeated results from the same test under the same conditions, and treat differences between test sites as a reason to investigate rather than choosing whichever result looks reassuring.
Does a passing test prove all my traffic is protected?
No. A browser-based DNS test reports information about the test’s own lookups at that time. It does not inspect every application, confirm every route, or provide a complete assessment of device privacy. For greater confidence, check the VPN connection state, relevant system and browser settings, and the behavior of the specific applications you use.
Practical takeaway: Establish a baseline, compare the same test with the VPN connected, inspect browser and device DNS controls, and verify one change at a time. Use the result to guide troubleshooting—not as a complete security verdict.