Tema

Herramientas populares

Test de fuga de WebRTC

WebRTC puede entregar a un sitio web direcciones que su navegador no enviaría de otro modo, incluida la que está detrás de su VPN. Este test pregunta a tres servidores STUN operados por Cloudflare y Google, muestra cada dirección que volvió y qué es cada una, y las compara con la dirección que un sitio web ya ve. Cuando no puede probar algo, lo dice en lugar de mostrarle una marca verde.

Se ejecuta en su navegador con los servidores STUN de Cloudflare y Google · no se guarda nada · tipos de candidato según RFC 8445

Hágalo una vez con la VPN desactivada y otra con la VPN activada. La diferencia es la respuesta.

Su navegador pregunta a tres servidores STUN, de Cloudflare y Google, qué dirección ven. Ninguna dirección que encuentre WebRTC se nos envía.

Lo que un sitio web ve de todos modosIPv4IPv6Buscando su conexión…
Cada dirección que produjo WebRTC

  1. Cada dirección que produce WebRTC aparece aquí, una por fila, a medida que responden los servidores STUN.

Ninguna dirección que encuentre WebRTC se nos envía. Su navegador pregunta a los servidores STUN por sí mismo, como en cualquier videollamada. Para mostrar lo que ve un sitio web, la página pregunta a ipify.org y a nuestro propio servidor por sus direcciones y sus redes, igual que el Test de fugas DNS.

¿Qué es una fuga de WebRTC?

WebRTC es la función del navegador detrás de las videollamadas. Para conectar a dos personas directamente, reúne cada dirección por la que se puede llegar a su máquina y se las ofrece a la página, incluidas direcciones que su navegador nunca enviaría en una solicitud normal.

El proceso se llama recolección de candidatos ICE (ICE candidate gathering) y está especificado en RFC 8445. Su navegador enumera las direcciones de sus propias interfaces de red, luego pregunta a un servidor STUN «¿desde qué dirección me ve llegar?» y agrega también esa. Cualquier página de internet puede iniciar esto con unas pocas líneas de JavaScript y leer cada candidato a medida que llega, sin ningún aviso de permiso: así está diseñado, porque una llamada tiene que funcionar sin él.

Se convierte en una fuga cuando una de esas direcciones es algo que usted estaba ocultando. Una VPN cambia la ruta que siguen las solicitudes de su navegador, pero WebRTC puede preguntar al sistema operativo por todas las interfaces, así que en una máquina donde la conexión física sigue activa, la dirección real puede aparecer junto a la de la VPN. Nada ha fallado: la función hace exactamente aquello para lo que fue diseñada.

Lo que cualquier página puede iniciaruna recolección, paso a paso

SU DISPOSITIVOINTERNETSu router (NAT)Script de la páginaSu navegadorServidor STUNstun.cloudflare.comnew RTCPeerConnection()sin aviso de permisoenumera cada interfaz de red192.168.1.20 → 8b7f4e2a-….local¿desde qué dirección me ve llegar?192.168.1.20:54400203.0.113.7:54400203.0.113.7:54400la dirección que viocada candidato, a medida que llegaonicecandidateSU DISPOSITIVOINTERNETScript de la páginaSu navegadorServidor STUNnew RTCPeerConnection()sin aviso de permisoenumera cada interfaz de red192.168.1.20 → 8b7f4e2a-….local¿desde qué dirección me ve llegar?192.168.1.20203.0.113.7203.0.113.7:54400la dirección que viocada candidato, a medida que llegaonicecandidateSu router (NAT)

El script completo

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());

Lo que imprimió

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0

Qué es cada línea

  • hostEn esta máquina8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localEnmascarada por su navegador
  • srflxVista por un servidor STUN203.0.113.7Enrutable en internet
