Sumário do artigo

Introdução: por que o proxy pode estar perfeito e ainda assim te enxergarem

Imagine a situação. Você comprou um proxy móvel de qualidade, configurou o navegador antidetect, checou o IP em três serviços diferentes — em todos, o endereço da operadora de celular na região certa. Você inicia uma conta de anúncios, aquece as contas, faz scraping. Uns dias depois, vem um bloqueio com a justificativa de atividade suspeita. Soa familiar? Uma das causas mais subestimadas dessas histórias é o dns leak, ou seja, o vazamento de consultas DNS por fora do proxy.

O paradoxo é que o endereço IP realmente está trocado. O site vê o tráfego vindo da operadora móvel. Mas antes de cada conexão, seu computador pergunta silenciosamente ao provedor: "onde fica o servidor tal?". E essa pergunta sai direto, sem passar pelo proxy. O resultado é que o lado observador recebe duas imagens que não batem: a conexão vem de uma rede móvel de uma região, mas os nomes são resolvidos por um resolver do provedor de internet de outra cidade completamente diferente. Para os sistemas antifraude de 2026, essa discrepância não é detalhe — é um dos sinais mais confiáveis.

Pela nossa observação dos chamados no suporte, boa parte das reclamações do tipo "o proxy não funciona, o geo é detectado errado, as contas caem sem motivo" acaba se revelando, numa análise detalhada, não um problema do proxy em si. É um problema da camada DNS do lado do cliente. E as pessoas que verificam o DNS antes de começar a trabalhar ainda são minoria — a maioria se limita a checar o IP.

Neste guia vamos destrinchar o tema por completo. Você vai entender como funciona a resolução de nomes e em que momento ela escapa do proxy. Vai entender a diferença entre proxies HTTP e SOCKS do ponto de vista do DNS, por que uma única letra na string de conexão decide tudo, e como navegadores com DNS criptografado ativado criam uma nova categoria de vazamentos. Vamos dar quatro métodos práticos — diagnóstico, configuração do software cliente, navegadores e antidetects, nível de sistema — cada um com instruções passo a passo e checklists. Vamos ver erros típicos, casos com números e responder às perguntas difíceis.

Uma fronteira importante: este artigo é sobre a camada DNS. Vazamentos via WebRTC, fingerprint de navegador, timings e outros canais de desanonimização são temas separados, tratados em outros materiais do blog. Aqui vamos focar em um canal, mas fundamental, porque sem entendê-lo qualquer outra configuração fica em cima de areia.

Fundamentos: como o DNS funciona e o que é dns leak

A lista telefônica da internet

Toda vez que o navegador ou um script quer se conectar a um site, ele precisa não do domínio, mas de um endereço IP. O domínio é um nome legível para humanos. O endereço são coordenadas que a rede entende. O serviço que traduz um no outro se chama DNS (Domain Name System). A analogia mais simples é a lista telefônica: você sabe o nome, a lista dá o número. Só que essa lista é distribuída por milhares de servidores e funciona em milissegundos.

Como fica a resolução de nome na prática:

  1. O aplicativo chama uma função do sistema (no mundo Unix, geralmente getaddrinfo), passando o nome do domínio.
  2. O sistema operacional verifica o cache local e o arquivo hosts.
  3. Se não houver resposta, o stub resolver do SO envia a consulta ao endereço do servidor DNS configurado nas definições de rede. Normalmente é o servidor do seu provedor, entregue por DHCP, ou um resolver público que você indicou manualmente.
  4. O resolver recursivo do provedor percorre a cadeia de servidores raiz, servidores de zona do domínio e servidores autoritativos do domínio, encontra a resposta e devolve a você.
  5. O aplicativo recebe o IP e só então estabelece a conexão.

Repare na ordem. Primeiro o DNS, depois a conexão. O proxy é a ferramenta que interfere na conexão. Mas se ele vai interferir no DNS depende do tipo de proxy, do protocolo e de como exatamente o aplicativo o utiliza.

O que exatamente se chama de vazamento

DNS leak é a situação em que o tráfego do aplicativo passa pelo proxy, mas as consultas de resolução de nomes não. Elas saem direto da sua interface de rede real para o resolver configurado no sistema. Resultado: o site ao qual você se conecta vê o IP do proxy, mas seu provedor e o dono do resolver veem a lista de todos os domínios que você acessou. E o serviço de destino, sob certas condições, pode correlacionar de onde veio a conexão e de onde veio a consulta DNS.

Por que isso importa justamente para usuários de proxies móveis? Porque todo o valor do IP móvel está na sua verossimilhança. O endereço pertence a uma operadora de celular, tem milhares de assinantes reais atrás dele, muda, tem boa reputação. Mas um assinante real de rede móvel resolve nomes pelos servidores DNS dessa mesma operadora. Se o seu tráfego sai da rede móvel mas os nomes são resolvidos por um provedor de cabo de outra região, você deixa de parecer um assinante real. Você passa a parecer quem usa proxy. E é exatamente isso que você é — e você mesmo contou.

Três papéis que veem seu vazamento

  • Seu provedor de internet. Ele vê as consultas ao seu resolver e sabe quais domínios você visita, mesmo que o conteúdo em si tenha ido pelo proxy.
  • O dono do resolver. Se você configurou um DNS público, o operador dele vê a lista completa dos seus domínios e o seu IP real.
  • O site de destino e seu antifraude. Ele não recebe a consulta DNS diretamente, mas tem canais indiretos: a geografia dos servidores autoritativos, o mecanismo EDNS Client Subnet, o roteamento por CDN e domínios de teste especiais, gerados para uma sessão específica. Sobre isso, em detalhes, na próxima seção.

Mergulho profundo: anatomia do vazamento de DNS ao trabalhar via proxy

Proxy HTTP: por que normalmente não vaza, mas há exceções

