La configuración de proxy HTTP del navegador no cubre WebRTC automáticamente. Una página corriente de comprobación de IP mide una petición web; una llamada puede usar otras rutas para conectarse y descubrir direcciones.

SOCKS5 no elimina esa diferencia. La implementación de proxy de URL SOCKS5 integrada en Chromium admite TCP, no una asociación UDP de uso general. El protocolo ofrece más posibilidades que esa interfaz del navegador.

Los navegadores ofrecen controles de red separados para WebRTC. Chrome expone una política de manejo de IP mediante su API de extensiones de privacidad, incluido disable_non_proxied_udp; Mozilla también documenta ajustes de privacidad de red de WebRTC. Ese valor de Chrome es una política de API, no una casilla universal ni una garantía de ocultar todas las direcciones.

Comprueba la salida web habitual y después revisa el comportamiento de WebRTC en la aplicación de conferencias que vayas a usar, con un diagnóstico cuyos campos entiendas. Las direcciones locales, de retransmisión y públicas observadas describen partes distintas de una conexión. Anota el navegador y las condiciones de prueba: las políticas, extensiones, comportamiento de privacidad y rutas disponibles influyen en el resultado. Ni «siempre filtra» ni una comprobación de IP web correcta bastan como conclusión.

Si restringes una ruta de WebRTC, vuelve a probar las llamadas que necesites. Reducir la exposición de direcciones también puede impedir que una llamada se conecte. Ese equilibrio es independiente de que el endpoint del proxy HTTP esté en línea.

Artículos relacionados