Una recolección en una conexión doméstica, con direcciones de documentación. La dirección privada nunca sale del navegador tal cual; el servidor STUN ve el lado público del router, no la máquina, y ambas respuestas van a cualquier script que las haya pedido.
Resultado del test de fuga de WebRTC con cada candidato ICE, su tipo, qué es cada dirección y el veredictoResultado del test de fuga de WebRTC con cada candidato ICE, su tipo, qué es cada dirección y el veredictoEl veredictoFuga, sin fuga o, con honestidad, no se pudo probar, con el motivo.Cada direcciónCon su tipo de candidato, porque un candidato host significa algo distinto de uno reflexivo de servidor.Qué esPrivada, NAT de operador, un túnel o enrutable. Solo una dirección enrutable puede ser una fuga.Los servidoresCada servidor STUN en su propia línea. Un servidor que no dijo nada es un test que no se ejecutó.Lo que ve un sitio webLas direcciones que su navegador envía de todos modos, con las que se comparan las de WebRTC.
Una ejecución del test: qué respondió cada servidor STUN, cada dirección que expuso WebRTC, qué tipo de dirección es y si es una que el sitio web ya ve. Seleccione un número para ver qué muestra cada parte.

Cómo comprobar si hay una fuga de WebRTC

Inicie el test de arriba. Reúne candidatos de tres servidores STUN, determina qué es cada dirección y compara las enrutables con la dirección que un sitio web ya ve.

Hay tres resultados posibles, no dos.Sin fuga significa que cada dirección enrutable que produjo WebRTC es una que el sitio ya tiene. Fuga significa que al menos una no lo es, o que se ofreció directamente una dirección de su propia máquina. No se pudo probar significa que WebRTC está desactivado, bloqueado o que ningún servidor STUN respondió, y es el resultado que la mayoría de las herramientas convierten discretamente en un aprobado.

Hágalo dos veces si usa una VPN: una con ella desactivada, para ver sus direcciones habituales, y otra con ella activada. La segunda ejecución es la que importa, y la diferencia entre ambas es la respuesta. La página guarda el primer resultado para que pueda comparar sin anotar nada.

Tres resultados, no dosqué significa cada uno

  1. Sin fuga

    Cada dirección enrutable que produjo WebRTC es una que un sitio web ya tiene.

    WebRTC entregó

    • 198.51.100.23Vista por un servidor STUNYa la ven los sitios web
    • 8b7f4e2a-….localEn esta máquinaEnmascarada por su navegador

    Un sitio web ve

    198.51.100.23
  2. Fuga

    Al menos una dirección no es una que el sitio ya tiene, o se ofreció directamente una dirección de su propia máquina.

    WebRTC entregó

    • 198.51.100.23Vista por un servidor STUNYa la ven los sitios web
    • 2001:db8:4a1f:7c00::1cEn esta máquinaNo la ven los sitios web

    Un sitio web ve

    198.51.100.23
  3. No se pudo probar

    WebRTC está desactivado o bloqueado, o ningún servidor STUN respondió. No se midió nada.

    stun.cloudflare.comSin respuesta

    stun.l.google.comSin respuesta

    Lo que muestran aquí la mayoría de las herramientasSin fuga

Hágalo dos veces

VPN desactivada

WebRTC entregó203.0.113.7

Un sitio web ve203.0.113.7

Sin fuga

VPN activada

WebRTC entregó198.51.100.23203.0.113.7

Un sitio web ve198.51.100.23

Sigue ahí con la VPN activada

Fuga
Cada resultado con una ejecución que lo produce. Con la VPN desactivada, la dirección de WebRTC y la del sitio web son la misma; con ella activada, ambas deberían cambiar, y la que se mantiene es la respuesta.

¿Una VPN detiene una fuga de WebRTC?

No por sí sola. Una VPN cambia adónde va su tráfico; WebRTC puede preguntar a su sistema operativo qué interfaces existen, y la física suele seguir ahí.

La propia descripción del IETF es exacta: «si el cliente intenta ocultar su ubicación física mediante una red privada virtual (VPN), y la VPN y el sistema operativo local admiten el enrutamiento por varias interfaces, WebRTC puede descubrir no solo la dirección pública de la VPN, sino también la dirección pública del ISP sobre la que funciona la VPN». Se ofrecen ambas direcciones, y una página que esté atenta puede leer las dos.

Algunos clientes de VPN cierran el hueco enrutando todo el tráfico a nivel del sistema operativo, o incluyendo una extensión de navegador que restringe WebRTC. Ambos métodos funcionan, y ambos hay que comprobarlos en lugar de darlos por hechos, que es para lo que sirve esta página. Una VPN cuya propia página de test de fugas dice que usted está protegido no es una prueba independiente.

Una VPN activada, el Wi-Fi todavía conectadodos interfaces, dos respuestas

