undetected-chromedriver, nodriver, Playwright-Stealth, Camoufox: 4 Engines im echten Test

Wenn du „undetected-chromedriver vs. nodriver vs. Playwright-Stealth vs. Camoufox” suchst, fragst du eigentlich, welcher von vier unterschiedlichen Engineering-Ansätzen für Browser-Stealth tatsächlich funktioniert. Wir haben bereits drei davon gegen ein reales Anti-Bot-Ziel gebenchmarkt. Diesmal haben wir eine vierte hinzugefügt — architektonisch die unterschiedlichste im Bunde —, um zu sehen, ob sich das Muster hält.

Runde 1: bot.sannysoft.com, alle vier Engines

Engine	Ansatz	Kern-Tests	WebGL Vendor/Renderer
ChromiumFish	Natives C++/Blink-Spoofing	8/8 bestanden	FAIL
patchright	JS-gepatchtes Chromium	8/8 bestanden	FAIL
camoufox	Gepatchtes Firefox	7/8 bestanden (Chrome-only-Test N/A)	PASS
zendriver	CDP-direkt, persistente Session	8/8 bestanden	FAIL

Dieselbe Geschichte wie beim ersten Benchmark, jetzt mit einem vierten Datenpunkt, der sie bestätigt: Ob eine Engine einen Fingerprint nativ spooft, ihn per JS patcht oder ein echtes Chrome direkt über CDP steuert — die Kern-Stealth-Checks kommen identisch zurück. WebGL bleibt die eine Chromium-förmige Lücke — drei von vier scheitern daran, der Firefox-basierte Ausreißer nicht.

Der einzige echte Unterschied auf Engine-Ebene, den wir in dieser Runde gefunden haben, stand gar nicht auf der Checkliste. ChromiumFish, patchright und camoufox präsentieren jeweils einen gespooften Windows-User-Agent. zendriver macht sich diese Mühe nicht — es meldet genau das, was es ist, X11; Linux x86_64. Das ist nicht offensichtlich schlechter: Ein wahrheitsgemäßer OS-String ist eine Sache weniger, die mit dem Rest des Fingerprints (WebGL-Renderer, Font-Liste, navigator.platform) kohärent bleiben muss, und eine Diskrepanz zwischen dem behaupteten OS und einem dieser Werte ist ein deutlich häufigerer Anti-Bot-Hinweis als „das ist Linux”. Wir haben keine Daten dazu, welche Strategie Anti-Bot-Anbieter tatsächlich stärker gewichten — wichtig ist zu wissen, dass die Engines hier unterschiedliche Wetten eingehen, nicht nur, dass sie unterschiedliche Spoofing-Mechaniken nutzen.

Runde 2: dasselbe reale Ziel, jetzt mit einer 4. Architektur

Engine	nowsecure.nl (öffentliche JS-Challenge-Demo)	g2.com (reales Bot Management)
ChromiumFish	PASS	403
patchright	PASS	403
camoufox	PASS	403
zendriver	PASS	403

Volle Übereinstimmung, 4 von 4 in beide Richtungen. Jede Engine bestand die weiche öffentliche Demo. Jede Engine scheiterte hart mit 403 am realen Bot-Management-Ziel — dieselbe kleine Cloudflare-Blockseite (<title>g2.com</title>, der #cmsg-Challenge-Injection-Marker), byte-für-byte in derselben Form, die unser erster Benchmark schon bei den anderen drei Engines gesehen hat.

Das ist der Teil, bei dem es sich zu verweilen lohnt: zendriver ist keine Variation desselben Themas wie die anderen drei — es ist eine strukturell andere Art, einen Browser zu steuern, eine persistente Session über rohes CDP statt ein frischer Spawn pro Request als HTTP-Service. Wenn die Engine-Architektur für die Entscheidung eines echten Anti-Bot-Anbieters eine Rolle spielen würde, wäre genau das die Art von Unterschied, die sich hätte zeigen müssen. Sie zeigte sich nicht. (Wir haben die Proxy-Runde aus unserem ersten Benchmark hier nicht wiederholt — siehe diesen Beitrag für das Ergebnis mit dem Datacenter-Proxy-Pool, das für dieses Ziel gilt, unabhängig davon, welche Engine es steuert.)

Was zwischen diesen vier Engines wirklich unterschiedlich ist

Stapelt man beide Benchmarks übereinander, sind die Unterschiede, die real sind, nicht diejenigen, mit denen „Stealth-Browser”-Content üblicherweise vorprescht:

• Camoufox ist die einzige, die WebGL sauber besteht, weil sie als einzige nicht headless auf Chromium läuft.
• zendriver sagt die Wahrheit über sein OS; die anderen drei spoofen Windows. Unterschiedliche Wetten, kein gemessener Unterschied bei der Passrate in beide Richtungen.
• zendrivers Session-Modell ist architektonisch verschieden — ein langlebiger Browser statt frisch pro Request —, was für Latenz und Ressourcenverbrauch in großem Maßstab zählt, nicht dafür, ob ein einzelner Request durchkommt.
• Jede andere Achse, die wir messen konnten — genau die, um die „nativ vs. JS-gepatcht vs. CDP-direkt”-Marketing-Pitches sich normalerweise drehen — endete unentschieden. Ob ein echtes Cloudflare-Bot-Management-Ziel durchgelassen wurde, hing im ersten Benchmark an der IP-Reputation, und eine 4., architektonisch andere Engine landete genau an derselben Wand.

Das Fazit

Wenn du zwischen den Nachfolgern von undetected-chromedriver, JS-Patching im playwright-stealth-Stil und einem gepatchten-Firefox-Ansatz wählst, lautet die ehrliche Antwort aus jetzt zwei Benchmarks: Wähle nach Maintenance-Aufwand und Ökosystem-Fit, nicht nach Stealth. Keiner der vier getesteten Ansätze — natives Spoofing, JS-Patching, Firefox-Patching oder CDP-direkte Steuerung eines echten Browsers — hat gegen ein Ziel, das tatsächlich die IP-Reputation prüft, etwas bewegt. Der Hebel, der etwas bewegt, ist derjenige, den weder dieser Beitrag noch der letzte im Browser selbst gefunden hat.

Wie wir das gemacht haben (und die Vorbehalte)

zendriver erforderte eine andere Benchmark-Methode als die anderen drei. ChromiumFish, patchright und camoufox exponieren jeweils einen einfachen POST /fetch-HTTP-Contract; zendriver exponiert einen rohen CDP-WebSocket hinter einem Host-Header-umschreibenden Proxy, also haben wir es mit Playwrights connect_over_cdp aus einem anderen Pod im selben Cluster gesteuert und pro Test einen frischen Browser-Kontext geholt (passend zur Isolation, die die anderen drei standardmäßig bekommen, da zendrivers Browser-Prozess selbst geteilt/persistent ist).

nodriver selbst wurde nicht getestet — es ist in unserer Flotte aktuell auf 0 Replicas skaliert. zendriver wird hier als das nächstgelegene live laufende Äquivalent präsentiert (ein aktiv gepflegter Fork derselben Codebasis), nicht als nodriver selbst.

Dieselben Small-Sample-Vorbehalte wie beim ersten Benchmark gelten auch hier: ein kostenloser Detektor, zwei Live-Ziele (eines weich, eines hart), einzelne sequenzielle Requests. Das ist ein Benchmark, kein Lasttest, und er misst vier spezifische Engines, nicht jede Implementierung von „nativem Spoofing” oder „CDP-direkter Steuerung”, die es gibt.

Erspar dir die Wahl zwischen vier Engines selbst

Crawloras Flotte betreibt all diese Ansätze hinter einer API und routet automatisch um jede Engine herum, die ein Ziel gerade blockiert. 2.000 kostenlose Credits pro Monat, keine Kreditkarte erforderlich.

Web Scraping API ansehenPreise ansehen