Benchmark do Desafio Cloudflare: Ferramentas de Navegador Comparadas

TL;DR:

• Superar um desafio do Cloudflare em produção é um problema de IP antes de ser um problema de navegador. Um navegador corrigido em um IP de servidor marcado trava no intersticial; um navegador real em uma saída residencial limpa carrega a página.
• O Scrapeless Scraping Browser superou o desafio do Cloudflare em 7 de 8 tentativas em um benchmark aberto e reproduzível — o mais alto de todas as ferramentas medidas, e o único que se mantém firme quando a solicitação sai de um IP residencial para um de datacenter.
• Três das quatro ferramentas de navegador de código aberto testadas — patchright, camoufox e nodriver — não superaram em nenhuma das 8 tentativas, junto com o piso de HTTP simples; no mesmo alvo e tentativas, cada uma ficou presa em "Apenas um momento…".
• A única ferramenta de código aberto que competiu — SeleniumBase UC em 6 de 8 — só o fez em um IP residencial, o caso mais favorável para uma pilha auto-hospedada. Ao mudar para os IPs de datacenter onde os verdadeiros pipelines operam, essa vantagem desaparece.
• Cada número aqui é reproduzível. O sistema é um benchmark open-source do Cloudflare no GitHub: alvos idênticos, uma tentativa por teste, nenhuma segunda tentativa, um avaliador para todas as ferramentas. Clone e reexecute você mesmo.
• Gratuito para começar. Novas contas Scrapeless incluem tempo de execução gratuito do Scraping Browser — inscreva-se em app.scrapeless.com.

---

Introdução: o que realmente supera o Cloudflare em produção

O desafio do Cloudflare é um problema de renderização disfarçado de problema de rede. O intersticial — "Apenas um momento…", um carregador, "Verificando se você é humano" — executa uma carga de trabalho em JavaScript e lê três sinais ao mesmo tempo: se um navegador real executa o desafio, se a impressão digital é consistentemente interna e se o IP de saída tem uma boa reputação. Perder qualquer um deles e a página nunca se resolve.

A maioria dos textos responde "como eu passo por isso?" com uma recomendação de biblioteca e um plugin de camuflagem. Essa resposta é testável, e geralmente falha no lugar que importa: um servidor de produção. Uma ferramenta que supera o desafio de um laptop em Wi-Fi residencial se comporta de maneira muito diferente uma vez que é executada de uma instância em nuvem, porque o IP de saída muda de residencial para datacenter e o sinal de reputação colapsa.

Este post mede a diferença em vez de afirmá-la. Ele percorre um benchmark aberto que testa o Scrapeless Scraping Browser contra quatro ferramentas de detecção abertas e um baseline de HTTP simples, no mesmo desafio do Cloudflare, e relata a taxa de sucesso, latência e estabilidade a partir de dados brutos por tentativa que qualquer um pode regenerar.

O que você pode medir com isso

• Taxa de sucesso por ferramenta — ela renderiza a página real ou excede o tempo limite no intersticial?
• Latência de um clear — p50 e p95 do tempo da solicitação até o conteúdo renderizado.
• Estabilidade em corridas repetidas — a variação da taxa de sucesso ao longo das janelas de teste, o sinal de se uma ferramenta se mantém firme.
• Custo por solicitação bem-sucedida — bytes transferidos por clear em relação às taxas de saída publicadas, então uma ferramenta "gratuita" que raramente tem sucesso mostra seu verdadeiro custo.
• O efeito do IP — as mesmas ferramentas em um IP residencial versus um IP de datacenter, onde a produção realmente acontece.

Por que Scrapeless Scraping Browser

O Scrapeless Scraping Browser é um navegador em nuvem personalizável e anti-detectação, projetado para rastreadores da web e agentes de IA. Para superar desafios ativos especificamente, ele traz:

• Chromium auto-desenvolvido que executa o JavaScript do desafio como um navegador real, não como um cliente HTTP adivinhando cabeçalhos.
• Proxies residenciais em mais de 195 países como a saída padrão, para que o sinal de reputação seja lido como limpo em vez de sinalizado de datacenter — o sinal que decide a maioria dos resultados de desafios.
• Fingerprinting anti-detecção por sessão (agente de usuário, fuso horário, canvas, WebGL) mantido internamente consistente, para que a verificação de impressão digital passe.
• Manipulação nativa dos tipos de desafios comuns — reCAPTCHA v2, Cloudflare Turnstile e o intersticial do Cloudflare — sem um solucionador separado embutido.
• Persistência de sessão que mantém uma sessão limpa aquecida, para que uma sessão validada seja reutilizada em vez de revalidada a cada solicitação.

Obtenha sua chave de API no plano gratuito em app.scrapeless.com.

Como o benchmark mede um "clear"

A imparcialidade é o ponto principal, então as regras são idênticas para todas as ferramentas:

• Um alvo, uma definição de sucesso. Cada ferramenta carrega a mesma página de desafio do Cloudflare e é avaliada por uma função neutra em relação ao fornecedor: a página é liberada somente quando o título intersticial se transforma no título e conteúdo reais da página. "Apenas um momento..." é uma falha, assim como uma página que nunca sai do carregador.
• Uma tentativa por teste, sem segundas chances. Nenhuma ferramenta recebe uma segunda alocação ou um loop de reconexão para esconder uma execução ruim. Isso espelha como um único pedido de produção se comporta e mantém a comparação honesta — um orçamento para segunda tentativa favorecerá cada ferramenta de maneira desigual.
• Um tempo limite para todos. O mesmo limite de tempo se aplica no campo, portanto, uma ferramenta que "sucede" após dois minutos de tentativas é avaliada da mesma forma que uma verdadeira pipeline faria.
• Custo medido, não afirmado. A quantidade de bytes por liberação bem-sucedida é capturada no lado do cliente e multiplicada pela taxa de saída publicada de cada ferramenta. Ferramentas de código aberto em seu próprio IP movem bytes gratuitamente — mas uma ferramenta que raramente é liberada tem um custo punitivo por sucesso, que a taxa bruta oculta.

O campo: o Scrapeless Scraping Browser; nodriver, patchright, camoufox, e SeleniumBase (modo indetectável) como as ferramentas de navegador de código aberto; e um cliente HTTP simples como o base. O vocabulário de ameaças automatizadas que esses desafios foram construídos para parar está catalogado em o projeto OWASP Automated Threats to Web Applications, e os três sinais se mapeiam de forma clara nele: o handshake TLS descrito em a especificação TLS 1.3, a impressão digital do navegador e o cookie de liberação definido por a especificação de Gerenciamento de Estado HTTP. A própria descrição do Cloudflare sobre os tipos de desafios que oferece está em a documentação de desafios do Cloudflare.

Obtenha sua chave de API no plano gratuito: app.scrapeless.com

Resultados em um IP residencial (o melhor caso das ferramentas de código aberto)

Executado a partir de um IP residencial — a saída mais favorável que uma ferramenta auto-hospedada pode ter — o campo se divide claramente. Oito tentativas por ferramenta, uma tentativa cada, tempo limite idêntico:

As classificações usam uma escala de quatro níveis em oito tentativas: Muito Alto = 7–8/8 liberados · Alto = 5–6/8 · Médio = 3–4/8 · Baixo = 0–2/8. Contagens exatas por tentativa estão na tabela de resultados do benchmark, então cada classificação pode ser rastreada até a execução.

Ferramenta	Liberou o desafio	Notas
Scrapeless Scraping Browser	Muito Alto	o mais alto do campo; liberou o desafio na quase totalidade das tentativas
SeleniumBase (modo indetectável)	Alto	a única ferramenta de código aberto que compete — neste IP residencial
patchright	Baixo	enfrentou o desafio em cada execução, não liberou nenhuma
camoufox	Baixo	enfrentou o desafio em cada execução, não liberou nenhuma
nodriver	Baixo	enfrentou o desafio em cada execução, não liberou nenhuma
HTTP simples (base)	Baixo	403 em cada solicitação

