A DNS leak test checks whether domain lookups are going to a resolver outside the route you expect when a VPN or proxy is active. It is useful for finding configuration problems, but a test result needs context: seeing an unfamiliar DNS provider does not automatically prove that your traffic is exposed, and seeing a familiar provider does not prove that every app is protected. Check the public IP address, DNS resolvers, and IPv6 behavior together, then repeat the test after making changes.
What a DNS leak test can—and cannot—tell you
When you enter a website name, your device or browser needs to translate that name into an IP address. This lookup is handled by a DNS resolver. Depending on the device and its settings, the request may be sent by the operating system, a browser’s encrypted DNS feature, a VPN client, or a proxy client. If the lookup takes a path different from the one you intended, a test may show a resolver associated with your internet provider or network.
A test page usually relies on requests made by your browser and reports the public address it sees, along with information about the DNS resolvers that answered its test queries. It is a useful snapshot, not an audit of every app, every connection, or every possible network state. Results can vary with browser settings, split tunneling, the resolver’s infrastructure, and whether a page is showing a resolver operator, a server location, or both.
Keep three separate questions in mind: does the public IP match the route you selected; are DNS requests handled as intended; and is IPv6 covered, disabled, or otherwise accounted for? A browser-only test can also miss behavior in desktop software, games, messaging apps, or other applications that use their own networking stacks.
3
Checks: IP, DNS, IPv6
2
States: disconnected and connected
1
Change at a time when troubleshooting
Prepare for a reliable test
Before testing, note which client and connection mode you are using. Some services provide an official client; other setups use compatible third-party clients such as Clash Verge, sing-box, or Shadowrocket. Their controls and labels differ, and a proxy profile is not necessarily the same thing as a full-device VPN tunnel. A system proxy may route supported app traffic while other apps continue to use the ordinary network. A tunnel or virtual network interface may cover more traffic, but its actual behavior depends on the client, profile, and operating system.
Check the client’s current documentation for the meaning of its modes and DNS options. Do not assume that a setting called “global,” “TUN,” “enhanced mode,” or “VPN” has identical behavior across products. Similarly, do not paste a subscription URL or private configuration into an unfamiliar test or conversion service. Subscription links can grant access to account resources, so keep them private.
- ✅ Record the active client, profile, mode, selected route, and any DNS options you changed.
- ✅ Close other VPN or proxy clients before testing; competing network extensions and system proxies can make results ambiguous.
- ✅ Use the same browser and network for the disconnected and connected checks.
- ❌ Don’t treat a resolver’s brand or apparent location alone as proof of a leak.
- ❌ Don’t change several DNS, IPv6, and routing settings at once; you will not know which change affected the result.
If you are setting up a client for the first time, follow the relevant setup instructions for your platform rather than copying settings from a different app. A configuration that works in one client may not translate directly to another because subscription formats, protocol support, and DNS handling are client-specific.
Run IP, DNS, and IPv6 checks
Use a DNS leak test service you trust, preferably one that explains what its results represent. Avoid logging in or entering sensitive information on the test page. The practical sequence below gives you a baseline and a connected result to compare. If the test page offers standard and extended tests, use the same option in both states.
- Establish a baseline. Disconnect the VPN or proxy intentionally. Open the test page and note the public IPv4 and IPv6 addresses, if shown, and the DNS resolver names or organizations. This records what the current network exposes without the client.
- Connect and verify the client. Connect to the intended route and wait until the client reports a completed connection. Confirm that the intended profile and mode are active. A “connected” indicator alone does not establish which applications or requests are being routed.
- Check the public IP. Refresh the test page and compare its public IP result with the baseline. If the address is unchanged, check whether the selected mode routes browser traffic, whether the client is actually connected, and whether the page reused cached results. Do not infer a problem solely from an IP address that belongs to an unfamiliar network operator.
- Run the DNS test again. Start the test after the connection is established. If possible, run both the standard and extended options. Look for whether the resolvers change between disconnected and connected states, and whether the test shows repeated requests reaching resolvers associated with the ordinary network.
- Check IPv6 separately. If the page reports an IPv6 address, determine whether the client and current configuration are meant to route IPv6. An IPv4-only route may leave IPv6 behavior different from IPv4. An IPv6 address is not automatically a leak if it is routed as intended, but an address from the local ISP when the VPN is expected to cover all traffic deserves investigation.
- Repeat once after refreshing. Close and reopen the test page or use a private browser window, then repeat the checks. If results disagree, compare the browser’s secure DNS settings and the client’s DNS mode before changing anything.
For a useful record, note the time, network type, client mode, and result rather than saving a screenshot containing account details or a full subscription link. Test again after switching between Wi-Fi and mobile data, changing profiles, or updating the client: a setting that behaves correctly on one network may not behave the same way on another.
Interpret the results without jumping to conclusions
| Test result | What it may indicate | What to check next |
|---|---|---|
| Public IP appears unchanged | The browser may not be routed, the selected mode may be a system proxy, or the connection may not be active. | Check the client status, routing mode, browser proxy settings, and whether the route is intended for all traffic or selected apps. |
| DNS resolver resembles the local network provider | DNS may be using the operating system or router configuration, but resolver names and locations can be misleading. | Repeat the test, inspect client DNS settings, and compare with the disconnected baseline before concluding that requests bypassed the tunnel. |
| IPv6 appears only while connected | The client may route IPv6 differently from IPv4, or the address may be part of the selected route. | Check the client’s IPv6 support and routing policy. Avoid disabling IPv6 globally unless the client documentation or network administrator recommends it. |
| Results differ between browsers | Browsers may use different secure DNS settings, proxy settings, extensions, or cached test data. | Compare browser DNS options and extensions, then test with a clean browser profile without changing the operating system configuration. |
Resolver identification is not always straightforward. A resolver can be operated by one organization, use infrastructure in several locations, or appear under a hosting provider’s name. A test may report the resolver it detects rather than the exact physical destination of every packet. Treat a mismatch as a lead to investigate, not as a complete explanation.
Fix common DNS and routing problems
Start with the least disruptive checks. Disconnect and reconnect once, confirm that only one client is controlling the network, and select the intended profile again. If the issue persists, change one setting at a time and repeat the same test. Record the original value so you can restore it.
Check client mode and DNS settings
Review whether the client uses a system proxy, a tunnel interface, or application-specific rules. In rule-based clients, verify that the browser and the DNS requests it generates are handled by the expected rules. Some clients provide DNS modes for local resolution, remote resolution, or routing DNS through a particular outbound. The labels and supported behavior vary; use the client’s documentation and the configuration format it actually imports.
If the client has a DNS option intended to route queries through the selected proxy or tunnel, test that option only after understanding how it interacts with local domains and private network devices. Forcing every lookup through a remote resolver may interfere with printers, local services, or organization-managed networks. Avoid copying a DNS address from an unrelated tutorial without knowing who operates it and how it fits your configuration.
Review browser secure DNS and split tunneling
Browsers can offer DNS over HTTPS or another secure DNS mode. That may be a deliberate privacy choice, but it can also bypass the resolver behavior you expected the VPN client to control. Check the browser’s secure DNS provider and whether the feature is set to automatic, selected, or disabled. Test with the browser setting unchanged first; then make a documented, reversible adjustment only if the client’s instructions call for it.
Split tunneling and per-app routing can also explain different results. If the browser is excluded from the tunnel, its DNS requests may follow the ordinary network even while another app uses the VPN. Check both the app inclusion rules and any domain-based routing rules. A proxy client may also route DNS differently from web traffic, so confirm the policy for DNS explicitly rather than assuming it follows the same rule.
Account for IPv6 and network changes
Some networks provide IPv4 and IPv6 at the same time. A client or profile may route one family differently, and a test that checks only IPv4 can miss that distinction. Prefer a client and configuration that clearly document IPv6 handling. If IPv6 is not supported in the mode you use, follow the client’s guidance for preventing unintended traffic; changing system-wide IPv6 settings can affect local services and other applications.
Network changes can also leave stale settings behind. When moving between a home router, workplace Wi-Fi, and a mobile hotspot, check whether the operating system has a custom DNS server, managed profile, or network-specific proxy. On managed devices, an organization’s policy may control DNS or VPN settings, so consult its administrator instead of overriding those controls.
Verify the fix and prevent repeat issues
After a change, rerun the same sequence: baseline if appropriate, connect, check the public IP, run the DNS test, and check IPv6. Use the same browser and test options so the comparison is meaningful. Then test the apps that matter to you. A browser test cannot confirm that every application follows the same route, particularly when the client uses a system proxy or selective routing.
If the result is still unclear, restore the last known configuration and isolate the variables: browser secure DNS, client DNS mode, routing rules, IPv6 handling, and other network tools. Avoid repeatedly changing operating-system DNS values, installing multiple clients, or disabling security features as a guess. If you cannot tell whether a mismatch is expected, collect the client name and version, operating system, connection mode, and redacted test result when asking for support. Remove public IP addresses or account identifiers if they are not needed, and never include a private subscription URL.
A DNS leak test is a diagnostic, not a guarantee. Recheck after client updates, profile changes, or a change of network, and keep a note of settings that you deliberately altered.
DNS leak test FAQ
Does a different DNS provider automatically mean a leak?
No. A different resolver can be expected if the client routes DNS through a selected service or the resolver uses shared infrastructure. Compare connected and disconnected results, review the client’s DNS policy, and interpret the test’s provider labels cautiously.
Why does a test show my internet provider?
The operating system, router, browser, or client may be using a resolver associated with the provider. The label may also identify an upstream network rather than the physical resolver location. Check whether the same result appears while disconnected, then inspect browser secure DNS, client mode, and routing rules.
Should I disable IPv6 to stop a leak?
Not as a default fix. First determine whether IPv6 is routed by your client and whether the displayed address is expected. Disabling IPv6 system-wide can affect other network functions. Follow the client’s documented recommendation for the specific mode you use.
How often should I run a DNS test?
Run one when setting up a client or troubleshooting a mismatch, and repeat it after meaningful changes such as a new profile, client update, browser DNS change, or move to another network. Routine repeated tests are less useful than checking the settings and applications relevant to your situation.