Tema

Herramientas populares

DNS Leak Test

Vea qué servidores DNS responden de verdad a sus consultas y si su VPN las filtra a su proveedor de internet. Este test DNS se inicia al abrir la página, nombra cada servidor y da un veredicto claro.

Visto por nuestro propio servidor de nombres de prueba · servidores DNS mostrados por su dirección IPv4 · lo visto se guarda 10 minutos en memoria y luego se olvida

¿Qué quiere comprobar?
Haga el test una vez con la VPN desactivada y otra con la VPN activada: le mostraremos qué servidores DNS desaparecieron.

Empieza solo al abrir la página · 6 consultas que nadie ha hecho antes · unos 4 s · se olvida a los 10 minutos

UstedIPv4IPv6Buscando su conexión…
Servidores DNS que preguntaron a nuestro servidor de nombres

  1. Los servidores DNS que preguntan a nuestro servidor de nombres aparecen aquí, uno por fila, a medida que llegan.

Comprobar desde la línea de comandos

1El DNS de su sistema

El servidor DNS que usan sus apps. Compárelo con las filas de arriba.

C:\> nslookup -type=txt whoami.leak.dnsrobot.net
  • La respuesta es la dirección del servidor DNS que nos preguntó.
  • Una respuesta distinta significa que su navegador y sus apps toman caminos diferentes, por ejemplo el DNS seguro del navegador.
  • ¿Tiene su propio resolutor (Pi-hole con Unbound)? La respuesta es la dirección de su casa: no la publique.

2La prueba de secuestro

Pregunta directamente a Cloudflare (1.1.1.1).

C:\> nslookup -type=txt whoami.leak.dnsrobot.net 1.1.1.1
  • Una dirección de Cloudflare (AS13335): su consulta llegó a Cloudflare como se pidió.
  • La dirección de cualquier otra red: un fuerte indicio de que algo redirige su DNS: su app de VPN (algunas lo hacen a propósito), un software de seguridad, su router o su proveedor.
¿Qué comando?

El texto se queda en esta página; solo la dirección se consulta en nuestro servidor para nombrar su red.

Nuestro servidor de nombres guarda lo que vio en cada test durante 10 minutos en memoria y luego lo olvida. Su último resultado se queda solo en este navegador, para el antes y después.

¿Qué significa el resultado de mi test de fugas DNS?

Depende de dos cosas: qué servidores DNS preguntaron a nuestro servidor de nombres y si usa una VPN. El DNS de su proveedor de internet es normal sin VPN y una fuga con ella; un DNS público como Cloudflare o Google nunca es una fuga por sí mismo.

Una fuga de DNS (DNS leak) significa que los servidores DNS de su proveedor respondieron mientras usaba una VPN, así que su proveedor ve los sitios que consulta pese al túnel. Los socios o empresas de hosting que operan el DNS de su VPN no son una fuga: Proton VPN traza la misma línea.

El test clasifica cada servidor por tipo (DNS de su VPN, DNS público, DNS de su ISP, red de hosting o su propio resolutor) y escribe el veredicto a partir de la mezcla, con la marca nombrada. El DNS de su VPN más el de su proveedor es una fuga parcial: algunas consultas escapan de vez en cuando.

No llegó nada nunca es luz verde: algo detuvo las consultas del test antes de que llegaran a internet. Y un servidor DNS en otro país tampoco es una fuga.

Qué preguntó a nuestro servidor de nombres × ¿usa una VPN?los seis veredictos

