What a WebRTC leak really is
A WebRTC leak occurs when a website can learn an IP address from your browser that you did not intend to expose. WebRTC builds direct, low-latency paths for real-time media. To do that on a typical network, the browser needs to discover how it appears on the public internet and which local interfaces can carry traffic. This discovery creates a set of ICE candidates. Each candidate is a hint about where packets could flow: a local host interface, a server-reflexive address learned from STUN, or a relay address from TURN. A leak is not simply “any extra address.” A leak matters when an address uniquely identifies you outside the tunnel you expect to use.
Why srflx is the main signal
Among all candidate types, the srflx address is the most useful indicator for privacy testing. It represents the public address that sits beyond your NAT at the moment the ICE check runs. If you rely on a VPN or proxy to present a single outward identity, you want the srflx address to be the same as the public IP that your HTTPS traffic uses. When srflx differs from that public IP, a peer connection created inside the browser can disclose an alternative endpoint to any site that uses WebRTC. That difference does not prove that media actually flowed there; it is still enough to identify your connection in many scenarios.
Host, mDNS, private ranges, and false alarms
Host candidates often include private or link-local ranges. Those are not visible to the wider internet and, by themselves, are not leaks. Modern browsers also publish mDNS names that replace the raw local address with a randomized hostname ending in .local. That design reduces tracking surface on shared networks. Seeing mDNS is normal. A public host candidate can appear on some setups, for example when the machine is directly assigned a public address or when policy routes exclude the VPN interface for certain traffic classes. Treat those cases as configuration hints rather than automatic leaks.
How this test interprets results
The test begins by reading the public address of your HTTPS session and displaying it at the top of the page. Then it creates a short-lived peer connection with STUN enabled and collects candidates for a couple of seconds. For each candidate, the page classifies it as private, mDNS, or public, and notes whether the value matches the HTTPS address. If at least one public srflx candidate differs from the HTTPS address, the page flags a potential leak. If there is no HTTPS address available but srflx exists, the page also warns because the browser clearly discovered an external path that the page cannot reconcile with the baseline.
Practical test workflow
Run the test with your VPN off to capture a baseline set of addresses. You should expect srflx to point at your normal internet gateway. Then enable your VPN or proxy and run the test again. In an ideal configuration the HTTPS address and the srflx value converge to the same endpoint. If they differ, repeat the test after reconnecting or changing the VPN server. Some providers expose different stacks for IPv4 and IPv6; try toggling IPv6 to check whether the results stabilize. If your browser offers a “use less private connections” or “restrict WebRTC” setting, test both positions to see how the candidate set changes.
Understanding common edge cases
Dual-stack differences do not automatically imply tracking risk. A site can still correlate sessions across addresses using other signals. However, if you see a stable srflx value that persists across reconnects and it does not match the public address used for HTTPS, that is stronger evidence of a leak path. Another edge case occurs when enterprise devices enforce split tunneling. In that model only some destinations use the VPN, which can legitimately create a mismatch between what WebRTC discovers and what your browser uses for normal web requests. The correct action is not to disable WebRTC outright, but to verify the intent of your policy.
Hardening options without breaking the web
The blunt approach is to block peer connections, but that can break video calls and screen sharing. A more balanced path is to ensure your VPN routes and firewall rules keep ICE checks on the tunneled interface. Some clients offer a “block local network” option that hides host interfaces from the browser. Others ship with WebRTC leak protection that manipulates ICE behavior behind the scenes. If your provider supports both IPv4 and IPv6, keep them consistent: either tunnel both or disable the one that cannot be protected. The goal is not to hide every candidate, but to make sure that the public identity presented by srflx is the same as the one used by your normal web traffic.
How to read the results
The list shows candidates in the order the browser discovers them. “Type” indicates whether an entry is a host or srflx. “Protocol” shows UDP or TCP. “Match” reports whether a public value equals the HTTPS address (“✓ matches”) or differs (“≠ differs”). The controls above the list let you hide mDNS entries and private ranges so you can focus on routable endpoints. The raw view reveals the original candidate strings exactly as the browser produced them, which is helpful for tickets and repeatable tests. If you are diagnosing an intermittent issue, capture a run when everything looks correct and compare future runs against that snapshot.
Privacy stance of this page
The page does not call any third-party HTTP services, does not relay media, and does not persist results. The only external interaction is the STUN exchange required to learn the srflx address. That exchange contains no payload and exists solely to reflect your apparent address. The test lives entirely in your browser and discards the connection when ICE gathering finishes. The intent is to provide a clear, reproducible signal that mirrors how real-world WebRTC applications behave while keeping the overall footprint minimal.
Bottom line
A WebRTC leak is about unintended exposure, not about the mere presence of extra technical details. Focus on the srflx candidate: if it regularly differs from your HTTPS address when you expect a single public identity, you have a configuration problem to solve. If the two match, the presence of private, mDNS, or auxiliary host entries is usually harmless. Use this test as a fast triage step, then adjust your network settings so that your browser presents a consistent view of who you are on the network.