Su laptopVPN10.64.0.2Wi-Fi192.168.1.20TÚNEL VPNServidor VPN198.51.100.23Sitio websu navegaciónServidor STUNRouter (NAT)Su proveedor203.0.113.7WebRTC pregunta por ambasSu laptopVPN10.64.0.2Wi-Fi192.168.1.20TÚNEL VPNServidor VPN198.51.100.23Router (NAT)Su proveedor203.0.113.7su navegaciónSitio webServidor STUNWebRTC pregunta por ambas

Lo que recibe la página

  • 198.51.100.23srflxVista por un servidor STUNpor la VPNYa la ven los sitios web
  • 203.0.113.7srflxVista por un servidor STUNpor el Wi-Fi, fuera del túnelNo la ven los sitios web

RFC 8828

Lo que cierra el hueco

  • Enrutamiento a nivel del sistema operativoNada sale fuera del túnel, así que un servidor STUN solo puede ver la dirección de la VPN.
  • La extensión de navegador de la VPNRestringe WebRTC dentro del navegador, así que nunca se pregunta por la otra interfaz.
  • Luego compruebe, no supongaHaga este test con la VPN activada. La propia página de test de fugas de una VPN no es una prueba independiente.
El caso que describe el IETF en RFC 8828: la VPN y el sistema operativo enrutan por más de una interfaz, así que WebRTC encuentra la dirección pública de la VPN y, debajo de ella, la del proveedor.

Host, reflexivo de servidor y relay: ¿qué candidato es cuál?

Un candidato host es una dirección de su propia máquina. Uno reflexivo de servidor es lo que vio un servidor STUN: el lado público de su NAT. Un candidato relay es la dirección de un servidor TURN, no la suya.

La distinción importa, y la mayoría de los tests de fugas la desechan. Un candidato reflexivo de servidor que lleva su IPv4 pública no suele ser noticia: es la misma dirección que el sitio web obtiene de la conexión que usted ya está usando. Un candidato host que lleva una dirección enrutable es otra cosa: es una dirección de la propia máquina, ofrecida directamente a la página. Identifica a esta máquina, no solo al router de su hogar, y cambia cuando cambia la red.

La página muestra el tipo junto a cada dirección, además del transporte, el puerto y la dirección relacionada que nombra un candidato reflexivo. Un candidato relay es la dirección propia del servidor TURN y no revela nada sobre usted; este test no usa ningún servidor TURN, así que si aparece uno, otra cosa en la página lo configuró.

Un candidato, campo por campotal como lo recibe una página

  1. candidate:1467250027Fundamento
  2. 1Componente
  3. udpTransporte
  4. 1686052607Prioridad
  5. 203.0.113.7Dirección
  6. 54400Puerto
  7. typ srflxTipo
  8. raddr 0.0.0.0 rport 9Dirección relacionada
  9. generation 0Extensión

Sustituida por 0.0.0.0, puerto 9, donde se enmascaran las direcciones locales

Los cuatro tipos

  • typ hostEn esta máquina

    Una dirección de una de sus propias interfaces de red.

    Una privada se enmascara. Una enrutable es el propio dispositivo: el hallazgo más grave.

    Lo más grave si es enrutable

  • typ srflxVista por un servidor STUN

    El lado público de su router, tal como lo vio un servidor STUN.

    Suele ser la dirección que un sitio web ya tiene por su conexión.

    Normalmente no es noticia

  • typ prflxVista por el otro extremo

    El lado público de su router, tal como lo vio el otro extremo de una llamada.

    Solo aparece al conectarse con el otro extremo, así que un test sin llamada nunca ve uno.

    Solo durante una llamada

  • typ relayLa dirección propia de un servidor relay

    La dirección de un servidor TURN, que retransmite el tráfico por usted.

    La dirección del servidor, no la suya. Este test no usa ningún servidor TURN, así que si hay uno aquí lo configuró otra cosa.

    Nada sobre usted

La dirección del candidato se compara con lo que ve un sitio web; su tipo dice qué tan grave es una diferencia. Definiciones de RFC 8445, sección 4.

¿Qué es una dirección mDNS .local y me protege?

Los navegadores modernos reemplazan sus direcciones privadas por un nombre aleatorio terminado en .local antes de ofrecerlas a una página. Funciona, para las direcciones privadas. Nunca se pensó para ocultar una pública.