Servidores DNS vistosSin VPNCon VPN
DNS de su VPNNo es posibleSin VPN no hay DNS de VPN que ver.Sin fugasM247 en Fráncfort responde: su proveedor no ve nada.
DNS públicoCloudflare respondeSu configuración de 1.1.1.1 funciona. No es una fuga.Sin fugasSus consultas llegan desde la dirección de la VPN, no desde la suya.
DNS de su ISPDNS de su ISPExample Broadband responde, como debe ser sin VPN. No es una fuga.Fuga de DNSSu proveedor ve cada nombre que consulta, pese a la VPN.
Una mezcla: VPN o público + ISPNo es una fugaUn segundo ajuste de DNS o un respaldo: normal sin VPN.Fuga parcialAlgunas consultas escapan del túnel: haga el test extendido.
Una red de hostingProbablemente Quad9O el socio de otro servicio, o el servidor al que reenvía su router: la página lo dice cuando no puede distinguirlo.Sin fugasNo es la red de su proveedor: probablemente el socio de DNS de su VPN.
No llegó nadaSin luz verdeNunca «seguro»: algo detuvo las consultas del test.Sin luz verdePermita los nombres del test, o haga el test extendido.
Las filas son los tipos de servidor DNS que nombra el test, con sus colores de los resultados; las celdas son los veredictos que escribe la página. La regla con una VPN: todo lo que no sea la red de su proveedor no es una fuga.
DNS Leak Test: las consultas de un usuario de VPN respondidas por el DNS de su proveedor de internet, cada servidor nombradoDNS Leak Test: las consultas de un usuario de VPN respondidas por el DNS de su proveedor de internet, cada servidor nombradoEl veredictoUna frase que dice quién responde sus consultas y si eso es una fuga, con el siguiente paso.Un servidor DNSCada servidor que preguntó a nuestro servidor de nombres: su marca o su red, dirección IPv4, ubicación, tipo y cuota de las peticiones.También comprobadoPor dónde sale su dirección IPv6, más una nota cuando iCloud Private Relay o Tor lleva su tráfico.Su ruta DNSSu dispositivo, el túnel VPN y los servidores DNS que preguntaron, con una fuga dibujada como una consulta fuera del túnel.
Un resultado inventado con VPN: el DNS de Example Broadband sigue respondiendo fuera del túnel, así que el test informa una fuga. Seleccione un número para ver qué muestra cada parte.

¿Cómo funciona un test de fugas DNS?

Este comprobador de fugas DNS hace que su navegador consulte nombres que nunca existieron, como 1-k3x9q2mfp7c1vn4a.leak.dnsrobot.net. Ningún servidor DNS los tiene en caché, así que el servidor que atiende sus consultas debe preguntar a nuestro servidor de nombres, que anota su dirección y responde «ese nombre no existe».

Luego la página pregunta a nuestro servidor de nombres qué servidores DNS vinieron a pedir los nombres de este test. Esos son los servidores que su navegador usa de verdad, digan lo que digan sus ajustes; un router doméstico normalmente solo reenvía las consultas, así que aparece el servidor al que las reenvía. Cada nombre se usa una sola vez, y nuestro servidor de nombres olvida el test a los 10 minutos.

El test estándar hace 6 consultas, normalmente suficientes para detectar una fuga. El test extendido hace 36, en tandas de 6, para detectar un servidor DNS que solo responde de vez en cuando, como Windows probando cada adaptador cuando el DNS de la VPN tarda en responder.

Si un servidor DNS pasa parte de su dirección (EDNS Client Subnet), su fila le muestra esa subred solo a usted. Nunca se registra.

Una consulta, paso a pasoun test real, direcciones reemplazadas

Su navegadorSu servidor DNSNuestro servidor de nombres1-k3x9q2….leak.dnsrobot.net ?¿quién tiene 1-k3x9q2…?preguntado por203.0.113.53NXDOMAIN · ese nombre no existela imagen falla: consulta hecha¿qué servidores pidieron k3x9q2…?→ 203.0.113.53 ×4 · 203.0.113.54 ×2Su navegadorSu servidor DNSNuestro servidor de nombres1-k3x9q2….leak.dnsrobot.net ?¿quién tiene 1-k3x9q2…?preguntado por203.0.113.53NXDOMAIN · ese nombre no existela imagen falla: consulta hecha¿qué servidores pidieron k3x9q2…?→ 203.0.113.53 ×4203.0.113.54 ×2
Arriba: una de las seis consultas desde una conexión doméstica, paso a paso. Cada nombre se usa una sola vez, y nuestro servidor de nombres guarda quién preguntó durante 10 minutos, en memoria. Abajo: los dos tamaños de test, una celda por consulta; cada tanda de 6 espera como máximo 3 segundos. Los colores ilustran una VPN que envía 2 de 36 consultas al DNS del proveedor, algo que un test de 6 consultas puede pasar por alto fácilmente. El test en sí muestra la cuota de peticiones de cada servidor DNS.

¿Por qué aparecen Google, Cloudflare u otro país?

Porque la dirección que usted configura no es la dirección que pregunta. Los servicios de DNS público responden en 1.1.1.1 u 8.8.8.8 desde muchos sitios a la vez (anycast), y cada sitio pregunta a otros servidores de nombres desde su propio grupo de direcciones, a veces en la red de un socio.

Desde una conexión que probamos, solo Cloudflare, Google y OpenDNS llegaron a nuestro servidor de nombres desde sus propias redes; Quad9 llegó a través de Equinix, AdGuard a través de Datacamp y NextDNS a través de Vultr. Nada de eso es una fuga. Un DNS público en su resultado significa que su navegador, su dispositivo o su VPN envía allí las consultas, y desde una VPN llegan con la dirección de la VPN, no con la suya.

