WebRTC is the browser technology behind video calls, screen sharing and peer-to-peer file transfer. To connect two browsers directly, it has to discover the network addresses each one can be reached at, and any web page can start that discovery without asking permission. If your browser sends web traffic through a proxy or VPN but lets WebRTC use your normal connection, a page can learn the address you meant to hide. That is a WebRTC leak, and this test checks for it.
How the test works
When the page loads, it creates a WebRTC connection object, adds a data channel and starts gathering ICE candidates, the list of addresses WebRTC could use. It points the browser at a public STUN server run by Cloudflare (stun.cloudflare.com, port 3478). A STUN server answers one question: "what address did this request come from?" The answer is your public address as the internet sees it on the path WebRTC took.
The test waits up to five seconds for candidates, then compares them with the IP address our server saw when your browser loaded the page. No call is made, no camera or microphone is used, and nothing is stored.
ICE candidates come in types (MDN):
- host: an address on your own device or local network.
- srflx (server reflexive): your public address as seen by the STUN server.
- prflx (peer reflexive): a public address learned during connection checks.
- relay: an address on a TURN relay server. This test doesn't use TURN.
Reading your results
| Row | What it shows | Good result |
|---|---|---|
| IP websites see | The address our server saw for this page load | Your proxy or VPN address, if you use one |
| WebRTC public address | Each srflx or prflx address WebRTC found | Matches the row above, or "none exposed" |
| Local address | Each host candidate | A random name ending in .local |
| WebRTC turned off | Shown when the browser has no WebRTC | Nothing can leak through WebRTC |
A red WebRTC public address means WebRTC found a public IP different from the one websites see. If you use a proxy or VPN, this is usually your real connection: a leak.
"None exposed" means the browser didn't reveal a public address through STUN. That happens when WebRTC is restricted to the proxy and the proxy doesn't carry the UDP traffic STUN uses, or when a browser setting blocks it.
A yellow local address means WebRTC showed a raw local network address, such as 192.168.1.20 or 10.0.0.5. Modern browsers replace these with a random name such as 1f4b6c2e-8d3a-4c51-9b7e-2a6f0d9c3e85.local, using multicast DNS, so that pages can't read your local network layout. The technique is described in the IETF draft Using Multicast DNS to protect privacy when exposing ICE candidates. A raw local address usually means the site has permission to use your camera or microphone, the browser's WebRTC policy was changed, or the browser is an older version.
Why WebRTC leaks happen
Most proxies carry web traffic over TCP: HTTP and HTTPS proxies always do, and many SOCKS5 setups do in practice. WebRTC prefers UDP. If the browser is told to use a proxy for web pages but allowed to send UDP directly, the STUN request goes out through your normal connection and the answer reveals your normal public IP.
The IETF's RFC 8828 describes four ways a browser can handle this:
- Enumerate all addresses: use every network interface. Most revealing; the RFC says it must not be used without user consent.
- Default route plus associated local addresses: use the route web traffic takes, and expose the local addresses of that interface. The RFC recommends this mode when the user hasn't given consent.
- Default route only: like mode 2, without the local addresses.
- Force proxy: when web traffic goes through a proxy, WebRTC traffic must too. If the proxy can't carry UDP, media falls back to TCP.
A system-wide VPN usually doesn't leak, because all traffic, including UDP, follows the VPN route. Browser-level proxies and proxy extensions are where leaks are common.
IPv4 and IPv6
If your network has both IPv4 and IPv6, your browser may reach our site over one while WebRTC reports the other. Both addresses then belong to your own connection, and the test shows them as different. Before treating that as a leak, check whether the WebRTC address belongs to your own network, or test with IPv6 off.
How to fix a WebRTC leak
- Use a system-wide VPN instead of a browser-only proxy, if one connection for the whole computer is acceptable.
- Restrict WebRTC in the browser. Chromium-based browsers support policies that stop WebRTC from using connections outside the proxy. Some privacy extensions apply these settings for you.
- Turn WebRTC off in browsers where you never need calls. Video calling sites will then stop working in that browser.
- Use a browser profile with its own WebRTC setting, so each profile follows its own proxy.
After any change, reload this page. A fixed setup shows either your proxy's address or "none exposed" in the WebRTC row.
WebRTC in Multime profiles
Every Multime profile has its own proxy and its own WebRTC setting, with four choices:
- Through proxy: WebRTC traffic goes through the profile's proxy.
- Replace IP: WebRTC reports the proxy's IP instead of your own.
- Disabled: WebRTC can't use connections outside the proxy. Calling sites may not work.
- Real: WebRTC behaves as in a normal browser and can show your real address. Use it only when you mean to.
Multime supports HTTP, HTTPS, SOCKS5 and SSH proxies, handles proxy logins through a local relay, and sends DNS through the proxy. It also has port-scan protection, which stops websites from probing services on your computer or local network. Open this page inside a profile to confirm the setting does what you expect with your proxy provider. Read more about proxies in Multime.