Chrome lo hace de forma predeterminada desde la versión 76 y Firefox tiene media.peerconnection.ice.obfuscate_host_addresses en true: en lugar de 192.168.1.20, una página recibe algo como 8b7f4e2a-….local, que no significa nada para nadie fuera de su red. Safari va más allá: hasta que un sitio tenga permiso de cámara o micrófono, no ofrece ningún candidato host. El test de arriba reconoce esos nombres .local y los presenta como la protección funcionando, no como un hallazgo.

El borrador del IETF que lo define es explícito sobre lo que no hace: «una dirección que ya está expuesta a internet no necesita protegerse con mDNS, ya que el servidor web puede observarla trivialmente». Así que un candidato reflexivo de servidor sigue llevando su IPv4 pública y, lo que sorprende a la gente, una máquina con una dirección IPv6 enrutable todavía puede ofrecer esa dirección como candidato host. Hay un hueco más que conviene conocer: Chrome desactiva la protección en cualquier sitio que ya tenga permiso de cámara o micrófono, así que un sitio de videollamadas que haya usado antes ve sus direcciones locales reales.

Lo que reemplaza el nombre .localy lo que deja como está

Lo que tiene su navegador

candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0

Lo que recibe la página

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0

Lo que hace cada navegador por defecto

  • ChromeVersión 76, agosto de 2019
  • Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
  • SafariNingún candidato host hasta que un sitio tenga permiso de cámara o micrófono

El mecanismo es un borrador del IETF, revisado por última vez en diciembre de 2021 y nunca publicado como RFC. draft-ietf-mmusic-mdns-ice-candidates-03

Una dirección que WebRTC podría ofrecer¿Enmascarada?
192.168.1.20Su IPv4 privada, como candidato hostEnmascaradaReemplazada por un nombre aleatorio: la página no se entera de nada sobre su red.
203.0.113.7Su IPv4 pública, como candidato del servidor STUNVisibleYa es pública, así que se queda. Solo se vacía la dirección relacionada.
2001:db8:4a1f:7c00::1cUna IPv6 enrutable, como candidato hostVisibleTambién es pública, así que el enmascaramiento nunca se pensó para cubrirla.
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07Una dirección IPv6 temporalPuede verseEl borrador permite que un navegador la deje sin enmascarar, por decisión propia.
192.168.1.20Cualquier dirección local, en un sitio con permiso de cámara o micrófonoSin enmascararChrome desactiva ahí el enmascaramiento: el sitio ve sus direcciones locales reales.
El enmascaramiento oculta lo que solo su propia red sabe. Lo que un sitio web podría ver de todos modos lo deja como está: por diseño, no por error.

Por qué IPv6 es la fuga que queda

Una dirección IPv6 global pertenece a una sola máquina y no a un hogar detrás de NAT, y mDNS la deja como está a propósito. Es lo más identificativo que WebRTC sigue entregando.

Con IPv4, el NAT de su router doméstico pone todo detrás de una sola dirección, así que un candidato reflexivo de servidor le dice a una página más o menos lo que ya le dice su conexión habitual. IPv6 no tiene NAT: cada dispositivo tiene su propia dirección enrutable, y un candidato host que la lleva identifica al dispositivo, no a la línea. Si su VPN solo lleva IPv4 (muchas lo hacen), esa dirección IPv6 además queda completamente fuera del túnel.

Las extensiones de privacidad ayudan, porque una dirección IPv6 temporal va rotando. Pero no la ocultan: el borrador de mDNS dice que esas direcciones pueden quedar sin ofuscar. El test de arriba marca un candidato host IPv6 enrutable como lo más grave que puede encontrar, y el Test IPv6 le dirá si su conexión tiene IPv6 o no.

A quién nombra una direcciónlos mismos tres dispositivos, dos veces

RouterIPv4, detrás de NATIPv6, sin NAT
Laptop192.168.1.202001:db8:4a1f:7c00::1c
Teléfono192.168.1.212001:db8:4a1f:7c00::2b
TV192.168.1.222001:db8:4a1f:7c00::3d
Router203.0.113.7Una dirección para toda la líneaUna dirección por dispositivo

Una dirección IPv6 global, en dos mitades

