curl_cffi vs requests: O que Resolve e o que Não Pode

Trocar requests por curl_cffi transforma muitos 403 em 200. Também não faz nada para um IP queimado. Aqui está a linha entre os dois, e um teste de quinze minutos que te diz de que lado está o seu problema.

A questão curl_cffi vs requests geralmente surge no meio de um incidente: um scraper que funcionou por meses começa a retornar 403 na primeira chamada, alguém no Reddit diz para trocar o cliente, e funciona. Esse é um efeito real com uma explicação real — mas a forma como é repetido ("apenas use curl_cffi") esconde tanto o que está acontecendo quanto onde ele para de ajudar. requests não é lento ou mal escrito. Ele tem exatamente uma desvantagem em um contexto de scraping, é uma grande, e não tem nada a ver com a API que você digita. Aqui é onde os dois clientes realmente diferem, o que muda quando você troca, e a única coisa que a personificação nunca vai corrigir, não importa qual biblioteca você escolha.

A única diferença que importa

Ambas as bibliotecas enviam os mesmos cabeçalhos. A diferença está uma camada abaixo, no handshake TLS que abre a conexão antes de um único byte HTTP se mover. requests se baseia em urllib3 e OpenSSL, que anunciam uma lista de cifras, conjunto de extensões e ordenação que pertencem ao Python e nada mais. curl_cffi é uma ligação a um fork modificado do curl que reproduz o ClientHello de um navegador byte a byte, junto com seu quadro SETTINGS HTTP/2 — então seus hashes JA3, JA3N e Akamai correspondem ao Chrome real em vez de uma biblioteca de script. Fornecedores anti-bot mantêm bancos de dados dessas assinaturas; uma discrepância entre um cabeçalho User-Agent do Chrome e um handshake do Python é uma contradição da qual você não pode se livrar. Descompactamos a mecânica em JA3 e JA4 fingerprinting, e o mesmo efeito explica por que curl recebe um 403 onde seu navegador recebe um 200 em uma URL idêntica.

Todo o resto na comparação decorre da implementação. Porque curl_cffi envolve libcurl, herda HTTP/2, HTTP/3, websockets e asyncio, nenhum dos quais requests jamais suportou. Porque requests é puramente Python, instala-se em qualquer coisa e tem uma década de ecossistema por trás. Ambas as afirmações são verdadeiras ao mesmo tempo, e qual delas domina depende inteiramente do seu alvo.

Um teste reproduzível que você pode executar em cinco minutos

Não acredite cegamente na tabela de taxa de sucesso de ninguém, incluindo a nossa. A diferença de impressão digital é diretamente observável: aponte ambos os clientes para um endpoint de eco TLS e compare os hashes que eles retornam. Se as duas linhas coincidirem, sua construção não está personificando nada.

# pip install requests curl_cffi
import requests
import curl_cffi

URL = "https://tls.browserleaks.com/json"

a = requests.get(URL, timeout=30).json()
b = curl_cffi.get(URL, impersonate="chrome", timeout=30).json()

print("requests   ja3n:", a["ja3n_hash"], "| akamai:", a.get("akamai_hash", "-"))
print("curl_cffi  ja3n:", b["ja3n_hash"], "| akamai:", b.get("akamai_hash", "-"))

# Two different ja3n hashes = impersonation is working. The curl_cffi README
# documents aa56c057ad164ec4fdcb7a5a283be9fc as a Chrome-matched ja3n value.
# The akamai (HTTP/2) fingerprint is usually empty for requests: it is
# HTTP/1.1 only, so there is no SETTINGS frame to fingerprint in the first place.

Desde a v0.15 há uma versão de uma linha do mesmo teste: curl-cffi get tls.browserleaks.com/json --impersonate chrome. Execute isso antes de depurar qualquer outra coisa — isso separa "minha personificação está mal configurada" de "minha personificação está bem e algo mais está me bloqueando", que são duas tardes completamente diferentes.

Comparação lado a lado de requests e curl_cffi em suporte a protocolos, concorrência, impressão digital e portabilidade
requests ganha em portabilidade e ecossistema; curl_cffi ganha em protocolos e impressões digitais. Nenhum ganha em qualidade de IP — isso não é uma característica do cliente.

