WebRTC Leak Test: Verify Your Real IP Exposure
Real-time communication in the browser is brilliant for video calls and screen sharing, but it also opens a lesser-known window into your network identity. A WebRTC session can briefly reveal addresses that normal web requests never show. Our goal here is to help you understand exactly what the browser exposes, why it happens, and how to read the signals with confidence. This page explains the moving parts behind the scenes so that a quick run gives you actionable, technically sound guidance.
Use this WebRTC leak test to compare the public IP your HTTPS session presents with the addresses discovered during peer-to-peer setup. If the public address discovered for WebRTC differs from the one used by your regular browsing, a site could correlate you through that alternative path. Not every difference is harmful, and not every extra detail is a “leak.” The key is knowing which candidates matter and how to interpret them.
What This Tool Checks
The test collects the IP address your browser uses for the page itself, then spins up a short-lived peer connection and listens to the ICE (Interactive Connectivity Establishment) candidate list. It classifies each candidate, highlights routable public entries, and shows whether any public value matches the address seen by HTTPS. A mismatch on a public, server-learned candidate is the prime signal to investigate.
The Mechanics: ICE, STUN, and TURN in Plain English
ICE is the process that helps two peers find a way to reach each other. Your browser proposes possible paths called “candidates.” Host candidates describe local interfaces. STUN (Session Traversal Utilities for NAT) asks a simple reflector on the internet, “What do I look like from out there?” and returns a server-reflexive (srflx) address. TURN (Traversal Using Relays around NAT) offers a last-resort relay so media can pass even when direct paths fail. For privacy testing, srflx is the most revealing because it reflects the public address the world sees right now.
Why Server-Reflexive (srflx) Matters
When you use a VPN or proxy to project a single identity, you want WebRTC’s srflx address to match the public IP used by your normal HTTPS traffic. If srflx points to a different gateway—say, your ISP edge instead of your VPN egress—then a site initiating WebRTC could learn that alternative endpoint and correlate sessions outside your tunnel. That does not prove media ever flowed there; it simply proves visibility, which is often enough for tracking.
Host, Private Ranges, and mDNS Are Not Leaks
Most host candidates are private RFC 1918 or link-local addresses. They are not reachable from the internet and therefore do not, by themselves, expose you. Modern browsers often replace raw local addresses with randomized mDNS hostnames ending in “.local,” which further reduces local tracking. Seeing those entries is normal. In some edge setups, you may see a public host candidate—e.g., when a machine has a directly assigned public IP or when policy routes exclude the VPN for certain classes of traffic. Treat that as a configuration clue rather than an automatic red flag.
How to Run a Clean Test
First, collect a baseline. Disconnect any VPN or proxy, reload the page, and note your public address and the srflx value. Next, connect your secure tunnel, refresh, and repeat. In an ideal outcome, both the HTTPS address and srflx converge on the same VPN egress. If they do not, reconnect the tunnel, switch to a different server, or toggle IPv6 and test again. Running the WebRTC leak test across a few reconnections helps you distinguish one-off noise from a stable pattern.
Reading the Output Like a Pro
Focus on three columns: Type, Value, and Match. “Type” tells you whether the entry is host, srflx, or relay. “Value” is the candidate’s address. “Match” indicates whether a public candidate equals your HTTPS IP. A public srflx with “≠ differs” is the main privacy concern. UDP candidates are common and perfectly fine; TCP may appear when UDP is blocked or restricted. The order in which candidates show up is not important for privacy; the presence and equality of public addresses is.
Common Causes of Mismatch
Split tunneling is the most frequent cause: only some destinations use the VPN while peer-to-peer discovery takes a direct path. Mixed IPv4/IPv6 policies are another: HTTPS might route over the tunnel for IPv4 while WebRTC exposes a native IPv6 path outside it. Policy-based routing or firewall rules that exempt STUN from the tunnel can also create mismatches. On laptops, captive portals and hotel Wi-Fi gear sometimes force STUN out an unintended interface during the first minutes after joining the network.
Hardening Without Breaking Calls
You can reduce exposure without sabotaging real-time apps. Ensure your VPN client tunnels both IPv4 and IPv6 or cleanly disables the one it cannot protect. Prefer configurations that keep STUN traffic inside the tunnel. Many clients include a “block local network” or “WebRTC leak protection” switch that hides host interfaces or manipulates ICE so srflx is derived from the tunneled egress. Browser flags that disable peer connections entirely are effective but heavy-handed; they may break voice/video sites and remote assistance tools.
Mobile and Cross-Device Considerations
On phones, cellular networks often use large-scale NAT (and sometimes NAT64 or DS-Lite). That can produce srflx addresses that look unusual compared with Wi-Fi. Because mobile operating systems aggressively manage radios and background permissions, the candidate set may update as networks change. When tethering or switching from Wi-Fi to cellular, rerun the test to confirm that the tunnel keeps srflx aligned with your browsing IP.
Troubleshooting Checklist
- Reconnect the VPN and retest; short-lived routing glitches are common.
- Try a different VPN location to rule out exit-node quirks.
- Toggle IPv6: either tunnel it consistently or disable it system-wide.
- Verify that STUN (UDP/3478) is not forced outside the tunnel by local rules.
- Turn off split tunneling, or explicitly include your browser in the tunnel list.
- Confirm that no secondary adapters (Hyper-V, VirtualBox, WSL) leak public paths.
- Repeat the run in another browser to compare implementation differences.
Privacy Model and Data Handling
The page performs its checks inside your browser. It does not relay media, store identifiers, or call third-party HTTP APIs. The only external interaction required for discovery is the STUN exchange that reflects your apparent address. When candidate gathering finishes, the temporary connection is discarded. This minimalist approach mirrors how real-world WebRTC apps behave while keeping the footprint small.
Security vs. Usability Balance
Blocking WebRTC entirely eliminates a class of leaks but removes important capabilities many users rely on. A better strategy is to aim for consistency: the public identity revealed by srflx should match the one used by your regular web traffic. If those are equal, the presence of private, mDNS, or auxiliary host entries is typically benign. Keep your routing simple, your tunnel comprehensive, and your expectations clear.
Bottom Line
A “leak” is about unintended exposure, not about the mere existence of extra technical details. Use this WebRTC leak test to verify that your browser’s peer-to-peer discovery aligns with the identity you intend to project. If srflx reliably differs from your browsing IP when you expect a single public endpoint, you have a configuration issue to fix. If it matches, you are in good shape—even if the list includes local or mDNS entries along the way.