Por eso el test no se fía de una tabla: pregunta a cada servicio de DNS público, desde su navegador, qué dirección usa para usted, y comprueba Google con los rangos que Google publica. Un servidor que no puede confirmar aparece como probable de ese servicio, o como un servidor en una red de hosting, nunca como una fuga.

Los países también engañan: los datos de registro dan el país donde está registrada una red, no donde está el servidor (el propio 1.1.1.1 está registrado en Australia). Una fuga tiene que ver con quién ve sus consultas, no con dónde están.

Lo que configuró · quién nos preguntó · su redun test grabado, direcciones reemplazadas

Grabado en una línea de fibra en India, 24 oct 2026

  • Cloudflare1.1.1.1192.0.2.10su propia red, AS13335país de registro: Estados UnidosNo es una fuga
  • Google8.8.8.8192.0.2.12, 192.0.2.13su propia red, AS15169país de registro: Estados Unidosdos direcciones para dos consultasNo es una fuga
  • Quad99.9.9.9192.0.2.11vía Equinix, AS15830país de registro: Países Bajosla red de un socioNo es una fuga
  • AdGuard94.140.14.14192.0.2.30vía Datacamp (CDN77), AS60068un socio de hosting (también lleva DNS4EU)No es una fuga
  • NextDNSsu configuración192.0.2.41vía Vultr, AS20473un socio de hosting (también lleva CleanBrowsing)No es una fuga
De los 12 servicios de DNS público consultados desde esta conexión, solo Cloudflare, Google y OpenDNS llegaron a nuestro servidor de nombres desde sus propias redes; el resto llegó a través de socios o proveedores de hosting. La bandera indica dónde está registrada una red, no dónde está el servidor. La página pregunta en vivo a cada servicio qué dirección usa para usted, en lugar de fiarse de una tabla como esta.

¿Qué causa una fuga de DNS?

Normalmente, su dispositivo envía consultas a un sitio distinto de la VPN: la app de VPN no fija su propio DNS, Windows pregunta a todos los adaptadores de red, o IPv6 rodea un túnel que solo lleva IPv4.

Windows puede enviar cada consulta por el Wi-Fi y por la VPN a la vez para responder más rápido (smart multi-homed name resolution). Muchas VPN solo llevan IPv4 y dejan el tráfico IPv6, y el DNS enviado por él, fuera del túnel (RFC 7359). Un DNS personalizado configurado en el sistema también puede anular la protección de la app de VPN.

Cada causa deja su propio patrón en el resultado. Un proveedor de DNS seguro personalizado en el navegador aparece como ese DNS público, saltándose el de la VPN. Eso sí, el modo automático de Chrome mantiene su proveedor actual, y la opción predeterminada de Firefox se hace a un lado ante una VPN.

Algo que redirige el DNS en el puerto 53, como un proxy transparente del proveedor, muestra a su proveedor aunque usted haya configurado 1.1.1.1. Una VPN que se cae sin kill switch solo filtra un momento, así que un test puede no verlo: repita el test cuando la VPN se reconecte.

Seis causas y lo que este test muestra en cada unala última línea de la tarjeta

  • La VPN no fija su propio DNS

    El tráfico va por el túnel, pero el sistema conserva los servidores DNS que tenía antes, normalmente los de su proveedor.

    Fuga de DNSDNS de su ISP con VPN

  • Un DNS seguro personalizado en el navegador

    Con un proveedor personalizado, el navegador le envía las consultas por HTTPS, saltándose el DNS de la VPN. El modo automático de Chrome mantiene su proveedor actual, y la opción predeterminada de Firefox se hace a un lado cuando detecta una VPN.

    Sin fugasun DNS público, no el de su VPN

  • Windows pregunta a todos los adaptadores

    Con «smart multi-homed name resolution», Windows envía las consultas por todas las redes a la vez: la VPN y el Wi-Fi por igual.

    Fuga parcialDNS de su VPN + DNS de su ISP

  • IPv6 rodea el túnel

    Muchas VPN solo llevan IPv4. El tráfico IPv6, y cualquier DNS enviado por él, sale por su proveedor.

    Fuga de IPv6su propia línea bajo el resultado

  • Algo redirige el DNS

    Un router, un software de seguridad o el proveedor (o una app de VPN, a propósito) intercepta las consultas en el puerto 53 y las responde, incluso las destinadas a 1.1.1.1.

    DNS de su ISP«No es Cloudflare 1.1.1.1: respondió su ISP»

  • La VPN se cae, sin kill switch

    Si el túnel se interrumpe, las consultas pueden ir al DNS predeterminado del sistema, probablemente el de su proveedor, hasta que vuelva.

    Fuga parcialsolo de vez en cuando: el test extendido lo detecta más a menudo

