Sumário do artigo

Imagine a cena. Você conectou um proxy da região desejada, verificou o endereço IP – está tudo certo, cidade e país coincidem. Mas o site alvo teima em mostrar um conteúdo diferente, e o sistema antifraude marca a sessão como suspeita. Familiar? Muito provavelmente você esbarrou em um dos fenômenos mais traiçoeiros ao trabalhar com proxies: o vazamento de DNS ou o caminho errado de resolução do nome de domínio.

Este artigo é um guia completo sobre como exatamente ocorre a conversão do nome de domínio em endereço IP quando o tráfego passa por um proxy. Vamos detalhar as diferenças fundamentais entre os esquemas socks5 e socks5h, quem e em que etapa envia a consulta DNS, por que o site às vezes enxerga uma região completamente diferente da esperada e como configurar a resolução remota nos clientes e bibliotecas mais populares. É um tema específico, mas extremamente importante. É justamente na resolução de nomes que milhares de configurações aparentemente corretas vão por água abaixo.

Introdução: por que o proxy está conectado, mas o site vê outra região

Vamos começar pelo sintoma que leva a maioria dos leitores a este tema. Você configurou o proxy. O endereço IP foi substituído corretamente – é fácil verificar em qualquer serviço de identificação de IP. Mesmo assim, algo está errado: o site exibe a localização de outro país, a CDN o direciona para um nó inesperado e, às vezes, o sistema de segurança do recurso alvo bloqueia a requisição sem motivo aparente.

A causa é quase sempre a mesma. Seu tráfego HTTP ou de aplicação realmente passa pelo proxy, mas a consulta DNS – aquela que transforma um nome como example.com em um endereço IP específico – sai fora do proxy, diretamente da sua máquina. E essa consulta entrega você de bandeja.

Por que isso acontece? Porque a resolução do nome e a transmissão dos dados são duas etapas distintas, que podem seguir rotas diferentes. Muitos clientes, por padrão, resolvem o nome localmente e enviam pelo proxy apenas a conexão já pronta com o IP. Do ponto de vista da rede, é lógico. Do ponto de vista da privacidade e geolocalização, é um desastre.

Ao final deste material, você entenderá:

  • quem exatamente executa a resolução do nome – o sistema operacional, a biblioteca da aplicação, o navegador ou o próprio servidor proxy;
  • como o esquema socks5 difere do socks5h no nível do protocolo e por que uma única letra muda tudo;
  • como o método CONNECT em proxies HTTP resolve o problema da resolução quase que automaticamente;
  • por quais canais o DNS vaza mesmo com uma configuração aparentemente correta;
  • como habilitar a resolução remota em curl, Python, Node.js, Go, Chrome, Firefox, Selenium e Playwright;
  • como verificar o caminho real da resolução com ferramentas como dig, nslookup e tcpdump.

Vamos combinar desde já os limites. Não discutiremos qual servidor DNS público é melhor, nem recomendaremos provedores específicos. Nosso assunto é exclusivamente o caminho da resolução ao trabalhar com proxy. Nem mais, nem menos.

Fundamentos: o que é resolução de nome e quem a executa

Para entender os vazamentos, primeiro precisamos dominar a mecânica da resolução. Vamos dividir em partes.

O que é resolução de nome de domínio

Computadores se comunicam por endereços IP, e humanos por nomes. Resolução (do inglês resolve, resolver) é o processo de converter um nome legível por humanos, como shop.example.com, em um endereço IP de máquina, como 93.184.216.34. Sem essa etapa, nenhuma conexão é possível: o navegador não sabe a qual servidor se conectar até obter o IP.

A resolução é uma transação de rede separada. Normalmente, usa o protocolo DNS sobre UDP ou TCP na porta 53. O cliente envia uma consulta ao resolvedor, e o resolvedor devolve a resposta. O ponto crucial: quem exatamente envia essa consulta e por qual rota é a questão central de todo o nosso tema.

Quatro possíveis executores da resolução

Quando uma aplicação deseja se conectar a example.com, a resolução pode ser feita por um dos quatro participantes. Vamos analisar cada um.

1. Sistema operacional

A maioria das aplicações não resolve nomes por conta própria. Elas chamam a função do sistema – no mundo C, é getaddrinfo. O SO tem seu próprio resolvedor (stub resolver), que sabe a qual servidor DNS recorrer, mantém um cache local e leva em conta o arquivo hosts. Esse é o caminho mais comum. E o mais perigoso em termos de vazamentos: o resolvedor do sistema, por padrão, sai direto para a rede, ignorando seu proxy.

2. Biblioteca da aplicação

Alguns programas e bibliotecas têm lógica própria de resolução, que pode delegar a tarefa ao SO, executá-la por conta própria ou – e isso é o mais importante – enviar o nome para o servidor proxy, para que a resolução ocorra no lado remoto. Esse mecanismo é justamente o que implementam os esquemas socks5h e o proxy-hosting.

3. Navegador

Navegadores modernos são um universo à parte. Eles têm sua própria política de resolução, cache DNS próprio, mecanismos como DoH (DNS over HTTPS), pré-carregamento de conexões e WebRTC. O navegador pode resolver o nome de forma totalmente independente das configurações do sistema, gerando toda uma classe de vazamentos.

4. O próprio servidor proxy

O cenário ideal para a privacidade. O cliente nem sequer resolve o nome. Ele envia ao servidor proxy uma string com o nome do host, e o proxy, do seu lado, executa a resolução e se conecta ao IP desejado. Do ponto de vista do site alvo, a consulta DNS veio da rede do proxy, não da sua.

Analogia-chave

