Seeing the expected IP address on a lookup page can make it seem as though every setting is working. In fact, that result only tells you which source address the lookup service observed for that web request. DNS resolution, WebRTC traffic and IPv6 connections may use different paths.
The key to determining whether an IP or DNS leak has occurred is not “how many addresses appear on the page,” but whether any information or traffic leaves the path you intended to protect. Seeing a private address, a public DNS, or a region name different from your exit cannot alone be taken as proof of a leak.
This article is suitable for checking your own device, browser, and network settings. Test results only reflect the currently observable environment and should not be interpreted as a privacy guarantee for all applications on the device.
First, determine which traffic you want protected
Before testing, answer a simple question: have you configured a browser proxy, a system proxy, or a VPN that takes over network routing?
Their coverage may differ. A browser extension doesn’t necessarily handle other applications; a system proxy doesn’t guarantee that every protocol follows the proxy settings. Whether a VPN covers IPv6, DNS, and split-tunnel traffic also depends on its implementation and configuration.
If you intentionally allow a certain application to connect directly, it using the original exit is not necessarily a fault. But if your expectation is “all outbound traffic uses the designated exit,” the same phenomenon requires further investigation.
It’s advisable to keep a baseline first: your public IPv4 and IPv6 without the target configuration enabled, and the resolvers observable in DNS tests. The baseline is for before-and-after comparison and doesn’t need to be published; especially in corporate networks, you shouldn’t casually expose internal addresses and configuration screenshots.
WebRTC: Distinguish candidate addresses before judging egress exposure
WebRTC enables real-time audio, video, and data communication in the browser. To establish connections, it gathers possible network paths, known as ICE candidates.
MDN’s candidate types distinguish host, srflx, prflx, and relay, among others. For ordinary users, the most important distinction is between local interface information, information observed after address translation, and relay server addresses. Whether candidates are exposed to web pages is also influenced by the browser’s WebRTC privacy policy.
Result in test | More reasonable interpretation |
|---|---|
Private IPv4 such as 192.168.x.x, 10.x.x.x | May reflect LAN information; cannot conclude public egress leak from this alone |
.local names | May be browser privacy handling for local candidates, not the real public IP |
Public address matching the expected exit | Consistent with this test’s expectation, but doesn’t mean all traffic has been verified |
Public address confirmed to belong to the original network | If it was supposed to be protected, this is an exposure signal worth verifying |
TURN relay address | Indicates the candidate is relayed, not direct proof of the user’s original public address |
WebRTC exposing the original network address is not imaginary. RFC 8828 discusses IP information exposure in scenarios such as split-tunnel VPNs, multiple network interfaces, and application proxies. But browser implementations, permissions, and network policies affect actual behavior, so you can’t directly apply test conclusions from old browsers to all devices.
In the WebRTC leak test, if you see a public address that doesn't match expectations, first compare it with your baseline, then verify which network it belongs to. Don't jump to conclusions just because a second address is shown, and don't equate "no candidates collected" with absolute safety—blocked communication or an incomplete test can also produce empty results.
DNS: What does seeing your ISP's resolver mean?
Before a browser can access a domain, it usually needs to obtain the address corresponding to that domain. DNS leak testing focuses on whether this step follows the expected resolution policy and whether a party that shouldn't see the query might have seen it.
Common DNS leak tests make the browser request a set of test domains, then observe the query source from the authoritative DNS side. The page typically shows the exit point in the recursive resolution chain, not a direct reading of your device's DNS configuration.
This means that after detecting a DNS address, you can't immediately conclude, "This is my local DNS server." Recursive forwarding, public resolver services, and Anycast deployments can all make the results more complex than what the system settings show.
In particular, don't just look at the country name: the geolocation of the DNS exit is different from that of the web exit, and it alone isn't sufficient to prove a leak. You should further verify the resolver operator, how the service routes queries, and whether it matches your intended configuration.
If your expectation is to use only the VPN-specified resolution path, but tests consistently show your original ISP's resolver exit, that's a signal worth investigating. If you deliberately configured a public DNS service, seeing that service itself is not necessarily an anomaly.
You can use the DNS leak test for before-and-after comparison. When multiple resolvers appear, first check whether there is overlap or simultaneous use among the browser's Secure DNS, the operating system's DNS, the VPN DNS, and split-tunneling settings.
Does enabling DoH mean no leaks?
DoH addresses the encryption of DNS query transport, not all routing and trust issues. Cloudflare's explanation describes how DNS queries are encapsulated in HTTPS, but "transport is encrypted" does not equal "queries definitely went through your specified VPN."
The resolver service still processes your queries. Some deployments may also use EDNS Client Subnet to pass client network prefix information in recursive queries; this mechanism and its privacy implications are described in RFC 7871. When ordinary DNS tests don't explicitly provide results for this, don't assume they have checked ECS.
IPv6: A correct IPv4 exit doesn't mean the other address family is correct
Many networks provide both IPv4 and IPv6. If a proxy or VPN only handles IPv4, and the device can still use IPv6 directly through the original network, then IPv6-capable destinations may observe a different exit path.
However, "IPv4 and IPv6 addresses are different" is normal. They belong to different address families, and you can't judge whether protection is working by how similar the address strings look.
What you should compare is whether the network ownership and actual routing of both protocols match your expectations, and whether IPv6 still points to the original network. Changes in IPv6 temporary addresses alone do not automatically indicate a leak.
In the Browser environment check, look at the available IPv4 and IPv6 information separately. If the IPv6 test doesn't complete, you can only mark it as unconfirmed; that's different from "confirmed IPv6 unavailable."
A repeatable troubleshooting sequence
1. Compare before and after on the same device and browser
Record the exit information when the target configuration is not enabled, then enable the configuration and test again. During testing, avoid changing Wi-Fi, browser proxy, and DNS at the same time, otherwise it's hard to tell which step caused the change.
2. Check web, WebRTC, DNS, and IPv6 separately
Record the four sets of results separately: the public exit observed by the web, WebRTC candidates, DNS query source, and IPv6 reachability and exit. Don't use the green status of one item to represent the others.
3. Locate settings by abnormal path
If WebRTC exposes your original network's public address, check proxy coverage, WebRTC policy, and whether the VPN uses split tunneling. If DNS doesn't match expectations, check browser and system resolution settings, and the DNS fallback behavior after VPN disconnect. If IPv6 still goes through the original network, check the VPN's IPv6 support and related routes.
Change only one relevant option at a time, then retest. When dealing with long-term business issues, keeping timestamps, configuration states, and result summaries is usually more helpful for pinpointing than just a screenshot of a red warning.
4. Check behavior after reconnection
Network reconnection, device wake from sleep, and VPN reconnection can all change paths. When possible, check again after these normal usage scenarios. A single passing test only proves that the behavior observed at that time met expectations; it cannot replace ongoing stability verification.
Don't rush to disable everything
Disabling WebRTC outright may affect browser calls and meetings; disabling IPv6 outright may mask configuration issues. Whether to do so should depend on your actual needs and acceptable loss of functionality, not just to make the test page show fewer lines.
A more prudent approach is to first clarify the scope of protection, then fix the corresponding routing, resolution, or browser settings. Enterprise devices should also follow administrator policies and not bypass established network and security configurations on their own.
Can a private window prevent these leaks?
Do not treat incognito mode as a network tunnel. It mainly changes how local session data such as browsing history and cookies are handled, and does not naturally take over DNS, WebRTC, or IPv6 routing.
If the original IP cannot be detected, does that mean complete anonymity?
No. The IP path is only part of privacy. Account logins, cookies, browser fingerprinting, and voluntarily submitted information can all allow a service to identify or correlate a visit.
After completing this set of checks, a reasonable conclusion should be: “Under the current configuration and test conditions, the observed network path is as expected.” This is more accurate than a blanket “zero leakage, complete anonymity” with no scope, and better guides subsequent use.
Split-routing scenarios: How to interpret four different results on the same device
Suppose you have configured domain-based routing, or are running a VPN alongside a local direct connection. In one test, the HTTP egress shows the address of proxy node A, the DNS test shows recursive server B's address, the WebRTC candidates include a public address C from the original network and a TURN address D, and IPv6 is still using the ISP's route. Such results are easily misread as “four leaks.” In reality, they may simply be on different paths. The key is not how many IPs appear, but whether these paths match your expectations.
In this example, if you only want web HTTP traffic to go through the proxy, egress A may be consistent with the configuration; whether DNS is direct needs separate confirmation. If the WebRTC candidates visible to the page include the public address C from the original network, that already shows the page can learn C in this test—it does not need to wait for a media connection to actually use it to count as exposure. Whether this is an unintended leak depends on whether you require that address to be hidden from that page.
mDNS candidates especially need to be distinguished. Browsers often use randomly generated .local names to represent local network interfaces, avoiding direct exposure of real LAN information. Seeing an entry like “2f8c…local” on a WebRTC test page should be understood as privacy handling for local candidates, not your public IP or hostname. Treating it as evidence of a leak is a common misjudgment. If a public address from the original network is also present, and the application should have been protected by the tunnel, that is an exposure signal worth verifying.
IPv6 must also be recorded separately. If the IPv4 egress goes through proxy A, but IPv6 still uses the ISP's direct link, dual-stack target sites may observe your ISP address via IPv6, simultaneously or preferentially. This is not necessarily caused by proxy misconfiguration; many clients that use CIDR-based routing or proxy only IPv4 do not take over IPv6 routing by default. Do not rush to conclude “IPv6 leak”; first confirm whether the VPN or proxy claims to cover IPv6, then check whether the local system has an IPv6 default route pointing to the tunnel.
Differences in DNS recursive servers can be assessed with the help of ASN and RDAP information. If the address of B belongs to a public resolver you deliberately specified, it is normal even if it differs from the HTTP egress; if it belongs to your original ISP and you intended resolution traffic to enter the tunnel, that is an anomaly to investigate. Anycast-deployed resolvers may show different nodes in different regions, so a change in geographic location alone does not prove DNS is direct. Focus on the operator name, ASN ownership, and whether the test domain observes query sources on the authoritative side that do not match expectations.
When encountering such coexistence of multiple egresses, the first step is not to disable features, but to write down your “expectations.” Which applications should use the proxy, which should go direct; who should handle DNS; whether IPv6 should be covered by the tunnel or allowed direct; whether WebRTC should collect local candidates when the VPN is connected. After completing a measurement, compare against the baseline. If an item does not match expectations, return to the specific settings and adjust one at a time. Change only one variable at a time—for example, change DNS first, then retest—to determine which rule caused the difference.
Repeated measurement and disconnect recovery: Making test results verifiable again
Passing a test once only means the environment met expectations at that time. VPN reconnection, system wake, or browser permission changes can alter the path. It is recommended to repeat measurements after normal usage scenarios: after disconnecting and reconnecting the VPN, after sleep/wake, and after switching between Wi-Fi and mobile networks, check the HTTP egress, DNS source, WebRTC candidates, and IPv6 status separately. The stability of these four results is more informative than a single all-green test.
Keep only one variable change per measurement. For example, if today you only change WebRTC-related settings, keep DNS and VPN settings unchanged; tomorrow if you only change IPv6, retest all four items. If you simultaneously adjust the browser's “secure DNS,” proxy routing, and system IPv6 switch, intermittent behavior will be hard to trace to a specific change. Recording time, configuration state, and a summary of results is more useful for long-term maintenance than a screenshot of red warnings.
Browser permissions directly affect WebRTC candidates. If a site does not have microphone or camera permission, the browser may not collect local interface candidates; once audio/video is authorized, candidate collection may expand. Therefore, test WebRTC before and after granting permission to observe changes in the candidate list. Do not conclude that there is no WebRTC exposure path just because the page shows no candidates when permission is denied—that mistakes “not measured” for “protected.” Likewise, incognito windows do not change network routing and cannot be used as an anti-leak measure.
IPv6 should be handled explicitly according to requirements: if full dual-stack protection is needed, choose and configure a tunnel that supports IPv6, and verify actual routing and firewall; if the product only supports IPv4, confirm what blocking or bypass policy it has for IPv6. Adding only a default route does not guarantee all applications and disconnect states are protected. Disabling IPv6 globally may also affect compatibility; first understand client capabilities and keep a recoverable configuration, then verify normal, reconnect, and disconnect states separately.
Disconnect recovery acceptance should include a “kill switch” policy. If a VPN claims to block all outbound traffic after disconnection, test whether DNS queries also fail during network interruption, rather than falling back to the original network resolver. Some implementations cut only IPv4 TCP but allow IPv6 or DNS to continue on the original path; this “partial protection” leaves an observation window. You can confirm by triggering disconnect events separately and observing the behavior of HTTP, DNS, and IPv6 requests.
A “miss” in test results does not equal “safe.” If IPv6 shows as unreachable because the network does not support it, it can only be labeled “unconfirmed,” not interpreted as “confirmed no IPv6 leak.” A path can be called passed for this verification only if the test was sent and the result matched expectations. Each measurement should note the test conditions, such as browser version, proxy mode, VPN protocol, and network environment, to provide a basis for later reproduction.
In more complex environments, CGNAT may alter the mapping between public egress and internal addresses. In such cases, refer to Public IP Lookup and CGNAT: How to Check Your Connection to understand NAT layers. Some security detection tools may falsely report normal phenomena as VPN or proxy characteristics; consult IP Flagged as a VPN or Proxy? How to Check a False Positive to further interpret tool outputs. Combining these resources can reduce misjudgments caused by address types or detection logic.
Ultimately, organize the findings into an acceptance record: whether the expected path is clear, whether each traffic type meets expectations in normal, reconnect, and disconnect states, and whether anomalies have been traced to specific settings. The conclusion thus drawn—"under the current conditions and test scope, the observed network paths meet expectations"—is more valuable than any one-time green indicator.