2001:db8:4a1f:7c00Prefijo de red: su línea /64:8d3:5e2f:a41c:9b07Identificador de interfaz: este dispositivo

  • Estable2001:db8:4a1f:7c00::1c
  • Temporal: va rotando2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

Una VPN que solo lleva IPv4

  • IPv4198.51.100.23Dentro del túnel
  • IPv62001:db8:4a1f:7c00::1cFuera del túnel
Detrás de un NAT IPv4, un hogar comparte una sola dirección; en IPv6 cada dispositivo tiene la suya, y un candidato host la ofrece directamente. El test trata un candidato host IPv6 enrutable como el hallazgo más grave.

Cómo detener una fuga de WebRTC en cada navegador

Firefox tiene preferencias que funcionan. Edge tiene una política empresarial. Safari ya restringe los candidatos. Las extensiones de navegador que todavía se recomiendan ya no hacen nada.

En Firefox, about:config → media.peerconnection.ice.default_address_only envía una sola dirección en lugar de todas, y media.peerconnection.ice.relay_only limita la recolección a candidatos relay, lo que rompe las llamadas directas pero oculta todo lo demás. Ambas están desactivadas de forma predeterminada; el enmascaramiento mDNS de las direcciones privadas (media.peerconnection.ice.obfuscate_host_addresses) ya está activado. En Edge, la política WebRtcLocalIpsAllowedUrls controla qué sitios pueden ver las direcciones locales; la propia documentación de Microsoft advierte que agregar un sitio «debilita la protección». Chrome no tiene un ajuste equivalente para un usuario común. Safari es el más estricto sin que se lo pida: sin permiso de cámara o micrófono, WebKit solo ofrece candidatos reflexivos de servidor y relay, y ningún candidato host.

Dos cosas que todavía se recomiendan mucho ya no sirven. La opción «Prevent WebRTC from leaking local IP addresses» de uBlock Origin se eliminó en la versión 1.38, con la nota de que «ya no es necesaria en los navegadores modernos, salvo en Firefox para Android». Y la extensión WebRTC Network Limiter de Google, que sigue publicada en la tienda, no puede ejecutarse: las extensiones Manifest V2 están desactivadas para todos los usuarios de Chrome desde Chrome 138, en julio de 2025. Si una página le dice que instale cualquiera de las dos, esa página lleva años sin actualizarse.

Lo que ofrece cada navegadorcomprobado con la documentación de cada fabricante

  • FirefoxPreferencias que funcionan

    about:config

    • media.peerconnection.ice.obfuscate_host_addressesPredeterminado trueEnmascara las direcciones privadas. Ya está activado.
    • media.peerconnection.ice.default_address_onlyPredeterminado falseCámbielo a trueEnvía una sola dirección en lugar de todas.
    • media.peerconnection.ice.relay_onlyPredeterminado falseCámbielo a trueSolo candidatos relay. Es lo que más oculta, y rompe las llamadas directas.

  • EdgePolítica empresarial

    WebRtcLocalIpsAllowedUrls

    Enumera los sitios que pueden ver las direcciones locales.

    Sin configurar: las direcciones locales siguen enmascaradas.

    La propia nota de Microsoft: agregar un sitio debilita la protección.

    Windows y macOS, versión 80 y posteriores

  • ChromeSin ajuste

    Sin ajuste para un usuario común.

    Direcciones privadas enmascaradas por defecto desde la versión 76.

    No en un sitio con permiso de cámara o micrófono.

  • SafariEstricto por defecto

    Sin permiso de cámara o micrófono, solo candidatos de servidor STUN y relay.

    Ningún candidato host.

Consejos que ya no funcionan

  • Prevent WebRTC from leaking local IP addresses

    uBlock Origin

    Eliminada en la versión 1.38

    Ya no es necesaria en los navegadores modernos, según uBlock Origin, salvo en Firefox para Android.

  • WebRTC Network Limiter

    Google · Chrome Web Store

    Sigue publicada, no puede ejecutarse

    Las extensiones Manifest V2 están desactivadas para todos los usuarios de Chrome desde Chrome 138, julio de 2025.

La documentación de cada fabricante, leída el día en que se revisó esta página. Una página que todavía le dice que instale cualquiera de las dos últimas lleva años sin actualizarse.

Fuga de WebRTC, fuga de DNS y fuga de IP: ¿cuál es la diferencia?

