Contenido del artículo

Imagina la escena. Conectaste un proxy de la región deseada, verificaste la dirección IP: todo correcto, la ciudad y el país coinciden. Pero el sitio web objetivo obstinadamente te muestra contenido diferente, y el sistema antifraude marca la sesión como sospechosa. ¿Te suena? Lo más probable es que te hayas topado con uno de los fenómenos más insidiosos al trabajar con proxies: la fuga de DNS o la ruta incorrecta de resolución del nombre de dominio.

Este artículo es una guía exhaustiva sobre cómo ocurre exactamente la conversión de un nombre de dominio en una dirección IP cuando el tráfico pasa a través de un proxy. Analizaremos en qué se diferencian fundamentalmente los esquemas socks5 y socks5h, quién y en qué etapa envía la solicitud DNS, por qué a veces el sitio web ve una región completamente diferente a la esperada, y cómo configurar la resolución remota en clientes y bibliotecas populares. Es un tema específico, pero terriblemente importante. Es en la resolución de nombres donde se rompen miles de configuraciones que, en apariencia, estaban correctamente ajustadas.

Introducción: ¿por qué el proxy está conectado pero el sitio web ve otra región?

Empecemos con el síntoma que lleva a la mayoría de los lectores a este tema. Configuraste un proxy. La dirección IP está reemplazada correctamente; es fácil verificarlo en cualquier servicio de detección de IP. Y sin embargo, algo sale mal: el sitio web muestra la localización de otro país, la CDN te dirige a un nodo inesperado y, a veces, el sistema de seguridad del recurso objetivo bloquea la solicitud sin motivo aparente.

La razón es casi siempre la misma. Tu tráfico HTTP o de aplicación realmente pasa a través del proxy, pero la solicitud DNS —esa solicitud que convierte un nombre como example.com en una dirección IP concreta— sale fuera del proxy, directamente desde tu máquina. Y esa solicitud te delata por completo.

¿Por qué sucede esto? Porque la resolución del nombre y la transmisión de datos son dos etapas diferentes que pueden seguir rutas distintas. Muchos clientes resuelven el nombre localmente de forma predeterminada y envían a través del proxy una conexión ya preparada con la IP. Desde el punto de vista de la red, es lógico. Desde el punto de vista de la privacidad y la geolocalización, es un desastre.

Al final de este material, entenderás:

  • quién es el que realmente realiza la resolución del nombre: el sistema operativo, la biblioteca de la aplicación, el navegador o el propio servidor proxy;
  • en qué se diferencia el esquema socks5 de socks5h a nivel de protocolo y por qué una sola letra lo cambia todo;
  • cómo el método CONNECT en los proxies HTTP resuelve el problema de la resolución casi automáticamente;
  • por qué canales se produce la fuga de DNS incluso cuando la configuración parece correcta;
  • cómo activar la resolución remota en curl, Python, Node.js, Go, Chrome, Firefox, Selenium y Playwright;
  • cómo verificar la ruta real de resolución con herramientas como dig, nslookup y tcpdump.

Acordemos de inmediato los límites. No discutiremos qué servidor DNS público es mejor ni recomendaremos proveedores concretos. Nuestro tema es exclusivamente la ruta de resolución al trabajar con un proxy. Ni más ni menos.

Fundamentos: ¿qué es la resolución de nombres y quién la realiza?

Para entender las fugas, primero debemos asimilar firmemente la mecánica de la resolución. Vamos por partes.

¿Qué es la resolución de un nombre de dominio?

Las computadoras se comunican mediante direcciones IP; los humanos, mediante nombres. La resolución (del inglés resolve, resolver) es el proceso de convertir un nombre legible por humanos, como shop.example.com, en una dirección IP de máquina como 93.184.216.34. Sin este paso, ninguna conexión es posible: el navegador no sabe a qué servidor conectarse hasta que obtiene la IP.

La resolución es una transacción de red independiente. Normalmente utiliza el protocolo DNS sobre UDP o TCP en el puerto 53. El cliente envía una solicitud al resolvedor, y el resolvedor devuelve una respuesta. El punto clave es: quién exactamente envía esta solicitud y por qué ruta es la cuestión central de todo nuestro tema.

Cuatro posibles ejecutores de la resolución

Cuando una aplicación quiere conectarse a example.com, la resolución puede ser realizada por uno de estos cuatro participantes. Analicemos cada uno.

1. El sistema operativo

La mayoría de las aplicaciones no resuelven nombres por sí mismas. Recurren a la función del sistema —en el mundo C, es getaddrinfo. El SO tiene su propio resolvedor (stub resolver), que sabe a qué servidor DNS consultar, mantiene una caché local y tiene en cuenta el archivo hosts. Es la ruta más común. Y la más peligrosa en términos de fugas: el resolvedor del sistema, por defecto, sale directamente a la red, ignorando tu proxy.

2. La biblioteca de la aplicación

Algunos programas y bibliotecas tienen su propia lógica de resolución, que puede delegar la tarea al SO, realizarla por sí misma o —y esto es lo más importante— transferir el nombre al servidor proxy para que la resolución ocurra en el lado remoto. Este mecanismo es el que implementan los esquemas socks5h y el hosting de proxy.

3. El navegador

Los navegadores modernos son un universo aparte. Tienen su propia política de resolución, su propia caché DNS, mecanismos como DoH (DNS sobre HTTPS), precarga de conexiones y WebRTC. El navegador puede resolver el nombre de forma completamente independiente de la configuración del sistema, lo que da lugar a toda una clase de fugas.

4. El propio servidor proxy

El escenario ideal para la privacidad. El cliente no resuelve el nombre en absoluto. Pasa al servidor proxy una cadena con el nombre del host, y el proxy, por su parte, realiza la resolución y se conecta a la IP deseada. Desde el punto de vista del sitio web objetivo, la solicitud DNS proviene de la red del proxy, no de la tuya.

