WebRTC leaks explained, and how to disable WebRTC

WebRTC is the browser technology behind video calls, screen sharing and peer-to-peer file transfer that run without a plugin. To connect 2 browsers directly it has to find out what addresses each one can be reached at, and it will tell any web page that asks. When you are behind a proxy or a VPN, the address it finds can be your real one. That is a WebRTC leak, and a page can trigger it with a few lines of script, no camera permission, no visible sign.

This article explains what is exposed and why, how to see it, and how to restrict or disable WebRTC in each browser, with the trade-offs of each approach.

What WebRTC exposes

Before 2 peers can connect, each gathers ICE candidates: a list of address and port pairs it might be reachable on. The browser builds that list in 3 ways.

Candidate type	What it contains	How the browser gets it
host	The addresses of your own network interfaces: LAN address, VPN adapter address, IPv6 addresses	Read straight from the operating system
srflx (server reflexive)	The public address and port your traffic appears from on the internet	By sending a UDP packet to a STUN server, which replies with the source address it saw
relay	The address of a TURN relay server	Only when the page configures one

The srflx candidate is the leak. Your device sends a tiny UDP packet to a STUN server and the server answers "you came from this address". Behind a home router that address is your public IP, after NAT has translated it. The important detail is the path the packet takes:

• Through a VPN that tunnels UDP, the packet leaves via the tunnel and the STUN server sees the VPN's address. No leak.
• Through an HTTP or SOCKS proxy configured in the browser, the packet does not go through the proxy at all. Proxies carry the TCP connections the browser hands them; the STUN request is UDP sent directly by the browser. The STUN server sees your real address, and so does the page.

Host candidates used to be a second problem: the browser handed out your private LAN address, such as 192.168.1.20, and the address of any VPN adapter. Over 2019 to 2021, Chromium browsers, Safari and Firefox moved to replacing private host addresses with a random name ending in .local, resolved through mDNS only by peers on the same network. A .local name in a test result is therefore the expected, harmless outcome. A raw private address appearing means an old browser or a changed setting.

IPv6 adds a third angle. If your device has a global IPv6 address and the STUN server is reachable over IPv6, the browser can gather an IPv6 srflx candidate even when your IPv4 traffic is tunneled. That is the same mechanism as an IPv6 leak, surfacing through WebRTC instead of a page load.

How to test it

Open the WebRTC leak test. It creates a throwaway peer connection against a public STUN server, lists every candidate your browser produces and compares the public ones with the address your connection arrived from. Read it like this:

• Only a .local name, plus one srflx address equal to your connection IP: no leak. WebRTC works and shows the same address as everything else.
• An srflx address different from your connection IP: a leak. That is your real address, or at least an address your real network is reachable on. On our anonymity score this costs 15 points, and on strict sites it ends the session.
• Only host candidates, no srflx: UDP to the STUN server is blocked. Nothing public is exposed.
• No candidates at all: WebRTC is disabled. Nothing is exposed; the browser is identifiable as one with WebRTC off.

The glossary entry on WebRTC leak has the short definition. The combined IP leak test runs the same check alongside DNS and IPv6 so you see all 3 side by side.

Fixing it: 3 strategies

Before the per-browser settings, decide which outcome you want, because they are different.

1. Make WebRTC show the right address. Use a VPN that tunnels UDP, or an antidetect profile that substitutes the proxy address for the discovered one. WebRTC keeps working, the page sees a consistent story, nothing stands out. This is the best result when it is available.
2. Restrict WebRTC to proxied traffic. Chromium's "disable non-proxied UDP" policy makes WebRTC use only a proxy if one is configured, over TCP, and gather no direct UDP candidates. Calls may still work through TURN relays; the leak is closed.
3. Disable WebRTC entirely. Simplest and most reliable, at the cost of browser calls and a small fingerprint signal.

Chrome and Edge

Neither browser has a user-facing switch; the behavior is controlled by the WebRTC IP handling policy, which extensions and administrators can set. The 4 values are:

Value	Effect
default	Gather every candidate, private addresses as mDNS names
default_public_and_private_interfaces	Same, but only interfaces with a default route
default_public_interface_only	Only the interface used for the default route; hides VPN or secondary adapters
disable_non_proxied_udp	No direct UDP. WebRTC works only through a configured proxy over TCP

Options, in order of preference:

