Fugas de DNS: cómo el tráfico evade el proxy y cómo cerrar el dns leak a nivel de sistema

Introducción: por qué el proxy puede ser perfecto y aun así te ven

Imagina la situación. Compraste un proxy móvil de calidad, configuraste el navegador antidetect, verificaste la IP en tres servicios distintos — en todos aparece la dirección del operador celular en la región correcta. Abres la cuenta publicitaria, calientas los perfiles, haces scraping. Y a los pocos días recibes un bloqueo con la fórmula de "actividad sospechosa". ¿Te suena? Una de las causas más subestimadas de estas historias es el dns leak, es decir, la fuga de consultas DNS que evaden el proxy.

La paradoja es que la dirección IP sí está efectivamente suplantada. El sitio ve tráfico desde el operador móvil. Pero antes de cada conexión, tu computadora le pregunta silenciosamente a su proveedor: "¿dónde está el servidor tal?" Y esa pregunta sale directamente, sin pasar por el proxy. Como resultado, la parte observadora obtiene dos imágenes que no coinciden: la conexión viene de una red móvil de una región, y los nombres se resuelven a través del resolutor del proveedor de internet doméstico de otra ciudad completamente distinta. Para los sistemas antifraude de 2026, esa discrepancia no es un detalle menor, sino una de las señales más confiables.

Según nuestras observaciones en las consultas al soporte, una porción notable de las quejas del tipo "el proxy no funciona, el geolocalización se detecta mal, las cuentas caen sin razón" al analizarse en detalle resulta no ser un problema del proxy en absoluto. Es un problema de la capa DNS del lado del cliente. Y además, quienes verifican el DNS de manera intencional antes de empezar a trabajar siguen siendo minoría — la mayoría se limita a verificar la IP.

En esta guía desglosaremos el tema por completo. Sabrás cómo funciona la resolución de nombres y en qué momento evade el proxy. Entenderás en qué se diferencian los proxies HTTP y SOCKS desde el punto de vista del DNS, por qué una sola letra en la cadena de conexión lo decide todo, y cómo los navegadores con DNS cifrado activado crean una nueva categoría de fugas. Daremos cuatro métodos prácticos — diagnóstico, configuración del software cliente, navegadores y antidetects, nivel de sistema — cada uno con instrucciones paso a paso y listas de verificación. Analizaremos errores típicos, casos con cifras y responderemos preguntas complejas.

Una frontera importante: este artículo trata sobre la capa DNS. Las fugas mediante WebRTC, las huellas del navegador, los tiempos y otros canales de desanonimización son temas aparte, desarrollados en otros materiales del blog. Aquí nos concentraremos en un canal, pero fundamental, porque sin entenderlo cualquier otra configuración se sostiene sobre arena.

Fundamentos: cómo funciona el DNS y qué es un dns leak

La guía telefónica de internet

Cada vez que el navegador o un script quiere conectarse a un sitio, no necesita el dominio, sino la dirección IP. El dominio es un nombre comprensible para una persona. La dirección son coordenadas comprensibles para la red. El servicio que traduce uno en otro se llama DNS (Domain Name System). La analogía más simple es una guía telefónica: conoces el nombre, la guía te da el número. Solo que esta guía está distribuida en miles de servidores y funciona en milisegundos.

Así se ve la resolución de un nombre en la práctica:

1. La aplicación llama a una función del sistema (en el mundo Unix suele ser getaddrinfo), pasándole el nombre de dominio.
2. El sistema operativo revisa la caché local y el archivo hosts.
3. Si no hay respuesta, el resolutor stub (stub resolver) del SO envía la consulta a la dirección del servidor DNS configurado en los ajustes de red. Normalmente es el servidor de tu proveedor, entregado por DHCP, o un resolutor público que indicaste manualmente.
4. El resolutor recursivo del proveedor recorre la cadena de servidores raíz, servidores de zona del dominio y servidores autoritativos del dominio, encuentra la respuesta y te la devuelve.
5. La aplicación recibe la IP y recién entonces establece la conexión.

Presta atención al orden. Primero el DNS, después la conexión. El proxy es una herramienta que interviene en la conexión. Pero si interviene o no en el DNS depende del tipo de proxy, del protocolo y de cómo exactamente la aplicación lo use.

Qué es exactamente lo que se llama fuga

Un DNS leak es la situación en que el tráfico de la aplicación pasa por el proxy, pero las consultas de resolución de nombres no. Salen directamente desde tu interfaz de red real hacia el resolutor configurado en el sistema. Resultado: el sitio al que te conectas ve la IP del proxy, pero tu proveedor y el dueño del resolutor ven la lista completa de todos los dominios que consultaste. Y el servicio objetivo, bajo ciertas condiciones, puede correlacionar de dónde vino la conexión y de dónde vino la consulta DNS.

¿Por qué es importante precisamente para usuarios de proxies móviles? Porque todo el valor de una IP móvil está en su verosimilitud. La dirección pertenece a un operador celular, detrás de ella hay miles de abonados reales, cambia, tiene buena reputación. Pero un abonado real de red móvil resuelve nombres a través de los servidores DNS de ese mismo operador. Si tu tráfico sale de la red móvil y los nombres se resuelven a través del proveedor de cable de otra región, dejas de parecer un abonado real. Empiezas a parecer alguien que usa un proxy. Y en efecto lo eres — y tú mismo lo contaste.

Tres roles que ven tu fuga

• Tu proveedor de internet. Ve las consultas a su resolutor y sabe qué dominios visitas, incluso si el contenido en sí salió por el proxy.
• El dueño del resolutor. Si configuraste un DNS público, su operador ve la lista completa de tus dominios y tu IP real.
• El sitio objetivo y su antifraude. Directamente no recibe la consulta DNS, pero tiene canales indirectos: la geografía de los servidores autoritativos, el mecanismo EDNS Client Subnet, el enrutamiento CDN y dominios de prueba especiales que se generan para una sesión concreta. Sobre esto en detalle en la siguiente sección.

