Você recebeu 403 — e a primeira coisa que geralmente se faz é tentar mudar o proxy. Às vezes ajuda, na maioria das vezes não. Porque "antibot" não é uma única tecnologia, mas pelo menos seis sistemas diferentes com mecânicas de detecção variadas, rigorosidade diferente e requisitos distintos para o seu tráfego. O que protege contra a Imperva é inútil contra a Kasada. Vamos analisar quem é quem em 2026, como identificar o fornecedor em 30 segundos e o que exatamente mudar na pilha de proxies para cada um.
Por que "simplesmente mudar o proxy" parou de funcionar
A lógica clássica era simples: bloqueou o IP — pegamos outro. Isso funcionava enquanto a detecção se baseava na reputação do endereço. Hoje, o IP é apenas uma camada entre cinco, e para diferentes fornecedores, seu peso é fundamentalmente diferente.
O conjunto geral de sinais que de alguma forma todos usam:
- Fingerprint TLS (JA3/JA4) — ordem dos conjuntos de criptografia e extensões no handshake;
- ordem e registro dos cabeçalhos HTTP — no cliente Python não é o mesmo que no Chrome;
- reputação do IP — ASN, pertencimento ao data center, histórico do endereço;
- fingerprint do navegador — canvas, WebGL, sensores de hardware;
- biometria comportamental — trajetórias do mouse, velocidade de rolagem, padrão de entrada.
A conclusão chave que todos os pesquisadores do tema repetem: a consistência dos sinais é importante. A combinação do User-Agent do Chrome com o fingerprint TLS do Python marca você como bot para qualquer um dos fornecedores — independentemente de quão limpo seja seu IP. Um endereço residencial não "cobre" uma camada de navegador vulnerável, e vice-versa.
Passo um: identificar o fornecedor pelos rastros
Antes de mudar algo, olhe os cabeçalhos de resposta e cookies. Cada sistema deixa uma assinatura reconhecível — essa é a maneira mais rápida de entender com o que você está lidando.
- Cloudflare — cabeçalho CF-RAY, cookies cf_clearance e __cf_bm, carrega challenge.js; em novas versões, pode haver o cabeçalho cf-mitigated.
- DataDome — cookies datadome e _dd_s, script tags.js.
- Akamai — cookie _abck, cabeçalho de referência akamai-grn.
- PerimeterX (HUMAN Security) — cookies _px3, _pxvid, _pxhd, scripts px.js ou d.js.
- Kasada — cabeçalhos da família x-kpsdk-* (ct — token de desafio, dv — validação de dispositivo, cd — dados de desafio, v — versão), cookie KP_UIDz, scripts ips.js ou p.js.
- Imperva (Incapsula) — cookies incap_ses_*, visid_incap_*, reese84.
- AWS WAF — cookie aws-waf-token, chamada do endpoint /challenge.js.
- F5 / Shape Security — cookies com o prefixo TS (por exemplo, TS01a2b3c4).
Um marcador separado é o próprio caráter da recusa. A Kasada responde com um "nude" 429 sem corpo de resposta: se você vê 403 ou 429 junto com os cabeçalhos x-kpsdk-*, a questão está resolvida. A DataDome frequentemente retorna 403 com uma página CAPTCHA. A Cloudflare — um desafio interativo ou Turnstile.
Como os sistemas realmente diferem na mecânica
A assinatura diz "quem", mas a tática é definida pelo "como". Arquitetonicamente, os fornecedores divergem bastante.
Cloudflare — modelos globais na borda da rede
Opera no nível da borda CDN: a decisão é tomada antes que a solicitação chegue ao aplicativo. Os modelos são globais, treinados no tráfego de toda a rede — cerca de um quinto dos sites da internet. O lado positivo para você: o comportamento é previsível, a experiência de um site se transfere para outro. O lado negativo: a rede vê sua sub-rede em milhares de recursos simultaneamente, a reputação se acumula rapidamente.
DataDome — modelo personalizado para cada site
A principal diferença: a plataforma mantém cerca de 85.000 modelos de ML de clientes, treinados no tráfego de um site específico, e processa mais de 5 trilhões de sinais por dia com um tempo de resposta inferior a 2 milissegundos. A consequência prática é simples e desagradável: cada site protegido é uma tarefa separada. A combinação que funciona para Etsy não se transfere para outro recurso sob o mesmo fornecedor. Em 2025, foi adicionado a análise de intenção (avaliando o objetivo da visita, e não apenas o fato da automação) e uma categorização separada de crawlers LLM.
Akamai — foco em TLS e telemetria
Verifica os sinais do handshake e valida a telemetria comportamental do seu lado através do cookie _abck. De acordo com medições independentes de 2026, a Akamai e a Imperva desafiam clientes automatizados padrão menos frequentemente do que a Cloudflare e a DataDome — mas isso não significa "mais fraco": onde está configurado de forma agressiva, a superação requer uma camada TLS correta, e não apenas a troca de IP.
PerimeterX / HUMAN — reputação de rede
A reputação do cliente se espalha por toda a rede do fornecedor. Se você foi pego em um site — chega a outro já marcado. Plataformas típicas: e-commerce e imóveis.
Kasada — interrogatório ativo do ambiente
A mais rigorosa das sistemas massivos. Não apenas coleta impressões digitais, mas interroga ativamente o ambiente: inspeciona o código do cliente através de Function.prototype.toString(), aplica anti-ofuscação em seus próprios scripts. Em avaliações agregadas de complexidade, recebe notas extremas tanto em sofisticação de detecção quanto em dificuldade de superação independente. É utilizada em ticketing e imóveis.
Imperva (Incapsula) — lógica WAF por padrão
Baseia-se no IP e nas regras WAF; camadas comportamentais são ativadas em configurações mais altas. Plataformas clássicas — sites corporativos e boards de empregos.
Quem é mais rigoroso: números em vez de sensações
Há um benchmark independente Scrapeway: oito serviços contra onze alvos, mais de 1000 solicitações por serviço por alvo, dois relatórios por mês. Os alvos estão vinculados aos fornecedores — Indeed sob Cloudflare, Etsy sob DataDome, Walmart e Zillow sob PerimeterX, Realtor sob Kasada.
O que as medições de 2026 mostram:
- Alta rigorosidade — Cloudflare, DataDome, PerimeterX, Kasada: a esmagadora maioria dos clientes automatizados padrão e não configurados recebe um desafio.
- Moderada — Akamai e Imperva: desafiam clientes padrão com muito menos frequência.
- Contra alvos da Cloudflare, apenas uma pequena fração de clientes não configurados conseguiu acessar o conteúdo da página de forma consistente.
Para comparação: serviços de superação especializados mantêm sucesso contra esses alvos na faixa de 94–100%, dependendo do fornecedor — ou seja, a tarefa é solucionável, mas não com um cliente padrão e não apenas trocando o IP.
O que mudar na pilha de proxies para cada um
Agora a prática. Abaixo — não é uma receita de superação, mas a lógica de seleção da infraestrutura para o tipo de detecção.
- Imperva e AWS WAF. O peso do IP é alto, as camadas comportamentais frequentemente estão desligadas. Aqui proxies de data center ainda são viáveis — desde que as sub-redes sejam limpas e a taxa razoável. Comece por aqui, é o mais barato em termos de tráfego.
- Akamai. Proxies resolvem menos do que a camada TLS. Primeiro, organize o handshake e a ordem dos cabeçalhos, e só então eleve a classe do IP. Trocar o proxy com um fingerprint JA4 incorreto não trará resultados.
- Cloudflare. A reputação global significa que a sub-rede se esgota rapidamente e imediatamente em todos os lugares. Precisamos de proxies residenciais com um amplo pool e rotação razoável: não "um novo IP para cada solicitação", mas manter a sessão durante o tempo da tarefa lógica, caso contrário, o cf_clearance se desfaz.
- DataDome. O modelo é treinado no tráfego de um site específico, portanto, o mais importante é a homogeneidade do seu comportamento especificamente nele. Um IP residencial dá uma pontuação de confiança positiva, porque pessoas reais acessam de conexões residenciais — mas por si só, sem gerenciar o fingerprint do navegador, não garante nada. Não transfira configurações de um site para outro às cegas. Detalhes sobre a especificidade deste fornecedor estão na análise proxies para DataDome.
- PerimeterX / HUMAN. Como a reputação é de rede, a isolação é mais importante que o volume: diferentes projetos — diferentes pools, para que a marca de uma plataforma não se estenda para outras.
- Kasada. Endereços de data center são bloqueados na entrada. O mínimo operacional — residenciais, ou melhor proxies móveis: por trás de um único IP móvel através de CGNAT estão centenas de assinantes vivos, e é mais caro para o sistema banir esse endereço. Além disso, a correspondência obrigatória do User-Agent com a versão atual do navegador — uma string desatualizada revela a combinação instantaneamente.
O principal erro: pilha heterogênea
Vamos repetir o que começamos, porque essa é a razão da maioria dos banimentos "inexplicáveis". Todos os seis sistemas capturam desincronização entre as camadas. IP residencial da Alemanha + fuso horário do sistema UTC + fingerprint TLS do curl + Chrome atualizado no User-Agent — isso não é "quase passou", é um perfil de bot pronto. O proxy responde exatamente por uma camada entre cinco; as outras quatro vivem no seu cliente.
Daqui, a ordem prática de trabalho: primeiro, identifique o fornecedor pela assinatura, depois avalie qual camada está mais fraca e conserte-a — e não a que é mais fácil de mudar. Se, após organizar a pilha, os alvos ainda estiverem inacessíveis, a questão passa para "construir por conta própria ou pagar por algo pronto" — essa bifurcação foi discutida no material proxies contra scraping API e desbloqueadores web.
Resumindo
Não existe um único "antibot", e também não há uma superação universal — nenhuma técnica funciona contra todos os oito sistemas ao mesmo tempo. Identifique o fornecedor pelos cookies e cabeçalhos (isso leva 30 segundos), entenda sua mecânica — peso do IP na Imperva, TLS na Akamai, reputação global na Cloudflare, modelo personalizado do site na DataDome, marca de rede na PerimeterX, interrogatório ativo do ambiente na Kasada — e escolha o tipo de proxy para isso, e não ao acaso. Data center onde olham para o IP de forma formal; residenciais onde consideram a confiança; móveis onde a rede bloqueia rigidamente tudo que é servidor. E mantenha a consistência de todas as camadas: é exatamente nela que a maioria dos projetos que parecem estar configurados corretamente falham.
```