WebRTC leak test

How this test works

WebRTC is the browser feature behind video calls and screen sharing without a plugin. Before two browsers can talk directly, each has to learn what addresses it can be reached at, a step called ICE candidate gathering. The browser lists its own network interfaces, then asks a public STUN server what address it appears to come from on the internet, and collects the answers as candidates. Any web page is allowed to start that process with a short script, no camera or microphone permission required, and read the candidates back.

This page does exactly that, in your browser, and shows you the list. The server's only role is to tell the script which public IP your connection arrived from, so the script can compare. The steps are:

1. The script creates a peer connection object with a public STUN server configured.
2. It opens a data channel, which triggers candidate gathering without touching any media device.
3. Every candidate the browser produces is written into the table as it arrives: its type, the address, the transport protocol and the port.
4. When gathering finishes, each public candidate is compared with the connection IP. The status is set to pass when every public address matches, and to fail when a public address differs. If no public candidate appears, the status explains why.
5. Nothing is sent to anyone except the STUN request itself; the comparison happens in the page. On the anonymity score page the same result is also posted back to our server so the WebRTC row of the score can be updated.

The four candidate types you may see:

The srflx row is the one that leaks. It is the address your UDP packets carry when they leave your network, and if your proxy only carries TCP, that address is your real one.

How to read your result

Compare the public candidate with the address at the top of the page. If they match, your setup passes this test even if other rows in the table look technical. If they differ, the different one is your real address, or at least an address your real network can be reached on, and no other check matters until this is fixed.

How to fix it

Pick the entry for what you use. Then press the run button on this page to gather candidates again; no reload is needed, though a reload is harmless.

VPN apps and extensions

1. In the VPN's browser extension, enable the WebRTC protection option. Most providers' extensions can block or rewrite WebRTC candidates for the browser they are installed in.
2. In the desktop app, make sure the tunnel is a full system VPN rather than a browser-only proxy mode; a full tunnel carries UDP, so the STUN reply arrives through the exit and the public candidate becomes the VPN's address.
3. Rerun the test; the srflx row should now equal the connection IP.

Chrome, Edge, Brave and other Chromium browsers

1. Brave has a built-in control: Settings, then Privacy and security, then WebRTC IP handling policy. Choose "Disable non-proxied UDP" to force candidates through a proxy or hide them when none is available.
2. Chrome and Edge have no user-facing toggle. Install the WebRTC Network Limiter extension or an equivalent and set it to use the default public interface only, or to disable non-proxied UDP. Enterprise policies can set the same thing for managed machines.
3. Rerun the test and confirm that no public address other than the connection IP appears.

Firefox

1. Open about:config in the address bar and accept the warning.
2. To stop WebRTC from exposing any address beyond the default route, set media.peerconnection.ice.default_address_only to true and media.peerconnection.ice.no_host to true. To turn WebRTC off entirely, set media.peerconnection.enabled to false.
3. With a SOCKS5 proxy, also set media.peerconnection.ice.proxy_only to true so candidates are gathered through the proxy or not at all.
4. Rerun the test.

Safari

1. Safari routes WebRTC through the system network stack, so a system-wide VPN protects it. Current versions offer no user switch for candidate gathering; the WebRTC entries in the Develop menu are developer options and should be left at their defaults.
2. If a leak persists on macOS, the fix belongs in the VPN app: enable its full-tunnel mode and its kill switch.

Antidetect browsers

1. Open the profile's WebRTC setting. Choose the mode that replaces or alters the public address with the proxy's address, often called replace or altered. The address shown here should then equal the proxy IP.
2. Avoid disabled mode for logins to strict sites; a browser with no WebRTC at all is uncommon and some fingerprinting scripts record that.
3. If the proxy is SOCKS5 without UDP support, replace mode is the only one that produces a matching public candidate; real mode will leak.

Android and iOS

1. Mobile browsers rarely expose WebRTC settings. Use a VPN app that tunnels all traffic; the public candidate then becomes the VPN's address.
2. Firefox for Android supports the same about:config keys as the desktop version on some release channels; where available, set media.peerconnection.enabled to false if you do not use calls in the browser.
3. For proxies on mobile, prefer apps that provide a VPN-style tunnel over browser-only proxy settings, which do not carry UDP.

Routers and firewalls

1. Blocking outbound UDP to port 3478 and the common STUN ports at the firewall removes srflx candidates for every device behind it. This is a blunt tool; it also breaks calls that rely on STUN.

Limits of this test

• One STUN server, one moment. Candidates are gathered against one public STUN server at the time you run the test. A site that uses its own TURN server or a different STUN server could see a different relay address, though the public srflx address would be the same.
• The comparison is against your connection IP as our server saw it. If you reached this page through a different path than the one your target site uses, for example a browser proxy that applies only to some domains, the comparison may not reflect that site's view.
• IPv6 candidates are compared only by address. An IPv6 srflx candidate when your connection is IPv4 is flagged because it is a route outside the tunnel; whether a given site will combine it with other data is up to that site.
• Extension behavior is not visible to the test. An extension that rewrites candidates makes the leak disappear from the table, which is the intent, but the test cannot tell a rewritten candidate from a real one. That is fine for a login check and worth remembering if you debug a call problem later.
• No media devices are touched. The test gathers candidates through a data channel only; it does not enumerate cameras or microphones, so a site that does may learn more about your device than this page shows.
• The .local names cannot be resolved by the page and are shown as the browser reports them. A site cannot turn them into your LAN address either.

Why WebRTC leaks behind proxies but less often behind VPNs

A proxy set in the browser carries the browser's web requests, which travel over TCP. WebRTC's address discovery is a UDP exchange with the STUN server, and browsers do not send UDP through an HTTP proxy; SOCKS5 can carry UDP in principle, but browser support for that is limited and off by default. So the STUN request leaves on your real connection and the reply names your real public address. A VPN operates below the browser, at the network interface, and carries every packet including UDP, so the STUN reply comes back through the exit and the public candidate is the VPN's address. That is the single reason a VPN passes this test by default while a proxy fails it, and the reason antidetect browsers add a replace mode: it fakes what a full tunnel would have produced.

Local addresses and mDNS

Older browsers reported your device's private address, such as 192.168.1.20, as a host candidate, which let sites fingerprint your home network and count devices. Current browsers replace it with a random name under .local, a technique borrowed from mDNS, and only resolve that name for a real peer on the same network. If you see a raw private address in the host row, the browser is old or a setting has disabled the masking. It is not the public-IP leak this page is about, but it is extra information a careful visitor would rather not give out.

Does a passing WebRTC test mean my VPN is safe?

It means WebRTC is not the channel leaking your address. Two other channels are tested separately: name lookups, covered by the DNS leak test, and IPv6 routing, covered by the IPv6 test. The IP leak test runs all three together with the IPv4 check, and the anonymity score combines them with the network and browser consistency checks. A webrtc leak is the most common of the three on proxied setups and the easiest to confirm, so it is the one to run first, not the only one to run.