O que curl_cffi não corrige: reputação de IP

Aqui está a parte que o conselho de trocar a biblioteca deixa de fora. Uma impressão digital TLS responde à pergunta "que software é este?". Não diz nada sobre "de onde isso está vindo?" — e essa segunda pergunta é respondida por uma consulta separada contra seu IP de saída: qual ASN o possui, é um provedor de hospedagem ou um ISP consumidor, apareceu em feeds de abuso, quantas outras sessões atingiram este site do mesmo endereço na última hora. Um handshake Chrome impecável chegando de uma VM em nuvem em uma faixa de datacenter é um navegador Chrome que aparentemente foi instalado em um rack de servidor. Isso não é mais convincente do que python-requests. Em alguns casos é menos, porque a contradição é mais acentuada.

O próprio FAQ do projeto coloca a qualidade do IP em primeiro lugar em sua lista de fatores, à frente da taxa de requisição e impressões digitais de JavaScript, ao explicar por que a personificação sozinha pode não ser suficiente. Essa ordem não é um acidente: a reputação é o sinal mais barato para um defensor avaliar e o mais difícil para um atacante falsificar, porque ao contrário de um cabeçalho ou uma lista de cifras, você não pode gerá-la localmente. Se seu scraper baseado em requests já estava rodando através de um pool de datacenter e sendo bloqueado, mudar para curl_cffi no mesmo pool muda uma de duas verificações falhas. Você verá uma melhoria parcial em alvos suaves e nenhuma melhoria em alvos difíceis — que é exatamente o resultado confuso que as pessoas relatam.

A correção para esse eixo é a qualidade do endereço, não o código: IPs residenciais de alocações reais de ISPs consumidores, que é o que 90M+ endereços em mais de 200 países te oferecem. Se você quiser verificar como está sua saída atual antes de mudar qualquer coisa, nosso verificador de qualidade de IP gratuito relata o ASN e a classificação que um alvo veria.

O 2x2 que te diz qual eixo está quebrado

Em vez de adivinhar, teste ambas as variáveis independentemente contra seu alvo real. Quatro requisições, quatro linhas de saída, e o resultado nomeia seu problema:

import requests
import curl_cffi

TARGET = "https://your-target.example/api/items"
DC  = "http://USER:PASS@your-datacenter-gateway:PORT"
RES = "http://USER:PASS@gate.quantumproxies.io:PORT"

def probe(label, fn):
    try:
        print(f"{label:26} -> {fn().status_code}")
    except Exception as e:
        print(f"{label:26} -> {type(e).__name__}")

probe("requests  + datacenter",
      lambda: requests.get(TARGET, proxies={"https": DC}, timeout=30))
probe("curl_cffi + datacenter",
      lambda: curl_cffi.get(TARGET, proxy=DC, impersonate="chrome", timeout=30))
probe("requests  + residential",
      lambda: requests.get(TARGET, proxies={"https": RES}, timeout=30))
probe("curl_cffi + residential",
      lambda: curl_cffi.get(TARGET, proxy=RES, impersonate="chrome", timeout=30))

Leia os quatro resultados como uma tabela de verdade:

Execute isso algumas dezenas de vezes em vez de uma única. Ambas as camadas de bloqueio são probabilísticas, e um único 200 não te diz quase nada.

Teste a linha residencial com IPs reais de residências

Diagrama mostrando um handshake TLS compatível com navegador de um IP de datacenter sendo bloqueado enquanto o mesmo handshake de um IP residencial passa
Personificação e reputação de IP são portões separados. Corrigir um e deixar o outro é por que 'eu mudei para curl_cffi e nada mudou' é um relatório tão comum.

Quando a dependência extra não vale a pena

A franqueza é mais barata que uma reescrita. Fique com requests quando:

E há um caminho do meio que a maioria das pessoas perde: você não precisa abandonar requests para obter o handshake. Os mantenedores apontam para curl-adapter, que monta curl_cffi como um adaptador de transporte requests, e httpx-curl-cffi no PyPI, que faz o mesmo para httpx. Você mantém seu código e ecossistema existentes, e apenas os bytes na rede mudam.