Inmersión profunda: anatomía de la fuga de DNS al trabajar a través de un proxy

Proxy HTTP: por qué normalmente no hay fuga, pero hay excepciones

Al trabajar a través de un proxy HTTP, el navegador le envía una solicitud donde el dominio está indicado como texto. Para HTTP sin cifrar es la URL completa en la primera línea de la solicitud. Para HTTPS el navegador envía el comando CONNECT con el nombre del host y el puerto, y el proxy mismo resuelve ese nombre y establece el túnel. En ambos casos el cliente no necesita conocer la IP del servidor objetivo. La resolución la hace el proxy, de su lado, con sus resolutores. En el caso de un proxy móvil, del lado del módem o del teléfono, a través de los servidores DNS del operador. Así es como debe ser.

¿De dónde entonces surgen fugas con proxy HTTP? Sus fuentes son indirectas:

• Scripts PAC. El archivo de autoconfiguración del proxy puede contener la función dnsResolve, que resuelve el dominio localmente para decidir si enviar la solicitud a través del proxy. La decisión misma se toma ya después de la consulta DNS local.
• Resolución previa de nombres. Algunas aplicaciones verifican la disponibilidad del host antes de conectarse: hacen ping, resuelven, y luego van por el proxy. Aplicaciones Java con InetAddress, ciertos scrapers, plugins de verificación de enlaces.
• Servicios en segundo plano del navegador. La precarga de páginas, el DNS-prefetch, las verificaciones de navegación segura y las actualizaciones pueden funcionar con sus propias reglas y no siempre respetan la configuración del proxy.

SOCKS: una sola letra entre una sesión limpia y la fuga

Aquí empieza lo más interesante. El protocolo SOCKS4 en su versión original solo puede pasar al proxy la dirección IP de destino. Eso significa que el cliente está obligado a resolver el nombre por sí mismo, antes de conectarse. La fuga está incorporada al protocolo. La extensión SOCKS4a añadió la posibilidad de pasar el nombre del host. SOCKS5 admite tres tipos de dirección de destino: IPv4, IPv6 y nombre de dominio.

Parecería que SOCKS5 resuelve el problema. Pero el soporte del nombre de dominio en el protocolo no significa que el cliente lo use. Muchas bibliotecas y programas resuelven el nombre localmente por defecto y envían al proxy una IP ya lista. El protocolo lo permite — simplemente la fuga ocurre un paso antes.

De ahí la famosa letra h. En curl y en las bibliotecas que siguen su convención, el esquema socks5:// significa resolución local de nombres, y socks5h:// significa pasar el nombre del host al servidor proxy para resolución remota. Una sola letra. La diferencia entre una sesión limpia, donde todo, incluyendo el DNS, sale de la red móvil del operador, y una sesión en la que cada nombre primero se filtra a tu proveedor.

Por qué es mejor que el servidor proxy resuelva por sí mismo

Hay un punto no evidente que muchos pasan por alto. No se trata solo de privacidad. Cuando el nombre lo resuelve el lado remoto del proxy móvil, la respuesta DNS se forma teniendo en cuenta la ubicación del operador. Los grandes servicios usan CDN y geo-DNS: para un mismo dominio a distintos clientes se les devuelven distintas IP, las más cercanas a ellos. Si resuelve tu proveedor doméstico, obtendrás la dirección del nodo CDN cercano a tu ubicación real. Y luego te conectarás a ese nodo a través del proxy móvil de otra región. Para el servicio esto se ve extraño: un cliente de la red móvil de la región A de repente llegó a un nodo destinado a la región B. Este es precisamente el canal indirecto de detección de dns leak, que no requiere ningún acceso a tus consultas DNS.

EDNS Client Subnet: cómo el resolutor reparte tu subred

El mecanismo EDNS Client Subnet (ECS) se ideó para que los resolutores públicos pudieran transmitir a los servidores autoritativos parte de la dirección del cliente — normalmente los primeros 24 bits para IPv4. Así la CDN entiende de dónde viene el usuario real y entrega el nodo más cercano. Es cómodo para la velocidad. Pero desde el punto de vista de las fugas, esto significa que al resolver localmente a través de un DNS público con soporte de ECS, el servidor autoritativo del dominio objetivo recibe la subred de tu conexión real. No la dirección completa, pero suficiente para entender el proveedor y la ciudad. Y la conexión luego llega desde una IP móvil. Dos subredes, dos operadores, un usuario.

DNS cifrado: nueva categoría de fugas

Desde la década de 2020, los navegadores y sistemas operativos migraron masivamente a DNS over HTTPS (DoH) y DNS over TLS (DoT), y para 2026 se sumó también DNS over QUIC. La idea es buena: el proveedor ya no ve tus consultas. Pero para el trabajo a través de proxy surgió un efecto secundario. Un navegador con "DNS seguro" activado se dirige al servidor DoH elegido con su propio cliente, y ese tráfico no siempre sigue la configuración del proxy. Es decir, los nombres no se resuelven en el operador móvil, sino en un gran resolutor público, y además desde tu IP real. El cifrado protege del proveedor, pero no de la discrepancia entre el lado DNS y el lado de la conexión.

Una capa adicional de complejidad añade Encrypted Client Hello (ECH). Para que funcione, el navegador solicita registros HTTPS especiales en el DNS. Cuantos más sitios usan ECH, más consultas DNS hace el navegador — y más motivos de fuga si el DNS no va por el camino correcto.

IPv6 y Happy Eyeballs

Los sistemas modernos solicitan simultáneamente registros A (IPv4) y AAAA (IPv6) e intentan conectarse al que responda más rápido — el algoritmo Happy Eyeballs. Si tu red real soporta IPv6 y el proxy solo funciona por IPv4, varias aplicaciones pueden salir directamente por IPv6, evitando el proxy por completo. Estrictamente hablando, esto no es dns leak sino una fuga de conexión, pero el disparador es precisamente la respuesta DNS con registro AAAA. Por eso, en el contexto de la higiene DNS, hay que tener IPv6 presente.

