A WebRTC leak happens when a web page uses the browser's real-time connection feature to learn an IP address other than the one your proxy or VPN gives it. Your page loads go through the proxy, but WebRTC tries to open direct connections for audio, video and data, and in doing so it can report your own public address, or a local network address, to the page's script.
This post explains how that works, how to test a profile in a couple of minutes, which fixes exist and what each one costs, and why DNS needs the same attention.
What WebRTC does, and why it needs your address
WebRTC (Web Real-Time Communication) lets two browsers talk directly: video calls, screen sharing, file transfer in a page. To connect two computers that each sit behind a home router or office firewall, the browser has to work out every way it might be reached. That process is called ICE (Interactive Connectivity Establishment, RFC 8445), and each possible route is a candidate:
- Host candidates: the addresses of your own network interfaces, such as a local Wi-Fi address.
- Server-reflexive candidates: your public address as seen by a STUN server (RFC 8489). The browser sends a small UDP packet to the STUN server and asks, in effect, "what address did this come from?"
- Relay candidates: an address on a TURN relay that forwards traffic when no direct route works.
The page's JavaScript can read these candidates as they are gathered. No microphone or camera permission is needed for a data-only connection, so a page can collect candidates silently in the background.
How the leak happens
Most proxies used with browsers are HTTP or SOCKS5 proxies, and the browser sends page traffic through them over TCP. The STUN request is UDP, and an ordinary browser does not send it through an HTTP proxy at all. So the STUN packet goes straight out of your own connection, the STUN server sees your real public address, and the browser hands that address to the page as a server-reflexive candidate.
The result is a profile that loads pages from a proxy in Frankfurt while its WebRTC candidates name a home connection somewhere else. A site that compares the two sees a contradiction, and learns the address you meant to keep private.
What about local addresses?
Local addresses (the 192.168.x.x or 10.x.x.x kind on a home network) used to leak the same way, as host candidates. Current browsers usually replace them with random names in the multicast DNS (mDNS) local domain, so a page sees a meaningless generated name instead of the address. That closes most of the local-address problem, but it does nothing for the public address found through STUN.
How to check a profile for a WebRTC leak
You need two numbers: the address the profile's pages come from, and every address WebRTC offers.
- Open the profile and visit any "what is my IP" page. Note the address. This should be your proxy's exit.
- Open the browser's developer tools (View › Developer › JavaScript Console, or F12) on any ordinary page and paste:
const pc = new RTCPeerConnection({ iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] });
pc.createDataChannel('x');
pc.onicecandidate = (e) => { if (e.candidate) console.log(e.candidate.candidate); };
await pc.setLocalDescription(await pc.createOffer());- Read the lines it prints. Each contains an address followed by
typ host,typ srflxortyp relay.
How to read the result:
| What you see | What it means |
|---|---|
| Only random mDNS names and the proxy's exit address | No leak. WebRTC presents the same address as your pages. |
A srflx address that is not the proxy's exit | A leak: that is the address your own connection uses. |
A private address (192.168…, 10…, 172.16–31…) after typ host | Your local address is exposed. |
| Nothing at all | WebRTC is disabled or every candidate is suppressed. No leak, but unusual. |
Repeat the test after any change to the proxy or the WebRTC setting. Our free browser fingerprint test checks the rest of the profile's consistency in the same visit, and runs entirely in your browser.
The fixes, and what each costs
There are four common approaches.
- Leave WebRTC as it is. Calls work, and the real address leaks whenever a proxy is in use. Fine without a proxy; a problem with one.
- Disable WebRTC. Nothing leaks, but video calls and some sites stop working, and a browser with no WebRTC at all is itself unusual. Few real visitors look like that.
- Allow only proxied UDP. The browser refuses to send UDP outside the proxy, so no STUN request leaves on your own connection. With an HTTP or SOCKS5 proxy that cannot carry UDP, WebRTC then has no public candidate, which is safe but can look odd next to a normal page load.
- Replace the candidate with the exit's address. The browser blocks UDP outside the proxy and presents the proxy's measured exit address as its public candidate. The page sees one consistent address everywhere. This needs the exit to be known accurately; a wrong address is a stronger contradiction than none.
Browser extensions that toggle WebRTC usually offer the first three. The fourth needs the browser itself to know where the proxy exits.
Do not forget DNS
DNS leaks are WebRTC's quieter cousin. Before a browser connects to a site, it looks up the site's name. If that lookup goes to your own network's resolver instead of through the proxy, your internet provider or office network sees every site the profile visits, even though the pages themselves go through the proxy. With SOCKS5 and HTTP proxies the fix is to let the proxy resolve names (sometimes called remote DNS). Check your proxy settings for it.
How Browz handles WebRTC and DNS
Browz sets WebRTC from the profile's proxy, in the browser itself, so you do not need an extension.
- Derived from the proxy, by default. Every proxy check opens a real tunnel and measures the exit over HTTPS. With WebRTC on its recommended setting, derive from the proxy, a profile on a proxy presents the measured exit address as its public candidate and sends no UDP outside the proxy. When the exit has not been measured yet, Browz disables WebRTC for that profile instead of guessing an address (anti-detect features).
- Replace, disable or real, when you choose. Settings › Network and proxies has all the modes. Real exposes your computer's address behind the proxy, and Browz warns about it.
- SSH and HTTP proxies alike. SSH carries no UDP, so an SSH proxy's WebRTC is handled as for an HTTP proxy.
- DNS at the proxy by default. Each proxy resolves site names at the proxy (remote DNS). You can switch an individual proxy to local DNS if you need to (DNS and WebRTC with a proxy).
- Timezone and languages follow the same exit, so the clock and the address agree as well.
Check it from the command line
The browz command shows what a proxy's exit supports and what a profile presents:
browz check "Frankfurt ISP 1"
browz fingerprint "Acme – Ads – DE"browz check reports the exit IP, country and city, which protocols the proxy carries, and the WebRTC mode profiles on that exit will use. browz fingerprint lists every value the profile presents and where it came from. Then run the console test above in the profile itself: the srflx line should name the same exit. More on the proxy side is on the proxies feature page.
Frequently asked questions
Does a VPN stop WebRTC leaks?
A VPN that routes all your computer's traffic, UDP included, usually does: the STUN request goes through the tunnel and the server sees the VPN's address. A browser proxy is different, because it carries only the browser's TCP traffic, so the STUN request can still leave on your own connection. Test either way with the console snippet above.
Should I disable WebRTC completely?
Usually not. Video calls and some sites need it, and a browser that has no WebRTC at all stands out. Presenting the proxy's exit address keeps WebRTC working and consistent with the address your pages use.
Is a WebRTC leak the same as a DNS leak?
No. A WebRTC leak exposes your address to the website through the page's script. A DNS leak exposes the names of the sites you visit to whoever runs your DNS resolver, usually your internet provider. Both happen when part of the browser's traffic skips the proxy, so check both.
Do mobile browsers leak through WebRTC too?
They can, for the same reason: a STUN request sent outside the proxy reveals the device's own public address. The same console test works wherever you can open developer tools.