A maioria dos tutoriais de "como contornar o Cloudflare" disponíveis na internet deixou de funcionar no fim de 2024. O motivo não é que o Cloudflare adicionou novas defesas. É que as defesas antigas, fingerprinting JA3 e verificações básicas de cabeçalhos, foram substituídas por uma nova geração que quebra todos os atalhos. Este guia explica o que o Cloudflare realmente verifica em 2026, por que o cloudscraper, o undetected-chromedriver e a maioria dos plugins "stealth" falham, e a receita de quatro camadas que ainda funciona em produção.
O resumo honesto, logo de cara: não existe um truque único. Contornar o Cloudflare de forma confiável exige o IP certo, o fingerprint TLS certo, a ordenação correta dos frames HTTP/2 e (para o nível Bot Management) um navegador real. Erre qualquer um desses e você falha no filtro de borda antes mesmo de sua requisição chegar ao servidor de origem.
A detecção de bots do Cloudflare funciona como um pipeline de filtros na borda. Cada requisição passa por eles em ordem. O primeiro filtro a rejeitar é o que vence, o que significa que uma requisição pode falhar apenas pela reputação do IP, antes que qualquer fingerprint ou cabeçalho seja examinado.
Esta é a primeira e mais barata verificação. O Cloudflare mantém um banco de dados indexado por ASN (Autonomous System Number). ASNs pertencentes a provedores de nuvem conhecidos (AWS AS16509, GCP AS15169, Azure AS8075, OVH AS16276, DigitalOcean AS14061, Hetzner AS24940, Vultr AS20473) recebem o maior escrutínio. Mesmo com um fingerprint perfeito, de nível de navegador, uma requisição originada desses ASNs é tratada como culpada até que se prove o contrário.
ASNs residenciais (Comcast AS7922, Verizon AS701, China Telecom AS4134, BT AS2856) são presumidos legítimos. Uma requisição de um IP residencial com um fingerprint Python desajeitado ainda pode passar, enquanto uma requisição de um IP de datacenter com um fingerprint Chrome perfeito será desafiada ou bloqueada.
O JA4 é o sucessor de 2023 do JA3, lançado pela FoxIO. Ele faz o hash de campos específicos do ClientHello do TLS: versão do TLS, suítes de cifras (em ordem), extensões (em ordem), protocolos ALPN, algoritmos de assinatura e grupos suportados. A saída é um fingerprint determinístico como t13d1516h2_8daaf6152771_b1ff8ab2d16f.
O Chrome 124 real produz um JA4 específico. O Firefox 124 real produz um diferente. A biblioteca requests do Python (que usa urllib3 e OpenSSL) produz um JA4 que nenhum navegador real jamais emite, porque a ordem das cifras e a lista de extensões não correspondem nem ao Chrome nem ao Firefox. O Cloudflare sinaliza esse padrão antes de analisar qualquer cabeçalho HTTP.
A implicação: toda biblioteca que usa o OpenSSL do sistema ou o TLS padrão do Python é detectável. Isso inclui requests, aiohttp, httpx (configuração padrão), e qualquer wrapper de "bypass" construído em cima deles.
Conexões HTTP/2 carregam frames de settings, window updates, frames de prioridade e frames de cabeçalhos. Navegadores os enviam em uma ordem específica com valores específicos. O Chrome 124 envia um frame SETTINGS inicial com esses valores exatos, depois um WINDOW_UPDATE, depois HEADERS. O httpx do Python com HTTP/2 habilitado envia um payload de settings diferente e pula os frames de prioridade que o Chrome inclui.
A ordem dos pseudo-cabeçalhos do HTTP/2 também vaza identidade. O Chrome envia :method, :authority, :scheme, :path nessa ordem. O Firefox envia :method, :path, :authority, :scheme. A maioria das bibliotecas Python e Go os serializa em ordem alfabética. O Cloudflare compara a ordem com o padrão esperado para o User-Agent declarado e sinaliza incompatibilidades.
Cabeçalhos HTTP/1.1 preservam a ordem de inserção. O Chrome real envia os cabeçalhos em uma ordem fixa: Host, Connection, Cache-Control, sec-ch-ua, sec-ch-ua-mobile, sec-ch-ua-platform, Upgrade-Insecure-Requests, User-Agent, Accept, Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-User, Sec-Fetch-Dest, Accept-Encoding, Accept-Language. A biblioteca requests do Python os reordena e às vezes os capitaliza de forma diferente. Mesmo definir os cabeçalhos manualmente na ordem certa não ajuda, porque a biblioteca subjacente os reordena novamente.
Se os filtros anteriores passam mas a pontuação ainda é suspeita, o Cloudflare serve um desafio JavaScript. O script calcula um token a partir de valores do ambiente do navegador (hash de canvas, renderizador WebGL, contexto de áudio, propriedades do navigator, medições de tempo) e o submete via XHR. Nenhum cliente HTTP consegue resolver isso. Você precisa de um navegador real, e o navegador precisa parecer real (sem navigator.webdriver = true, sem propriedades faltando).
No nível Bot Management, o Cloudflare coleta movimento do mouse, velocidade de rolagem, tempo de cliques e dinâmica de digitação por meio de um script em execução contínua. Um navegador headless que carrega a página e imediatamente faz scraping sem nunca mover o mouse é detectado em segundos. Usuários reais se movem de forma errática, pausam e releem. Bots rolam linearmente e clicam com precisão de pixel.
As ferramentas de atalho que impulsionaram o scraping de 2021-2024 compartilham todas um mesmo modo de falha: elas remendam a superfície visível, mas não a pilha TLS subjacente.
| Ferramenta | O que ela remenda | Por que falha em 2026 |
|---|---|---|
cloudscraper | Solucionador de desafio JS (legado) | O Cloudflare migrou para o Turnstile em 2023; desafios legados foram descontinuados |
undetected-chromedriver | Remenda flags de vazamento do Selenium | O JA4 ainda vaza do TLS subjacente do chromedriver; navigator.webdriver é apenas um de mais de 40 sinais |
selenium-stealth | Injeta propriedades JS falsificadas | O Cloudflare lê da camada C++, não do JS; a falsificação é detectável como inconsistente |
FlareSolverr | Envolve o Chromium para resolver um desafio pontual | O cf_clearance fica vinculado ao IP do solucionador; um proxy novo invalida o token imediatamente |
puppeteer-extra-plugin-stealth padrão | Remenda ~17 pontos de detecção | O Cloudflare adicionou ~12 novas verificações em 2024-2025 não cobertas pelo plugin |
O padrão é claro: ferramentas que envolvem um navegador real e remendam vazamentos conhecidos perdem a corrida armamentista em questão de meses. Ferramentas que simulam a pilha TLS de um navegador (curl_cffi, tls-client) sobreviveram porque estão mais próximas do fio.
Um bypass que funciona em 2026 precisa de todas as quatro camadas. Pular qualquer uma derruba a taxa de sucesso para um único dígito.
Isso é inegociável para qualquer site que rode Cloudflare Pro ou superior. O filtro de reputação de IP rejeita ASNs de datacenter antes que o handshake TLS seja concluído. Use um proxy residencial com sessão sticky por pelo menos 10 minutos para que o cookie cf_clearance sobreviva.
Use curl_cffi (Python) ou tls-client (Go/Python). Ambos se vinculam a um BoringSSL modificado que vem com a ordem exata de cifras, lista de extensões e valores ALPN do Chrome.
from curl_cffi import requests
response = requests.get(
"https://target.com/api/products",
impersonate="chrome124",
proxies={"https": "http://user-session-abc123:[email protected]:10001"},
timeout=30,
)
print(response.status_code, len(response.text))O parâmetro impersonate="chrome124" troca a pilha TLS para que o ClientHello corresponda byte a byte ao Chrome 124. O hash JA4 será idêntico ao de uma instalação real do Chrome 124. Combine-o com um proxy residencial e você passa pelos dois primeiros filtros.
O curl_cffi define os cabeçalhos na ordem do Chrome automaticamente quando você usa impersonate. Se adicionar cabeçalhos personalizados, anexe-os ao final em vez de inserir no meio. Evite definir cabeçalhos que o Chrome real não enviaria (por exemplo, X-Requested-With em uma navegação normal).
Para o Accept-Language, faça-o corresponder à localização geográfica do proxy. Um IP residencial dos EUA enviando Accept-Language: zh-CN,zh;q=0.9 é um sinal pequeno, mas real. Use en-US,en;q=0.9 para IPs dos EUA, de-DE,de;q=0.9 para IPs alemães, e assim por diante. Esse é um dos poucos sinais que você pode corrigir de graça.
Se o alvo dispara um Managed Challenge (você vê uma página de desafio do CF no corpo da resposta), o curl_cffi sozinho não consegue resolvê-lo. Mude para o Playwright com Chromium remendado.
from playwright.sync_api import sync_playwright
from rebrowser_playwright.sync_api import sync_playwright as rebrowser_sync
with rebrowser_sync() as p:
browser = p.chromium.launch(
headless=True,
proxy={
"server": "http://gate.jibaoproxy.com:10001",
"username": "user-session-abc123",
"password": "pass",
},
)
context = browser.new_context(
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36",
viewport={"width": 1920, "height": 1080},
locale="en-US",
timezone_id="America/New_York",
)
page = context.new_page()
page.goto("https://target.com/", wait_until="networkidle")
# cf_clearance is now in context.cookies()
cookies = context.cookies()
cf_clearance = next((c for c in cookies if c["name"] == "cf_clearance"), None)
browser.close()Use rebrowser-playwright em vez do playwright padrão. Ele remenda os vazamentos de runtime do CDP (Runtime.enable, exposição de comandos CDP à página) que o Cloudflare lê para detectar automação headless. Depois que o desafio passa, extraia o cf_clearance dos cookies e devolva-o ao curl_cffi para o loop real de scraping. O navegador é necessário uma vez por sessão, não por requisição.
O instinto de usar o proxy mais barato está quase sempre errado em sites protegidos por Cloudflare. Acompanhe a conta com números reais.
Premissas: página HTML média de 500KB, scraping de 100.000 páginas no total, o alvo usa Cloudflare Pro com Bot Fight Mode habilitado.
| Configuração | Custo de banda | Taxa de sucesso | Requisições por sucesso | Custo total | Custo por página |
|---|---|---|---|---|---|
| Datacenter US$0.8/GB + requests | US$0,0005 / req | 0,5% | 200 | US$10.000 | US$0,10 |
| Datacenter US$0.8/GB + curl_cffi | US$0,0005 / req | 3% | 33 | US$1.650 | US$0,0165 |
| Residencial US$6,8/GB + requests | US$0,0033 / req | 40% | 2,5 | US$825 | US$0,0083 |
| Residencial US$6,8/GB + curl_cffi | US$0,0033 / req | 92% | 1,09 | US$360 | US$0,0036 |
| Residencial US$6,8/GB + Playwright (rebrowser) | US$0,017 / req (assets + JS) | 96% | 1,04 | US$1.700 | US$0,017 |
Dois achados que vale a pena notar:
Este é o padrão que recomendamos a clientes que fazem scraping de alvos protegidos por Cloudflare em escala. Ele minimiza o uso do Playwright (que é lento e caro) e maximiza o uso do curl_cffi (que é rápido e barato).
from curl_cffi import requests as cf_requests
from rebrowser_playwright.sync_api import sync_playwright
PROXY_USER_FMT = "user-session-{sid}"
PROXY_HOST = "http://gate.jibaoproxy.com:10001"
PROXY_PASS = "your_password"
def get_cf_clearance(target_url, session_id):
"""One-shot Playwright call to solve the challenge and extract cf_clearance."""
with sync_playwright() as p:
browser = p.chromium.launch(
headless=True,
proxy={"server": PROXY_HOST,
"username": PROXY_USER_FMT.format(sid=session_id),
"password": PROXY_PASS},
)
ctx = browser.new_context(user_agent="Mozilla/5.0 ... Chrome/124.0.0.0 Safari/537.36")
page = ctx.new_page()
page.goto(target_url, wait_until="networkidle", timeout=45000)
cookies = ctx.cookies()
browser.close()
return {c["name"]: c["value"] for c in cookies}
def scrape_with_clearance(urls, session_id, cookies):
"""Reuse the same session_id (sticky IP) for all requests."""
proxy = f"http://{PROXY_USER_FMT.format(sid=session_id)}:{PROXY_PASS}@gate.jibaoproxy.com:10001"
out = []
for url in urls:
r = cf_requests.get(
url,
impersonate="chrome124",
proxies={"https": proxy},
cookies=cookies,
timeout=30,
)
if r.status_code == 200:
out.append((url, r.text))
elif r.status_code in (403, 503) and "challenge" in r.text.lower():
# cf_clearance expired; re-solve
cookies = get_cf_clearance(url, session_id)
r = cf_requests.get(url, impersonate="chrome124",
proxies={"https": proxy}, cookies=cookies)
out.append((url, r.text))
return out, cookies
# Usage
session_id = "scrape-job-2026-05-27"
cookies = get_cf_clearance("https://target.com/", session_id)
results, cookies = scrape_with_clearance(target_urls, session_id, cookies)Pontos-chave desta receita:
Algumas implantações do Cloudflare não podem ser contornadas a nenhum custo razoável. Se você ver estes sinais, mude de estratégia (use uma API, faça parceria com o dono do site ou compre os dados) em vez de queimar orçamento em um bypass que nunca vai estabilizar.
| Nível do alvo | Receita | Taxa de sucesso esperada |
|---|---|---|
| CF Free / Pro (sem Bot Fight) | Datacenter + curl_cffi | 60-75% |
| CF Free / Pro + Bot Fight Mode | Residencial + curl_cffi | 85-93% |
| CF Business | Residencial + curl_cffi + Playwright ocasional | 80-90% |
| CF Business + Turnstile | Residencial + rebrowser-playwright (toda requisição) | 70-85% |
| CF Enterprise + Bot Management | Residencial móvel + rebrowser + simulação de comportamento | 30-60% |
| CF Enterprise + Bot Management + WAF personalizado | Não faça scraping; busque API ou parceria | <10% |
A JIBAO Proxy oferece proxies residenciais dinâmicos com mais de 90M de IPs em mais de 240 países, sessões sticky de até 60 minutos e segmentação em nível de país a partir de US$6,8/GB. Para IPs móveis, veja proxies móveis dinâmicos. Ambos funcionam de imediato com curl_cffi, tls-client, Playwright, Puppeteer, Selenium e qualquer cliente HTTP que suporte proxies HTTP/SOCKS5.
Leitura relacionada: Sessões de Proxy Sticky vs Rotativas aborda a configuração de sessões em profundidade. Proxies para Agentes de IA explica o caso de uso de agentes de IA, que se sobrepõe fortemente ao fluxo de trabalho de bypass do Cloudflare.
Ganhe 500MB de tráfego grátis. Rode a combinação curl_cffi + residencial sticky contra seu alvo antes de se comprometer.
Iniciar Teste GratuitoNovos usuários recebem 500MB ao se cadastrar, mais um bônus na primeira recarga. Oferta por tempo limitado.