Cómo Eludir Cloudflare en 2026 (Sin Quemar IPs de Centro de Datos)

La mayoría de los tutoriales de "cómo eludir Cloudflare" que circulan por internet dejaron de funcionar a finales de 2024. La razón no es que Cloudflare añadiera nuevas defensas. Es que las defensas antiguas, el fingerprinting JA3 y las comprobaciones básicas de cabeceras, fueron reemplazadas por una nueva generación que rompe todos los atajos. Esta guía explica qué comprueba realmente Cloudflare en 2026, por qué cloudscraper, undetected-chromedriver y la mayoría de los plugins "stealth" fallan, y la receta de cuatro capas que aún funciona en producción.

El resumen honesto de entrada: no existe un único truco. Eludir Cloudflare de forma fiable requiere la IP correcta, la huella TLS correcta, el orden correcto de frames HTTP/2 y (para el nivel Bot Management) un navegador real. Si fallas en cualquiera de estos, no superas el filtro del edge antes de que tu petición llegue siquiera al servidor de origen.

Qué comprueba realmente Cloudflare en 2026

La detección de bots de Cloudflare funciona como una cadena de filtros en el edge. Cada petición pasa por ellos en orden. Gana el primer filtro que rechaza, lo que significa que una petición puede fallar solo por la reputación de IP antes de que se examine cualquier huella o cabecera.

1. Reputación de IP (ASN + historial de abusos)

Esta es la primera comprobación y la más barata. Cloudflare mantiene una base de datos indexada por ASN (Autonomous System Number). Los ASN pertenecientes a proveedores de nube conocidos (AWS AS16509, GCP AS15169, Azure AS8075, OVH AS16276, DigitalOcean AS14061, Hetzner AS24940, Vultr AS20473) reciben el mayor escrutinio. Incluso con una huella perfecta a nivel de navegador, una petición que se origina en estos ASN se trata como culpable hasta que se demuestre lo contrario.

Los ASN residenciales (Comcast AS7922, Verizon AS701, China Telecom AS4134, BT AS2856) se presumen legítimos. Una petición desde una IP residencial con una huella torpe de Python puede pasar igualmente, mientras que una petición desde una IP de centro de datos con una huella perfecta de Chrome será desafiada o bloqueada.

2. Huella TLS JA4

JA4 es el sucesor de 2023 de JA3, publicado por FoxIO. Hashea campos específicos del ClientHello de TLS: versión de TLS, suites de cifrado (en orden), extensiones (en orden), protocolos ALPN, algoritmos de firma y grupos soportados. La salida es una huella determinista como t13d1516h2_8daaf6152771_b1ff8ab2d16f.

El Chrome 124 real produce una JA4 específica. El Firefox 124 real produce una distinta. La librería requests de Python (que usa urllib3 y OpenSSL) produce una JA4 que ningún navegador real emite jamás, porque el orden de cifrado y la lista de extensiones no coinciden ni con Chrome ni con Firefox. Cloudflare marca este patrón antes de analizar cualquier cabecera HTTP.

La implicación: toda librería que use el OpenSSL del sistema o el TLS estándar de Python es detectable. Esto incluye requests, aiohttp, httpx (configuración por defecto) y cualquier wrapper de "bypass" construido encima de ellas.

3. Orden de frames HTTP/2 y secuencia de pseudo-cabeceras

Las conexiones HTTP/2 transportan frames de settings, window updates, frames de prioridad y frames de cabeceras. Los navegadores los envían en un orden específico con valores específicos. Chrome 124 envía un frame SETTINGS inicial con estos valores exactos, luego un WINDOW_UPDATE y luego HEADERS. El httpx de Python con HTTP/2 activado envía una carga de settings distinta y omite los frames de prioridad que Chrome incluye.

El orden de las pseudo-cabeceras de HTTP/2 también filtra la identidad. Chrome envía :method, :authority, :scheme, :path en ese orden. Firefox envía :method, :path, :authority, :scheme. La mayoría de las librerías de Python y Go las serializan alfabéticamente. Cloudflare compara el orden con el patrón esperado para el User-Agent declarado y marca las discrepancias.

4. Orden y mayúsculas de las cabeceras

Las cabeceras de HTTP/1.1 preservan el orden de inserción. El Chrome real envía las cabeceras en un orden fijo: 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. El requests de Python las reordena y a veces usa mayúsculas distintas. Incluso fijar las cabeceras manualmente en el orden correcto no ayuda, porque la librería subyacente las vuelve a ordenar.

5. Desafío de JavaScript (Managed Challenge)

Si los filtros anteriores pasan pero la puntuación sigue siendo sospechosa, Cloudflare sirve un desafío de JavaScript. El script calcula un token a partir de valores del entorno del navegador (hash de canvas, renderer de WebGL, audio context, propiedades de navigator, mediciones de tiempo) y lo envía vía XHR. Ningún cliente HTTP puede resolver esto. Necesitas un navegador real, y el navegador debe parecer real (sin navigator.webdriver = true, sin propiedades faltantes).

6. Señales de comportamiento (solo Bot Management Enterprise)

En el nivel Bot Management, Cloudflare recopila el movimiento del ratón, la velocidad de scroll, el timing de los clics y la dinámica de pulsación de teclas mediante un script que se ejecuta de forma continua. Un navegador headless que carga la página y la scrapea inmediatamente sin mover nunca el ratón es detectado en segundos. Los usuarios reales se mueven de forma errática, hacen pausas y releen. Los bots scrollean de forma lineal y hacen clic con precisión de píxel.

Por qué la mayoría de las herramientas de bypass de la era 2024 están muertas

Las herramientas atajo que impulsaron el scraping de 2021-2024 comparten todas un mismo modo de fallo: parchean la superficie visible pero no la pila TLS subyacente.

El patrón es claro: las herramientas que envuelven un navegador real y parchean fugas conocidas pierden la carrera armamentística en cuestión de meses. Las herramientas que simulan la pila TLS de un navegador (curl_cffi, tls-client) han sobrevivido porque se sitúan más cerca del cable.

La receta de cuatro capas que aún funciona

Un bypass que funcione en 2026 necesita las cuatro capas. Saltarse cualquiera de ellas reduce la tasa de éxito a un solo dígito.

Capa 1: IP residencial o móvil

Esto es innegociable para cualquier sitio que use Cloudflare Pro o superior. El filtro de reputación de IP rechaza los ASN de centro de datos antes de que se complete el handshake TLS. Usa un proxy residencial con una sesión sticky de al menos 10 minutos para que la cookie cf_clearance sobreviva.

Capa 2: Huella TLS de navegador real

Usa curl_cffi (Python) o tls-client (Go/Python). Ambos enlazan contra un BoringSSL modificado que incorpora el orden de cifrado exacto de Chrome, su lista de extensiones y sus valores ALPN.

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))

El parámetro impersonate="chrome124" intercambia la pila TLS para que el ClientHello coincida con Chrome 124 byte a byte. El hash JA4 será idéntico al de una instalación real de Chrome 124. Combínalo con un proxy residencial y superas los dos primeros filtros.

Capa 3: Orden de cabeceras que coincida con el navegador suplantado

curl_cffi fija las cabeceras en el orden de Chrome automáticamente cuando usas impersonate. Si añades cabeceras personalizadas, agrégalas al final en lugar de insertarlas en medio. Evita fijar cabeceras que el Chrome real no enviaría (p. ej., X-Requested-With en una navegación normal).

Para Accept-Language, hazlo coincidir con la ubicación geográfica del proxy. Una IP residencial de EE. UU. enviando Accept-Language: zh-CN,zh;q=0.9 es una señal pequeña pero real. Usa en-US,en;q=0.9 para IPs de EE. UU., de-DE,de;q=0.9 para IPs alemanas, y así sucesivamente. Esta es una de las pocas señales que puedes corregir gratis.

Capa 4: Navegador real para desafíos JS (cuando se requiera)

Si el objetivo dispara un Managed Challenge (ves una página de desafío de CF en el cuerpo de la respuesta), curl_cffi por sí solo no puede resolverlo. Cambia a Playwright con Chromium parcheado.

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()

Usa rebrowser-playwright en lugar del playwright estándar. Parchea las fugas del runtime de CDP (Runtime.enable, la exposición de comandos CDP a la página) que Cloudflare lee para detectar automatización headless. Tras superar el desafío, extrae cf_clearance de las cookies y pásalo de vuelta a curl_cffi para el bucle de scraping real. El navegador se necesita una vez por sesión, no por petición.

La cuenta del coste: por qué el residencial gana en objetivos protegidos

El instinto de usar el proxy más barato casi siempre está equivocado en sitios protegidos por Cloudflare. Repasemos los números con cifras reales.

Supuestos: página HTML promedio de 500KB, scraping de 100,000 páginas en total, el objetivo usa Cloudflare Pro con Bot Fight Mode activado.

Dos hallazgos que vale la pena destacar:

1. Residencial + curl_cffi es el ganador en coste por éxito por un factor de 3-18 veces sobre cualquier otra combinación. La intuición de que el residencial es "caro" es correcta en $/GB pero errónea en $/página exitosa.
2. Playwright es más caro por petición porque descarga el bundle completo de assets (CSS, JS, imágenes). Úsalo solo para la única petición que resuelve el desafío, y luego pasa cf_clearance a curl_cffi.

Receta práctica: un scraper de grado producción

Este es el patrón que recomendamos a los clientes que scrapean objetivos protegidos por Cloudflare a escala. Minimiza el uso de Playwright (que es lento y caro) y maximiza el uso de curl_cffi (que es rápido y 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)

Puntos clave de esta receta:

• Una llamada a Playwright por sesión. El navegador resuelve el desafío, entrega la cookie cf_clearance a curl_cffi y luego se cierra. Todas las peticiones posteriores pasan por curl_cffi a máxima velocidad.
• ID de sesión sticky ligado al trabajo de scraping. La misma IP durante toda la vida útil de cf_clearance (normalmente 30 minutos). Reutilizar la cookie en una IP distinta la invalida.
• Re-desafío automático. Cuando cf_clearance expira, la respuesta contiene una página de desafío de CF. Captúrala y vuelve a resolver con Playwright, luego reanuda.
• impersonate="chrome124" coincide con la cadena User-Agent que fijas en Playwright. Un UA y una JA4 que no coinciden son en sí mismos una señal de detección.

Cuándo rendirse

Algunos despliegues de Cloudflare no se pueden eludir a ningún coste razonable. Si ves estas señales, cambia de estrategia (usa una API, asóciate con el dueño del sitio o compra los datos) en lugar de quemar presupuesto en un bypass que nunca se estabilizará.

• Cloudflare Bot Management Enterprise + Turnstile + seguimiento de comportamiento. Bancos, procesadores de pagos, sitios de venta de entradas (Ticketmaster) y algunas plataformas de apuestas deportivas. Tasa de éxito por debajo del 5% incluso con residencial perfecto + rebrowser. El coste por petición exitosa se acerca a $1.
• Reglas WAF personalizadas montadas encima de CF. Algunos sitios añaden límites de tasa por IP residencial que se disparan tras 3-5 peticiones. Ningún proxy puede recuperarse de una limitación de tasa cocinada en la lógica de la aplicación.
• Sitios que requieren login + 2FA + vinculación de dispositivo. Cloudflare no es el único obstáculo; incluso con un cf_clearance válido, la capa de aplicación exige un dispositivo registrado.

Referencia rápida

JIBAO Proxy ofrece proxies residenciales dinámicos con más de 90M de IPs en más de 240 países, sesiones sticky de hasta 60 minutos y segmentación a nivel de país desde $2/GB. Para IPs móviles, consulta los proxies móviles dinámicos. Ambos funcionan de inmediato con curl_cffi, tls-client, Playwright, Puppeteer, Selenium y cualquier cliente HTTP que soporte proxies HTTP/SOCKS5.

Lectura relacionada: Sesiones de Proxy Sticky vs Rotativas cubre en profundidad la configuración de sesiones. Proxies para Agentes de IA explica el caso de uso de agentes de IA que se solapa fuertemente con el flujo de trabajo de elusión de Cloudflare.