Wir haben 15 Stealth-Browser-Engines gegen Cloudflare getestet. Der Browser war nicht das Problem.

Jede von uns getestete Stealth-Browser-Engine — einschließlich einer, die ihren Fingerprint nativ auf der C++/Blink-Ebene spooft, nicht per JS-Patch — wurde mit exakt derselben Rate geblockt, sobald ein echter Anti-Bot-Anbieter ins Spiel kam. Nicht «etwas schlechter performt». Identisch geblockt, egal wie sauber ihr Fingerprint war. Wir betreiben 15 dieser Engines produktiv und haben beschlossen, mit echten Zahlen herauszufinden, ob die Wahl der «besten» Engine so viel ausmacht, wie das Marketing rund um sie glauben macht.

Warum «besteht einen kostenlosen Detektor» nicht der eigentliche Test ist

Kostenlose Fingerprint-Checker wie bot.sannysoft.com suchen nach den offensichtlichen Verräter-Merkmalen: Ist navigator.webdriver gesetzt, existiert window.chrome, ist die Plugin-Liste leer. Jede brauchbare Stealth-Engine besteht das mittlerweile — das ist Grundvoraussetzung, kein Unterscheidungsmerkmal. Was sie nicht prüfen, ist die Sache, die tatsächlich darüber entscheidet, ob ein echter Anti-Bot-Anbieter eine Anfrage durchlässt: woher sie kommt. Also haben wir dieselben drei Engines durch beide Tests laufen lassen — den leichten und den, der wirklich zählt.

Runde 1: natives Spoofing vs. JS-Patching, an einem kostenlosen Detektor

Engine	Kern-Tests (webdriver, chrome, plugins usw.)	WebGL Vendor/Renderer
ChromiumFish (nativer Fork)	8/8 bestanden	FEHLGESCHLAGEN — kein WebGL-Kontext
patchright (JS-gepatchtes Chromium)	8/8 bestanden	FEHLGESCHLAGEN — kein WebGL-Kontext
camoufox (gepatchtes Firefox)	7/8 bestanden — scheitert nur am Chrome-spezifischen window.chrome-Check, den ein Firefox-basierter Browser nie haben wird	BESTANDEN

Nahezu Gleichstand bei den Tests, die Stealth messen. Die eine echte Trennlinie: Beide Chromium-basierten Engines scheitern am WebGL-Vendor/Renderer-Check — Headless-Chrome ohne GPU hat keinen echten WebGL-Kontext zu melden, natives Spoofing hin oder her — während camoufox' Firefox-Engine ihn sauber besteht. Das ist ein echter, messbarer Unterschied auf Engine-Ebene. Nur eben nicht der, den «natives Fingerprint-Spoofing» eigentlich bringen sollte.

Runde 2: dieselben drei Engines gegen ein echtes Cloudflare-Ziel, ohne Proxy

Hier wird es interessant — und hier hätte uns ein einziges Testziel in die Irre geführt. Wir haben alle drei gegen zwei verschiedene, mit Cloudflare geschützte Seiten laufen lassen, direkt von der Rechenzentrums-IP des Clusters, ohne Proxy.

Engine	nowsecure.nl (öffentliche JS-Challenge-Demo)	g2.com (echtes Bot Management — 403 bei einem einfachen curl)
ChromiumFish	BESTANDEN	403
patchright	BESTANDEN	403
camoufox	BESTANDEN	403

Jede Engine bestand die öffentliche Demo sauber — echter Erfolgsinhalt wurde gerendert, keine Challenge-Seite. Jede Engine bekam auf dem echten Bot-Management-Ziel einen harten 403, mit exakt derselben Rate, unabhängig davon, wer in Runde 1 den saubereren Fingerprint hatte.

«Schlägt Cloudflare» ist keine einzelne Behauptung. Eine leichtgewichtige JS-Challenge-Demo und ein echtes Bot-Management-Deployment sind völlig unterschiedliche Schwierigkeitsgrade, und ein Blogbeitrag, der nur die leichte testet und das dann «Cloudflare schlagen» nennt, misst die falsche Sache. Am Ziel, das wirklich zählt, hat uns Fingerprint-Qualität nichts gebracht.

