SOCKS5 vs SOCKS5h: corrigiendo la fuga de DNS en Python, curl, Selenium

Ha configurado un proxy SOCKS5, el tráfico parece pasar a través de él, la IP en el navegador se muestra correctamente, pero los sitios aún ven su región real o el proveedor comienza a sospechar algo. La razón casi siempre es la misma: las solicitudes DNS se envían directamente desde su computadora, omitiendo el proxy. En este artículo, analizaremos por qué sucede esto, en qué se diferencia SOCKS5 de SOCKS5h y cómo cerrar esta fuga en el código y en herramientas listas para usar.

Qué es SOCKS5 y en qué se diferencia de SOCKS5h

SOCKS5 es un protocolo de proxy que opera a nivel de conexiones TCP/UDP y no analiza el contenido de los paquetes, a diferencia de los proxies HTTP(S). Esto lo hace versátil: a través de SOCKS5 se puede proxificar prácticamente cualquier tráfico: navegador, Telegram, cliente torrent, script en Python. Pero la implementación clásica de SOCKS5 tiene una característica importante: la resolución de nombres de dominio (DNS) se realiza por defecto del lado del cliente, es decir, en su computadora, y no en el servidor proxy.

SOCKS5h es el mismo protocolo, pero con el modificador "h" (hostname), que indica a la aplicación cliente que no resuelva el dominio por sí misma, sino que lo envíe tal cual al servidor proxy, y será el proxy quien realice la solicitud DNS en su nombre. La diferencia está en una letra, pero las consecuencias para la anonimidad y la estabilidad de funcionamiento son fundamentales.

Es importante entender: SOCKS5h no es un protocolo separado, sino un acuerdo a nivel de una biblioteca o aplicación específica sobre cómo formar la solicitud al proxy. El propio servidor proxy funciona de la misma manera en ambos casos, la única diferencia es quién inicia la resolución DNS: el cliente o el servidor.

Por qué las solicitudes DNS evitan el proxy

Cuando accede a una dirección como https://example.com, antes de establecer la conexión, la aplicación debe averiguar la dirección IP de ese dominio. Este proceso se llama resolución DNS. Al trabajar a través de un SOCKS5 normal, muchas bibliotecas y configuraciones del sistema realizan la resolución a través del servidor DNS del sistema, es decir, el que está configurado en la red de su proveedor o en el router.

Como resultado, se produce una situación paradójica: el tráfico HTTP/TCP se envía a través del proxy y parece que la solicitud proviene de la IP del servidor proxy, mientras que la solicitud DNS "¿Cuál es la IP de example.com?" se envía directamente desde su IP real al servidor DNS del proveedor. Esto es lo que se conoce como fuga de DNS (DNS leak). Un sitio o servicio que analiza la actividad de red a un nivel más profundo (y estos métodos de detección son utilizados activamente por sistemas antifraude de Facebook, Google, TikTok) puede ver una discrepancia entre la IP de la conexión y la fuente de la solicitud DNS.

La razón es que el protocolo SOCKS5 fue diseñado originalmente como un nivel de transporte para conexiones IP ya establecidas, y no para la resolución de nombres. A los desarrolladores de bibliotecas y utilidades les ha tocado implementar por separado la función de transmisión de solicitudes DNS a través del túnel; de ahí surgió SOCKS5h como una indicación clara de "resuelve el dominio tú mismo, no yo".

Cuáles son los peligros de una fuga de DNS en la práctica

Para un desarrollador de un parser o un script de automatización, la fuga de DNS no es una teoría abstracta, sino una razón concreta para bloqueos y baneos de cuentas. Analicemos algunos escenarios.

Parsing de marketplaces y sitios web. Si está parseando Wildberries, Ozon u otro recurso a través de un proxy de la región correcta, pero las solicitudes DNS se envían a través del proveedor, el sistema anti-bots puede detectar la discrepancia de geolocalización y aumentar el nivel de sospecha de la sesión, hasta el punto de un captcha o un bloqueo temporal de la IP del proxy.

Multi-cuentas y arbitraje de tráfico. Al trabajar con Facebook Ads, TikTok Ads o Google Ads a través de varias cuentas, los sistemas antifraude analizan decenas de parámetros, incluida la huella DNS. Si las solicitudes DNS de varias "diferentes" cuentas de repente pasan por el mismo servidor DNS del proveedor, esto es una señal para agrupar cuentas en un solo clúster, y como consecuencia, una cadena de baneos (chain-ban).

