Você configura um proxy em uma saída alemã, executa sua coleta, e o destino continua servindo conteúdo para a região errada. O endereço de saída se confirma como alemão, as requisições têm sucesso, e ainda assim os resultados parecem ter vindo de onde seu servidor realmente está. Uma causa comum é que a conexão passou pelo proxy, mas a resolução de nome não passou.
Isso é um vazamento de DNS. Em um contexto de privacidade, isso é descrito como seu resolvedor vendo quais domínios você visita, e isso é real, mas para coleta de dados existe uma consequência mais imediata: a resolução de DNS é frequentemente sensível à geografia, então resolver localmente enquanto sai remotamente produz uma incompatibilidade que pode te entregar o endpoint regional errado e silenciosamente contaminar um conjunto de dados com segmentação geográfica.
O que realmente vaza, e por que isso importa aqui
Uma requisição para um hostname envolve dois passos: transformar o nome em um endereço, depois conectar a esse endereço. Um proxy intercepta o segundo passo. Se ele intercepta o primeiro depende inteiramente do seu cliente.
Quando o cliente resolve localmente, a consulta DNS sai da sua própria rede para o seu próprio resolvedor, revelando o domínio ao seu provedor de internet ou operador do resolvedor, e retornando uma resposta calculada para a sua localização.
Essa última parte é o que quebra a coleta. Sites grandes ficam atrás de CDNs e DNS sensível à geografia que retornam endereços diferentes dependendo de onde a consulta veio, então uma busca resolvida localmente pode apontar para um nó de borda perto do seu servidor em vez de perto da sua saída de proxy. Você então conecta a esse nó através de um endereço alemão, e a incompatibilidade pode produzir conteúdo para a região errada, resultados inconsistentes entre execuções, ou um sinal que parece incomum para o destino. Se o seu trabalho depende de segmentação em nível de cidade, esse modo de falha vale a pena descartar primeiro quando a geografia parece errada, junto com as diferenças de banco de dados de geolocalização que são a outra causa comum.
Proxies HTTP raramente vazam, SOCKS5 frequentemente vaza
O comportamento se divide por protocolo, e isso é o cerne do problema.
Com um proxy HTTP, uma requisição HTTPS usa CONNECT e envia o hostname ao proxy, que o resolve remotamente. HTTP simples da mesma forma envia uma URL absoluta contendo o hostname. Em ambos os casos o proxy realiza a busca por design, então o uso comum de proxy HTTP não vaza DNS.
Com SOCKS5, o protocolo suporta ambos. Ele pode aceitar um hostname e resolver remotamente, ou aceitar um endereço que o cliente resolveu por conta própria. Qual dos dois acontece é uma decisão do cliente, e muitos clientes por padrão resolvem localmente. É por isso que o mesmo gateway vaza através de uma configuração e não de outra, e quase sempre é uma configuração do lado do cliente em vez de qualquer coisa relacionada ao proxy.
Na maioria das ferramentas a distinção é um único caractere. socks5:// significa resolver localmente, socks5h:// significa entregar o hostname ao proxy. O h é toda a solução.
Corrigindo por cliente
curl. Use o esquema socks5h, ou --proxy com esse esquema, em vez de socks5:
# vaza: resolve localmente
curl -x socks5://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.com
# correto: hostname resolvido no proxy
curl -x socks5h://customer-USERNAME-country-de:PASSWORD@p.shifter.io:443 https://example.comPython. Com requests e PySocks, o esquema carrega o mesmo significado, e é fácil errar porque ambas as grafias funcionam:
import requests
user = "customer-USERNAME-country-de"
PROXY = f"socks5h://{user}:PASSWORD@p.shifter.io:443" # note o h
r = requests.get("https://example.com",
proxies={"http": PROXY, "https": PROXY}, timeout=20)O mais simples de tudo, use o esquema HTTP contra o mesmo gateway, que resolve remotamente por padrão e evita a questão inteiramente. Essa é a configuração em usando proxies residenciais com Python.
Node. Agentes socks tipicamente expõem uma flag para resolução remota; verifique se ela está ativada em vez de assumir, já que os padrões diferem entre bibliotecas e versões.
Navegadores headless. É aqui que os vazamentos são mais prováveis, porque um navegador tem seu próprio comportamento de resolvedor independente da configuração de proxy. O Chromium resolve através de sua própria pilha e precisa que o caminho de DNS seja restringido explicitamente ao usar SOCKS; o Firefox tem uma preferência controlando se hostnames SOCKS são resolvidos remotamente, e ela nem sempre está ativada por padrão. Se você conduz navegadores, verifique em vez de assumir, e observe os canais de vazamento específicos de navegador abaixo.
Testando se você realmente vaza
Não assuma a partir da configuração. Existem três níveis de verificação.
O mais rápido é comparar o que o destino vê com o que você espera: busque um endpoint que reporta o endereço que ele observou e confirme que corresponde à sua região de saída, depois busque uma página sensível à geografia e confirme que o conteúdo corresponde. Se o endereço está certo mas o conteúdo está errado, DNS é o principal suspeito.
Mais diretamente, observe o tráfego DNS de saída enquanto uma requisição via proxy é executada. Na máquina que faz a requisição, se você ver consultas para o hostname do seu destino saindo pela porta 53, a resolução está acontecendo 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.comSe consultas para o hostname do destino aparecerem na captura, o cliente resolveu localmente e você encontrou o vazamento.
Terceiro, para automação de navegador, use uma das páginas públicas de teste de vazamento de DNS, que reportam os resolvedores que responderam em seu nome, e verifique se eles estão na região da sua saída ou na sua.
Os outros canais de vazamento que vale a pena conhecer
DNS é o comum, mas para completude, três outros produzem a mesma classe de falha.
IPv6. Se o proxy lida apenas com IPv4 e seu sistema prefere IPv6 para um destino de pilha dupla, esse tráfego pode contornar o proxy inteiramente. Desativar IPv6 na máquina que faz a coleta, ou forçar IPv4 no cliente, remove uma categoria inteira de resultados confusos.
WebRTC. Em navegadores reais, o WebRTC pode expor endereços locais e públicos através de um mecanismo separado que ignora as configurações de proxy. Se você está conduzindo um navegador para qualquer coisa sensível a identidade, desative-o.
Padrões de sistema e biblioteca. Alguns runtimes fazem cache agressivo de resultados de DNS ou consultam o resolvedor do sistema operacional independentemente da configuração de proxy, e uma entrada no arquivo hosts ou um resolvedor de cache local vai sobrescrever tudo o que você configurou.
Se a consistência de identidade importa para o seu trabalho, DNS é uma camada entre várias, e o conjunto mais amplo de sinais que precisam concordar é abordado em fingerprinting de TLS e HTTP/2 e evitando bloqueios.
Uma checklist rápida
Prefira o esquema HTTP contra o gateway a menos que você precise especificamente de SOCKS5, já que ele resolve remotamente por padrão. Se você usa SOCKS5, use socks5h em todo lugar e faça grep no seu código por socks5:// simples para pegar casos esquecidos. Verifique com uma captura de pacotes na porta 53 em vez de confiar na configuração. Force IPv4 se o caminho do seu proxy for apenas IPv4. Desative o WebRTC em navegadores automatizados. Depois execute novamente uma requisição sensível à geografia e confirme que o conteúdo corresponde à região de saída em vez da sua própria.
Conclusão
Um vazamento de DNS significa que seu tráfego passou pelo proxy enquanto a resolução de nome não passou, o que expõe os domínios que você consulta ao seu próprio resolvedor e, mais importante para coleta, os resolve a partir da sua localização em vez da sua saída. Proxying HTTP resolve remotamente por padrão e raramente vaza; SOCKS5 vaza sempre que o cliente resolve localmente, e é por isso que socks5h versus socks5 é a correção mais comum. Navegadores headless precisam de atenção explícita porque resolvem independentemente da sua configuração de proxy. Teste com uma captura de pacotes em vez de confiar na configuração, e descarte IPv6 e WebRTC enquanto está nisso. Quando um trabalho com segmentação geográfica retorna conteúdo para a região errada e o endereço de saída parece correto, isso é a primeira coisa a verificar.
O gateway fala tanto HTTP(S) quanto SOCKS5 no mesmo endpoint, então trocar esquemas para testar não custa nada: veja gateway e autenticação. O produto é proxies residenciais com segmentação por país e cidade e preços por GB.