A DNS leak occurs when your device sends domain-name queries outside the VPN tunnel, even though the VPN client appears to be connected. The webpage may still open through the expected exit route while the DNS request is handled by your local internet provider, workplace network, router, or another resolver. That can reveal which domains your device is looking up and can also cause inconsistent access, location results, or filtering behavior.
A DNS leak test is therefore not the same as checking your public IP address. An IP check asks where your internet traffic appears to exit. A DNS check asks which resolver is answering the domain-name requests made by your browser and applications. Both checks are useful, but neither should be treated as an absolute promise of anonymity. This guide explains how to test DNS behavior, how to interpret the result, and how to correct common configuration problems on Windows, macOS, Android, iOS, and Linux.
What a DNS leak really means
DNS, or the Domain Name System, translates a hostname such as example.com into an address that a device can connect to. Before a browser loads many websites, it normally asks a DNS resolver for this information. The resolver may be operated by your internet provider, a public DNS company, your router, an organization, or the VPN configuration itself.
When a VPN is configured correctly, DNS requests should normally follow the intended VPN path or be sent to a resolver selected by the VPN client. A leak happens when the operating system continues to use a local resolver, when the browser sends encrypted DNS independently of the VPN rules, or when an application bypasses the system tunnel. In these cases, your visible IP address and your DNS resolver can point to different network paths.
This difference matters because DNS requests are metadata. They can expose requested domain names to the resolver operator, affect which address a service returns, and create a mismatch between your apparent exit location and your DNS location. A DNS leak does not necessarily reveal the full content of an encrypted HTTPS session, but it is still a privacy and troubleshooting concern.
90+
countries covered
200+
routes available
5
supported platforms
Unlimited
simultaneous devices
A test result should also be read carefully. Seeing a familiar resolver name does not automatically prove that the VPN has failed, because some VPN providers intentionally use third-party DNS infrastructure. Conversely, seeing a foreign resolver does not prove that all traffic is protected. The useful question is whether the displayed resolver, route, and address match the configuration you intended to use.
How to run a reliable DNS leak test
Start with a clean baseline. Disconnect the VPN, close browser tabs that may be loading content in the background, and note the DNS servers shown by the operating system or router. You do not need to publish this information; it is only a reference for comparison. Then connect one VPN client or compatible proxy client, wait until its connection state is stable, and repeat the same check.
Browser-based test pages are convenient because they can display the resolver organizations observed during a series of DNS lookups. Use a standard test first, and use an extended test only when the page explains that it will generate additional queries. Do not interpret a single resolver line without reading the page’s location and organization details. The result may contain several resolvers, and that is not automatically a leak: a resolver provider may operate multiple addresses in different locations.
- Disconnect all VPN, proxy, and privacy-routing applications.
- Open a DNS leak testing page and record the visible resolver organization and approximate location.
- Close the page, connect the intended VPN profile, and wait for the client to show an established connection.
- Run the same test again in the same browser.
- Compare the resolver information with the VPN client’s DNS and routing settings.
- Repeat after restarting the browser if the first result may have been cached.
For a stronger check, repeat the process in a private browser window and in a second browser. Browsers can use their own encrypted DNS setting, and an extension can also modify how name resolution works. If one browser reports a different resolver from another, the difference is evidence that the applications are not using the same DNS path. It is not, by itself, proof that the VPN tunnel is broken.
| Observation | Possible explanation | Next action |
|---|---|---|
| Resolver matches your local network | The system or router may still be handling DNS | Review VPN DNS mode and reconnect |
| Resolver differs between browsers | One browser may use independent encrypted DNS | Compare browser DNS settings with client rules |
| Resolver is operated by the VPN service | The VPN may be providing its own DNS path | Confirm this against the client documentation |
| IPv4 looks protected but IPv6 differs | IPv6 may be bypassing the tunnel | Enable IPv6 support or disable it consistently |
Do not run multiple VPN clients at the same time while testing. A Windows or macOS desktop client, Clash Verge, sing-box, Shadowrocket, a browser proxy, and a separate system DNS utility can all change routing behavior. Test one arrangement at a time, otherwise you will not know which application created the observed result.
Common causes of DNS leaks
The operating system keeps its original DNS preference
Some clients establish a proxy connection without taking full control of system DNS. The browser may send web traffic through the proxy while the operating system continues to ask the local router for DNS answers. This is especially common when a client is running in rule mode rather than full tunnel mode, or when the system proxy setting was not applied successfully.
Check whether the client has a DNS option such as remote DNS, encrypted DNS, fake-IP handling, or tunnel DNS. The exact names differ between applications. A system-wide VPN mode generally has more control than a browser-only proxy, but it still depends on the operating system permissions and the client implementation.
The browser uses independent encrypted DNS
Modern browsers can send DNS queries directly to a provider over HTTPS. This feature, often called DNS over HTTPS or DoH, improves transport confidentiality from the local network, but it can bypass the DNS policy intended by a VPN client. Whether this is a problem depends on your goal. If you want the VPN client to select the resolver and apply its routing rules, an independent browser resolver can create an unexpected path. If you deliberately chose browser DoH, you should verify that its provider and route fit your privacy model.
Review the browser’s secure DNS setting and decide whether it should follow the operating system, use a specified provider, or be disabled while the VPN is active. Avoid changing the setting repeatedly during a test. Change one item, restart the browser, and test again so that cached results do not confuse the comparison.
IPv6 is outside the tunnel
A VPN profile may protect IPv4 traffic while leaving IPv6 available through the local interface. In that situation, a device can use the VPN for some connections and the ordinary network for others. DNS behavior can also differ between IPv4 and IPv6 resolvers. If the client supports IPv6, enable it and verify the result. If it does not, use a consistent operating-system setting that prevents unprotected IPv6 traffic rather than assuming that an IPv4-only connection covers everything.
Split tunneling and application bypass rules
Split tunneling is useful when selected applications or local services must remain outside the VPN. However, an exclusion can cover more than expected. A browser, DNS helper, game launcher, or background service may be placed in a bypass list, while the user assumes that only one application is excluded. Rule-based clients can also direct DNS traffic according to a separate rule set.
- ✅ Use one client during the initial test and close competing proxy tools.
- ✅ Check both IPv4 and IPv6 behavior when the client offers separate controls.
- ✅ Review browser secure DNS settings instead of assuming they follow the system.
- ✅ Inspect split-tunnel and bypass lists for browsers, DNS tools, and background services.
- ❌ Do not treat a changed public IP as proof that DNS is also protected.
Device-by-device fix checklist
Windows
On Windows, first confirm whether the client is using a system VPN interface, a system proxy, or only an application-level proxy. A system proxy may affect browsers that respect Windows proxy settings but not every application. A virtual tunnel interface generally provides broader routing control, but it may require administrator permission.
Open the client’s DNS settings and look for remote or tunnel-based DNS. If the client provides a kill switch, understand whether it blocks only ordinary traffic or also blocks DNS and IPv6 traffic during reconnects. After changing settings, disconnect and reconnect rather than testing while an old session remains active.
Windows may retain resolver information in its DNS cache. Restarting the browser is useful, and flushing the local cache can help distinguish an old answer from a new query. A cached record does not necessarily show where the original query was made, so use a fresh browser test as well as command-line checks. If a work VPN, security suite, or manually configured adapter is present, review its priority because Windows can select a different interface than expected.
macOS
macOS can have DNS settings associated with Wi-Fi, Ethernet, a VPN service, and other network interfaces. A proxy client may appear connected while the active service order still favors the physical interface for name resolution. Check the client’s full-tunnel or system-extension mode, then inspect the active network service and reconnect after applying changes.
Private Relay, browser secure DNS, corporate profiles, and security software can also alter resolution. These features may be appropriate for their intended use, but they make a VPN comparison less straightforward. Disable or pause one overlapping feature only for a controlled test, then restore it if it is required for your normal workflow. Do not remove an organization-managed profile without authorization.
Android
Android includes a system-level Private DNS setting. It can use an automatic mode, a specified hostname, or another policy depending on the device version and manufacturer interface. A VPN application may coexist with Private DNS, but their interaction can vary. Review the Private DNS choice and the VPN app’s DNS behavior together.
Android also allows per-application VPN exclusions in some clients. Battery optimization can stop a VPN process in the background, causing the connection state to change while applications continue using the ordinary network. Set the client to an appropriate background mode, check the always-on VPN option if it suits your needs, and test after the screen has been locked and unlocked. These controls are device-specific, so use the labels shown by your handset rather than copying instructions for a different Android version.
iOS and iPadOS
On iOS, VPN profiles, encrypted DNS profiles, content filters, and application-specific network extensions can affect resolution. A client using a tunnel profile may manage DNS differently from a client using a local proxy method. Check which connection type the application uses and whether it reports that DNS is protected.
Because iOS restricts low-level network changes compared with desktop systems, focus on the controls exposed by the official client. Remove unused VPN profiles only when you know they are no longer needed, and avoid installing multiple DNS or filtering profiles during troubleshooting. If a browser test gives an unexpected result, disconnect every other profile, restart the browser, reconnect the intended client, and test again.
Linux
Linux resolution can be managed by NetworkManager, systemd-resolved, a desktop environment, a local DNS daemon, or a manually edited resolver configuration. A proxy client that works in a terminal may not automatically control applications launched through the desktop session. Conversely, a system VPN may route browser traffic correctly while a container or isolated namespace uses its own resolver.
Inspect the active resolver and interfaces with the tools provided by your distribution, such as NetworkManager or systemd-resolved utilities. Check whether the VPN interface receives DNS servers and whether the default route and DNS routing domains change after connection. If you use sing-box or another rule-based client, verify its DNS rules separately from its proxy rules. Do not copy a resolver file from another system without understanding which service regenerates it.
For all platforms, official clients for Windows, macOS, iOS, Android, and Linux are the simplest starting point. Compatible clients such as Clash Verge, sing-box, or Shadowrocket can import a subscription link, but the imported profile still needs to be checked for DNS mode, IPv6 handling, fake-IP or redirection behavior, and bypass rules. The subscription supplies configuration data; it does not override every local operating-system policy automatically.
How protocols and routing modes affect the result
Protocols such as Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard describe how traffic is transported or encapsulated, but a protocol name alone does not determine whether DNS will be protected. DNS behavior is controlled by the client’s routing mode, tunnel implementation, resolver configuration, and rules. A well-configured Shadowsocks profile can protect DNS, while a poorly configured profile using the same protocol can leave local resolution in place.
Full-tunnel mode usually sends more traffic through the VPN interface and is easier to verify. Rule mode can be more efficient for local services, but it requires careful review of which domains and applications are sent directly. Global proxy mode may affect more applications than rule mode, yet it still may not capture applications that ignore system proxy settings. TUN mode can capture traffic at a lower network layer, but it may require permissions and can conflict with another virtual interface.
DNS modes also need interpretation. Traditional remote DNS sends queries to a resolver through the proxy path. Fake-IP methods return synthetic addresses to help the client apply domain-based rules, which means command-line output may look different from a normal DNS response. DoH and DNS over TLS encrypt the DNS exchange, but encryption alone does not show whether the query went through the VPN. The route and resolver policy must be checked together.
When changing a profile, record the original mode first. Then alter one setting, reconnect, clear or wait for browser state to expire, and repeat the test. If the result improves, keep the change and verify that local websites, banking applications, printers, and other services still work. A privacy setting that breaks essential local traffic may need a narrower rule rather than simply being left enabled globally.
What to do when the test still shows a leak
First, verify that the test page itself is not reporting cached or stale information. Close the tab, restart the browser, reconnect the VPN, and run a fresh test. Then test from another browser or a separate network. A resolver result that remains the same across several controlled tests is more significant than a single unexpected line.
Next, simplify the connection. Disable browser extensions that manage DNS or proxies, close additional VPN clients, remove temporary proxy settings, and pause manually configured DNS tools. Confirm that the intended client has permission to create a VPN interface or modify system routing. On desktop systems, also check whether a security product or organizational policy is blocking the client’s network extension.
Check for IPv6 separately, especially if the client does not advertise IPv6 support. Review split tunneling and domain rules, then inspect whether the application being tested is excluded. If only one application leaks while the browser is protected, the issue is probably application routing rather than a universal DNS failure.
If the problem persists, export or inspect the client profile without publishing the subscription link. A subscription link can contain access credentials or configuration information and should be kept private. Compare the profile’s DNS server, mode, route rules, and TUN settings with the client documentation. Re-importing the same profile repeatedly will not fix a local conflict if another adapter or browser setting continues to take priority.
- ✅ Test after a clean reconnect and a browser restart.
- ✅ Compare results across a second browser or network.
- ✅ Check IPv6, split tunneling, and application exclusions independently.
- ✅ Keep subscription links private while troubleshooting.
- ❌ Do not install several DNS profiles at once to “force” a result.
- ❌ Do not conclude that every request is protected from one successful webpage load.
Once the result is consistent, document the working settings for that device: client name, routing mode, DNS mode, IPv6 choice, browser secure DNS choice, and any intentional bypasses. This makes future troubleshooting easier after an operating-system update, network change, or profile refresh.
DNS leak test FAQ
Does a changed IP address prove that there is no DNS leak?
No. The public IP address and DNS resolver are separate observations. A VPN can change the visible exit IP while the operating system still sends DNS requests to the local resolver. Run both an IP check and a DNS check, then compare them with the client’s intended routing and resolver policy.
Is using a public DNS provider automatically safer?
No. A public resolver may offer useful security and reliability features, but the provider can still receive your DNS queries. If the resolver is configured outside the VPN tunnel, the query may also reveal your activity to the local network. The important questions are who operates the resolver, what information it retains, and whether the query follows the route you selected.
Should browser secure DNS be turned off?
There is no universal answer. Turn it off or set it to follow the system when you want the VPN client to control DNS consistently. Keep it enabled when you intentionally use a trusted provider and have verified that its connection follows your privacy requirements. The correct choice depends on your threat model and whether the browser setting conflicts with the VPN rules.
Why can a phone show different results after switching networks?
Mobile devices can change between Wi-Fi and cellular interfaces, apply Private DNS or DNS profiles, pause background VPN processes, or use application-specific exclusions. Reconnect the VPN after changing networks, review the mobile DNS setting, and test while the device is using the same network conditions as your normal activity.
A DNS leak test is most useful as a repeatable configuration check, not as a one-time badge of perfect privacy. Confirm the exit route, inspect DNS behavior, account for IPv6 and browser-specific settings, and keep the setup simple enough to understand. For a fresh subscription import and platform-specific setup, see the setup guide; for available route coverage, review the route information.