WebRTC Leak Test Guide

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. A page may show the VPN or proxy egress for normal web requests while a script discovers another network path through WebRTC, weakening privacy isolation.

Why test it?

A WebRTC test is one part of a network privacy check. When using a VPN, proxy, cross-border setup, AI service, or streaming service, compare the HTTP egress, WebRTC public candidates, and DNS resolver path. A mismatch is a reason to review whether the proxy handles UDP, whether browser privacy settings are active, and whether an extension changes WebRTC behavior.

Browser behavior depends on its implementation, privacy defaults, extensions, and proxy mode. Chromium browsers often need a policy or extension to limit candidate gathering; Firefox exposes more direct configuration options. The most reliable answer comes from testing the browser and network environment you actually use.

ICE candidates

When a peer-to-peer connection starts, the browser gathers ICE candidates through STUN / TURN services:

• host: a local interface or LAN address such as 192.168.x.x or 10.x.x.x.
• srflx: a public mapped address returned by a STUN service, which should be compared with the HTTP egress.
• relay: an address allocated through a TURN relay.
• mDNS: a random .local hostname used to replace a real local address in many browsers.

Normal HTTP(S) traffic usually follows the browser proxy setting, while WebRTC STUN traffic may use UDP directly from the network stack. If a proxy handles web traffic but not UDP, the WebRTC public candidate can differ from the HTTP address.

How IPDO tests WebRTC

IPDO creates a separate RTCPeerConnection for each STUN server instead of mixing every server into one connection. This shows which node responded, how long it took, and which candidates it returned.

The test currently includes 12 domestic and international STUN nodes in batches:

1. Create a data channel and offer to trigger ICE gathering.
2. Read host, srflx, prflx, and relay candidates.
3. Get the HTTP egress from /api/ip-check, excluding loopback and private addresses from comparison.
4. Mark public candidates matching the egress green and other public candidates red.
5. Show .local candidates separately. A timeout only means that node did not complete this request; it does not prove safety or blocking.

Reading the result

• Green public address: it matches the HTTP egress, so this run found no additional public address.
• Red public address: it differs from the HTTP egress and is the main WebRTC leak signal to investigate.
• .local address: usually an mDNS-obfuscated local candidate, not proof that the real LAN address was exposed.
• All timeouts: may be caused by blocked UDP, proxy rules, browser extensions, or a STUN outage. Do not treat them as proof of safety.
• Egress comparison unavailable: the page can show STUN candidates but cannot determine whether they are additional leak addresses.

Reducing the risk

If browser audio and video are still needed, limit candidate gathering instead of disabling WebRTC entirely:

• WebRTC Network Limiter limits the network interfaces and candidate paths used by WebRTC.
• WebRTC Leak Prevent applies extension rules to reduce address exposure.

Firefox users can change media.peerconnection.enabled in about:config. Disabling it completely also disables browser video meetings, voice calls, and peer-to-peer features. If WebRTC must keep working, a VPN TUN / TAP mode that handles UDP is preferable. Reload and test again after changing a setting.

Privacy

STUN probing and candidate parsing happen in this browser, and candidates are not sent back to IPDO. The page only calls the site's IP lookup endpoint to obtain the HTTP egress for comparison. STUN services can see your connection details, but the result is not stored as a lookup record.