Automatización en Selenium/Playwright. Los scripts que emulan las acciones del usuario en el navegador son especialmente vulnerables: el propio navegador puede resolver DNS a través de la configuración del sistema operativo, ignorando el proxy configurado solo para el tráfico HTTP. Como resultado, toda la otra huella de red revela la ubicación real.

Para la mayoría de estas tareas, es crítico utilizar proxies residenciales con la resolución DNS correctamente configurada del lado del servidor; esto reduce significativamente el riesgo de detección por características de red.

Cómo comprobar si hay una fuga de DNS

Antes de arreglar el problema, es conveniente asegurarse de que realmente existe. Aquí hay algunas formas rápidas de comprobarlo.

Abra el sitio dnsleaktest.com o ipleak.net a través de su conexión proxy y ejecute la prueba extendida (Extended test).
Compare la lista de servidores DNS en los resultados con lo que realmente es su proveedor de internet. Si ve el proveedor en lugar del centro de datos del proxy, la fuga está confirmada.
Para la línea de comandos, use la combinación tcpdump o Wireshark, filtrando el tráfico por el puerto 53 (DNS); si los paquetes van directamente al servidor del proveedor, y no a través del túnel del proxy, el problema está de su lado.
En Python, se puede comprobar rápidamente la resolución manualmente a través de socket.getaddrinfo() antes y después de activar el proxy; si la IP coincide con el resultado sin proxy, la resolución se está realizando localmente.

Corrección en Python (requests, PySocks, urllib3)

El error más común en los scripts de Python es el uso de la biblioteca requests junto con PySocks sin especificar explícitamente el esquema socks5h. La diferencia está en un solo carácter, pero es precisamente ese carácter el que decide quién resuelve el dominio.

import requests

# MALO: DNS se resuelve localmente, omitiendo el proxy
proxies_leak = {
    "http": "socks5://user:pass@proxy_host:1080",
    "https": "socks5://user:pass@proxy_host:1080",
}

# BUENO: DNS se resuelve en el servidor proxy
proxies_safe = {
    "http": "socks5h://user:pass@proxy_host:1080",
    "https": "socks5h://user:pass@proxy_host:1080",
}

response = requests.get("https://example.com", proxies=proxies_safe, timeout=10)
print(response.status_code)
print(response.text[:200])

Para que el esquema socks5h funcione correctamente a través de requests, necesitará instalar la dependencia:

pip install "requests[socks]" PySocks

Si está utilizando urllib3 a bajo nivel directamente, el ejemplo se verá así:

from urllib3.contrib.socks import SOCKSProxyManager

proxy = SOCKSProxyManager(
    "socks5h://user:pass@proxy_host:1080",
    num_pools=10
)

response = proxy.request("GET", "https://example.com")
print(response.status)

Para scripts asíncronos en aiohttp, se utiliza la biblioteca aiohttp-socks, donde el esquema se especifica de la misma manera:

import aiohttp
from aiohttp_socks import ProxyConnector

connector = ProxyConnector.from_url("socks5h://user:pass@proxy_host:1080")

async def fetch():
    async with aiohttp.ClientSession(connector=connector) as session:
        async with session.get("https://example.com") as resp:
            print(await resp.text())

Corrección en curl

En curl también hay dos banderas diferentes para el proxy SOCKS5, y la confusión entre ellas es una causa clásica de fuga de DNS en scripts bash.

# MALO: resolución en la máquina local
curl --socks5 proxy_host:1080 https://example.com

# BUENO: resolución en el servidor proxy
curl --socks5-hostname proxy_host:1080 https://example.com

# Con autorización
curl --socks5-hostname user:pass@proxy_host:1080 https://example.com

La bandera --socks5-hostname es el análogo directo de socks5h en otras herramientas. Le dice a curl: "no toques DNS, simplemente pasa el dominio al servidor proxy tal como está".

Corrección en Selenium y Playwright

Con la automatización del navegador, la situación es más complicada: Chrome o Firefox por defecto pueden resolver DNS a través de la configuración del sistema, ignorando el proxy que se ha configurado solo a nivel de la solicitud de red. Para Selenium con Chrome, es necesario habilitar explícitamente la resolución a través del proxy utilizando una bandera de inicio del navegador.

from selenium import webdriver
from selenium.webdriver.chrome.options import Options

