Em 13 de julho de 2026, a Cloudflare anunciou uma nova camada de detecção de bots chamada Precursor. A abordagem do Precursor é diferente dos controles a que estamos acostumados: em vez de examinar o visitante uma única vez na porta de entrada, ele avalia continuamente o comportamento ao longo da navegação pelo site. Neste artigo explicamos o que o Precursor faz, em que ponto ele se diferencia das proteções anteriores, como os donos de sites o ativam e o que isso significa para equipes que usam automação de navegador.
Por que a Cloudflare precisou de uma nova camada?
As proteções clássicas contra bots focam em momentos específicos: página de login, formulário de cadastro, etapa de pagamento. O visitante passa por um CAPTCHA ou recebe aprovação de uma verificação em JavaScript nesse ponto e segue seu caminho.
Segundo a constatação do post de anúncio da Cloudflare, a automação moderna passou a conseguir vencer esses testes curtos: os bots executam JavaScript, usam um ambiente de navegador real e conseguem passar por CAPTCHAs individuais sem levantar suspeita. A conclusão da Cloudflare é a seguinte: ficou mais fácil parecer humano em momentos curtos, mas manter um comportamento humano consistente ao longo do tempo ainda é difícil.
Essa mudança também mostra a direção geral da detecção de bots. Primeiro se olhava a reputação do IP; os proxies superaram isso. Depois se olhava o ambiente do navegador; navegadores reais e ferramentas antidetect superaram isso. Agora é a vez da consistência do comportamento ao longo do tempo.
As camadas de proteção atuais da Cloudflare
Para posicionar o Precursor no lugar certo, vale lembrar as camadas que a Cloudflare usa para proteger um site:
| Camada | O que faz? | Quando entra em ação? |
|---|---|---|
| Reputação de IP e regras de WAF | Bloqueia endereços conhecidos como maliciosos e padrões de requisição | Em cada requisição, no lado do servidor |
| Pontuação de bot | Gera uma pontuação de 1 a 99 com base em cabeçalhos de requisição, fingerprint de TLS e machine learning | Em cada requisição |
| JavaScript Detections | Testa no lado do cliente se o navegador é real | No carregamento da página, uma única vez |
| Turnstile / Managed Challenge | Apresenta uma verificação visível ou invisível ao visitante | Quando o limite de suspeita é ultrapassado |
| Precursor | Avalia o comportamento de interação ao longo da sessão | Depois que a página carrega, continuamente |
Como a tabela mostra, os controles do lado do cliente anteriores ao Precursor eram pontuais. O Precursor preenche essa lacuna.
Como o Precursor funciona?
Segundo a documentação para desenvolvedores da Cloudflare, o Precursor é um sistema que roda no lado do cliente e faz verificação ao longo da sessão. O anúncio descreve três componentes:
- Camada de coleta. A Cloudflare insere um pequeno script na resposta HTML do site. O dono do site não precisa alterar nada no código. O script escuta sinais de interação como movimento do cursor, atividade de teclado, mudanças de foco e se a página está visível. Segundo o anúncio, não é o conteúdo digitado no teclado que é avaliado, e sim o ritmo da digitação.
- Camada de avaliação. Os sinais passam por múltiplos avaliadores nos servidores de borda da Cloudflare e são cruzados entre si. Por exemplo, se houver movimento de cursor enquanto a página está em segundo plano, isso é uma inconsistência.
- Integração de sessão. Os resultados se acumulam ao longo da sessão. O ponto destacado no anúncio é: um bot não consegue zerar o histórico de comportamento atualizando a página ou iniciando uma nova verificação.
Os resultados da avaliação se refletem no cookie cf_clearance do visitante. Segundo a documentação, se o comportamento se tornar suspeito durante a sessão, o efeito de uma permissão de acesso já concedida pode ser reduzido ou invalidado.
Quais sinais são avaliados?
O anúncio e a documentação não listam os sinais um a um, mas as categorias descritas são:
- Movimento do cursor: velocidade, aceleração e mudanças de direção, e se elas se parecem com o movimento humano. O cursor humano não anda em linha reta e em velocidade constante.
- Ritmo do teclado: a distribuição dos intervalos entre teclas. Não é o conteúdo, é o ritmo que é avaliado.
- Foco e visibilidade: se a página está na aba ativa, se a janela está em foco. Se há interação vindo de uma aba em segundo plano, há uma contradição.
- Relação entre interação e requisições de rede: se a requisição esperada depois de um clique realmente chega, se requisições estão sendo geradas sem um clique.
- Consistência ao longo do tempo: se os sinais acima mantêm o mesmo "caráter" durante toda a sessão.
Essa lista explica por que o Precursor não é vencido com um único controle: produzir um movimento parecido com o humano em um instante é fácil; produzir um comportamento consistente por minutos, não.
Ele substitui o CAPTCHA e o Turnstile?
Não. A Cloudflare posiciona o Precursor como complemento das verificações existentes. Segundo a documentação, o Precursor ajuda a decidir quando uma verificação adicional é necessária e reavalia depois um visitante que já passou por uma verificação. Quando o Precursor é ativado, o antigo recurso JavaScript Detections é desativado automaticamente.
| Verificação clássica | Precursor | |
|---|---|---|
| Quando verifica? | Em momentos específicos | Ao longo da sessão |
| O que observa? | Ambiente do navegador, teste pontual | Consistência do comportamento de interação ao longo do tempo |
| Pode ser reiniciado? | Com uma nova tentativa | Acumula no escopo da sessão |
| O usuário vê? | Se um CAPTCHA aparecer | Na maioria dos modos escolhidos, não |
| Mudança de código do dono do site | Sim, para o Turnstile | Não, o script é inserido automaticamente |
Como os donos de sites ativam o Precursor?
O Precursor não vem ativado por padrão; o dono do site precisa habilitá-lo. Segundo a documentação, o ajuste é feito no painel da Cloudflare em Security > Settings e dois modos são oferecidos:
- Minimize Friction: a verificação roda em segundo plano, a experiência do usuário é mantida o mais contínua possível.
- Maximize Security: uma tela intermediária leve pode ser usada para uma verificação mais rígida.
Os resultados se refletem na análise de bots da tela Security > Analytics da região e nas correspondências de regras de WAF. Como os planos e condições em que o recurso é oferecido podem mudar com o tempo, vale acompanhar a informação atualizada na documentação da Cloudflare.
Se você protege o seu próprio site com a Cloudflare, vale verificar duas coisas antes de ativar o Precursor: a automação legítima do seu site (ferramentas de monitoramento, seus próprios scripts de teste, integrações de parceiros) e se esse tráfego está isento nas regras de WAF. Caso contrário, as suas próprias ferramentas também serão avaliadas como "não humanas".
O que muda para a automação de navegador?
Em um site com o Precursor ativado, a automação feita com navegador headless passa a ser avaliada não apenas no ponto de entrada, mas durante toda a sessão. Isso tem algumas consequências práticas:
- A abordagem de "passar" uma única vez não funciona. Uma sessão que passa na verificação na primeira página pode perder o acesso se, nas páginas seguintes, apresentar um padrão não humano.
- Atualizar a página não abre uma página limpa. O histórico de comportamento se acumula no escopo da sessão.
- O IP sozinho não é determinante. Um endereço IP com boa reputação não salva a sessão se os sinais comportamentais forem inconsistentes. Explicamos o papel do fingerprint do navegador no artigo O que é fingerprint do navegador?.
- Navegação sem interação é suspeita. Uma sessão que passa de página em página sem nenhum movimento de cursor, sem nunca rolar a tela, não se parece com um visitante comum.
Aqui vale destacar um ponto: desenvolver ferramentas que imitam o comportamento humano para contornar o Precursor significa mirar em uma proteção que o dono do site ativou de forma consciente. Isso pode entrar em conflito tanto com os termos de uso do site quanto com a legislação de vários países.
O caminho certo para automação legítima
Para equipes que trabalham com coleta de dados, testes ou monitoramento, a mensagem do Precursor é clara: em vez de competir com as camadas de proteção, obter o consentimento do site é mais sustentável.
- Prefira as APIs oficiais. Muitas plataformas oferecem os dados necessários via API. A API é mais rápida e nem entra na avaliação comportamental.
- Combine com o dono do site. Se você está testando seus próprios sites ou o site de um cliente, o dono do site pode isentar o tráfego de teste nas regras de WAF. Esse é o caminho mais limpo para a automação funcionar sem problemas mesmo com o Precursor ativado.
- Analise os programas de bots verificados. Bots conhecidos, como os crawlers de motores de busca, são reconhecidos pelo mecanismo de bot verificado da Cloudflare. Se você opera um crawler que presta um serviço público, é possível se candidatar a esse programa.
- Velocidade razoável e identidade clara. Ao coletar dados públicos, mantenha a velocidade das requisições baixa, siga as regras do
robots.txte use um User-Agent que se identifique. - Procure caminhos que não exijam navegador. Se os dados da página vêm de um endpoint JSON, fazer a requisição diretamente a esse endpoint é mais barato do que a automação de navegador e independe da camada comportamental.
A infraestrutura de proxy mantém sua importância nesse contexto: ver conteúdo que muda por localização a partir da região correta, não concentrar o tráfego em um único endereço e distribuir de forma equilibrada as cargas de crawler web são necessidades reais. Em alvos protegidos, o Proxies residenciais, vindo de endereços de usuários reais, e o Proxies de sessão fixa, que mantém o mesmo endereço durante a sessão, fazem parte desse arranjo. Porém, o proxy não é uma ferramenta que legitima uma proteção comportamental que um site estabeleceu explicitamente. Tratamos de quais dados podem ser coletados sob quais condições no artigo A extração de dados é legal?.
A tendência geral que o Precursor aponta
Mais do que um produto isolado, o Precursor mostra para onde a detecção de bots está caminhando. Três conclusões podem ser tiradas:
- Sinais estáticos perdem valor. Tipo de IP, User-Agent e ambiente do navegador — sinais lidos uma única vez — ainda são usados, mas não decidem sozinhos.
- A sessão vira a unidade de análise. A avaliação não é feita por requisição, mas por sessão. Isso significa que a estratégia de "um IP diferente a cada requisição" pode se voltar contra você em alguns alvos; a mudança de IP dentro da sessão pode ser considerada uma inconsistência.
- Declarar a identidade da automação legítima ganha importância. Programas de bots verificados e combinações com o dono do site se tornam um caminho mais confiável do que a automação oculta.
Essa tendência não é exclusiva da Cloudflare; abordagens comportamentais parecidas aparecem em outros provedores de proteção. Ao planejar sua infraestrutura de automação, perguntar "para onde a proteção está indo" em vez de "qual controle existe hoje" leva a decisões mais duradouras.
Perguntas frequentes
O Precursor funciona em todos os sites da Cloudflare?
Não. É um recurso opcional que o dono do site precisa ativar no painel.
O Precursor coleta dados pessoais?
Segundo o anúncio da Cloudflare, o script coleta sinais de interação; não avalia o conteúdo digitado no teclado, apenas o ritmo. É responsabilidade do dono do site explicar esse processamento na política de privacidade para os visitantes.
Ferramentas como o Undetected ChromeDriver funcionam contra o Precursor?
Esse tipo de ferramenta foca em reduzir vestígios conhecidos de automação no ambiente do navegador. Já o Precursor olha a consistência do comportamento ao longo da sessão, então atua em uma camada diferente. Explicamos os limites gerais dessas ferramentas no artigo Undetected ChromeDriver.
Como sei se um site usa o Precursor?
Não há um método externo definitivo. Em um site atrás da Cloudflare, se depois de passar pelo ponto de entrada o acesso se torna mais restrito nas páginas seguintes ou uma verificação extra é solicitada, isso pode ser um indício. Se você for o dono do site, consegue ver isso pelo painel.
O Precursor bloqueia usuários reais por engano?
A Cloudflare afirma que o modo "Minimize Friction" foi desenhado para manter esse risco baixo. Ainda assim, o dono do site precisa monitorar falsos positivos na tela de analytics para ferramentas de acessibilidade, usuários que dependem muito do teclado e dispositivos incomuns.
O que fazer ao trabalhar com Puppeteer em um site com Precursor?
Primeiro, veja se o site oferece uma API; depois, entre em contato com o dono do site. Se a automação for indispensável, reduza a velocidade, mantenha a sessão e fique em um único IP; explicamos esses passos no artigo Puppeteer e CAPTCHA. Recorrer a ferramentas que geram imitação de comportamento, por outro lado, é frágil e arriscado.
Em resumo
O Cloudflare Precursor leva a detecção de bots de exames pontuais para uma avaliação contínua ao longo da sessão. É ativado por escolha do dono do site, complementa as verificações existentes e não é reiniciado ao atualizar a página. Para equipes que trabalham com automação, a estratégia mais sólida não é tentar contornar a proteção, mas construir um processo de coleta de dados baseado em API, permissão e tráfego razoável. Nesse arranjo, o proxy não é a ferramenta para burlar a proteção, e sim para gerenciar o tráfego a partir da região correta e de forma equilibrada.
