Índice
Una fuga WebRTC es tu navegador entregando tu dirección IP real a un sitio web mientras crees que estás oculto tras una VPN. No es un fallo de tu VPN ni es malware. Es WebRTC haciendo exactamente aquello para lo que fue diseñado: encontrar la ruta de red más rápida posible entre dos navegadores, lo que implica averiguar primero tu dirección IP real.
Qué es una fuga WebRTC
WebRTC (Web Real-Time Communication) es la API del navegador detrás de las videollamadas, el chat de voz y la transferencia de archivos entre pares que funciona sin plugins. Jitsi, Google Meet, la voz de Discord y la mayoría de las herramientas de videollamada en el navegador la usan.
Para conectar dos navegadores directamente en lugar de retransmitir cada paquete a través de un servidor, WebRTC necesita conocer la dirección IP real de cada lado. La obtiene mediante STUN (Session Traversal Utilities for NAT), una consulta ligera que pregunta a un servidor "¿cuál es mi IP pública vista desde fuera de mi router?". Esa consulta pasa por la propia pila de red del navegador, no por el túnel que el cliente de tu VPN haya creado para el resto de tu tráfico. Si tu VPN no la intercepta expresamente, la respuesta STUN vuelve con tu IP real, y cualquier página que ejecute JavaScript de WebRTC puede leerla.
Es un hueco de la VPN, no un fallo de la VPN
Cómo se produce realmente la fuga
- Una página carga código WebRTC (un widget de videollamada, un script de fingerprinting de una red publicitaria, cualquier cosa que llame a RTCPeerConnection).
- El navegador envía una petición STUN para descubrir su IP pública dentro del proceso de recopilación de candidatos ICE.
- Esa petición sale por la pila de red del sistema operativo, que en la mayoría de configuraciones VPN es justo donde el túnel debería atraparla, pero a menudo no lo hace.
- El JavaScript de la página lee directamente los candidatos de IP devueltos, sin necesidad de ida y vuelta a un servidor, y ya tiene tu dirección real.
Por eso la solución tampoco es tan sencilla como "bloquear WebRTC". STUN, TURN e ICE son el mismo mecanismo que hace rápidas las videollamadas entre pares, y el mismo proceso de recopilación de candidatos que documenta MDN para crear aplicaciones WebRTC es el que filtra tu IP como efecto secundario. Nuestro análisis de STUN vs. TURN vs. ICE y nuestra guía de arquitectura WebRTC explican cómo funciona esa negociación si quieres la mecánica en profundidad.
No afecta por igual a todos los navegadores
Qué queda realmente expuesto
| Expuesto | No expuesto |
|---|---|
| Tu dirección IP pública real | El historial de navegación o el contenido de las páginas |
| Ubicación geográfica aproximada (a nivel de ciudad, por la IP) | Credenciales de acceso o cookies de sesión |
| Tu proveedor de internet, deducible del bloque de IP | Archivos o contenido del portapapeles |
El riesgo práctico es la correlación, no el robo de datos. Si un sitio o un anunciante puede vincular una vez tu sesión VPN con tu IP real, puede llegar a relacionar tu navegación "anónima" con tu identidad o tu ubicación reales en visitas futuras.
Cómo comprobar si tienes una fuga WebRTC
Conecta tu VPN y abre browserleaks.com/webrtc o ipleak.net. Ambos muestran todas las direcciones IP que la pila WebRTC de tu navegador está dispuesta a entregar. Compáralas con la IP de tu VPN (compruébala por separado en cualquier página de "cuál es mi IP" con la VPN activada).
Las IP locales no son automáticamente una fuga
Si prefieres verlo ocurrir en lugar de fiarte de un sitio de terceros, abre las DevTools (F12), ve a la pestaña Network y carga una de las páginas de prueba de arriba con los filtros WebSocket/other desactivados. Verás salir la petición STUN y volver en la respuesta las IP candidatas, los mismos datos que el sitio de prueba solo te está presentando con formato.
También puedes hacer la comprobación sin un sitio de terceros: abre nuestro probador ICE de WebRTC con la VPN activada, elige el preajuste STUN y recopila los candidatos. Si un candidato server reflexive muestra tu IP pública real en lugar de la de la VPN, esa es la fuga.
Solucionarla en cada navegador
| Navegador | Qué hacer | Contrapartida |
|---|---|---|
| Firefox | about:config → poner media.peerconnection.enabled en false | Desactiva WebRTC por completo y rompe Meet, la voz de Discord y cualquier sitio que use RTCPeerConnection |
| Chrome / Edge | No hay un interruptor para el usuario. Usa una extensión basada en la API webRTCIPHandlingPolicy de Chrome (ver abajo) | Exige confiar en una extensión de terceros |
| Safari | WebRTC está activado por defecto desde Safari 11; tampoco hay un interruptor sencillo para desactivarlo | Menos opciones de extensiones que Chrome/Firefox |
Como un interruptor que desactive WebRTC por completo rompe las
videollamadas legítimas, una extensión del navegador que restrinja el
enrutamiento de WebRTC en lugar de desactivar toda la API es la
solución más práctica para la mayoría de la gente. Chrome ofrece una
API de privacidad
que permite a una extensión fijar webRTCIPHandlingPolicy en
disable_non_proxied_udp, lo que obliga a WebRTC a pasar por
la interfaz de proxy o VPN configurada en lugar de salir directamente.
WebRTC Leak Prevent
es una extensión actual y de código abierto basada exactamente en esa API.
uBlock Origin ya no lo hace en escritorio
Elijas la solución que elijas, vuelve a hacer después la prueba de la sección anterior. Las actualizaciones del navegador desactivan las extensiones más a menudo de lo que la gente cree.
El papel de tu VPN
No todas las VPN gestionan esto igual, y los textos de marketing ("cifrado de grado militar", "anonimato total") no dicen nada sobre WebRTC en concreto. Antes de confiar en que una VPN lo cubra, busca:
- Una mención explícita a la protección contra fugas WebRTC en la propia documentación de la VPN, no solo a la protección contra fugas DNS o a un kill switch (son mecanismos distintos)
- Una extensión del navegador del mismo proveedor, ya que el bloqueo de fugas WebRTC suele implementarse a nivel de extensión y no en el cliente VPN del sistema operativo
- Resultados de pruebas independientes, no solo las afirmaciones del propio proveedor
Después compruébalo tú mismo con la prueba de antes, en el navegador y el dispositivo que usas a diario. Una VPN que bloquea las fugas WebRTC en Chrome de escritorio no tiene por qué hacer lo mismo en su aplicación móvil.
Si prefieres no depender de la palabra de un proveedor de VPN externo para nada de esto, la alternativa es tener la tuya propia. Nuestra comparación de VPN autoalojadas cubre instalaciones de OpenVPN, WireGuard y Headscale en las que controlas la configuración del cliente de principio a fin.
Si desarrollas sobre WebRTC
Si eres tú quien gestiona la infraestructura de videoconferencia en lugar de solo usarla, la conversación sobre las fugas se invierte: quieres un descubrimiento de IP preciso para que las llamadas se conecten entre pares en lugar de retransmitirse por un servidor TURN en cada sesión. La pregunta de privacidad pasa a ser qué hace tu propio código del lado del cliente con las IP candidatas que recopila, y si las estás registrando en algún sitio donde no deberías. Los despliegues autoalojados (por ejemplo, Jitsi detrás de tu propia instancia de coturn) te dan una visibilidad sobre ese flujo de datos que una herramienta SaaS alojada no te da.
Las direcciones IP cuentan como datos personales según el RGPD y normativas similares, así que si tu aplicación atiende a usuarios de la UE, registrar las IP candidatas en bruto de las sesiones WebRTC es una decisión que conviene tomar de forma consciente y no por defecto. Consulta nuestras notas sobre despliegues WebRTC conformes con el RGPD y nuestras buenas prácticas de seguridad para Jitsi Meet si eres tú quien opera la infraestructura y no solo un usuario de ella.
Preguntas frecuentes
¿Qué es una fuga WebRTC?
Una fuga WebRTC (WebRTC leak) ocurre cuando el motor WebRTC de tu navegador revela tu dirección IP real a un sitio web aunque estés conectado a través de una VPN. Sucede porque WebRTC hace su propio descubrimiento de IP (mediante STUN) fuera del control de la VPN, no porque la VPN en sí haya fallado.
¿Cómo compruebo si tengo una fuga WebRTC?
Abre browserleaks.com/webrtc o ipleak.net con la VPN conectada. Si ves cualquier dirección IP distinta de la de tu VPN, es una fuga. Que aparezcan IP locales o privadas (192.168.x.x, 10.x.x.x) no es una fuga por sí solo, ya que Chrome las oculta tras mDNS por defecto, pero una IP pública que no sea la de tu VPN sí lo es.
¿Desactivar WebRTC en el navegador lo soluciona?
Sí, pero es una solución tosca. En Firefox, poner media.peerconnection.enabled en false en about:config desactiva WebRTC por completo, lo que también rompe Google Meet, la voz de Discord y cualquier sitio que llame a RTCPeerConnection. Chrome no tiene un interruptor único equivalente. Si dependes a diario de videollamadas basadas en WebRTC, una extensión con un alcance limitado suele ser mejor compromiso que desactivar la API por completo.
¿Qué revela realmente una fuga WebRTC?
Tu dirección IP pública real. A partir de ella, un sitio puede deducir tu ubicación geográfica aproximada y tu proveedor de internet, y relacionarla con otras sesiones en las que tu VPN no estaba activa. No revela el historial de navegación, las credenciales ni el contenido de archivos.
¿Por qué importa esto si ya uso una VPN?
Porque la fuga se produce en una capa que la VPN no toca. Una VPN redirige tu tráfico IP general, pero las peticiones STUN de WebRTC pueden resolver tu IP real directamente a través de la pila de red. Que tu VPN concreta lo bloquee depende de si el proveedor incluyó la gestión de WebRTC en su cliente, no del protocolo de la VPN en sí.
¿Cómo evito que una VPN filtre el tráfico WebRTC?
Comprueba si el cliente de tu VPN documenta específicamente la protección contra fugas WebRTC (no solo el 'kill switch' o la 'protección contra fugas DNS', que son cosas distintas). Si no lo hace, o no estás seguro, añade una extensión del navegador que bloquee WebRTC como segunda capa y vuelve a hacer la prueba con la VPN activada.
¿Son vulnerables tanto Chrome como Firefox?
Ambos implementan WebRTC, así que ambos pueden tener fugas. Chrome oculta por defecto las IP de la red local tras nombres de host mDNS desde Chrome 75 (2019), lo que cierra automáticamente una vía de fuga. No afecta a la capacidad de STUN de descubrir tu IP pública real. Safari admite WebRTC por defecto desde Safari 11, así que el antiguo consejo de que Safari es 'inmune' está desactualizado.
¿También es un problema de los navegadores móviles?
Sí. Chrome y Firefox para móvil implementan la misma pila WebRTC que en escritorio, así que se aplica la misma fuga basada en STUN. La solución es la misma: revisa cómo gestiona WebRTC la aplicación de tu VPN y usa una extensión que bloquee WebRTC si tu navegador móvil admite extensiones.
¿Gestionas tu propia infraestructura WebRTC?
Desplegamos y protegemos instalaciones autoalojadas de Jitsi y coturn para equipos que quieren controlar a dónde van realmente los datos de las llamadas y las conexiones.
Habla con nuestro equipo