Prueba de referencia del desafío de Cloudflare: Herramientas para navegadores comparadas

TL;DR:

• Superar un desafío de Cloudflare en producción es un problema de IP antes de ser un problema de navegador. Un navegador parcheado en una IP de servidor marcada se detiene en el intersticial; un navegador real en un egreso residencial limpio carga la página.
• Scrapeless Scraping Browser superó el desafío de Cloudflare en 7 de 8 intentos en un banco de pruebas abierto y reproducible — el más alto de todas las herramientas medidas, y el único que se mantiene cuando la solicitud sale de una IP domiciliaria a una de centro de datos.
• Tres de las cuatro herramientas de navegador de código abierto probadas — patchright, camoufox y nodriver — no lo superaron en ninguno de los 8 intentos, junto al umbral de HTTP simple; en el mismo objetivo y pruebas, cada una se quedó atascada en "Solo un momento…".
• La única herramienta de código abierto que compitió — SeleniumBase UC en 6 de 8 — solo lo hace en una IP residencial, el caso más favorable para una pila auto-alojada. Moverse a las IPs de centro de datos donde corren los pipelines reales hace que esa ventaja desaparezca.
• Cada número aquí es reproducible. La estructura es un benchmark de Cloudflare de código abierto en GitHub: objetivos idénticos, un intento por prueba, sin segundos intentos, un evaluador para todas las herramientas. Clónalo y ejecútalo tú mismo.
• Gratis para empezar. Las nuevas cuentas de Scrapeless incluyen tiempo de ejecución gratuito para el Scraping Browser — regístrate en app.scrapeless.com.

---

Introducción: qué realmente supera Cloudflare en producción

El desafío de Cloudflare es un problema de renderización que adopta la apariencia de un problema de red. El intersticial — "Solo un momento…", un spinner, "Verificando que eres humano" — ejecuta una carga de trabajo de JavaScript y lee tres señales a la vez: si un navegador real ejecuta el desafío, si la huella digital es internamente consistente y si la IP de salida tiene una reputación limpia. Si falla en cualquiera de estas, la página nunca se resuelve.

La mayoría de los informes responden a "¿cómo puedo superar esto?" con una recomendación de biblioteca y un complemento furtivo. Esa respuesta es comprobable y generalmente falla en el lugar que importa: un servidor de producción. Una herramienta que supera el desafío desde una laptop en Wi-Fi doméstico se comporta de forma muy diferente una vez que se ejecuta desde una instancia en la nube, porque la IP de salida cambia de residencial a centro de datos y la señal de reputación colapsa.

Esta publicación mide la diferencia en lugar de afirmarla. Camina a través de un benchmark abierto que ejecuta el Scrapeless Scraping Browser contra cuatro herramientas anti-detección de código abierto y una base de HTTP simple, sobre el mismo desafío de Cloudflare, y reporta tasa de éxito, latencia y estabilidad a partir de datos crudos por prueba que cualquiera puede regenerar.

Qué puedes medir con esto

• Tasa de éxito por herramienta — ¿renderiza la página real o se agota en el intersticial?
• Latencia de un clear — p50 y p95 del tiempo desde la solicitud hasta el contenido renderizado.
• Estabilidad a lo largo de ejecuciones repetidas — la dispersión de la tasa de éxito a lo largo de ventanas de prueba, la señal de si una herramienta se mantiene firme.
• Costo por solicitud exitosa — bytes movidos por clear contra tasas de egreso publicadas, de modo que una herramienta "gratuita" que rara vez tiene éxito muestra su verdadero costo.
• El efecto de IP — las mismas herramientas en una IP residencial frente a una IP de centro de datos, que es donde realmente se ejecuta la producción.

Por qué Scrapeless Scraping Browser

Scrapeless Scraping Browser es un navegador en la nube, personalizable y anti-detección, diseñado para rastreadores web y agentes de IA. Para superar desafíos activos específicamente, aporta:

• Chromium auto-desarrollado que ejecuta el JavaScript del desafío como un navegador real, no como un cliente HTTP adivinando encabezados.
• Proxies residenciales en más de 195 países como el egreso predeterminado, de modo que la señal de reputación se lea limpia en lugar de marcada por un centro de datos — la señal que decide la mayoría de los resultados de los desafíos.
• Huella digital anti-detección por sesión (agente de usuario, zona horaria, canvas, WebGL) mantenida internamente consistente, de modo que la verificación de la huella digital se apruebe.
• Manejo nativo de tipos comunes de desafío — reCAPTCHA v2, Cloudflare Turnstile y el intersticial de Cloudflare — sin necesidad de un solucionador separado conectado.
• Persistencia de sesión que mantiene una sesión equivalente cálida, de modo que una sesión validada se reutiliza en lugar de volver a validarse en cada solicitud.

Obtén tu clave API en el plan gratuito en app.scrapeless.com.

Cómo el benchmark mide un "clear"

La equidad es el objetivo principal, por lo que las reglas son idénticas para cada herramienta:

• Un objetivo, una definición de éxito. Cada herramienta carga la misma página de desafío pública de Cloudflare y es calificada por una función neutral al proveedor: la página se despeja solo cuando el título intersticial cambia al título de la página real y el contenido se renderiza. "Solo un momento…" es un fallo, y también lo es una página que nunca deja el spinner.
• Un intento por prueba, sin segundas oportunidades. Ninguna herramienta recibe una segunda asignación o un bucle de reconexión para ocultar una mala ejecución. Esto refleja cómo se comporta una única solicitud de producción y mantiene la comparación honesta: un presupuesto de segundo intento halagaría de manera desigual a cada herramienta.
• Un límite de tiempo para todos. El mismo techo del reloj aplica en todo el campo, por lo que una herramienta que "tiene éxito" después de dos minutos de esfuerzo es puntuado de la misma manera que lo haría una tubería real.
• Costo medido, no afirmado. Los bytes transmitidos por una limpieza exitosa se capturan del lado del cliente y se multiplican por la tarifa de egreso publicada de cada herramienta. Las herramientas de código abierto en su propia IP mueven bytes de forma gratuita, pero una herramienta que rara vez se despeja tiene un costo punitivo por éxito, que la tarifa cruda oculta.

El campo: el Scrapeless Scraping Browser; nodriver, patchright, camoufox, y SeleniumBase (modo no detectado) como herramientas de navegador de código abierto; y un cliente HTTP simple como el mínimo. El vocabulario de amenazas automatizadas para el que se construyen estos desafíos está catalogado en el proyecto OWASP de Amenazas Automatizadas a Aplicaciones Web, y las tres señales se mapean claramente en él: el apretón de manos TLS descrito en la especificación TLS 1.3, la huella digital del navegador, y la cookie de clearance establecida por la especificación de Gestión de Estado HTTP. La propia descripción de Cloudflare sobre los tipos de desafío que proporciona se encuentra en la documentación de desafíos de Cloudflare.

Obtén tu clave API en el plan gratuito: app.scrapeless.com

Resultados en una IP residencial (el mejor caso de las herramientas de código abierto)

Ejecutado desde una IP residencial — el egreso más favorable que puede tener una herramienta autoalojada — el campo se divide con claridad. Ocho pruebas por herramienta, un intento cada una, tiempo de espera idéntico:

Las calificaciones utilizan una escala de cuatro niveles en ocho pruebas: Muy Alto = 7–8/8 despejados · Alto = 5–6/8 · Medio = 3–4/8 · Bajo = 0–2/8. Los conteos exactos por prueba están en la tabla de resultados del benchmark, por lo que cada calificación rastrea de vuelta a la ejecución.

Herramienta	Despejó el desafío	Notas
Scrapeless Scraping Browser	Muy Alto	el mejor en el campo; despejó el desafío en casi todas las pruebas
SeleniumBase (modo no detectado)	Alto	la única herramienta de código abierto que compite — en esta IP residencial
patchright	Bajo	enfrentó el desafío en cada ejecución, no despejó ninguno
camoufox	Bajo	enfrentó el desafío en cada ejecución, no despejó ninguno
nodriver	Bajo	enfrentó el desafío en cada ejecución, no despejó ninguno
HTTP simple (mínimo)	Bajo	403 en cada solicitud