Pegadinhas de migração que vale a pena saber primeiro

A API é próxima o suficiente para que a maioria dos scripts funcione após mudar a importação, mas a página de compatibilidade lista diferenças reais e vale a pena lê-las antes de uma grande portabilidade. Corpos de resposta de redirecionamento não são retidos em Response.history. Cookies com domínios vazios podem ser perdidos em redirecionamentos. Objetos de resposta de streaming não podem ser serializados, embora respostas normais possam. E não há transportes ou adaptadores, porque a biblioteca é deliberadamente soldada ao libcurl-impersonate. A configuração de proxy também difere de uma pequena maneira que confunde as pessoas:

# requests: dict, and retries mounted on an adapter
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

s = requests.Session()
s.mount("https://", HTTPAdapter(max_retries=Retry(total=4, status_forcelist=[429, 503])))
r = s.get(url, proxies={"https": "http://USER:PASS@gate.quantumproxies.io:PORT"}, timeout=30)

# curl_cffi: single proxy string preferred, retries are a session parameter
from curl_cffi import Session
from curl_cffi.requests import RetryStrategy

s = Session(
    impersonate="chrome",
    proxy="http://USER:PASS@gate.quantumproxies.io:PORT",
    retry=RetryStrategy(count=4, delay=1.0, backoff="exponential"),
    timeout=30,
)
r = s.get(url)  # note: retry fires on transport errors, not on 429/503

A superfície completa do proxy — chaves de dicionário, proxy_auth, rotação por requisição, async e o prefixo https:// que produz um erro WRONG_VERSION_NUMBER não útil — é coberta passo a passo em nosso guia de proxy curl_cffi. Se você está ficando, a referência equivalente para o outro lado é nosso guia de proxy Python Requests.

Perguntas frequentes

curl_cffi é mais rápido que requests?

Sim, e os benchmarks do projeto o colocam no mesmo nível de aiohttp e pycurl em vez de requests. O ganho vem do libcurl fazendo o trabalho em C mais a multiplexação HTTP/2, não de um Python inteligente. Para um punhado de chamadas sequenciais a diferença é invisível; em alta concorrência, especialmente com async, é substancial.

curl_cffi é seguro para usar?

É licenciado pelo MIT, amplamente implantado e envia rodas pré-compiladas, então não há etapa de construção para auditar. Um aviso vale a pena ser seguido: um aviso da v0.15.0 cobre SSRF baseado em redirecionamento. Se você buscar URLs fornecidos por outras pessoas, defina allow_redirects="safe" ou desative redirecionamentos. Personificar um navegador é uma medida técnica, não permissão para ignorar os termos de um site.

curl_cffi contorna Cloudflare?

Remove a impressão digital TLS e HTTP/2, o que limpa níveis básicos de proteção. Não pode executar um desafio JavaScript, resolver Turnstile, ou corrigir um IP de saída sinalizado. Os mantenedores dizem isso em seu FAQ, e recomendam um pool de proxy melhor mais automação de navegador para os níveis mais altos.

curl_cffi vs httpx ou tls_client — qual devo usar?

httpx te dá HTTP/2 e async mas sem personificação de impressão digital, então fica entre requests e curl_cffi em discrição. tls_client também falsifica perfis TLS e tem benchmarks semelhantes; curl_cffi tem a maior comunidade e adiciona HTTP/3 e websockets. Se httpx já está na sua pilha, o transporte httpx-curl-cffi te dá personificação sem uma reescrita.

A versão curta: mude para curl_cffi quando seu alvo lê handshakes, permaneça em requests quando não lê, e nunca espere que qualquer escolha limpe um IP de datacenter. Os clientes diferem em um eixo, os proxies em outro, e scrapers bloqueados são quase sempre uma história sobre ambos. Execute as quatro sondagens, leia a tabela de verdade, e corrija o eixo que os dados apontam em vez do que a internet gritou.

Corrija o eixo que a personificação não pode alcançar