Imagine que você está enviando um entregador (proxy) com um pacote para outra cidade. Existem duas maneiras. A primeira: você mesmo descobre o endereço exato do destinatário consultando uma lista telefônica em sua casa, escreve as coordenadas no pacote e entrega ao entregador apenas as coordenadas. A lista telefônica da sua cidade pode dar um endereço diferente da lista telefônica da cidade de destino – e você nem percebe. A segunda maneira: você dá ao entregador apenas o nome do destinatário, e ele encontra o endereço já no local, usando a lista telefônica local. A segunda maneira é a resolução remota. Ela garante que o endereço seja determinado a partir do ponto correto da rede.

socks5 vs socks5h: onde a decisão de resolução é tomada

Agora chegamos ao coração do tema. A diferença entre socks5 e socks5h não é cosmética nem sinônimo. São caminhos de resolução fundamentalmente diferentes, embora o protocolo SOCKS5 por baixo seja o mesmo.

O que diz o protocolo SOCKS5

O protocolo SOCKS5 é flexível por si só. No comando de estabelecimento de conexão, o cliente especifica o tipo de endereço de destino. Existem três opções:

  • Endereço IPv4 – o cliente envia um IP já resolvido;
  • Endereço IPv6 – o mesmo, mas para IPv6;
  • Nome de domínio – o cliente envia uma string com o nome, e então a resolução é obrigação do servidor proxy.

Ou seja, o próprio protocolo suporta tanto a resolução local quanto a remota. A questão é apenas qual tipo de endereço o cliente enviará. E é aqui que entra a convenção de nomenclatura dos esquemas.

Esquema socks5: resolução local

Quando um cliente usa o esquema socks5 (sem a letra h), por convenção estabelecida significa: resolver o nome localmente. O cliente primeiro pergunta ao seu resolvedor (normalmente o do sistema) qual é o IP de example.com, obtém o endereço e depois envia ao servidor proxy um IPv4 ou IPv6 já pronto.

O que o site alvo vê? Ele vê a conexão vindo do proxy – isso está correto. Mas a consulta DNS saiu da sua rede, do seu lado, através do seu resolvedor local. Se o seu resolvedor estiver geográfica ou logicamente vinculado à sua região, a infraestrutura alvo, por meio de CDN e geolocalização DNS, pode determinar exatamente a sua região, e não a do proxy. Daí o sintoma da introdução.

Esquema socks5h: resolução remota

A letra h em socks5h significa hostname – nome do host. Esse esquema diz ao cliente: não resolva você mesmo, envie o nome para o servidor proxy. O cliente envia um comando com o tipo de endereço nome de domínio, e o servidor proxy executa a resolução do seu lado.

O que o site alvo vê agora? A consulta DNS vem do resolvedor que o proxy utiliza, ou seja, da rede do proxy. A geolocalização via DNS aponta para a região do proxy. Seu resolvedor local não é acionado e não sabe nada sobre para onde você está indo. Esse é o caminho correto e limpo para a maioria das tarefas.

Tabela comparativa da mecânica

Vamos reunir as diferenças de forma compacta:

  • socks5: a resolução é feita pelo cliente (SO/biblioteca). O proxy recebe o IP. A consulta DNS sai da sua rede. Possível dessincronização geográfica e vazamento.
  • socks5h: a resolução é feita pelo proxy. O proxy recebe o nome. A consulta DNS sai da rede do proxy. A região é consistente, não há vazamento.

Lembre-se da regra simples: se a privacidade e a correta geolocalização são importantes – sempre use socks5h. Uma letra economiza horas de depuração.

Por que essa convenção existe

Uma breve referência histórica ajuda a entender. Inicialmente, os clientes SOCKS resolviam por conta própria, porque as primeiras versões do protocolo (SOCKS4) não suportavam o envio de nomes. O SOCKS5 adicionou suporte a nomes de domínio, mas o ecossistema de ferramentas introduziu o sufixo h para distinguir explicitamente o comportamento. Assim nasceu o par socks5 / socks5h, que hoje é compreendido por curl, Python, muitos clientes HTTP. É um padrão de nomenclatura de facto, não parte de uma RFC.

Proxy HTTP e HTTPS: por que o método CONNECT resolve no proxy

O SOCKS não é o único tipo de proxy. Uma enorme parcela das tarefas de trabalho usa proxies HTTP. E aqui a mecânica de resolução é diferente, e em muitos casos, mais feliz.

Requisição HTTP comum via proxy

Quando você acessa um recurso HTTP (sem criptografia) através de um proxy HTTP, o cliente envia ao proxy uma requisição completa com a URL absoluta. A linha de requisição contém o nome do host. O proxy vê o nome, resolve por conta própria e se conecta ao servidor. Ou seja, no proxy HTTP comum, a resolução ocorre naturalmente do lado do proxy. O cliente não precisa saber o IP.

Método CONNECT para HTTPS

Com HTTPS a coisa fica mais interessante. O tráfego criptografado não pode ser lido pelo proxy – e nem deve. Por isso, para HTTPS é usado um método especial chamado CONNECT. O cliente envia ao proxy um comando do tipo CONNECT example.com:443. Observe que aqui é passado o nome do host, não o IP.

O que acontece em seguida? O servidor proxy recebe o nome, resolve do seu lado, abre um túnel TCP para o IP de destino e se transforma em um tubo transparente. Dentro desse túnel ocorre o handshake TLS completo entre o seu cliente e o servidor de destino – o proxy não o descriptografa.

