IPDO · Browser privacy checks
WebRTC Leak Test
WebRTC uses STUN services to establish connections. We collect candidates from 12 domestic and international nodes and compare them with the current egress IP to surface extra public or local candidates.
What is a WebRTC leak?
WebRTC (Web Real-Time Communication) is the browser technology used for real-time audio, video, and peer-to-peer data channels. Video meetings, screen sharing, web support, and cloud gaming can use it. A WebRTC leak happens when the ICE candidate exchange exposes a local or real public IP, allowing a website or third party to learn more than the VPN or proxy egress address it normally sees.
A WebRTC test is one part of a network privacy check. When using a VPN, proxy, AI service, streaming service, or a cross-border setup, compare the WebRTC result with the DNS and IP purity checks. The combination is more useful than relying on the IP shown by a normal web request alone.
Are all browsers affected by WebRTC leaks?
Not necessarily. The risk depends on the browser implementation, privacy defaults, extensions, and whether the proxy or VPN actually handles WebRTC UDP connections. Chromium browsers often need a policy or extension to limit candidate collection, while Firefox exposes more direct configuration options. Browser behavior around ICE, mDNS, local addresses, and STUN requests differs, so the most reliable answer comes from testing the browser in the network environment you actually use.
What does a WebRTC leak mean?
A leak gives a page or third-party service a chance to identify your real network environment instead of only seeing the proxy egress. It can expose a public IP, a local network range, a region, or an operator. For users who rely on proxy environments, a mismatch between the access egress and the real network can also increase detection, risk checks, or access restrictions. This is a privacy and network-isolation issue, not just a technical detail.
How a WebRTC leak works
- When a peer-to-peer connection starts, the browser gathers ICE candidates through STUN / TURN services. Common types are host (local or LAN address), srflx (a public mapped address returned by STUN), and relay (an address allocated through a TURN relay).
- If a page can read host or srflx candidates, it may learn a LAN address or the real public address. Chrome, Edge, and Firefox commonly replace local addresses with mDNS hostnames, but public candidates still depend on proxy and VPN policy.
- Normal HTTP(S) traffic usually follows the browser proxy setting, while WebRTC STUN traffic may use UDP directly from the network stack. If the proxy handles web traffic but not UDP, the web IP and WebRTC IP can differ.
What does this test do?
Each STUN server gets its own RTCPeerConnection instead of being mixed into one connection. This lets the page show which nodes responded and which candidates they returned.
- Connects to 12 domestic and international STUN nodes in batches to reduce interference from many simultaneous connections.
- Creates a data channel and offer to trigger ICE candidate gathering in the browser.
- Reads host, srflx, prflx, and relay candidates, then compares public addresses with the egress IP returned by this page's HTTP lookup.
- Marks addresses matching the egress IP green and other public candidates red. A timeout only means that node did not complete this request.
How should the result be read?
- No public candidate: the browser or network did not complete STUN gathering. This alone does not prove that every path is safe.
- Public candidates match the HTTP address: no additional public address was found in this run, so the tested egresses are consistent.
- A public candidate differs from the HTTP address: this is the main WebRTC leak signal. Review whether the proxy handles UDP and review the browser's WebRTC privacy policy.
- A .local name appears: this is mDNS obfuscation, which usually means the real LAN address was not directly exposed. A real 192.168 or 10.x host candidate deserves more attention.
How can WebRTC leak risk be reduced?
Start by checking the VPN or proxy mode, then choose a restriction that matches whether you need browser audio and video. Reload this page and test again after changing a setting.
- Chrome and Edge users can consider WebRTC Network Limiter
- or use WebRTC Leak Prevent
- Firefox users can change media.peerconnection.enabled in about:config. Disabling it completely also disables browser video calls, voice calls, and peer-to-peer features.
- If WebRTC must keep working, a VPN TUN / TAP mode that handles UDP is usually preferable to disabling it. Do not treat all timeouts as proof of safety; a server or network policy can also cause them.
Frequently asked questions
Why can a VPN still expose my real IP?
Many browser proxies and SOCKS / HTTP proxies handle only TCP HTTP(S) traffic, while WebRTC ICE gathering may send UDP directly through the network stack. A VPN mode that also handles the whole network path, such as TUN, is more likely to keep the web and WebRTC addresses consistent.
Do all STUN timeouts mean that I am safe?
No. Timeouts can come from network restrictions, browser extensions, proxy rules, blocked UDP, or a target outage. A more useful signal is that at least one node returns candidates and every successful public candidate matches the HTTP egress.
What does a .local address mean?
It is mDNS obfuscation. The browser uses a random hostname in place of the real LAN address, which is a common privacy protection. It does not prove that the public address is protected; compare public candidates with the HTTP egress as well.
Does IPDO store the WebRTC result?
No. STUN probing and candidate parsing happen in this browser, and candidates are not sent back to IPDO. The page only calls the local IP lookup endpoint to obtain an HTTP egress address for comparison. The result does not persist after you leave the page.
