A VPN can show “Connected” while DNS requests or WebRTC traffic still reveal information outside the intended tunnel. This does not necessarily mean the VPN is useless or that your public IP is fully exposed; it usually means that different traffic types are following different paths. DNS is responsible for translating domain names into IP addresses, while WebRTC is a browser technology that can discover connection candidates for real-time audio, video, and data sessions. Each has its own leak conditions and its own troubleshooting method.
A reliable check therefore needs more than one website or one screenshot. First record your normal network behavior, then connect the VPN, test DNS and WebRTC separately, change one setting at a time, and repeat the same checks. This guide explains what to observe, how to distinguish a browser issue from a VPN configuration issue, and how to avoid claiming that a single successful test proves complete privacy.
What DNS and WebRTC can reveal
When you type a domain name into a browser, the device normally asks a DNS resolver which IP address belongs to that domain. The resolver may be supplied by your internet provider, local router, operating system, browser, VPN client, or a manually configured encrypted DNS service. If the VPN carries ordinary web traffic through its tunnel but DNS requests continue to use the local router or internet provider, an observer handling that DNS service may still see the domain lookups. The requested domain is not the same as the full page content, but it can still reveal browsing patterns.
A DNS leak is usually a routing or resolver-selection problem. Common causes include a VPN client that does not install DNS rules correctly, an operating system that keeps a previous resolver active, split tunneling that excludes the browser or DNS process, an IPv6 path outside the tunnel, or a browser using its own secure DNS setting. Public DNS services can be useful, but simply choosing a well-known resolver does not prove that the request is traveling through the VPN. The path matters as much as the resolver’s name.
WebRTC is different. Browsers use it to establish peer-to-peer communication for meetings, calls, streaming tools, and collaborative applications. During connection setup, a browser may gather several candidate addresses, including local interface addresses, private network addresses, and public server-reflexive addresses obtained through network traversal services. Modern browsers have added restrictions and privacy controls, but the exact behavior depends on the browser, operating system, permissions, extensions, and application.
A WebRTC result can therefore show an address that is not the same as the address displayed by an ordinary IP-check page. That does not automatically mean the VPN tunnel has failed. It may be a local address with no direct internet reachability, an address associated with a network interface that the application can see, or a public candidate exposed by a browser path that the VPN does not control. The correct response is to identify the address type and repeat the test after changing browser or client settings.
2
Leak categories
3
Core verification stages
5
Common test surfaces
The numbers above describe the structure of a practical check, not a guarantee of privacy. DNS and WebRTC should be tested independently, and each result should be interpreted alongside the VPN client’s route, DNS, IPv6, and browser settings.
Prepare a reliable baseline before connecting
Testing is easier when you know what the device does without a VPN. Disconnect the VPN and close applications that may actively use network connections, especially browsers with many open tabs, video-call software, download tools, and virtual machines. Record the DNS resolvers reported by a reputable DNS test page, note the public address shown by a standard IP page, and run a WebRTC check in the browser you actually use. This baseline helps distinguish an address that already existed before the VPN from one that appeared only after the tunnel was enabled.
Use the same browser profile for the before-and-after comparison. Private browsing mode may have different extensions or permissions, and another browser may use a separate secure DNS policy. If your device has both Wi-Fi and Ethernet, note which interface is active. Also record whether you use a mobile hotspot, a home router, a corporate network, or another managed connection. These environments can provide different IPv4, IPv6, DNS, and NAT behavior.
Do not treat a single test page as an authority. Test pages are useful diagnostic tools, but they can differ in how they identify resolvers, how they request WebRTC candidates, and how they interpret IPv6. A result that says “no leak” may only mean that the page could not observe a particular type of exposure. Compare the resolver organization, address family, and route behavior instead of focusing only on a colored status label.
Record the baseline
- ✅ Note the public IPv4 and IPv6 results, if the test page displays both.
- ✅ Record every DNS resolver organization and address reported by the test.
- ✅ Run the WebRTC check in the browser profile used for normal browsing.
- ✅ Keep the network type and active interface unchanged during comparison.
- ❌ Do not paste a private subscription link or account credential into a testing page.
After recording the baseline, connect the VPN using the normal client or compatible configuration. Wait until the client reports a completed connection, then check whether the client has an option such as “prevent DNS leaks,” “use VPN DNS,” “block connections outside the tunnel,” or “disable IPv6.” The exact label varies by platform. Do not enable every option at once, because changing several controls makes it difficult to identify which one changed the result.
How to test for DNS leaks
Begin with the browser-based DNS test. Run the standard or extended test offered by the testing service, then compare the reported resolvers with the baseline. A common indication of a possible leak is that the same local router or internet-provider resolver remains visible after the VPN connects, while the VPN client claims to route DNS through the tunnel. Another indication is that DNS results continue to come from a resolver associated with the physical network even though the VPN’s documentation says it provides its own resolver.
Interpret the result carefully. A resolver’s location or corporate name is not by itself proof of a leak. Some VPN providers intentionally use a third-party DNS infrastructure, and some resolvers may be anycast services whose visible organization does not match the VPN brand. The useful questions are: did the resolver set change as expected, does the VPN documentation explain the resolver, and does the result remain consistent across repeated tests after reconnecting?
Next, check the operating system and browser configuration. On desktop systems, inspect the active network adapter and DNS settings. A manually configured resolver may remain in place even when the VPN connects. On mobile devices, look for a system-level private DNS or secure DNS setting that can coexist with the VPN. In browsers, encrypted DNS may be enabled independently from the operating system. That feature is not inherently unsafe, but it can create a separate path if the VPN client does not account for it.
Split tunneling deserves special attention. If the browser is excluded from the VPN, its DNS behavior may also be outside the tunnel, depending on the client and operating system. Some clients apply split rules by application, while others apply them by destination or process. Temporarily disable split tunneling and reconnect before testing again. If the DNS result changes, the configuration rather than the provider’s entire tunnel may be the relevant cause.
IPv6 can create another difference between the expected and observed result. A VPN may protect IPv4 traffic correctly while leaving an IPv6 route active, or it may support IPv6 only on certain protocols and platforms. If the baseline includes IPv6 and the connected test still reports the same physical-network IPv6 path, check whether the client supports IPv6 protection. Do not assume that disabling IPv6 is always the best answer; it can affect applications and local network behavior. Use the client’s documented control where available.
| Observation | Possible explanation | Next diagnostic step |
|---|---|---|
| The local resolver remains visible | DNS routing was not applied, or the browser uses an independent resolver | Check VPN DNS protection, browser secure DNS, and split tunneling |
| A different resolver appears | The VPN may be using its own resolver or an explained external DNS service | Compare the result with the provider’s documentation and repeat after reconnecting |
| Only IPv6 results look unchanged | IPv6 may bypass the tunnel or use a separate client path | Review IPv6 support and test with the documented protection option |
| The result changes between browsers | One browser may have independent encrypted DNS or extension rules | Compare browser settings and repeat with extensions temporarily disabled |
How to test WebRTC exposure
Keep the VPN connected and use a WebRTC test that lists the candidates detected by the browser. Compare those candidates with the baseline rather than asking only whether the page says “protected.” Separate local or private addresses from publicly routable addresses. A local address may identify an interface or local network pattern without being directly reachable from the internet. A public candidate that matches the physical connection, while the VPN’s public address is different, deserves further investigation.
Run the test in the browser used for normal activity, then repeat it in another supported browser if possible. Browser privacy behavior is not identical. Some browsers limit local address exposure, some offer policies that alter candidate handling, and some extensions modify WebRTC behavior. A browser setting that prevents certain candidates may improve privacy but can also interfere with calls, meetings, or peer-to-peer applications. Test the setting with the services you need rather than assuming the most restrictive option is always suitable.
Browser extensions should be tested carefully. An extension that claims to prevent WebRTC leaks may only change JavaScript-visible information, not every network behavior. Another extension may inject scripts, change permissions, or conflict with a video-call application. Disable extensions temporarily, restart the browser, and compare the result. If the exposure disappears only after an extension is disabled, inspect that extension’s permissions and decide whether its function is worth the trade-off.
Also distinguish a browser-generated candidate from an actual connection leak. A diagnostic page may display an address that the browser knows, even when application traffic is still routed through the VPN. To investigate, compare the candidate with the physical interface, the VPN interface, and the public address shown by an ordinary IP test. If the same physical public address appears repeatedly while the VPN is connected, test the VPN client’s kill switch and WebRTC-related guidance before drawing a conclusion.
Fix the cause without changing everything at once
Start with the least disruptive change. In the VPN client, enable its documented DNS protection or VPN DNS option, reconnect, and repeat the DNS test. If the client offers a kill switch or “block outside connections” mode, enable it when you need protection against temporary tunnel drops. A kill switch is not the same as DNS protection: one controls what happens when the tunnel is unavailable, while the other concerns how name-resolution requests are routed. Some clients combine these features, but they should still be tested separately.
For browser-related WebRTC behavior, review the browser’s privacy and WebRTC controls. If the browser provides a setting that limits local network exposure, test it with websites that use calls or real-time collaboration. If a browser does not offer a suitable control, consider using a browser with clearer WebRTC privacy settings for sensitive work, but do not assume that changing browsers fixes the VPN’s system-wide routing.
If the problem appears only with a third-party compatible client, inspect the imported configuration and client mode. Clash Verge, sing-box, Shadowrocket, and official VPN clients may expose different controls for DNS, TUN mode, system proxy, routing rules, IPv6, and WebRTC-related traffic. A system proxy can affect browser requests without routing every application. A TUN-based mode may capture more traffic, but its behavior depends on permissions, routing rules, and the operating system. Protocols such as WireGuard, Shadowsocks, VMess, Trojan, and Hysteria2 can have different client implementations; the protocol name alone does not prove that DNS or browser candidate traffic is protected.
Do not run two independent proxy or VPN clients at the same time while diagnosing a leak. Their virtual interfaces, DNS rules, and route priorities can conflict. Disable one client completely, reconnect the other, and test from a clean state. If you use a router-level VPN together with a browser extension, test each layer separately. Otherwise, a browser result may be attributed to the wrong component.
- ✅ Change one DNS, browser, IPv6, or routing setting at a time.
- ✅ Reconnect the VPN after changing a network or client setting.
- ✅ Test both normal browsing and any browser application that uses WebRTC.
- ✅ Keep a note of the setting that changed the observed result.
- ❌ Do not claim that a VPN prevents every form of tracking or identification.
- ❌ Do not treat a browser extension as a replacement for correct VPN routing.
Verify the fix and understand its limits
After making a change, repeat the baseline process in the same order: connect the VPN, confirm the client status, test the public address, test DNS, and test WebRTC. Reconnect once more and repeat the tests because some problems appear only during connection establishment or after a network change. Move between Wi-Fi and another trusted network only when you are ready to test roaming behavior; a fix that works on one network may not behave identically on another.
Check the result on every platform where you rely on the VPN. Windows, macOS, Android, iOS, and Linux may use different DNS APIs, browser policies, permission models, and VPN integration methods. A configuration imported into Clash Verge or sing-box may also behave differently from the same account used in an official client. Keep a separate record for each device and client instead of treating one successful desktop test as proof for all devices.
Privacy testing has boundaries. DNS and WebRTC checks do not measure account security, malware, browser fingerprinting, cookies, application telemetry, traffic correlation, or the policies of the service you use. A VPN can reduce exposure on a network path while websites still identify you through a signed-in account or browser storage. Similarly, a clean test result means that the tested page did not observe the specified leak under those conditions; it does not promise anonymity in every application or network.
The most useful outcome is a repeatable configuration: you know which resolver appears, which address classes WebRTC reports, which browser settings are active, whether IPv6 is handled, and how the client behaves after reconnecting. Keep the VPN application and browser updated through trusted channels, review imported configurations before applying them, and remove old clients that may continue installing routes or DNS settings in the background.