Son tres formas distintas de saltarse una VPN. Una fuga de WebRTC muestra una dirección; una fuga de DNS muestra quién responde sus consultas; una fuga de IP es el caso simple en que su tráfico nunca entró en el túnel.

Una fuga de WebRTC tiene que ver con direcciones que su navegador ofrece por su cuenta a través de una función diseñada para ofrecerlas. Una fuga de DNS tiene que ver con qué resolutor responde sus consultas: su tráfico puede ir por la VPN mientras sus consultas siguen yendo al resolutor de su proveedor, lo que le dice a ese proveedor cada sitio que visita. Nuestro Test de fugas DNS lo comprueba con nuestro propio servidor de nombres, así que puede ver exactamente qué resolutores preguntaron.

Una fuga de IP, en sentido general, es la dirección que un sitio web simplemente ve, y puede comprobarla en Cuál es mi IP o Cuál es mi ISP. Haga los tres tests juntos después de cualquier cambio en la VPN: fallan de forma independiente, y un resultado limpio en uno no dice nada sobre los demás.

Tres formas de saltarse una VPNcada una falla por su cuenta

UstedTÚNEL VPNPor el túnelFuga de IP · su tráficoEl sitio web203.0.113.7Fuga de DNS · sus consultasEl resolutor de su proveedor203.0.113.53Fuga de WebRTC · sus direccionesEl script de la página203.0.113.7UstedTÚNEL VPNPor el túnelFuga de IPsu tráficoEl sitio web203.0.113.7Fuga de DNSsus consultasEl resolutor de su proveedor203.0.113.53Fuga de WebRTCsus direccionesEl script de la página203.0.113.7

  • Fuga de IP

    Qué se filtraLa dirección que lleva cada solicitud

    Quién se enteraCada sitio que visita

    Compruébelo conCuál Es Mi IPCuál Es Mi ISP

  • Fuga de DNS

    Qué se filtraQué resolutor responde sus consultas

    Quién se enteraSu proveedor, para cada sitio que consulta

    Compruébelo conTest de Fugas DNS

  • Fuga de WebRTC

    Qué se filtraDirecciones que su navegador ofrece a una página

    Quién se enteraCualquier página que pregunte, sin aviso

    Compruébelo conTest de Fuga WebRTC

Fallan de forma independiente: un resultado limpio en una no dice nada sobre las otras dos. Haga los tres tests después de cualquier cambio en su VPN.

Por qué este test pregunta a más de un servidor STUN

Porque «no volvió ninguna dirección» y «no existe ninguna dirección» se ven idénticos, y solo uno de los dos es una buena noticia.

Un firewall corporativo, una VPN restrictiva o una red que bloquea UDP pueden impedir que un servidor STUN responda. Un test que pregunta a un solo proveedor y no ve nada no ha aprendido nada; aun así, la respuesta habitual es mostrar una marca verde. Este pregunta al punto de acceso STUN documentado de Cloudflare y al de Google, informa de cada uno por separado y dice que no se pudo probar cuando ninguno respondió.

La elección de servidores es deliberada. Cloudflare publica stun.cloudflare.com:3478 como parte de un producto, así que hay condiciones que leer. El stun.l.google.com:19302 de Google solo está documentado como el valor predeterminado del validador WebRTC del propio Google, sin condiciones publicadas, así que se usa como segunda opinión y no como única fuente. El de Twilio requiere credenciales, y Mozilla no documenta ningún servidor STUN público, por mucho que se cite uno.

Servidores STUN públicosy a cuáles pregunta este test

  • CloudflareConsultado

    stun.cloudflare.com:3478

    Un punto de acceso documentado, parte de un producto, con condiciones que leer.

  • GoogleConsultado, como segunda opinión

    stun.l.google.com:19302

    Documentado solo como el valor predeterminado del validador WebRTC del propio Google. Sin condiciones publicadas.

  • TwilioNo consultado

    global.stun.twilio.com:3478

    Requiere credenciales de la API de Twilio: no está abierto a cualquier página.

  • MozillaNo consultado

    Ningún servidor público

    No documenta ningún servidor STUN público. Firefox no trae ningún servidor ICE predeterminado.

Cuando un servidor no dice nada