Teredo, la antigua forma de Windows de tunelizar IPv6 sobre IPv4, está desactivado desde Windows 10 versión 1803, así que hoy rara vez es la causa.

¿Cómo soluciono una fuga de DNS?

Active en su app de VPN DNS leak protection, IPv6 leak protection y el kill switch (los nombres varían según la app) y repita el test. La protección contra fugas mantiene el DNS dentro de la VPN con reglas de firewall; el kill switch cubre los momentos en que el túnel se cae.

Si la fuga sigue, corrija el sistema. En Windows, block-outside-dns en un perfil de OpenVPN mantiene las consultas lejos de cualquier otro adaptador, y un túnel de WireGuard que lo enruta todo (0.0.0.0/0) con una línea DNS = hace que el puerto 53 solo llegue al DNS del túnel. Desactivar «smart multi-homed name resolution» solo detiene las consultas en paralelo; no es la solución.

En Linux con systemd-resolved, asigne al enlace de la VPN el dominio de enrutamiento ~. para que no se pregunte a ningún otro enlace. Deje que la app de VPN lleve o bloquee IPv6 en lugar de desactivar IPv6, algo que Microsoft desaconseja. Quite del navegador cualquier proveedor de DNS seguro personalizado, y del sistema cualquier DNS personalizado, mientras usa la VPN.

En Android, ponga «DNS privado» en No mientras usa la VPN, como recomiendan Proton VPN y Mullvad: un nombre de host de DNS privado envía cada consulta a ese proveedor. Luego repita el test: el antes y después muestra qué servidores DNS desaparecieron.

Los ajustes que importanpor sistema

App de VPN · Configuración

DNS leak protectionmantiene cada consulta dentro del túnel
IPv6 leak protectionbloquea IPv6 o lo lleva por el túnel
Kill Switchsin tráfico mientras el túnel está caído
Custom DNSdéjelo desactivado: en algunas apps desactiva la protección contra fugas

Perfil de OpenVPN (.ovpn)

block-outside-dns
# solo Windows: el puerto 53 no llega a ningún otro adaptador

WireGuard (.conf)

