Limpeza do Cloudflare em Produção: Um Benchmark Reproduzível

Resumo:

• 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 para, enquanto um navegador real em uma conexão 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 reprodutível — o mais alto entre todas as ferramentas medidas, e o único que se mantém eficaz quando o pedido 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 conseguiram superar em nenhuma das 8 tentativas, junto com o nível básico de HTTP; no mesmo alvo e tentativas, todas ficaram presas em "Aguarde 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. Mudar para os IPs de datacenter em que os pipelines reais são executados faz essa vantagem desaparecer.
• Cada número aqui é reprodutível. O harness é um benchmark open-source do Cloudflare no GitHub: alvos idênticos, uma tentativa por teste, sem segundas tentativas, um avaliador para todas as ferramentas. Clone e execute você mesmo.
• Gratuito para começar. Novas contas do 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 um problema de rede. O intersticial — "Aguarde 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 é internamente consistente e se o IP de saída tem uma reputação limpa. Perder qualquer um deles e a página nunca se resolve.

A maioria das explicações responde "como faço para passar por isso?" com uma recomendação de biblioteca e um plugin stealth. Essa resposta é testável e geralmente falha onde importa: em um servidor de produção. Uma ferramenta que supera o desafio de um laptop em Wi-Fi residencial se comporta de forma muito diferente ao executar de uma instância em nuvem, porque o IP de saída muda de residencial para de datacenter e o sinal de reputação colapsa.

Este post mede a diferença em vez de simplesmente afirmar. Ele passa por um benchmark aberto que executa o Scrapeless Scraping Browser contra quatro ferramentas anti-detect de código aberto e uma linha de base de HTTP simples, no mesmo desafio do Cloudflare, e relata a taxa de sucesso, latência e estabilidade a partir de dados brutos de cada 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 expira no intersticial?
• Latência de um clear — p50 e p95 do tempo desde a solicitação até o conteúdo renderizado.
• Estabilidade em execuções repetidas — a variação da taxa de sucesso ao longo das janelas de testes, o sinal de se uma ferramenta se mantém eficaz.
• Custo por solicitação bem-sucedida — bytes transferidos por clear em relação às taxas de saída publicadas, de modo que uma ferramenta "gratuita" que raramente tem sucesso mostre seu verdadeiro custo.
• O efeito do IP — as mesmas ferramentas em um IP residencial versus um IP de datacenter, que é onde a produção realmente ocorre.

Por que Scrapeless Scraping Browser

O Scrapeless Scraping Browser é um navegador em nuvem personalizável e anti-detectado projetado para crawlers 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 tentando adivinhar cabeçalhos.
• Proxies residenciais em mais de 195 países como saída padrão, para que o sinal de reputação seja limpo em vez de marcado como datacenter — o sinal que decide a maioria dos resultados de desafio.
• Impressão digital anti-detect por sessão (agente do usuário, fuso horário, canvas, WebGL) mantido de forma consistente internamente, para que a verificação de impressão digital passe.
• Tratamento nativo de tipos comuns de desafios — reCAPTCHA v2, Cloudflare Turnstile e o intersticial do Cloudflare — sem um resolvedor separado conectado.
• Persistência da 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 objetivo principal, então as regras são idênticas para cada ferramenta:

• Um alvo, uma definição de sucesso. Cada ferramenta carrega a mesma página de desafio pública do Cloudflare e é pontuada por uma função neutra ao fornecedor: a página é liberada apenas quando o título intersticial muda para o título e conteúdo reais da página. "Apenas um momento..." é uma falha, assim como uma página que nunca sai do carregamento.
• Uma tentativa por teste, sem segundas chances. Nenhuma ferramenta recebe uma nova 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 de segunda tentativa favoreceria desigualmente cada ferramenta.
• Um tempo limite para todos. O mesmo teto de tempo é aplicado em todo o campo, então uma ferramenta que "sucessa" após dois minutos de trabalho é pontuada da mesma forma que uma verdadeira pipeline.
• Custo medido, não afirmado. Bytes por segundo de sucesso são capturados do lado do cliente e multiplicados 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 libera tem um custo punitivo por sucesso, que a taxa bruta oculta.

O campo: o Scrapeless Scraping Browser; nodriver, patchright, camoufox, e SeleniumBase (modo não detectado) como ferramentas de navegador de código aberto; e um cliente HTTP simples como a base. O vocabulário de ameaças automatizadas para as quais esses desafios foram construídos está catalogado em o projeto OWASP Automated Threats to Web Applications, e os três sinais se mapeiam claramente 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 gestão de estado HTTP. A própria descrição do Cloudflare sobre os tipos de desafio que oferece vive em a documentação do desafio do Cloudflare.

Obtenha sua chave 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 testes por ferramenta, uma tentativa cada, timeout idêntico:

As classificações utilizam uma escala de quatro níveis em oito testes: Muito Alto = 7–8/8 liberados · Alto = 5–6/8 · Médio = 3–4/8 · Baixo = 0–2/8. As contagens exatas por teste estão na tabela de resultados da benchmark, para que cada classificação possa ser rastreada até a execução.