Analogía clave

Imagina que envías un mensajero (el proxy) con un paquete a otra ciudad. Hay dos formas. La primera: tú mismo averiguas la dirección exacta del destinatario consultando una guía en tu casa, escribes las coordenadas en el paquete y le das al mensajero solo las coordenadas. La guía de tu ciudad puede dar una dirección diferente a la guía de la ciudad de destino, y ni siquiera te darás cuenta. La segunda forma: le das al mensajero solo el nombre del destinatario, y él encuentra la dirección en el lugar, usando la guía local. La segunda forma es la resolución remota. Garantiza que la dirección se determina desde el punto correcto de la red.

socks5 vs socks5h: ¿dónde se toma la decisión de resolución?

Ahora llegamos al corazón del tema. La diferencia entre socks5 y socks5h no es cosmética ni un sinónimo. Son rutas de resolución fundamentalmente diferentes, aunque el protocolo SOCKS5 subyacente es el mismo.

¿Qué dice el protocolo SOCKS5?

El protocolo SOCKS5 en sí mismo es flexible. En el comando de establecimiento de conexión, el cliente indica el tipo de dirección de destino. Son posibles tres opciones:

  • Dirección IPv4: el cliente pasa una IP ya resuelta;
  • Dirección IPv6: igual, pero para IPv6;
  • Nombre de dominio: el cliente pasa una cadena con el nombre, y entonces la resolución debe realizarla el servidor proxy.

Es decir, el protocolo en sí mismo admite tanto la resolución local como la remota. La cuestión es qué tipo de dirección enviará el cliente. Y aquí entra en juego el convenio de nomenclatura de los esquemas.

Esquema socks5: resolución local

Cuando un cliente utiliza el esquema socks5 (sin la letra h), según la convención establecida, significa: resolver el nombre localmente. El cliente primero consulta a su resolvedor (normalmente el del sistema) cuál es la IP de example.com, obtiene la dirección y luego pasa al servidor proxy una IPv4 o IPv6 ya preparada.

¿Qué ve el sitio web objetivo? Ve una conexión desde el proxy, eso es correcto. Pero la solicitud DNS salió desde tu red, desde tu lado, a través de tu resolvedor local. Si tu resolvedor está geográfica o lógicamente vinculado a tu región, la infraestructura objetivo, a través de la CDN y la geolocalización DNS, puede determinar tu región real, no la del proxy. De ahí el síntoma de la introducción.

Esquema socks5h: resolución remota

La letra h en socks5h significa hostname: nombre de host. Este esquema le dice al cliente: no resuelvas tú mismo, pasa el nombre al servidor proxy. El cliente envía un comando con el tipo de dirección nombre de dominio, y el servidor proxy realiza la resolución en su lado.

¿Qué ve ahora el sitio web objetivo? La solicitud DNS proviene del resolvedor que utiliza el proxy, es decir, desde la red del proxy. La geolocalización por DNS apunta a la región del proxy. Tu resolvedor local no se utiliza en absoluto y no sabe nada sobre a dónde vas. Este es el camino correcto y limpio para la mayoría de las tareas.

Tabla comparativa de la mecánica

Resumamos las diferencias de forma compacta:

  • socks5: la resolución la realiza el cliente (SO/biblioteca). El proxy recibe la IP. La solicitud DNS sale de tu red. Posible desincronización geográfica y fuga.
  • socks5h: la resolución la realiza el proxy. El proxy recibe el nombre. La solicitud DNS sale de la red del proxy. La región es consistente, no hay fuga.

Recuerda la regla simple: si la privacidad y la corrección de la geolocalización son importantes, usa siempre socks5h. Una sola letra ahorra horas de depuración.

¿Por qué esta convención?

Un apunte histórico es útil para entender. Originalmente, los clientes SOCKS resolvían por sí mismos, porque las primeras versiones del protocolo (SOCKS4) no podían transmitir nombres. SOCKS5 añadió soporte para nombres de dominio, pero el ecosistema de herramientas introdujo el sufijo h para distinguir explícitamente el comportamiento. Así nació el par socks5 / socks5h, que hoy entienden curl, Python y muchos clientes HTTP. Es un estándar de nomenclatura de facto, no parte de una RFC.

Proxies HTTP y HTTPS: por qué el método CONNECT resuelve en el proxy

SOCKS no es el único tipo de proxy. Una enorme cantidad de tareas laborales utilizan proxies HTTP. Aquí la mecánica de resolución es diferente y, en muchos casos, más favorable.

Solicitud HTTP normal a través de un proxy

Cuando accedes a un recurso HTTP (sin cifrado) a través de un proxy HTTP, el cliente envía al proxy una solicitud completa con una URL absoluta. La línea de solicitud contiene el nombre del host. El proxy ve el nombre, lo resuelve por sí mismo y se conecta al servidor. Es decir, en el proxy HTTP normal, la resolución ocurre naturalmente en el lado del proxy. El cliente no necesita conocer la IP.

Método CONNECT para HTTPS

Con HTTPS todo es más interesante. El tráfico cifrado el proxy no puede leerlo —ni debe. Por eso, para HTTPS se utiliza un método especial llamado CONNECT. El cliente envía al proxy un comando como CONNECT example.com:443. Observa: aquí se transmite el nombre del host, no la IP.

¿Qué sucede después? El servidor proxy recibe el nombre, lo resuelve en su lado, abre un túnel TCP hacia la IP de destino y se convierte en un tubo transparente. Dentro de ese tubo, se realiza el handshake TLS completo entre tu cliente y el servidor de destino —el proxy no lo descifra.

