WebRTC Loopback Candidates in Chrome: The Flag, Explained

The short answer

A loopback candidate is an address like 127.0.0.1 or ::1 that only points back at your own computer. Chrome doesn't include loopback addresses in WebRTC connection candidates by default. The only related setting, the --allow-loopback-in-peer-connection launch switch, does the opposite: it adds loopback addresses, and it exists for developers testing calls on one machine. There's no chrome://flags setting to turn loopback candidates off, because they're already off.

What WebRTC actually exposes

When a site starts a WebRTC connection, for a video call, file transfer, or chat widget, your browser gathers "ICE candidates": the addresses another computer could use to reach you. Two kinds matter for privacy:

• Your local network IP, like 192.168.1.20. Modern Chrome hides it by default behind a random name ending in .local, unless that protection has been turned off.
• Your public IP, found by asking a STUN server what address it sees you coming from. By default WebRTC can do this on every network interface, including the one your VPN doesn't cover. That's how a site can see your real public IP while your VPN is on.

So when people talk about a "WebRTC leak," they almost always mean the public IP, not loopback, and usually not the local address either.

The settings that do control it

Chrome decides which network interfaces WebRTC may use through an IP handling policy with four values:

• default: use every network interface. Best for call quality, worst for privacy.
• default_public_and_private_interfaces: only the interface that reaches the internet, but private addresses are allowed.
• default_public_interface_only: only the interface that reaches the internet, and no private addresses. A good balance: video calls still work for most people.
• disable_non_proxied_udp: no direct UDP at all. WebRTC goes through a proxy or falls back to TCP, so your real IP stays hidden, but some calls get choppier or fail.

There are three ways to set it:

1. An extension. Extensions can set this policy through Chrome's privacy settings, with no command line or admin access. WebRTC Privacy Shield, which I built, uses disable_non_proxied_udp by default and has a balanced mode (default_public_interface_only) for when calls need it.
2. A launch switch. Starting Chrome with --force-webrtc-ip-handling-policy=default_public_interface_only applies the policy for that session. Handy for testing, awkward for everyday use.
3. Company policy. On managed computers, IT sets the WebRtcIPHandling policy, and it overrides the other two.

What about the mDNS flag?

The WebRTC flag most people find is chrome://flags/#enable-webrtc-hide-local-ips-with-mdns, "Anonymize local IPs exposed by WebRTC." It's what replaces your local network address with a .local name, and it's on by default. Leave it on. Turning it off, or an administrator listing sites in the WebRtcLocalIpsAllowedUrls policy, puts your real local IP back into WebRTC candidates.

How to check your own browser

1. Connect your VPN, if you use one.
2. Open a WebRTC leak test and look at the addresses it finds. How to check if your VPN leaks through WebRTC walks through it.
3. If the test shows the public IP you have with the VPN off, WebRTC is leaking. Set the policy to default_public_interface_only or disable_non_proxied_udp and test again.
4. If you see a .local name instead of an address like 192.168.x.x, the local IP protection is working.

If you're a developer

If you need loopback candidates, for example to connect two peers on one machine, start a separate Chrome profile with --allow-loopback-in-peer-connection. Keep that profile for testing, not everyday browsing.