SOCKS5 vs SOCKS5h: corrigindo vazamento de DNS em Python, curl, Selenium

Você configurou um proxy SOCKS5, o tráfego parece estar passando por ele, o IP no navegador é o correto — mas os sites ainda conseguem ver sua região real ou o provedor começa a suspeitar de algo. A razão é quase sempre a mesma: as solicitações DNS estão indo diretamente do seu computador, ignorando o proxy. Neste artigo, vamos discutir por que isso acontece, como SOCKS5 se diferencia de SOCKS5h e como corrigir essa vazamento no código e em ferramentas prontas.

O que é SOCKS5 e como ele se diferencia de SOCKS5h

SOCKS5 é um protocolo de proxy que opera no nível de conexões TCP/UDP e não analisa o conteúdo dos pacotes, ao contrário dos proxies HTTP(S). Isso o torna versátil: através do SOCKS5, é possível proxyar praticamente qualquer tráfego — navegador, Telegram, cliente torrent, script em Python. Mas a implementação clássica do SOCKS5 tem uma característica importante: a resolução de nomes de domínio (DNS) é realizada por padrão do lado do cliente, ou seja, no seu computador, e não no lado do servidor proxy.

SOCKS5h é o mesmo protocolo, mas com o modificador “h” (hostname), que indica ao aplicativo cliente para não resolver o domínio por conta própria, mas enviá-lo como está para o servidor proxy, que então executará a solicitação DNS em seu nome. A diferença está em uma letra, mas as consequências para a anonimidade e a estabilidade do funcionamento são fundamentais.

É importante entender: SOCKS5h não é um protocolo separado, mas um acordo no nível de uma biblioteca ou aplicativo específico sobre como formar a solicitação ao proxy. O próprio servidor proxy funciona da mesma forma em ambos os casos, a diferença está apenas em quem inicia a resolução DNS — o cliente ou o servidor.

Por que as solicitações DNS ignoram o proxy

Quando você acessa um endereço como https://example.com, antes de estabelecer a conexão, o aplicativo precisa descobrir o endereço IP desse domínio. Esse processo é chamado de resolução DNS. Ao trabalhar através de um SOCKS5 comum, muitas bibliotecas e configurações do sistema realizam a resolução através do servidor DNS do sistema — aquele que está configurado nas configurações de rede do seu provedor ou roteador.

Como resultado, ocorre uma situação paradoxal: o tráfego HTTP/TCP vai através do proxy e parece que a solicitação veio do IP do servidor proxy, enquanto a solicitação DNS “Qual é o IP de example.com?” vai diretamente do seu IP real para o servidor DNS do provedor. Isso é o que chamamos de vazamento de DNS (DNS leak). Um site ou serviço que analisa a atividade de rede em um nível mais profundo (e esses métodos de detecção são amplamente utilizados por sistemas antifraude como Facebook, Google, TikTok) pode ver a discrepância entre o IP da conexão e a origem da solicitação DNS.

A razão é que o protocolo SOCKS5 foi originalmente desenvolvido como um nível de transporte para conexões IP já estabelecidas, e não para resolução de nomes. Os desenvolvedores de bibliotecas e utilitários tiveram que implementar separadamente a função de transmissão de solicitações DNS através do túnel — daí surgiu o SOCKS5h como uma indicação clara de “resolva o domínio você mesmo, e não eu”.

Quais são os perigos de um vazamento de DNS na prática

Para um desenvolvedor de parser ou script de automação, um vazamento de DNS não é uma teoria abstrata, mas uma razão concreta para bloqueios e banimentos de contas. Vamos analisar alguns cenários.

Parsing de marketplaces e sites. Se você está fazendo scraping de Wildberries, Ozon ou outro recurso através de um proxy da região correta, mas as solicitações DNS estão indo através do provedor, o sistema anti-bot pode detectar a discrepância de geolocalização e aumentar o nível de suspeita da sessão — chegando até a captcha ou bloqueio temporário do IP do proxy.