Ao trabalhar via proxy HTTP, o navegador envia a ele uma requisição em que o domínio está em texto. Para HTTP não criptografado, é a URL completa na primeira linha da requisição. Para HTTPS, o navegador envia o comando CONNECT com o nome do host e a porta, e o proxy mesmo resolve esse nome e estabelece o túnel. Nos dois casos, o cliente não precisa saber o IP do servidor de destino. A resolução é feita pelo proxy, do seu lado, com seus resolvers. No caso do proxy móvel — do lado do modem ou do celular, pelos servidores DNS da operadora. É assim que deve ser.

De onde então vêm vazamentos com proxy HTTP? Suas fontes são indiretas:

  • Scripts PAC. O arquivo de autoconfiguração de proxy pode conter a função dnsResolve, que resolve o domínio localmente para decidir se envia a requisição pelo proxy. A decisão é tomada depois da consulta DNS local.
  • Resolução prévia de nomes. Alguns aplicativos verificam a disponibilidade do host antes da conexão: dão ping, resolvem, e só depois vão pelo proxy. Aplicativos Java com InetAddress, certos scrapers, plugins de verificação de links.
  • Serviços de fundo do navegador. Pré-carregamento de páginas, DNS-prefetch, verificações de navegação segura e de atualizações podem funcionar com regras próprias e nem sempre respeitam as configurações de proxy.

SOCKS: uma letra entre a sessão limpa e o vazamento

Aqui começa a parte mais interessante. O protocolo SOCKS4, na versão original, só consegue passar ao proxy o endereço IP de destino. Isso significa que o cliente é obrigado a resolver o nome sozinho, antes da conexão. O vazamento está embutido no protocolo. A extensão SOCKS4a adicionou a possibilidade de passar o nome do host. O SOCKS5 suporta três tipos de endereço de destino: IPv4, IPv6 e nome de domínio.

Parece que o SOCKS5 resolve o problema. Mas o suporte ao nome de domínio no protocolo não significa que o cliente vá usá-lo. Muitas bibliotecas e programas, por padrão, resolvem o nome localmente e enviam ao proxy um IP já pronto. O protocolo permite isso — só que o vazamento acontece um passo antes.

Daí a famosa letra h. No curl e nas bibliotecas que seguem sua convenção, o esquema socks5:// significa resolução local de nomes, e socks5h:// significa passar o nome do host ao servidor proxy para resolução remota. Uma letra. A diferença entre uma sessão limpa, em que tudo, incluindo o DNS, sai da rede móvel da operadora, e uma sessão em que cada nome primeiro vaza para o seu provedor.

Por que é melhor que o próprio servidor proxy resolva

Há um ponto não óbvio aqui que muita gente deixa passar. Não é só questão de privacidade. Quando o nome é resolvido pelo lado remoto do proxy móvel, a resposta DNS é formada levando em conta a localização da operadora. Grandes serviços usam CDN e geo-DNS: para o mesmo domínio, clientes diferentes recebem IPs diferentes, os mais próximos deles. Se quem resolve é o seu provedor de casa, você recebe o endereço do nó de CDN perto da sua localização real. E depois se conecta a esse nó através do proxy móvel de outra região. Para o serviço, isso soa estranho: um cliente de rede móvel da região A foi parar num nó destinado à região B. Esse é o canal indireto de detecção de dns leak, que não exige nenhum acesso às suas consultas DNS.

EDNS Client Subnet: como o resolver entrega a sua sub-rede

O mecanismo EDNS Client Subnet (ECS) foi criado para que resolvers públicos pudessem passar aos servidores autoritativos parte do endereço do cliente — geralmente os primeiros 24 bits para IPv4. Assim a CDN entende de onde vem o usuário real e entrega o nó mais próximo. Isso é conveniente para a velocidade. Mas do ponto de vista de vazamentos, significa que, ao resolver localmente por meio de um DNS público com suporte a ECS, o servidor autoritativo do domínio de destino recebe a sub-rede da sua conexão real. Não o endereço completo, mas o suficiente para entender o provedor e a cidade. E a conexão depois chega de um IP móvel. Duas sub-redes, duas operadoras, um usuário.

DNS criptografado: uma nova categoria de vazamentos

Desde a década de 2020, navegadores e sistemas operacionais migraram em massa para DNS over HTTPS (DoH) e DNS over TLS (DoT), e até 2026 veio também o DNS over QUIC. A ideia é boa: o provedor deixa de ver suas consultas. Mas, para o trabalho via proxy, surgiu um efeito colateral. Um navegador com "DNS seguro" ativado acessa o servidor DoH escolhido com seu próprio cliente, e esse tráfego nem sempre segue as configurações do proxy. Ou seja, os nomes são resolvidos não na operadora móvel, mas num grande resolver público, e ainda por cima a partir do seu IP real. A criptografia protege do provedor, mas não da discrepância entre o lado DNS e o lado da conexão.

Uma camada adicional de complexidade é o Encrypted Client Hello (ECH). Para funcionar, o navegador requisita registros HTTPS especiais no DNS. Quanto mais sites usam ECH, mais consultas DNS o navegador faz — e mais motivos para vazamento, se o DNS não segue o caminho correto.

IPv6 e Happy Eyeballs

Sistemas modernos consultam ao mesmo tempo os registros A (IPv4) e AAAA (IPv6) e tentam se conectar ao que responder mais rápido — o algoritmo Happy Eyeballs. Se a sua rede real suporta IPv6 e o proxy só funciona via IPv4, vários aplicativos conseguem sair direto por IPv6, contornando o proxy por completo. A rigor, isso não é dns leak, mas vazamento de conexão; só que o gatilho é justamente a resposta DNS com registro AAAA. Por isso, no contexto de higiene de DNS, é preciso ter o IPv6 em mente.

Cache e hosts: vazamento vindo do passado

O SO faz cache das respostas DNS. Se você trabalhou sem proxy e depois ativou o proxy, parte dos nomes já está no cache com endereços obtidos pelo resolver de casa. Não haverá novas consultas, mas as conexões irão para nós de CDN "de casa". O mesmo vale para o arquivo hosts: registros nele substituem a resolução de nomes por completo, e o proxy nem fica sabendo.

Método 1. Diagnóstico: como verificar o dns leak com as próprias mãos

Antes de configurar qualquer coisa, é preciso ver o problema. A boa notícia: verificar vazamento de DNS é um procedimento de cinco minutos, que pode e deve virar um ritual antes de cada sessão de trabalho.

Como funcionam os testes on-line

Qualquer serviço de verificação de dns leak funciona igual. A página gera vários subdomínios únicos no formato string-aleatória.domínio-de-teste e obriga seu navegador a resolvê-los, geralmente carregando imagens ou scripts invisíveis. Como os subdomínios são únicos, eles com certeza não estão em cache nenhum. A consulta obrigatoriamente chega ao servidor autoritativo do domínio de teste, que pertence ao serviço. Ele registra de qual IP veio a consulta — esse é o endereço do resolver recursivo que você está usando. Depois a página mostra duas colunas: o endereço de onde veio a conexão HTTP e os endereços dos resolvers. Se a conexão vem da operadora móvel e o resolver pertence ao provedor de casa ou a um serviço de DNS público — há vazamento.

É importante entender: qualquer site pode fazer exatamente a mesma coisa. O mecanismo não exige permissões especiais. Sistemas antifraude de grandes plataformas usam técnicas parecidas como parte da avaliação de risco da sessão. Não é teoria da conspiração, é engenharia padrão.

Procedimento passo a passo de verificação

  1. Registre a linha de base. Desligue o proxy, abra o teste de dns leak, anote quais resolvers aparecem. Essa é a sua "impressão digital de casa". Você deve reconhecê-la de bate-pronto.
  2. Limpe o cache DNS. No Windows, o comando ipconfig /flushdns; no macOS, reinicie o serviço mDNSResponder; no Linux, depende do resolver (por exemplo, resolvectl flush-caches para o systemd-resolved). Reinicie o navegador — ele tem cache próprio.
  3. Ative o proxy do jeito que você vai trabalhar de verdade: pelo perfil do antidetect, por extensão, pelas configurações do sistema ou por código.
  4. Rode um teste avançado, que faça não uma, mas dezenas de verificações. O vazamento pode ser parcial: nove consultas de dez saem pelo proxy, e a décima vai direto. Um teste único não pega isso.
  5. Compare. Todos os resolvers devem pertencer à operadora de celular pela qual o proxy funciona, ou à infraestrutura do serviço de proxy. Nenhum endereço da linha de base. Nenhum resolver público que você não escolheu conscientemente.
  6. Verifique o IPv6 separadamente. Se o teste mostra qualquer endereço IPv6 que não pertença ao proxy — vazamento.
  7. Repita depois de dez minutos de trabalho. Alguns processos de fundo iniciam com atraso.

Verificação sem serviços de terceiros: seu próprio domínio de teste

Para quem trabalha com fazendas de contas ou scraping em escala industrial, é razoável ter uma ferramenta própria. O esquema é este: você registra um domínio barato e sobe para ele um servidor DNS autoritativo no seu VPS com log de consultas ativado. Depois, em qualquer projeto, na inicialização de qualquer sessão, você acessa um subdomínio único no formato identificador-da-sessão.seu-domínio. No log do servidor DNS aparece um registro: qual subdomínio foi consultado e de qual IP de resolver. Você correlaciona com o identificador da sessão e vê na hora qual sessão, qual perfil, qual worker vazou. Isso transforma a verificação pontual em monitoramento constante.

Verificação de baixo nível: olhando a rede

O jeito mais honesto é olhar o que realmente sai da interface de rede. Rode um analisador de tráfego (Wireshark ou tcpdump) na interface física da máquina e filtre a porta 53 UDP e TCP, além da porta 853 para DoT. Depois trabalhe pelo proxy por cinco minutos. No mundo ideal, o filtro fica vazio: todos os nomes são resolvidos do lado do proxy, não há pacote DNS local nenhum. Se houver pacotes, você vê na hora quais domínios e para onde vão. Para DoH o filtro é mais complicado, porque é HTTPS comum na porta 443, mas uma pista são as conexões a endereços conhecidos de provedores DoH públicos, que aparecem fora do proxy.

Checklist de diagnóstico

  • Linha de base sem proxy registrada.
  • Cache do SO e do navegador limpo antes do teste.
  • Teste avançado com dezenas de consultas executado.
  • Todos os resolvers correspondem ao lado do proxy.
  • Endereços IPv6 de rede alheia ausentes.
  • Teste repetido após 10 minutos de trabalho aprovado.
  • Para projetos críticos: analisador de tráfego na porta 53 mostrando zero pacotes.

Método 2. Configuração correta do software cliente e do código

Você achou o vazamento. Agora é preciso entender onde exatamente o aplicativo decide resolver o nome localmente e mudá-lo para resolução remota. Vamos ver os ambientes mais comuns na prática de afiliados e desenvolvedores.

Princípio: o nome do host deve chegar ao proxy

A regra é uma só, e é universal. O proxy deve receber de você o nome do domínio, não o IP. Para proxy HTTP isso acontece naturalmente. Para SOCKS5 é preciso escolher explicitamente o modo de DNS remoto. Para SOCKS4 sem a extensão a, isso é impossível por princípio — esses proxies não servem para trabalho limpo. Proxies móveis de serviços modernos suportam tanto HTTP quanto SOCKS5 com resolução remota, então a limitação está apenas do lado do cliente.

curl e linha de comando

Para SOCKS5, use sempre o esquema com a letra h. Exemplo de chamada correta:

curl -x socks5h://user:pass@host:port https://example.com/

Sem a letra h, o curl resolve o nome localmente. Isso vale também para todas as ferramentas construídas sobre a libcurl. Para proxy HTTP, o esquema http:// no parâmetro -x já basta: o nome irá na requisição CONNECT.

Python: requests, httpx, aiohttp

Na biblioteca requests com o pacote de suporte a SOCKS instalado, vale a mesma regra: socks5:// significa resolução local, socks5h:// significa resolução remota. Esse é o erro mais comum em scrapers: o desenvolvedor copia o exemplo da documentação, onde está socks5, e passa anos rodando tráfego com dns leak sem nem suspeitar. No httpx e no aiohttp, o suporte a SOCKS é implementado por transportes de terceiros, e o modo de resolução remota precisa ser checado na documentação do transporte específico — em alguns é o parâmetro rdns, em outros também é o esquema com h. Verifique não pela documentação, mas na prática: rode o script contra o seu próprio domínio de teste e veja no log de onde veio a consulta.

Uma armadilha à parte são as bibliotecas de socket de baixo nível que fazem monkey patch no módulo socket padrão para envolver todo o tráfego em SOCKS. Elas têm uma flag de resolução remota, mas por padrão ela muitas vezes vem desligada. Além disso, qualquer chamada a socket.gethostbyname no seu código ou nas dependências passa por fora e resolve o nome pelo resolver do sistema.

Node.js e navegadores headless

No ecossistema Node.js, os agentes SOCKS geralmente passam o nome do host ao proxy, mas isso depende do pacote específico e da versão dele. Para Puppeteer e Playwright, o proxy é definido na inicialização do navegador, e o comportamento é herdado do motor Chromium — sobre as particularidades dele com SOCKS5, vamos falar na próxima seção. Se você trabalha com o modo HTTP do proxy móvel, a questão some: o Chromium envia CONNECT com o nome do host.

Go, Java e outras linguagens

Em Go, o pacote padrão golang.org/x/net/proxy para SOCKS5 passa o nome do host remotamente, mas só se você usar o Dialer dele diretamente, sem resolver antes. Em Java, as propriedades de sistema para proxy SOCKS funcionam, mas muitos clientes HTTP criam um objeto InetSocketAddress com resolução prévia, o que causa o vazamento. A solução é criar um endereço não resolvido (métodos do tipo createUnresolved) e garantir que o cliente suporte o repasse do nome. Dica universal para qualquer linguagem: encontre no código e nas dependências todos os lugares em que o domínio vira IP e confirme que isso acontece depois do estabelecimento da conexão com o proxy, não antes.

Auditoria passo a passo do projeto

  1. Encontre no código todas as strings de conexão com o proxy. Cheque os esquemas: socks5 sem h — bandeira vermelha.
  2. Encontre todas as chamadas explícitas de resolução de nomes: gethostbyname, getaddrinfo, dns.lookup, InetAddress.getByName. Cada uma é um vazamento em potencial.
  3. Verifique as dependências: bibliotecas de verificação de disponibilidade, health-check, retries com ping prévio.
  4. Rode o projeto contra o seu próprio domínio de teste com um subdomínio único por worker. O log do servidor DNS vai mostrar quem está vazando.
  5. Adicione um teste automatizado: a sessão não é considerada válida enquanto a verificação DNS não confirmar que o resolver pertence ao lado do proxy.
  6. Registre o resultado na documentação do projeto: qual biblioteca, qual versão, qual modo.

Checklist para o desenvolvedor

  • Todas as conexões SOCKS5 usam resolução remota.
  • Não há resolução prévia antes da conexão.
  • As bibliotecas foram verificadas não pela documentação, mas pelo log do domínio de teste.
  • Verificação automática de DNS embutida no início da sessão.
  • Para o modo HTTP do proxy, verificado que se usa CONNECT, e não substituição por IP.

Método 3. Navegadores e navegadores antidetect sem vazamentos de DNS

A maior parte do público de proxies móveis trabalha não em código, mas no navegador: contas de anúncios, redes sociais, marketplaces, multiaccounting. Aqui as regras são outras, e mudam de motor para motor.

Firefox e seus derivados

O Firefox historicamente oferece o controle mais transparente. O parâmetro-chave em about:config é network.proxy.socks_remote_dns. Com valor true, os nomes são passados ao proxy SOCKS para resolução remota. Com false, são resolvidos localmente. Em muitas builds e perfis antigos ele vem desligado. O segundo parâmetro é network.trr.mode, que controla o DNS criptografado: o valor 5 o desliga por completo, o que, para trabalhar via proxy, é preferível, porque senão o navegador pode acessar o servidor DoH com cliente próprio. O terceiro bloco é o de pré-carregamento: network.dns.disablePrefetch em true e network.predictor.enabled em false desligam a resolução especulativa de nomes para links da página, que de outra forma pode sair por fora do proxy antes do clique real. Navegadores antidetect baseados no motor Firefox geralmente configuram esses parâmetros corretamente, mas vale conferir sempre depois de atualizações.

Chrome, Chromium e antidetects baseados neles

Com o Chromium a história é mais complicada. Trabalhando via proxy HTTP, ele envia CONNECT com o nome — não há vazamento. Já ao usar proxy SOCKS5 por flag de inicialização, o motor, em várias configurações, resolve nomes localmente, e não há configuração padrão de "DNS remoto" na interface. Um truque de engenharia conhecido é a flag --host-resolver-rules com uma regra que mapeia todos os nomes para o estado "não encontrado", exceto o próprio endereço do proxy. Como resultado, o resolver local não consegue resolver nada, e o navegador é forçado a passar os nomes ao proxy. Parece gambiarra, mas funciona de forma confiável. O segundo ponto importante é a configuração de DNS seguro na seção de privacidade: quando ativado, o Chromium usa DoH com o provedor escolhido, e esse tráfego nem sempre segue o proxy. Para trabalhar via proxy móvel, é preciso desligá-lo ou garantir, em testes, que ele é tunelado corretamente. Terceiro — pré-carregamento de páginas: nas configurações de desempenho há uma opção de pré-carregamento que inicia consultas DNS para links em que você ainda nem clicou.

O que um navegador antidetect deve saber fazer

Um bom antidetect assume toda essa rotina. Mas a qualidade da implementação varia muito. Veja o que checar na escolha e depois de cada atualização:

  • Modo de DNS remoto para SOCKS5 ativado por padrão para cada perfil, não globalmente.
  • Isolamento de DNS entre perfis. O cache de nomes resolvidos não deve ser compartilhado: senão um perfil em proxy móvel de uma região recebe um IP cacheado por um perfil em proxy de outra região.
  • DNS criptografado desligado ou tunelado. Pergunte ao suporte diretamente: como se comporta o DoH embutido ao trabalhar via proxy.
  • Prefetch desligado. A resolução especulativa não deve existir num perfil que finge ser um usuário móvel comum.
  • Verificação embutida de dns leak na inicialização do perfil, ou pelo menos um atalho prático para o teste.
  • Comportamento em queda do proxy. O que o navegador faz se o proxy está indisponível: bloqueia conexões ou sai direto? A segunda opção é um desastre não só para o DNS.

Extensões de proxy: gelo fino

Extensões de navegador que trocam de proxy funcionam pela API do navegador. Elas conseguem definir o proxy para as conexões, mas o controle sobre o DNS é limitado pelas capacidades do motor. A extensão não pode obrigar o Chromium a usar DNS remoto para SOCKS5 se o próprio motor não faz isso naquela configuração. Além disso, a extensão não gerencia os serviços de fundo do navegador. Por isso, extensões são uma opção aceitável para o modo HTTP do proxy móvel e para verificações rápidas, mas não para trabalho sério com contas sensíveis.

Configuração passo a passo do perfil

  1. Crie o perfil e indique o proxy móvel. Prefira o modo HTTP se o antidetect não garante DNS remoto para SOCKS5.
  2. Desligue o DNS criptografado nas configurações do motor ou do perfil.
  3. Desligue o pré-carregamento de páginas e o DNS-prefetch.
  4. Se for um motor tipo Firefox — confira socks_remote_dns manualmente.
  5. Inicie o perfil, limpe o cache e passe no teste avançado de dns leak.
  6. Navegue por alguns sites com analytics ativo e repita o teste: apareceram novos resolvers?
  7. Salve o resultado como referência para esse perfil.

Método 4. Nível de sistema e infraestrutura: fechando vazamentos à força

Todos os métodos anteriores funcionam por confiança: configuramos o aplicativo e esperamos que ele se comporte corretamente. A abordagem de engenharia é outra: tornar o vazamento tecnicamente impossível. Mesmo que o aplicativo tente enviar uma consulta DNS direta, ela não deve sair.

Princípio "tudo proibido, exceto pelo proxy"

Na máquina de trabalho ou no servidor da fazenda, configura-se um firewall que bloqueia o tráfego de saída na porta 53 (UDP e TCP) e na porta 853 para todos os processos, exceto os explicitamente permitidos. No Windows, são regras de saída no firewall; no Linux, nftables ou iptables; no macOS, pf. O sentido: se o navegador ou o script tentar resolver um nome localmente, receberá um erro, e não um vazamento silencioso. O erro é visível na hora — você o verá e corrigirá a configuração do aplicativo. O vazamento silencioso pode viver meses.

A sutileza com o DoH: ele vai para a porta 443, que não pode ser bloqueada por inteiro. A solução é bloquear não a porta, mas os endereços de resolvers DoH públicos conhecidos para os processos que devem sair apenas pelo proxy. Isso exige manter uma lista, mas ela muda raramente.

Isolamento via contêineres e network namespaces

Para desenvolvedores e donos de fazenda no Linux, a ferramenta mais poderosa são os network namespaces e contêineres. A ideia: cada worker, cada perfil de navegador ou grupo de perfis vive em seu próprio namespace de rede, no qual não existe rota padrão para a internet de forma alguma. O único caminho para fora é o endereço do proxy. Faça o que fizer — resolver nome, sair por IPv6, abrir conexão direta — o aplicativo fisicamente não tem rota. Essa é a forma mais confiável de garantir ausência de dns leak em escala. No Docker, isso é obtido com uma rede personalizada sem gateway externo, mais liberação explícita de acesso apenas ao endereço do proxy. Adicionalmente, na configuração do resolver do contêiner, pode-se indicar um endereço comprovadamente inacessível, para que qualquer tentativa de resolução local falhe na hora, em vez de pendurar no timeout.

IPv6 no nível de sistema

Se o seu proxy móvel funciona por IPv4 e a máquina tem conexão IPv6, a solução mais simples e confiável é desligar o IPv6 na interface a partir da qual os perfis de proxy trabalham, ou proibir a saída IPv6 por firewall. É grosseiro, sim. Mas elimina toda uma classe de problemas em que um registro AAAA na resposta DNS desvia a conexão para fora.

Resolver do sistema e suas particularidades

Sistemas operacionais modernos têm resolvers em várias camadas. No Windows 11 há suporte a DoH no nível do sistema, e se ele estiver ativado para o seu adaptador, todas as resoluções locais irão ao servidor DoH escolhido. Para uma máquina de trabalho com proxy, é preciso ter consciência disso: o DoH do sistema ativado muda o quadro do vazamento, mas não o elimina. O Android usa o recurso Private DNS — história parecida para quem trabalha com proxy em dispositivos móveis ou emuladores. No Linux com systemd-resolved, vale checar quais servidores DNS estão atribuídos a cada interface, porque o resolver sabe rotear consultas por sufixos de domínio entre interfaces, e isso cria caminhos inesperados.

Monitoramento como processo

No nível da infraestrutura, a verificação de dns leak deixa de ser pontual e se torna contínua. Vale implantar:

  • Log de tentativas DNS bloqueadas pelo firewall. Cada registro no log é um aplicativo tentando resolver localmente. Essa é a sua lista para corrigir.
  • Seu próprio domínio de teste com subdomínios únicos por sessão e alerta automático ao aparecer um resolver estranho.
  • Captura periódica do tráfego de rede na porta 53 da interface física — uma vez por dia, automaticamente, com alerta se o contador não for zero.
  • Verificação depois de cada atualização de navegador, antidetect, bibliotecas. Atualizações são a principal fonte de regressões: desenvolvedores mudam padrões, ligam novas funcionalidades de pré-carregamento, adicionam DNS criptografado.

Checklist de nível de sistema

  • Tráfego de saída nas portas 53 e 853 bloqueado para os processos de trabalho.
  • Endereços DoH públicos conhecidos bloqueados para os mesmos processos.
  • IPv6 desligado ou bloqueado nas interfaces de trabalho.
  • Workers críticos isolados em network namespaces sem rota direta.
  • Logs do firewall de DNS coletados e revisados.
  • Domínio de teste e alertas configurados.

Erros típicos: o que não fazer

Erro 1. Verificar apenas o IP

O mais comum de todos. A pessoa vê o endereço da operadora móvel na página de verificação de IP e considera a tarefa resolvida. Mas a verificação de IP só responde à pergunta "de onde veio a conexão", e não "de onde vieram as consultas DNS". São perguntas diferentes, com respostas diferentes.

Erro 2. Configurar um DNS público e achar que resolveu

A lógica é compreensível: se o provedor vê minhas consultas, indico um resolver público. Mas, para trabalhar via proxy, isso não é solução, é trocar um vazamento por outro. As consultas continuam saindo do seu IP real, agora para outro observador. E, além disso, resolvers públicos usam ECS ativamente e passam a sua sub-rede aos servidores autoritativos. A discrepância entre o lado DNS e o lado da conexão continua.

Erro 3. Usar SOCKS5 sem DNS remoto

Esquema socks5 em vez de socks5h no código, socks_remote_dns desligado no navegador, antidetect com resolução local por padrão. Milhares de projetos vivem com esse erro há anos.

Erro 4. Achar que DNS criptografado resolve o problema

O DoH protege o conteúdo das consultas do provedor. Mas, ao trabalhar via proxy, ele cria um canal separado que não passa pelo proxy. Criptografia não é o mesmo que roteamento correto.

Erro 5. Ignorar o pré-carregamento e os serviços de fundo

O navegador resolve nomes de links que você ainda não abriu. O antivírus verifica URLs. O atualizador procura o servidor de updates. Tudo isso são consultas DNS que podem sair por fora. Verificação com um teste único não pega essas coisas.

Erro 6. Cache DNS compartilhado entre perfis

Se dois perfis em proxies de regiões diferentes compartilham o cache, o segundo perfil se conectará ao nó de CDN escolhido para a primeira região. O isolamento de perfis deve incluir o DNS.

Erro 7. Não testar depois de atualizações

A nova versão do navegador ligou o DNS seguro por padrão. A biblioteca atualizada mudou o comportamento SOCKS. A atualização do antidetect resetou as configurações do motor. Todos esses são cenários reais que só se revelam com nova verificação.

Erro 8. Permitir saída direta quando o proxy está indisponível

Configurações do tipo "se o proxy não responde, vai direto" transformam qualquer falha em desanonimização completa da sessão, começando pelo DNS. O comportamento correto é bloquear conexões até o proxy voltar.

Erro 9. Resolução manual "pela velocidade"

Alguns scrapers resolvem o domínio uma vez e depois andam por IP, para economizar no DNS. Além do vazamento da própria consulta, eles recebem um IP escolhido pelo geo-DNS para a sua região real, e depois rodam o tráfego pelo proxy móvel para um nó de CDN "alheio". A economia de milissegundos resulta num perfil inconsistente.

Ferramentas e recursos

Testes de vazamento on-line

Os serviços de verificação de dns leak se dividem em básicos e avançados. Os básicos fazem uma ou duas consultas e servem para uma estimativa rápida. Os avançados geram dezenas de subdomínios únicos e revelam vazamentos parciais. Para o trabalho, escolha os que mostram não só o IP do resolver, mas também a que ele pertence: organização, sistema autônomo, país. Um bom teste também mostra IPv4 e IPv6 separadamente e consegue verificar o comportamento em consultas repetidas.

Analisadores de tráfego

Wireshark — analisador gráfico com filtros como dns ou udp.port == 53. tcpdump — equivalente de console para servidores e máquinas Linux. Ambos permitem ver a verdade: o que realmente sai da interface de rede. Para DoH, veja também as conexões TLS para endereços de resolvers públicos.

DNS autoritativo próprio

Para monitoramento em escala: qualquer servidor DNS leve com log de consultas (CoreDNS, Unbound em modo autoritativo, BIND, servidores compactos em Go ou Python) mais um domínio próprio. O custo é mínimo, e o resultado é supervisão constante de todos os workers e perfis.

Ferramentas de linha de comando

dig e nslookup mostram a qual resolver o sistema recorre e o que ele responde. resolvectl no Linux com systemd-resolved mostra a configuração de DNS por interface. curl com a flag de saída detalhada mostra se ele passa o nome ao proxy ou resolve sozinho. No Windows, ipconfig /displaydns mostra o conteúdo do cache, e Get-DnsClientServerAddress no PowerShell, os servidores atribuídos por adaptador.

Firewalls

O firewall embutido do Windows com regras por programa, nftables e iptables no Linux, pf no macOS. Para facilitar o gerenciamento de regras por aplicativo, há complementos gráficos. O requisito-chave é poder bloquear portas para processos específicos e manter log de bloqueios.

Conteinerização

Docker e Podman com redes personalizadas, network namespaces do Linux via ip netns e, para fazendas de navegadores, orquestradores de perfis que suportam isolamento de rede no nível do perfil. Eles transformam a regra "só pelo proxy" de configuração em garantia arquitetural.

Recursos do lado do serviço de proxy

Preste atenção ao que o próprio fornecedor de proxy móvel oferece: suporte a SOCKS5 com resolução remota de nomes, modo HTTP com tratamento correto de CONNECT, estabilidade do DNS do lado da operadora, ausência de substituição de respostas DNS na infraestrutura. Vale perguntar ao suporte por quais resolvers os nomes são resolvidos na resolução remota — a resposta correta é: pelos resolvers da operadora móvel à qual o modem está conectado.

Casos e resultados

Caso 1. Fazenda de contas de anúncios e a causa invisível dos banimentos

Uma equipe de afiliados gerenciava cerca de 120 contas de anúncios em proxies móveis por meio de um antidetect popular. O tempo médio de vida da conta até o bloqueio se mantinha em 9–12 dias com configuração aparentemente impecável: IPs móveis da região certa, fingerprints cuidadosos, aquecimento. A auditoria mostrou que, depois de uma atualização do antidetect, o motor passou a ter DNS criptografado ativado, e todos os perfis resolviam nomes pelo mesmo resolver DoH público, a partir do IP real do escritório. 120 "usuários independentes" de cidades diferentes resolviam nomes de um único ponto. Depois de desligar o DoH, ativar o DNS remoto e bloquear a porta 53 no firewall, o tempo médio de vida das contas subiu para 30+ dias, e a proporção de bloqueios precoces na primeira semana caiu cerca de três vezes. O custo da correção: duas horas de trabalho de um especialista.

Caso 2. Scraper de marketplace e preços geográficos misteriosos

Um desenvolvedor coletava preços de um grande marketplace por região, via proxies móveis de cidades diferentes. Os dados não batiam com o que usuários reais daquelas regiões viam: parte dos preços e da disponibilidade correspondia a outra cidade. A causa estava na string de conexão: a biblioteca requests com esquema socks5 sem h. Os nomes eram resolvidos localmente na cidade do desenvolvedor, o geo-DNS do marketplace entregava o nó da região dele, e depois as requisições via proxy móvel de outra cidade chegavam a um nó "alheio", que devolvia a vitrine regional segundo sua própria lógica. Trocar uma letra na configuração e adicionar verificação automática de DNS na inicialização de cada worker restaurou a correção dos dados. Efeito colateral: caiu a proporção de requisições que o marketplace respondia com captcha — as sessões ficaram mais consistentes.

Caso 3. Teste de anúncios para públicos regionais

Uma agência de marketing verificava como anúncios e landing pages apareciam para usuários de regiões diferentes, trabalhando via proxies móveis e navegador Chromium com conexão SOCKS5. Parte das verificações mostrava conteúdo de região errada. Nos logs do domínio de teste próprio da agência, os resolvers pertenciam ao provedor do escritório. A migração para o modo HTTP dos mesmos proxies móveis, no qual o Chromium passa os nomes via CONNECT, mais o desligamento do pré-carregamento de páginas, eliminou a discrepância. Bônus extra — resultados de verificação estáveis, sem repetições, economizaram à equipe cerca de 15% do tempo nas auditorias regulares.

Caso 4. Multiaccounting em rede social e cache compartilhado

Um operador de dezenas de contas em rede social notou que contas que trabalhavam no mesmo dia passaram a ser bloqueadas em grupos. A análise mostrou dois fatores na camada DNS: o antidetect usava cache DNS compartilhado entre perfis, e parte dos perfis estava em SOCKS5 sem resolução remota. No fim, perfis em proxies de regiões diferentes se conectavam aos mesmos nós de CDN, e alguns ainda resolviam nomes de um único IP real. Depois de ativar o isolamento de cache por perfil e migrar todas as conexões para DNS remoto, os bloqueios em grupo cessaram; nos dois meses seguintes, as perdas de contas voltaram ao nível típico de um trabalho manual cuidadoso.

Conclusão geral dos casos

Nas quatro histórias os proxies estavam íntegros. O problema vivia do lado do cliente e custava semanas de trabalho, orçamentos e contas. A correção, a cada vez, levava horas. Essa proporção é uma característica típica justamente do dns leak: o problema é invisível sem verificação específica, mas se corrige facilmente se você sabe onde olhar.

FAQ: perguntas difíceis sobre vazamentos de DNS

Se o site não recebe minhas consultas DNS, como ele fica sabendo do vazamento?

Por três caminhos indiretos. O primeiro são subdomínios de teste únicos: o site pode forçar seu navegador a resolver um domínio que ele mesmo controla e ver de qual resolver veio a consulta. O segundo é o geo-DNS e a CDN: se você chega a um nó destinado a outra região, essa discrepância com o seu IP é visível do lado da infraestrutura. O terceiro é o EDNS Client Subnet: resolvers públicos passam a sub-rede do cliente aos servidores autoritativos, e ela não coincide com a sub-rede da conexão. Nenhum desses caminhos exige acesso ao seu provedor.

O proxy móvel resolve nomes pela operadora. Isso é bom ou ruim?

É ideal para a verossimilhança. Um assinante real de rede móvel resolve nomes pelos resolvers da operadora, e suas conexões chegam de endereços da mesma operadora. Quando o seu proxy faz o mesmo, o lado DNS e o lado da conexão pertencem à mesma rede. É exatamente esse estado que você deve ver nos testes: resolvers da operadora, IP da operadora, uma só região.

Em que o modo HTTP do proxy móvel é melhor que o SOCKS5 do ponto de vista do DNS?

No fato de que, no modo HTTP, o nome do host é passado ao proxy por definição do protocolo — no CONNECT para HTTPS e na URL para HTTP. O cliente não consegue resolver o nome localmente por acidente, salvo casos exóticos como scripts PAC. No SOCKS5, a resolução remota é uma opção que o cliente precisa escolher explicitamente, e muitos clientes não o fazem por padrão. Se você não tem certeza do comportamento de determinado navegador ou biblioteca, o modo HTTP é mais seguro. O SOCKS5 é mais cômodo para protocolos que não são HTTP, mas exige controle.

Basta simplesmente desligar o DNS seguro no navegador?

Não. Isso fecha um canal — o DoH do navegador. Restam a resolução local para SOCKS5, o pré-carregamento, os serviços de fundo, o DoH do sistema no SO e o IPv6. Desligar o DNS seguro é passo necessário, mas não suficiente. Suficiente é apenas a confirmação por teste avançado e, idealmente, o bloqueio do DNS direto no nível do sistema.

O que fazer se no teste aparecem resolvers que não pertencem nem a mim nem à operadora?

Investigar pela cadeia. Primeiro identifique a organização pelo IP: se for um serviço de DNS público, procure DoH ativado no navegador ou no sistema. Se for uma hospedagem desconhecida, talvez a infraestrutura do proxy use resolvers próprios em vez dos da operadora — confirme com o fornecedor. Se for o seu provedor, mas não o resolver que você viu na linha de base — talvez seja IPv6 ou outro adaptador. Todo resolver inesperado tem explicação, e ela precisa ser encontrada, não ignorada.

O dns leak afeta a velocidade ao trabalhar via proxy?

Afeta, e muitas vezes numa direção inesperada. Na resolução local, o geo-DNS escolhe o nó de CDN perto da sua localização real, e o tráfego depois vai pela rede móvel de outra região até esse nó — a rota fica mais longa que o ideal. Na resolução remota, o nó é escolhido perto da saída do proxy, e o caminho do proxy até o servidor é mais curto. Ou seja, a configuração correta de DNS geralmente não deixa mais lento, e em vários casos acelera o carregamento.

Como testar dns leak em cenários automatizados sem navegador?

O caminho mais confiável é o seu próprio domínio de teste. Na inicialização de cada worker, o script acessa via proxy um subdomínio único, e o seu servidor DNS autoritativo registra de qual resolver veio a consulta. O script então lê o log por API e compara o endereço do resolver com a faixa esperada da operadora. Se não houver correspondência, a sessão não inicia. Isso transforma a verificação de manual em contratual: o worker não tem o direito de trabalhar enquanto não provar a limpeza do DNS.

Como o quadro muda com a difusão do ECH e do DNS criptografado em 2026?

O cenário caminha na direção de "o DNS fica mais importante". O ECH depende de registros DNS do tipo HTTPS, os navegadores ligam o DNS criptografado por padrão, os sistemas operacionais adicionam DoH e DoQ de sistema. Para o usuário comum, isso é um ganho de privacidade. Para quem trabalha via proxy, significa mais tráfego DNS, mais clientes DNS independentes dentro do sistema e mais pontos em que a consulta pode escapar do proxy. Os sistemas antifraude, por sua vez, usam cada vez mais a consistência entre o lado DNS e o lado da conexão como sinal. Conclusão: a disciplina no trabalho com DNS deixa de ser "desejável" e passa a ser "obrigatória".

Dá para confiar num navegador antidetect que afirma ter proteção contra dns leak?

Confiar — sim; verificar — obrigatório. A afirmação do marketing não elimina regressões após atualizações, diferenças entre motores e as particularidades da sua configuração de proxy. Verifique cada perfil depois de criar e depois de cada atualização do navegador. Um teste avançado leva um minuto, e recuperar uma fazenda queimada leva semanas.

Conclusão: o DNS como fundamento de uma sessão limpa

Vamos resumir. O proxy muda o endereço de onde vem a conexão, mas não garante que a resolução de nomes siga o mesmo caminho. A consulta DNS acontece antes da conexão, e é justamente nessa fresta que nasce o dns leak. Para usuários de proxies móveis isso é especialmente crítico: todo o valor do IP móvel está na sua semelhança com um assinante real, e um assinante real resolve nomes pela sua operadora. A discrepância entre o lado DNS e o lado da conexão denuncia o uso de proxy com mais confiabilidade que muitos outros sinais.

Vimos como o DNS vaza em diferentes cenários: SOCKS sem resolução remota, DNS criptografado em navegadores e sistemas, pré-carregamento, cache compartilhado, IPv6, scripts PAC e resolução prévia no código. Demos quatro métodos que funcionam juntos: diagnóstico com linha de base e teste avançado, configuração correta de clientes e bibliotecas, ajuste de navegadores e antidetects e, por fim, proteção forçada no nível do firewall e do isolamento de rede. Cada método, sozinho, fecha parte do problema. Todos juntos — tornam o vazamento tecnicamente impossível.

Seus próximos passos

  1. Hoje: registre a linha de base sem proxy, depois passe no teste avançado de dns leak em cada perfil de trabalho e em cada script. Anote os resultados.
  2. Nesta semana: verifique todas as strings de conexão no código em busca de socks5 sem h, desligue o DNS criptografado e o pré-carregamento nos navegadores, garanta o isolamento de cache entre perfis.
  3. Neste mês: bloqueie o DNS direto no nível do sistema para os processos de trabalho, desligue ou bloqueie o IPv6 nas interfaces de trabalho, suba um domínio de teste próprio com logging.
  4. Sempre: repita a verificação depois de cada atualização de navegador, antidetect e bibliotecas. Transforme isso num ritual, como a verificação de IP.

Um bom proxy móvel te dá um endereço verossímil e resolvers verossímeis da operadora. Sua tarefa é não perder essa vantagem no último metro, dentro do seu próprio sistema. Configure o DNS uma vez, corretamente, transforme a verificação em hábito, e toda uma categoria de bloqueios inexplicáveis simplesmente desaparecerá da sua prática. Não foi para isso que você leu este guia até o fim?