A DNS leak occurs when your device sends domain-name lookup requests outside the VPN tunnel, even though the visible web traffic appears to use the VPN connection. The destination website may see the VPN exit address while DNS providers, internet service providers, public Wi-Fi operators, or local network administrators can still observe which domains your device is trying to resolve. This does not automatically expose the content of every connection, but it weakens the privacy separation that most people expect from a VPN.
DNS leak testing is therefore not the same as checking your public IP address. An IP test answers where a web server believes your connection is coming from. A DNS test answers which resolvers received the requests needed to translate names such as example.com into IP addresses. A reliable privacy check should examine both, and it should be repeated after changing networks, switching VPN protocols, enabling split tunneling, or allowing the device to sleep and wake.
What a DNS leak is and why it matters
When you enter a website address, an application normally needs to resolve the hostname before it can connect. Depending on the operating system and application, the request may go to a router, a mobile carrier resolver, a public DNS service, an encrypted DNS provider, or a resolver supplied by the VPN. The request can use traditional DNS over UDP or TCP, or an encrypted method such as DNS over HTTPS or DNS over TLS. Encryption protects the request while it travels, but the selected resolver can still receive the domain name.
With a full-tunnel VPN, the usual privacy goal is for DNS requests to travel through the same encrypted interface as other traffic. The VPN client may install a virtual adapter, change system DNS settings, and apply routing rules that direct resolver traffic into the tunnel. If one of those operations fails, the operating system may continue using the local router or carrier resolver. The VPN session can look connected while DNS follows a different path.
Several situations commonly create this mismatch. A client may reconnect without restoring the original DNS setting. An IPv6 resolver may remain active while the VPN only handles IPv4. A browser may use its own DNS-over-HTTPS policy instead of the operating system resolver. Split tunneling may intentionally leave the browser or a background service outside the tunnel. Public Wi-Fi may push a captive-portal resolver before the VPN has fully connected. These cases have different fixes, so changing DNS addresses at random is rarely the best first step.
2
Core checks: IP and DNS
4
Common device groups
1
Active VPN tunnel
0
Assumption that one test proves all apps
A DNS result that shows a familiar local ISP does not always mean every request is exposed, and a result that shows a VPN-associated resolver does not guarantee perfect privacy. Resolver names and ownership data can be incomplete, especially when a provider uses shared infrastructure. Compare the country or network identity shown by the test with your VPN exit, then consider which application generated the request and whether the VPN was fully connected during the test.
How to perform a reliable DNS leak test
Begin with a clean baseline. Disconnect the VPN, open a private browsing window, and record the DNS providers shown by a reputable browser-based DNS test. You do not need to publish the result or submit personal information. The purpose of the baseline is to understand what the current network supplies before the VPN changes the route. On a home network, this may be the router or broadband provider. On public Wi-Fi, it may be the venue’s network or a captive-portal system.
Next, close the test page, connect the VPN, wait until the client reports a completed connection, and run both a standard test and an extended test if the site provides one. A standard test may query a small set of hostnames, while an extended test sends more varied requests. The extended result is useful because a resolver path may appear normal during one query and reveal a second resolver during another. Avoid treating the number of listed servers as a score. A provider can legitimately use several resolvers, and a long list does not automatically indicate a leak.
Use more than one independent method when the result is important. A second DNS test can reveal whether the first site has a misleading database or incomplete resolver identification. You can also inspect the active DNS configuration locally. On Windows, review the adapter properties and use the system network commands to display DNS servers. On macOS, check the active network service in system settings or use the built-in network configuration tools. On Linux, inspect the resolver service used by the distribution, such as NetworkManager, systemd-resolved, or another local resolver. On Android and iOS, review Private DNS or encrypted DNS settings and the VPN profile, while remembering that mobile operating systems restrict low-level inspection.
Repeat the test under conditions that commonly expose configuration problems:
- ✅ Test once with the VPN connected before opening other network-heavy applications.
- ✅ Test after changing from Wi-Fi to mobile data or from one Wi-Fi network to another.
- ✅ Test after sleep, hibernation, or a temporary loss and restoration of the tunnel.
- ✅ Test with split tunneling disabled, then repeat with the selected application excluded.
- ✅ Test in more than one browser if one browser has its own secure DNS setting.
- ❌ Do not identify a DNS leak solely from a browser’s WebRTC or local-address result; WebRTC exposure and DNS routing are separate checks.
For a stronger application-level check, test the browser, command-line tools, and a privacy-sensitive application separately. A browser may use encrypted DNS internally, while a command-line utility follows the operating system resolver. An application with its own networking stack may ignore system proxy settings or use a hard-coded resolver. If only one application produces a different result, focus on that application before changing the entire operating system configuration.
| Test result | Likely interpretation | Next action |
|---|---|---|
| VPN exit and VPN-associated DNS appear together | The basic full-tunnel path is probably working for that browser test | Repeat after reconnecting and on another network |
| VPN exit appears, but local ISP DNS also appears | DNS traffic may be bypassing the tunnel or using mixed resolver paths | Check client DNS protection, IPv6, and split tunneling |
| Local IP and local DNS both appear | The VPN may not be active for the browser, or the browser is excluded | Check the client state, proxy mode, and application rules |
| Only one browser shows a different resolver | That browser may be using its own encrypted DNS policy | Review secure DNS settings and test the system resolver separately |
Hands-on fix steps for Windows, macOS, mobile, and Linux
Fixing a DNS leak should follow a controlled sequence. First disconnect the VPN and save the current network settings if your operating system allows it. Then reconnect using the official VPN client or a compatible client with a correctly imported subscription. Confirm that the tunnel is actually established rather than relying on a tray icon or a notification. Run the test again before making additional changes. This prevents a temporary connection failure from being confused with a DNS configuration failure.
Check the VPN client before changing system DNS
Look for settings named DNS leak protection, use VPN DNS, secure DNS, remote DNS, or prevent DNS outside the tunnel. The exact wording differs between official Windows, macOS, Android, iOS, and Linux clients, as well as compatible clients such as Clash Verge, sing-box, and Shadowrocket. Enable the option that keeps DNS requests within the VPN path when the client provides one. If the client offers a choice between system DNS, remote DNS, and a custom resolver, understand that a custom address does not by itself guarantee that requests travel through the tunnel.
Review split tunneling at the same time. A rule that excludes a browser, terminal, or system service may also change how its DNS requests are routed. For troubleshooting, temporarily use full-tunnel mode and disable application exclusions. Once the test is clean, re-enable exclusions one by one and test after each change. This is safer than adding many rules together because you can identify the exact setting that changes the result.
Platform-specific checks
Windows: Check every active adapter, including Wi-Fi, Ethernet, virtual machine adapters, and older VPN interfaces. Multiple active interfaces can create confusing resolver priority. Flush the local DNS cache after changing the connection, reconnect the VPN, and test again. If IPv6 is enabled on the physical adapter but the VPN does not provide IPv6 handling, ask whether the client supports IPv6 leak protection. Disabling IPv6 can be a troubleshooting measure, but it should not be the first permanent fix if the VPN has proper IPv6 support.
macOS: Confirm which network service is active and inspect both IPv4 and IPv6 resolver information. macOS may retain resolver state after a network change, so disconnecting and reconnecting Wi-Fi, restarting the VPN client, or clearing the local cache can help distinguish stale information from an active leak. Also check whether a browser’s secure DNS feature is enabled independently of the VPN. A browser resolver may be privacy-friendly, but it can still bypass the VPN provider’s DNS policy and may complicate split-tunnel expectations.
Android: Review the Private DNS setting. An always-on Private DNS hostname can send lookups to a separately configured provider, depending on the VPN and operating-system behavior. Check whether the VPN is set to always-on mode and whether the option to block connections without the VPN is available. Battery optimization can stop or delay a VPN service in the background, especially after the screen is off. Exclude the VPN application from aggressive battery restrictions when the device manufacturer offers such controls.
iOS: Check the active VPN profile, any DNS or filtering profile, and the browser’s own privacy settings. iOS applications may use system networking or their own encrypted resolver behavior. A result from Safari should not be treated as proof for every other application. If a connection drops when the device changes networks, verify whether the VPN reconnects automatically and whether the kill switch or on-demand behavior is enabled by the client.
Linux: Identify which component controls DNS: NetworkManager, systemd-resolved, a desktop environment, or a manually configured resolver. A VPN profile may install a route correctly but fail to update the resolver scope. Check the active interface and per-link DNS information rather than editing a static resolver file blindly. If you use a proxy-oriented client instead of a system VPN, remember that many proxy modes do not automatically capture every application’s DNS traffic.
After each change, reconnect the tunnel and run a fresh test. Do not keep an old test tab open and assume that newly generated requests use the new configuration. DNS results may be cached by the browser, operating system, local router, or resolver, so use a new private window and query several unrelated domains.
Kill Switch, protocols, and tunnel behavior
A kill switch is designed to block traffic when the VPN tunnel is unavailable. Its privacy value depends on what it blocks and when the rules are applied. Some clients block only general internet traffic; others also block IPv6, local network access, or DNS requests. Test the behavior deliberately: connect the VPN, confirm normal browsing, temporarily interrupt the tunnel using the client’s disconnect control or a controlled network change, and check whether applications stop communicating. Restore the connection afterward and verify that traffic resumes only when the tunnel is active.
A kill switch is not a substitute for DNS leak protection. If the client continues to allow DNS queries while the tunnel is reconnecting, a short exposure may still occur. Likewise, a kill switch that blocks the browser but allows a background service may not meet your expectations. Read the client’s documentation and test the applications you actually use. On mobile devices, operating-system restrictions and battery management can affect always-on behavior.
Protocol choice can influence reliability and recovery, but no protocol automatically makes a configuration leak-proof. WireGuard uses a modern tunnel design and often reconnects efficiently, while OpenVPN can operate over UDP or TCP and offers broad client compatibility. Trojan and VMess are commonly encountered in proxy-oriented configurations, and Hysteria2 is designed for particular transport conditions. The important question for DNS privacy is whether the selected client routes DNS through the tunnel and applies leak protection consistently. A protocol change should therefore be followed by a new IP test, DNS test, and disconnect test.
Do not confuse a proxy mode with a full-device VPN. A system VPN normally installs routes and can protect DNS for applications that use the system network stack. A rule-based proxy client may capture selected traffic while leaving other applications, DNS services, or IPv6 paths outside its rules. If your goal is to check one browser, that may be acceptable. If your goal is device-wide privacy on public Wi-Fi, verify the client’s operating mode and coverage rather than assuming that a connected status covers every process.
Common false alarms and misleading test results
Some DNS test results look alarming but require context. A resolver may be operated by the VPN provider but appear under a hosting company or a regional network name. A public resolver may serve requests from several locations, so its displayed country may not exactly match the VPN exit. An extended test may list multiple resolvers within the same provider infrastructure; that is not automatically a leak. Compare ownership, network identity, and behavior across repeated tests instead of judging the result from one label.
WebRTC is another frequent source of confusion. A WebRTC test may reveal a local or public address through browser real-time communication mechanisms. That result concerns browser address discovery and is not the same as a DNS request escaping the tunnel. WebRTC controls can still matter for privacy, but they should be investigated separately. Similarly, an IPv6 address shown by an IP test may indicate an IPv6 routing issue, while an IPv6 DNS result specifically indicates that resolver traffic is using that path.
Cached DNS answers can make a test appear unchanged after a fix. The browser may reuse an answer it already received, and the operating system may retain entries in its local cache. Restarting the browser, clearing the relevant cache, reconnecting the network, and testing new hostnames can help. Do not repeatedly flush caches without checking the active route, because cache clearing cannot repair a resolver that is still outside the tunnel.
Captive portals also complicate testing. Public Wi-Fi may require an initial login before the VPN can establish a tunnel. During that stage, local DNS is expected because the device has not yet connected to the VPN. Complete the portal login first, then connect the VPN and run the test again. If the client cannot connect after the portal is completed, check whether the network blocks the selected protocol or requires a different transport mode. Avoid entering passwords or payment details into a captive portal that does not clearly belong to the venue.
- ✅ Treat resolver ownership and route context as more important than a country label alone.
- ✅ Separate DNS, IP, WebRTC, and IPv6 tests so each result has a clear meaning.
- ✅ Repeat the test after caches expire or after opening a fresh private window.
- ❌ Do not assume a browser result represents command-line tools, games, update services, or every mobile application.
- ❌ Do not install unknown “DNS protection” utilities merely because a test page recommends them.
Realistic privacy precautions for public Wi-Fi and daily browsing
A clean DNS test improves confidence, but it does not make a connection anonymous or risk-free. The VPN provider can generally observe some connection metadata, and the websites or services you sign into can still associate activity with your account. Cookies, browser fingerprints, application telemetry, and payment records are outside the scope of DNS protection. Use HTTPS, keep the operating system and browser updated, and avoid entering credentials into pages reached through unexpected links.
On public Wi-Fi, connect to the correct network, complete any captive-portal step carefully, and then enable the VPN before opening sensitive services. Keep file sharing and unnecessary local discovery disabled when using an untrusted network. A VPN can protect traffic from local network observation, but it cannot prevent malware already installed on the device from reading data before encryption or after decryption.
For everyday browsing, choose a client mode that matches your goal. Full-tunnel mode is easier to reason about because DNS and application traffic follow a single policy. Split tunneling can improve access to local printers, banking services, or regional websites, but every exclusion creates another path to test. If you import a subscription into Clash Verge, sing-box, Shadowrocket, or another compatible client, confirm whether the imported profile includes DNS rules, fake-IP behavior, IPv6 handling, and a final catch-all rule. The presence of a node list alone does not prove that DNS is protected.
Keep a simple record of what changed when troubleshooting: device, network type, client, protocol, split-tunnel state, browser DNS state, and test result. This does not need to contain personal browsing history. The purpose is to identify patterns, such as leaks only after sleep, only on mobile data, or only when a specific application is excluded. If a provider’s official client behaves differently from a third-party client, compare their DNS and routing designs rather than assuming that the server itself is the cause.
DNS leak testing FAQ
Does a VPN always use its own DNS server?
No. Some VPN clients install provider-operated DNS resolvers, while others allow system DNS, a custom resolver, or encrypted DNS configured by the operating system. The important issue is not the branding of the resolver but whether the request travels through the intended tunnel and whether the resolver policy matches your privacy expectations. Check the client settings and verify with repeated tests.
Is using a public DNS service enough to prevent a leak?
No. A public DNS service can be encrypted and reputable, but it may still receive requests outside the VPN tunnel. Changing the resolver address does not automatically change the route. First confirm that DNS traffic is bound to the VPN interface or protected by the client. Then evaluate whether the resolver’s logging and jurisdiction policies are acceptable to you.
Can browser DNS-over-HTTPS cause a VPN DNS leak?
It can bypass the VPN client’s intended DNS policy, although the request is encrypted between the browser and its selected resolver. Whether that is a privacy problem depends on your goal. If you want all DNS to use the VPN provider’s resolver or to follow one audited policy, review or disable the browser’s independent secure DNS setting. If you keep it enabled, test that browser separately from the operating system.
Does a kill switch stop every DNS leak?
Not necessarily. A kill switch may block ordinary traffic but leave IPv6, background services, or resolver requests outside its rules. Features differ by client and platform. Test the actual disconnect behavior, review whether DNS and IPv6 are included, and use full-tunnel mode while diagnosing. A reliable result comes from configuration, testing, and repeat checks—not from the feature name alone.
In 2026, the most useful DNS leak check remains a repeatable process: establish a baseline, connect the VPN, compare IP and DNS results, test separate applications, inspect IPv4 and IPv6 behavior, verify split tunneling, and confirm what happens when the tunnel drops. If a leak appears, fix the client policy before replacing DNS addresses, then repeat the test after every meaningful network or protocol change. This approach produces a realistic privacy improvement without treating one browser result as a guarantee about the entire device.