What is a WebRTC leak
WebRTC is a browser's built-in real-time communication capability, used for video conferencing, voice calls, P2P file transfer, and similar scenarios. To establish a peer-to-peer connection, the browser discovers its own public-facing address through a STUN server. This probing typically uses UDP, and ordinary HTTP / SOCKS proxies don't necessarily intercept UDP.
If the STUN request bypasses the proxy and goes out directly from the local network, a web script could obtain your real public IP. This process usually doesn't require camera or microphone permission and doesn't trigger an extra confirmation prompt, which is why it's commonly used to check whether a proxy truly covers real-time communication traffic.
How this tool detects it
The page attempts WebRTC probes against multiple STUN servers, collects the returned public addresses, and compares them with the HTTP egress IP. If the returned address matches the current egress, the UDP path is likely handled by the proxy; if it returns a local carrier address, that's worth investigating.
- Verify whether UDP goes through the proxy egress
- Detect whether IPv4 / IPv6 each leak independently
- Observe whether different STUN targets hit different routing rules
The role of STUN and UDP
UDP is a connectionless transport protocol commonly used for voice, video, games, and real-time communication. STUN's job is simple: you send a UDP packet to the server, and the server tells you the source IP it saw. WebRTC relies on this result to negotiate a connection, so the address seen by STUN is the key evidence for judging a leak.
How to interpret the results
No leak detectedWebRTC returned no public IP, or the returned public IP matches your current proxy egress.
Suspected leakWebRTC returned a different public IP, and its location, carrier, or ASN points to your real local network.
Normal traffic splittingMultiple STUN servers returned different proxy egresses, but these egresses match your configured routing or rule expectations.
What to do after finding a leak
- Firefox: disable
media.peerconnection.enabled in about:config. - Chrome / Edge: use an extension like uBlock Origin to restrict WebRTC from exposing local addresses.
- Brave: set the WebRTC IP handling policy to "Disable non-proxied UDP".
- When you need conferencing or voice calls, first fix the UDP / STUN routing rules in your proxy client.
Multiple egress IPs aren't necessarily a leak
If you've configured traffic splitting, different STUN servers may route through different nodes — for example, Google's STUN through a US egress, Cloudflare's STUN through a Hong Kong egress. This isn't necessarily dangerous; what matters is whether it matches your rule design. What you really need to watch for is when all WebRTC addresses point to your physical location or local ISP.
DNS leaks matter just as much
A WebRTC leak exposes "your real IP"; a DNS leak exposes "which domains you've queried". If DNS requests don't go through the proxy, your local carrier or upstream resolver can still see which sites you've visited.
This page's DNS leak detection uses a real probe: CleanIP.io runs one authoritative NS each in Hong Kong (ns1) and Los Angeles, US (ns2), serving the dp.cleanip.io zone. Each detection resolves 8 independent <uuid>.dp.cleanip.io subdomains; these queries pass through your system's stub resolver -> ISP / VPN / public recursive resolver, ultimately landing on our authoritative NS, which records the querying resolver's IP and (if present) the EDNS Client Subnet, then returns it to you for comparison.
Focus on two signals: ① ECS subnet — if the recursive resolver forwarded your client subnet (common with Google 8.8.8.8), that subnet is definitive proof of your client identity; ② resolver country — cross-border anycast for public recursive resolvers (1.1.1.1 / 8.8.8.8) is normal; what matters is whether, when you think your VPN is on, the resolver's location matches your HTTP egress country.
Why proxy mode and TUN mode give different results
HTTP / SOCKS proxies typically handle only TCP, so the UDP that STUN needs may fail to send, and the page may show "no leak". This doesn't mean UDP has been securely proxied — it just means UDP never reached the STUN server. TUN mode intercepts both TCP and UDP on the virtual network adapter, so it better reflects the real UDP egress path.
ModeSTUN UDPResult meaning
HTTP / SOCKS proxyMay fail to send"No leak" may just mean UDP was blocked
TUN / virtual adapterCan genuinely sendBetter suited for verifying UDP egress and routing rules
We recommend retesting under the network mode you actually use: if you normally use TUN, test with TUN; if you rely on a browser proxy, also confirm that a blocked UDP isn't being misjudged as safe. When judging a WebRTC leak, focus on the ASN, location, and whether the returned IP matches your traffic-splitting expectations.