Dos cosas se destacan. Primero, incluso en el terreno que favorece más a una pila autoalojada, el Scrapeless Scraping Browser lidera el campo y despeja con más consistencia. Segundo, "usa un navegador anti-detección" no es una respuesta completa: tres de las cuatro herramientas de navegador de código abierto no despejaron el desafío en ninguna ocasión, y no fallaron rápidamente: mantuvieron el intersticial hasta el límite de tiempo.

La IP de centro de datos es la historia de producción

El Wi-Fi residencial no es donde se ejecutan los raspadores. Las tuberías de producción funcionan en servidores en la nube, y un servidor en la nube sale a través de una IP de centro de datos que Cloudflare trata de manera muy diferente. Ese único cambio es lo que separa el campo.

Medido en CI (IP de centro de datos, GitHub Actions), mismo objetivo, mismas ocho pruebas por herramienta, misma regla de un intento:

Herramienta	Despejó el desafío	p50	p95	KB medio / despeje	$/1k éxito	Estabilidad σ
Scrapeless Scraping Browser	Alto	14,274 ms	26,009 ms	153.9	$0.063	43.3%
seleniumbase-uc	Bajo	58,993 ms	65,390 ms	—	—	—
camoufox	Bajo	56,574 ms	59,348 ms	—	—	—
patchright	Bajo	51,920 ms	52,302 ms	—	—	—
nodriver	Bajo	51,830 ms	52,886 ms	—	—	—
HTTP simple (mínimo)	Bajo	100 ms	254 ms	—	—	—
El residencial 6-de-8 que SeleniumBase (modo no detectado) publicó no tiene nada sobre lo que apoyarse aquí: en la IP del centro de datos, no superó el desafío en ninguna ocasión, y las columnas p50/p95 muestran por qué: cada herramienta de navegador de código abierto gastó aproximadamente 52-65 segundos por prueba luchando con la página intersticial antes de que se agotara el tiempo, y luego no devolvió nada. El límite de HTTP sin cifrado "falla rápido" en un p50 de 100 ms porque nunca ejecuta el desafío en absoluto: toma el 403 y sale. Las columnas de costo y bytes están en blanco para las herramientas del 0% porque no hay una superación exitosa para dividir bytes o dólares; una herramienta "gratuita" sin superaciones tiene un costo por éxito indefinido, no uno barato.

En una IP de centro de datos, las herramientas autohospedadas pierden la única ventaja que tenían: una salida residencial limpia, porque no tienen una salida limpia propia a la que recurrir. El Navegador de Scraping sin Scrapeless no se ve afectado de esta manera: aún supera el desafío porque sus solicitudes salen a través de proxies residenciales sin importar dónde se ejecute el proceso de referencia, aterrizando en 6 de 8 (Alto) con un p50 de 14.3 segundos y un costo medido de $0.063 por mil superaciones exitosas. El resultado es la versión de esta prueba que coincide con la producción: solo la herramienta que trae su propia salida residencial sigue superando el desafío, y lo hace mientras el resto del campo devuelve 0%.

Ese es el caso honesto para un navegador en la nube administrado. No es que las herramientas de código abierto nunca puedan superar Cloudflare; una de ellas puede, en la IP correcta. Es que la fiabilidad en el entorno en el que realmente se despliega es la propiedad que se mantiene, y esa propiedad proviene de la salida y la consistencia, no de un parche sigiloso.

Cómo leer esto para tu propia pila

