Prevent WebRTC IP Leaks Through a Proxy

A normal webpage showing the proxy exit does not automatically prove that WebRTC uses the same route. WebRTC searches for available network paths for real-time media and peer-to-peer connections, so a proxied profile needs its WebRTC network policy checked separately.

MaskPilot recommends Disable non-proxied UDP. It lets WebRTC use proxied UDP when the proxy supports it and otherwise fall back to proxied TCP, instead of using UDP outside the proxy. This restricts the network path without turning WebRTC off.

Check the current profile

1. Fully close the target profile and wait until it becomes available again.
2. Edit the profile and open WebRTC network policy in its fingerprint settings.
3. Confirm that Disable non-proxied UDP (recommended) is selected.
4. Save and relaunch the profile. A browser that is already running does not read the newly saved policy, so a full restart is required.
5. Check the normal page exit and the WebRTC test result inside that relaunched profile. Do not substitute another browser or profile.

New profiles use the recommended policy by default, but an existing profile may have a different saved choice. Check each affected profile during troubleshooting.

If the test still shows the device network

If a WebRTC test shows the device’s public IP, or an address clearly different from the normal page exit, work through these checks in order:

1. Confirm that you are testing the same profile that was edited and relaunched.
2. Return to Proxies and run Check connection on the assigned entry proxy. If it has an upstream proxy, also run Check full connection.
3. Confirm that the profile still uses the intended proxy and was not temporarily changed to a direct connection.
4. Fully close the profile again, confirm that no browser process remains, then relaunch and retest.
5. Pause another VPN, system proxy, or network filter that may rewrite the route. Change only one variable at a time.
6. Cross-check with a second trusted WebRTC test page instead of treating one page’s presentation as conclusive.

If the normal page exit is also wrong, fix the proxy route before changing WebRTC again. See fix a profile that will not start with a proxy and why the proxy check failed.

Do not disable every real-time feature first

The recommended policy restricts UDP that does not use the proxy; it does not remove WebRTC. Disabling real-time communication entirely can break meetings, voice, video, or peer-to-peer features and makes it harder to verify how the actual proxy route behaves.

The recommended policy can add latency to real-time communication. A feature may also fail when the service cannot establish the required connection through proxied UDP or TCP. If the workflow needs WebRTC, validate it in a test profile rather than selecting a more permissive network policy only to make one test page appear successful.

If the saved policy does not take effect

Like other fingerprint settings, the WebRTC policy is loaded when the browser starts. If the old result remains after saving:

• Confirm that you edited the intended profile.
• Confirm that the original browser process has fully exited.
• Do not change the proxy, browser version, and several fingerprint fields at the same time.
• Restore the recommended policy, fully relaunch, and then isolate one difference at a time.

For the settings lifecycle, see configure a stable browser fingerprint and why profile settings did not apply.

Before contacting support

Record the browser version, WebRTC policy, proxy type, whether an upstream route is present, whether the normal page exit matches the WebRTC result, and the retest time. Redact account details and proxy credentials from screenshots. Never submit the full proxy address, username, password, or secret.

Chrome Enterprise’s official WebRTC IP handling policy explains how the recommended value restricts non-proxied UDP. Chrome for Developers also documents the compatibility tradeoffs of proxying WebRTC.