A VPN can show “Connected” while some name lookups or browser requests still use a different network path. A DNS leak test checks which resolvers answer domain-name requests; a WebRTC check looks for network addresses that a browser may expose through real-time communication features. These checks help identify unexpected routing, but a result is not a complete privacy audit: it does not prove that every app uses the tunnel, that a website cannot identify you in other ways, or that a VPN provider follows any particular data policy.
The most useful approach is to test under controlled conditions, record what you see, and change one setting at a time. Run checks with the VPN connected, compare them with a disconnected baseline, and repeat them after changing networks or client settings. If a result looks concerning, first distinguish an actual route outside the tunnel from a resolver or address that is simply labeled differently by a test website.
3
Useful checks: DNS, WebRTC, and IP routing
2
Common leak surfaces: name lookups and browser traffic
1
Change at a time when troubleshooting
What DNS and WebRTC tests can show
DNS, or the Domain Name System, translates names such as example.com into addresses that a device can connect to. When an app asks the operating system to resolve a name, the request goes to a DNS resolver. Depending on the operating system, VPN client, browser, and network configuration, that resolver might be provided by the VPN service, the local network, an internet provider, or a separately configured encrypted DNS service.
A DNS leak test reports the resolvers it can observe answering its test queries. If the VPN is connected and the test consistently identifies a resolver associated with your current internet provider or local network, that is worth investigating. However, resolver names and locations in test results are often inferred from public databases. A resolver may be registered in a different city or country from the VPN exit address, and that mismatch alone does not prove a leak. Focus on the resolver identity and the route the request took, not only on a map pin or country label.
WebRTC is a set of browser technologies used for real-time audio, video, and peer-to-peer communication. During connection setup, a browser may gather network candidates so that devices can establish a media path. A test page can sometimes display public or local address information gathered during that process. Modern browsers may mask local addresses, for example by using mDNS names, and behavior differs by browser and configuration. A visible local address is not automatically the same thing as a public IP escaping the VPN.
Keep the scope of each test in mind. A browser-based check says something about that browser in that moment. It does not verify a separate desktop application, a game, a command-line tool, or every connection made by a phone. Likewise, a clean result on one network does not guarantee that DNS and routing will behave identically on another network.
Prepare a reliable test
Before testing, update the VPN client and browser through their normal trusted update channels, then note the current setup. Record the device, operating system, browser, VPN mode, selected route, and whether custom DNS, browser secure DNS, or split tunneling is enabled. This simple record makes it easier to identify which change affected the result. Do not post screenshots containing account details, subscription links, or other private information in a public support forum.
Choose a test page you trust and read its instructions before granting permissions. A DNS test usually asks the browser to load a set of unique names and then reports the resolvers that handled them. A WebRTC test may inspect browser connection candidates. These pages do not generally need access to your VPN account. Avoid installing an unknown extension or app just to run a basic check, and close other test pages if they keep generating background requests.
First check your public IP using a reputable IP-check page or the site’s IP lookup page. With the VPN connected, the displayed public address should normally correspond to the selected VPN exit rather than your ordinary connection. Use the same browser and network for the following checks. If you need setup guidance, see the quick-start guide before changing advanced settings.
Next, run a DNS test more than once while the VPN remains connected. A different set of resolvers on a later run is not automatically evidence of a leak: some services use multiple resolvers, and test pages can select different probes. Look for a consistent pattern, such as a resolver associated with the local ISP appearing alongside the VPN connection. Then run the same check with the VPN disconnected, if it is safe and appropriate to do so. The baseline can help you recognize your ordinary network’s resolver, but do not confuse the baseline result with the connected result.
Finally, run a WebRTC check in the same browser. Compare any public address shown with the address reported by the IP check. Pay attention to whether the page identifies a public address from the local connection, a VPN exit address, a private LAN address, or a browser-masked local candidate. Repeat after reloading the page and, if possible, in a second browser profile without extensions. A single unexpected line is a reason to investigate, not a reason to assume every app is exposed.
Run the checks step by step
- Establish the connected state. Connect the VPN and wait until the client reports that its tunnel or proxy is active. Confirm the selected mode and route. A system-proxy mode may cover only applications that honor the operating system’s proxy settings; a tunnel or virtual network adapter mode can handle a different set of traffic. The connection indicator alone does not establish which applications are covered.
- Check the public IP. Open an IP-check page in the browser you plan to test. If it shows your normal public address instead of the VPN exit, pause here and investigate the connection mode, routing rules, or browser proxy settings before interpreting DNS results.
- Run a DNS test. Use the test page’s standard or extended test, if available, and note the resolver names, organizations, and reported regions. Run it again after the first result completes. Record whether the same resolver group appears consistently.
- Run a WebRTC test. Look for public candidates and compare them with the IP-check result. Do not treat a private address such as a local network address, or an mDNS-style hostname, as proof that your public IP bypassed the VPN.
- Compare a controlled baseline. Disconnect the VPN only if doing so is acceptable for your circumstances, then repeat the IP and DNS checks. Reconnect immediately afterward. The comparison helps identify which results belong to your ordinary connection, but it should not be used to expose sensitive activity or to test on a network you do not trust.
- Change one setting and repeat. If you find a reproducible discrepancy, change one relevant setting—such as browser secure DNS, IPv6 handling, or the VPN’s DNS option—then rerun the same checks. If several settings change at once, it becomes difficult to know which one corrected or caused the result.
Keep a short before-and-after note rather than relying on memory. Include the test time, network type, client mode, resolver names, and which public address the browser displayed. You do not need to preserve full browsing histories or share identifiable data to describe a routing issue. If results vary, repeat the test after reconnecting the VPN and after moving between networks, such as home Wi-Fi and a mobile hotspot, because each environment can supply different DNS and IPv6 settings.
Interpret unexpected results
| Observation | Possible explanation | What to verify next |
|---|---|---|
| DNS test reports resolvers associated with the local ISP | The operating system, browser, or VPN configuration may be sending DNS outside the intended route; the test’s resolver database may also be imprecise | Repeat the test, compare the disconnected baseline, and review the VPN DNS and split-tunnel settings |
| DNS resolver region differs from the VPN exit region | The resolver may be centrally located, anycast, or labeled using an outdated public database | Check the resolver organization and consistency across runs; do not infer a leak from geography alone |
| WebRTC displays a public address that matches the ordinary connection | The browser may be using a path outside the VPN, or the result may be stale or misread | Reload the test, confirm the connected public IP, disable extensions temporarily, and review VPN coverage for the browser |
| Only a private or masked local candidate appears | The browser may be reporting a LAN address or masking it with an mDNS name | Check whether any public candidate matches the ordinary connection before treating it as an exposure |
| Results differ between browsers or networks | Secure DNS, extensions, proxy preferences, IPv6, or network-provided settings may differ | Compare browser settings and repeat each test under the same connection conditions |
DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt DNS queries between a device or browser and a resolver. Encryption protects the query on that segment, but it does not by itself ensure that the request uses the VPN tunnel. A browser’s secure DNS setting can send queries directly to its chosen resolver, depending on the browser and operating-system integration. Conversely, a VPN may route that encrypted connection through its tunnel. The relevant question is both which resolver receives the query and which network path carries it.
IPv6 deserves a separate check. Some internet connections provide IPv6 while a VPN configuration handles only IPv4, or handles IPv6 differently. If an IP test reports an address that belongs to the ordinary network, review whether the client supports IPv6 tunneling or has a setting to block IPv6 outside the tunnel. Do not disable IPv6 system-wide as a first response: that can disrupt local services or connectivity, and it may conceal rather than correct a client configuration problem.
Fix common DNS and WebRTC issues
Start with the least disruptive checks. Reconnect the VPN, confirm that the intended route is selected, and verify that the browser is not excluded by a split-tunneling rule. If the client offers a DNS protection or “use VPN DNS” option, review its description and enable it only if it matches your intended setup. Menu names vary by client and operating system, so do not copy a setting name from another product without confirming what it controls.
Check for competing network tools. Running multiple VPN clients, proxy applications, DNS filters, or security products that install network adapters can create conflicting routes or resolver settings. Temporarily pause one nonessential tool at a time, following its own instructions, and retest. Also inspect system proxy settings if you use a proxy-based client. A browser that has a separate proxy configured may bypass the system setting or send traffic to a different endpoint.
For browser DNS behavior, review the browser’s secure DNS or “DNS over HTTPS” setting. If the browser is configured to use a custom provider, test with the default or system setting and compare results. This is a diagnostic comparison, not a recommendation to leave DNS unencrypted: choose a final configuration that is compatible with your VPN and that you understand. Extensions that filter requests, change proxy routing, or protect WebRTC can affect test results. Disable them temporarily for diagnosis, then enable them one by one to identify whether an extension changes the outcome.
For WebRTC, first update the browser and test with a clean profile. If a public address outside the VPN remains visible, inspect whether the VPN mode covers the browser and whether the client offers a WebRTC-related protection feature. Browser controls and extension behavior differ, and blocking WebRTC entirely can disable voice or video calling features. Apply the narrowest setting that addresses the observed issue, then check both the test page and the sites or apps that rely on real-time communication.
If the discrepancy persists, save the minimal diagnostic details: operating system, client version, connection mode, protocol if shown, whether IPv6 is available, browser name, and the non-sensitive resolver organization or address category reported by the test. Do not send a private subscription URL or account password. Provide the information through the provider’s official support route and ask which DNS and IPv6 behavior is expected for that client mode. On managed work or school devices, consult the administrator before changing network settings.
- ✅ Confirm the browser is included in the VPN’s traffic coverage before changing DNS.
- ✅ Repeat a test after each setting change and keep the network conditions consistent.
- ✅ Review IPv4 and IPv6 results separately when the test page reports both.
- ✅ Use a clean browser profile to distinguish browser extensions from VPN behavior.
- ❌ Do not assume a resolver in another region proves that DNS left the tunnel.
- ❌ Do not install unknown “leak fixer” software or change several network settings at once.
FAQ
What counts as a DNS leak?
In practical terms, a concern exists when DNS requests made while the VPN is connected are reproducibly sent through an unintended route or handled by an unintended resolver. A resolver’s displayed location alone is not enough to establish that. Compare the connected result with a baseline, confirm the resolver identity where possible, and repeat the test.
Does WebRTC always reveal my public IP?
No. The result depends on the browser, its settings, the VPN’s coverage, and the network. A test may show a VPN exit address, a private local address, a masked local candidate, or a public address associated with the ordinary connection. Interpret the address type and compare it with a current IP check rather than treating every WebRTC candidate as a public-IP leak.
Should I turn off secure DNS?
Not automatically. Secure DNS encrypts queries between the browser and its resolver, but its route depends on the browser and VPN configuration. Temporarily changing the setting can help isolate a problem. For the final configuration, make sure the resolver and route match your privacy and compatibility needs, then repeat the checks.
Why do two test pages disagree?
Test pages may use different probes, resolver databases, and WebRTC detection methods. Browsers can also use different DNS and proxy settings. Repeat the checks in the same browser and network, compare the actual addresses and resolver organizations reported, and use a second reputable test as corroboration rather than treating either result as definitive.
Good leak testing is a repeatable troubleshooting process: verify the public IP, inspect DNS and WebRTC separately, compare results under controlled conditions, and adjust one setting at a time. A consistent result that matches the intended VPN route is more informative than a single “secure” badge, while an unexplained discrepancy is best handled by checking client coverage, DNS configuration, browser behavior, and IPv6 before drawing conclusions.