--- title: "Fugas de WebRTC y DNS: qué son y cómo evitarlas" description: "Incluso con un proxy activo, el navegador puede revelar tu IP real por WebRTC o DNS. Explicamos por qué ocurren las fugas, cómo detectarlas y cerrarlas." url: https://proxynet.io/es/blog/webrtc-dns-leak date: 2026-09-13 author: "Acar Diveroli" category: "Proxy 101, Tutoriales" lang: es --- # Fugas de WebRTC y DNS: qué son y cómo evitarlas Configuras un proxy en el navegador, la página de comprobación de IP muestra la dirección del proxy y todo parece correcto. Pero una página abierta en ese mismo navegador todavía puede conocer tu dirección IP real con unas pocas líneas de JavaScript. Hay dos vías habituales para que esto ocurra: **WebRTC** y las **consultas DNS**. Ambas funcionan fuera del tráfico HTTP que cubre un proxy, así que puede que la configuración del proxy no les afecte. En este artículo explicamos qué es una fuga de IP, el mecanismo por el que WebRTC expone tu dirección real, de dónde vienen las fugas de DNS y cómo comprobar ambas. Después vemos los ajustes de Chrome y Firefox que cierran la fuga, por qué importa la resolución DNS remota con SOCKS5 y otras señales, además de la IP, que delatan tu ubicación. Al final hay una lista de comprobación de una página. > **Nota: Respuesta breve** > > Una fuga de WebRTC ocurre cuando WebRTC, que el navegador usa para videollamadas, esquiva el proxy, llega a un servidor STUN por UDP y comunica a la página tu IP pública real. Una fuga de DNS ocurre cuando las consultas de nombres de dominio salen desde tu propia red en lugar de pasar por el proxy. Para WebRTC, usa la política `WebRtcIPHandling` en Chrome y los ajustes `media.peerconnection` en Firefox; para DNS, activa la resolución remota (`socks5h`) con SOCKS5. ## ¿Qué es una fuga de IP? Una fuga de IP es que tu dirección IP real quede visible a través de una parte de tu tráfico mientras usas un proxy o una VPN. Una fuga no significa que el proxy no funcione. Las peticiones HTTP de la página web pasan por el proxy, y el sitio de destino ve la dirección del proxy en esas peticiones. El problema es que el navegador también puede abrir otras conexiones de red además de HTTP. La configuración de proxy de un navegador suele cubrir solo las peticiones HTTP y HTTPS. Las otras conexiones que hace un navegador son: - **WebRTC:** conexiones directas por UDP para videollamadas, compartir pantalla y transferencia de datos entre pares. - **Consultas DNS:** consultas que el sistema operativo o el navegador envían a un servidor DNS para convertir nombres de dominio en direcciones IP. - **Extensiones del navegador y conexiones internas de aplicaciones:** componentes que usan su propia configuración de red. Si un sitio ve tu dirección real por uno de estos canales, puede compararla con la dirección que muestra el proxy. Dos direcciones de países distintos muestran claramente que el visitante usa un proxy. Explicamos cómo funciona un proxy en lo básico en [Qué es un servidor proxy y cómo funciona](/es/blog/what-is-a-proxy-server). ## ¿Cómo revela WebRTC tu IP real? WebRTC está diseñado para que dos navegadores hablen directamente entre sí sin pasar por un servidor. Para ello, cada navegador necesita conocer las direcciones en las que se le puede localizar y comunicárselas al otro lado. Estas direcciones se llaman **candidatos ICE**, y el proceso de descubrimiento está definido en [RFC 8445](https://www.rfc-editor.org/rfc/rfc8445). Cuando una página inicia una conexión WebRTC, ocurre lo siguiente: 1. **La página crea un `RTCPeerConnection`.** No necesita pedir permiso al usuario; no se enciende la cámara ni el micrófono. Basta con solicitar un canal de datos. 2. **El navegador reúne candidatos locales.** Son las direcciones de las interfaces de red del equipo (candidatos `host`). Los navegadores actuales ocultan la dirección local tras un nombre aleatorio `xxxx.local` en lugar de mostrarla directamente. 3. **El navegador envía un paquete UDP a un servidor STUN.** El servidor STUN devuelve la dirección IP pública y el puerto desde los que llegó el paquete. Esta dirección se registra como candidato `srflx` (server reflexive). 4. **El paquete UDP no pasa por el proxy.** Un proxy HTTP solo transporta tráfico HTTP; el navegador envía el paquete STUN directamente desde la interfaz de red. El servidor STUN ve llegar el paquete desde **tu IP pública real**. 5. **Los candidatos se comunican a la página.** JavaScript lee la lista de candidatos con el evento `onicecandidate` y puede enviar a su propio servidor la IP pública del candidato `srflx`. El resultado: la página ve la dirección del proxy en las peticiones HTTP y tu dirección real a través de WebRTC. Qué direcciones pueden exponer los navegadores en WebRTC está definido en [RFC 8828](https://www.rfc-editor.org/rfc/rfc8828) en cuatro modos: usar todas las interfaces, usar solo la ruta por defecto y su dirección local asociada, usar solo la dirección pública de la ruta por defecto y forzar UDP a través del proxy. Los ajustes de Chrome y Firefox corresponden a estos modos. ## ¿Qué es una fuga de DNS? Antes de conectarse a un sitio web, hay que convertir su nombre de dominio en una dirección IP. Una fuga de DNS es que esa consulta se haga a través del servidor DNS de tu proveedor de internet o de tu red local en lugar de a través del proxy. Cómo funciona la resolución de nombres y cómo ver o cambiar el servidor DNS que usa tu dispositivo lo explicamos en [¿Qué es el DNS y cómo cambiar tu servidor DNS?](/es/blog/what-is-dns). Una fuga de DNS tiene dos consecuencias: - **Los sitios que visitas son visibles desde la red local.** Tu proveedor de internet, la red de tu trabajo o alguien en la misma red wifi pueden ver qué nombres de dominio consultas, aunque uses un proxy. - **El sitio de destino puede darte otra dirección de servidor.** Los sitios que usan una CDN devuelven el servidor más cercano según la ubicación del servidor que hace la consulta DNS. Si la consulta sale desde Türkiye mientras la petición sale por un proxy en Alemania, te envían a un servidor lejano y aparece una incoherencia de ubicación. Las fugas de DNS son más frecuentes cuando: - Con un proxy SOCKS5, el cliente resuelve el nombre de dominio él mismo y envía al proxy solo una dirección IP. - El proxy está configurado solo en el navegador y otras aplicaciones usan el DNS del sistema. - El software de VPN o proxy no cambia la configuración DNS del sistema operativo. Con proxies HTTP y HTTPS, el navegador envía el nombre de dominio al proxy en la petición `CONNECT example.com:443` y la resolución la hace el proxy. Eso hace que los proxies HTTP sean menos arriesgados en cuanto a fugas de DNS para el tráfico web del navegador. Explicamos cómo difieren aquí los dos protocolos en [SOCKS o HTTP](/es/blog/socks-vs-http-proxy). ## ¿Cómo se comprueban las fugas de WebRTC y DNS? Existen páginas de prueba ya hechas, pero hacer la prueba tú una vez te enseña qué buscar. ### Prueba de WebRTC Con el proxy activo, abre cualquier página en el navegador, abre la consola de las herramientas para desarrolladores (F12) y ejecuta este código: ```javascript const pc = new RTCPeerConnection({ iceServers: [{ urls: "stun:stun.l.google.com:19302" }] }); pc.createDataChannel("test"); pc.onicecandidate = (e) => { if (e.candidate) console.log(e.candidate.candidate); }; await pc.setLocalDescription(await pc.createOffer()); ``` Verás algunas líneas de candidatos en la consola. Busca la línea que contiene `typ srflx`. Si la dirección IP de esa línea es: - **la misma que la IP de salida del proxy**, o no hay ninguna línea `srflx`, no hay fuga de WebRTC. - **tu dirección IP real**, hay una fuga de WebRTC. Si no conoces tu dirección IP real, abre una página de comprobación de IP con el proxy desactivado. ### Prueba de DNS Una fuga de DNS no se puede medir solo desde el navegador, porque únicamente el propietario del dominio puede ver desde qué servidor DNS llegó una consulta. Por eso las páginas de prueba de fugas de DNS te hacen resolver subdominios generados al azar y te muestran qué servidores DNS hicieron esas consultas. Si el resultado muestra los servidores DNS de tu propio proveedor de internet, las consultas no pasan por el proxy. En la línea de comandos, la salida detallada de cURL muestra cómo gestiona el DNS un proxy SOCKS5: ```bash # Resolución local: el nombre de dominio se convierte en IP en tu equipo curl -v -x "socks5://user:pass@pr.proxynet.io:1080" https://httpbin.org/ip # Resolución remota: el nombre de dominio se envía al proxy, que hace la resolución curl -v -x "socks5h://user:pass@pr.proxynet.io:1080" https://httpbin.org/ip ``` En la salida del primer comando, cURL indica que resolvió el dominio antes de conectarse y envió una dirección IP al proxy. En el segundo, se envía al proxy el propio nombre de dominio. Todas las opciones de proxy de cURL están en [Cómo usar un proxy con cURL](/es/blog/curl-proxy). ## ¿Cómo se evitan las fugas de WebRTC en Chrome? El menú de configuración de Chrome no tiene ninguna opción para desactivar WebRTC. Este comportamiento se cambia con una política empresarial o con extensiones. El método de la política no necesita extensiones y se basa en la documentación oficial de Google. La [política WebRtcIPHandling de Chrome Enterprise](https://chromeenterprise.google/policies/web-rtc-ip-handling/) admite estos valores: | Valor | Comportamiento | Equivalente en RFC 8828 | |---|---|---| | `default` | Se usan todas las interfaces de red | Modo 1 | | `default_public_and_private_interfaces` | Dirección pública y local de la ruta por defecto | Modo 2 | | `default_public_interface_only` | Solo la dirección pública de la ruta por defecto | Modo 3 | | `disable_non_proxied_udp` | Se desactiva el UDP que no pasa por un proxy; WebRTC recurre a TCP a través del proxy | Modo 4 | El valor que cierra la fuga cuando usas un proxy es `disable_non_proxied_udp`. En Windows puedes escribir esta política en el registro desde PowerShell abierto como administrador: ```powershell New-Item -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Force | Out-Null Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "WebRtcIPHandling" -Value "disable_non_proxied_udp" ``` Cierra Chrome por completo, vuelve a abrirlo y escribe `chrome://policy` en la barra de direcciones para comprobar que la política se ha cargado. Después repite la prueba de WebRTC anterior. Este ajuste tiene un costo: las herramientas de videollamada y de compartir pantalla basadas en el navegador no pueden usar UDP, así que pueden ralentizarse o dejar de funcionar. Si en el mismo equipo haces trabajo con proxy y videollamadas, es más práctico usar un perfil de navegador distinto, o un navegador distinto, para cada cosa. De dónde lee Chrome su configuración de proxy se explica en [Configuración de proxy en Windows y Chrome](/es/blog/windows-chrome-proxy-settings). ## ¿Cómo se evitan las fugas de WebRTC en Firefox? Firefox ofrece estos ajustes en la página `about:config`. Escribe `about:config` en la barra de direcciones, acepta el aviso y busca los ajustes siguientes. | Ajuste | Valor | Efecto | |---|---|---| | `media.peerconnection.ice.proxy_only_if_behind_proxy` | `true` | Con un proxy configurado, WebRTC se conecta solo a través del proxy | | `media.peerconnection.ice.default_address_only` | `true` | Solo se usa la dirección de la ruta por defecto | | `media.peerconnection.ice.no_host` | `true` | No se envían candidatos locales (host) | | `media.peerconnection.enabled` | `false` | WebRTC se desactiva por completo | El primer ajuste busca cerrar la fuga durante el uso del proxy sin romper del todo las herramientas de llamadas. Poner `media.peerconnection.enabled` en `false` es la solución más definitiva, pero desactiva todas las funciones de videollamada y de compartir pantalla del navegador. Para el DNS en Firefox, marca también **«DNS proxy usando SOCKS v5»** en la pantalla de configuración de proxy. En `about:config` esta opción es `network.proxy.socks_remote_dns`. La configuración completa de proxy en Firefox está en [Configuración de proxy en Firefox](/es/blog/firefox); para gestionar proxies por perfil, consulta nuestra guía de [SwitchyOmega](/es/blog/switchy-omega). ## ¿Por qué importa el DNS remoto con SOCKS5? El protocolo SOCKS5 permite al cliente indicar el destino al proxy de dos formas: como dirección IP o como nombre de dominio. Si el cliente envía una dirección IP, es que ha resuelto el nombre de dominio él mismo, lo que significa que la consulta DNS salió desde tu propia red. En librerías y herramientas este comportamiento tiene nombres distintos: - **cURL:** `socks5://` resuelve localmente y `socks5h://`, de forma remota. - **Python Requests y HTTPX:** el esquema `socks5h://` en la dirección del proxy. - **Firefox:** la opción «DNS proxy usando SOCKS v5». - **Chrome:** envía el nombre de dominio al proxy con SOCKS5. - **Herramientas de enrutamiento como Proxifier:** una opción del tipo «Resolver nombres de host a través del proxy». La segunda ventaja de la resolución remota es la coherencia de ubicación: cuando el proxy resuelve el DNS, las CDN devuelven un servidor cercano a la ubicación del proxy. Para los detalles técnicos de SOCKS5, consulta [¿Qué son los proxies SOCKS5?](/es/blog/socks5-proxy-101). Los esquemas que también cubren tráfico de aplicaciones usan planes [Proxies SOCKS5](https://proxynet.io/es/socks5-proxy). ## Señales, además de las fugas, que delatan tu ubicación Tras cerrar las fugas de IP y DNS, una página todavía puede reunir pistas sobre tu ubicación a partir de lo que sabe del propio navegador. No son fugas de red, pero cuando contradicen la ubicación del proxy tienen el mismo efecto. Los sitios que restringen contenido por país leen esas mismas señales; cómo deciden dónde estás lo explicamos en [¿Qué es el geobloqueo y cómo saben los sitios dónde estás?](/es/blog/what-is-geo-blocking). - **Zona horaria.** JavaScript lee la zona horaria del sistema con `Intl.DateTimeFormat().resolvedOptions().timeZone`. Una IP que sale en Alemania con la zona horaria `Europe/Istanbul` es una contradicción. - **Preferencias de idioma.** `navigator.languages` y la cabecera `Accept-Language` muestran el orden de idiomas del navegador. - **Permiso de ubicación.** Si has dado a un sitio permiso de ubicación en el navegador, la API de geolocalización puede devolver tu ubicación real a partir de las redes wifi cercanas. - **Cookies y sesiones.** Una cookie de sesión de una visita sin proxy se envía también en la visita con proxy y vincula ambas visitas. - **Huella del navegador.** La resolución de pantalla, las fuentes y la información de la tarjeta gráfica identifican el navegador con independencia de la IP. Los detalles están en [Browser fingerprinting](/es/blog/browser-fingerprinting). Si necesitas trabajar con más de una identidad, hay esquemas que mantienen coherentes entre sí el proxy, la zona horaria y el idioma de cada perfil; los explicamos en [¿Qué es un navegador antidetect?](/es/blog/what-is-antidetect-browser). ## Casos de uso - **Un equipo que revisa anuncios y contenido en distintos países:** una fuga de WebRTC puede hacer que el sitio te clasifique en una ubicación equivocada. Junto con un [Proxies residenciales](https://proxynet.io/es/residential-proxy), que sale por líneas de usuarios reales, también hay que corregir los ajustes del navegador. - **Un desarrollador que prueba tráfico con aspecto móvil:** una IP de operador móvil que aparece en WebRTC junto con la dirección real de una red de escritorio crea una incoherencia. La misma comprobación vale al usar un [Proxies móviles](https://proxynet.io/es/mobile-proxy). - **Un usuario que enruta una aplicación de escritorio por un proxy:** las consultas DNS de la aplicación pueden pasar por el DNS del sistema; hay que activar la resolución remota en la herramienta de enrutamiento. - **Un equipo que usa automatización de navegador:** los navegadores de automatización también admiten WebRTC. Al iniciar Chrome hay que usar la misma política o un ajuste de arranque equivalente. ## Errores comunes - **Dar por suficiente el resultado de la página de comprobación de IP.** Estas páginas solo muestran la dirección de la petición HTTP; WebRTC y DNS hay que comprobarlos por separado. - **Cambiar el ajuste sin reiniciar el navegador.** Las políticas de Chrome no se cargan hasta cerrar y volver a abrir el navegador por completo. - **Usar VPN y proxy a la vez e interpretar mal la dirección filtrada.** Con una VPN activa, en la prueba de WebRTC aparece la dirección de la VPN; no es tu dirección real, pero tampoco coincide con la del proxy. - **Dejar el esquema `socks5://` como predeterminado.** La mayoría de los ejemplos de librerías usan el esquema que resuelve localmente. - **Desactivar WebRTC por completo y extrañarse de que las herramientas de llamadas no funcionen.** `proxy_only_if_behind_proxy` o un perfil aparte consiguen lo mismo con menos efectos secundarios. - **Olvidar la zona horaria y el idioma.** Aunque las fugas de red estén cerradas, estas señales revelan la incoherencia de ubicación. ## Lista de comprobación | Comprobación | Cómo | Resultado esperado | |---|---|---| | Dirección de salida HTTP | Página de comprobación de IP | La dirección del proxy | | Candidatos WebRTC | Prueba de `RTCPeerConnection` en la consola | Sin `srflx`, o con la dirección del proxy | | Política de Chrome | `chrome://policy` | `WebRtcIPHandling: disable_non_proxied_udp` | | WebRTC en Firefox | `about:config` | `proxy_only_if_behind_proxy: true` | | DNS con SOCKS5 | Esquema en la dirección del proxy | `socks5h://` u opción de DNS remoto activada | | Servidores DNS | Prueba de fugas de DNS | No aparecen los servidores de tu propio proveedor | | Zona horaria e idioma | Ajustes del navegador y del sistema operativo | Coherentes con la ubicación del proxy | | Cookies | Perfil aparte o sesión limpia | Ninguna cookie de sesión de fuera del proxy | ## Preguntas frecuentes ### ¿Las fugas de WebRTC solo afectan a quienes usan un proxy? También pueden afectar a quienes usan una VPN, pero como la mayoría de las VPN funcionan a nivel del sistema operativo y también llevan el tráfico UDP por el túnel, las fugas son menos frecuentes. Un proxy solo cubre el tráfico HTTP del navegador, así que el riesgo es mayor. ### ¿Desactivar WebRTC rompe los sitios web? Las videollamadas, el chat de voz, la función de compartir pantalla y algunos servicios de transferencia de archivos basados en el navegador dejan de funcionar o se ralentizan. La gran mayoría de los sitios web normales no se ven afectados. ### ¿Se sigue filtrando mi dirección IP local (192.168...)? Las versiones actuales de Chrome y Firefox ocultan por defecto las direcciones locales tras nombres aleatorios terminados en `.local`. El riesgo real es la IP pública obtenida a través de STUN. ### ¿Puede haber una fuga de DNS con un proxy HTTP? Normalmente no para el tráfico web del navegador, porque el nombre de dominio se envía al proxy en la petición `CONNECT`. Pero otras aplicaciones y componentes del sistema operativo que no tienen proxy configurado siguen haciendo sus propias consultas DNS. ### ¿Hay fugas de WebRTC en dispositivos móviles? Puede haberlas. Los navegadores móviles también admiten WebRTC, y un proxy wifi configurado en el teléfono solo cubre el tráfico HTTP. Explicamos la configuración de proxy en iPhone en [Configuración de proxy en iPhone](/es/blog/iphone-proxy); puedes hacer la misma prueba de WebRTC en un navegador móvil. ### He cerrado la fuga, pero el sitio sigue sabiendo que uso un proxy. ¿Por qué? Puede que la propia dirección IP pertenezca a un centro de datos, que la zona horaria y el idioma contradigan la ubicación del proxy o que la huella del navegador coincida con tu visita anterior. Una fuga de red es solo una de estas señales. ## En resumen Un proxy transporta el tráfico HTTP del navegador; las conexiones UDP de WebRTC y algunas consultas DNS pueden quedar fuera de ese alcance. Cierra las fugas de WebRTC con la política `WebRtcIPHandling` en Chrome y los ajustes `media.peerconnection` en Firefox. Para las fugas de DNS, usa resolución remota con SOCKS5 y confirma los resultados con la prueba en la consola. Después asegúrate de que la zona horaria, el idioma y las cookies son coherentes con la ubicación del proxy. Encontrarás planes para tráfico de navegador y de aplicaciones en nuestros [servicios de proxy](/es/proxy).