What is a WebRTC leak and how do you stop it?

9 November 2026

WebRTC lets a browser make voice and video calls and exchange data directly with another device. To find a path between the two, it gathers your device's addresses, and any web page can read them with a few lines of JavaScript. If those requests travel outside your proxy or tunnel, the page sees your real address, and that is a WebRTC leak.

Why the browser gathers your addresses

Connecting two devices directly is hard, because most of them sit behind network address translation (NAT). WebRTC solves this with ICE, defined in RFC 8445. ICE gathers candidates, meaning addresses and ports where the other side might reach you, and then tests them until one works.

• Host candidate. An address on one of the device's own interfaces, including virtual ones such as a VPN interface.
• Server reflexive candidate. The public address and port a STUN server sees after the request has passed through NAT. It shows up in a candidate line as srflx.
• Relayed candidate. An address allocated on a TURN relay server, used to carry data when a direct connection fails.

The browser learns its public address by sending a Binding request to a STUN server, usually on port 3478. The server's response carries an XOR-MAPPED-ADDRESS attribute with the address and port as the server saw them, as described in RFC 8489.

What a page actually does

Gathering addresses does not require a real call. A page needs four steps:

1. It creates an RTCPeerConnection object and gives it a STUN server.
2. It opens an empty data channel. This needs no camera or microphone permission, and the user sees no prompt.
3. It creates an offer and sets it as the local description, which starts candidate gathering.
4. Each candidate reaches the page through an icecandidate event, and the page sends it to its server along with the rest of the visit data.

In the end the page never connects to anyone, and it does not need to. The addresses it collected are all it wanted.

In a real call, the candidates also go to the other party, who needs them to reach you directly. Whoever you talk to in the browser can therefore learn your address, unless the call goes through a relay.

Why a proxy does not protect you here

Browser proxy settings carry HTTP and HTTPS requests, which run over TCP. A STUN request goes out over UDP and follows the operating system's routing table. It leaves through your normal connection, and the server reflexive candidate comes back with your real public address.

A full-device VPN changes this. The STUN request follows the default route into the tunnel and returns the exit address instead of yours. The risk remains with split tunneling, where part of the traffic bypasses the tunnel.

RFC 8828 calls this the most significant privacy concern for WebRTC: the browser may discover both the tunnel's public address and the ISP address underneath it. Host candidates can also reveal your address on the local network. Most current browsers therefore replace a private local address with a random name ending in .local, unless the page has camera or microphone permission.

IP address handling modes

RFC 8828 defines four modes a browser can choose from, from the most revealing to the most restrictive:

In Chrome and Edge, extensions can set this behaviour through webRTCIPHandlingPolicy in the extension privacy API. One of its values, disable_non_proxied_udp, blocks UDP that does not go through the proxy.

How to test your browser

Open the developer tools with F12 on any page, then paste these lines into the Console:

const pc = new RTCPeerConnection({ iceServers: [{ urls: "stun:stun.l.google.com:19302" }] });
pc.createDataChannel("");
pc.onicecandidate = (e) => { if (e.candidate) console.log(e.candidate.candidate); };
pc.createOffer().then((offer) => pc.setLocalDescription(offer));

1. Each printed line is one candidate. Look for the line containing typ srflx.
2. The address just before the port number on that line is your public address as the STUN server saw it.
3. Compare it with the address shown by the What is my IP tool. If they differ and the first one belongs to your ISP, the browser is leaking.

Every line follows a fixed format defined in RFC 8839. Here is an example using documentation addresses:

candidate:2 1 udp 1694498815 192.0.2.3 45664 typ srflx raddr 0.0.0.0 rport 0

• The first fields. The foundation 2, the component number 1, the transport protocol and the candidate's priority.
• Address and port. 192.0.2.3 and 45664, the part that matters for the test.
• Type. After typ comes host, srflx, prflx or relay.
• Related address. After raddr comes the local address the request left from, which the browser may replace with 0.0.0.0 to hide it.

No srflx line means the browser blocks the request or UDP is blocked on your network. A typ host line with an address ending in .local means the browser is hiding your local address.

How to prevent WebRTC leaks

• Use a full-device connection. Do not split the browser out of the tunnel, so STUN goes through it like everything else.
• Set a WebRTC policy with a browser proxy. If only the browser uses the proxy, use a trusted extension that blocks UDP not going through it.
• In Firefox. Setting media.peerconnection.enabled to false in about:config turns WebRTC off entirely.
• Be careful with camera and microphone permission. Grant it only to sites you trust, because it lifts the hiding of local addresses.
• Test after every update. A browser or extension update can change the setting without you noticing.

Every fix has a cost. Blocking direct UDP pushes calls through a relay or over TCP, which adds some delay.

WebRTC and syriaproxy

Our Chrome and Edge extension sets WebRTC so it does not expose your real address, and Extension setup shows how to install it. The Android, Windows and Linux apps, and WireGuard on iPhone, iPad and macOS, carry the whole device's traffic, STUN requests included.

FAQ

Test your browser now with the free WebRTC leak test.