Runde 3: löst ein Proxy-Pool das Problem?

Wir haben ChromiumFish über unseren eigenen rotierenden Proxy-Pool geleitet und sechs weitere Male gegen g2.com laufen lassen. (In unserem Setup nimmt nur ChromiumFish einen Proxy pro Anfrage entgegen; die anderen beiden lesen ihn nur aus einer fest eingestellten Umgebungsvariable, die auf den Live-Services nicht gesetzt ist — diese Runde ist also nur ChromiumFish, im selben Umfang wie der Rest dieses Tests.)

Ergebnis	Versuche
Harter 403 (kleine Block-Seite)	4 / 6
Echter G2-Homepage-Inhalt ausgeliefert — unter einem 403-Status	1 / 6
Proxy-Hop selbst fehlgeschlagen (Verbindung abgebrochen)	1 / 6

Diese mittlere Zeile lohnt einen genaueren Blick: Ein Versuch lieferte die echte G2-Homepage zurück — korrekter Titel, echter Inhalt, keine Challenge-Marker — während der HTTP-Statuscode trotzdem 403 sagte. Ergebnisse eines echten Scrapes sind nicht immer ein sauberes Bestanden/Durchgefallen; manchmal liefert die Seite den Inhalt und das Blocksignal gleichzeitig aus. Wir zählen das nicht als verlässlichen Erfolg. Zwei Exit-IPs, die wir aus demselben Pool stichprobenartig geprüft haben, kamen als ein niederländisches Hosting-ASN und eine Scaleway-Adresse (Frankreich) mit dem Flag hosting: true zurück — nach wie vor Rechenzentrums- und Cloud-Infrastruktur, nicht Residential. Das ist derselbe Charakter Proxy-Pool, den ein vergleichbarer Test im Juni gefunden hat — nur mit anderen Anbietern.

Was tatsächlich vorhersagt, ob es klappt oder nicht — im großen Maßstab

Stapelt man die drei Runden übereinander, fällt ein Muster heraus, das nichts mit der gewählten Stealth-Browser-Engine zu tun hat:

1. Fingerprint-Spoofing ist notwendig und weitgehend austauschbar. Native und JS-gepatchte Engines lagen bei jedem stealth-spezifischen Test gleichauf. Eine «bessere» Spoofing-Engine zu kaufen brachte uns einen WebGL-Haken, keine höhere Erfolgsquote gegen ein echtes Ziel.
2. IP-Ruf ist das eigentliche Tor. Dieselben drei Engines gingen von 3/3 bestanden zu 3/3 geblockt — allein dadurch, dass wir das Cloudflare-Deployment wechselten, gegen das sie liefen. Kein Code geändert, keine Engine geändert.
3. Ein Rechenzentrums-Proxy-Pool löst #2 nicht. Das Routing über rotierende Cloud-IPs scheiterte immer noch 4-5 von 6 Mal gegen ein echtes Bot-Management-Ziel, weil die Exits weiterhin Cloud-gehostet waren, nicht Residential.

Wenn du ein Scraping-Setup optimierst, ist der Hebel, der etwas bewegt, nicht «welcher Stealth-Browser». Es ist, wer die IP liefert. (Wir haben diese Behauptung mit einer vierten, architektonisch andersartigen Engine weiter getestet — siehe 4 Stealth-Browser-Engines, ein echter Test.)

Die ehrlichen Kosten, 15 Engines selbst zu betreiben