Conclusão principal: em uma implementação correta de proxy HTTP com método CONNECT, a resolução é remota por padrão. O nome vai para o proxy, e o proxy resolve por conta própria. Essa é uma das razões pelas quais proxies HTTP para tráfego HTTPS geralmente se comportam de forma mais correta logo de cara do que um SOCKS mal configurado.

Ressalva sobre otimização do cliente

Há uma nuance importante. Alguns clientes, na tentativa de otimizar a conexão, ainda assim resolvem o nome localmente antes de enviar o CONNECT e depois passam no CONNECT o endereço IP em vez do nome. Formalmente, isso é permitido, mas anula todo o benefício da resolução remota. Portanto, mesmo com proxy HTTP, não se pode confiar cegamente no comportamento – é preciso verificar. Os métodos de verificação serão discutidos em uma seção separada.

Proxy HTTPS como termo separado

Não confunda os dois significados. Às vezes, proxy HTTPS significa um proxy que faz proxy de tráfego HTTPS (via CONNECT). E às vezes, significa um proxy cuja conexão em si é criptografada por TLS (ou seja, o canal cliente-proxy é protegido). São coisas diferentes. Do ponto de vista da resolução, o mais importante é o primeiro: como o nome de destino é transmitido. A criptografia do canal até o proxy não afeta diretamente o caminho da resolução, embora proteja o próprio fato da transmissão do nome de um observador entre você e o proxy.

Vazamentos de DNS: mecânica de ocorrência e cenários típicos

Agora a parte mais interessante – a anatomia dos vazamentos. Vazamento de DNS é a situação em que a consulta DNS sai contornando o proxy, revelando seu resolvedor real, sua região ou o próprio fato de estar acessando um domínio específico. Vamos analisar os cenários um por um, pois cada um exige tratamento diferente.

Cenário 1: resolvedor do sistema contornando o proxy

O caso mais comum. Você configurou a aplicação para socks5 (sem h), ou o cliente simplesmente não suporta resolução remota. A aplicação chama o getaddrinfo do sistema, o SO envia a consulta DNS diretamente ao seu resolvedor pela rede, ignorando o proxy. Os dados depois passam pelo proxy, mas o nome já vazou.

Como reconhecer: no proxy chegam conexões por IP, não por nome. No dump de rede da sua máquina, são visíveis pacotes de saída na porta 53 que não estão encapsulados no túnel do proxy.

Tratamento: migrar para socks5h, habilitar a resolução remota no cliente ou isolar a aplicação de modo que ela não tenha acesso direto à rede para DNS.

Cenário 2: WebRTC no navegador

WebRTC é uma tecnologia de tempo real para áudio, vídeo e transferência de dados diretamente entre navegadores. Para estabelecer a conexão, o WebRTC usa o mecanismo ICE, que coleta candidatos – inclusive resolve hosts de servidores STUN e pode iniciar consultas que saem fora do proxy configurado. Historicamente, o WebRTC era conhecido por revelar endereços reais mesmo com um proxy funcionando. Embora os navegadores modernos tenham endurecido significativamente a política, o risco permanece se a configuração não for cuidadosa.

Tratamento: controle da política de WebRTC no navegador, desabilitar ou limitar o processamento de candidatos ICE, usar configurações do navegador que forcem todo o tráfego, incluindo WebRTC, a passar pelo proxy.

Cenário 3: DoH embutido no navegador

Navegadores modernos suportam DNS over HTTPS – resolução por meio de uma requisição HTTPS criptografada para seu próprio provedor DoH. O problema é que essa requisição pode sair contornando seu esquema SOCKS, diretamente da máquina, se o navegador estiver configurado para resolver via DoH próprio e não encapsular esse tráfego no proxy. O paradoxo: o nome é resolvido de forma criptografada e privada do provedor, mas fora do seu proxy, o que é pior para tarefas de geolocalização. Esse mecanismo será detalhado na seção sobre DoH.

Cenário 4: caminho IPv6 paralelo

O cenário mais traiçoeiro. Seu proxy funciona em IPv4, você configurou a resolução remota. Mas sua máquina tem IPv6 ativo, e o cliente, seguindo o algoritmo Happy Eyeballs (tentativas simultâneas em IPv4 e IPv6), tenta resolver registros AAAA e se conectar por IPv6 diretamente, contornando o proxy. Parte do tráfego e do DNS saem pelo caminho errado. A região se desencontra, a conexão vai parcialmente para lugar nenhum.

Tratamento: desabilitar IPv6 para a aplicação que utiliza o proxy ou garantir que o proxy suporte IPv6 e que todo o tráfego, incluindo a resolução AAAA, passe por ele. Para muitas tarefas, é mais simples forçar o cliente a usar apenas IPv4.

Cenário 5: cache e pré-carregamento

Navegadores e SOs fazem cache agressivo de DNS e estabelecem conexões antecipadamente (preconnect, prefetch). Se antes de configurar o proxy o cache estava preenchido, a aplicação pode usar registros antigos ou conexões pré-estabelecidas que ignoram a nova configuração. Um detalhe, mas que na depuração pode enlouquecer.

Tratamento: limpar o cache de DNS do SO e do navegador, reiniciar, desabilitar o pré-carregamento agressivo durante o diagnóstico.

Padrão geral dos vazamentos

Percebeu o padrão? Todos os vazamentos se resumem a um só: existe um canal pelo qual o nome ou a conexão saem sem passar pelo proxy. A tarefa do engenheiro é encontrar e fechar todos esses canais. Vazamento é sempre uma porta não fechada, e não misticismo.

Prática por ferramenta: como habilitar a resolução remota