Caché y hosts: la fuga del pasado

El SO almacena en caché las respuestas DNS. Si trabajaste sin proxy y luego lo activaste, parte de los nombres ya están en la caché con direcciones obtenidas a través del resolutor doméstico. No habrá nuevas consultas, pero las conexiones irán a nodos CDN "domésticos". Igualmente, el archivo hosts: las entradas en él sustituyen por completo la resolución de nombres, y el proxy no se entera.

Método 1. Diagnóstico: cómo verificar el dns leak con tus propias manos

Antes de configurar algo, hay que ver el problema. La buena noticia: verificar la fuga de DNS es un procedimiento de cinco minutos que se puede y se debe convertir en un ritual antes de cada sesión de trabajo.

Cómo funcionan los tests en línea

Cualquier servicio de verificación de dns leak está construido igual. La página genera varios subdominios únicos del tipo cadena-aleatoria.dominio-de-prueba y obliga a tu navegador a resolverlos, normalmente cargando imágenes o scripts invisibles. Como los subdominios son únicos, seguro no están en ninguna caché. La consulta llegará obligatoriamente al servidor autoritativo del dominio de prueba, que pertenece al servicio. Este registra desde qué IP vino la consulta — la dirección del resolutor recursivo que estás usando. Luego la página te muestra dos columnas: la dirección desde la que vino la conexión HTTP y las direcciones de los resolutores. Si la conexión es del operador móvil y el resolutor pertenece al proveedor doméstico o a un servicio DNS público, hay fuga.

Es importante entender: exactamente lo mismo puede hacer cualquier sitio. El mecanismo no requiere permisos especiales. Los sistemas antifraude de las grandes plataformas aplican técnicas similares como parte de la evaluación de riesgo de la sesión. No es teoría conspirativa, sino ingeniería estándar.

Procedimiento paso a paso de verificación

1. Fija la línea base. Desactiva el proxy, abre el test de dns leak, anota qué resolutores aparecen. Es tu huella "doméstica". Debes reconocerla a simple vista.
2. Limpia la caché DNS. En Windows el comando ipconfig /flushdns, en macOS reiniciar el servicio mDNSResponder, en Linux depende del resolutor (por ejemplo, resolvectl flush-caches para systemd-resolved). Reinicia el navegador — tiene su propia caché.
3. Activa el proxy de la manera en que vas a trabajar realmente: a través del perfil antidetect, la extensión, los ajustes del sistema o el código.
4. Ejecuta un test avanzado que haga no una sino decenas de verificaciones. La fuga puede ser parcial: nueve consultas de diez salen por el proxy y la décima va directa. Un test único no lo detectará.
5. Compara. Todos los resolutores deben pertenecer al operador celular a través del cual funciona el proxy, o a la infraestructura del servicio de proxies. Ninguna dirección de la línea base. Ningún resolutor público que no hayas elegido conscientemente.
6. Verifica IPv6 por separado. Si el test muestra cualquier dirección IPv6 que no pertenezca al proxy — hay fuga.
7. Repite a los diez minutos de trabajo. Algunos procesos en segundo plano arrancan con retraso.

Verificación sin servicios externos: dominio de prueba propio

Para quienes trabajan con granjas de cuentas o scraping a escala industrial, es razonable tener su propia herramienta. El esquema es así: registras un dominio barato y levantas para él un servidor DNS autoritativo en tu VPS con registro de consultas activado. Luego, en cualquier proyecto, al iniciar cualquier sesión, consultas un subdominio único del tipo identificador-de-sesión.tu-dominio. En el log del servidor DNS aparece una entrada: qué subdominio se consultó y desde qué IP del resolutor. Lo correlacionas con el identificador de la sesión y ves al instante qué sesión, qué perfil, qué worker filtró. Esto convierte la verificación puntual en monitoreo constante.

Verificación de bajo nivel: mirar la red

La forma más honesta es ver qué sale realmente de la interfaz de red. Ejecuta un analizador de tráfico (Wireshark o tcpdump) en la interfaz física de la máquina y filtra el puerto 53 UDP y TCP, y también el puerto 853 para DoT. Luego trabaja a través del proxy cinco minutos. En un mundo ideal el filtro quedará vacío: todos los nombres se resuelven del lado del proxy, no hay paquetes DNS locales en absoluto. Si hay paquetes, ves de inmediato qué dominios y a dónde salen. Para DoH el filtro es más complejo, porque es HTTPS común en el puerto 443, pero una pista son las conexiones a direcciones conocidas de proveedores públicos de DoH que aparecen sin pasar por el proxy.

Lista de verificación del diagnóstico

• Línea base sin proxy registrada.
• Caché del SO y del navegador limpiada antes del test.
• Test avanzado con decenas de consultas ejecutado.
• Todos los resolutores corresponden al lado del proxy.
• Direcciones IPv6 de red ajena ausentes.
• Test repetido a los 10 minutos de trabajo superado.
• Para proyectos críticos: analizador de tráfico en el puerto 53 muestra cero paquetes.

Método 2. Configuración correcta del software cliente y del código

Encontraste la fuga. Ahora hay que entender dónde exactamente la aplicación toma la decisión de resolver el nombre localmente, y cambiar eso a resolución remota. Analicemos los entornos más frecuentes en la práctica de los afiliados y desarrolladores.

Principio: el nombre del host debe llegar al proxy

La regla es una, y es universal. El proxy debe recibir de ti el nombre de dominio, no la IP. Para un proxy HTTP esto ocurre naturalmente. Para SOCKS5 hay que elegir explícitamente el modo de DNS remoto. Para SOCKS4 sin extensión a esto es imposible en principio — tales proxies no sirven para trabajo limpio. Los proxies móviles de los servicios modernos soportan tanto HTTP como SOCKS5 con resolución remota, así que la limitación aquí es solo del lado del cliente.

curl y línea de comandos

Para SOCKS5 usa siempre el esquema con la letra h. Ejemplo de llamada correcta:

curl -x socks5h://user:pass@host:port https://example.com/

Sin la letra h, curl resuelve el nombre localmente. Esto también aplica a todas las herramientas construidas sobre libcurl. Para un proxy HTTP el esquema http:// en el parámetro -x es suficiente: el nombre irá en la solicitud CONNECT.

Python: requests, httpx, aiohttp

En la biblioteca requests con el paquete de soporte SOCKS instalado la regla es análoga: socks5:// significa resolución local, socks5h:// — remota. Este es el error más frecuente en scrapers: el desarrollador copia un ejemplo de la documentación donde está socks5, y durante años lleva tráfico con dns leak sin siquiera sospecharlo. En httpx y aiohttp el soporte SOCKS se implementa mediante transportes de terceros, y el modo de resolución remota hay que verificarlo en la documentación del transporte específico — en algunos es el parámetro rdns, en otros también el esquema con h. Verifica no por la documentación, sino por los hechos: ejecuta el script contra tu propio dominio de prueba y mira en el log desde dónde vino la consulta.

Una trampa aparte son las bibliotecas de sockets de bajo nivel que hacen monkey patch del módulo socket estándar para envolver todo el tráfico en SOCKS. Tienen un flag de resolución remota, pero por defecto con frecuencia está apagado. Además, cualquier llamada a socket.gethostbyname en tu código o en las dependencias pasará de largo y resolverá el nombre a través del resolutor del sistema.

Node.js y navegadores headless

En el ecosistema Node.js los agentes SOCKS normalmente pasan el nombre del host al proxy, pero esto depende del paquete específico y de su versión. Para Puppeteer y Playwright el proxy se define al nivel del arranque del navegador, y el comportamiento se hereda del motor Chromium — sobre sus particularidades con SOCKS5 hablaremos en la siguiente sección. Si trabajas con el modo HTTP del proxy móvil, la cuestión se elimina: Chromium enviará CONNECT con el nombre del host.

Go, Java y otros lenguajes

En Go el paquete estándar golang.org/x/net/proxy para SOCKS5 pasa el nombre del host de forma remota, pero solo si lo usas directamente como Dialer, y no resuelves antes. En Java las propiedades del sistema para proxy SOCKS funcionan, pero muchos clientes HTTP crean un objeto InetSocketAddress con resolución previa, y eso causa la fuga. La solución es crear una dirección no resuelta (métodos del tipo createUnresolved) y asegurarte de que el cliente soporte el paso del nombre. Consejo universal para cualquier lenguaje: encuentra en el código y en las dependencias todos los lugares donde un dominio se convierte en IP, y asegúrate de que eso ocurre después de establecer la conexión con el proxy, no antes.

Auditoría paso a paso del proyecto

1. Encuentra en el código todas las cadenas de conexión al proxy. Verifica los esquemas: socks5 sin h — bandera roja.
2. Encuentra todas las llamadas explícitas de resolución de nombres: gethostbyname, getaddrinfo, dns.lookup, InetAddress.getByName. Cada una es una fuga potencial.
3. Revisa las dependencias: bibliotecas de verificación de disponibilidad, health-check, reintentos con ping previo.
4. Ejecuta el proyecto contra tu propio dominio de prueba con un subdominio único por worker. El log del servidor DNS mostrará quién filtra.
5. Añade un autotest: la sesión no se considera válida hasta que la verificación DNS confirme que el resolutor pertenece al lado del proxy.
6. Fija el resultado en la documentación del proyecto: qué biblioteca, qué versión, qué modo.

Lista de verificación para el desarrollador

• Todas las conexiones SOCKS5 usan resolución remota.
• No hay resolución previa antes de la conexión.
• Las bibliotecas fueron verificadas no por la documentación, sino por el log del dominio de prueba.
• La verificación DNS automática está integrada en el inicio de la sesión.
• Para el modo HTTP del proxy se verificó que se usa CONNECT y no la sustitución por IP.

Método 3. Navegadores y antidetect browsers sin fugas de DNS

La mayor parte de la audiencia de proxies móviles trabaja no en código sino en el navegador: cuentas publicitarias, redes sociales, marketplaces, multitud de cuentas. Aquí hay sus propias reglas, y difieren de motor a motor.

Firefox y sus herederos

Firefox históricamente da el control más transparente. El parámetro clave en about:config es network.proxy.socks_remote_dns. Con el valor true, los nombres se pasan al proxy SOCKS para resolución remota. Con false — se resuelven localmente. En muchas compilaciones y perfiles antiguos está desactivado. El segundo parámetro es network.trr.mode, que controla el DNS cifrado: el valor 5 lo desactiva por completo, lo cual para trabajar a través de proxy es preferible, porque de lo contrario el navegador puede dirigirse al servidor DoH con su propio cliente. El tercer bloque es la precarga: network.dns.disablePrefetch en true y network.predictor.enabled en false desactivan la resolución especulativa de nombres para enlaces de la página, que de otro modo puede ir por fuera del proxy antes del clic real. Los antidetect browsers basados en el motor Firefox normalmente configuran estos parámetros correctamente, pero conviene verificarlos cada vez después de una actualización.

Chrome, Chromium y antidetects basados en ellos

Con Chromium la historia es más compleja. Trabajando a través de un proxy HTTP, envía CONNECT con el nombre — no hay fuga. En cambio, al usar un proxy SOCKS5 mediante un flag de arranque, el motor en varias configuraciones resuelve los nombres localmente, y no hay una configuración estándar de "DNS remoto" en la interfaz. Un truco de ingeniería conocido es el flag --host-resolver-rules con una regla que mapea todos los nombres al estado "no encontrado", excluyendo la dirección del propio proxy. Como resultado, el resolutor local no puede resolver nada, y el navegador se ve obligado a pasar los nombres al proxy. Parece un parche, pero funciona de forma confiable. El segundo punto importante es la configuración de DNS seguro en la sección de privacidad: con el estado activado, Chromium usa DoH hacia el proveedor elegido, y ese tráfico no siempre sigue el proxy. Para trabajar a través de un proxy móvil conviene desactivarlo o asegurarte en las pruebas de que se tuneliza correctamente. El tercero es la precarga de páginas: en los ajustes de rendimiento hay una opción de precarga que inicia consultas DNS para enlaces en los que aún no has hecho clic.