Multi-contas e arbitragem de tráfego. Ao trabalhar com Facebook Ads, TikTok Ads ou Google Ads através de várias contas, os sistemas antifraude analisam dezenas de parâmetros, incluindo a impressão digital DNS. Se as solicitações DNS de várias contas “diferentes” de repente estão indo através do mesmo servidor DNS do provedor, isso é um sinal para agrupar contas em um único cluster — e, como consequência, uma cadeia de banimentos (chain-ban).

Automação em Selenium/Playwright. Scripts que emulam ações do usuário no navegador são especialmente vulneráveis: o próprio navegador pode resolver DNS através das configurações do sistema operacional, ignorando o proxy configurado apenas para tráfego HTTP. Como resultado, toda a outra impressão digital da rede revela a localização real.

Para a maioria dessas tarefas, é crítico usar proxies residenciais com resolução DNS corretamente configurada do lado do servidor — isso reduz significativamente o risco de detecção por sinais de rede.

Como verificar se há vazamento de DNS

Antes de corrigir o problema, é importante garantir que ele realmente exista. Aqui estão algumas maneiras rápidas de verificar.

Acesse o site dnsleaktest.com ou ipleak.net através da sua conexão proxy e inicie o teste avançado (Extended test).
Compare a lista de servidores DNS nos resultados com o que realmente é o seu provedor de internet. Se você vê o provedor em vez do data center do proxy — o vazamento está confirmado.
Para a linha de comando, use a combinação tcpdump ou Wireshark, filtrando o tráfego pela porta 53 (DNS) — se os pacotes estão indo diretamente para o servidor do provedor, e não através do túnel proxy, o problema está do seu lado.
No Python, você pode rapidamente verificar a resolução manualmente através de socket.getaddrinfo() antes e depois de ativar o proxy — se o IP coincidir com o resultado sem proxy, a resolução está ocorrendo localmente.

Correção em Python (requests, PySocks, urllib3)

O erro mais comum em scripts Python é usar a biblioteca requests em conjunto com PySocks sem especificar explicitamente o esquema socks5h. A diferença está em um único caractere, mas é ele que decide quem resolve o domínio.

import requests

# RUIM: DNS é resolvido localmente, ignorando o proxy
proxies_leak = {
    "http": "socks5://user:pass@proxy_host:1080",
    "https": "socks5://user:pass@proxy_host:1080",
}

# BOM: DNS é resolvido do lado do 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 o funcionamento correto do esquema socks5h através de requests, será necessário instalar a dependência:

pip install "requests[socks]" PySocks

Se você estiver usando a biblioteca de baixo nível urllib3 diretamente, o exemplo será assim:

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 assíncronos em aiohttp, usa-se a biblioteca aiohttp-socks, onde o esquema é especificado da mesma forma:

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())

Correção em curl

No curl, também existem duas bandeiras diferentes para proxies SOCKS5, e a confusão entre elas é uma razão clássica para vazamentos de DNS em scripts bash.

# RUIM: resolução na máquina local
curl --socks5 proxy_host:1080 https://example.com

# BOM: resolução do lado do servidor proxy
curl --socks5-hostname proxy_host:1080 https://example.com

# Com autenticação
curl --socks5-hostname user:pass@proxy_host:1080 https://example.com

A bandeira --socks5-hostname é o equivalente direto de socks5h em outras ferramentas. Ela informa ao curl: “não mexa no DNS, apenas passe o domínio para o servidor proxy como está”.

Correção em Selenium e Playwright

Com a automação do navegador, a situação é mais complicada: o próprio Chrome ou Firefox pode resolver DNS por padrão através das configurações do sistema, ignorando o proxy configurado apenas no nível da solicitação de rede. Para Selenium com Chrome, é necessário habilitar explicitamente a resolução através do proxy usando uma bandeira de inicialização do navegador.

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

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

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

