Does a Browser Proxy Cover WebRTC?

A browser's HTTP proxy setting does not automatically cover WebRTC. A normal IP-check page measures a web request; a call can use separate connection and address-discovery paths.

SOCKS5 does not settle that distinction. Chromium's built-in SOCKS5 URL proxy implementation supports TCP rather than a general UDP association. The protocol's capabilities are broader than that browser interface.

Browsers provide separate WebRTC network controls. Chrome exposes an IP-handling policy through its privacy extension API, including disable_non_proxied_udp; Mozilla documents WebRTC network privacy settings too. The Chrome value is an API policy, not a universal checkbox or a guarantee to hide every address.

Check the ordinary web exit, then inspect WebRTC behavior in the actual conferencing application with a diagnostic whose reported fields you understand. Local addresses, relay addresses and publicly observed addresses describe different parts of a connection. Record the browser and test conditions: policies, extensions, privacy behavior and available paths affect the result, so neither “always leaks” nor a successful web IP check is a sufficient conclusion.

If you restrict a WebRTC path, retry the calls you need. Reducing address exposure can also prevent a call from connecting. That tradeoff is separate from whether an HTTP proxy endpoint is online.