Qué debe saber hacer un antidetect browser

Un buen antidetect asume toda esta rutina. Pero la calidad de la implementación varía mucho. Esto es lo que hay que verificar al elegir y después de cada actualización:

• Modo de DNS remoto para SOCKS5 activado por defecto para cada perfil, no de forma global.
• Aislamiento del DNS entre perfiles. La caché de nombres resueltos no debe ser compartida: de lo contrario, un perfil en el proxy móvil de una región obtendrá la IP cacheada por un perfil en el proxy de otra región.
• DNS cifrado desactivado o tunelizado. Pregunta directamente al soporte: cómo se comporta el DoH integrado al trabajar a través del proxy.
• Prefetch desactivado. La resolución especulativa no debe vivir en un perfil que se hace pasar por un usuario móvil común.
• Verificación integrada de dns leak al iniciar el perfil, o al menos un acceso cómodo al test.
• Comportamiento ante la caída del proxy. Qué hace el navegador si el proxy no está disponible: bloquea las conexiones o sale directo. Lo segundo es una catástrofe no solo para el DNS.

Extensiones de proxy: hielo fino

Las extensiones del navegador que cambian el proxy funcionan a través de la API del navegador. Pueden configurar el proxy para las conexiones, pero su control sobre el DNS está limitado por las capacidades del motor. Una extensión no puede obligar a Chromium a usar DNS remoto para SOCKS5 si el propio motor no lo hace en esa configuración. Además, la extensión no controla los servicios en segundo plano del navegador. Por eso las extensiones son una opción aceptable para el modo HTTP del proxy móvil y verificaciones rápidas, pero no para trabajo serio con cuentas sensibles.

Configuración paso a paso del perfil

1. Crea un perfil e indica el proxy móvil. Prefiere el modo HTTP si el antidetect no garantiza DNS remoto para SOCKS5.
2. Desactiva el DNS cifrado en los ajustes del motor o del perfil.
3. Desactiva la precarga de páginas y el DNS-prefetch.
4. Si es un motor tipo Firefox — verifica socks_remote_dns manualmente.
5. Inicia el perfil, limpia la caché y pasa un test avanzado de dns leak.
6. Navega por varios sitios con analítica activa y repite el test: ¿aparecieron nuevos resolutores?
7. Guarda el resultado como referencia para este perfil.

Método 4. Nivel de sistema e infraestructura: cerramos las fugas de forma forzosa

Todos los métodos anteriores funcionan por el principio de confianza: configuramos la aplicación y esperamos que se comporte bien. El enfoque de ingeniería es otro: hacer la fuga técnicamente imposible. Incluso si la aplicación intenta enviar una consulta DNS directa, esta no debe salir.

Principio "todo lo que no va por el proxy está prohibido"

En la máquina de trabajo o en el servidor de la granja se configura un firewall que bloquea el tráfico saliente al puerto 53 (UDP y TCP) y al puerto 853 para todos los procesos, excepto los explícitamente permitidos. En Windows son reglas de conexión saliente en el firewall, en Linux — nftables o iptables, en macOS — pf. El sentido: si el navegador o el script intenta resolver un nombre localmente, recibirá un error, no una fuga silenciosa. El error es visible de inmediato — lo verás y corregirás la configuración de la aplicación. Una fuga silenciosa puede vivir meses.

Una sutileza con DoH: va al puerto 443, que no se puede bloquear entero. La solución es bloquear no el puerto, sino las direcciones de resolutores DoH públicos conocidos para los procesos que deben ir solo por el proxy. Esto requiere mantener una lista, pero la lista cambia rara vez.

Aislamiento mediante contenedores y espacios de nombres de red

Para desarrolladores y dueños de granjas en Linux, la herramienta más potente son los espacios de nombres de red (network namespaces) y los contenedores. La idea: cada worker, cada perfil de navegador o grupo de perfiles vive en su propio espacio de red, en el que no hay ninguna ruta por defecto hacia internet. La única salida es la dirección del proxy. Haga lo que haga la aplicación — resolver un nombre, salir por IPv6, abrir una conexión directa — físicamente no tiene ruta. Esta es la forma más confiable de garantizar la ausencia de dns leak a escala. En Docker esto se logra con una red personalizada sin puerta de enlace externa más el permiso explícito de acceso solo a la dirección del proxy. Adicionalmente, en la configuración del resolutor del contenedor se puede indicar una dirección inalcanzable para que cualquier intento de resolución local falle al instante y no se quede colgado en timeout.

IPv6 a nivel de sistema

Si tu proxy móvil funciona por IPv4 y la máquina tiene conexión IPv6, la solución más simple y confiable es desactivar IPv6 en la interfaz desde la cual funcionan los perfiles de proxy, o prohibir el IPv6 saliente con el firewall. Sí, es tosco. Pero excluye toda una clase de problemas en los que un registro AAAA en la respuesta DNS desvía la conexión directamente.

Resolutor del sistema y sus particularidades

Los SO modernos tienen resolutores multicapa. En Windows 11 hay soporte de DoH a nivel de sistema, y si está activado para tu adaptador, todas las resoluciones locales irán al servidor DoH elegido. Para una máquina de trabajo con proxy esto hay que comprenderlo: el DoH del sistema activado cambia el panorama de la fuga, pero no la elimina. Android usa la función Private DNS — una historia análoga para quienes trabajan con proxies en dispositivos móviles o emuladores. En Linux con systemd-resolved conviene verificar qué servidores DNS están asignados a cada interfaz, porque el resolutor sabe enrutar consultas por sufijos de dominio entre interfaces, y eso crea rutas inesperadas.

Monitoreo como proceso

A nivel de infraestructura, la verificación de dns leak se convierte de puntual en continua. Lo que tiene sentido implementar:

• Registro de intentos DNS bloqueados por el firewall. Cada entrada en el log es una aplicación que intenta resolver localmente. Es tu lista de pendientes a corregir.
• Dominio de prueba propio con subdominios únicos por sesión y alerta automática cuando aparece un resolutor ajeno.
• Captura periódica del tráfico de red en el puerto 53 desde la interfaz física — una vez al día, automáticamente, con alerta si el contador no es cero.
• Verificación tras cada actualización del navegador, antidetect, bibliotecas. Las actualizaciones son la principal fuente de regresiones: los desarrolladores cambian los defaults, activan nuevas funciones de precarga, añaden DNS cifrado.

Lista de verificación a nivel de sistema

• El tráfico saliente a los puertos 53 y 853 está bloqueado para los procesos de trabajo.
• Las direcciones DoH públicas conocidas están bloqueadas para esos mismos procesos.
• IPv6 está desactivado o bloqueado en las interfaces de trabajo.
• Los workers críticos están aislados en espacios de red sin ruta directa.
• Los logs del firewall sobre DNS se recopilan y se revisan.
• El dominio de prueba y las alertas están configurados.

Errores típicos: lo que no hay que hacer

Error 1. Verificar solo la IP

El más masivo. La persona ve la dirección del operador móvil en la página de verificación de IP y considera la tarea resuelta. Pero la verificación de IP responde solo a la pregunta "de dónde vino la conexión", no a "de dónde vinieron las consultas DNS". Son preguntas distintas con respuestas distintas.

Error 2. Configurar un DNS público y tranquilizarse

La lógica es comprensible: si el proveedor ve mis consultas, indicaré un resolutor público. Pero para trabajar a través de proxy esto no es una solución, sino el reemplazo de una fuga por otra. Las consultas igual salen desde tu IP real, ahora hacia otro observador. Y además los resolutores públicos usan ECS activamente y transmiten tu subred a los servidores autoritativos. La discrepancia entre el lado DNS y el lado de la conexión permanece.

Error 3. Usar SOCKS5 sin DNS remoto

El esquema socks5 en lugar de socks5h en el código, socks_remote_dns desactivado en el navegador, un antidetect con resolución local por defecto. Miles de proyectos viven con este error durante años.

Error 4. Considerar el DNS cifrado la solución del problema

DoH protege el contenido de las consultas del proveedor. Pero al trabajar a través de un proxy crea un canal aparte que no pasa por el proxy. Cifrado no es igual a enrutamiento correcto.

Error 5. Ignorar la precarga y los servicios en segundo plano

El navegador resuelve nombres de enlaces que aún no abriste. El antivirus verifica la URL. El actualizador busca el servidor de actualizaciones. Todo eso son consultas DNS que pueden ir por fuera. Una verificación con un test único no capta estas cosas.

Error 6. Caché DNS compartida entre perfiles

Si dos perfiles en proxies de distintas regiones comparten la caché, el segundo perfil se conectará al nodo CDN elegido para la primera región. El aislamiento de perfiles debe incluir el DNS.

Error 7. No verificar después de las actualizaciones

Una nueva versión del navegador activó el DNS seguro por defecto. Una biblioteca actualizada cambió el comportamiento de SOCKS. Una actualización del antidetect reseteó los ajustes del motor. Todos estos son escenarios reales que solo se descubren con una verificación repetida.

Error 8. Permitir la salida directa cuando el proxy no está disponible

Configuraciones del tipo "si el proxy no responde, ir directo" convierten cualquier fallo en una desanonimización total de la sesión, empezando por el DNS. El comportamiento correcto es bloquear las conexiones hasta que el proxy se restablezca.

Error 9. Resolución manual "por velocidad"

Algunos scrapers resuelven el dominio una vez y luego van por IP, para ahorrar en DNS. Además de la fuga de la consulta en sí, obtienen la IP elegida por el geo-DNS para su región real, y después llevan el tráfico a través del proxy móvil hacia un nodo CDN "ajeno". El ahorro de milisegundos se traduce en un perfil inconsistente.

Herramientas y recursos

Tests de fugas en línea

Los servicios de verificación de dns leak se dividen en básicos y avanzados. Los básicos hacen una o dos consultas y sirven para una estimación rápida. Los avanzados generan decenas de subdominios únicos y detectan fugas parciales. Para trabajar elige los que muestran no solo la IP del resolutor, sino también su pertenencia: organización, sistema autónomo, país. Un buen test también muestra IPv4 e IPv6 por separado y sabe verificar el comportamiento en consultas repetidas.

Analizadores de tráfico

Wireshark — analizador gráfico con filtros del tipo dns o udp.port == 53. tcpdump — su análogo de consola para servidores y máquinas Linux. Ambos permiten ver la verdad: qué sale realmente de la interfaz de red. Para DoH además observa las conexiones TLS hacia direcciones de resolutores públicos.

DNS autoritativo propio

Para monitoreo a escala: cualquier servidor DNS ligero con registro de consultas (CoreDNS, Unbound en modo autoritativo, BIND, servidores compactos en Go o Python) más un dominio propio. Los costos son mínimos, y el resultado es una supervisión constante de todos los workers y perfiles.

Herramientas de línea de comandos

dig y nslookup muestran a qué resolutor se dirige el sistema y qué responde. resolvectl en Linux con systemd-resolved muestra la configuración DNS por interfaces. curl con flag de salida detallada muestra si pasa el nombre al proxy o lo resuelve por sí mismo. En Windows ipconfig /displaydns mostrará el contenido de la caché, y Get-DnsClientServerAddress en PowerShell — los servidores asignados por adaptador.

Firewalls

El firewall integrado de Windows con reglas por programas, nftables e iptables en Linux, pf en macOS. Para mayor comodidad en la gestión de reglas por aplicación existen capas gráficas. El requisito clave es la capacidad de bloquear puertos para procesos concretos y llevar un log de bloqueos.

Contenedorización