Vamos à prática. Analisaremos clientes específicos e mostraremos como habilitar a resolução remota e evitar a local. Esta é a seção mais aplicada – mantenha-a à mão.

curl: socks5 vs socks5-hostname

curl é a ferramenta de referência para entender a diferença. Ele oferece uma escolha explícita.

  • --socks5 host:port – resolução local. O próprio curl determina o IP e depois passa pelo proxy.
  • --socks5-hostname host:port – resolução remota. O curl envia o nome para o servidor proxy.

Através da opção --proxy também é possível controlar o esquema: socks5://... dá resolução local, e socks5h://... dá remota. Exemplo de chamada correta para resolução remota: curl --proxy socks5h://user:pass@proxyhost:1080 https://example.com. Para proxy HTTP, o esquema http://... com método CONNECT por padrão resolve no proxy, mas também vale verificar o comportamento real.

Python: requests e httpx

No ecossistema Python, o esquema socks5h é o padrão ouro para resolução remota.

Para requests, é necessário o pacote de suporte a SOCKS. O proxy é definido por um dicionário: use o esquema socks5h://user:pass@host:port para https e http. O esquema socks5:// sem h significa resolução local – é justamente esse o motivo mais comum de vazamentos entre iniciantes. Uma letra decide.

Para httpx, a lógica é análoga: passe o proxy com o esquema socks5h:// para resolução remota. O httpx é rigoroso com esquemas e documenta bem o comportamento, mas o princípio é o mesmo – a letra h alterna a resolução para o lado do proxy.

Observação importante: mesmo indicando socks5h, verifique se não está sendo usado o proxy do sistema a partir de variáveis de ambiente (HTTP_PROXY, ALL_PROXY) com outro esquema. As variáveis de ambiente podem sobrescrever suas intenções.

Node.js

Em Node.js, não há suporte direto a SOCKS no http padrão. Usam-se agentes SOCKS, que criam a conexão através do proxy. O parâmetro chave desses agentes é uma opção que determina se o nome será resolvido localmente. Em agentes SOCKS populares, existe uma flag, geralmente chamada algo como lookup ou uma opção relacionada a DNS: com o valor que desativa a consulta local, o nome é enviado ao proxy. Certifique-se de que o agente esteja configurado para enviar o hostname, e não para resolver previamente via dns.lookup.

Dica prática: em Node, preste atenção especial para não chamar dns.resolve ou dns.lookup em algum lugar do código antes de estabelecer a conexão. Essa resolução prematura anula o caminho remoto.

Go

Em Go, a biblioteca padrão fornece um pacote para trabalhar com proxies. Através de golang.org/x/net/proxy é possível criar um dialer SOCKS5. Por padrão, o comportamento depende se você passa para o Dial um nome ou um endereço já resolvido. A chave é usar o dialer de modo que ele receba exatamente o nome de domínio, e não o resultado de net.LookupHost. Se você mesmo chamou a resolução e passou o IP, é resolução local com todas as consequências. A abordagem correta: passar para o dialer uma string host:port com o nome e não resolver antes.

Chrome: flags de inicialização

O Chrome é controlado por flags de linha de comando e políticas. Para especificar o proxy, usa-se a flag proxy-server. O ponto crítico é que, ao trabalhar com SOCKS5, o Chrome, por padrão, pode resolver localmente. Existe uma flag que faz com que a resolução para conexões por proxy seja executada do lado do proxy – seu nome está relacionado a host-resolver-rules e a uma configuração que força todos os hosts a passarem pelo proxy. Também é importante controlar o DoH embutido: se o Secure DNS do navegador estiver ativo e configurado com um provedor próprio, ele pode contornar seu esquema. Para um experimento limpo, o Secure DNS geralmente é desabilitado durante o diagnóstico, e a política de WebRTC é endurecida.

Firefox: configurações about:config

O Firefox, historicamente, é mais amigável para o controle da resolução. A configuração chave é network.proxy.socks_remote_dns. Defina-a como true, e o Firefox enviará os nomes de host para o proxy SOCKS para resolução remota, em vez de resolver localmente. Essa é uma das configurações mais importantes de todo o material. Além disso, controle:

  • network.trr.mode – modo DoH (TRR, Trusted Recursive Resolver). Um valor que desative o DoH forçado é importante se você quiser que a resolução ocorra apenas via proxy.
  • media.peerconnection.enabled – controle do WebRTC, para eliminar vazamentos via ICE.
  • configurações que desabilitam IPv6 ou pré-carregamento, se houver caminho paralelo.

Selenium

O Selenium controla um navegador real, portanto a lógica de resolução é herdada do Chrome ou Firefox. Para o Chrome, você passa as mesmas flags pelas opções de inicialização (argumentos proxy-server e relacionados à resolução). Para o Firefox, você define um perfil com network.proxy.socks_remote_dns ativado por meio do objeto de configurações do perfil. O segredo do sucesso: não confie nos padrões do driver – especifique explicitamente a configuração de resolução remota no perfil ou nas flags e, em seguida, verifique o caminho real.

Playwright

