Probamos 15 motores de navegador stealth contra Cloudflare. El navegador no era el problema.

Todos los motores de navegador stealth que probamos —incluido uno que falsifica su huella digital de forma nativa en la capa C++/Blink, no mediante un parche JS— fueron bloqueados exactamente a la misma tasa en cuanto entró en escena un proveedor real de anti-bot. No "rindió un poco peor". Bloqueado de forma idéntica, sin importar cuán limpia fuera su huella digital. Operamos 15 de estos motores en producción y decidimos averiguar, con números reales, si elegir el "mejor" importa tanto como sugiere el marketing que los rodea.

Por qué "pasar un detector gratuito" no es la prueba real

Los verificadores de huella digital gratuitos como bot.sannysoft.com buscan las señales obvias: si navigator.webdriver está definido, si window.chrome existe, si la lista de plugins está vacía. Cualquier motor stealth que valga la pena ya supera esto a estas alturas — son el mínimo indispensable, no un diferenciador. Lo que no verifican es lo que realmente decide si un proveedor real de anti-bot deja pasar una solicitud: de dónde viene. Así que hicimos correr a los mismos tres motores a través de ambas pruebas — la fácil y la que realmente importa.

Ronda 1: falsificación nativa frente a parcheo JS, en un detector gratuito

Motor	Pruebas básicas (webdriver, chrome, plugins, etc.)	Proveedor/renderizador WebGL
ChromiumFish (fork nativo)	8/8 aprobadas	FALLA — sin contexto WebGL
patchright (Chromium parcheado con JS)	8/8 aprobadas	FALLA — sin contexto WebGL
camoufox (Firefox parcheado)	7/8 aprobadas — solo falla la verificación específica de Chrome window.chrome, que un navegador basado en Firefox nunca tendrá	APRUEBA

Prácticamente un empate en las pruebas que miden el sigilo. La única división real: ambos motores basados en Chromium fallan la verificación de proveedor/renderizador WebGL — Chrome headless sin GPU no tiene un contexto WebGL real que reportar, falsificación nativa o no— mientras que el motor Firefox de camoufox la aprueba sin problemas. Esa es una diferencia genuina y medible a nivel de motor. Simplemente no es la que la "falsificación nativa de huella digital" prometía darnos.

Ronda 2: los mismos tres motores contra un objetivo real de Cloudflare, sin proxy

Aquí es donde se pone interesante, y donde un solo objetivo de prueba nos habría llevado a conclusiones erróneas. Enfrentamos a los tres contra dos sitios diferentes protegidos por Cloudflare, directamente desde la IP de centro de datos del clúster, sin proxy.

Motor	nowsecure.nl (demo pública de desafío JS)	g2.com (Bot Management real — devuelve 403 a un curl plano)
ChromiumFish	APRUEBA	403
patchright	APRUEBA	403
camoufox	APRUEBA	403

Todos los motores superaron la demo pública sin problemas — contenido de éxito real renderizado, sin página de desafío. Todos los motores recibieron un 403 duro en el objetivo real de Bot Management, exactamente a la misma tasa, sin importar cuál tuviera la huella digital más limpia en la Ronda 1.

«Vencer a Cloudflare» no es una sola afirmación. Una demo ligera de desafío JS y un despliegue real de Bot Management son niveles de dificultad completamente distintos, y una entrada de blog que solo prueba el fácil y lo llama "vencer a Cloudflare" está midiendo lo que no corresponde. En el objetivo que realmente importa, la calidad de la huella digital no nos dio nada.

Ronda 3: ¿un pool de proxies lo soluciona?

Enrutamos ChromiumFish a través de nuestro propio pool de proxies rotativos y lo hicimos correr contra g2.com seis veces más. (Solo ChromiumFish toma un proxy por solicitud en nuestra configuración; los otros dos solo lo leen desde una variable de entorno fija que no está establecida en los servicios en vivo — así que esta ronda es exclusiva de ChromiumFish, con el mismo alcance que el resto de este banco de pruebas.)

Resultado	Intentos
403 duro (página de bloqueo pequeña)	4 / 6
Contenido real de la página de inicio de G2 servido — bajo un estado 403	1 / 6
El propio salto de proxy falló (conexión caída)	1 / 6

Vale la pena detenerse en esa fila del medio: un intento devolvió la página de inicio real de G2 — título correcto, contenido real, sin marcadores de desafío— mientras el código de estado HTTP seguía marcando 403. Los resultados de scraping en el mundo real no siempre son un aprobado/reprobado limpio; a veces el sitio entrega el contenido y la señal de bloqueo al mismo tiempo. No lo contamos como una victoria confiable. Dos IP de salida que muestreamos del mismo pool resultaron ser un ASN de hosting en Países Bajos y una dirección de Scaleway (Francia) marcada como hosting: true — seguía siendo infraestructura de centro de datos y nube, no residencial. Es el mismo carácter de pool de proxies que encontró un banco de pruebas comparable en junio, solo con proveedores distintos.