Conclusión clave: con una implementación correcta de un proxy HTTP con método CONNECT, la resolución es remota por defecto. El nombre va al proxy, el proxy resuelve por sí mismo. Esta es una de las razones por las que los proxies HTTP para tráfico HTTPS a menudo se comportan más correctamente desde el primer momento que un SOCKS mal configurado.

Salvedad sobre la optimización del cliente

Hay un matiz importante. Algunos clientes, buscando optimizar la conexión, resuelven el nombre localmente antes de enviar el CONNECT y luego pasan en el CONNECT la dirección IP en lugar del nombre. Formalmente, esto es permitido, pero anula todo el beneficio de la resolución remota. Por lo tanto, incluso con un proxy HTTP, no debes confiar ciegamente en el comportamiento: hay que verificarlo. Hablaremos de los métodos de verificación en una sección aparte.

Proxy HTTPS como término independiente

No confundas los dos significados. A veces, proxy HTTPS significa un proxy que proxifica tráfico HTTPS (a través de CONNECT). Y otras veces, significa un proxy cuya conexión con el cliente está cifrada mediante TLS (es decir, el canal cliente-proxy está protegido). Son cosas diferentes. Desde el punto de vista de la resolución, lo más importante es lo primero: cómo se transmite el nombre de destino. El cifrado del canal hacia el proxy no afecta directamente la ruta de resolución, aunque protege el hecho mismo de la transmisión del nombre de un observador entre tú y el proxy.

Fugas de DNS: mecánica de aparición y escenarios típicos

Ahora viene lo más interesante: la anatomía de las fugas. Una fuga de DNS es una situación en la que la solicitud DNS sale sin pasar por el proxy, revelando tu resolvedor real, tu región o el simple hecho de que has accedido a un dominio concreto. Analicemos los escenarios uno por uno, porque cada uno requiere su propio tratamiento.

Escenario 1: resolvedor del sistema sin pasar por el proxy

El caso más frecuente. Configuraste la aplicación para usar socks5 (sin h), o el cliente no admite resolución remota. La aplicación llama a getaddrinfo del sistema, el SO envía la solicitud DNS a su resolvedor directamente a través de la red, sin pasar por el proxy. Luego los datos van a través del proxy, pero el nombre ya se ha filtrado.

Cómo reconocerlo: en el proxy llegan conexiones por IP, no por nombre. En el volcado de red de tu máquina se ven paquetes salientes al puerto 53 que no están encapsulados en el túnel del proxy.

Tratamiento: cambiar a socks5h, activar la resolución remota en el cliente, o aislar la aplicación para que no tenga acceso directo a la red para DNS.

Escenario 2: WebRTC en el navegador

WebRTC es una tecnología en tiempo real para audio, vídeo y transferencia de datos directamente entre navegadores. Para establecer la conexión, WebRTC utiliza el mecanismo ICE, que recopila candidatos —incluyendo la resolución de hosts de servidores STUN— y puede iniciar solicitudes que van más allá del proxy configurado. Históricamente, WebRTC era conocido por revelar direcciones reales incluso con un proxy funcionando. Aunque los navegadores modernos han endurecido significativamente las políticas, el riesgo persiste si la configuración no es cuidadosa.

Tratamiento: controlar la política de WebRTC en el navegador, deshabilitar o limitar el procesamiento de candidatos ICE, y utilizar configuraciones del navegador que obliguen a todo el tráfico, incluido WebRTC, a pasar por el proxy.

Escenario 3: DoH incorporado en el navegador

Los navegadores modernos soportan DNS sobre HTTPS (DoH): resolución a través de una solicitud HTTPS cifrada a su propio proveedor de DoH. El problema es que esta solicitud puede ir sin pasar por tu esquema SOCKS, directamente desde la máquina, si el navegador está configurado para resolver mediante su propio DoH y no encapsula ese tráfico en el proxy. Se produce una paradoja: el nombre se resuelve de forma cifrada y privada para el proveedor, pero sin pasar por tu proxy, lo que para tareas de geolocalización es peor. Analizaremos este mecanismo en detalle en la sección sobre DoH.

Escenario 4: ruta IPv6 paralela

El escenario más insidioso. Tu proxy funciona sobre IPv4, configuraste la resolución remota. Pero tu máquina tiene IPv6 activo, y el cliente, siguiendo el algoritmo Happy Eyeballs (intentos simultáneos por IPv4 e IPv6), intenta resolver registros AAAA y conectarse por IPv6 directamente, sin pasar por el proxy. Parte del tráfico y el DNS se filtran. La región se desincroniza, la conexión va parcialmente por otro lado.

Tratamiento: deshabilitar IPv6 para la aplicación que usa el proxy, o asegurarse de que el proxy soporte IPv6 y que todo el tráfico, incluida la resolución AAAA, pase a través de él. Para muchas tareas, es más sencillo forzar al cliente a usar solo IPv4.

Escenario 5: caché y precarga

Los navegadores y los SO almacenan en caché el DNS de forma agresiva y establecen conexiones por adelantado (preconnect, prefetch). Si antes de configurar el proxy la caché se llenó, la aplicación puede usar entradas antiguas o conexiones preestablecidas sin pasar por la nueva configuración. Es un detalle, pero en la depuración puede volverte loco.

Tratamiento: limpiar la caché DNS del SO y del navegador, reiniciar, y desactivar la precarga agresiva durante el diagnóstico.

Patrón general de las fugas

¿Notaste el patrón común? Todas las fugas se reducen a una sola cosa: existe un canal por el cual el nombre o la conexión sale sin pasar por el proxy. La tarea del ingeniero es encontrar y cerrar todos esos canales. Una fuga es siempre una puerta abierta, no un misterio.

Práctica por herramientas: cómo activar la resolución remota

Pasemos a la acción. Analicemos clientes concretos y mostremos cómo activar la resolución remota y evitar la local. Esta es la sección más práctica: tenla a mano.