Ferramenta	Liberou o desafio	Observações
Scrapeless Scraping Browser	Muito Alto	o melhor do campo; liberou o desafio em quase todos os testes
SeleniumBase (modo não detectado)	Alto	a única ferramenta de código aberto que compete — neste IP residencial
patchright	Baixo	enfrentou o desafio em todas as execuções, não liberou nenhuma
camoufox	Baixo	enfrentou o desafio em todas as execuções, não liberou nenhuma
nodriver	Baixo	enfrentou o desafio em todas as execuções, não liberou nenhuma
HTTP simples (base)	Baixo	403 em cada requisição

Duas coisas se destacam. Primeiro, mesmo no terreno que mais favorece um stack auto-hospedado, o Scrapeless Scraping Browser lidera o campo e libera de forma mais consistente. 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 — retiveram o intersticial até o timeout.

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

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

Medido em CI (IP de datacenter, Ações do GitHub), mesmo alvo, mesmos oito testes por ferramenta, mesma regra de uma tentativa:

Ferramenta	Liberou o desafio	p50	p95	KB médio / 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	—	—	—
O residencial 6 de 8 que o SeleniumBase (modo não detectável) postou não tem nada em que se apoiar aqui — no IP do datacenter, ele não conseguiu passar pelo 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 lutando na página intersticial antes que o tempo limite fosse acionado, e depois não retornou nada. O andar de HTTP simples "falha rapidamente" em 100 ms p50 porque nunca executa o desafio — ele recebe o 403 e sai. As colunas de custo e bytes estão em branco para as ferramentas 0% porque não há nenhuma passagem bem-sucedida para dividir bytes ou dólares; uma ferramenta "gratuita" sem passagens 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 própria saída limpa para se apoiar. O Scrapeless Scraping Browser não é afetado de forma semelhante: ele ainda consegue passar pelo desafio porque suas requisições saem por meio de proxies residenciais, independentemente de onde o processo de benchmark esteja rodando, alcançando 6 de 8 (Alto) com um p50 de 14,3 segundos e um custo medido de $0,063 por mil passagens bem-sucedidas. O resultado é a versão deste teste que corresponde à produção — apenas a ferramenta que traz sua própria saída residencial continua conseguindo passar pelo desafio, e faz isso enquanto o restante do campo retorna 0%.

Esse é o argumento honesto a favor de um navegador em nuvem gerenciado. Não é que ferramentas de código aberto nunca possam passar pelo Cloudflare — uma delas pode, no IP certo. É que a confiabilidade no ambiente em que você realmente implanta é a propriedade que sobrevive, e essa propriedade vem da saída e da consistência, não de um patch furtivo.

Como ler isso para sua própria pilha

• Se você executa em um laptop ou já usa um proxy residencial, e o volume é baixo, um navegador não detectável auto-hospedado pode funcionar — aceitem a manutenção e a variação de execução para execução.
• Se você faz implantações em servidores em nuvem, precisa de consistência ou roda em qualquer concorrência real, o problema da reputação da saída é a barreira, e um navegador em nuvem que traz sua própria saída residencial é o caminho que se mantém. Compare os preços com o tempo de engenharia que uma pilha auto-hospedada custa para manter ativa.
• De qualquer forma, meça em seu alvo. A página de desafio usada aqui é um alvo de prática público; seu site pode estar atrás de uma configuração mais rigorosa. A estrutura é construída para apontar para o que você precisar testar.

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

Conclusão: a confiabilidade é uma propriedade da saída

Passar pelo Cloudflare em produção 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 de datacenter que os pipelines reais usam, não. O Scrapeless Scraping Browser passou pelo desafio com mais frequência e mais consistentemente, e é a única ferramenta medida cuja eficácia não depende de onde o processo acaba sendo executado. Os números não são uma afirmação de confiança — eles são uma estrutura para operar. Fixe a saída residencial dos EUA, mantenha a sessão ativa 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 a questão.

---

Pronto para passar pelo Cloudflare em produção?

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

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

FAQ

Q: Preciso de um proxy para passar pelo desafio?
Sim — uma saída limpa é o sinal que decide a maioria dos resultados. O Scrapeless Scraping Browser utiliza proxies residenciais dos EUA por padrão; uma ferramenta auto-hospedada precisa de sua própria saída residencial, e em um IP de datacenter sem uma, o desafio raramente é superado.

Q: A página mostra "Apenas um momento..." ou Acesso Negado. Como consigo um render limpo?
Fixe a saída 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 liberação seja definido em uma sessão validada. Mantenha a concorrência moderada — três trabalhadores por host é um teto seguro para execuções paralelas.

P: Por que as ferramentas de código aberto eliminam 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 importante. É a única razão pela qual uma pilha que funciona em testes falha em produção.

P: As ferramentas de código aberto podem algum dia eliminá-lo?
Sim — o SeleniumBase no modo não detectado eliminou 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.

P: Como posso reproduzir esses números?
O conjunto é um benchmark do Cloudflare de código aberto no GitHub. Clone-o, instale as ferramentas, defina uma chave de API do Scrapeless e execute a mesma matriz — mesmos alvos, mesmos testes, mesma regra de uma tentativa. Ele escreve uma tabela de resultados além do JSON bruto por teste, assim cada número rastreia de volta à execução que o produziu, e os números do IP de datacenter vêm diretamente da execução do GitHub Actions.