• Si trabajas en un portátil o ya utilizas un proxy residencial y el volumen es bajo, un navegador no detectado autohospedado puede funcionar: acepta el mantenimiento y la variabilidad de ejecución a ejecución.
• Si despliegas en servidores en la nube, necesitas consistencia o trabajas con alguna concurrencia real, el problema de reputación de la salida es el obstáculo, y un navegador en la nube que envía su propia salida residencial es el camino que se mantiene. Compara los precios con el tiempo de ingeniería que cuesta mantener viva una pila autohospedada.
• De cualquier manera, míralo en tu objetivo. La página del desafío utilizada aquí es un objetivo de práctica pública; tu sitio puede estar detrás de una configuración más estricta. El arnes está diseñado para apuntar a lo que necesites probar.

Para la mecánica de operar el navegador en la nube — creación de sesiones, país del proxy y lectura del DOM renderizado — la documentación del Navegador de Scraping cubre todo el flujo, y el enfoque anti-bot se desglosa más en la guía hermana sobre superar la protección de Cloudflare y Turnstile.

Conclusión: la fiabilidad es una propiedad de salida

Superar Cloudflare en producción se reduce a tres señales: un navegador real, una huella digital consistente y una IP de salida limpia; y la tercera es donde las pilas autohospedadas rompen en silencio. En una IP residencial, el campo parece competitivo; en la IP del centro de datos que utilizan las verdaderas canalizaciones, no lo es. El Navegador de Scraping sin Scrapeless superó el desafío con mayor frecuencia y más consistencia, y es la única herramienta medida cuyo éxito no depende de dónde se ejecute el proceso. Los números no son una afirmación de confianza; son un arnes para operar. Fija la salida residencial de EE. UU., mantiene la sesión activa cargando el sitio una vez antes de la página objetivo, mantiene la concurrencia moderada por anfitrión, y deja que la tasa de éxito medida resuelva el argumento.

---

¿Listo para superar Cloudflare en producción?

Únete a nuestra comunidad para reclamar un plan gratuito y conectarte con desarrolladores que están construyendo canalizaciones resistentes a bots: Discord · Telegram.

Regístrate en app.scrapeless.com para obtener tiempo de ejecución gratuito del Navegador de Scraping y apunta la referencia a las páginas protegidas por Cloudflare que tu canalización necesita.

FAQ

P: ¿Necesito un proxy para superar el desafío?
Sí, la salida limpia es la señal que decide la mayoría de los resultados. El Navegador de Scraping sin Scrapeless utiliza proxies residenciales de EE. UU. por defecto; una herramienta autohospedada necesita su propia salida residencial, y en una IP de centro de datos sin ella, el desafío rara vez se supera.

P: La página muestra "Solo un momento..." o Acceso denegado. ¿Cómo consigo un renderizado limpio?
Pin US residential egress y calienta la sesión primero: carga la página de inicio del sitio en la misma sesión antes de solicitar la página objetivo, de modo que la cookie de eliminación se establezca en una sesión validada. Mantén la concurrencia moderada: tres trabajadores por host es un techo seguro para las ejecuciones paralelas.

P: ¿Por qué las herramientas de código abierto superan el desafío en mi laptop pero fallan en mi servidor?
Tu laptop sale a través de una IP residencial; tu servidor sale a través de una IP de centro de datos con una reputación peor. La misma herramienta, el mismo código: cambió la IP de salida, y esa es la señal que Cloudflare evalúa con mayor peso. Es la razón más importante por la que un stack que funciona en pruebas falla en producción.

P: ¿Pueden las herramientas de código abierto superarlo alguna vez?
Sí: SeleniumBase en modo no detectado superó el desafío en una IP residencial en este benchmark. El punto no es que las herramientas autohospedadas nunca funcionen; es que su éxito depende de una condición de IP que la producción generalmente elimina, además del mantenimiento continuo a medida que las herramientas y el desafío cambian.

P: ¿Cómo reproduzco estos números?
El arnés es un benchmark de Cloudflare de código abierto en GitHub. Clónalo, instala las herramientas, establece una clave de API de Scrapeless y ejecuta la misma matriz: mismos objetivos, mismos ensayos, misma regla de un solo intento. Escribe una tabla de resultados más JSON crudo por ensayo, por lo que cada cifra remonta a la ejecución que la produjo, y los números de IP de centro de datos provienen directamente de su ejecución de GitHub Actions.