curl: socks5 vs socks5-hostname

curl es la herramienta de referencia para entender la diferencia. Ofrece una elección explícita.

  • --socks5 host:port: resolución local. curl determina la IP por sí mismo y luego pasa por el proxy.
  • --socks5-hostname host:port: resolución remota. curl pasa el nombre al servidor proxy.

A través de la opción --proxy también se puede controlar el esquema: socks5://... da resolución local, y socks5h://... da resolución remota. Ejemplo de llamada correcta para resolución remota: curl --proxy socks5h://user:pass@proxyhost:1080 https://example.com. Para un proxy HTTP, el esquema http://... con método CONNECT resuelve en el proxy por defecto, pero igualmente conviene verificar el comportamiento real.

Python: requests y httpx

En el ecosistema de Python, el esquema socks5h es el estándar de oro para la resolución remota.

Para requests, necesitas el paquete de soporte SOCKS. El proxy se define mediante un diccionario: indica el esquema socks5h://user:pass@host:port para https y http. El esquema socks5:// sin h significa resolución local: es la causa más frecuente de fugas entre los principiantes. Una letra lo decide.

Para httpx, la lógica es análoga: pasa un proxy con esquema socks5h:// para resolución remota. httpx es estricto con los esquemas y documenta bien el comportamiento, pero el principio es el mismo: la letra h cambia la resolución al lado del proxy.

Observación importante: incluso si indicas socks5h, verifica que no se haya activado algún proxy del sistema mediante variables de entorno (HTTP_PROXY, ALL_PROXY) con otro esquema. Las variables de entorno pueden anular tus intenciones.

Node.js

En Node.js, no hay soporte directo de SOCKS en el http estándar. Se utilizan agentes SOCKS que crean la conexión a través del proxy. El parámetro clave de estos agentes es una opción que determina si se resuelve el nombre localmente. En los agentes SOCKS populares, hay una bandera, generalmente llamada algo como lookup o una opción relacionada con DNS: cuando se desactiva la búsqueda local, el nombre se pasa al proxy. Asegúrate de que el agente esté configurado para transmitir el hostname, no para resolverlo previamente mediante dns.lookup.

Consejo práctico: en Node, presta especial atención a que no se llame a dns.resolve o dns.lookup en algún lugar del código antes de establecer la conexión. Esa resolución prematura anula la ruta remota.

Go

En Go, la biblioteca estándar proporciona un paquete para trabajar con proxies. A través de golang.org/x/net/proxy se puede crear un dialer SOCKS5. Por defecto, el comportamiento depende de si le pasas a Dial un nombre o una dirección ya resuelta. La clave es usar el dialer de manera que reciba el nombre de dominio, no el resultado de net.LookupHost. Si tú mismo llamas a la resolución y pasas la IP, eso es resolución local con todas sus consecuencias. El enfoque correcto es pasar al dialer la cadena host:port con el nombre y no resolver previamente.

Chrome: flags de inicio

Chrome se controla mediante flags de línea de comandos y políticas. Para indicar el proxy se usa el flag proxy-server. Es crítico que, al trabajar con SOCKS5, Chrome por defecto puede resolver localmente. Existe un flag que controla que la resolución para las conexiones proxificadas se realice en el lado del proxy; su nombre está relacionado con host-resolver-rules y una configuración que obliga a todos los hosts a pasar por el proxy. También es importante controlar el DoH incorporado: si Secure DNS en el navegador está activo y configurado con su propio proveedor, puede saltarse tu esquema. Para un diagnóstico limpio, Secure DNS se desactiva temporalmente y se endurece la política de WebRTC.

Firefox: ajustes en about:config

Firefox es históricamente más cómodo para controlar la resolución. El ajuste clave es network.proxy.socks_remote_dns. Establécelo en true, y Firefox enviará los nombres de host al proxy SOCKS para su resolución remota en lugar de hacerlo localmente. Es uno de los ajustes más importantes de todo el material. Además, controla:

  • network.trr.mode: el modo DoH (TRR, Trusted Recursive Resolver). Un valor que desactive el DoH forzado es importante si quieres que la resolución solo pase por el proxy.
  • media.peerconnection.enabled: control de WebRTC para evitar fugas a través de ICE.
  • ajustes que deshabiliten IPv6 o la precarga si se observa una ruta paralela.

Selenium

Selenium controla un navegador real, por lo que la lógica de resolución se hereda de Chrome o Firefox. Para Chrome, pasas los mismos flags a través de las opciones de inicio (argumentos proxy-server y los relacionados con la resolución). Para Firefox, configuras un perfil con network.proxy.socks_remote_dns activado mediante el objeto de opciones del perfil. El secreto del éxito: no confíes en los valores por defecto del driver; establece explícitamente la resolución remota en el perfil o los flags y luego verifica la ruta real.

Playwright