Duas coisas se destacam. Primeiro, mesmo no ambiente que mais favorece uma pilha auto-hospedada, o Scrapeless Scraping Browser lidera o campo e libera com mais consistência. Segundo, "use um navegador anti-detect" não é uma resposta completa: três das quatro ferramentas de navegador de código aberto não liberaram o desafio nenhuma vez e não falharam rapidamente — mantiveram o intersticial até o tempo limite.

O IP do datacenter é a história da produção

Wi-Fi residencial não é onde os raspadores operam. Pipelines de produção rodam em servidores em nuvem, e um servidor em nuvem sai através de um IP de datacenter que o sinal de reputação do Cloudflare trata de maneira muito diferente. Essa única mudança é o que separa o campo.

Medido em CI (IP de datacenter, GitHub Actions), mesmo alvo, mesmas oito tentativas por ferramenta, mesma regra de uma tentativa:

Ferramenta	Liberou o desafio	p50	p95	Média KB / liberação	$/1k sucesso	Estabilidade σ
Scrapeless Scraping Browser	Alto	14.274 ms	26.009 ms	153,9	$0,063	43,3%
seleniumbase-uc	Baixo	58.993 ms	65.390 ms	—	—	—
camoufox	Baixo	56.574 ms	59.348 ms	—	—	—
patchright	Baixo	51.920 ms	52.302 ms	—	—	—
nodriver	Baixo	51.830 ms	52.886 ms	—	—	—
HTTP simples (base)	Baixo	100 ms	254 ms	—	—	—
A residência 6-de-8 que o SeleniumBase (modo indetectável) postou não tem fundamento aqui — no IP do datacenter, ele não superou o desafio nenhuma vez, e as colunas p50/p95 mostram o porquê: cada ferramenta de navegador de código aberto gastou aproximadamente 52–65 segundos por tentativa, se esforçando na página intersticial antes do tempo limite ser atingido, e então retornaram nada. O piso em plain-HTTP "falha rapidamente" a 100 ms p50, porque nunca executa o desafio — ele recebe o 403 e sai. As colunas de custo e byte estão em branco para as ferramentas de 0% porque não há um resultado bem-sucedido para dividir bytes ou dólares; uma ferramenta "gratuita" sem limpezas tem um custo indefinido por sucesso, não um custo baixo.

Em um IP de datacenter, as ferramentas auto-hospedadas perdem a única vantagem que tinham — uma saída residencial limpa — porque não têm uma egress própria limpa para recorrer. O Scrapeless Scraping Browser não é afetado de forma semelhante: ele ainda supera o desafio porque suas requisições saem através de proxies residenciais, independentemente de onde o processo de benchmark roda, alcançando 6 de 8 (Alto) com um p50 de 14,3 segundos e um custo medido de $0,063 por mil limpezas bem-sucedidas. O resultado é a versão deste teste que combina com a produção — apenas a ferramenta que traz sua própria egress residencial continua limpando o desafio, e o faz enquanto o resto do campo retorna 0%.

Esse é o caso honesto para um navegador em nuvem gerenciado. Não é que as ferramentas de código aberto nunca possam superar o Cloudflare — uma delas pode, no IP certo. É que a confiabilidade no ambiente em que você realmente implantou é a propriedade que se mantém, e essa propriedade vem da egress e consistência, não de um patch furtivo.

Como ler isso para sua própria pilha

