How a WebRTC leak happens
WebRTC lets two browsers talk directly instead of through a server. To find a path between them, the browser runs a process called ICE, which gathers every address it might be reached at, called candidates, and tests them in pairs.12 Those candidates are given to the web page so it can pass them to the other side, which means a page learns more about your network than an ordinary visit would show.1
| Candidate | Where it comes from | What it can reveal |
|---|---|---|
| Host | Your device’s own network interfaces | Your private address on the local network |
| Server reflexive | A STUN server reporting the address it sees you from | Your public IP address on that route |
| Relay | A TURN server that forwards the traffic | The relay’s address, not yours |
Any web page can start this process through JavaScript and read the results.3 The address property of each candidate can show where a device is, how its network is laid out, and can be used to fingerprint it.3
When it exposes your real IP
The IETF’s guidance on WebRTC address handling names three situations where it gives away more than it should.1
- A split tunnel VPN. If your device can route over more than one connection, WebRTC can find your internet provider’s public address as well as the VPN’s.
- A proxy instead of a VPN. If your browser sends web traffic through a proxy but direct internet access is still allowed, WebRTC’s STUN checks go around the proxy and reveal your public address.
- Your local network. Behind a home router, WebRTC can reveal your private address, which adds to a browser fingerprint.
How browsers and VPNs prevent it
The same guidance tells browsers to follow the system’s routing table unless you have given permission, such as for a call, so WebRTC traffic takes the same route as the rest of your browsing.1 With a full tunnel VPN, that route is the tunnel, and the public address WebRTC finds is the VPN server’s. Browsers can also hide local addresses behind random names using multicast DNS, a method described by the IETF, so a page gets a throwaway name instead of your private IP.4
To check your own setup, connect your VPN and open a WebRTC leak test page. If it shows an address that belongs to your internet provider, traffic is leaving outside the tunnel. Keeping your browser inside the tunnel, and using a full VPN instead of a browser proxy, closes the gaps described above.
WebRTC and Secria VPN
With Secria VPN, DNS is resolved by our own resolver inside the tunnel, and an OS-level kill switch blocks all traffic if the tunnel drops. Every connection is protected with WireGuard plus ML-KEM-1024.
Related terms
Sources
- IETF, RFC 8828: WebRTC IP Address Handling Requirements (January 2021).
- IETF, RFC 8445: Interactive Connectivity Establishment (ICE) (July 2018).
- MDN Web Docs, RTCIceCandidate: address property, security notes.
- IETF, Using Multicast DNS to protect privacy when exposing ICE candidates (Internet-Draft).
Checked October 2026. Secria facts are from our Mail and VPN pages and the whitepaper.
Questions about WebRTC leaks
Does a VPN stop WebRTC leaks?
A full tunnel VPN does in the usual case, because the browser follows the system’s route and that route is the tunnel. Leaks mostly happen with split tunneling, with browser proxy extensions, or when traffic is allowed outside the tunnel.
Should I disable WebRTC?
Usually not. Turning it off breaks video calls and other features in the browser. A full tunnel VPN covers your public address, and browsers can hide your local address behind a random name.
What does a WebRTC leak test show?
The addresses a web page can collect through WebRTC. With your VPN on, any public address listed should belong to the VPN, not to your internet provider.
Is a WebRTC leak the same as a DNS leak?
No. A DNS leak exposes the names of the sites you look up. A WebRTC leak exposes an IP address. Both happen when traffic slips outside the VPN tunnel.