Playwright proporciona un parámetro proxy al lanzar un contexto o un navegador. Indicamos server con el esquema (por ejemplo, socks5://host:port) y las credenciales. Aquí hay un detalle: el comportamiento de la resolución depende del motor (Chromium, Firefox, WebKit) y de cómo se implementa la proxificación. Para garantizar la resolución remota en el motor Chromium, combina la configuración del proxy con los argumentos de inicio correspondientes; en el motor Firefox, combínala con la configuración del perfil socks_remote_dns. Siempre finaliza la configuración con una prueba de fuga.

Tabla resumen: cliente, cómo activar la resolución remota, cómo verificar

Aquí está la tabla práctica principal del material:

  • curl: activar: usar --socks5-hostname o esquema socks5h:// en --proxy. Verificar: curl con verbose y observar que se transmite el nombre; volcado de tráfico sin solicitudes directas al puerto 53.
  • Python requests: activar: esquema socks5h:// en el diccionario proxies. Verificar: solicitud a un servicio que muestre la fuente de la resolución; control de variables de entorno.
  • Python httpx: activar: proxy con esquema socks5h://. Verificar: prueba de fuga, análisis de qué resolvedor se ve.
  • Node.js: activar: agente SOCKS con transmisión de hostname, sin dns.lookup previo. Verificar: ausencia de llamadas a dns.resolve antes de la conexión; volcado al puerto 53.
  • Go: activar: dialer SOCKS5, pasar host:port con nombre, sin net.LookupHost previo. Verificar: registro de lo que se envía al dialer; tcpdump.
  • Chrome: activar: proxy-server con SOCKS5, host-resolver-rules hacia el proxy, desactivar Secure DNS durante el diagnóstico. Verificar: test de fuga en línea, comparar región de IP y región de DNS.
  • Firefox: activar: network.proxy.socks_remote_dns en true, controlar network.trr.mode. Verificar: about:networking, test de fuga en línea.
  • Selenium: activar: los mismos flags de Chrome o perfil de Firefox con socks_remote_dns. Verificar: ejecutar test de fuga dentro del navegador controlado.
  • Playwright: activar: parámetro proxy más argumentos del motor para resolución remota. Verificar: navegar a un test de fuga en una sesión automatizada.

DoH y DoT: cómo interactúan con el proxy

DNS sobre HTTPS (DoH) y DNS sobre TLS (DoT) son cifrados de las solicitudes DNS. Por sí mismos, son excelentes para proteger el contenido de la solicitud de un observador. Pero en el contexto de un proxy, generan efectos sutiles que hay que entender.

¿Qué son DoH y DoT en pocas palabras?

DoT encapsula DNS en TLS en un puerto dedicado. DoH oculta la solicitud DNS dentro del tráfico HTTPS normal, haciéndola indistinguible de la navegación web. Ambos protocolos cifran la solicitud. Pero —y esto es crítico— el cifrado de la solicitud no equivale al enrutamiento a través del proxy. Son dimensiones diferentes.

El conflicto clave: DoH del navegador sin pasar por el proxy

Aquí está la idea principal de la sección. Cuando el navegador activa su propio DoH y está configurado para resolver a través de su proveedor, establece una conexión HTTPS hacia el endpoint DoH. La pregunta: ¿esta conexión pasa por tu proxy? A menudo, no. El navegador puede abrir un canal DoH directamente, porque la resolución se percibe como una operación de servicio, independiente de la navegación del usuario.

El resultado es paradójico. Por un lado, la solicitud DNS está cifrada y el proveedor no ve qué dominio estás consultando. Por otro lado, esa solicitud sale desde tu máquina real, desde tu red, sin pasar por el proxy. Para la geolocalización, es un fracaso: la infraestructura objetivo ve la resolución desde tu región, no desde la del proxy. Tu hermoso esquema socks5h se evita porque el navegador no pasó por SOCKS para la resolución; fue por su propio camino DoH.

Cuándo el DoH del navegador rompe tu esquema por completo

Concretemos las situaciones en las que DoH evita el proxy:

  • el navegador está configurado para usar DoH forzado a través de su proveedor, y el proxy solo está definido para el tráfico normal, no para la resolución de servicio;
  • el sistema operativo o la aplicación tiene DoH activado a nivel de SO, y no se encapsula en el túnel;
  • el endpoint DoH está en caché y la conexión se estableció antes de aplicar la configuración del proxy.

Conclusión práctica: para tareas donde la consistencia de la región es importante, al trabajar con un proxy, el DoH del navegador y del sistema debe desactivarse o dirigirse explícitamente a través del mismo proxy. El panorama ideal es que toda la resolución, esté cifrada o no, pase por el servidor proxy (resolución remota), no lo evite.

DoT y el proxy

DoT funciona en un puerto dedicado y es más fácil de manejar mediante políticas de red, pero igualmente puede salir sin pasar por el proxy si no se encapsula explícitamente. Para nuestros fines, el principio es el mismo: controla que la resolución pase por el proxy, no por un canal independiente.

La regla de oro de DoH en el contexto del proxy

Recuerda: el cifrado de la resolución y su enrutamiento a través del proxy son propiedades independientes. Puedes tener una resolución cifrada que, sin embargo, revele completamente tu región porque sale sin pasar por el proxy. Para la consistencia, busca siempre la resolución remota en el proxy, y decide el tema del cifrado por separado y de forma consciente.

Cómo verificar: dig, nslookup, tcpdump y pruebas en línea

Configurar es la mitad del trabajo. Un ingeniero debe verificar que la resolución realmente va por donde se planeó. Analicemos herramientas de diagnóstico, desde las simples hasta las serias.

dig y nslookup a través del proxy

dig y nslookup son utilidades clásicas para resolución manual. El detalle es que el DNS normal funciona sobre UDP, y un proxy SOCKS proxifica TCP de forma nativa. Por lo tanto, verificar la resolución a través del proxy requiere que la solicitud DNS vaya por TCP y que la utilidad sea dirigida a través de un envoltorio SOCKS. En la práctica, para observar el comportamiento, es más conveniente envolver las herramientas mediante programas que encapsulen el tráfico TCP en SOCKS. El sentido de la verificación: asegurarse de que, con la resolución remota, tu máquina local no envía solicitudes DNS por sí misma, sino que solo ve el resultado llegado a través del canal del proxy.

nslookup es útil para una verificación rápida de qué resolvedor responde y qué IP se devuelve. Compara la IP obtenida localmente con la IP a la que realmente se conecta a través del proxy. La discrepancia es un indicador de que la resolución va por caminos diferentes.

tcpdump en el puerto 53: la prueba más honesta

Este es mi método favorito porque no miente. Ejecuta en tu máquina una captura de tráfico con filtro en el puerto 53 (y en el 443 para sospechas de DoH). Luego realiza una solicitud proxificada. La lógica es simple:

  • si con la resolución remota ves paquetes DNS salientes al puerto 53 directamente desde tu máquina, tienes una fuga: la resolución es local;
  • si el puerto 53 está en silencio y todo el tráfico va hacia el túnel del proxy, la resolución remota funciona correctamente;
  • si el puerto 53 está en silencio, pero hay conexiones HTTPS sospechosas hacia endpoints DoH conocidos sin pasar por el proxy, tienes una fuga a través de DoH.

tcpdump muestra la realidad física de la red, no las declaraciones de los archivos de configuración. Por eso es indispensable en la verificación final.

Prueba de fuga en línea: cómo leer el resultado correctamente

Existen servicios web que muestran qué resolvedor realizó tu solicitud DNS y desde qué región. La clave para leer correctamente el resultado es no confundir dos parámetros:

  • tu IP visible: es la IP desde la que llegó la conexión HTTP, es decir, la IP del proxy;
  • el resolvedor DNS: es la dirección y región de quien realmente realizó la resolución.

La imagen correcta con resolución remota: tanto la IP visible como el resolvedor apuntan a la región del proxy. Una señal de alarma: la IP visible es de la región del proxy, pero el resolvedor es de tu región real. Esa es una fuga clásica por resolución local. Otra variante de fuga: el resolvedor pertenece a un gran proveedor de DoH, pero la conexión hacia él fue sin pasar por el proxy; entonces la región del resolvedor puede ser neutral, pero la ruta igualmente no pasa por el proxy, lo que se ve ya con tcpdump.

Lista de verificación de la resolución

Recorre los puntos secuencialmente:

  1. Limpia la caché DNS del SO y del navegador; reinicia la aplicación.
  2. Asegúrate de que el esquema sea socks5h o que la resolución remota esté activada en el cliente.
  3. Verifica las variables de entorno del proxy en busca de esquemas conflictivos.
  4. Ejecuta tcpdump con filtro en los puertos 53 y 443.
  5. Realiza una solicitud proxificada a un recurso de prueba.
  6. Confirma que no hay paquetes DNS directos al puerto 53.
  7. Verifica la ausencia de conexiones HTTPS independientes hacia endpoints DoH.
  8. Abre una prueba de fuga en línea y compara la región de la IP con la región del resolvedor.
  9. Verifica la ruta IPv6: que no haya solicitudes AAAA ni conexiones paralelas.
  10. Documenta la configuración de referencia en la documentación del equipo.

    11. Errores típicos que casi todos cometen

    A lo largo de los años trabajando con proxies, se acumula una colección de rastrillos. Analicemos los más frecuentes para que no tropieces con ellos.

    Error 1: confundir socks5 y socks5h

    El líder absoluto. Alguien escribe socks5:// y está seguro de que la resolución es remota. Pero es local. Una letra h que falta y toda la región se desincroniza. Indica siempre explícitamente socks5h si necesitas resolución remota, y verifícalo con un volcado.

    Error 2: configurar el proxy pero olvidar el DoH

    Un clásico en los navegadores. El proxy está configurado, pero el Secure DNS / DoH incorporado está activo y va sin pasar por él. El usuario ve la IP correcta y se calma, mientras la resolución se filtra. Siempre sincroniza la política de DoH con el proxy.

    Error 3: ignorar IPv6

    El proxy está en IPv4, pero la máquina tiene pila doble. Happy Eyeballs hace su trabajo y parte de las conexiones van directamente por IPv6. O desactivas IPv6 para la aplicación, o te aseguras de que el proxy atienda completamente IPv6.

    Error 4: resolución local previa en el código

    Un problema frecuente en Node.js y Go. El desarrollador, con la mejor intención, llama a la resolución antes (para verificar, para registrar) y pasa al proxy la IP. La resolución remota muere. No resuelvas el nombre antes de pasarlo al dialer del proxy.

    Error 5: confiar en las variables de entorno

    HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY: saboteadores silenciosos. Anulan la configuración en el código o entran en conflicto con el esquema. Verifica el entorno antes de ejecutar y limpia lo innecesario.

    Error 6: creer en la configuración sin verificarla

    Escribiste la línea correcta y seguiste adelante. Pero la configuración es una intención, no un hecho. El comportamiento real solo se verifica con un volcado de tráfico y una prueba de fuga. Nunca termines la configuración sin verificación.

    Error 7: caché DNS olvidada

    Cambias la configuración, pero el resultado sigue siendo el mismo porque las entradas antiguas y las conexiones están en caché. Siempre limpia la caché y reinicia antes de probar.

    Error 8: mezclar tipos de proxy en un mismo pipeline

    En un lugar, un proxy HTTP con CONNECT; en otro, SOCKS con resolución local. El comportamiento de la resolución difiere y parte de las solicitudes se filtran. Unifica el enfoque en todo el pipeline.

    Error 9: no tener en cuenta la caché de la aplicación

    Algunas aplicaciones mantienen su propia caché DNS y un pool de conexiones que sobreviven a un cambio de configuración. A veces es necesario reiniciar el proceso.

    Error 10: ignorar WebRTC en la automatización

    En la automatización de navegadores, a menudo se olvida WebRTC. El navegador controlado puede iniciar ICE y revelar rutas sin pasar por el proxy. Siempre controla la política de WebRTC en las sesiones automatizadas.

    Herramientas y recursos para trabajar con la resolución a través de proxy

    Reunamos un arsenal que debes tener a mano. Los dividimos por propósito.

    Herramientas de diagnóstico

    • tcpdump: captura de tráfico de red, el juez supremo de la verdad sobre las rutas de resolución.
    • Wireshark: análisis gráfico de paquetes, útil para casos complejos con DoH e IPv6.
    • dig y nslookup: resolución manual, verificación rápida de las respuestas del resolvedor.
    • Pruebas de fuga DNS en línea: muestran el resolvedor y su región, dan un veredicto rápido.
    • about:networking en Firefox: diagnóstico incorporado de conexiones y DNS del navegador.

    Herramientas y bibliotecas para la configuración

    • curl: referencia para probar el comportamiento de socks5 y socks5-hostname, ideal para depuración.
    • Envoltorios SOCKS para tráfico TCP: permiten encapsular una aplicación arbitraria en SOCKS para pruebas de resolución.
    • Bibliotecas SOCKS para lenguajes: paquetes de soporte SOCKS en Python, agentes SOCKS en Node.js, paquete proxy en Go.
    • Herramientas de automatización de navegadores: Selenium y Playwright con configuración explícita de proxy y resolución.

    Recursos de conocimiento

    • Documentación oficial de curl sobre opciones de proxy: la mejor fuente primaria sobre la semántica de socks5 vs socks5h.
    • Documentación de los clientes HTTP de Python sobre trabajo con proxies y esquemas.
    • Referencias de about:config de Firefox sobre parámetros de red y resolución.
    • Documentación de tu proveedor de proxy, en particular el servicio MobileProxy.space, donde se describen los esquemas soportados y recomendaciones sobre resolución remota para proxies móviles.

    Mini marco de decisión para elegir el enfoque

    Para no perderte, ten esta lógica simple de decisión:

    1. ¿Necesitas tráfico HTTPS y resolución remota? Proxy HTTP con CONNECT o SOCKS5 con esquema socks5h.
    2. ¿Trabajas desde una biblioteca o CLI? Indica explícitamente socks5h o el flag de resolución remota.
    3. ¿Trabajas desde un navegador? Activa la resolución remota, desactiva o dirige el DoH a través del proxy, limita WebRTC e IPv6.
    4. Siempre finaliza la configuración con un volcado de tráfico y una prueba en línea.

      5. Casos y resultados: cómo se ve en la práctica

      La teoría sin práctica está muerta. Analicemos casos generalizados que reflejan situaciones típicas. Las cifras son condicionales, pero las proporciones y la lógica provienen de la práctica real de ingeniería.

      Caso 1: desincronización de región en un analista de datos

      Un equipo recopilaba datos mediante un script de Python con un proxy de la región deseada. Los resultados llegaban con la localización de otro país en aproximadamente el cuarenta por ciento de los casos. El diagnóstico mostró el esquema socks5:// en el diccionario proxies: resolución local. El cambio a socks5h:// eliminó la desincronización por completo. tcpdump confirmó: las solicitudes directas al puerto 53 desaparecieron. Lección: una letra resolvió un problema en el que se habían invertido dos días.

      Caso 2: fuga a través de DoH del navegador en automatización

      Al automatizar Chromium con Playwright, la región IP era correcta, pero el recurso objetivo determinaba obstinadamente otra región. Una prueba en línea mostró un resolvedor que no coincidía con la región del proxy. Wireshark reveló conexiones HTTPS independientes a un endpoint DoH sin pasar por el proxy. Solución: desactivar Secure DNS en la configuración de lanzamiento y forzar la resolución remota. Tras el ajuste, la región del resolvedor coincidió con la región de la IP, y las falsas detecciones de antifraude se redujeron drásticamente.

      Caso 3: IPv6 paralelo en un microservicio

      Un servicio en Go se conectaba a través de SOCKS5, pero periódicamente parte de las solicitudes iban directamente. La causa era la pila doble y los intentos por IPv6 sin pasar por el proxy. Limitar el cliente solo a IPv4 y transmitir correctamente el nombre en el dialer eliminó la fuga. tcpdump dejó de mostrar solicitudes AAAA directas. La estabilidad de la región aumentó hasta casi el cien por cien.

      Caso 4: variables de entorno saboteadoras

      Un script se comportaba de manera diferente en dos máquinas con código idéntico. En una funcionaba la resolución remota; en la otra, no. La revelación: en la máquina problemática estaba definida la variable ALL_PROXY con un esquema sin h, que anulaba la configuración. Tras limpiar el entorno, el comportamiento se volvió consistente. Lección: el entorno es parte de la configuración; hay que controlarlo tan estrictamente como el código.

      Conclusión general de los casos

      Observa el patrón. En todos los casos, el síntoma era similar —región incorrecta o activación de protección—, pero las causas eran diferentes: esquema, DoH, IPv6, entorno. Por eso, el diagnóstico mediante una lista de verificación es más importante que la intuición. Un enfoque sistemático encuentra la raíz más rápido que las conjeturas.

      Preguntas frecuentes (FAQ)

      ¿En qué se diferencian socks5 y socks5h en palabras simples?

      socks5 resuelve el nombre de dominio en tu lado y envía al proxy la IP ya lista. socks5h envía al proxy el nombre mismo, y la resolución la realiza el proxy. Para privacidad y geolocalización correcta, casi siempre necesitas socks5h. La letra h significa hostname: el nombre del host se transmite de forma remota.

      Si uso un proxy HTTP, ¿debo preocuparme por la resolución?

      Con HTTPS a través del método CONNECT, normalmente el nombre va al proxy y él resuelve, lo cual es bueno. Pero algunos clientes resuelven localmente antes y pasan la IP en el CONNECT. Por lo tanto, incluso con un proxy HTTP, verifica el comportamiento real con un volcado de tráfico.

      ¿Por qué la IP es correcta pero el sitio web ve otra región?

      Casi con toda seguridad, tu solicitud DNS va sin pasar por el proxy —a través de un resolvedor local o del DoH del navegador. La infraestructura objetivo, mediante la geolocalización DNS y la CDN, determina la región de tu resolvedor, no la del proxy. El tratamiento es la resolución remota y el control del DoH.

      ¿Cómo se relaciona WebRTC con la resolución y las fugas?

      WebRTC, para establecer conexiones, recopila candidatos de red y puede iniciar solicitudes que van sin pasar por el proxy. Esto puede revelar rutas y direcciones. Al trabajar con un proxy, especialmente en automatización de navegadores, la política de WebRTC debe controlarse o limitarse.

      ¿El DoH rompe mi configuración de proxy?

      Puede romperla. El cifrado de la resolución y su enrutamiento a través del proxy son cosas diferentes. El DoH del navegador o del sistema puede ir directamente, sin pasar por el proxy, revelando tu región. Para consistencia, desactiva ese DoH o dirige la resolución a través del proxy.

      ¿Cómo puedo verificar rápidamente si hay una fuga?

      Dos pasos. Primero, ejecuta tcpdump con filtro en el puerto 53 y realiza una solicitud proxificada: los paquetes DNS directos significan fuga. Segundo, abre una prueba en línea y compara la región de la IP visible con la región del resolvedor. Coinciden: bien; divergen: fuga.

      ¿Qué hago con IPv6 si el proxy solo está en IPv4?

      O desactivas IPv6 para la aplicación que usa el proxy, o te aseguras de que el proxy atienda IPv6 y que todo el tráfico, incluida la resolución AAAA, pase a través de él. De lo contrario, el algoritmo Happy Eyeballs enviará parte de las conexiones directamente, sin pasar por el proxy.

      ¿Por qué el mismo código se comporta de manera diferente en dos máquinas?

      Una causa frecuente son las variables de entorno del proxy (HTTP_PROXY, ALL_PROXY y similares). Anulan la configuración en el código o establecen un esquema diferente. Verifica y limpia el entorno para que el comportamiento sea consistente.

      ¿Es suficiente indicar socks5h para garantizar que no haya fugas?

      Para la aplicación en sí, es un gran paso adelante, pero no es una garantía para todo el sistema. Quedan canales como el DoH del navegador, WebRTC e IPv6. La protección completa es la resolución remota más el control de todos los canales alternativos más la verificación obligatoria con volcado.

      ¿Se puede resolver a través de un proxy en la línea de comandos para probar?

      Sí. curl con la opción --socks5-hostname o el esquema socks5h es la forma más simple de probar la resolución remota. Para utilidades como dig, es conveniente encapsular el tráfico TCP en SOCKS, recordando que el DNS clásico sobre UDP no se proxifica de forma nativa a través de SOCKS.

      Conclusión: resumen y próximos pasos

      Hemos recorrido el camino desde el síntoma hasta una comprensión profunda. Recopilemos lo principal en un marco conceptual compacto que te quedará.

      La resolución de un nombre de dominio es una transacción de red independiente que puede seguir una ruta diferente a la de tu tráfico principal. Esa independencia es la que genera la mayoría de los problemas. La resolución puede ser realizada por cuatro actores: el sistema operativo, la biblioteca de la aplicación, el navegador y el propio proxy. Tu objetivo es casi siempre delegar la resolución al servidor proxy para que el nombre se determine desde el punto correcto de la red.

      La diferencia entre socks5 y socks5h es fundamental. socks5: resolución local; socks5h: resolución remota. Una letra lo cambia todo: región, privacidad, consistencia. Los proxies HTTP con método CONNECT, por naturaleza, transmiten el nombre al proxy, pero tampoco hay que confiar ciegamente: verifica.

      Las fugas se reducen a un principio: existe un canal por el cual el nombre sale sin pasar por el proxy. El resolvedor del sistema, WebRTC, el DoH del navegador, IPv6 paralelo, la caché: esos son los principales sospechosos. Y recuerda la idea clave: el cifrado de la resolución no equivale a su enrutamiento a través del proxy. Puedes tener un DoH cifrado que, sin embargo, revele completamente tu región.

      ¿Qué hacer ahora mismo? Aquí tienes tu plan de acción:

      1. Revisa tus configuraciones actuales y cambia socks5 a socks5h donde necesites resolución remota.
      2. Verifica los navegadores: activa la resolución remota, resuelve la política de DoH y WebRTC.
      3. Asegúrate de que IPv6 no cree una ruta paralela sin pasar por el proxy.
      4. Limpia las variables de entorno del proxy de valores conflictivos.
      5. Realiza la verificación mediante tcpdump y una prueba en línea siguiendo la lista de verificación del artículo.
      6. Documenta la configuración de referencia en la documentación del equipo para que no tengan que reinventar la rueda.

      El tema de la resolución a través de proxy parece específico, pero es donde se rompen las configuraciones más costosas y frustrantes. Ahora tienes un mapa del terreno: entiendes quién resuelve, dónde se toma la decisión, cómo ocurren las fugas y cómo cerrarlas. Guarda este material en favoritos y vuelve a la tabla y las listas de verificación cada vez que el proxy esté conectado pero el sitio web obstinadamente vea otra región. Ahora sabes dónde buscar.

      Sobre el autor

      Andrey Kokh

      Andrey Kokh

      Leading Expert and Business Consultant

      Experiencia laboral: Leading expert with 12 years of experience. Consults Forbes-listed companies, author of 3 books. Teaches at HSE and SKOLKOVO. His methodologies are used by hundreds of companies across Russia. RBC and Forbes expert on strategic development and digital transformation.
      Formación académica: Higher School of Economics. Faculty of Economics, Master's Program
      Especialización:
      Strategic Consulting Digital Transformation Change Management Business Strategy Innovation Management Organizational Development Lean Management Agile Transformation

      Comparte el artículo: