Como funciona a detecção de bots: a lógica anti-bot

O responsável por uma loja online abre o relatório da manhã: às três da madrugada o número de visitantes quadruplicou, as adições ao carrinho não mudaram e a página de login registra milhares de tentativas sem sucesso. Quanto desse tráfego é buscador, quanto é serviço de comparação de preços, quanto é um script testando senhas roubadas? A detecção de bots é o esforço do dono do site para responder a essa pergunta em cada requisição, em milissegundos.

Neste artigo descrevemos a detecção de bots pelo lado do dono do site: por quais camadas uma requisição passa, o que cada camada mede, como os sinais viram uma única pontuação e quem paga a conta quando essa pontuação erra. Resumimos seis camadas em ordem e deixamos o detalhe para o artigo próprio de cada uma. Como os navegadores headless são reconhecidos, como os bots bons comprovam quem são e qual é o caminho legítimo para quem opera automação também estão aqui. Formas de contornar proteções não são o assunto deste artigo.

O que é detecção de bots?#

Detecção de bots é o trabalho de distinguir se uma requisição que chega a um site veio do navegador usado por uma pessoa ou de um programa automático. O software que faz isso é chamado de sistema anti-bot, proteção contra bots ou gerenciamento de bots; a maior parte dele roda não no código do próprio site, mas no CDN ou no firewall de aplicação web (WAF) que fica à frente. Cloudflare, Akamai e DataDome são fornecedores citados com frequência nessa área. O sistema busca resposta para duas perguntas: a requisição é automática e, se for, é do tipo desejado?

O que é tráfego de bots: como separar bots bons de ruins?#

Tráfego de bots é toda requisição produzida pela decisão de um programa, e não pelo clique de uma pessoa. Nos logs, três tipos ficam lado a lado:

• Os bots que o site quer. Rastreadores de buscadores, serviços que monitoram disponibilidade, aplicativos de mensagem que geram prévias de links, a própria automação de testes do site.
• Os bots que o site pondera. Serviços de comparação de preços, ferramentas de arquivamento, rastreadores de IA, scripts de pesquisa. Alguns sites abrem a porta, outros aceitam com limite de velocidade.
• A automação que o site não quer. O projeto de ameaças automatizadas da OWASP cataloga esse grupo dando nome a ele: o teste em massa de senhas roubadas (credential stuffing), a validação de números de cartão roubados (carding), a compra automatizada de estoque limitado (scalping) e a cópia em massa de conteúdo (scraping) estão nessa lista.

A dificuldade é que os três se parecem na rede. Por isso o sistema não olha um sinal isolado, e sim a soma das camadas.

Em que ordem uma requisição é avaliada?#

1. A conexão chega. Antes de qualquer conteúdo ser lido, o IP de origem já é conhecido; consultam-se sua reputação, seu país e sua rede.
2. O handshake TLS acontece. A primeira mensagem (ClientHello) carrega uma pista sobre qual software está falando.
3. A conexão HTTP é estabelecida. No HTTP/2 o cliente anuncia suas configurações de conexão; depois vêm o método, o endereço e os cabeçalhos.
4. A pontuação do lado do servidor é calculada. Os sinais dos três primeiros passos se juntam ao histórico recente do endereço; a requisição já pode ser recusada aqui.
5. A página chega ao navegador. Um pequeno script na página examina o ambiente do navegador e devolve o resultado.
6. A sessão é acompanhada. A frequência das requisições, a ordem de navegação e a interação atualizam a pontuação ao longo da sessão.
7. Se o limiar for ultrapassado, vem a ação. Um limite de velocidade, uma tela de verificação ou um bloqueio.

Os quatro primeiros passos acontecem no servidor sem que o visitante perceba nada; o quinto e o sexto só produzem dados em clientes que executam JavaScript.

As camadas em uma tabela: o que cada camada mede?#

A última coluna carrega a ideia central do artigo: cada camada tem um grupo de pessoas com quem erra, e os limiares são ajustados sabendo desse custo.

A camada de rede: o que dizem a reputação do IP e o ASN?#

O endereço IP é a informação mais precoce sobre uma requisição. O sistema olha o histórico de abuso do endereço, seu país e, pelo ASN (número de sistema autônomo), a qual rede ele está registrado. Uma requisição vinda da rede de uma empresa de hospedagem e outra vinda de um bloco que um provedor reserva a assinantes residenciais não recebem o mesmo tratamento: usuários domésticos não saem para a internet por um data center. Como os sites classificam um endereço como «provedor» ou «hospedagem» explicamos em Proxy ISP e proxy residencial: diferenças.

A reputação vem de duas fontes: listas negras que registram se o endereço já foi denunciado como origem de spam ou ataque (listas negras de IP) e serviços de pontuação de risco que reduzem a um único número o tipo do endereço e se ele é saída de proxy ou VPN (IP Fraud Score). A fraqueza da camada é medir o endereço, não a pessoa. Operadoras móveis e muitos provedores colocam um número enorme de assinantes atrás do mesmo endereço (CGNAT); um script rodando dali derruba a reputação de todo mundo que divide aquele endereço.

A camada de protocolo: impressão digital TLS e configurações de HTTP/2#

Na primeira mensagem de uma conexão HTTPS, o cliente envia de forma aberta as suítes de cifra que suporta, as extensões e a ordem delas. A lista muda de navegador para navegador e de biblioteca para biblioteca; quando o servidor a transforma em um resumo curto (JA3 e JA4 são formatos comuns), ele passa a ter uma marca independente dos cabeçalhos. Uma requisição cujo cabeçalho User-Agent diz Chrome mas cujo handshake se parece com o de uma biblioteca Python se destaca por essa incoerência. O detalhe do cálculo e seus limites estão em Impressão digital TLS e JA3.

A RFC 9113 exige que os dois lados enviem um quadro SETTINGS no início de uma conexão HTTP/2. Os valores desse quadro e a ordem em que os pseudocabeçalhos (:method, :authority, :scheme, :path) são enviados variam em cada pilha HTTP. O valor da camada é não depender de nenhuma declaração; o risco é que funcionários atrás de equipamentos de segurança corporativos, que abrem e refazem o tráfego TLS, cheguem com um handshake que não combina com o navegador deles.

A camada de cabeçalhos: User-Agent e coerência#

Cabeçalhos são a declaração que o cliente faz sobre si mesmo: o User-Agent informa o navegador e o sistema operacional, os cabeçalhos de Client Hints (a família Sec-CH-UA) repetem a mesma informação de forma estruturada e o Accept-Language anuncia a preferência de idioma. Ninguém verifica essa declaração; qualquer programa pode escrever o valor que quiser. Como essa cadeia é lida está em O que é o User-Agent?.

Por isso o sistema anti-bot não olha a declaração em si, e sim o encaixe dela com as outras camadas. A versão de navegador declarada realmente envia aquele conjunto de cabeçalhos, naquela ordem? A preferência de idioma combina com o país do IP, e o fuso horário com o que o navegador informa? Nenhuma incoerência é prova sozinha (quem mora fora se conecta de outro país com o navegador no idioma natal), mas cada uma puxa a pontuação um pouco para baixo.

A camada do navegador: sinais de JavaScript#

Quando a página abre, a proteção alcança um terreno que não via pelo servidor: o próprio navegador. Um script inserido na página lê as medidas da tela, as fontes instaladas, o resultado de desenho do hardware gráfico, o fuso horário e as APIs suportadas; a combinação desses valores é a impressão digital do navegador. Ela serve para duas coisas: reconhecer o mesmo cliente mesmo com o IP mudando e testar se o ambiente declarado é real. Um ambiente que diz ser Chrome no Windows mas informa um driver gráfico que só existe em servidores Linux tropeça nesse teste. A lista completa de sinais está em Impressão digital do navegador.

Clientes que nunca executam o script (bibliotecas HTTP como cURL ou Python Requests) não produzem dados nessa camada. Em um endpoint de API isso é o esperado; em uma página HTML, a ausência completa de resultado do script já basta para o cliente não contar como navegador.

O que é um navegador headless e como os sites o reconhecem?#

Um navegador headless é um navegador de verdade que roda sem abrir janela na tela: carrega a página, executa o JavaScript e entrega o resultado ao código. É usado em testes de ponta a ponta, na geração de PDF, no monitoramento de sites e na coleta de dados autorizada; as ferramentas comuns são Playwright, Puppeteer e Selenium. Quando ele é necessário explicamos em Páginas estáticas e dinâmicas, e a diferença entre as duas ferramentas em Playwright e Selenium.

Os sites reconhecem um navegador conduzido por automação por três marcas:

O sinalizador da primeira linha não é um truque de detecção, e sim parte do padrão: o texto do W3C o define como a maneira padronizada de o navegador informar ao documento que está sendo controlado pelo WebDriver.

O peso da segunda linha diminuiu com o tempo. Segundo a documentação headless do Chrome, o modo headless antigo era um aplicativo à parte que não compartilhava o código do navegador; a partir do Chrome 132 ele é oferecido apenas como um binário separado chamado chrome-headless-shell, enquanto o --headless executa o código real do Chrome. Conforme as diferenças de ambiente encolheram, o peso migrou para o comportamento.

A lição para o dono do site é esta: detectar um navegador headless não é detectar má intenção. Seu time de QA e seu serviço de monitoramento carregam as mesmas marcas; separar esse tráfego com um IP conhecido ou uma regra de requisição assinada causa menos dano do que olhar o sinalizador e bloquear em bloco.

A camada de comportamento: ritmo e padrão de navegação#

As camadas anteriores olham de quem veio a requisição; a de comportamento olha o que ela faz. A medida mais simples é o ritmo: quantas requisições chegam em um período do mesmo endereço, sessão ou conta. Quando o limite é ultrapassado, o servidor devolve 429 Too Many Requests. Sobre o que os contadores são mantidos e como funcionam os algoritmos de janela fixa, janela deslizante e token bucket explicamos em 429 Too Many Requests.

Além do ritmo existe o padrão de navegação. Uma pessoa vai da página inicial para uma categoria e dali para um produto, e o navegador dela também baixa as imagens e as folhas de estilo; uma sessão que percorre só endereços de produto em intervalos constantes, sem pedir nenhum arquivo secundário, tem outra cara. Requisições a links ocultos que um visitante nunca conseguiria ver também são sinal dessa camada (armadilhas honeypot). Sistemas mais novos acompanham a interação dentro da página (movimento do cursor, se a aba está visível) ao longo da sessão; um exemplo atual analisamos em Cloudflare Precursor.

Essa camada diz pouco sobre uma requisição e muito sobre cem. O preço é o atraso: é preciso acumular dados para decidir.

Como os sinais viram decisão: pontuação e verificação#

Nenhuma camada diz sozinha «isto é um bot». Os resultados delas se juntam em uma pontuação. A documentação da Cloudflare sobre pontuação de bots é um exemplo claro dessa abordagem: cada requisição recebe um valor entre 1 e 99, em que 1 indica alta confiança de que a requisição foi automática e 99, de que veio de uma pessoa; abaixo de 30 conta como «provavelmente automático». Segundo a documentação, alimentam essa pontuação as regras heurísticas, o aprendizado de máquina, a detecção de anomalias e as checagens de JavaScript.

Pontuação não é ação. A ação é definida pela regra que o dono do site escreve, e as opções formam uma escada:

1. Permitir. A pontuação é alta ou a requisição vem de um bot verificado.
2. Limitar a velocidade. A requisição é aceita e sua frequência é cortada.
3. Mostrar verificação. Ao navegador é apresentado um teste invisível e ao visitante uma caixa de seleção; o que essa tela significa do lado do visitante está em Cloudflare «Verify You Are Human».
4. Bloquear. A requisição é recusada com um 403 ou uma página de bloqueio.

A escada é ajustada por endpoint: em uma página de blog, deixar passar uma requisição de pontuação baixa custa alguns kilobytes de tráfego; na página de login, custa uma conta invadida.

O custo do falso positivo: e se um visitante real for tomado por bot?#

A detecção de bots tem dois tipos de erro. Tomar um bot por pessoa (falso negativo) volta como carga, conta falsa ou conteúdo roubado. Tomar uma pessoa por bot (falso positivo) é receita perdida: o cliente que desiste na tela de verificação, o pagamento que não se completa. O segundo erro não aparece nos relatórios, porque o visitante bloqueado nunca chega à ferramenta de analytics.

As principais fontes são estas:

• Endereços IP compartilhados. Assinantes de operadoras móveis e usuários de redes de alojamento estudantil, cafés e empresas pagam pelo comportamento dos outros.
• VPN e ferramentas de privacidade. Como o endereço parece de data center, a camada de rede baixa a pontuação (VPN ou proxy detectado).
• Bloqueadores de script, ferramentas de acessibilidade, navegação por teclado. A camada do navegador não recebe dados e a de comportamento não encontra o padrão que espera.

Do lado do visitante, isso aparece como mensagens do tipo «detectado como bot» ou «tráfego incomum detectado»: dois exemplos tratamos em erro «tráfego incomum» do Google e «Sorry, You Have Been Blocked».

A conclusão prática: mostre verificação antes de bloquear e acompanhe a proporção de quem passa. Cada requisição que passa é registro de que a regra estava parando a pessoa errada.

Bots verificados: como um site reconhece um bot bom?#

Escrever «Googlebot» no cabeçalho User-Agent é trabalho de uma linha; por isso um bot bom é reconhecido pela prova, não pela declaração. Hoje três métodos estão em uso.

Verificação por DNS reverso. A documentação do Google sobre verificar o Googlebot dá o método: faz-se uma consulta DNS reversa para o IP do log, confere-se se o nome devolvido está sob googlebot.com, google.com ou googleusercontent.com, e depois esse nome é resolvido de volta para um IP e confirmado como igual ao primeiro endereço.

Listas de bots verificados. Serviços de gerenciamento de bots fazem essa checagem em nome do dono do site; a documentação da Cloudflare sobre bots verificados lista duas condições: o bot se identificar com honestidade (por assinatura criptográfica, lista de IPs publicada ou DNS reverso) e não abusar dessa confiança, ou seja, respeitar o robots.txt e manter um ritmo de requisições razoável. Não respeitar a diretiva crawl-delay ou gerar tráfego que não bate com o propósito declarado são motivos de saída da lista.

Requisições assinadas (Web Bot Auth). Na abordagem mais nova o bot assina cada requisição com sua chave privada, publica a chave pública no próprio domínio e o site verifica a assinatura. O padrão de base é a RFC 9421 HTTP Message Signatures, e para adaptá-la aos bots foi criado no IETF um grupo de trabalho Web Bot Auth. O grupo considera insuficientes as soluções atuais, como listas de IP, cadeias de User-Agent e chaves de API compartilhadas; a identidade do agente que faz requisições em nome de um usuário está no escopo, e a do usuário final por trás do agente fica de fora. Os cabeçalhos da assinatura descrevemos em Por que agentes de compra com IA são bloqueados em sites.

Nos três casos a identidade se constrói com uma prova (registro DNS, propriedade do IP, chave privada), não com o que o cliente declara.

Se você opera automação, qual é o caminho legítimo?#

O mapa leva ao mesmo resultado para quem opera automação: o sistema é montado para abrir caminho ao tráfego que se identifica e age com moderação.

• Use a API oficial, se houver. O acesso se apoia em um acordo e a detecção de bots nem entra em cena.
• Respeite o robots.txt. O formato dele e como checá-lo em Python estão em O que é o arquivo robots.txt?.
• Limite seu ritmo por site. Respeite as respostas 429 e Retry-After.
• Dê um nome ao seu bot. O nome do bot e um endereço de contato no User-Agent dão ao administrador a opção de escrever para você em vez de bloquear.
• Peça permissão para acesso de grande volume. Se você opera um rastreador de serviço público, candidate-se aos programas de bots verificados.
• Pare quando aparecer uma tela de verificação. Essa tela é a preferência declarada do site; não recomendamos serviços de resolução de CAPTCHA.

A aplicação desses passos (concorrência, requisições condicionais, a diferença entre rotação e sessão fixa) está com código testado em Como coletar dados sem ser bloqueado.

Casos de uso: quem precisa conhecer esse mapa e para quê?#

• Times de marketing e analytics: para separar a origem dos picos de tráfego e proteger o orçamento de anúncios do clique falso. O lado publicitário está em fraude de cliques no Google Ads e na nossa página de solução de verificação de anúncios.
• Times de dados: para entender qual comportamento parece suspeito e por quê ao coletar dados de páginas públicas; o desenho geral está na nossa página de solução de extração de dados e, para conteúdo que muda conforme a localização, usa-se um Proxies residenciais.
• Times de QA e teste: a proteção contra bots do seu próprio site pode parar a sua própria automação de testes. Tire o tráfego de teste por um endereço fixo e escreva uma regra de permissão para ele; para isso usa-se um Proxies ISP ou seu próprio IP estático (solução de teste de aplicativos).
• Times de proteção de marca: as varreduras por lojas falsas e anúncios de imitação também são automação e passam pelas mesmas camadas; o escopo está na nossa página de solução de proteção de marca.

Erros comuns#

• Bloquear por um sinal só. Uma regra que olha apenas o ASN de data center ou o sinalizador navigator.webdriver também para serviços de monitoramento e seus próprios testes.
• Confiar no User-Agent e abrir a porta para «Googlebot». Declaração não é prova; use DNS reverso ou uma lista de bots verificados.
• Aplicar o mesmo limiar a todos os endpoints. A página de login e um artigo de blog não carregam o mesmo risco.
• Não medir os falsos positivos. Se a proporção de requisições que passam na verificação não é acompanhada, você não sabe quem sua regra está parando.
• Do lado da automação: tratar o bloqueio como um enigma técnico. A tela de verificação não é erro, é a resposta do dono do site; revise seu ritmo, seu alcance e sua situação de permissão.

Guia de decisão#

Perguntas frequentes#

O que é anti-bot e para que serve?#

Anti-bot é a camada de software que classifica o tráfego automático que chega a um site e, conforme as regras do dono, permite, desacelera, pede verificação ou bloqueia. O objetivo não é parar todos os bots, e sim separar a automação nociva dos bots desejados, como os dos buscadores.

O que significa «detectado como bot»?#

Significa que a camada de proteção do site deu uma pontuação baixa à sua requisição; isso não quer dizer que você usou um programa. As causas mais comuns são VPN ou IP compartilhado, extensões que bloqueiam scripts e abrir muitas páginas em pouco tempo. O primeiro passo é desligar a VPN e as extensões e recarregar a página.

Por que Selenium e Playwright caem na detecção de bots?#

Essas ferramentas conduzem o navegador por WebDriver ou protocolo parecido, e o padrão exige que o navegador informe isso com o sinalizador navigator.webdriver. Somam-se a isso as diferenças de ambiente e um ritmo que não lembra interação humana. Se você está testando o próprio site, a solução é escrever uma regra de permissão para o tráfego de teste do lado da proteção.

A detecção de bots olha só o endereço IP?#

Não. O IP é o sinal mais precoce, não o único: o handshake TLS, a coerência dos cabeçalhos, o ambiente do navegador e o comportamento ao longo da sessão são avaliados separadamente. Por isso trocar só o IP não afeta as outras camadas.

Como identifico tráfego de bots no Google Analytics?#

Um pico repentino vindo de uma única cidade ou rede, tempo de interação perto de zero e sessões sem relação com conversões são marcas típicas. Para uma separação segura a ferramenta de analytics não basta; examine a mesma faixa de horário nos logs do servidor ou do CDN, quebrados por IP, ASN e User-Agent.

Por onde começar para proteger um site pequeno de bots?#

Comece com três passos: coloque limites de velocidade em endpoints caros como login, cadastro e busca, ligue a proteção básica contra bots do seu CDN em modo de verificação em vez de bloqueio, e confira se os bots de buscadores estão passando pela lista de verificados.

Em resumo#

A detecção de bots não é um muro, e sim uma série de medições enfileiradas: a camada de rede lê a reputação e o ASN do endereço, a de protocolo o rastro de TLS e HTTP/2, a de cabeçalhos a coerência da declaração, a do navegador a autenticidade do ambiente, a de comportamento o padrão de navegação. Tudo se junta em uma pontuação, e o dono do site escolhe permitir, limitar a velocidade, verificar ou bloquear conforme o risco do endpoint. Como cada camada erra com usuários reais, um sistema bem montado verifica primeiro e bloqueia depois. Bots bons provam quem são com DNS reverso, listas de bots verificados e assinaturas baseadas na RFC 9421; para quem opera automação, o caminho duradouro passa pela API oficial, pelo robots.txt, por um ritmo moderado e por uma identidade aberta. Para seus trabalhos de coleta de dados dentro das regras, você encontra os tipos de proxy nos nossos serviços de proxy.