Lo que realmente predice el paso o el bloqueo a escala

Apilando las tres rondas, surge un patrón que no tiene nada que ver con qué navegador stealth se eligió:

1. La falsificación de huella digital es necesaria y prácticamente intercambiable. Los motores nativos y los parcheados con JS empataron en cada prueba específica de sigilo que realizamos. Comprar un motor de falsificación "mejor" nos compró una casilla de WebGL, no una tasa de aprobación más alta contra un objetivo real.
2. La reputación de la IP es la verdadera puerta. Los mismos tres motores pasaron de 3/3 aprobados a 3/3 bloqueados simplemente cambiando de despliegue de Cloudflare al que se enfrentaban — sin cambiar código, sin cambiar de motor.
3. Un pool de proxies de centro de datos no soluciona el punto 2. Enrutar a través de IP de nube rotativas siguió fallando entre 4 y 5 de cada 6 veces contra un objetivo real de Bot Management, porque las salidas seguían alojadas en la nube, no eran residenciales.

Si estás optimizando una configuración de scraping, la palanca que mueve la aguja no es "qué navegador stealth". Es qué está proporcionando la IP. (Pusimos a prueba esa afirmación con un cuarto motor, arquitectónicamente distinto — ver 4 motores de navegador stealth, una prueba real.)

El costo honesto de operar 15 motores por cuenta propia

Mantenemos 15 de estos porque la cobertura importa y ningún motor gana en todos los frentes — pero cada uno es su propia carga de mantenimiento. Un fork nativo como ChromiumFish o alternativas de la clase Cagebase implica compilar y recompilar un fork de Chromium contra cada parche de seguridad (horas por compilación, decenas de gigabytes de disco), no solo un pip install. Un motor parcheado con JS como patchright necesita volver a parchearse cada vez que un proveedor de anti-bot actualiza su script de detección, lo cual es frecuente. Nada de ese mantenimiento compra una tasa de aprobación significativamente más alta contra un objetivo que realmente verifica la reputación de la IP — que, según las rondas 2 y 3, es la mayoría de ellos.

La conclusión

La falsificación de huella digital, hecha de forma nativa o mediante un parche JS, es el mínimo indispensable — necesaria para superar las verificaciones fáciles, no suficiente para superar un despliegue real de anti-bot. A lo largo de dos bancos de pruebas separados por siete semanas, los mismos tres motores han empatado en cada prueba específica de sigilo que les hemos aplicado, y se han diferenciado únicamente en si la solicitud provenía de una IP limpia. Si el discurso de venta de un proveedor sobre "el mejor navegador stealth" no menciona de dónde viene la solicitud, está respondiendo la pregunta equivocada.

Cómo hicimos esto (y las salvedades)

Infraestructura: los tres motores se ejecutan como microservicios siempre activos en nuestra flota de producción de Kubernetes, cada uno detrás del mismo contrato POST /fetch utilizado en los 15 motores. Las solicitudes fueron individuales y secuenciales — esto es un benchmark, no una prueba de carga.

Este es un seguimiento de un banco de pruebas interno realizado el 2026-06-22, vuelto a ejecutar de cero para esta entrada en lugar de reutilizar los números antiguos. Dos cosas cambiaron en las siete semanas entre bancos de pruebas que vale la pena señalar: la ruta de prueba específica de areyouheadless ahora devuelve 502 (el dominio en sí está activo; esa ruta en particular está muerta, así que la descartamos), y el panel de puntuación de confianza de CreepJS no se puede recuperar de una instantánea HTML estática incluso después de esperar 20 segundos a que se estabilice — sus resultados se renderizan de una forma que nuestro enfoque de fetch-y-serializar no puede capturar, así que lo descartamos en lugar de reportar un número que no podemos respaldar. La capa de proxy de ambos motores también había sido renombrada/reestructurada en el intervalo; el pool contra el que probamos es el equivalente actual en vivo.

La muestra del pool de proxies es pequeña (2 salidas verificadas directamente, 6 intentos contra un objetivo difícil) — suficiente para ver el patrón de centro de datos/nube con claridad, no suficiente para caracterizar con precisión el comportamiento de todo el pool.

Solo 3 de los 15 motores de la flota se probaron a fondo aquí. Se eligieron porque representan los dos enfoques de falsificación que vale la pena comparar — motor nativo y parcheado con JS— más una línea base que no es de Chromium. Los otros 12 existen por cobertura y no formaron parte de esta comparación.

«Objetivo real de Bot Management» es un solo sitio (g2.com) confirmado que devuelve 403 a un curl plano — un indicador razonable de "un sitio que realmente verifica más allá del desafío JS", no una afirmación sobre la línea de productos de Cloudflare en su conjunto.

Evita tener que parchear 15 motores por tu cuenta

Crawlora opera y mantiene la flota de navegadores stealth, la rotación de proxies y el manejo de anti-bot detrás de una sola API. 2000 créditos gratis al mes, sin tarjeta requerida.

Ver la Web Scraping APIVer precios