• An extension that sets the policy. Any extension using the browser's privacy API can switch the policy; look for one whose only purpose is WebRTC control, set it to disable non-proxied UDP, and confirm with the test. Several open-source content blockers also include a setting labeled "Prevent WebRTC from leaking local IP addresses", which applies the public-interface-only policy.
• Enterprise policy, for managed machines or when you want a setting no extension can change: the Chrome policy is WebRtcIPHandling, the Edge policy is WebRtcLocalhostIpHandling, both accepting the values above. On Windows they are registry values under the browser's Policies key; on macOS and Linux, managed preferences.
• Launch flag for a dedicated profile: starting the browser with --force-webrtc-ip-handling-policy=disable_non_proxied_udp applies the policy for that session only.

There is no reliable way to turn WebRTC off completely in Chrome or Edge without an extension; disable non-proxied UDP is the closest built-in equivalent.

Firefox

Firefox exposes the controls directly in about:config. Type about:config in the address bar, accept the warning and search for the preference.

Preference	Set to	Effect
media.peerconnection.enabled	false	Disables WebRTC entirely. The test shows no candidates.
media.peerconnection.ice.default_address_only	true	Gathers candidates only on the default route interface
media.peerconnection.ice.no_host	true	No host candidates at all, only STUN and relay
media.peerconnection.ice.proxy_only_if_behind_proxy	true	When a proxy is configured, send all ICE traffic through it; no direct UDP

For a browser using a SOCKS or HTTP proxy, proxy_only_if_behind_proxy is the setting that closes the leak while keeping WebRTC alive. For a VPN that tunnels UDP, default_address_only keeps a secondary interface from showing up. For maximum certainty, media.peerconnection.enabled = false. Changes apply immediately; reload the test to confirm.

Firefox on Android only exposes about:config in the Nightly and Beta builds, so on the release version the fix is a VPN that tunnels UDP.

Safari

Safari has no user-facing WebRTC switch on macOS or iOS. Its default behavior is already conservative: host candidates are hidden behind mDNS names and, without camera or microphone permission, local addresses are not exposed at all. It does perform STUN, so a server-reflexive address can still appear, and that address is your real one if your proxy does not carry UDP.

The macOS Develop menu contains experimental WebRTC toggles under Develop > Feature Flags…, but they change between versions and are debugging aids, not a privacy control. The dependable fixes for Safari are a VPN that tunnels UDP, or a content blocker rule set that blocks the STUN servers a page tries to use, which is fragile. If you must use a browser-level proxy on a Mac for sensitive work, use Firefox or a Chromium browser with the policy set.

Brave

Brave ships the Chromium policy as a setting. Open Settings > Privacy and security (older versions list it under Shields) and find "WebRTC IP handling policy". The 4 options map directly to the table above. "Disable non-proxied UDP" is the right choice when a proxy is configured; "Default public interface only" is enough for a VPN that tunnels UDP. Brave applies the setting without a restart; reload the test.

Tor Browser and antidetect browsers

Tor Browser ships with WebRTC disabled and should stay that way; the network does not carry UDP.

Antidetect and multi-profile browsers add a per-profile WebRTC mode, usually with 3 values: real (leak), disabled, and altered or replaced, where the candidate shows the profile's proxy address instead of the real one. Use the altered mode when the site you are logging into uses WebRTC itself, disabled otherwise, and verify the result from inside the profile rather than trusting the label. A profile whose altered address differs from its proxy address, because the proxy rotated after the profile was configured, fails the test just as a real leak would.

Phones

Mobile browsers offer nearly nothing here. iOS Safari and Chrome on both platforms have no setting, Firefox on Android hides the preferences on the release build, and content blockers cannot intercept UDP. The one fix that works on every phone is a VPN app that tunnels all traffic, including UDP, so the discovered address is the VPN's. Browser-level proxies on phones should be considered leaky for WebRTC unless the test proves otherwise.

The trade-offs

Approach	Leak closed	Calls work	Stands out
VPN that tunnels UDP	Yes	Yes	No
Antidetect "altered" mode	Yes, if the address matches the proxy	Usually	No
Disable non-proxied UDP	Yes	Only through TURN over TCP via the proxy	Slightly
Public interface only	Only for secondary adapters; direct UDP still leaks without a VPN	Yes	No
WebRTC disabled	Yes	No	Yes: no candidates at all

"Stands out" matters more than it seems. Anti-fraud systems compare a visitor with the population of visitors, and a browser that returns no candidates is a minority. It is a far smaller signal than an exposed real address, so if the choice is between the 2, disable. But when a VPN or a substituted address is available, it gives the better result: WebRTC behaves like everyone else's and reports the same address as the rest of your connection. That consistency, not the absence of a feature, is what a browser fingerprint check is looking for.

Whatever you choose, change the setting, reload the test, and only then log in. WebRTC is one of the few leaks that hands a site your real address in one request, and the test takes 5 seconds.