Como os Sites Detectam Proxies: Todos os Sinais e Como Passar por Cada Um
A detecção de proxies não é um único teste, é uma pilha deles - e a maioria das configurações 'indetectáveis' falha nos mais simples primeiro. Aqui estão todos os sinais que um site usa para identificar um proxy e a contramedida para cada um.
Os sites não detectam proxies com um único truque inteligente. Eles executam uma pilha de verificações independentes, e uma conexão precisa passar por todas elas - então as configurações que as pessoas chamam de "indetectáveis" geralmente falham nos sinais mais simples primeiro: um cabeçalho vazado, um IP de datacenter, uma impressão digital TLS que não corresponde ao navegador que afirma ser. Entender como os sites detectam proxies camada por camada é a única maneira de raciocinar sobre quais você realmente vai passar. Aqui está a pilha completa de sinais e a contramedida para cada um.
Sinal 1: o endereço IP e seu ASN
A primeira e mais barata verificação é consultar o IP em um banco de dados. Serviços comerciais - MaxMind, spur.us, IP2Proxy, IPHub, proxycheck.io - classificam endereços pelo seu Número de Sistema Autônomo (ASN), o bloco ao qual um IP pertence. ASNs de datacenters e hospedagem são facilmente sinalizados, por isso um IP de servidor em nuvem é bloqueado antes mesmo de qualquer outra verificação ser executada. IPs residenciais e móveis pertencem a ASNs de ISPs de consumidores, então eles passam por este filtro por padrão. Este único sinal é o motivo pelo qual proxies residenciais têm sucesso onde IPs de datacenter falham - o ASN diz "banda larga residencial", não "AWS". DNS reverso é uma verificação relacionada: um registro PTR apontando para um provedor de hospedagem é outro indício.
Sinal 2: cabeçalhos HTTP que anunciam um proxy
Proxies mal configurados vazam. Cabeçalhos como Via, X-Forwarded-For, Forwarded e Proxy-Connection literalmente existem para declarar que o tráfego passou por um intermediário, e um proxy transparente que os encaminha entrega ao site uma confissão. A ordem dos cabeçalhos e a coerência também importam: uma solicitação alegando ser do Chrome, mas enviando cabeçalhos em uma ordem não-Chrome, é uma incompatibilidade de impressão digital. A solução é um proxy que não injete cabeçalhos de encaminhamento e um cliente que envie um conjunto de cabeçalhos consistente com o navegador que está imitando.
Sinal 3: TLS e a impressão digital JA3
Antes de qualquer HTTP ser enviado, o handshake TLS expõe uma impressão digital (JA3/JA4) construída a partir dos conjuntos de cifras e extensões exatas que seu cliente oferece. Uma biblioteca HTTP em Python ou Go produz um handshake que não se parece em nada com o do Chrome - então uma solicitação com um user-agent do Chrome, mas uma impressão digital TLS do Python, é instantaneamente incoerente, e nenhum proxy corrige isso, porque está acontecendo abaixo da camada do proxy. É por isso que IPs limpos ainda são bloqueados: o IP passou, o TLS não. Nosso mergulho profundo em impressões digitais TLS JA3/JA4 cobre as bibliotecas de imitação que fazem o handshake de um cliente corresponder a um navegador real.
Sinal 4: vazamentos de DNS e WebRTC
Mesmo com um IP perfeito, sua localização real pode vazar lateralmente. Se o DNS for resolvido na sua máquina em vez de através do proxy, a localização do resolvedor o trai - o que é exatamente por isso que os usuários de SOCKS5 devem usar o esquema socks5h para que o DNS passe pelo túnel. Em um navegador real, o WebRTC é pior: ele pode revelar o IP local e público verdadeiro diretamente para uma página via uma API de mídia, passando direto pelo proxy. Configurações anti-detecção desativam o WebRTC ou o roteiam através do proxy por esse motivo. Ambos são vazamentos de "canal lateral" - o proxy está bem, mas algo ao redor dele não está.
Sinal 5: latência, coerência geográfica e comportamental
As verificações mais sutis procuram por coisas que não fazem sentido. Um proxy insere um salto de rede extra, e técnicas de pesquisa (a análise de latência acadêmica estilo "BadPass") comparam tempos de ida e volta para identificar a assinatura de dois saltos - embora isso se degrade contra saídas residenciais de baixa latência e IPs móveis. A coerência de geolocalização importa mais na prática: se o IP diz Alemanha, mas o fuso horário do navegador, cabeçalhos de idioma e localidade dizem Nova York, essa discrepância é um forte sinal. IPs móveis são os mais difíceis de bloquear, porque o NAT de nível de operadora significa que um endereço é compartilhado por milhares de usuários reais ao mesmo tempo - bloqueá-lo eliminaria clientes genuínos. Essa é a lógica por trás de por que proxies móveis são confiáveis.
Verifique a pontuação de fraude e os sinais de proxy de qualquer IP gratuitamente
Juntando tudo: coerência supera qualquer truque único
A linha de raciocínio é a coerência. A detecção não é uma parede; é um conjunto de observações independentes que ou concordam ou não. Um IP residencial com cabeçalhos de proxy vazados ainda falha. Um IP limpo com uma impressão digital TLS do Python ainda falha. A configuração vencedora é consistentemente entediante de ponta a ponta: um IP atribuído por ISP, sem cabeçalhos de encaminhamento, um handshake TLS compatível com o navegador, DNS e WebRTC roteados pelo túnel, e uma pilha de geo/fuso horário/idioma que aponta para o mesmo lugar. Antes de fazer scraping em um alvo difícil, teste sua saída contra um verificador para saber quais sinais você está vazando. Nossa comparação de reputação de IP vs impressão digital de dispositivo cobre qual camada corrigir primeiro.
Também vale saber que a detecção raramente é um sim ou não definitivo. A maioria dos sistemas atribui uma pontuação de risco e age com base em limites: um sinal ligeiramente suspeito pode apenas adicionar fricção - um CAPTCHA, uma versão mais leve da página - enquanto uma pilha de bandeiras vermelhas resulta em um bloqueio total. É por isso que perseguir um único truque "indetectável" é o modelo mental errado. Cada vazamento que você fecha reduz a pontuação, e abaixo do limite o site o trata como qualquer outro visitante. Corrija os maiores sinais primeiro (tipo de IP, depois cabeçalhos e TLS), re-teste, e geralmente você passará sem nunca precisar das contramedidas exóticas que as pessoas obsessivamente buscam.
Perguntas frequentes
Como os sites detectam proxies?
Eles executam uma pilha de verificações: consultando o IP em um banco de dados de proxy pelo seu ASN, inspecionando cabeçalhos HTTP para sinais de encaminhamento, identificando a impressão digital do handshake TLS, observando vazamentos de DNS e WebRTC, e testando a coerência geográfica e de latência. Uma conexão precisa passar por todas elas. A maioria das configurações falha na verificação de IP ou cabeçalho antes mesmo das mais sutis importarem.
Proxies residenciais podem ser detectados?
Proxies residenciais passam pela verificação de ASN que elimina IPs de datacenter, mas não são automaticamente invisíveis. Se o seu cliente vazar cabeçalhos de encaminhamento, enviar uma impressão digital TLS não compatível com o navegador ou expor seu IP real via DNS ou WebRTC, um site ainda pode sinalizar a sessão. IPs residenciais removem o maior sinal; coerência no resto é o que mantém você limpo.
Como posso testar se meu proxy é detectável?
Execute o IP de saída através de um verificador de pontuação de fraude ou proxy - ele relata a classificação ASN, se o IP está em listas conhecidas de proxy e sua reputação. Nosso verificador de IP gratuito mostra a pontuação de fraude e os sinais de proxy que um site alvo veria, para que você possa identificar um IP queimado antes que ele queime sua execução.
Por que IPs limpos ainda são bloqueados?
Porque o IP é apenas um sinal. Um IP residencial novo emparelhado com uma impressão digital TLS do Python ou Go, cabeçalhos vazados ou uma discrepância de geo/fuso horário é incoerente, e o site bloqueia pela contradição, não pelo endereço. Corrigir a detecção significa alinhar todas as camadas - IP, cabeçalhos, TLS e vazamentos - não apenas obter um IP melhor.
A detecção de proxy recompensa a consistência e pune a contradição. Comece com um IP residencial ou móvel para passar pela verificação de banco de dados, depois certifique-se de que nada ao redor dele discorde - cabeçalhos, TLS, DNS, WebRTC e geo todos contando a mesma história. Teste antes de escalar, e você saberá exatamente qual sinal corrigir em vez de adivinhar.