[Interface]
DNS = 10.2.0.1
# sin esta línea, el sistema conserva su DNS anterior
[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
# WireGuard para Windows: con una ruta /0, el puerto 53 solo llega al DNS de arriba

Windows 11 · Settings

SettingsNetwork & internetWi-FiManage known networks

DNS server assignmentcon una VPN, un DNS que usted escribió puede anular su protección contra fugasAutomatic (DHCP)

Deje IPv6 activado: Microsoft desaconseja desactivarlo. Use la protección contra fugas de IPv6 de la app de VPN.

Group Policy

Computer Configuration › Network › DNS Client
Turn off smart multi-homed name resolution = Enabled
# solo detiene las consultas en paralelo: no es la solución

valor del Registro

DisableSmartNameResolution

Compruebe el DNS del sistema

C:\> nslookup -type=txt whoami.leak.dnsrobot.net

macOS · System Settings

Apple menuSystem SettingsNetworkWi-FiDetailsDNS

DNS Serversquite los servidores que agregó a mano mientras usa una VPN

Un perfil o una app de DNS cifrado que usted activó se aplica a todo el sistema, y una app de VPN no puede redirigirlo.

Con una VPN activada, iCloud Private Relay se hace a un lado.

Compruebe el DNS del sistema

$ dns-sd -q whoami.leak.dnsrobot.net TXT
# se ejecuta hasta que presione Ctrl-C
$ dig +short TXT whoami.leak.dnsrobot.net
# dig solo pregunta al resolutor principal, el de /etc/resolv.conf

Linux

systemd-resolvedUna consulta que no coincide con ningún dominio de enrutamiento va a cada enlace con ruta predeterminada: la VPN y el Wi-Fi por igual.la solución: asigne al enlace de la VPN el dominio de enrutamiento ~.
NetworkManagerUna prioridad de DNS negativa en el perfil de la VPN deja fuera los servidores DNS de las demás conexiones.
/etc/resolv.confSin systemd-resolved: elimine de /etc/resolv.conf las líneas nameserver que queden tras conectarse.
# enviar cada consulta al enlace de la VPN
$ resolvectl domain wg0 '~.'
# NetworkManager: solo el DNS del perfil de la VPN
$ nmcli connection modify my-vpn ipv4.dns-priority -10

Compruebe el DNS del sistema

$ resolvectl query --type=TXT whoami.leak.dnsrobot.net

Android · Settings

SettingsNetwork & internetPrivate DNS

Samsung: SettingsConnectionsMore connection settingsPrivate DNS

  • Off
  • Automatic
  • Private DNS provider hostname
  • Los fabricantes de VPN recomiendan elegir «No» mientras usa la VPN.
  • Un nombre de host envía cada consulta a ese proveedor, saltándose el DNS de la VPN.

iPhone · Settings

SettingsWi-FiⓘConfigure DNS

  • Automatic
  • Manual

Un DNS que usted escribe solo se aplica a esa red Wi-Fi, y puede anular el de la VPN.

  • Un perfil o una app de DNS cifrado que usted activó se aplica a todo el sistema, y una app de VPN no puede redirigirlo.
  • Con una VPN activada, iCloud Private Relay se hace a un lado.

Chrome · Settings

SettingsPrivacy and securitySecurityAdvanced

Use secure DNS
  • your current service provider
  • a custom service provider

Edge: las mismas opciones, enSettingsPrivacy, search, and services

  • El modo automático solo pasa su proveedor actual a DNS cifrado.
  • Un proveedor personalizado envía las consultas saltándose la VPN, donde la app de VPN no puede redirigirlas.
  • Los fabricantes de VPN van más allá y recomiendan desactivarlo.

Firefox · Settings

DNS over HTTPS

  • Default Protection
  • Increased Protection
  • Max Protection
  • Off
  • «Default Protection» desactiva DNS over HTTPS cuando detecta una VPN.
  • «Increased» y «Max» mantienen el proveedor que usted eligió, saltándose el DNS de la VPN.
  • Activado de forma predeterminada solo en: Estados Unidos, Canadá, Rusia y Ucrania.
Los nombres de los ajustes varían según la app: estos son rótulos genéricos. Los nombres de los menús son los rótulos en inglés de cada fabricante. 10.2.0.1 es el DNS de Proton VPN dentro del túnel, como ejemplo; la opción de OpenVPN solo funciona en Windows.

¿Funciona su DNS personalizado? Compruebe 1.1.1.1, NextDNS, AdGuard o Pi-hole

Elija lo que configuró en ¿Qué quiere comprobar? y haga el test: el veredicto dice si ese servicio de verdad responde. Una configuración que funciona solo muestra ese servicio, a menudo desde la red de un socio o de un proveedor de hosting en lugar de la suya, como muestra la tabla. Cuando funcione, el Test de velocidad de DNS lo cronometra frente a otros resolutores desde su conexión.

Un Pi-hole reenvía las consultas a su DNS upstream, así que el test muestra ese servidor (Cloudflare, por ejemplo), no el Pi-hole. Con Unbound resuelve los nombres por sí mismo, así que aparece la dirección de su casa: normal sin VPN. Cloudflare y NextDNS también confirman sus propios servicios, en la página de comprobación de Cloudflare y en test.nextdns.io.

Si en cambio aparece su proveedor, un router, una app o el navegador está anulando su elección, o algo redirige el puerto 53; algunos routers incluso enrutan mal el propio 1.1.1.1. La comprobación por línea de comandos le ayuda a saber cuál.

Lo que debería mostrar cada servicioel ejemplo de una conexión

ServicioUsted configuraEste test debería mostrarSuele llegar desde
Cloudflare1.1.1.1DNS público Cloudflaresu propia red · AS13335
Google Public DNS8.8.8.8DNS público Googlesus propios rangos publicados · AS15169 +3 más
Quad99.9.9.9DNS público Quad9un socio, como Equinix · AS15830
NextDNSsu ID de configuraciónHosting NextDNS probableun proveedor de hosting, como Vultr · AS20473
AdGuard DNS94.140.14.14Hosting AdGuard probableun proveedor de hosting, como Datacamp (CDN77) · AS60068
Control D76.76.2.0DNS público Control Dun proveedor de hosting regional · AS146943
Pi-holela dirección de su Pi-holeDNS público el servidor al que reenvía su Pi-hole, o Propio con Unboundla red de ese servidor, o su propia dirección
«Suele llegar desde» es el ejemplo de una sola conexión (verificación de datos, 24 oct 2026); en su caso puede variar. La página no depende de ello: pregunta a cada servicio por DNS over HTTPS qué dirección usa para usted, y dice «probable» cuando no se le puede preguntar a un servicio.

¿Cómo compruebo fugas de DNS desde la línea de comandos?

Ejecute nslookup -type=txt whoami.leak.dnsrobot.net: nuestro servidor de nombres responde con la dirección del servidor DNS que preguntó, el predeterminado de su sistema. En una Mac use dns-sd -q whoami.leak.dnsrobot.net TXT (deténgalo con Ctrl-C), porque ahí dig solo ve el ajuste DNS principal; en Linux, resolvectl query --type=TXT whoami.leak.dnsrobot.net. El panel de comandos copia cada uno.

Este test ve el DNS que usa su navegador, y las apps pueden tomar otro camino: un proveedor de DNS seguro personalizado en Chrome o Firefox recibe las consultas del navegador en lugar del DNS del sistema. Si el navegador y el comando no coinciden, la fuga está solo en uno de ellos.

Agregue 1.1.1.1 al final para preguntar directamente a Cloudflare (dig @1.1.1.1 TXT whoami.leak.dnsrobot.net +short en una Mac o en Linux). La respuesta debería ser una dirección de la red de Cloudflare. La dirección de cualquier otra red es un fuerte indicio de que algo responde el DNS destinado a 1.1.1.1: su app de VPN (algunas lo hacen a propósito), un software de seguridad, su router o su proveedor.

Si tiene su propio resolutor, como Pi-hole con Unbound, la respuesta es la dirección de su casa: téngalo en cuenta antes de pegarla en cualquier sitio.

Dos comprobaciones desde una terminalnslookup de Windows, formato real de la salida

1 · el DNS de su sistema

C:\> nslookup -type=txt whoami.leak.dnsrobot.net
Server:  cache2.broadband.example
Address:  203.0.113.53

Non-authoritative answer:
whoami.leak.dnsrobot.net        text =

        "203.0.113.53"

DNS de Example Broadband: el mismo servidor que en el test del navegador, así que aquí el navegador y el sistema toman el mismo camino.

¿Tiene su propio resolutor (Pi-hole con Unbound)? Entonces la respuesta es su propia dirección pública.

2 · la prueba de secuestro

C:\> nslookup -type=txt whoami.leak.dnsrobot.net 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Non-authoritative answer:
whoami.leak.dnsrobot.net        text =

        "192.0.2.10"

Una dirección de Cloudflare (AS13335): su consulta llegó a Cloudflare, como se pidió. Eso solo no demuestra que no haya nada en medio: un proxy puede reenviar las consultas a 1.1.1.1.

Si hubiera dicho "203.0.113.53": un fuerte indicio de que algo redirige su DNS: su app de VPN (algunas lo hacen a propósito), un software de seguridad, su router o su proveedor.

El formato de la salida real de nslookup de Windows frente a nuestro servidor de nombres, con direcciones de documentación. El panel de la herramienta copia estos comandos para Windows, macOS y Linux, y para PowerShell.

Fugas de DNS, de IPv6 y de WebRTC: ¿cuál es la diferencia?

Son tres caminos distintos que rodean una VPN. Una fuga de DNS le muestra a su proveedor los nombres que consulta; una fuga de IPv6 saca el tráfico IPv6 con su dirección real; una fuga de WebRTC permite que un sitio web lea su dirección a través de la función de llamadas en tiempo real del navegador. Un test completo de fugas de VPN, o de fugas de IP, revisa las tres.

Esta página comprueba las dos primeras en un mismo test: los servidores DNS que preguntan y por dónde sale su dirección IPv6, en su propia línea bajo el resultado. WebRTC nunca toca el DNS, así que tiene su propio Test de fuga WebRTC; las direcciones que ven los sitios web están en Cuál es mi IP, y si puede llegar a sitios IPv6, en el Test IPv6.

También sirve como test de fugas DNS por IPv6, con un límite: nuestro servidor de nombres solo es accesible por IPv4, así que cada servidor DNS aparece con su dirección IPv4. Una consulta que su dispositivo envía por IPv6 se detecta igual, porque el servidor DNS al que llega tiene que preguntarnos por IPv4; un raro servidor DNS solo IPv6 no puede llegar a nosotros y aparece como No llegó nada.

Tres caminos que rodean una VPNuna conexión, tres comprobaciones

TÚNEL VPN · M247Consultas DNSWebRTCTráfico IPv6los nombres que visitalas direcciones que ofrecesu propia direcciónfuera del túnel: esta VPN solo lleva IPv4DNS de su VPN198.51.100.53 · M247este test no lo compruebaExample Broadband · IPv62001:db8:4a1f:7c00::1cTÚNEL VPN · M247Consultas DNSWebRTCTráfico IPv6los nombres que visitalas direcciones que ofrecesu propia direcciónfuera del túnel: esta VPN solo lleva IPv4DNS de su VPN198.51.100.53 · M247este test no lo compruebaExample Broadband · IPv62001:db8:4a1f:7c00::1c
  • Fuga de DNSLos servidores DNS que preguntaron: las filas de este test.
  • Fuga de WebRTCLas direcciones que su navegador puede compartir con los sitios web: el Test de fuga WebRTC las comprueba.
  • Fuga de IPv6Por dónde sale su tráfico IPv6: su propia línea bajo el resultado de este test.
El ejemplo de fuga de IPv6 de la herramienta: el DNS va por el túnel hasta el DNS de la VPN, así que no hay fuga de DNS, mientras que IPv6 sale por Example Broadband porque esta VPN solo lleva IPv4. WebRTC necesita su propio test.

¿Qué debería mostrar una VPN en un test de fugas DNS?

Solo el DNS propio de la VPN: un servidor en la red de la VPN o de su socio, normalmente cerca del servidor al que se conectó. El nombre de su proveedor de internet nunca debería aparecer mientras la VPN está activa; Cuál es mi ISP muestra qué red ven los sitios web en su lugar.

Cada empresa lo describe de otra forma. Surfshark dice que un test de fugas DNS de Surfshark debería mostrar un servidor DNS con la misma dirección que su VPN; Proton VPN y Windscribe dicen que la dirección es distinta pero está en el mismo lugar. Mullvad usa el servidor DNS del servidor VPN al que está conectado, ExpressVPN tiene su propio DNS cifrado en cada servidor, y NordVPN publica sus dos direcciones DNS.

Así que un test de fugas DNS de ExpressVPN, Mullvad o NordVPN, como cualquier test de fugas DNS de una VPN, se supera cuando ningún servidor DNS está en la red de su proveedor, sea cual sea la dirección: este test nunca compara direcciones. La regla de Mullvad es más estricta: allí, cualquier servidor DNS que no sea de Mullvad cuenta como fuga.

Un DNS personalizado en la app de VPN cambia las cosas: la opción «Use Existing DNS» de PIA y la opción de DNS personalizado de Mullvad envían las consultas saltándose el DNS propio de la VPN, así que aparece ese servidor. La tabla recoge lo que dicen las páginas de ayuda de cada VPN; no es un ranking ni una recomendación.

Lo que siete VPN dicen que debería versegún sus propias páginas de ayuda

VPNDNS propio por defectoLo que muestra este testDirección DNS que publica
MullvadsíEl servidor DNS del servidor de Mullvad al que está conectadono publicada
Proton VPNsíUn servidor DNS en el mismo centro de datos que su servidor VPN, con otra dirección; puede pertenecer a un socio10.2.0.1
NordVPNsíLos servidores DNS propios de NordVPN103.86.96.100103.86.99.100
SurfsharksíUn servidor DNS de la misma ubicación; Surfshark dice que sus direcciones IP y DNS coincidenno publicada
ExpressVPNsíEl DNS cifrado propio de ExpressVPN, que funciona en cada uno de sus servidoresno publicada
Private Internet AccesssíEl DNS de PIA, el predeterminado de la app10.0.0.24210.0.0.243
WindscribesíSu propio DNS en el mismo país, normalmente no exactamente su dirección VPN10.255.255.x
Según las páginas de ayuda de cada VPN, consultadas el 24 oct 2026. Sus reglas difieren (Surfshark: la misma dirección; Proton y Windscribe: otra dirección en el mismo lugar), así que el test nunca compara direcciones: si ningún servidor DNS está en la red de su proveedor, no hay fuga.

Test de fugas DNS: preguntas frecuentes

¿Qué es una fuga de DNS y es grave?

Una fuga de DNS ocurre cuando los servidores DNS de su proveedor de internet responden sus consultas mientras usa una VPN. Importa si confía en la VPN para su privacidad: su proveedor puede ver el nombre de cada sitio que consulta, aunque su tráfico vaya por el túnel. Sin VPN, el DNS de su proveedor es el camino normal, no una fuga. El test le dice en qué caso está.

¿Puede mi ISP ver mi navegación si hay una fuga de DNS?

Puede ver los nombres de los sitios que consulta, como example.com, y cuándo. No puede ver las páginas ni lo que escribe, porque HTTPS los cifra. Con una VPN que funciona, solo ve el túnel. Con una fuga de DNS vuelve a ver los nombres: el DNS tradicional no está cifrado, aunque el sitio web use HTTPS (RFC 9076).

¿Una VPN soluciona las fugas de DNS?

Una buena app de VPN las evita enviando cada consulta a su propio DNS dentro del túnel, siempre que su protección contra fugas de DNS esté activada y nada en su dispositivo la anule. Los adaptadores de red de Windows, IPv6, un proveedor de DNS seguro personalizado en el navegador y el DNS privado de Android aún pueden enviar consultas a otro lado. Haga el test después de conectarse para comprobarlo.

¿Por qué el test muestra un servidor DNS en otro país?

Los servicios de DNS responden desde el más cercano de sus muchos sitios, y ese sitio puede preguntar a otros servidores de nombres desde una dirección registrada en otro lugar o desde la red de un socio. El DNS de una VPN también puede estar en un centro de datos cercano. Otro país nunca es una fuga por sí mismo: lo que importa es de quién es el servidor, y eso se lo dice la etiqueta de cada fila.

¿Por qué veo Google o Cloudflare si no los configuré?

Algo en su dispositivo o red envía allí las consultas: un DNS seguro personalizado en el navegador, los ajustes del router, su app de VPN o una app de DNS. Si el DNS de su sistema es 1.1.1.1 u 8.8.8.8, Chrome puede seguir usándolo por HTTPS, saltándose una VPN que solo intercepta el puerto 53. Nada de eso es una fuga en sí: desde una VPN, esas consultas llegan con la dirección de la VPN, no con la suya.

El test no encontró servidores DNS. ¿Significa que no hay fuga?

No. «No llegó nada» significa que ningún servidor DNS preguntó a nuestro servidor de nombres, normalmente porque un bloqueador de anuncios, una lista de Pi-hole, un DNS con filtro o un bloqueo de red detuvo los nombres del test, así que el test no puede ver su DNS en absoluto. Permita *.leak.dnsrobot.net y repita el test, o pruebe el test extendido. Un resultado vacío nunca se toma como luz verde.

¿Es privado este test DNS?

El test consulta nombres aleatorios bajo nuestro dominio; nuestro servidor de nombres guarda 10 minutos en memoria los servidores DNS que preguntaron y luego los olvida. Para leer su otra dirección y nombrar los DNS públicos, su navegador también hace una o dos preguntas a ipify y a algunos servicios de DNS, que así ven su dirección IP. Una subred transmitida sobre usted solo la ve usted. Su último resultado se queda en su navegador y puede borrarlo.

¿Qué es una fuga de IPv6 y este test la comprueba?

Una fuga de IPv6 ocurre cuando su VPN lleva el tráfico IPv4 pero su tráfico IPv6 sale por su proveedor, con su dirección IPv6 real. Este test comprueba en el mismo análisis por dónde sale su dirección IPv6 y lo muestra en su propia línea. La solución es la protección contra fugas de IPv6 de la app de VPN, o una VPN que lleve IPv6; Microsoft desaconseja desactivar IPv6.

¿DNS over HTTPS evita las fugas de DNS?

Oculta sus consultas a su red, no a la empresa de DNS que las recibe, así que un servicio DoH como Cloudflare o NextDNS no es una fuga hacia su proveedor. Eso sí, un proveedor DoH personalizado en el navegador se salta el DNS de su VPN. El modo automático de Chrome mantiene su proveedor actual, y Firefox solo activa DoH por defecto en Estados Unidos, Canadá, Rusia y Ucrania, y se hace a un lado ante una VPN.

¿Puedo tener una fuga de DNS sin VPN?

No en el sentido habitual: sin VPN, el DNS de su proveedor es el camino normal. Lo que sí puede pasar es que un DNS que usted eligió, como 1.1.1.1, no sea el que responde, porque su router, una app o su proveedor lo anula o redirige el puerto 53. Elija ese servicio en «¿Qué quiere comprobar?» y el veredicto le dirá si de verdad responde.

¿Cómo soluciono una fuga de DNS en Android o iPhone?

En Android, ponga «DNS privado» en «No» mientras usa una VPN: un nombre de host configurado ahí envía cada consulta a ese proveedor y no a la VPN. En iPhone, un perfil o una app de DNS cifrado se aplica a todo el sistema una vez activado: elimine los que ya no use. Con iCloud Private Relay, las consultas de Safari las hacen los socios de relay de Apple, y aparecen sus servidores; una VPN tiene prioridad sobre Private Relay.

¿Con qué frecuencia debo hacer un test de fugas de DNS?

Después de instalar o actualizar una app de VPN, después de cambiar los ajustes de DNS y cada vez que cambie de red, por ejemplo del Wi-Fi de casa al de un café o a los datos móviles. Cada red entrega su propio DNS, y una VPN que se cae puede volver a él por un momento. La página guarda su último resultado en su navegador, así que cada nuevo test muestra qué servidores DNS cambiaron.

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

Más herramientas de DNS y red