Docker y Podman con redes personalizadas, espacios de nombres de red de Linux mediante ip netns, y para granjas de navegadores — orquestadores de perfiles que soportan aislamiento de red a nivel de perfil. Convierten la regla "solo por el proxy" de un ajuste en una garantía arquitectónica.

Capacidades del lado del servicio de proxy

Presta atención a lo que ofrece el propio proveedor de proxies móviles: soporte de SOCKS5 con resolución remota de nombres, modo HTTP con manejo correcto de CONNECT, estabilidad del DNS del lado del operador, ausencia de sustitución de respuestas DNS en la infraestructura. Es útil aclarar con el soporte a través de qué resolutores se resuelven los nombres en la resolución remota — la respuesta correcta: a través de los resolutores del operador móvil a cuya red está conectado el módem.

Casos y resultados

Caso 1. Granja de cuentas publicitarias y una causa invisible de baneos

Un equipo de afiliados gestionaba unas 120 cuentas publicitarias en proxies móviles a través de un antidetect popular. El promedio de vida de la cuenta hasta el bloqueo se mantenía en 9–12 días con una configuración aparentemente impecable: IP móviles de la región correcta, huellas cuidadas, calentamiento. La auditoría mostró que tras una actualización del antidetect, en el motor había quedado activado el DNS cifrado, y todos los perfiles resolvían nombres a través del mismo resolutor DoH público desde la IP real de la oficina. 120 "usuarios independientes" de distintas ciudades resolvían nombres desde un mismo punto. Tras desactivar DoH, activar DNS remoto y bloquear el puerto 53 con el firewall, el promedio de vida de las cuentas subió a 30+ días, y la proporción de bloqueos tempranos en la primera semana cayó aproximadamente a un tercio. El costo de la corrección: dos horas de trabajo de un especialista.

Caso 2. Scraper de marketplace y precios geolocalizados misteriosos

Un desarrollador recopilaba precios de un gran marketplace por regiones a través de proxies móviles de distintas ciudades. Los datos no coincidían con lo que veían los usuarios reales en esas regiones: parte de los precios y del stock correspondía a otra ciudad completamente distinta. La causa estaba en la cadena de conexión: la biblioteca requests con esquema socks5 sin h. Los nombres se resolvían localmente en la ciudad del desarrollador, el geo-DNS del marketplace devolvía el nodo de su región, y luego las consultas a través del proxy móvil de otra ciudad llegaban a un nodo "ajeno" que entregaba resultados regionales según su propia lógica. El cambio de una letra en la configuración y la adición de una verificación DNS automática al inicio de cada worker restauraron la corrección de los datos. Efecto secundario: bajó la proporción de consultas que el marketplace respondía con captcha — las sesiones se volvieron más consistentes.

Caso 3. Testeo de publicidad para audiencias regionales

Una agencia de marketing verificaba cómo se mostraban los anuncios y landings a usuarios de distintas regiones, trabajando a través de proxies móviles y un navegador Chromium con conexión SOCKS5. Parte de las verificaciones mostraba contenido de una región equivocada. En los logs del dominio de prueba propio de la agencia, los resolutores pertenecían al proveedor de la oficina. El paso al modo HTTP de los mismos proxies móviles, en el que Chromium pasa los nombres mediante CONNECT, más la desactivación de la precarga de páginas, eliminaron la discrepancia. Bonus adicional — resultados de verificación estables sin ejecuciones repetidas ahorraron al equipo alrededor del 15 por ciento del tiempo en auditorías recurrentes.

Caso 4. Multitud de cuentas en redes sociales y caché compartida

El operador de decenas de cuentas en una red social notó que las cuentas que trabajaban el mismo día empezaron a bloquearse por grupos. El análisis mostró dos factores en la capa DNS: el antidetect usaba una caché DNS compartida entre perfiles, y parte de los perfiles estaba en SOCKS5 sin resolución remota. Como resultado, perfiles en proxies de distintas regiones se conectaban a los mismos nodos CDN, y algunos de ellos además resolvían nombres desde una misma IP real. Tras activar el aislamiento de la caché por perfiles y pasar todas las conexiones a DNS remoto, los bloqueos grupales cesaron; en los dos meses siguientes las pérdidas de cuentas volvieron al nivel característico de un trabajo manual cuidadoso.

Conclusión general de los casos

En las cuatro historias los proxies estaban en buen estado. El problema vivía del lado del cliente y costaba semanas de trabajo, presupuestos y cuentas. La corrección cada vez tomaba horas. Esa proporción es un rasgo característico precisamente del dns leak: el problema es invisible sin una verificación especial, pero se corrige fácil si sabes dónde mirar.

FAQ: preguntas complejas sobre las fugas de DNS

Si el sitio no recibe mis consultas DNS, ¿cómo se entera de la fuga?

Por tres vías indirectas. La primera — subdominios de prueba únicos: el sitio puede obligar a tu navegador a resolver un dominio que él mismo controla y ver desde qué resolutor vino la consulta. La segunda — geo-DNS y CDN: si llegas a un nodo destinado a otra región, esa discrepancia con tu IP es visible del lado de la infraestructura. La tercera — EDNS Client Subnet: los resolutores públicos transmiten la subred del cliente a los servidores autoritativos, y esta no coincide con la subred de la conexión. Ninguna de estas vías requiere acceso a tu proveedor.

El proxy móvil resuelve nombres a través del operador. ¿Es bueno o malo?

Es ideal para la verosimilitud. Un abonado real de red celular resuelve nombres a través de los resolutores del operador, y sus conexiones llegan desde direcciones del mismo operador. Cuando tu proxy hace lo mismo, el lado DNS y el lado de la conexión pertenecen a la misma red. Ese es exactamente el estado que debes ver en las pruebas: resolutores del operador, IP del operador, una misma región.

¿En qué es mejor el modo HTTP del proxy móvil que SOCKS5 desde el punto de vista del DNS?

