A VPN can encrypt the traffic it routes without automatically proving that every DNS request follows the same path. A DNS leak test helps you check which resolver appears to handle your lookups while the VPN is connected. Compare your public IP, the DNS servers reported by the test, and IPv6 behavior; then repeat the checks after changing a setting. One test result is a clue, not a complete audit of every app or connection.
What a DNS leak test can show
DNS, or the Domain Name System, translates a domain name into information a device can use to connect to a service. When you open a website, your device or browser may ask a DNS resolver to look up that domain. Depending on your operating system, browser, VPN app, and network, the request might use a resolver supplied by the VPN, one supplied by your internet provider, a public resolver, or an encrypted DNS service configured in the browser.
A public DNS leak test typically asks your browser to perform lookups and reports the resolver addresses that answer. The result can help you spot a mismatch: for example, the VPN is connected, but the test reports a resolver associated with your local internet provider. However, the test does not necessarily reveal every DNS request made by every application. It also cannot, by itself, establish what a resolver logs or prove that all traffic is private.
Interpret the result in context. A resolver’s displayed location or organization may not match your apparent VPN exit location because DNS providers use distributed infrastructure, anycast, or regional routing. A DNS server address that differs from the VPN server’s public IP is not automatically evidence of a leak. Check the VPN provider’s documentation for the resolver behavior it intends, and compare repeated results rather than drawing a conclusion from a single unfamiliar label.
3
checks: public IP, DNS, IPv6
2
states: disconnected and connected
1
setting change at a time
Check your public IP, DNS servers, and IPv6
Start by recording a baseline with the VPN disconnected. Use a reputable browser-based IP and DNS test, and note the public IP address, the reported network or provider, the DNS resolver addresses, and whether the page reports an IPv6 address. You do not need to publish or send these details to anyone. Treat them as temporary diagnostic information and avoid posting screenshots that reveal your address.
Connect the VPN, wait for the client to show that the connection is established, and run the same checks again in the same browser. A changed public IP is generally expected when the VPN routes that browser traffic. DNS results should be consistent with the VPN’s documented configuration, though the resolver’s name or apparent location may not match the public IP exactly. If the test still shows the same IP and resolver as the disconnected baseline, investigate before assuming the connection protects all traffic.
Check IPv6 separately. Some networks and applications can use IPv6 even when the VPN tunnel handles IPv4. If the test reports an IPv6 address that belongs to your ordinary internet connection while the VPN is active, that may indicate that IPv6 traffic is not using the tunnel. On the other hand, an IPv6 result is not automatically a problem if the VPN explicitly supports IPv6 routing and the address is consistent with its documented behavior. If IPv6 is unsupported, the app or operating system may need to block it while connected.
For a practical comparison, use a private browser window only if it does not change your browser’s DNS settings, extensions, or network path. Disable unrelated proxy or privacy extensions temporarily if they might alter the test, and close other VPN or proxy apps. If the browser has Secure DNS or DNS-over-HTTPS enabled, note that fact: the browser may send its own encrypted DNS requests instead of using the system resolver controlled by the VPN app.
Why DNS requests may bypass a VPN
Many apparent leaks come from a difference between the route the user expects and the route the device is actually configured to use. Split tunneling is one common example: an app may be excluded from the VPN, or a rule may send selected traffic directly. If DNS is handled outside the tunnel, a browser can appear to use the VPN for ordinary web traffic while name lookups follow another path. Review both app-based and domain-based routing rules, if your client offers them.
Browser-level DNS settings can create a second path. A browser using DNS-over-HTTPS may contact a resolver chosen in its own settings, independently of the operating system’s resolver. Encrypted DNS can protect requests between the browser and its resolver, but it does not automatically mean the VPN carries those requests. For diagnosis, compare the browser’s Secure DNS setting with the VPN’s guidance. Do not disable a privacy feature permanently just because one test reports a resolver you do not recognize.
IPv6 support varies between networks and VPN configurations. If the local network provides IPv6 but the VPN only routes IPv4, an application may try IPv6 outside the tunnel unless the client blocks it or the system configuration prevents it. Network changes can also matter: switching between Wi-Fi and mobile data, waking a device from sleep, reconnecting to a router, or moving between access points may briefly restore default DNS settings before the VPN reapplies its configuration.
Other possible causes include a manually configured DNS server, an old network profile, a second proxy or VPN client, a misapplied system proxy, or a VPN app that has not been granted the required network permissions. A kill switch may limit traffic when the tunnel drops, but its exact scope differs by client. It may block internet traffic without controlling browser-specific DNS, or it may apply only after the tunnel has been established. Check the feature description rather than assuming every kill switch behaves alike.
Finally, a test can produce confusing results without showing a true bypass. Resolver infrastructure may be shared or distributed, and a test may report a resolver operated by a third party used by the VPN. Confirm the provider’s expected DNS design and repeat the check after reconnecting. If the resolver consistently matches your local provider and the VPN documentation does not describe that behavior, treat it as a configuration issue to investigate.
A step-by-step test and fix
Use this sequence to isolate the cause instead of changing several network settings at once. Keep a short note of the original result and each change. If a setting makes the connection worse, you can restore the previous value instead of trying to remember what changed.
- Establish a baseline. Disconnect the VPN and check the public IPv4 address, any available IPv6 address, and reported DNS resolvers. Note whether the browser uses its own secure DNS option.
- Connect and repeat. Use the same device, network, browser, and test. Confirm that the VPN app reports a completed connection, then check IP, DNS, and IPv6 again. Allow time for the page’s test to finish rather than relying on a partial result.
- Check routing rules. Temporarily turn off split tunneling or rules that exclude the browser, if those options are enabled. Make sure a second VPN, proxy, or traffic-filtering app is not active. Retest before changing operating-system DNS settings.
- Review browser DNS. Check whether Secure DNS or DNS-over-HTTPS is enabled and which provider is selected. Follow the VPN app’s instructions for browser DNS. If you temporarily change this setting to compare behavior, record the original value and restore it if the test does not support keeping the change.
- Check IPv6 handling. Look for an IPv6 option in the VPN app and its documentation. If IPv6 is not supported, use the app’s recommended blocking or protection setting where available. Avoid making a global system change unless you understand its effect on other network services.
- Reconnect and verify. Disconnect and reconnect the VPN, then rerun the same tests. Also repeat after a normal network change, such as reconnecting to Wi-Fi, if that is when the issue occurs. A successful follow-up test matters more than merely finding a setting that sounds relevant.
When choosing or reviewing a provider, clear documentation about DNS behavior, IPv6, and routing rules makes troubleshooting easier. For an overview of the service and its supported platforms, see VPNBody; still, use the specific instructions in your installed client when changing network settings.
- ✅ Compare a disconnected baseline with a connected result on the same network.
- ✅ Change one setting at a time and rerun the same test after each change.
- ✅ Check browser DNS and IPv6 as well as the VPN app’s connection status.
- ❌ Do not assume an unfamiliar resolver label proves a leak without checking expected VPN behavior.
- ❌ Do not publish your public IP or diagnostic screenshots in a public support thread.
Device and VPN client checks
On Windows, first inspect the VPN app’s routing, DNS, and IPv6 options. If you need to understand the system configuration, ipconfig /all can show network adapters and their configured DNS servers. A command such as nslookup example.com can help identify which resolver responds to that particular lookup, but it is not a complete leak test: browser DNS-over-HTTPS, cached answers, and app-specific routing can behave differently. Compare command-line results with a browser test instead of treating either one as conclusive on its own.
On macOS, check the VPN client’s own DNS and routing settings first. The command scutil --dns displays resolver configuration, including scoped resolvers that may apply to particular interfaces or domains. That output can be long and may describe configured behavior rather than prove where every request went on the public network. Disconnecting and reconnecting the VPN, then repeating the browser test, is a practical way to check whether the expected configuration is being applied.
On Linux, resolvectl status can show DNS configuration by link on systems using systemd-resolved. Some distributions use another resolver manager, so the command may not be available or may not describe the active path. Check the VPN client’s documented integration with NetworkManager or the system resolver. If you use a compatible client such as Clash Verge or sing-box, also verify whether it is configured for system-wide routing, a system proxy, or only selected applications; those modes do not cover the same traffic.
On Android and iOS, inspect the active VPN profile, any per-app routing options, and the device’s private or encrypted DNS settings. Menu names and available controls vary by operating-system version and app. A browser may have an independent secure DNS option, while a device-level private DNS setting may apply more broadly. Avoid installing multiple VPN profiles and switching among them during diagnosis, because it becomes difficult to tell which app owns the active route.
For every platform, update the VPN client through its official distribution channel, check that the operating system has granted its VPN permission, and consult the app’s documentation before changing adapter, resolver, or firewall settings. If you contact support, describe the operating system, browser, VPN connection state, and the resolver behavior you observed. Redact public IP addresses, account details, and any other identifying information unless a trusted support process specifically requires them.
DNS leak test FAQ
Is a different DNS server always a leak?
No. A VPN may use a separate resolver, and that resolver may be operated by a partner or served through distributed infrastructure. Compare the result with the VPN’s documentation and your disconnected baseline. A resolver associated with your regular internet provider while connected is worth investigating, but the label alone is not enough to identify the route or determine what data is retained.
Why do two tests show different results?
Tests may use different domains, lookup methods, or browser features. Browser DNS-over-HTTPS, cached records, network changes, and resolver distribution can affect what each page reports. Run the same test more than once under stable conditions, and compare it with another method only as a cross-check. A disagreement is a reason to inspect the configuration, not proof that one test is necessarily wrong.
Should I turn off IPv6?
Not automatically. If the VPN supports IPv6 routing, follow its instructions and confirm that the test result matches the documented behavior. If it does not support IPv6, use the client’s recommended protection setting or ask the provider how to prevent IPv6 traffic from bypassing the tunnel. Disabling IPv6 system-wide can affect local services and other network configurations, so do not make that change without understanding the consequences.
Does encrypted DNS prevent a DNS leak?
Encrypted DNS protects the request between the device or browser and the selected resolver, but it does not guarantee that the request travels through the VPN tunnel. It may also route DNS to a provider different from the one specified by the VPN. Check both the resolver choice and the network path, then repeat the test with the VPN connected.