CloudflareGoogle
RespondióRespondióEl resultado se mantiene
RespondióEn silencioEl resultado se mantiene; se nombra el servidor en silencio
En silencioRespondióEl resultado se mantiene; se nombra el servidor en silencio
En silencioEn silencioNo se pudo probar
Dos operadores, consultados por separado. Un servidor en silencio se nombra y el resultado se mantiene; cuando ninguno responde, no se midió nada, y el test lo dice en lugar de mostrar un aprobado.

¿Mi dirección IP es un dato personal?

En la UE, una dirección IP dinámica es un dato personal para el operador de un sitio web que podría identificarlo a usted con información que tiene el proveedor. El Tribunal de Justicia lo decidió en 2016.

El caso es Breyer, C-582/14, con sentencia del 19 de octubre de 2016, y el comunicado de prensa del Tribunal lo resume así: «la dirección de protocolo de Internet dinámica de un usuario constituye, para el gestor del sitio, un dato personal cuando dicho gestor dispone de medios legales que le permitan identificar al usuario de que se trate gracias a la información suplementaria de que dispone el proveedor de acceso a Internet del usuario». El mismo comunicado de prensa señala que un sitio puede tener un interés legítimo en conservar parte de esos datos para defenderse de ataques.

Esa es precisamente la razón por la que esta página hace su trabajo en su navegador. Los candidatos ICE los reúne su navegador, se comparan en su navegador y se le muestran a usted; ninguna dirección que encuentre WebRTC se nos envía, así que no hay nada de ella que podamos guardar, entregar o perder. Puede observar el panel de red mientras se ejecuta el test.

La sentencia BreyerTribunal de Justicia de la Unión Europea

C-582/14Breyer v Bundesrepublik Deutschland19 de octubre de 2016

  1. El operador del sitio webuna dirección y una hora, de sus registros203.0.113.7 · 14:02:37
  2. los medios legales para obtenerlo
  3. El proveedor de acceso a internetquién usaba esa dirección a esa hora203.0.113.7 · 14:02:37 →
  4. Dato personal, para ese operador

El comunicado de prensa del Tribunal: un sitio puede tener un interés legítimo en conservar parte de esos datos para defenderse de ataques.

En esta página

Su navegador

  1. Reúne
  2. Clasifica
  3. Compara
  4. Muestra
  • Ven su dirección pública, como en cualquier llamada
  • dnsrobot.netNo se envía ningún candidato
Caso C-582/14, Breyer. Una dirección IP dinámica es un dato personal para el operador de un sitio web que dispone de medios legales para identificarlo a usted con los registros del proveedor. Esta página mantiene los candidatos en su navegador.

Test de fuga de WebRTC: preguntas y respuestas

¿Qué es una fuga de WebRTC?

WebRTC es la función del navegador detrás de las videollamadas. Para conectar a dos personas directamente, reúne cada dirección por la que se puede llegar a su máquina y se las ofrece a la página, sin ningún aviso de permiso. Se convierte en una fuga cuando una de esas direcciones es una que usted estaba ocultando: normalmente su dirección real mientras usa una VPN, porque WebRTC puede preguntar por todas las interfaces de red y no solo por la que usa su navegación.

¿Cómo compruebo si hay una fuga de WebRTC?

Inicie el test de esta página. Pregunta a tres servidores STUN de dos operadores, enumera cada dirección que produjo WebRTC con el tipo de dirección que es cada una, y compara las enrutables con la dirección que un sitio web ya ve. Si usa una VPN, hágalo una vez con la VPN desactivada y otra con ella activada: la diferencia entre las dos ejecuciones es la respuesta.

¿Una VPN detiene una fuga de WebRTC?

No por sí sola. Una VPN cambia adónde va su tráfico, pero WebRTC puede preguntar al sistema operativo qué interfaces existen, y la conexión física suele seguir siendo una de ellas. El propio texto del IETF dice que WebRTC puede descubrir «no solo la dirección pública de la VPN, sino también la dirección pública del ISP sobre la que funciona la VPN». Algunos clientes de VPN cierran el hueco; este test le dice si el suyo lo hizo.

¿Qué significa una dirección .local en los resultados?

Es mDNS, y es una buena noticia. Los navegadores modernos reemplazan sus direcciones privadas por un nombre aleatorio terminado en .local antes de ofrecerlas a una página, así que, con esos nombres, un sitio no se entera de nada sobre su red doméstica. Chrome lo hace desde la versión 76 y Firefox hace lo mismo; Safari va más allá y no ofrece ningún candidato host hasta que un sitio tenga permiso de cámara o micrófono. El test marca esos nombres como la protección funcionando y no como un hallazgo.