No Playwright, a situação é mais simples: a biblioteca resolve DNS através do proxy por padrão, se ele estiver especificado na configuração do contexto do 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()

No entanto, é sempre recomendável verificar o comportamento real através do dnsleaktest.com após a configuração — o comportamento pode variar entre as versões do Chromium.

Configuração em navegadores anti-detect

Se você não está escrevendo código, mas trabalhando através de navegadores anti-detect como Dolphin Anty, AdsPower, Multilogin ou GoLogin — a boa notícia é que a maioria deles já resolve DNS através do servidor proxy automaticamente ao escolher o protocolo SOCKS5, sem a necessidade de especificar “h” manualmente. Esta é uma das suas principais vantagens em relação a scripts personalizados.

No entanto, é importante verificar isso na prática: abra um perfil no navegador anti-detect, vá para dnsleaktest.com e inicie o teste avançado diretamente dentro do perfil. Se você vê servidores DNS correspondentes à região do seu proxy, e não ao seu provedor real — a configuração está correta. Se não, entre em contato com o suporte do navegador anti-detect específico ou mude o tipo de proxy para HTTP(S), onde o problema de resolução de DNS não ocorre tão agudamente, pois o proxy HTTP sempre trabalha com URLs completas.

Para a criação de contas no Instagram, TikTok e gerenciamento de contas de anúncios no Facebook Ads, proxies móveis se destacam — devido à rotação dinâmica de IPs de operadores de telefonia, eles raramente levantam suspeitas de sistemas antifraude, mesmo que em algum lugar da cadeia tenha ocorrido um pequeno vazamento de DNS.

Tabela de comparação de protocolos de proxy

Protocolo	Quem resolve DNS	Risco de vazamento	Onde aplicar
SOCKS5	Cliente (seu computador)	Alto	Apenas se DNS não for crítico (testes locais)
SOCKS5h	Servidor proxy	Baixo	Scraping, multi-contas, automação
Proxy HTTP/HTTPS	Servidor proxy (por padrão)	Baixo	Tráfego web, navegadores, solicitações de API

Se sua tarefa é coletar dados em alta velocidade sem estar vinculado a uma região específica do usuário, considere proxies de data center — eles são mais baratos em termos de volume de tráfego e funcionam muito bem em conjunto com SOCKS5h para scraping, onde a velocidade é mais importante do que se disfarçar como um usuário residencial.

Checklist antes de iniciar o projeto

Use o esquema socks5h://, e não socks5:// em todas as bibliotecas e configurações.
Para curl, use a bandeira --socks5-hostname, e não --socks5.
No Selenium, a bandeira --host-resolver-rules foi adicionada ou o Playwright está sendo usado com resolução de proxy embutida.
Verifique o resultado em dnsleaktest.com ou ipleak.net após a configuração, e não antes.
No navegador anti-detect, teste a impressão digital DNS dentro do próprio perfil, e não apenas o IP externo.
Para tarefas com altas exigências de anonimato, considere proxies residenciais ou móveis em vez de proxies de data center.

Conclusão

A diferença entre SOCKS5 e SOCKS5h é literalmente uma letra, mas ela determina quem resolve a solicitação DNS: seu computador ou o servidor proxy. O vazamento de DNS é uma das causas mais discretas, mas frequentes de detecção ao fazer scraping, multi-contas e automação de contas de anúncios. Verificações através do dnsleaktest.com e a especificação explícita do esquema socks5h no código, comandos curl ou configurações de automação de navegador fecham essa brecha em poucos minutos.

Se você está apenas escolhendo a infraestrutura para a tarefa — para scraping e trabalho com API, proxies de data center são mais adequados, para multi-contas e redes sociais — proxies residenciais, e para uma impressão digital de rede o mais natural possível ao trabalhar com aplicativos móveis — proxies móveis. Em qualquer um desses casos, a configuração correta da resolução DNS através do SOCKS5h continua sendo um passo obrigatório antes de lançar o projeto em produção.