A VPN can show “Connected” while some requests still travel outside the intended tunnel. DNS queries may be sent to the local network, an operating-system resolver, or a third-party provider, while WebRTC can expose connection candidates through the browser. These issues do not always mean that the VPN encryption itself has failed. They usually indicate that traffic handling, DNS selection, browser behavior, or IPv6 support needs closer inspection.
This guide explains how to perform a practical DNS leak check, how to distinguish a genuine exposure from a normal test result, and which settings are worth changing. The goal is not to trust a single green status message or a single test page. Instead, combine the client status, resolver addresses, IP information, browser behavior, and a repeat test after every important configuration change.
What a DNS Leak Actually Means
DNS, or the Domain Name System, translates a domain name into an IP address. When you open a website, your device may first ask a resolver which address belongs to that domain. If the query is sent outside the VPN tunnel, the resolver or the network operating it may be able to observe which domains your device is requesting, even when the website connection itself uses HTTPS.
A DNS leak does not necessarily expose the complete content of a webpage. HTTPS can still protect the connection between your browser and the website. However, the DNS request can reveal useful metadata, including the domain being looked up, the approximate time of the request, and the resolver handling it. For privacy testing, the important question is whether DNS traffic follows the route you intended and whether the resolver shown by the test matches your chosen configuration.
VPN clients can handle DNS in several ways. Some send DNS requests through the tunnel to a resolver selected by the service. Others use the operating system resolver but route the resulting traffic through the tunnel. Advanced clients may create a virtual TUN adapter, intercept DNS at the local level, or use encrypted DNS such as DNS over HTTPS or DNS over TLS. Each method can work, but the result depends on correct implementation and on whether another application bypasses the client.
It is also useful to separate three different questions:
- ✅ Does the public IP address match the intended VPN exit region?
- ✅ Are DNS queries handled by the expected resolver rather than the local network?
- ✅ Does the browser expose WebRTC candidates that reveal an unwanted address?
- ❌ Do not treat an IP-address check as proof that DNS and WebRTC are also protected.
A resolver located in the same country as the VPN exit is not automatically proof of a secure configuration, and a resolver with a different organization name is not automatically a leak. Providers may use outsourced DNS infrastructure, anycast addresses, or resolver networks whose visible location differs from the VPN server. Interpret the result together with the service documentation and the client’s DNS settings.
Prepare for a Reliable DNS Leak Test
Testing is more useful when you establish a baseline. First, record which network you are using: home broadband, mobile data, hotel Wi-Fi, workplace Wi-Fi, or another access point. Then close applications that may generate background traffic, such as cloud synchronization, software stores, game launchers, and operating-system update tools. These applications can create additional DNS requests during the test and make the result harder to interpret.
Before connecting the VPN, open the system network information and note the current DNS servers if your operating system displays them. You do not need to publish this information. It is only a reference for comparison. If you are testing on a laptop, also note whether the device has both IPv4 and IPv6 connectivity. A client may handle IPv4 correctly while leaving IPv6 outside the tunnel if IPv6 support or a kill switch is incomplete.
Use a current browser and run the test in a private window if you want to reduce the effect of cached pages and extensions. A private window does not make the connection anonymous, and it does not alter the operating system’s DNS behavior, but it can make a repeated browser test easier to compare. Disable browser extensions that intentionally alter DNS, proxy, or WebRTC behavior unless you are specifically testing them.
For a meaningful comparison, use the same device and browser before and after connecting. If the device changes from Wi-Fi to mobile data during the process, the resolver and IP results may change for reasons unrelated to the VPN. Likewise, changing the selected route at the same time as changing DNS settings creates two variables, so test one major change at a time whenever possible.
3
Main checks: IP, DNS, WebRTC
2
Common DNS encryption methods: DoH and DoT
IPv4
Check separately from IPv6
1
Major setting change per retest
Run the Practical Leak Check
Start by disconnecting the VPN and load a reputable IP and DNS leak testing page. Record the visible public IP, the apparent country or region, and the DNS resolver organizations listed by the page. The exact display differs between test services, so focus on the underlying addresses and organizations rather than a simple pass or fail label.
Check the public IP address
After recording the baseline, connect the VPN using the client’s normal mode. Wait until the client reports an active connection, then refresh the IP test. The public address should change to the VPN exit rather than continuing to show the address assigned by your local network. If the address does not change, first check whether the client is connected only as a local proxy, whether the browser is using a separate proxy extension, or whether the application is excluded by split tunneling.
An unchanged IP does not always mean that every application is bypassing the VPN. Some clients use rules that send selected domains or applications directly, and a browser may have its own proxy setting. Test both an ordinary browser tab and any application that matters to you. If only one application shows the local address, inspect that application’s proxy and network settings instead of changing the entire system configuration immediately.
Inspect the DNS resolver results
Run the DNS portion of the test after the VPN is connected. Look for the resolver addresses and the organizations or network names associated with them. If the results clearly identify the home router, mobile carrier, hotel network, or workplace provider while the VPN is active, that is a strong reason to investigate DNS handling. If the results show a resolver operated by the VPN service or a documented upstream provider, the configuration is more consistent with the intended route.
Multiple resolver addresses are not automatically suspicious. A resolver service may return several addresses for redundancy, and a test page may display more than one result because the browser generated queries over time. The more important warning signs are a resolver that remains tied to the local access provider after the tunnel starts, a mixture of local and remote resolvers, or a change in results when only IPv6 is enabled.
Check WebRTC separately
WebRTC is a browser technology used for real-time audio, video, and peer-to-peer communication. During connection setup, a browser can collect ICE candidates describing possible network paths. Depending on the browser, operating system, permissions, and network design, these candidates may include local addresses, private addresses, server-reflexive public addresses, or relay addresses.
A WebRTC result showing a local private address is not equivalent to exposing your public home IP to every website. Private address ranges are normally meaningful only inside a local network. Nevertheless, the result can disclose information about your device’s network interfaces and may matter in a privacy-sensitive environment. A public address that matches the local connection, rather than the VPN exit, deserves closer attention.
WebRTC behavior varies across browsers and versions. A browser may hide some candidates by default, use mDNS hostnames, or route media through a relay while still showing local interface information in a test. Therefore, do not assume that a browser extension is the only solution. Review the browser’s WebRTC and local-network permissions, and remember that disabling WebRTC can affect meeting tools, calling features, and browser-based collaboration services.
At this point, the test should give you three separate observations: the public IP, the DNS resolver list, and the WebRTC candidate list. Write them down before making changes. The distinction helps prevent an incorrect fix, such as changing DNS when the real issue is an excluded browser, or disabling WebRTC when the actual exposure is an IPv6 route.
Fix Common DNS and Routing Gaps
The safest fix depends on what the test shows. Begin with the least disruptive change and repeat the test after it. Do not enable several “privacy” features simultaneously and then assume the result proves all of them are working. A configuration can appear cleaner while a different application or protocol remains outside the tunnel.
Use the client’s DNS protection option
Many official clients include an option such as “use VPN DNS,” “prevent DNS leaks,” or “route DNS through tunnel.” Enable the setting if it is available, then reconnect rather than merely refreshing the browser. A reconnect forces the client to rebuild routes and may restore the intended resolver configuration.
Check whether the option applies to all traffic or only to the client’s own connection. A local proxy mode may protect applications that respect the operating-system proxy while leaving other applications to use ordinary system networking. A TUN mode can capture a wider range of traffic, but it may require administrator permission and can interact with firewall, antivirus, virtualization, or other VPN software.
Review split tunneling and routing rules
Split tunneling deliberately sends some applications or destinations directly and others through the VPN. This is useful when local services need a local route, but it also means that a DNS query generated by an excluded application may follow the direct connection. Review the rule order, application exclusions, and domain rules. A broad direct rule can override a more specific VPN rule, while a rule based only on a domain may not cover every related hostname used by an application.
When troubleshooting, temporarily use the client’s full-tunnel or global mode if the client provides one. If the DNS result becomes clean in that mode, the problem is likely within the routing rules rather than the remote route itself. Restore split tunneling afterward and add exclusions carefully, testing the specific application each time.
Handle IPv6 and kill-switch behavior
IPv6 deserves a separate check because an application can prefer IPv6 even while the VPN tunnel handles only IPv4. If the client supports IPv6, confirm that its documentation describes how IPv6 traffic is routed. If it does not support IPv6, the practical choices may include disabling IPv6 on the relevant interface, using a client setting that blocks IPv6, or selecting a firewall mode that prevents traffic from escaping when the tunnel is unavailable.
A kill switch is intended to block traffic during connection loss or client shutdown. Its behavior differs between platforms and modes. Test it deliberately only when you understand the consequences: disconnect the tunnel, attempt to load a new page, and check whether traffic is blocked or whether the client falls back to the ordinary network. Do not rely on a kill switch to repair a DNS configuration that is already wrong while the VPN is connected.
Understand encrypted DNS correctly
DNS over HTTPS and DNS over TLS encrypt the connection between the device and the resolver. They can prevent a local network from reading ordinary DNS queries, but encryption alone does not prove that the query follows the VPN route. If the browser sends DoH directly to its own resolver while the rest of the device uses the VPN DNS, the browser and system may produce different results.
For consistent behavior, decide which layer should control DNS: the operating system, the VPN client, the browser, or a TUN-based network core. Avoid letting several layers silently override each other. If a browser has a “secure DNS” setting, compare its automatic, custom, and disabled modes while connected to the VPN. The correct choice depends on the client’s design and the resolver policy you intend to use.
- ✅ Prefer one clearly documented DNS control path instead of several overlapping resolvers.
- ✅ Reconnect the client after changing DNS, TUN, IPv6, or kill-switch settings.
- ✅ Test a browser and an important desktop or mobile application separately.
- ❌ Do not publish your subscription link, full DNS output, or identifiable network details in support screenshots.
Verify the Result on Each Platform
On Windows, inspect the active adapter and DNS entries after connecting. An official client may install a virtual adapter, while Clash Verge or sing-box may use a local mixed port or TUN interface. Confirm that the system proxy points to the intended client and that no older proxy application is still running. If the client offers both system proxy and TUN modes, test them separately because they cover different types of applications.
On macOS, check the active network service and DNS configuration after the tunnel starts. Browser traffic may follow a proxy while command-line tools or background applications use system networking. If a network filter, security product, or another VPN profile is installed, temporarily determine whether it is intercepting DNS. Make one change at a time and restore settings when the test is complete.
On Android, a VPN profile can be created by the official application or by a compatible client. Android’s “Always-on VPN” and “Block connections without VPN” options can improve continuity, but they can also prevent captive portals or local services from working until configured correctly. Check the system VPN status, private DNS setting, and the client’s own DNS option together. A browser-only test is not enough if other apps are important.
On iOS, the system gives the VPN profile significant control, but browser privacy settings and application-specific networking still matter. Shadowrocket and other compatible clients may use a local VPN profile, rules, and remote DNS options. Confirm which rule set is active, whether the device is using a full-tunnel or rule-based mode, and whether a second profile is enabled.
On Linux, NetworkManager, systemd-resolved, a desktop environment, and the client core can all participate in DNS resolution. A sing-box or other TUN configuration may route application traffic while a resolver service continues to listen on a local address. Inspect the active resolver state and interface routes using the tools appropriate for your distribution. The exact commands differ, so use your distribution’s documentation rather than copying a command intended for a different resolver architecture.
Interpret Failed, Mixed, and Inconclusive Results
A failed test is a starting point, not a complete diagnosis. If the public IP is local but DNS appears remote, investigate the client mode, browser proxy, and application exclusions. If the public IP is remote but DNS is local, focus on DNS capture, browser DoH, split tunneling, and IPv6. If both are remote but WebRTC shows a local private candidate, decide whether that disclosure matters for your browser use and adjust WebRTC permissions accordingly.
If results change after every refresh, background applications or resolver caching may be involved. Clear the browser’s relevant network state, close applications that generate traffic, reconnect the client, and run the same test again. A resolver may also return different addresses over time because of load balancing. Compare the organization and route context rather than expecting a single permanent address.
If the test page reports a DNS provider that you do not recognize, check the VPN service documentation before treating it as a leak. Some services use an upstream provider, while some clients intentionally use a public encrypted resolver. The key question is whether the resolver is reached through the protected route and whether its use matches your privacy expectations.
Frequently Asked Questions
Why can a DNS leak appear when the VPN says it is connected?
The connection indicator usually confirms that the client established a tunnel, not that every application and every DNS mechanism is using it. System proxy mode, split tunneling, browser DoH, IPv6, and a second network tool can all create a separate path. Check the client mode and DNS settings, then reconnect and repeat the test.
Is a public DNS provider automatically a privacy leak?
No. A public resolver can be used intentionally, and a VPN service may document it as part of its infrastructure. The concern is whether DNS requests are sent outside the intended tunnel or to a resolver you did not choose. Compare the result with the client’s documentation and test again after changing networks.
Should WebRTC be disabled completely?
Not always. Disabling or restricting WebRTC may reduce candidate exposure in a browser, but it can affect web meetings, calls, screen sharing, and peer-to-peer features. First determine whether the test shows only a local private address or an unwanted public address. Then choose browser permissions or a privacy setting that fits your actual use.
When should the leak test be repeated?
Repeat it after installing or switching clients, importing a new subscription, changing DNS or IPv6 settings, enabling split tunneling, moving between Wi-Fi and mobile data, and updating a browser or operating system. Routine checks are especially useful after a major network change because the device may recreate resolver or route settings.
DNS privacy works best as part of a wider configuration routine. Keep the client updated, protect subscription credentials, avoid running competing tunnel tools, review route rules, and verify important applications separately. If you want to start with an official client and a supported subscription workflow, use the platform instructions rather than importing a configuration into an incompatible application.