VPN DNS Leak Test: How to Check and Fix Privacy Leaks
A connected VPN does not always mean every DNS request follows the VPN tunnel. This guide explains why leaks happen, walks you through a browser-based test, and shows which DNS, leak protection, and kill switch settings to review before you reconnect.
A VPN connection indicator confirms that a client has established a tunnel, but it does not by itself prove that every DNS request uses the resolver or route you expect. DNS can behave differently across browsers, operating systems, network changes, and split-tunneling rules. This guide explains what a DNS leak test can and cannot tell you, how to run a careful browser-based check, and how to troubleshoot unexpected results without changing several settings at once.
What a DNS leak test shows
When you enter a website name, such as example.com, a DNS resolver helps translate that name into an IP address. Depending on your device and setup, the request may be handled by the operating system, the browser, a VPN client, a router, or a resolver operated by an internet provider or another organization. A VPN may route DNS requests through the tunnel, but the exact behavior depends on the VPN client, the operating system, and any DNS settings configured elsewhere.
A browser-based DNS leak test asks your browser to make requests to test domains and reports the resolvers that answer those requests. The results can help you determine whether the observed resolver behavior is consistent with your current VPN setup. They do not show every DNS request made by every app, and they are not a complete audit of your device or network. Treat them as one diagnostic signal, not as a certification that all traffic is protected.
It is also useful to distinguish two meanings that are often grouped under “DNS leak.” A request may travel outside the VPN tunnel, exposing it to the local network or internet provider. Alternatively, the request may travel through the tunnel but reach a DNS service that is not the one you intended to use. The second case may be a resolver choice or browser configuration issue rather than traffic bypassing the tunnel. A test result usually identifies resolver information; it may not establish the exact path each request took.
- ✅ Compare the resolver results with the VPN’s documented DNS behavior, if available.
- ✅ Note whether the VPN is connected and whether the browser uses its own secure DNS setting.
- ❌ Do not assume that a resolver’s displayed country proves your physical location or the full route of a request.
- ❌ Do not treat a single successful test as proof that every app follows the same DNS path.
Prepare before testing
Start with a clear baseline. Close or pause other VPN, proxy, DNS-filtering, and network-privacy apps that could change routing. Running two VPN clients at the same time can create conflicting routes, while a firewall, parental-control tool, or encrypted DNS app may alter which resolver appears in a browser test. Do not disable security software indiscriminately; instead, record what is active and change only one relevant setting at a time.
Check the VPN client’s status and confirm that it is connected to the location you intended to use. If the client offers a DNS option, read its description before changing it. Some clients use the service’s DNS by default; others may allow a custom resolver or follow system settings. Names such as “secure DNS,” “DNS protection,” or “use system DNS” are not standardized, so consult the client’s built-in help or the service’s instructions rather than assuming that similarly named options work identically.
Next, inspect the browser’s secure DNS setting. Browsers may offer DNS over HTTPS (DoH), which sends DNS queries to a selected provider over an encrypted connection. DoH can be useful for protecting DNS between the browser and its resolver, but it can also cause the browser to use a different resolver from the one configured by the VPN or operating system. Depending on routing, the DoH connection may still travel through the VPN tunnel. Therefore, an unexpected resolver in the test does not automatically mean that the request bypassed the tunnel.
| What to inspect | Why it matters | A sensible first check |
|---|---|---|
| VPN client DNS options | The client may select a service resolver, follow system DNS, or allow a custom choice. | Read the option description and note its current value before changing it. |
| Browser secure DNS | The browser may send DNS requests to a provider different from the system resolver. | Record whether DoH is enabled and which provider is selected. |
| Split tunneling | Selected apps or destinations may use a different route from the rest of the device. | Check whether the browser is excluded from the VPN or assigned a separate rule. |
| Other network tools | DNS filters, proxy apps, and security software can influence resolver selection. | Identify active tools and avoid changing several of them simultaneously. |
Run a browser-based DNS test
Use a DNS leak testing website only if you are comfortable sending test queries to that provider. Review its privacy information and avoid entering passwords, account details, or other sensitive information into a diagnostic page. A basic test should need only to generate test lookups; it should not require your VPN credentials. If the page asks for unrelated personal information, leave it and choose another diagnostic method.
For a useful comparison, run the test once without the VPN and once with it, using the same device, browser, and network when practical. The first run gives you a reference for the resolver behavior of your ordinary connection. The second shows what the browser observes after you connect. A comparison is more informative than looking at the VPN result in isolation, but it still does not reveal every detail of the network path.
- Record the baseline. Disconnect the VPN, open the test page, and run its standard DNS test. Note the resolver names or organizations shown, along with the browser and network you used. Do not publish a screenshot if it contains a public IP address or other identifying information.
- Connect the VPN. Choose the intended location, wait for the client to show an established connection, and confirm that the browser is not excluded by a per-app or split-tunneling rule.
- Start a fresh test. Reload the diagnostic page or begin a new test rather than relying on results left open from before the connection. Follow the page’s instructions for generating fresh DNS requests.
- Compare the results. Check whether the resolver information changed and whether it matches what the client or service says to expect. A provider name that is unfamiliar is a reason to investigate, not by itself proof of a leak.
- Repeat under controlled conditions. If results look unexpected, run the test again after confirming the VPN is connected. Then test a different browser or compare the browser’s secure DNS setting, changing only one variable per run.
Interpret locations cautiously. Resolver databases can be incomplete or outdated, and a resolver’s listed location may not match the location of the user, the VPN exit, or the resolver hardware. Some resolver operators use distributed networks, so multiple names or locations can appear even when the setup is functioning as designed. If the test identifies an organization you do not recognize, compare that result with the VPN provider’s documentation and the browser’s selected DNS provider before concluding that traffic escaped the tunnel.
Fix unexpected DNS results
If the resolver results remain unexpected, use a troubleshooting sequence rather than toggling every privacy option at once. First check that the browser is included in the VPN route. With split tunneling, an excluded browser may use the ordinary network while other apps use the VPN. Also verify that the rule is applied to the browser you actually tested; separate browser profiles or another installed browser can have different routing rules.
Next, review browser DoH. For a diagnostic comparison, you can temporarily set the browser to follow the operating system’s resolver or disable its custom secure DNS provider, then reconnect the VPN and repeat the test. Note the original setting so you can restore it. This comparison helps identify whether the browser’s resolver choice is responsible for the changed result. It does not necessarily mean that DoH is unsafe or that it must remain disabled; the right configuration depends on your privacy goals and how your VPN handles DNS.
Then inspect the VPN client’s DNS and leak-protection controls. If the client offers DNS leak protection, confirm that it is enabled and understand whether it applies to all apps or only the VPN’s default route. If a custom DNS address is configured at the operating-system level, temporarily return to the normal system setting only if you understand how to restore it. Avoid entering a random DNS address from an online list: a resolver can see the domains it processes, and the choice of provider is part of your privacy decision.
IPv6 can also complicate diagnosis. A VPN may route IPv4 traffic while the operating system or client handles IPv6 differently. This depends on the platform and client. Check whether the VPN documentation describes IPv6 support or protection, and use the client’s recommended setting. Do not disable IPv6 globally as a first response: that can disrupt applications or network features, and it may hide a configuration issue rather than correct it.
After each change, reconnect the VPN and start a fresh browser test. If the result changes, note which single adjustment made the difference. If it does not, restore the previous setting before trying the next check. For platform-specific setup steps, use the VPNND guides and the documentation for your installed client. Client controls and available options can vary by operating system and version.
- ✅ Confirm the tested browser is routed through the VPN.
- ✅ Compare the browser’s DoH setting with the operating system and VPN DNS options.
- ✅ Check the client’s DNS protection and IPv6 guidance before changing system-wide settings.
- ❌ Avoid changing the browser, operating system, router, and VPN settings in one troubleshooting pass.
- ❌ Do not share full subscription URLs, account credentials, or unredacted diagnostic screenshots.
Use a kill switch and retest safely
A kill switch is intended to block some or all network traffic when a VPN connection drops, depending on the client and platform. It is not the same as DNS leak protection, and enabling one does not automatically confirm that DNS is routed as intended. Review the client’s description to learn what it blocks, whether it applies during startup and reconnection, and whether local-network access is treated differently. Feature names and behavior vary, so test only with a connection you can safely interrupt.
To check the behavior, first save work and close activities that could be disrupted. Connect the VPN, verify ordinary browsing, and use the client’s documented method for testing disconnection behavior if one is provided. Do not deliberately interrupt a critical work call, file transfer, payment, or other sensitive session. After a drop or reconnect, verify the client’s status and run a fresh DNS test. A page that was already loaded is not a reliable test of whether new requests were blocked.
Also test network transitions that matter to your use, such as moving between Wi-Fi and mobile data, one at a time. A VPN may need to reconnect when the network changes. Check whether the client reports a connection interruption and whether the kill switch behaves as described while it reconnects. Do not infer that the connection remained protected just because the VPN icon reappeared afterward; verify with a new request once the tunnel is restored.
DNS leak test FAQ
If the test shows my internet provider, does that prove a DNS leak?
Not by itself. The result may reflect a browser-level DoH choice, a resolver arrangement used by the VPN, an ISP-operated resolver reachable through the tunnel, or incomplete resolver identification. Check split tunneling, browser DNS settings, and the VPN’s DNS documentation. If the result is still unexplained, compare another browser and contact the service through its official support channel without sharing credentials.
Can a DNS test confirm that every app is protected?
No. A browser test observes requests made in that browser under the tested conditions. Other apps may use their own DNS-over-HTTPS implementation, follow different system settings, or be excluded by split tunneling. Review the client’s routing controls and test relevant apps separately where appropriate.
Should I turn off browser secure DNS?
Not automatically. Secure DNS can encrypt the browser’s connection to a resolver, but the selected resolver may differ from the VPN’s expected DNS service. Temporarily comparing results with the browser set to use the system resolver can help diagnose the cause. Choose a final setting based on your privacy requirements, the browser’s behavior, and the VPN client’s guidance.
How often should I run a DNS leak test?
Run one when you first configure a VPN, after changing DNS, browser, split-tunneling, or IPv6 settings, and when troubleshooting a route change or unexpected result. Repeating tests without changing anything may not add useful information. Keep the test limited to the device and network conditions you need to verify.