Wir pflegen 15 davon, weil Abdeckung wichtig ist und keine einzelne Engine überall gewinnt — aber jede ist ihr eigener Wartungsaufwand. Ein nativer Fork wie ChromiumFish oder Cagebase-artige Alternativen bedeutet, einen Chromium-Fork bei jedem Sicherheitspatch zu kompilieren und neu zu kompilieren (Stunden pro Build, Dutzende Gigabyte Festplattenspeicher) — nicht einfach pip install. Eine JS-gepatchte Engine wie patchright muss jedes Mal neu gepatcht werden, wenn ein Anti-Bot-Anbieter sein Erkennungsskript aktualisiert, was oft vorkommt. Nichts von diesem Wartungsaufwand kauft eine spürbar höhere Erfolgsquote gegen ein Ziel, das tatsächlich den IP-Ruf prüft — was, laut Runde 2 und 3, die meisten Ziele tun.

Das Fazit

Fingerprint-Spoofing, ob nativ oder per JS-Patch, ist Grundvoraussetzung — notwendig, um die leichten Checks zu bestehen, nicht ausreichend, um ein echtes Anti-Bot-Deployment zu bestehen. Über zwei Testreihen im Abstand von sieben Wochen lagen dieselben drei Engines bei jedem stealth-spezifischen Test gleichauf, und trennten sich nur danach, ob die Anfrage von einer sauberen IP kam. Wenn das Pitch eines Anbieters für «den besten Stealth-Browser» nicht erwähnt, woher die Anfrage kommt, beantwortet er die falsche Frage.

Wie wir das gemacht haben (und die Einschränkungen)

Infra: alle drei Engines laufen als dauerhaft aktive Microservices in unserer produktiven Kubernetes-Fleet, jede hinter demselben POST /fetch-Contract, der über alle 15 Engines hinweg genutzt wird. Anfragen waren einzeln und sequenziell — das ist ein Benchmark, kein Lasttest.

Das ist eine Folgemessung zu einem internen Test vom 2026-06-22, für diesen Beitrag frisch neu durchgeführt, statt die alten Zahlen wiederzuverwenden. Zwei Dinge haben sich in den sieben Wochen zwischen den Testreihen geändert, die erwähnenswert sind: Die spezifische Testroute von areyouheadless liefert jetzt 502 (die Domain selbst ist erreichbar; dieser eine Pfad ist tot, deshalb haben wir ihn weggelassen), und das Trust-Score-Panel von CreepJS lässt sich aus einem statischen HTML-Snapshot nicht wiederherstellen, selbst nach 20 Sekunden Wartezeit — seine Ergebnisse werden auf eine Weise gerendert, die unser Fetch-dann-Serialisieren-Ansatz nicht erfassen kann, deshalb haben wir ihn weggelassen, statt eine Zahl zu berichten, hinter der wir nicht stehen können. Auch die Proxy-Schicht beider Engines wurde in der Zwischenzeit umbenannt/umstrukturiert; der Pool, gegen den wir getestet haben, ist das aktuelle Live-Äquivalent.

Die Proxy-Pool-Stichprobe ist klein (2 direkt geprüfte Exits, 6 Versuche gegen ein hartes Ziel) — genug, um das Rechenzentrums-/Cloud-Muster klar zu erkennen, nicht genug, um das Verhalten des gesamten Pools präzise zu charakterisieren.

Nur 3 der 15 Fleet-Engines wurden hier tiefgehend getestet. Sie wurden gewählt, weil sie die beiden vergleichenswerten Spoofing-Ansätze repräsentieren — native Engine und JS-gepatcht — plus eine Nicht-Chromium-Basislinie. Die anderen 12 existieren für Abdeckung und waren nicht Teil dieses Vergleichs.

«Echtes Bot-Management-Ziel» ist eine Seite (g2.com), von der bestätigt ist, dass sie einem einfachen curl mit 403 antwortet — ein vernünftiger Stellvertreter für «eine Seite, die tatsächlich über die JS-Challenge hinaus prüft», keine Aussage über Cloudflares Produktlinie insgesamt.

Erspar dir das Patchen von 15 Engines

Crawlora betreibt und pflegt die Stealth-Browser-Fleet, Proxy-Rotation und Anti-Bot-Behandlung hinter einer API. 2.000 kostenlose Credits pro Monat, keine Karte nötig.

Web Scraping API ansehenPreise ansehen