--- title: "WebRTC leak test" url: https://proxy.wiki/tools/webrtc-leak-test/ type: Tool author: "proxy.wiki editorial" published: 2026-10-21 updated: 2026-10-21 site: proxy.wiki license: CC BY 4.0; quote freely with attribution to https://proxy.wiki/ --- # WebRTC leak test > See every IP address WebRTC hands to websites, and whether one of them is an address your proxy or VPN does not cover. ## Key takeaways - WebRTC hands a page every address your browser can be reached on, without asking. - An HTTP proxy does not carry WebRTC's UDP, so the STUN answer can expose your real network. - A .local name is your browser hiding the address, not a leak. - A second public address without any proxy is usually your other IP version, not a leak. See every address WebRTC hands to a website, and whether one of them is an address your proxy or VPN does not cover. This is an interactive tool; it runs in a browser at [https://proxy.wiki/tools/webrtc-leak-test/](https://proxy.wiki/tools/webrtc-leak-test/). WebRTC lets a web page open a direct connection to another browser, for calls and file transfer. To set one up, your browser gathers every address it could be reached on and hands the list to the page. Those addresses are called ICE candidates. A page does not need your permission to collect them, and it can read them without opening a call at all. That is the leak. A proxy configured in your browser carries HTTP and HTTPS. WebRTC gathers its candidates over UDP, which an HTTP proxy does not carry, so the browser can discover and report an address the proxy was meant to hide. ## Reading the table | Candidate type | Where the address comes from | Is it a leak? | | --- | --- | --- | | local interface (host) | A network interface on your machine | Only if it is a public address. A private one like 192.168.1.20 reveals little. | | hidden (.local name) | Your browser replaced the local address with a random mDNS name | No. This is the browser protecting you. | | public, as a STUN server saw it (srflx) | Your browser asked a STUN server which address its packet came from | Yes, if it differs from the address our server saw | | relay server (relay) | A TURN relay. This test configures none, so you should not see one. | No | The comparison that matters is the STUN answer against the address our server saw over HTTPS. If you are behind a proxy and those two differ, the STUN answer is your real network, and any page can read it. If you are not using a proxy or VPN and still see a second public address, it is usually your other IP version. Our server may have seen you over IPv6 while STUN answered over IPv4, or the reverse. That is two addresses for one connection, not a leak. ## How to stop it - **Use a tunnel that carries UDP.** A full VPN routes all traffic, UDP included, so the STUN answer comes back with the VPN’s address. An HTTP proxy cannot do this. - **Firefox:** set `media.peerconnection.enabled` to `false` in `about:config`. WebRTC is then off entirely, and video calls in the browser stop working. - **Chromium browsers** have no switch for it in their settings. Extensions that restrict WebRTC exist; test again after installing one, because the result is what counts. - **Automation:** a headless browser driven through a proxy leaks the same way. Disable WebRTC in the browser profile, or route the whole machine through the tunnel. Run the test again after any change. A clean result here is one sample from this browser, on this network, at this moment. ## Frequently asked questions ### Does this test send my WebRTC addresses to proxy.wiki? No. The candidates are gathered and compared in your browser. The only request to our server asks which address it saw, so the page has something to compare against. ### Why does a VPN fix it when a proxy does not? A full VPN routes all traffic from the machine, UDP included, so the STUN server sees the VPN's address. A proxy set in the browser carries HTTP and HTTPS only. ### What is a .local address in the results? Your browser replaced a local network address with a random mDNS hostname so pages cannot read the real one. It is a protection, not a leak. ### Which STUN server does the test use? stun.l.google.com on port 19302, a public STUN server. Your browser contacts it directly to learn its own public address. ## Sources 1. [RFC 8445: Interactive Connectivity Establishment (ICE)](https://www.rfc-editor.org/rfc/rfc8445.html) 2. [RFC 8489: Session Traversal Utilities for NAT (STUN)](https://www.rfc-editor.org/rfc/rfc8489.html) 3. [IETF draft: Using Multicast DNS to protect privacy when exposing ICE candidates](https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-mdns-ice-candidates) 4. [MDN: RTCIceCandidate.type](https://developer.mozilla.org/en-US/docs/Web/API/RTCIceCandidate/type)