En que en el modo HTTP el nombre del host se pasa al proxy por definición del protocolo — en CONNECT para HTTPS y en la URL para HTTP. El cliente no puede resolver el nombre localmente por accidente, salvo casos exóticos como los scripts PAC. En SOCKS5 la resolución remota es una opción que el cliente debe elegir explícitamente, y muchos clientes no lo hacen por defecto. Si no estás seguro del comportamiento de un navegador o biblioteca concreto, el modo HTTP es más seguro. SOCKS5 es más cómodo para protocolos no HTTP, pero requiere control.

¿Basta con desactivar el DNS seguro en el navegador?

No. Eso cierra un canal — el DoH del navegador. Quedan la resolución local para SOCKS5, la precarga, los servicios en segundo plano, el DoH del sistema en el SO e IPv6. Desactivar el DNS seguro es un paso necesario, pero no suficiente. Suficiente es solo la confirmación mediante un test avanzado y, en el mejor de los casos, el bloqueo del DNS directo a nivel de sistema.

¿Qué hacer si en el test aparecen resolutores que no pertenecen ni a mí ni al operador?

Analizar la cadena. Primero determina la organización por IP: si es un servicio DNS público, busca el DoH activado en el navegador o en el sistema. Si es un hosting desconocido, quizá la infraestructura del proxy usa sus propios resolutores en lugar de los del operador — acláralo con el proveedor. Si es tu proveedor, pero no el resolutor que viste en la línea base — posiblemente es IPv6 u otro adaptador. Cada resolutor inesperado tiene una explicación, y hay que encontrarla, no ignorarla.

¿Afecta el dns leak a la velocidad de trabajo a través del proxy?

Afecta, y a menudo en una dirección inesperada. Con resolución local, el geo-DNS elige un nodo CDN cercano a tu ubicación real, y el tráfico luego va a través de la red móvil de otra región hacia ese nodo — la ruta resulta más larga que lo óptimo. Con resolución remota, el nodo se elige cerca de la salida del proxy, y el camino del proxy al servidor es más corto. Así que una configuración correcta del DNS normalmente no ralentiza, y en varios casos acelera la carga.

¿Cómo verificar el dns leak en escenarios automatizados sin navegador?

La vía más confiable es un dominio de prueba propio. Al iniciar cada worker, el script se dirige a través del proxy a un subdominio único, y tu servidor DNS autoritativo registra desde qué resolutor vino la consulta. El script luego lee el log por API y compara la dirección del resolutor con el rango esperado del operador. Si no hay coincidencia, la sesión no se inicia. Esto convierte la verificación de manual en contractual: el worker no tiene derecho a trabajar hasta que no haya probado la limpieza de su DNS.

¿Cómo cambia el panorama con la difusión de ECH y el DNS cifrado en 2026?

El panorama se mueve hacia "el DNS se vuelve más importante". ECH depende de registros DNS de tipo HTTPS, los navegadores activan el DNS cifrado por defecto, los sistemas operativos añaden DoH y DoQ a nivel de sistema. Para el usuario común esto es una ventaja de privacidad. Para quienes trabajan a través de proxy, significa más tráfico DNS, más clientes DNS independientes dentro del sistema y más puntos donde una consulta puede salir por fuera del proxy. Los sistemas antifraude, por su parte, utilizan cada vez más la consistencia entre el lado DNS y el lado de la conexión como señal. Conclusión: la disciplina en el trabajo con DNS pasa de "deseable" a "obligatoria".

¿Se puede confiar en un antidetect browser que afirma protección contra dns leak?

Confi ar — sí, verificar — obligatorio. La afirmación en el marketing no anula las regresiones tras actualizaciones, las diferencias entre motores y la especifi cidad de tu configuración de proxy. Verifica cada perfil después de crearlo y después de cada actualización del navegador. Un test avanzado toma un minuto, y recuperar una granja quemada toma semanas.

Conclusión: el DNS como base de una sesión limpia

Resumamos. El proxy cambia la dirección desde la que llega la conexión, pero no garantiza que la resolución de nombres vaya por el mismo camino. La consulta DNS se realiza antes de la conexión, y precisamente en ese intervalo nace el dns leak. Para los usuarios de proxies móviles esto es especialmente crítico: todo el valor de una IP móvil está en su parecido con un abonado real, y un abonado real resuelve nombres a través de su operador. La discrepancia entre el lado DNS y el lado de la conexión delata el uso de un proxy con más fiabilidad que muchas otras señales.

Analizamos cómo se fuga el DNS en distintos escenarios: SOCKS sin resolución remota, DNS cifrado en navegadores y sistemas, precarga, caché compartida, IPv6, scripts PAC y resolución previa en el código. Dimos cuatro métodos que funcionan juntos: diagnóstico con línea base y test avanzado, configuración correcta de clientes y bibliotecas, ajuste de navegadores y antidetects, y por último protección forzosa a nivel de firewall y aislamiento de red. Cada método por sí solo cierra parte del problema. Todos juntos — hacen la fuga técnicamente imposible.

Tus próximos pasos

1. Hoy: toma una línea base sin proxy, luego pasa un test avanzado de dns leak en cada perfil de trabajo y en cada script. Anota los resultados.
2. Esta semana: revisa todas las cadenas de conexión en el código por socks5 sin h, desactiva el DNS cifrado y la precarga en los navegadores, asegúrate del aislamiento de la caché entre perfiles.
3. Este mes: bloquea el DNS directo a nivel de sistema para los procesos de trabajo, desactiva o bloquea IPv6 en las interfaces de trabajo, levanta tu propio dominio de prueba con logging.
4. Constantemente: repite la verificación después de cada actualización del navegador, antidetect y bibliotecas. Conviértela en un ritual, como la verificación de IP.

Un buen proxy móvil te da una dirección verosímil y resolutores verosímiles del operador. Tu tarea es no perder esa ventaja en el último metro, dentro de tu propio sistema. Configura el DNS una vez correctamente, haz de la verificación un hábito, y toda una categoría de bloqueos inexplicables simplemente desaparecerá de tu práctica. ¿No fue para eso que leíste esta guía hasta el final?