Configuras un proxy en una salida alemana, ejecutas tu recolección, y el destino sigue sirviéndote contenido de la región equivocada. La dirección de salida se confirma como alemana, las peticiones tienen éxito, y aun así los resultados parecen provenir de donde realmente está tu servidor. Una causa habitual es que la conexión pasó por el proxy pero la resolución de nombres no lo hizo.
Esto es una fuga de DNS. En un contexto de privacidad se describe como que tu resolver ve qué dominios visitas, y eso es real, pero para la recolección de datos hay una consecuencia más inmediata: la resolución DNS a menudo tiene en cuenta la geografía, por lo que resolver localmente mientras se sale de forma remota produce un desajuste que puede entregarte el endpoint regional equivocado y contaminar silenciosamente un conjunto de datos geolocalizado.
Qué se filtra realmente, y por qué importa aquí
Una petición a un nombre de host implica dos pasos: convertir el nombre en una dirección y luego conectarse a esa dirección. Un proxy intercepta el segundo paso. Que intercepte también el primero depende por completo de tu cliente.
Cuando el cliente resuelve localmente, la consulta DNS sale de tu propia red hacia tu propio resolver, revelando el dominio a tu ISP o al operador del resolver, y devolviendo una respuesta calculada para tu ubicación.
Esa última parte es lo que rompe la recolección. Los sitios grandes se apoyan en CDN y en DNS con conciencia geográfica que devuelven direcciones distintas según de dónde venga la consulta, así que una búsqueda resuelta localmente puede apuntar a un nodo edge cercano a tu servidor en lugar de a uno cercano a la salida de tu proxy. Luego te conectas a ese nodo a través de una dirección alemana, y el desajuste puede producir contenido para la región equivocada, resultados inconsistentes entre ejecuciones, o una señal que resulta inusual para el destino. Si tu trabajo depende del targeting a nivel de ciudad, este modo de fallo merece descartarse primero cuando la geografía se ve mal, junto con las diferencias entre bases de datos de geolocalización, que son la otra causa habitual.
Los proxies HTTP rara vez tienen fugas, SOCKS5 a menudo sí
El comportamiento se divide por protocolo, y esto es el núcleo del problema.
Con un proxy HTTP, una petición HTTPS usa CONNECT y envía el nombre de host al proxy, que lo resuelve de forma remota. El HTTP simple, de manera similar, envía una URL absoluta que contiene el nombre de host. En ambos casos el proxy realiza la búsqueda por diseño, así que el uso ordinario de un proxy HTTP no filtra DNS.
Con SOCKS5, el protocolo admite ambas cosas. Puede aceptar un nombre de host y resolverlo de forma remota, o aceptar una dirección que el cliente ya resolvió por su cuenta. Cuál de las dos ocurre es una decisión del cliente, y muchos clientes resuelven localmente por defecto. Por eso la misma puerta de enlace filtra en una configuración y no en otra, y casi siempre es un ajuste del lado del cliente y no algo relacionado con el proxy.
En la mayoría de las herramientas la distinción es un solo carácter. socks5:// significa resolver localmente, socks5h:// significa entregar el nombre de host al proxy. La h es toda la solución.
Solucionarlo por cliente
curl. Usa el esquema socks5h, o --proxy con ese esquema, en lugar de socks5:
# filtra: resuelve localmente
curl -x socks5://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.com
# correcto: el nombre de host se resuelve en el proxy
curl -x socks5h://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.comPython. Con requests y PySocks, el esquema conlleva el mismo significado, y es fácil equivocarse porque ambas grafías funcionan:
import requests
user = "customer-USERNAME-country-de"
PROXY = f"socks5h://{user}:PASSWORD@p.shifter.io:443" # nótese la h
r = requests.get("https://example.com",
proxies={"http": PROXY, "https": PROXY}, timeout=20)Lo más sencillo de todo es usar el esquema HTTP contra la misma puerta de enlace, que resuelve de forma remota por defecto y evita la cuestión por completo. Esa es la configuración en usar proxies residenciales con Python.
Node. Los agentes socks normalmente exponen un indicador para la resolución remota; comprueba que esté activado en lugar de asumirlo, ya que los valores por defecto difieren entre librerías y versiones.
Navegadores headless. Aquí es donde las fugas son más probables, porque un navegador tiene su propio comportamiento de resolución independiente del ajuste del proxy. Chromium resuelve a través de su propia pila y necesita que la ruta DNS se restrinja explícitamente al usar SOCKS; Firefox tiene una preferencia que controla si los nombres de host SOCKS se resuelven de forma remota, y no siempre está activada por defecto. Si controlas navegadores, verifica en lugar de asumir, y ten en cuenta los canales de fuga específicos del navegador mencionados más abajo.
Comprobar si realmente hay fuga
No lo des por hecho a partir de la configuración. Hay tres niveles de comprobación.
El más rápido es comparar lo que ve el destino con lo que esperas: llama a un endpoint que informe de la dirección que observó y confirma que coincide con tu región de salida, luego llama a una página sensible a la geografía y confirma que el contenido coincide. Si la dirección es correcta pero el contenido no lo es, el DNS es el principal sospechoso.
De forma más directa, vigila el tráfico DNS saliente mientras se ejecuta una petición con proxy. En la máquina que hace la petición, si ves consultas para el nombre de host de tu destino saliendo por el puerto 53, la resolución está ocurriendo localmente:
# terminal 1
sudo tcpdump -n -i any port 53
# terminal 2
curl -x socks5h://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.comSi aparecen consultas para el nombre de host del destino en la captura, el cliente resolvió localmente y has encontrado la fuga.
En tercer lugar, para la automatización de navegadores, usa una de las páginas públicas de prueba de fuga de DNS, que informan de los resolvers que respondieron en tu nombre, y comprueba si se encuentran en la región de tu salida o en la tuya.
Los otros canales de fuga que conviene conocer
El DNS es el habitual, pero para completar, otros tres producen la misma clase de fallo.
IPv6. Si el proxy solo maneja IPv4 y tu sistema prefiere IPv6 para un destino de doble pila, ese tráfico puede saltarse el proxy por completo. Desactivar IPv6 en la máquina que hace la recolección, o forzar IPv4 en el cliente, elimina toda una categoría de resultados confusos.
WebRTC. En navegadores reales, WebRTC puede exponer direcciones locales y públicas mediante un mecanismo aparte que ignora los ajustes del proxy. Si estás controlando un navegador para algo sensible a la identidad, desactívalo.
Valores por defecto del sistema y de las librerías. Algunos runtimes almacenan en caché los resultados DNS de forma agresiva o consultan el resolver del sistema operativo independientemente de la configuración del proxy, y una entrada en el archivo hosts o un resolver de caché local anulará todo lo que hayas configurado.
Si la consistencia de la identidad importa para tu trabajo, el DNS es una capa entre varias, y el conjunto más amplio de señales que deben concordar se cubre en fingerprinting de TLS y HTTP/2 y en cómo evitar bloqueos.
Una lista de comprobación rápida
Prefiere el esquema HTTP contra la puerta de enlace a menos que necesites específicamente SOCKS5, ya que resuelve de forma remota por defecto. Si usas SOCKS5, usa socks5h en todas partes y busca en tu código apariciones sueltas de socks5:// para detectar rezagados. Verifica con una captura de paquetes en el puerto 53 en lugar de confiar en la configuración. Fuerza IPv4 si tu ruta de proxy es solo IPv4. Desactiva WebRTC en los navegadores automatizados. Luego vuelve a ejecutar una petición sensible a la geografía y confirma que el contenido coincide con la región de salida y no con la tuya.
La conclusión
Una fuga de DNS significa que tu tráfico pasó por el proxy mientras la resolución de nombres no lo hizo, lo que expone a tu propio resolver los dominios que consultas y, más importante para la recolección, los resuelve desde tu ubicación en lugar de desde tu salida. El proxying HTTP resuelve de forma remota por defecto y rara vez tiene fugas; SOCKS5 filtra siempre que el cliente resuelve localmente, por lo que socks5h frente a socks5 es la solución más habitual. Los navegadores headless necesitan atención explícita porque resuelven de forma independiente al ajuste de tu proxy. Prueba con una captura de paquetes en lugar de confiar en la configuración, y descarta IPv6 y WebRTC de paso. Cuando un trabajo geolocalizado devuelve contenido para la región equivocada y la dirección de salida parece correcta, esto es lo primero que hay que comprobar.
La puerta de enlace habla tanto HTTP(S) como SOCKS5 en el mismo endpoint, así que cambiar de esquema para probar no cuesta nada: consulta puerta de enlace y autenticación. El producto son los proxies residenciales con targeting por país y ciudad y precios por GB.