options = Options()
options.add_argument("--proxy-server=socks5://proxy_host:1080")
# Bandera crítica: resolver DNS a través del proxy
options.add_argument("--host-resolver-rules=MAP * ~NOTFOUND , EXCLUDE proxy_host")

driver = webdriver.Chrome(options=options)
driver.get("https://example.com")

En Playwright, la situación es más sencilla: la biblioteca resuelve DNS a través del proxy por defecto, si se especifica en la configuración del contexto del navegador.

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={"server": "socks5://proxy_host:1080"}
    )
    page = browser.new_page()
    page.goto("https://example.com")
    print(page.title())
    browser.close()

Sin embargo, se recomienda siempre verificar el comportamiento real a través de dnsleaktest.com después de la configuración; el comportamiento puede variar entre versiones de Chromium.

Configuración en navegadores anti-detección

Si no está escribiendo código, sino que trabaja a través de navegadores anti-detección como Dolphin Anty, AdsPower, Multilogin o GoLogin, la buena noticia es que la mayoría de ellos ya resuelven DNS a través del servidor proxy automáticamente al elegir el protocolo SOCKS5, sin necesidad de especificar "h" manualmente. Esta es una de sus principales ventajas sobre los scripts personalizados.

Sin embargo, vale la pena comprobar esto en la práctica: abra un perfil en el navegador anti-detección, vaya a dnsleaktest.com y ejecute la prueba extendida directamente dentro del perfil. Si ve servidores DNS que corresponden a la región de su proxy y no a su proveedor real, la configuración es correcta. Si no, comuníquese con el soporte del navegador anti-detección específico o cambie el tipo de proxy a HTTP(S), donde el problema de resolución de DNS no surge tan agudamente, ya que el proxy HTTP siempre trabaja con URL completas.

Para la creación de cuentas en Instagram, TikTok y la gestión de cuentas publicitarias en Facebook Ads, los proxies móviles funcionan muy bien; gracias a la rotación dinámica de IP de los operadores de telefonía móvil, son menos sospechosos para los sistemas antifraude, incluso si en algún lugar de la cadena ocurrió una pequeña fuga de DNS.

Tabla de comparación de protocolos de proxy

Protocolo	Quién resuelve DNS	Riesgo de fuga	Dónde aplicar
SOCKS5	Cliente (su computadora)	Alto	Solo si DNS no es crítico (pruebas locales)
SOCKS5h	Servidor proxy	Bajo	Parsing, multi-cuentas, automatización
Proxy HTTP/HTTPS	Servidor proxy (por defecto)	Bajo	Tráfico web, navegadores, solicitudes API

Si su tarea es la recopilación de datos de alta velocidad sin vinculación a una región específica del usuario, considere los proxies de centros de datos; son más baratos en términos de volumen de tráfico y funcionan muy bien en combinación con SOCKS5h para el parsing, donde la velocidad es más importante que la ocultación como un usuario residencial.

Lista de verificación antes de lanzar el proyecto

Utilice el esquema socks5h://, y no socks5:// en todas las bibliotecas y configuraciones.
Para curl, use la bandera --socks5-hostname, y no --socks5.
En Selenium, se ha añadido la bandera --host-resolver-rules o se utiliza Playwright con resolución de proxy incorporada.
Verifique el resultado en dnsleaktest.com o ipleak.net después de la configuración, y no antes.
En el navegador anti-detección, pruebe la huella DNS dentro del perfil, y no solo la IP externa.
Para tareas con altos requisitos de anonimato, considere proxies residenciales o móviles en lugar de proxies de centros de datos.

Conclusión

La diferencia entre SOCKS5 y SOCKS5h es literalmente una letra, pero esta decide quién resuelve la solicitud DNS: su computadora o el servidor proxy. La fuga de DNS es una de las causas más sutiles, pero a la vez frecuentes de detección al hacer parsing, multi-cuentas y automatización de cuentas publicitarias. La verificación a través de dnsleaktest.com y la especificación explícita del esquema socks5h en el código, comandos curl o configuraciones de automatización del navegador cierra esta brecha en unos minutos.

Si está eligiendo la infraestructura para la tarea, para el parsing y el trabajo con API, los proxies de centros de datos son más adecuados; para multi-cuentas y redes sociales, los proxies residenciales; y para una huella de red lo más natural posible al trabajar con aplicaciones móviles, los proxies móviles. En cualquiera de estos casos, la configuración correcta de la resolución DNS a través de SOCKS5h sigue siendo un paso obligatorio antes de lanzar el proyecto en producción.