O Playwright fornece um parâmetro proxy ao iniciar um contexto ou navegador. Você especifica o server com o esquema (por exemplo, socks5://host:port) e as credenciais. Aqui há uma sutileza: o comportamento da resolução depende do motor (Chromium, Firefox, WebKit) e de como o proxy é implementado. Para garantir a resolução remota no motor Chromium, combine a configuração do proxy com os argumentos de inicialização apropriados; no motor Firefox, com a configuração de perfil socks_remote_dns. Sempre finalize a configuração verificando vazamentos.

Tabela resumo: cliente, como habilitar resolução remota, como verificar

Tenha em mãos a principal tabela prática do material:

  • curl – habilitar: usar --socks5-hostname ou esquema socks5h:// em --proxy – verificar: curl com verbose e observar se o nome é passado; dump de tráfego para ausência de consultas diretas na porta 53.
  • Python requests – habilitar: esquema socks5h:// no dicionário proxies – verificar: requisição a um serviço que mostre a origem da resolução; controle das variáveis de ambiente.
  • Python httpx – habilitar: proxy com esquema socks5h:// – verificar: teste de vazamento, análise de qual resolvedor é visível.
  • Node.js – habilitar: agente SOCKS com envio de hostname, sem dns.lookup prévio – verificar: ausência de chamadas a dns.resolve antes da conexão; dump na porta 53.
  • Go – habilitar: dialer SOCKS5, passar host:port com nome, sem net.LookupHost antes – verificar: log do que vai para o dialer; tcpdump.
  • Chrome – habilitar: proxy-server com SOCKS5, host-resolver-rules para o proxy, desabilitar Secure DNS no diagnóstico – verificar: teste online de vazamento, comparar região do IP e região do DNS.
  • Firefox – habilitar: network.proxy.socks_remote_dns como true, controlar network.trr.mode – verificar: about:networking, teste online de vazamento.
  • Selenium – habilitar: mesmas flags do Chrome ou perfil do Firefox com socks_remote_dns – verificar: executar teste de vazamento dentro do navegador controlado.
  • Playwright – habilitar: parâmetro proxy mais argumentos do motor para resolução remota – verificar: navegar até um teste de vazamento em sessão automatizada.

DoH e DoT: como interagem com o proxy

DNS over HTTPS (DoH) e DNS over TLS (DoT) são criptografia de consultas DNS. Por si só, são ótimos para proteger o conteúdo da consulta de um observador. Mas no contexto do proxy, eles geram efeitos sutis que precisam ser compreendidos.

O que são DoH e DoT em poucas palavras

DoT encapsula o DNS em TLS em uma porta dedicada. DoH esconde a consulta DNS dentro do tráfego HTTPS comum, tornando-a indistinguível da navegação web. Ambos os protocolos criptografam a consulta. Mas – e isso é crítico – criptografar a consulta não é igual a roteá-la através do proxy. São dimensões diferentes.

Conflito chave: DoH do navegador ignorando o proxy

Aqui está o principal insight da seção. Quando o navegador ativa seu próprio DoH e está configurado para resolver através de seu provedor, ele estabelece uma conexão HTTPS com o endpoint DoH. A pergunta: essa conexão passa pelo seu proxy? Frequentemente, não. O navegador pode abrir o canal DoH diretamente, porque a resolução é tratada como uma operação de serviço, separada da navegação do usuário.

O resultado é paradoxal. Por um lado, a consulta DNS é criptografada e o provedor não vê qual domínio você está consultando. Por outro, essa consulta sai da sua máquina real, da sua rede, ignorando o proxy. Para geolocalização, é um fracasso: a infraestrutura alvo vê a resolução vindo da sua região, e não da região do proxy. Seu belo esquema socks5h é contornado porque o navegador simplesmente não passou pelo SOCKS para resolver – ele seguiu seu próprio caminho DoH.

Quando o DoH do navegador quebra todo o seu esquema

Vamos detalhar situações em que o DoH contorna o proxy:

  • o navegador está configurado para DoH forçado através de seu provedor, e o proxy foi definido apenas para o tráfego normal, não para a resolução de serviço;
  • o sistema operacional ou a aplicação tem DoH ativado no nível do SO, e ele não é encapsulado no túnel;
  • o endpoint DoH está em cache e a conexão com ele foi estabelecida antes da aplicação das configurações de proxy.

Conclusão prática: para tarefas onde a consistência de região é importante, ao trabalhar com proxy, o DoH do navegador e do sistema deve ser desabilitado ou explicitamente direcionado através do mesmo proxy. O cenário ideal é que toda a resolução, criptografada ou não, passe pelo servidor proxy (resolução remota), e não o contorne.

DoT e proxy

DoT funciona em uma porta dedicada e é mais fácil de ser controlado por política de rede, mas também pode sair fora do proxy se não for explicitamente encapsulado. Para nossos objetivos, o princípio é o mesmo: controle para que a resolução passe pelo proxy, e não por um canal independente.

Regra de ouro do DoH no contexto do proxy

Lembre-se: criptografar a resolução e roteá-la através do proxy são propriedades independentes. Você pode ter uma resolução criptografada que, no entanto, entrega totalmente sua região, porque está saindo fora do proxy. Para consistência, sempre busque a resolução remota no proxy, e a questão da criptografia trate separadamente e de forma consciente.

Como verificar: dig, nslookup, tcpdump e testes online

Configurar é metade do trabalho. Um engenheiro precisa verificar se a resolução realmente está indo para onde deveria. Vamos ver as ferramentas de diagnóstico, das simples às avançadas.

dig e nslookup através do proxy

dig e nslookup são utilitários clássicos para resolução manual. A sutileza é que o DNS normal funciona sobre UDP, e um proxy SOCKS faz proxy nativo de TCP. Portanto, verificar a resolução através do proxy exige que a consulta DNS seja feita via TCP, e que o utilitário seja direcionado através de um wrapper SOCKS. Na prática, para observar o comportamento, é mais conveniente encapsular as ferramentas através de programas que encapsulam tráfego TCP em SOCKS. O sentido da verificação: certificar-se de que, na resolução remota, sua máquina local não envia consultas DNS por conta própria, mas vê apenas o resultado que chega através do canal do proxy.

nslookup é útil para uma verificação rápida de qual resolvedor está respondendo e qual IP é retornado. Compare o IP obtido localmente com o IP para o qual a conexão está realmente indo através do proxy. A divergência é um indicador de que a resolução está seguindo caminhos diferentes.

tcpdump na porta 53 – o teste mais honesto

Este é meu método favorito, porque não mente. Execute uma captura de tráfego em sua máquina com filtro na porta 53 (e na 443 para suspeitas de DoH). Em seguida, faça uma requisição através do proxy. A lógica é simples:

  • se durante a resolução remota você vir pacotes DNS de saída na porta 53 diretamente da sua máquina – há vazamento, a resolução está sendo local;
  • se a porta 53 ficar em silêncio e todo o tráfego for para o túnel do proxy – a resolução remota está funcionando corretamente;
  • se a porta 53 ficar em silêncio, mas houver conexões HTTPS suspeitas para endpoints DoH conhecidos, fora do proxy – há vazamento via DoH.

tcpdump mostra a realidade física da rede, não as declarações dos arquivos de configuração. Por isso é indispensável na verificação final.

Teste online de vazamento: como ler o resultado corretamente

Existem serviços web que mostram qual resolvedor executou sua consulta DNS e de qual região ele é. A chave para ler o resultado corretamente é não confundir dois parâmetros:

  • seu IP visível – é o IP de onde veio a conexão HTTP, ou seja, o IP do proxy;
  • resolvedor DNS – é o endereço e a região de quem realmente executou a resolução.

O cenário correto com resolução remota: tanto o IP visível quanto o resolvedor apontam para a região do proxy. Sinal de alerta: o IP visível é da região do proxy, mas o resolvedor é da sua região real. Isso é um vazamento clássico por resolução local. Outra variante de vazamento: o resolvedor pertence a um grande provedor DoH, mas a conexão com ele foi fora do proxy – nesse caso, a região do resolvedor pode ser neutra, mas o caminho em si não passa pelo proxy, o que já é detectado pelo tcpdump.

Checklist de verificação da resolução

Siga os passos sequencialmente:

  1. Limpe o cache de DNS do SO e do navegador, reinicie a aplicação.
  2. Certifique-se de que o esquema é socks5h ou que a resolução remota está ativada no cliente.
  3. Verifique as variáveis de ambiente de proxy para esquemas conflitantes.
  4. Execute tcpdump com filtro nas portas 53 e 443.
  5. Faça uma requisição através do proxy para um recurso de teste.
  6. Confirme que não há pacotes DNS diretos na porta 53.
  7. Verifique a ausência de conexões HTTPS independentes para endpoints DoH.
  8. Acesse um teste online de vazamento e compare a região do IP com a região do resolvedor.
  9. Verifique o caminho IPv6: não há consultas AAAA paralelas e conexões.
  10. Registre a configuração de referência na documentação da equipe.

    11. Erros típicos que quase todo mundo comete

    Ao longo dos anos trabalhando com proxies, acumula-se uma coleção de armadilhas. Vamos ver as mais comuns para que você não caia nelas.

    Erro 1: confundir socks5 e socks5h

    O líder absoluto. A pessoa escreve socks5:// e acredita que a resolução é remota. Mas é local. Uma letra h faltando – e toda a região se desencontra. Sempre especifique explicitamente socks5h se precisar de resolução remota, e verifique com dump.

    Erro 2: configurar o proxy, mas esquecer o DoH

    Clássico em navegadores. O proxy está configurado, mas o Secure DNS / DoH embutido está ativo e sai fora. O usuário vê o IP correto e se acalma, enquanto a resolução vaza. Sempre sincronize a política de DoH com o proxy.

    Erro 3: ignorar o IPv6

    Proxy em IPv4, mas a máquina roda pilha dupla. O Happy Eyeballs faz seu trabalho, e parte das conexões vai diretamente por IPv6. Ou desabilite IPv6 para a aplicação, ou certifique-se de que o proxy atende completamente IPv6.

    Erro 4: resolução local prévia no código

    Um problema comum em Node.js e Go. O desenvolvedor, com as melhores intenções, chama a resolução antes (para verificação, para log) e passa o IP para o proxy. A resolução remota morre. Não resolva o nome antes de passar para o dialer do proxy.

    Erro 5: confiar nas variáveis de ambiente

    HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY – sabotadores silenciosos. Eles sobrescrevem as configurações no código ou entram em conflito com o esquema. Verifique o ambiente antes de executar e limpe o que for desnecessário.

    Erro 6: acreditar na configuração em vez de verificar

    Escreveu a linha correta e seguiu em frente. Mas configuração é intenção, não fato. O comportamento real só é verificado com dump de tráfego e teste de vazamento. Nunca finalize a configuração sem verificação.

    Erro 7: cache de DNS esquecido

    Você muda a configuração, mas o resultado é o mesmo – porque registros antigos e conexões estão em cache. Sempre limpe o cache e reinicie antes de verificar.

    Erro 8: misturar tipos de proxy no mesmo pipeline

    Em um lugar, proxy HTTP com CONNECT; em outro, SOCKS com resolução local. O comportamento da resolução difere, e parte das requisições vaza. Uniformize a abordagem em todo o pipeline.

    Erro 9: não considerar o cache da aplicação

    Algumas aplicações mantêm cache DNS próprio e pool de conexões que sobrevivem à mudança de configurações. Reiniciar o processo às vezes é obrigatório.

    Erro 10: ignorar WebRTC na automação

    Ao automatizar navegadores, o WebRTC é frequentemente esquecido. O navegador controlado inicia ICE tranquilamente e revela caminhos fora do proxy. Sempre controle a política de WebRTC em sessões automatizadas.

    Ferramentas e recursos para trabalhar com resolução via proxy

    Vamos montar o arsenal que você deve ter sempre à mão. Dividimos por finalidade.

    Ferramentas de diagnóstico

    • tcpdump – captura de tráfego de rede, o juiz supremo da verdade sobre os caminhos de resolução.
    • Wireshark – análise gráfica de pacotes, útil para casos complexos com DoH e IPv6.
    • dig e nslookup – resolução manual, verificação rápida das respostas do resolvedor.
    • testes online de vazamento de DNS – mostram o resolvedor e sua região, dão um veredito rápido.
    • about:networking no Firefox – diagnóstico embutido de conexões e DNS do navegador.

    Ferramentas e bibliotecas para configuração

    • curl – referência para verificar o comportamento de socks5 e socks5-hostname, ideal para depuração.
    • Wrappers SOCKS para tráfego TCP – permitem encapsular aplicações arbitrárias em SOCKS para testes de resolução.
    • Bibliotecas SOCKS para linguagens – pacotes de suporte a SOCKS em Python, agentes SOCKS em Node.js, pacote proxy em Go.
    • Ferramentas de automação de navegadores – Selenium e Playwright com configuração explícita de proxy e resolução.

    Recursos de conhecimento

    • documentação oficial do curl sobre opções de proxy – melhor fonte primária sobre a semântica de socks5 vs socks5h;
    • documentação dos clientes HTTP Python sobre trabalho com proxy e esquemas;
    • guias de about:config do Firefox sobre parâmetros de rede e resolução;
    • documentação do seu provedor de proxy escolhido, em particular do serviço MobileProxy.space, onde são descritos os esquemas suportados e recomendações para resolução remota em proxies móveis.

    Mini-framework para escolha da abordagem

    Para não se perder, tenha uma lógica simples de decisão:

    1. Precisa de tráfego HTTPS e resolução remota? Proxy HTTP com CONNECT ou SOCKS5 com esquema socks5h.
    2. Está trabalhando a partir de biblioteca ou CLI? Especifique explicitamente socks5h ou a flag de resolução remota.
    3. Está trabalhando a partir de navegador? Ative a resolução remota, desabilite ou direcione o DoH através do proxy, restrinja WebRTC e IPv6.
    4. Sempre finalize a configuração com dump de tráfego e teste online.

    Casos e resultados: como fica na prática

    Teoria sem prática é morta. Vamos analisar casos generalizados que refletem situações típicas. Os números são aproximados, mas as proporções e a lógica vêm da engenharia real.

    Caso 1: dessincronização de região em analista de dados

    Uma equipe coletava dados através de um script Python com proxy de uma região específica. Os resultados vinham com localização de outro país em cerca de quarenta por cento dos casos. O diagnóstico mostrou o esquema socks5:// no dicionário proxies – resolução local. A substituição por socks5h:// eliminou completamente a dessincronização. O tcpdump confirmou: as consultas diretas na porta 53 desapareceram. Lição: uma letra resolveu um problema que havia consumido dois dias.

    Caso 2: vazamento via DoH do navegador na automação

    Ao automatizar o Chromium via Playwright, o IP da região estava correto, mas o recurso alvo insistia em determinar outra região. O teste online mostrou um resolvedor que não coincidia com a região do proxy. O Wireshark revelou conexões HTTPS independentes para um endpoint DoH fora do proxy. Solução: desabilitar o Secure DNS na configuração de inicialização e forçar a resolução remota. Após o ajuste, a região do resolvedor coincidiu com a região do IP, e os falsos positivos de antifraude caíram drasticamente.

    Caso 3: IPv6 paralelo em microsserviço

    Um serviço em Go acessava via SOCKS5, mas periodicamente parte das requisições ia direto. A causa era a pilha dupla e tentativas por IPv6 fora do proxy. Restringir o cliente apenas a IPv4 e passar corretamente o nome para o dialer eliminou o vazamento. O tcpdump deixou de mostrar consultas AAAA diretas. A estabilidade da região subiu para quase cem por cento.

    Caso 4: variáveis de ambiente sabotadoras

    Um script se comportava de forma diferente em duas máquinas com código idêntico. Em uma, a resolução remota funcionava; na outra, não. A revelação: na máquina problemática, a variável ALL_PROXY estava definida com um esquema sem h, sobrescrevendo as configurações. Após limpar o ambiente, o comportamento se tornou consistente. Lição: o ambiente é parte da configuração e deve ser controlado com o mesmo rigor que o código.

    Conclusão geral dos casos

    Observe o padrão. Em todos os casos, o sintoma era semelhante – região incorreta ou disparo de proteção – mas as causas eram diferentes: esquema, DoH, IPv6, ambiente. Por isso, o diagnóstico baseado em checklist é mais importante que a intuição. A abordagem sistemática encontra a raiz mais rápido do que o chute.

    FAQ: perguntas frequentes

    Qual a diferença entre socks5 e socks5h em palavras simples?

    socks5 resolve o nome de domínio do seu lado e envia o IP pronto para o proxy. socks5h envia o próprio nome para o proxy, e a resolução é feita por ele. Para privacidade e geolocalização correta, quase sempre é necessário socks5h. A letra h significa hostname – o nome do host é enviado remotamente.

    Se eu uso proxy HTTP, preciso me preocupar com a resolução?

    No HTTPS via método CONNECT, o nome geralmente vai para o proxy, e ele resolve sozinho – isso é bom. Mas alguns clientes resolvem localmente antes e passam o IP no CONNECT. Por isso, mesmo com proxy HTTP, verifique o comportamento real com dump de tráfego.

    Por que o IP está correto, mas o site vê outra região?

    Quase com certeza sua consulta DNS está saindo fora do proxy – através do resolvedor local ou DoH do navegador. A infraestrutura alvo, por geolocalização DNS e CDN, determina a região do seu resolvedor, não do proxy. Tratamento: resolução remota e controle do DoH.

    Como o WebRTC se relaciona com a resolução e vazamentos?

    O WebRTC, para estabelecer conexões, coleta candidatos de rede e pode iniciar consultas que saem fora do proxy. Isso pode revelar caminhos e endereços. Ao trabalhar com proxy, especialmente em automação de navegadores, a política de WebRTC deve ser controlada ou limitada.

    O DoH quebra minha configuração de proxy?

    Pode quebrar. Criptografar a resolução e roteá-la através do proxy são coisas diferentes. O DoH do navegador ou do sistema pode sair diretamente, ignorando o proxy, entregando sua região. Para consistência, desabilite esse DoH ou direcione a resolução através do proxy.

    Como verificar rapidamente se há vazamento?

    Dois passos. Primeiro: execute tcpdump com filtro na porta 53 e faça uma requisição através do proxy: pacotes DNS diretos indicam vazamento. Segundo: acesse um teste online e compare a região do IP visível com a região do resolvedor. Se coincidirem, está bom; se divergirem, há vazamento.

    O que fazer com IPv6 se o proxy for apenas IPv4?

    Ou desabilite IPv6 para a aplicação que usa o proxy, ou certifique-se de que o proxy atende IPv6 e todo o tráfego, incluindo a resolução AAAA, passa por ele. Caso contrário, o algoritmo Happy Eyeballs enviará parte das conexões diretamente, fora do proxy.

    Por que o mesmo código se comporta de forma diferente em duas máquinas?

    Causa comum: variáveis de ambiente de proxy (HTTP_PROXY, ALL_PROXY e similares). Elas sobrescrevem as configurações no código ou definem um esquema diferente. Verifique e limpe o ambiente para tornar o comportamento consistente.

    É suficiente especificar socks5h para garantir que não haja vazamentos?

    Para a própria aplicação, é um grande avanço, mas não uma garantia para todo o sistema. Permanecem canais como DoH do navegador, WebRTC e IPv6. A proteção completa é a resolução remota mais o controle de todos os canais de desvio, mais a verificação obrigatória com dump.

    Posso resolver via proxy na linha de comando para teste?

    Sim. curl com a opção --socks5-hostname ou esquema socks5h é a maneira mais simples de testar a resolução remota. Para utilitários como dig, é conveniente encapsular o tráfego TCP em SOCKS, lembrando que o DNS clássico sobre UDP não é nativamente proxyado por SOCKS.

    Conclusão: resumo e próximos passos

    Percorremos o caminho do sintoma ao entendimento profundo. Vamos reunir o essencial em um quadro compacto que ficará com você.

    A resolução de nome de domínio é uma transação de rede separada, que pode seguir uma rota diferente da do seu tráfego principal. É exatamente essa independência que gera a maioria dos problemas. Quatro entidades podem executar a resolução: o sistema operacional, a biblioteca da aplicação, o navegador e o próprio proxy. Seu objetivo é quase sempre entregar a resolução ao servidor proxy, para que o nome seja determinado a partir do ponto correto da rede.

    A diferença entre socks5 e socks5h é fundamental. socks5 – resolução local; socks5h – remota. Uma letra muda tudo: região, privacidade, consistência. Proxies HTTP com método CONNECT, por natureza, transmitem o nome para o proxy, mas também aqui não se deve confiar cegamente – verifique.

    Os vazamentos se resumem a um princípio: existe um canal pelo qual o nome sai sem passar pelo proxy. Resolvedor do sistema, WebRTC, DoH do navegador, IPv6 paralelo, cache – esses são os principais suspeitos. E lembre-se do insight-chave: criptografar a resolução não é o mesmo que roteá-la através do proxy. Você pode ter um DoH criptografado que, no entanto, entrega totalmente sua região.

    O que fazer agora? Aqui está seu plano de ação:

    1. Revise suas configurações atuais e substitua socks5 por socks5h onde for necessária a resolução remota.
    2. Verifique os navegadores: ative a resolução remota, entenda a política de DoH e WebRTC.
    3. Certifique-se de que o IPv6 não está criando um caminho paralelo fora do proxy.
    4. Limpe as variáveis de ambiente de proxy de valores conflitantes.
    5. Realize a verificação com tcpdump e teste online, seguindo o checklist do artigo.
    6. Registre a configuração de trabalho de referência na documentação para que a equipe não reinvente a roda.

    O tema da resolução via proxy parece específico, mas é justamente onde as configurações mais caras e frustrantes quebram. Agora você tem um mapa do terreno: entende quem resolve, onde a decisão é tomada, como surgem os vazamentos e como fechá-los. Mantenha este material nos favoritos e volte à tabela e aos checklists sempre que o proxy estiver conectado, mas o site teimar em ver a região errada. Agora você sabe onde procurar.

    Sobre o autor

    Andrey Kokh

    Andrey Kokh

    Leading Expert and Business Consultant

    Experiência profissional: 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.
    Formação: Higher School of Economics. Faculty of Economics, Master's Program
    Especialização:
    Strategic Consulting Digital Transformation Change Management Business Strategy Innovation Management Organizational Development Lean Management Agile Transformation

    Compartilhe este artigo: