As equipes que se defendem de bots e as equipes que os constroem estão travadas em uma corrida armamentista em câmera lenta há cerca de quinze anos. A fronteira se moveu a cada poucos anos, e cada mudança forçou um tipo diferente de investimento das equipes de dados. Vale a pena conhecer a linha do tempo aproximada, porque o estado atual do jogo não é óbvio de fora, e muitos conselhos na internet estão duas gerações de anti-bot desatualizados.
Geração 1: listas de bloqueio de IP e limites de taxa
As primeiras defesas eram procedurais. Uma requisição chegava, o servidor anotava o IP, e se aquele IP fizesse qualquer coisa obviamente parecida com máquina, requisições demais por minuto, uma sequência previsível demais, um User-Agent pequeno demais, ele era limitado por taxa ou banido de vez. Listas de faixas de IP de datacenter conhecidas circulavam por aí. Qualquer coisa vinda da AWS ou da DigitalOcean era tratada com suspeita.
Essa foi a era em que a resposta para “como faço scraping do site X” era quase sempre “use um proxy”. Especificamente, um proxy de datacenter. Compre um /24, rotacione por ele, problema resolvido.
Funcionava porque os defensores não tinham muito mais o que fazer.
Geração 2: CAPTCHAs e o imposto de atrito ao usuário
Quando as defesas em nível de IP começaram a falhar, os defensores empurraram o atrito para o usuário. Os CAPTCHAs se tornaram universais, primeiro os de correspondência de imagens, depois o reCAPTCHA, depois o reCAPTCHA invisível, depois o hCaptcha, o Turnstile e o Arkose.
Os CAPTCHAs funcionam, no sentido de que quebram scrapers ingênuos. Também funcionam no sentido de que irritam usuários reais o suficiente para reduzir a conversão de forma mensurável. A maioria dos sites que usou camadas agressivas de CAPTCHA na janela de 2017-2020 recuou desde então, porque o custo do atrito superava o custo dos bots.
Do lado dos scrapers, os CAPTCHAs geraram toda uma indústria de serviços de resolução com humanos no processo. Pague alguns centavos por resolução, coloque seus CAPTCHAs em fila para um painel de trabalhadores em regiões de baixo custo, receba o token de volta, continue fazendo scraping. Não é elegante, mas funcionava.
Geração 3: fingerprinting de navegador e comportamental
A terceira geração subiu na pilha. Os sites começaram a fazer fingerprinting do próprio cliente, não apenas do IP, mas do navegador. Fingerprinting de canvas, assinaturas WebGL, listas de fontes, contexto de áudio, fuso horário, preferências de idioma, dimensões de tela, plugins disponíveis, a ordem em que as cifras TLS eram propostas no handshake (fingerprints JA3 / JA4), o tempo dos movimentos do mouse, a cadência das teclas digitadas.
O Chromium headless sem endurecimento específico vaza dezenas desses sinais. Os defensores construíram bibliotecas (Fingerprint.js, os vários equivalentes comerciais) que pontuavam as requisições nessa superfície e rejeitavam qualquer coisa que parecesse limpa demais, mecânica demais, ou diferente demais do navegador de um usuário real.
Foi aí que o scraping ficou difícil. Um IP residencial sozinho não bastava mais. Era preciso operar um navegador de verdade, ou um headless suficientemente bom com fingerprints corrigidos, e fazer o comportamento parecer natural. O proxy continuava essencial, mas havia se tornado um componente entre outros em uma pilha, e não a resposta inteira.
Geração 4: reputação em nível de rede
A fronteira atual é a mais cara para todos. Os defensores agora compram dados de reputação de provedores de rede como Cloudflare, Akamai, e uma dúzia de especialistas menores. Cada IP recebe uma pontuação de reputação que agrega sinais de milhões de sites: esse IP já foi visto fazendo login em contas bancárias, em fluxos de checkout, abrindo o Gmail normalmente? Ou já foi visto acessando endpoints de login em padrões que sugerem credential stuffing, postando comentários em cadências de máquina, fazendo scraping de páginas de preços de concorrentes às 3h de uma terça-feira?
Um IP de datacenter tem, quase por definição, um histórico de rede escasso ou negativo. Ele não fez coisas humanas normais. Um IP residencial, por outro lado, tem anos de tráfego mundano por trás dele: a residência que ele atende o usa para Netflix, Steam, Zoom, navegação normal. É essa reputação que protege os scrapers hoje.
Os proxies ISP ficam em um meio-termo interessante: são emitidos por ISPs residenciais reais (de modo que o provedor upstream corresponde a uma faixa de IP residencial), mas são alocados a data centers e mantidos de forma estática. São mais difíceis de detectar do que IPs de datacenter puros, mas mais fáceis do que residenciais rotativos, e o preço reflete isso.
O que isso significa para as equipes de dados em 2026
Algumas coisas permaneceram verdadeiras ao longo das quatro gerações e continuarão sendo:
O proxy certo é necessário, mas não suficiente. Um IP residencial real te faz passar pelo portão em nível de rede. A partir daí, seu cliente, seus cabeçalhos, seu fingerprint TLS e seus padrões comportamentais ainda precisam ser plausíveis.
A taxa de bloqueio é a única métrica que importa. Não o tamanho do pool, não a contagem de países, não os recursos anunciados. Se seus scrapes retornam HTML limpo a um custo aceitável, a infraestrutura está funcionando. Se não retornam, nenhuma alegação de marketing vai ajudar.
O proxy certo depende do fluxo de trabalho. Rotação por requisição em um pool residencial gigante é o correto para tarefas de monitoramento de preços em leque. Sessões fixas (sticky) em um único IP residencial por dez minutos é o correto para fluxos multi-página. IPs ISP fixos são o correto para gerenciamento de contas e qualquer fluxo de trabalho que precise da mesma identidade ao longo de semanas ou meses. Não escolha uma única ferramenta para todas as tarefas.
O anti-bot vai continuar subindo na pilha. A próxima camada é provavelmente uma análise comportamental mais agressiva na borda, classificadores treinados por aprendizado de máquina que observam a forma de sessões de vários minutos, não características de requisições isoladas. Isso já está em produção nos maiores sites. A corrida armamentista dos defensores se acumula, e o custo de continuar nela também.
A conclusão honesta: ninguém que te diga que o scraping está “resolvido” está certo. É um problema operacional, e a operação é o que você paga. Os proxies residenciais continuam sendo a base porque ainda são o único lugar onde o IP upstream carrega o tipo certo de histórico. Tudo o mais se apoia nisso.