undetected-chromedriver, nodriver, Playwright-Stealth, Camoufox: 4 motores, una prueba real

Si estás buscando «undetected-chromedriver vs. nodriver vs. Playwright-Stealth vs. Camoufox», en realidad te estás preguntando cuál de los cuatro enfoques de ingeniería para el stealth de navegadores realmente funciona. Ya evaluamos tres de ellos contra un objetivo real de anti-bot. Esta vez agregamos un cuarto —el más distinto arquitectónicamente del grupo— para ver si el patrón se mantenía.

Ronda 1: bot.sannysoft.com, los cuatro motores

Motor	Enfoque	Pruebas principales	Proveedor/renderizador WebGL
ChromiumFish	Spoofing nativo en C++/Blink	8/8 aprobadas	FALLA
patchright	Chromium parcheado con JS	8/8 aprobadas	FALLA
camoufox	Firefox parcheado	7/8 aprobadas (prueba exclusiva de Chrome N/A)	APRUEBA
zendriver	Directo por CDP, sesión persistente	8/8 aprobadas	FALLA

La misma historia que el primer banco de pruebas, ahora con un cuarto dato que la confirma: ya sea que un motor simule una huella digital de forma nativa, la parchee con JS, o controle un Chrome real directamente por CDP, las comprobaciones principales de stealth vuelven idénticas. WebGL sigue siendo el único agujero con forma de Chromium: tres de cuatro lo fallan, el valor atípico basado en Firefox no.

La única diferencia real a nivel de motor que encontramos esta ronda no estaba en absoluto en la lista de comprobación. ChromiumFish, patchright y camoufox presentan cada uno un user agent de Windows simulado. zendriver no se molesta: reporta exactamente lo que es, X11; Linux x86_64. Eso no es obviamente peor: una cadena de sistema operativo veraz es una cosa menos que debe mantenerse coherente con el resto de la huella digital (renderizador WebGL, lista de fuentes, navigator.platform), y una discrepancia entre un sistema operativo declarado y cualquiera de esos elementos es una señal de anti-bot mucho más común que «esto es Linux». No tenemos datos sobre qué estrategia pesan realmente más los proveedores de anti-bot; vale la pena saber que los motores hacen apuestas diferentes aquí, no solo que usan mecánicas de spoofing distintas.

Ronda 2: el mismo objetivo real, ahora con una 4ª arquitectura

Motor	nowsecure.nl (demo pública de desafío JS)	g2.com (Bot Management real)
ChromiumFish	APRUEBA	403
patchright	APRUEBA	403
camoufox	APRUEBA	403
zendriver	APRUEBA	403

Consenso total, 4 de 4 en ambos sentidos. Todos los motores superaron la demo pública suave. Todos los motores recibieron un 403 duro en el objetivo real de Bot Management: la misma pequeña página de bloqueo de Cloudflare (<title>g2.com</title>, el marcador de inyección de desafío #cmsg), con la misma forma byte por byte que vio nuestro primer banco de pruebas con los otros tres motores.

Esto es lo que vale la pena detenerse a considerar: zendriver no es una variación sobre el mismo tema que los otros tres; es una forma estructuralmente distinta de controlar un navegador, una sesión persistente sobre CDP crudo en lugar de un servicio HTTP con lanzamiento nuevo por cada solicitud. Si la arquitectura del motor le importara a la decisión de un proveedor de anti-bot real, este es exactamente el tipo de diferencia que debería haberse manifestado. No fue así. (No repetimos aquí la ronda de proxy de nuestro primer banco de pruebas; consulta esa entrada para el resultado con el pool de proxies de centro de datos, que se aplica a este objetivo sin importar qué motor lo esté controlando).

Lo que realmente difiere entre estos cuatro motores

Al combinar ambos bancos de pruebas, las diferencias que son reales no son las que suele destacar el contenido típico sobre «navegadores stealth»:

• Camoufox es el único que aprueba WebGL de forma limpia, porque es el único que no ejecuta Chromium en modo headless.
• zendriver dice la verdad sobre su sistema operativo; los otros tres simulan Windows. Apuestas diferentes, sin diferencia medida en la tasa de aprobación en ningún sentido.
• El modelo de sesión de zendriver es arquitectónicamente distinto: un navegador de larga duración frente a uno nuevo por cada solicitud, lo cual importa para la latencia y el uso de recursos a escala, no para si una solicitud dada logra pasar.
• Cada otro eje que pudimos medir —los que suelen destacar los discursos de marketing de «nativo vs. parcheado con JS vs. directo por CDP»— resultó en un empate. Superar un objetivo real de Cloudflare Bot Management dependió de la reputación de IP en el primer banco de pruebas, y un cuarto motor, arquitectónicamente distinto, se topó exactamente con la misma pared.

La conclusión

Si estás eligiendo entre los sucesores de undetected-chromedriver, un parcheo al estilo playwright-stealth y un enfoque de Firefox parcheado, la respuesta honesta tras dos bancos de pruebas es: elige según la carga de mantenimiento y el ajuste al ecosistema, no según el stealth. Ninguno de los cuatro enfoques que probamos —spoofing nativo, parcheo con JS, parcheo de Firefox o control directo por CDP de un navegador real— movió la aguja contra un objetivo que en realidad está verificando la reputación de IP. La palanca que sí funciona es la que ni esta entrada ni la anterior encontraron dentro del navegador.

Cómo hicimos esto (y las salvedades)

zendriver requirió un método de prueba distinto al de los otros tres. ChromiumFish, patchright y camoufox exponen cada uno un contrato HTTP simple POST /fetch; zendriver expone un WebSocket CDP crudo detrás de un proxy que reescribe el encabezado del host, así que lo controlamos con connect_over_cdp de Playwright desde dentro de otro pod en el mismo clúster, obteniendo un contexto de navegador nuevo por cada prueba (para igualar el aislamiento que los otros tres tienen por defecto, ya que el propio proceso del navegador de zendriver es compartido/persistente).

nodriver en sí no fue probado: actualmente está escalado a 0 réplicas en nuestra flota. zendriver se presenta aquí como su equivalente en vivo más cercano (un fork mantenido activamente del mismo código base), no como nodriver mismo.

Se aplican las mismas salvedades de muestra pequeña que en el primer banco de pruebas: un detector gratuito, dos objetivos en vivo (uno suave, uno duro), solicitudes secuenciales individuales. Esto es un banco de pruebas, no una prueba de carga, y mide cuatro motores específicos, no cada implementación de «spoofing nativo» o «control directo por CDP» que existe.

Evita elegir entre cuatro motores por tu cuenta

La flota de Crawlora ejecuta todos estos enfoques detrás de una sola API y redirige automáticamente hacia el que funcione cuando un objetivo esté bloqueando otro. 2000 créditos gratis al mes, sin necesidad de tarjeta.

Ver la API de Web ScrapingVer precios