curl_cffi vs requests: Lo que Soluciona y lo que No Puede

Cambiar requests por curl_cffi convierte muchos 403 en 200. También no hace nada en absoluto por una IP quemada. Aquí está la línea entre los dos, y una prueba de quince minutos que te dice de qué lado está tu problema.

La pregunta de curl_cffi vs requests generalmente surge en medio de un incidente: un scraper que funcionó durante meses comienza a devolver 403 en la primera llamada, alguien en Reddit dice que cambies el cliente, y funciona. Ese es un efecto real con una explicación real, pero la forma en que se repite ("simplemente usa curl_cffi") oculta tanto lo que está sucediendo como dónde deja de ayudar. requests no es lento ni está mal escrito. Tiene exactamente una desventaja en un contexto de scraping, es grande, y no tiene nada que ver con la API que escribes. Aquí es donde los dos clientes realmente difieren, qué cambia cuando cambias, y la única cosa que la suplantación nunca solucionará sin importar qué biblioteca elijas.

La única diferencia que importa

Ambas bibliotecas envían los mismos encabezados. La diferencia está un nivel más abajo, en el handshake TLS que abre la conexión antes de que se mueva un solo byte HTTP. requests se basa en urllib3 y OpenSSL, que anuncian una lista de cifrados, un conjunto de extensiones y un orden que pertenecen a Python y nada más. curl_cffi es un enlace a una bifurcación parcheada de curl que reproduce el ClientHello de un navegador byte por byte, junto con su marco HTTP/2 SETTINGS, por lo que sus hashes JA3, JA3N y Akamai coinciden con Chrome real en lugar de una biblioteca de scripting. Los proveedores anti-bot mantienen bases de datos de estas firmas; una discrepancia entre un encabezado User-Agent de Chrome y un handshake de Python es una contradicción de la que no puedes salir. Desempaquetamos la mecánica en JA3 y JA4 fingerprinting, y el mismo efecto explica por qué curl obtiene un 403 donde tu navegador obtiene un 200 en una URL idéntica.

Todo lo demás en la comparación se deriva de la implementación. Debido a que curl_cffi envuelve libcurl, hereda HTTP/2, HTTP/3, websockets y asyncio, ninguno de los cuales requests ha soportado jamás. Debido a que requests es puro Python, se instala en cualquier cosa y tiene una década de ecosistema detrás. Ambas afirmaciones son verdaderas a la vez, y cuál domina depende completamente de tu objetivo.

Una prueba reproducible que puedes realizar en cinco minutos

No tomes la tabla de tasas de éxito de nadie como verdad, incluida la nuestra. La diferencia de huella digital es directamente observable: apunta ambos clientes a un endpoint de eco TLS y compara los hashes que reportan de vuelta. Si las dos líneas coinciden, tu compilación no está suplantando 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 la v0.15 hay una versión de una sola línea del mismo chequeo: curl-cffi get tls.browserleaks.com/json --impersonate chrome. Ejecútalo antes de depurar cualquier otra cosa — separa "mi suplantación está mal configurada" de "mi suplantación está bien y algo más me está bloqueando", que son dos tardes completamente diferentes.

Lo que curl_cffi no soluciona: reputación de IP

Aquí está la parte que el consejo de cambiar la biblioteca omite. Una huella digital TLS responde a la pregunta "¿qué software es este?". No dice nada sobre "¿de dónde viene esto?" — y esa segunda pregunta se responde mediante una búsqueda separada contra tu IP de salida: qué ASN la posee, si es un proveedor de alojamiento o un ISP de consumidor, si ha aparecido en feeds de abuso, cuántas otras sesiones han golpeado este sitio desde la misma dirección en la última hora. Un handshake impecable de Chrome que llega desde una VM en la nube en un rango de centro de datos es un navegador Chrome que aparentemente ha sido instalado en un rack de servidores. Eso no es más convincente que python-requests. En algunos casos es menos, porque la contradicción es más aguda.

Las propias FAQ del proyecto ponen la calidad de IP primero en su lista de factores, por delante de la tasa de solicitudes y las huellas digitales de JavaScript, al explicar por qué la suplantación por sí sola puede no ser suficiente. Ese orden no es un accidente: la reputación es la señal más barata para que un defensor evalúe y la más difícil para que un atacante falsifique, porque a diferencia de un encabezado o una lista de cifrados no puedes generarla localmente. Si tu scraper basado en requests ya estaba ejecutándose a través de un pool de centro de datos y siendo bloqueado, cambiar a curl_cffi en el mismo pool cambia uno de dos chequeos fallidos. Verás una mejora parcial en objetivos blandos y ninguna mejora en absoluto en los duros — que es exactamente el resultado confuso que la gente reporta.

La solución para ese eje es la calidad de la dirección, no el código: IPs residenciales de asignaciones reales de ISP de consumidores, que es lo que 90M+ direcciones en más de 200 países te compran. Si quieres verificar cómo se ve tu salida actual antes de cambiar algo, nuestro verificador de calidad de IP gratuito informa el ASN y la clasificación que vería un objetivo.

El 2x2 que te dice qué eje está roto

En lugar de adivinar, prueba ambas variables de forma independiente contra tu objetivo real. Cuatro solicitudes, cuatro líneas de salida, y el resultado nombra tu 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))

Lee los cuatro resultados como una tabla de verdad:

• Solo fallan las filas del centro de datos — es la reputación de IP. El cliente es irrelevante; compra mejores salidas.
• Solo fallan las filas de requests — es la huella digital TLS. Cambia de cliente y mantén tu pool existente.
• Solo pasa la última fila — ambos chequeos están activos. Necesitas suplantación e IPs limpias juntas; este es el caso común en objetivos serios.
• Fallan las cuatro — estás más allá de lo que cualquier cliente HTTP puede hacer. Eso significa un desafío de JavaScript, un token que no estás generando, o un bloqueo a nivel de cuenta. Recurre a un navegador real o a una Scraper API gestionada.
• Pasan las cuatro — nunca tuviste un problema de huella digital. No añadas la dependencia.

Ejecuta esto unas cuantas docenas de veces en lugar de una sola. Ambas capas de bloqueo son probabilísticas, y un solo 200 no te dice casi nada.

Prueba la fila residencial con IPs reales de hogares

Cuando la dependencia extra no vale la pena

La franqueza es más barata que una reescritura. Quédate en requests cuando:

• Estás llamando a una API que estás autorizado a llamar. Los endpoints documentados con tu propia clave no te identifican. Añadir suplantación allí es un culto al cargo.
• Tu objetivo de despliegue es incómodo. curl_cffi envía ruedas compiladas y necesita Python 3.10 o más reciente desde la v0.14. requests se ejecuta en prácticamente cualquier cosa, incluidas imágenes antiguas y entornos embebidos limitados.
• Dependes del ecosistema de requests. Adaptadores personalizados, requests-cache, requests-oauthlib y similares todos enganchan la capa de transporte que curl_cffi deliberadamente no expone.
• Necesitas reintentos de códigos de estado de fábrica. Retry de urllib3 con status_forcelist reintenta en 429 y 503; el parámetro retry de curl_cffi solo vuelve a ejecutar en excepciones de transporte.
• Tus bloqueos son de comportamiento. Los límites de tasa, las prohibiciones de cuenta y las cuotas por sesión no se preocupan en absoluto por el handshake.

Y hay un camino intermedio que la mayoría de la gente pasa por alto: no tienes que abandonar requests para obtener el handshake. Los mantenedores señalan curl-adapter, que monta curl_cffi como un adaptador de transporte de requests, y httpx-curl-cffi en PyPI, que hace lo mismo para httpx. Mantienes tu código y ecosistema existentes, y solo los bytes en el cable cambian.

Aspectos a tener en cuenta antes de la migración

La API es lo suficientemente cercana como para que la mayoría de los scripts se ejecuten después de cambiar la importación, pero la página de compatibilidad enumera diferencias reales y vale la pena leerlas antes de una gran migración. Los cuerpos de respuesta de redirección no se retienen en Response.history. Las cookies con dominios vacíos pueden perderse a través de redirecciones. Los objetos de respuesta de streaming no se pueden serializar, aunque las respuestas normales sí. La API de archivos difiere ligeramente. Y no hay transportes ni adaptadores en absoluto, porque la biblioteca está deliberadamente soldada a libcurl-impersonate. La configuración de proxy también difiere de una manera pequeña que confunde a la gente:

# 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

La superficie completa del proxy — claves de dict, proxy_auth, rotación por solicitud, async y el prefijo https:// que produce un error de WRONG_VERSION_NUMBER poco útil — está cubierta paso a paso en nuestra guía de proxy de curl_cffi. Si te quedas, la referencia equivalente para el otro lado es nuestra guía de proxy de Python Requests.

Preguntas frecuentes

¿Es curl_cffi más rápido que requests?

Sí, y los benchmarks del proyecto lo sitúan a la par con aiohttp y pycurl en lugar de con requests. La ganancia proviene de que libcurl hace el trabajo en C más la multiplexación HTTP/2, no de un Python ingenioso. Para un puñado de llamadas secuenciales la diferencia es invisible; a alta concurrencia, especialmente con async, es sustancial.

¿Es seguro usar curl_cffi?

Tiene licencia MIT, está ampliamente desplegado y envía ruedas precompiladas, por lo que no hay un paso de construcción para auditar. Vale la pena actuar sobre una advertencia: un aviso de la v0.15.0 cubre SSRF basado en redirecciones. Si obtienes URLs proporcionadas por otras personas, configura allow_redirects="safe" o desactiva las redirecciones. Suplantar un navegador es una medida técnica, no un permiso para ignorar los términos de un sitio.

¿curl_cffi evita Cloudflare?

Elimina la señal de huella digital TLS y HTTP/2, lo que despeja los niveles básicos de protección. No puede ejecutar un desafío de JavaScript, resolver Turnstile, ni arreglar una IP de salida marcada. Los mantenedores dicen tanto en sus FAQ, y recomiendan un mejor pool de proxies más automatización de navegador para los niveles superiores.

curl_cffi vs httpx o tls_client — ¿cuál debería usar?

httpx te da HTTP/2 y async pero no suplantación de huellas digitales, por lo que se sitúa entre requests y curl_cffi en sigilo. tls_client también falsifica perfiles TLS y tiene benchmarks similares; curl_cffi tiene la comunidad más grande y añade HTTP/3 y websockets. Si httpx ya está en tu stack, el transporte httpx-curl-cffi te da suplantación sin una reescritura.

La versión corta: cambia a curl_cffi cuando tu objetivo lee handshakes, quédate en requests cuando no lo hace, y nunca esperes que ninguna elección lave una IP de centro de datos. Los clientes difieren en un eje, los proxies en otro, y los scrapers bloqueados son casi siempre una historia sobre ambos. Ejecuta las cuatro pruebas, lee la tabla de verdad, y arregla el eje al que apuntan los datos en lugar del que gritó internet.

Arregla el eje que la suplantación no puede alcanzar