Si mDNS oculta mi IP local, ¿estoy a salvo?

En parte. mDNS se diseñó para ocultar direcciones privadas y, de forma explícita, no para ocultar una que ya es pública: lo dice el borrador del IETF que lo define. Su IPv4 pública sigue apareciendo como candidato reflexivo de servidor, y una máquina con una dirección IPv6 enrutable todavía puede ofrecer esa dirección directamente. Chrome además desactiva la protección en cualquier sitio que ya tenga permiso de cámara o micrófono.

¿Por qué el test a veces dice que no se pudo probar?

Porque es la verdad. Si WebRTC está desactivado, bloqueado por una extensión o una política, o ningún servidor STUN respondió (un firewall, una VPN restrictiva, una red que bloquea UDP), entonces no se midió nada. La mayoría de las herramientas muestran una marca verde en esa situación, que es lo más engañoso que puede hacer un test de fugas. Este dice qué pasó y nombra los servidores que no respondieron.

¿Cómo desactivo WebRTC en Firefox?

Las preferencias documentadas de Firefox restringen WebRTC en lugar de desactivarlo. En about:config, media.peerconnection.ice.default_address_only envía una sola dirección en lugar de todas, y media.peerconnection.ice.relay_only limita la recolección a candidatos relay: es lo que más oculta, pero rompe las llamadas directas. El enmascaramiento de las direcciones privadas, media.peerconnection.ice.obfuscate_host_addresses, ya está activado de forma predeterminada. Repita el test después de cada cambio para ver qué ganó con él.

¿Cómo evito las fugas de WebRTC en Chrome?

Chrome no ofrece a un usuario común ningún ajuste para ello; el enmascaramiento mDNS de las direcciones privadas está activado de forma predeterminada y esa es la protección que tiene. Edge, que comparte el motor de Chrome, tiene la política empresarial WebRtcLocalIpsAllowedUrls. Las extensiones que todavía se recomiendan mucho no funcionan: uBlock Origin eliminó su opción de WebRTC en la versión 1.38, y WebRTC Network Limiter de Google no puede ejecutarse desde que Manifest V2 se desactivó en Chrome 138.

¿Qué diferencia hay entre un candidato host y uno reflexivo de servidor?

Un candidato host es una dirección de su propia máquina. Un candidato reflexivo de servidor es lo que vio un servidor STUN: el lado público de su NAT, que suele ser la dirección que el sitio web ya tiene por su conexión. Un candidato host enrutable es el hallazgo más grave, porque es una dirección del propio dispositivo, y en IPv6 identifica al dispositivo y no al hogar.

¿Una fuga de WebRTC es lo mismo que una fuga de DNS?

No. Una fuga de WebRTC revela una dirección; una fuga de DNS revela qué resolutor responde sus consultas, lo que le dice a su proveedor cada sitio que visita aunque el tráfico en sí vaya por la VPN. Fallan de forma independiente, así que un resultado limpio en una no dice nada sobre la otra. Haga también nuestro Test de fugas DNS después de cualquier cambio en la VPN.

¿Este test envía mi dirección IP a alguna parte?

Solo adonde la vería cualquier sitio web. Su navegador contacta con los servidores STUN, como en cualquier videollamada: en eso consiste el test. Para saber qué ve un sitio web, la página pregunta a ipify.org y a nuestro propio servidor por sus direcciones y sus redes, igual que el Test de fugas DNS. Las direcciones que encuentra WebRTC se quedan en su navegador: ninguna se nos envía. Observe su panel de red mientras se ejecuta el test.

¿Mi dirección IP es un dato personal según el derecho de la UE?

Para el operador de un sitio web en la UE, una dirección IP dinámica es un dato personal cuando ese operador dispone de medios legales para identificarlo a usted con información que tiene el proveedor de internet. Esa es la decisión del Tribunal de Justicia en el caso Breyer, C-582/14, de octubre de 2016. Es una de las razones por las que esta página mantiene en su navegador la parte WebRTC del test, y no en un servidor nuestro.

¿Le falta algo?Sugiera una función o una herramienta nueva

Herramientas relacionadas