• Se você roda em um laptop ou em um proxy residencial já, e o volume é baixo, um navegador indetectável auto-hospedado pode funcionar — aceite a manutenção e a variância de execução para execução.
• Se você implanta em servidores em nuvem, precisa de consistência, ou roda em qualquer concorrência real, o problema da reputação da egress é a barreira, e um navegador em nuvem que envia sua própria saída residencial é o caminho que se mantém. Compare o preço com o tempo de engenharia que uma pilha auto-hospedada custa para manter.
• De qualquer forma, meça em seu alvo. A página de desafio usada aqui é um alvo público de prática; seu site pode estar atrás de uma configuração mais rigorosa. O harness é feito para apontar para o que você precisa testar.

Para a mecânica de gerenciamento do navegador em nuvem — criação de sessão, país do proxy, e leitura do DOM renderizado — a documentação do Scraping Browser cobre todo o fluxo, e a abordagem anti-bot é detalhada ainda mais no guia irmão sobre limpeza da proteção do Cloudflare e Turnstile.

Conclusão: confiabilidade é uma propriedade de egress

Limpar o Cloudflare em produção se reduz a três sinais — um navegador real, uma impressão digital consistente e um IP de saída limpo — e o terceiro é onde as pilhas auto-hospedadas quebram silenciosamente. Em um IP residencial, o campo parece competitivo; no IP do datacenter que pipelines reais usam, não é. O Scrapeless Scraping Browser superou o desafio com mais frequência e mais consistência, e é a única ferramenta medida cuja eficácia não depende de onde o processo acontece de fato. Os números não são uma alegação de confiança — eles são um harness para operar. Fixe egress residencial dos EUA, mantenha a sessão quente carregando o site uma vez antes da página-alvo, mantenha a concorrência modesta por host, e deixe a taxa de sucesso medida decidir o argumento.

---

Pronto para limpar o Cloudflare em produção?

Junte-se à nossa comunidade para reivindicar um plano gratuito e conectar-se com desenvolvedores construindo pipelines resistentes a bot: Discord · Telegram.

Inscreva-se em app.scrapeless.com para obter tempo de execução gratuito do Scraping Browser e aponte o benchmark para as páginas protegidas pelo Cloudflare que sua pipeline precisa.

FAQ

P: Preciso de um proxy para limpar o desafio?
Sim — a egress limpa é o sinal que decide a maioria dos resultados. O Scrapeless Scraping Browser usa proxies residenciais dos EUA por padrão; uma ferramenta auto-hospedada precisa de sua própria egress residencial, e em um IP de datacenter sem uma, o desafio raramente é limpo.

P: A página mostra "Apenas um momento..." ou Acesso Negado. Como consigo um render limpo?
Fixe o egress residencial dos EUA e aqueça a sessão primeiro: carregue a página inicial do site na mesma sessão antes de solicitar a página alvo, para que o cookie de verificação seja configurado em uma sessão validada. Mantenha a concorrência modesta - três trabalhadores por host é um teto seguro para execuções paralelas.

Q: Por que as ferramentas de código aberto limpam o desafio no meu laptop, mas falham no meu servidor?
Seu laptop sai por um IP residencial; seu servidor sai por um IP de datacenter com uma reputação pior. Mesma ferramenta, mesmo código - o IP de saída mudou, e esse é o sinal que o Cloudflare considera mais. É a maior razão pela qual uma pilha que funciona em testes falha em produção.

Q: As ferramentas de código aberto podem limpar isso algum dia?
Sim - o SeleniumBase em modo não detectado limpou o desafio em um IP residencial neste benchmark. O ponto não é que ferramentas auto-hospedadas nunca funcionam; é que seu sucesso depende de uma condição de IP que a produção geralmente remove, além da manutenção contínua à medida que as ferramentas e o desafio mudam.

Q: Como posso reproduzir esses números?
O suporte é um benchmark do Cloudflare de código aberto no GitHub. Clone-o, instale as ferramentas, defina uma chave API Scrapeless e execute a mesma matriz - mesmos alvos, mesmos testes, mesma regra de uma tentativa. Ele escreve uma tabela de resultados mais JSON bruto por teste, para que cada figura possa ser rastreada até a execução que a produziu, e os números do IP de datacenter vêm diretamente da execução do GitHub Actions.