Test de fugas de DNS: qué comprueba y cómo cerrar una fuga
El DNS convierte nombres en direcciones. Si esas consultas salen de tu dispositivo por fuera del túnel, tu operador ve todos los dominios que visitas aunque el tráfico vaya cifrado. Las cuatro causas habituales y cómo arreglar cada una.

En resumen
- Una fuga de DNS significa que las consultas van al resolutor de tu operador en lugar del que corresponde al túnel. El contenido sigue cifrado, pero la lista de sitios no.
- El test funciona cargando recursos desde subdominios aleatorios y mirando qué resolutores preguntaron por ellos. Si uno pertenece a tu operador, hay fuga.
- Cuatro causas típicas: la VPN nunca fijó un resolutor, Windows pregunta por todos los adaptadores a la vez, el IPv6 rodea un túnel que solo lleva IPv4, y el navegador usa su propio DNS cifrado.
- La solución estructural no es configurar un resolutor público, sino que el DNS se resuelva en el propio servidor de salida.
- Comprueba el tuyo en el test de fugas. No guarda nada.
Por qué existe el DNS
Las máquinas se hablan por direcciones numéricas, las personas recordamos nombres. El DNS es la traducción entre ambos: antes de abrir una web, tu dispositivo pregunta «¿qué dirección tiene este nombre?» y alguien responde.
Ese «alguien» es el resolutor, y por defecto es el de tu operador. Ahí está el problema: aunque luego la conexión vaya cifrada de extremo a extremo, la pregunta se hizo antes y en claro. Quien responde sabe qué sitios abres, a qué hora y con qué frecuencia.
Por eso una VPN que cifra el tráfico pero deja el DNS fuera resuelve media cosa.
Cómo funciona realmente el test
No hay magia. La página de prueba carga recursos desde subdominios generados al azar, del tipo a7f3k9.test.ejemplo.com. Como ese nombre no lo ha pedido nadie antes, no está en ninguna caché y obliga a una consulta real.
El servidor que controla ese dominio anota qué resolutores preguntaron. Luego te muestra la lista.
La lectura es sencilla: si aparece un resolutor de tu operador, tus consultas salen por fuera. Si solo aparece el del servicio al que estás conectado, el túnel las lleva como debe.
Causa uno: la VPN nunca fijó un resolutor
El caso más común y el más tonto. El perfil levanta el túnel pero no indica qué servidor DNS usar, así que el sistema sigue con el que tenía.
En un perfil de WireGuard o AmneziaWG eso es una línea:
DNS = 10.0.0.1
Si esa línea falta, el sistema se queda con el resolutor del router y todas las consultas salen por fuera mientras el resto del tráfico va cifrado.
Causa dos: Windows pregunta a todos los adaptadores a la vez
Windows tiene una función llamada resolución multi-homed: ante una consulta, la manda por todas las interfaces de red disponibles y se queda con la respuesta más rápida.
El resultado es que, aunque el túnel esté bien configurado, la misma pregunta también sale por el adaptador normal. La respuesta del túnel suele llegar antes, así que todo parece funcionar, pero tu operador ya ha visto el nombre.
Se desactiva en la directiva de grupo o con una clave de registro, y muchos clientes de VPN lo hacen por ti. Si usas configuraciones importadas a mano, es cosa tuya.
Causa tres: el IPv6 rodea un túnel IPv4
Si el túnel solo transporta IPv4 y tu operador te da IPv6, el sistema puede resolver y conectar por IPv6 saltándose el túnel por completo.
Esto no es solo una fuga de DNS, es una fuga de tráfico entero, y por eso es la peor de las cuatro.
Nuestras salidas son solo IPv4, y el perfil de AmneziaWG enruta el IPv6 hacia el túnel y lo descarta allí en lugar de dejar que se escape. En aplicaciones VLESS, el modo TUN hace lo mismo. Si usas otro proveedor, comprueba esto antes que nada.
Causa cuatro: el navegador tiene su propio DNS
Firefox y Chrome pueden usar DNS cifrado por HTTPS, con un resolutor propio que no es el del sistema. Es bueno para la privacidad frente a tu operador y confuso para el diagnóstico: el navegador puede estar usando Cloudflare mientras el resto del sistema usa el túnel.
No es una fuga en sentido estricto, pero explica resultados contradictorios entre un test hecho en el navegador y otro hecho fuera de él.
Un orden de prueba que ahorra tiempo
- Conecta el túnel y abre el test. Apunta qué resolutores aparecen.
- Si sale tu operador, revisa primero si el perfil tiene línea DNS.
- Mira si aparece alguna dirección IPv6. Si la hay, ese es el problema principal.
- En Windows, descarta la resolución multi-homed antes de buscar cosas raras.
- Repite el test en una ventana privada con el DNS del navegador desactivado, para separar un caso del otro.
La solución estructural
Apuntar a un resolutor público conocido tapa el síntoma: deja de verlo tu operador y pasa a verlo esa empresa.
La solución de verdad es que el DNS se resuelva en el propio servidor de salida, de modo que la consulta nunca abandone el túnel. Nadie en el camino ve el nombre, y el proveedor que podría verlo es el mismo que ya transporta tu tráfico.
Así funcionan nuestras salidas: el DNS se resuelve en la máquina, y no se anota ni el tráfico, ni las consultas, ni las marcas de tiempo, ni las direcciones.
Preguntas frecuentes
¿Una fuga de DNS revela lo que hago en una web?
No, solo el nombre del dominio. Pero la lista de dominios ya dice bastante: qué bancos, qué servicios médicos, qué foros.
¿Sirve poner 8.8.8.8 o 1.1.1.1?
Cambia quién ve tus consultas, no si alguien las ve. Pasa de tu operador a Google o Cloudflare.
¿El modo incógnito evita las fugas de DNS?
No. El incógnito solo afecta al historial local. Las consultas salen igual.
¿Por qué el test sale limpio y luego sucio?
Normalmente por caché o por cambio de red. Repite tras reconectar y con una ventana nueva.
¿Y si la fuga aparece solo en el móvil?
Suele ser el DNS privado de Android, que convive con el túnel, o perfiles que no fijan resolutor. Revisa los ajustes de red del sistema, no los de la app.
Un túnel que también lleva el DNS
DNS resuelto en la máquina de salida, VLESS/Reality y AmneziaWG en todos los planes, sin cuenta ni correo. Pruébalo gratis una hora, planes desde 1,99 $.