Stealth-Browser-Benchmark: Patchright, nodriver, Camoufox (2026)

Am 3. Oktober 2026 haben wir einen kleinen Stealth-Browser-Benchmark durchgeführt: reines Playwright als Kontrollgruppe, dazu Patchright, nodriver, Camoufox und Zendriver, alle gegen öffentliche Testseiten zur Bot-Erkennung, einmal von einer Hetzner-Datacenter-IP und einmal über einen US-Residential-Proxy. Jedes Automatisierungsurteil hing am Browser. Reines Playwright wurde von deviceandbrowserinfo, BrowserScan, dem Fingerprint-Playground und Pixelscan in jedem Durchlauf von beiden IPs aus markiert. Im Headful-Modus bestanden die vier Stealth-Tools die ersten drei Seiten in jedem Durchlauf, der ein Urteil lieferte, und Pixelscan markierte 2 ihrer 39 Headful-Durchläufe (2 weitere waren n/a). Die Residential-IP veränderte nur die Prüfungen, die auf das Netzwerk schauen, und das nicht immer in die richtige Richtung.

Das sind 54 protokollierte Durchläufe von einem Host und aus einem Proxy-Land, auf Seiten, die zum Testen gebaut sind, kein Ranking irgendeines produktiven Anti-Bot-Systems. Im Folgenden: die Methode, die Rohurteile, was die Daten nicht hergeben, und der Code zum Nachvollziehen.

Stealth-Browser-Benchmark: die Kurzfassung

Wenn der Browser Automatisierung verrät, rettet ihn auch eine Residential-IP nicht. Ist der Browser sauber, beeinflusst die IP vor allem netzwerkseitige Prüfungen: Proxy-Erkennung, Zeitzonen-Konsistenz und WebRTC. Auf diesen Seiten wirkte das in beide Richtungen:

• Die Automatisierungsurteile änderten sich mit der IP nicht. Playwright bekam isBot: true auf deviceandbrowserinfo, „WebDriver: Robot“ auf BrowserScan und „bad bot (type: webdriver)“ auf dem Fingerprint-Playground, und zwar in allen 10 Headful-Durchläufen aus beiden Netzen. Patchright, nodriver, Zendriver und Camoufox erhielten in keinem Headful-Durchlauf eine dieser Markierungen.
• Pixelscan störte sich an der Datacenter-IP. Es zeigte „Proxy detected“ in 20 von 20 Durchläufen von der Hetzner-IP, obwohl diese Durchläufe gar keinen Proxy nutzten. Über den Residential-Proxy zeigte es das in 3 von 34 Durchläufen.
• Der Fingerprint-Playground störte sich an der Residential-IP. Sein Proxy-Signal markierte 33 von 34 Residential-Durchläufen und nannte oft ein Proxy-Netzwerk („residential proxy from SOAX“, „from INFATICA“ usw.). Die Hetzner-IP markierte es bei den Chrome-basierten Tools nicht. Für die drei Chrome-basierten Stealth-Tools lagen die Suspect Scores vom Datacenter bei 0–6 und über den Sticky-Residential-Proxy bei 8–24.
• Drei der fünf Tools legten über WebRTC die echte IP des Servers hinter dem Proxy offen. Playwright, Patchright und nodriver taten das in jedem Proxy-Durchlauf. Zendriver blockiert WebRTC standardmäßig, Camoufox fälscht es.
• Der Headless-Modus wog schwerer als die IP. Im Headless-Modus wurden Patchright und nodriver auf denselben Seiten markiert, die sie headful bestanden.

Was wir getestet haben: Versionen, Netzwerkbedingungen, Ziele

Alles lief in einem Debian-12-Container mit Xvfb, ein Browser nach dem anderen, auf einem Linux-Host mit 4 Kernen. Jedes Tool nutzte die Startkonfiguration, die seine eigene Dokumentation empfiehlt, und nichts darüber hinaus: kein eigener User-Agent, keine Fingerprint-Injection, keine Mausbewegung, kein Blockieren von Ressourcen. Für Patchright ist das die „Best Practice“-Konfiguration aus dem README: ein persistenter Context, echtes Chrome, headful, no_viewport=True.

Zwei Kompromisse, gleich vorweg. Die Kontrolle ist Playwright 1.62.0, nicht das aktuelle 1.63.0, weil camoufox 0.5.6 playwright<1.63 verlangt und alle Tools sich eine Umgebung teilten. Und Camoufox lief mit os="linux" und nur seinen Linux-Schriften, weil die Festplatte des Hosts fast voll war und wir die Schriftpakete für macOS und Windows nicht entpackt haben. Standardmäßig würde Camoufox ein zufälliges Betriebssystem wählen.

Netzwerkbedingungen:

• Datacenter: die eigene IP des Hosts, AS24940 Hetzner Online GmbH, Helsinki (laut ipinfo.io).
• Residential, sticky: ein US-Residential-Exit mit frischer Sticky Session pro Durchlauf. In jedem Proxy-Durchlauf verbanden sich alle Tools über dasselbe kleine lokale Relay. Es ergänzt die Proxy-Authentifizierung und zählt Bytes, weil nodriver und Zendriver Proxy-Zugangsdaten nicht in einem Chrome-Flag übergeben können.
• Drei Nebenbedingungen: ein rotierender Residential-Durchgang mit neuer Exit-IP bei jeder Verbindung, ein Warm-up-Durchgang (siehe unten) und je ein Headless-Durchlauf pro Tool von der Datacenter-IP.

Ziele, in dieser Reihenfolge in einem frischen Browser pro Durchlauf besucht, jedes in einem neuen Tab: bot.sannysoft.com, BrowserScan-Bot-Erkennung, deviceandbrowserinfo „Are you a bot?“, CreepJS, Fingerprint-Playground, nowsecure.nl (hinter Cloudflare; reines curl bekommt ein 403 mit cf-mitigated: challenge) sowie Pixelscans Bot-Check und Fingerprint-Check. Die Produktseite zur Bot-Erkennung von Fingerprint haben wir weggelassen, weil sie nur ein statisches JSON-Beispiel zeigt, kein Live-Urteil.

Messgrößen: ob die Seite geladen wurde, das Urteil genau so, wie die Seite es ausgab, und die Zeit bis zum Erscheinen dieses Urteils (Abfrage alle 0,5 s, Timeout 45 s). Für jeden Besuch haben wir den Seitentext und einen ganzseitigen Screenshot gespeichert. Ein Urteil, das sich nicht parsen ließ, wird als „unparsed“ erfasst und nie geraten. Vier Headful-Besuche endeten so, drei Seiten-Timeouts und eine Erfassung mitten in einer Aktualisierung. Sie zählen in den Tabellen als n/a.

Durchläufe: 3 pro Tool und Bedingung für Datacenter, rotierendes und Sticky-Residential, je 1 pro Tool für Headless und Warm-up. Insgesamt 54 Durchläufe, zwischen 06:50 und 08:02 UTC.

Ergebnisse: Automatisierungsprüfungen auf Browserebene

Die Tabelle zählt Durchläufe: „3/3“ heißt, die Seite hat den Browser in allen dreien markiert. Jede Zelle stammt aus der geparsten Ergebnisdatei.

Einige Details, die die Tabelle verbirgt:

• Die einzige fehlgeschlagene sannysoft-Zeile bei Camoufox ist „Chrome (New): missing“. Das ist für einen Firefox-basierten Browser zu erwarten und kein Automatisierungsleck.
• CreepJS gibt außerdem einen „% like headless“-Wert aus. Er lag in jedem Headful-Durchlauf bei 50 % für Playwright, 44 % für die drei Chrome-basierten Stealth-Tools und 6 % für Camoufox. Der „% stealth“-Wert war bei allen 0 %. CreepJS bewertet keine dieser Zahlen als bestanden oder durchgefallen.
• Pixelscans Bot-Check schlug zweimal um. Patchright bekam im einzigen Warm-up-Durchlauf „Bot Behavior Detected“ (CDP-Kachel), Zendriver einmal im rotierenden Durchgang. Beides ist auf den Screenshots zu sehen. Zwei weitere Pixelscan-Besuche sind n/a. Einer lief in einen Timeout. Beim anderen erfasste unser Text-Capture die Seite mitten in einer Aktualisierung, und der kurz darauf aufgenommene Screenshot zeigt „You're Definitely a Human“.
• nowsecure.nl zeigte in jedem Headful-Durchlauf seinen Seiteninhalt ohne verbleibende Challenge auf dem Bildschirm, reines Playwright von der Datacenter-IP eingeschlossen. Headful trennte es die Tools überhaupt nicht.

Warum genau diese Prüfungen Standard-Playwright erwischen (das Flag navigator.webdriver, Nebenwirkungen von CDP Runtime.enable, Start-Flags), erklären unser Patchright-Deep-Dive und unser Erklärartikel zu Browser-Fingerprinting.

Ergebnisse: IP-bezogene Signale, Datacenter vs. Residential

Nur zwei der Seiten bewerten das Netzwerk. Der Fingerprint-Playground zeigt VPN, Proxy, IP-Blocklist und einen Suspect Score. Pixelscans Fingerprint-Check zeigt Proxy und Standortkonsistenz. deviceandbrowserinfo sagt ausdrücklich, dass sein Test „does not use IP reputation or user behavior“. Dass seine Urteile sich mit der IP nicht bewegten, passt dazu.

Wo die Residential-IP geholfen hat

Pixelscan zeigte kein „Proxy detected“ mehr. In jedem Datacenter-Durchlauf zeigte es das, obwohl gar kein Proxy beteiligt war, was nahelegt, dass es das Hosting-ASN als Proxy liest. Über den Residential-Pool zeigte es das in 1 von 15 Sticky-Durchläufen. Camoufox bekam außerdem einen passenden Standort. Seine Option geoip=True setzt Zeitzone, Locale, Geolocation und WebRTC-IP anhand der Exit-IP, deshalb zeigte Pixelscan eine US-Stadt statt „Timezone spoofed“.

Wo sie geschadet oder nichts bewirkt hat

Das Proxy-Signal von Fingerprint erkannte die Residential-Exits in 33 von 34 Proxy-Durchläufen als Proxy-IPs, über alle drei Proxy-Modi hinweg, und hängte vielen davon Anbieternamen an. Wir lesen das so, dass Fingerprint Erkenntnisse über Residential-Pools hat. Es heißt nicht, dass jede IP etwas verraten hat, und es sagt nichts darüber, was eine bestimmte Website mit diesem Signal anfangen würde. Bei den Chrome-basierten Stealth-Tools stieg der Suspect Score über den Proxy, statt zu sinken. Der von Playwright ging von 19 auf 25–27, und der einzige Warm-up-Durchlauf kam auf 47.

Ein Teil davon ist vermutlich hausgemacht. Die Chrome-basierten Tools behielten die UTC-Zeitzone des Containers, also las Pixelscan eine US-IP mit UTC-Uhr in jedem Proxy-Durchlauf als „Timezone spoofed“. Camoufox zeigt denselben Mechanismus in umgekehrter Richtung. Von der Helsinkier Datacenter-IP aus verortete sein GeoIP-Lookup den Exit in Europe/Berlin, während ipinfo Helsinki angab. Fingerprint markierte daraufhin in allen drei Datacenter-Durchläufen ein VPN („timezone mismatch“) und einen Datacenter-Proxy mit niedriger Konfidenz, während die Chrome-Tools auf derselben IP keines der beiden Flags bekamen. Eine IP und eine Zeitzone, die sich widersprechen, fallen so oder so auf.

WebRTC verriet den Server hinter dem Proxy

CreepJS und Pixelscan gaben beide in jedem Proxy-Durchlauf von Playwright, Patchright und nodriver die Hetzner-Adresse des Hosts als WebRTC-IP aus. Der HTTP-Traffic lief über den Residential-Exit, die STUN-Anfrage über UDP aber nicht. Zendriver übergibt --webrtc-ip-handling-policy=disable_non_proxied_udp und --force-webrtc-ip-handling-policy standardmäßig, und CreepJS meldete WebRTC in all seinen Durchläufen als blockiert. Camoufox ersetzte die Adresse durch den Proxy-Exit. Ein blockiertes WebRTC ist selbst ein Signal, das manche Websites bewerten könnten. Ob eine dieser Seiten das bestraft, haben wir nicht getestet, und Pixelscan tat es nicht. Unter Wie Anti-Bot-Systeme Proxies erkennen finden Sie die anderen Diskrepanzen, nach denen sie suchen.

Der Headless-Modus verriet mehr als die IP

Wir haben pro Tool einen Headless-Durchlauf von der Datacenter-IP gemacht. Die Stichprobe ist kleiner als der Rest, aber die Richtung ist eindeutig:

Patchright und nodriver wurden allein durch den Wechsel in den Headless-Modus auf deviceandbrowserinfo und Fingerprint („bad bot, type: headless_chrome“) von sauber zu markiert. Bei sannysoft schlugen die Zeilen HEADCHR_UA und CHR_MEMORY fehl. Jedes Chrome-basierte Tool, Zendriver eingeschlossen, blieb bei nowsecure.nl auf Cloudflares „Just a moment...“-Seite hängen. Headful kamen dieselben Tools, reines Playwright eingeschlossen, direkt durch. Zendriver entging dem Bot-Flag von Fingerprint, wurde aber von deviceandbrowserinfo trotzdem markiert. Camoufox sah auf all diesen Seiten headless genauso aus wie headful.

Zwei Befunde aus dem Betrieb: Sticky Sessions und Hintergrund-Traffic

Parallele erste Verbindungen brachen Sticky Sessions

Mit einer Sticky-Session-ID zeigten Chrome-basierte Durchläufe oft auf der ersten Seite eine IP und ein paar Seiten später eine andere. Das passierte in 11 von 12 Sticky-Durchläufen. Camoufox blieb in 3 von 3 auf einer IP, vermutlich weil sein GeoIP-Lookup vor dem Browserstart eine einzelne Anfrage stellt. Mit curl haben wir es reproduziert: Sechs parallele Anfragen auf einer brandneuen Session-ID lieferten in zwei Versuchen 3 bzw. 5 verschiedene IPs. Sequenzielle Anfragen danach blieben auf einer. Eine einzelne serielle Warm-up-Anfrage vor dem Browserstart behob das in 4 von 4 Durchläufen. Unser erster Proxy-Durchgang nutzte außerdem einen Session-Parameter, den das Gateway nicht kennt, sodass jede Verbindung stillschweigend eine neue IP bekam. Dieser Durchgang ist oben als rotierende Bedingung aufgeführt. Die Lehre aus beidem: Prüfen Sie die Stickiness mit zwei sequenziellen Anfragen, bevor Sie sich darauf verlassen.

Manche Setups mit echtem Chrome laden im Hintergrund über Ihren Proxy herunter

Bei abgerechnetem Residential-Traffic verbrauchte Playwright etwa 7 MB pro Durchlauf über diese 9 Seiten, Patchright etwa 8 MB (12 MB in einem Durchlauf) und Camoufox 9–11 MB. Die meisten Durchläufe von nodriver und Zendriver verbrauchten 40–61 MB. In den Durchläufen, in denen wir Bytes pro Host protokolliert haben, kam das meiste von optimizationguide-pa.googleapis.com, einem Hintergrund-Download von Chrome. Zwei Durchläufe verbrauchten nur etwa 9 bzw. 15 MB, es passiert also nicht jedes Mal. Patchright startet ebenfalls echtes Chrome mit frischem Profil, zeigte das aber nicht, es hängt also davon ab, wie das Tool Chrome startet. Wenn Sie pro GB zahlen, zählen Sie die Bytes pro Host, bevor Sie skalieren.

Was dieser Benchmark nicht zeigt

• Er ist kein Test gegen produktive Anti-Bot-Systeme. Diese Seiten prüfen überwiegend Artefakte auf Browserseite. Kommerzielle Systeme ergänzen TLS- und HTTP/2-Fingerprints, Verhalten, IP-Historie und websitespezifische Modelle. Ein sauberes Ergebnis hier ist eine notwendige Hürde, keine hinreichende. Unser Leitfaden zu TLS-Fingerprinting behandelt eine Ebene, die diese Seiten kaum berühren.
• Die Stichprobe ist klein: 3 Durchläufe pro Zelle, ein Tag, ein Datacenter-Host in Finnland, ein Proxy-Land. Einzelne Umschwünge wie bei Pixelscan lassen sich nicht von Rauschen trennen.
• Es gab keine Interaktion. Keine Klicks, kein Scrollen, keine Formulare oder Mauspfade, Verhaltenserkennung wurde also nicht geprüft.
• Manche Prüfungen haben ein Gedächtnis. Der Fingerprint-Playground zeigt eine Historie pro Gerät („1 IP, 2 Linked IDs in the past 24 hours“), wiederholte Besuche könnten spätere Scores also beeinflusst haben.
• Die Standardwerte wurden nicht angepasst. Die Chrome-basierten Tools behielten UTC und en-US, Camoufox war auf Linux beschränkt, und nichts wurde über die Standardwerte der jeweiligen READMEs hinaus gehärtet. Ein angepasstes Setup könnte anders abschneiden. Das würden wir als Nächstes testen, gemessen haben wir es nicht.
• Ihre Ziele werden sich unterscheiden. Ob Sie eine Datacenter- oder Residential-IP nutzen sollten, hängt davon ab, was Sie wo sammeln. Residential vs. Datacenter fürs Scraping behandelt die Kostenseite. Prüfen Sie robots.txt, die Nutzungsbedingungen der Website und die Regeln zu personenbezogenen Daten, bevor Sie so etwas gegen eine echte Website laufen lassen.

Selbst nachvollziehen

Das Testgerüst umfasst etwa 260 Zeilen Python, ein 80-zeiliges Relay und einen Parser, der nur gespeicherten Seitentext liest. Unten steht das Patchright-Setup, das in unseren Daten sauber lief, mit den beiden Korrekturen von oben eingebaut: eine Warm-up-Anfrage, die die Sticky Session festnagelt, bevor Chrome parallele Verbindungen öffnet, und die WebRTC-Flags von Zendriver. Wir haben es einmal über einen US-Residential-Exit gegen deviceandbrowserinfo laufen lassen ("isBot": false); diese Prüfung gehört nicht zu den 54 Durchläufen.

import asyncio, os, tempfile, urllib.parse, urllib.request, uuid
from patchright.async_api import async_playwright

USER = os.environ["PROXY_USER"]          # Ihr Proxy-Benutzername
PASS = os.environ["PROXY_PASS"]          # Ihr Proxy-Passwort, niemals hart kodieren
GATE = "gate.proxyhat.com:8080"

def sticky_username() -> str:
    # eine frische Session pro Browserstart; -sid- hält die Exit-IP über Verbindungen hinweg
    return f"{USER}-country-US-sid-{uuid.uuid4().hex[:10]}-ttl-30m"

def warm_up(username: str) -> str:
    # eine serielle Anfrage, damit die Session fixiert ist, bevor Chrome parallele Verbindungen öffnet
    url = f"http://{urllib.parse.quote(username)}:{urllib.parse.quote(PASS)}@{GATE}"
    opener = urllib.request.build_opener(urllib.request.ProxyHandler({"http": url, "https": url}))
    return opener.open("https://api.ipify.org", timeout=30).read().decode()

async def main():
    username = sticky_username()
    print("session pinned to", warm_up(username))
    async with async_playwright() as p:
        ctx = await p.chromium.launch_persistent_context(
            user_data_dir=tempfile.mkdtemp(),
            channel="chrome",            # echtes Google Chrome, wie im Patchright-README empfohlen
            headless=False,              # auf einem Server unter Xvfb ausführen
            no_viewport=True,
            proxy={"server": f"http://{GATE}", "username": username, "password": PASS},
            args=["--webrtc-ip-handling-policy=disable_non_proxied_udp",
                  "--force-webrtc-ip-handling-policy"],
        )
        page = await ctx.new_page()
        await page.goto("https://deviceandbrowserinfo.com/are_you_a_bot")
        await page.wait_for_function("document.body.innerText.includes('\"isBot\"')", timeout=45000)
        print(await page.evaluate("document.body.innerText.match(/\"isBot\": (true|false)/)[0]"))
        await ctx.close()

asyncio.run(main())

Das Suffix im Benutzernamen ist ProxyHat-Syntax (-country-US für das Targeting, -sid-…-ttl-30m für eine Sticky Session). Ersetzen Sie es durch das Format Ihres Anbieters. Um einen Exit vor einem langen Lauf zu prüfen, zeigt der kostenlose Proxy-Checker, was eine Website sieht. So bewerten Sie eine Zelle wie wir:

1. Starten Sie pro Durchlauf einen frischen Browser, besuchen Sie jede Seite in einem neuen Tab und warten Sie, bis der Urteilstext der Seite selbst auf dem Bildschirm steht. Verwenden Sie keine feste Wartezeit. CreepJS haben wir nach Erscheinen der Scores 6 zusätzliche Sekunden gegeben, weil es weiterrechnet.
2. Speichern Sie document.body.innerText und einen ganzseitigen Screenshot, bevor Sie den Tab schließen.
3. Parsen Sie nur, was die Seite ausgegeben hat, zum Beispiel das "isBot"-JSON auf deviceandbrowserinfo, die Normal/Robot-Paare auf BrowserScan und „N% headless“ auf CreepJS. Alles andere ist „unparsed“.
4. Erfassen Sie die Exit-IP zu Beginn und vergleichen Sie sie mit der IP, die die letzte Seite zeigt. Weichen sie ab, war Ihre Session nicht sticky.
5. Zählen Sie die Proxy-Bytes pro Durchlauf, damit Hintergrund-Traffic auffällt, bevor die Rechnung es tut.

Was Sie daraus machen sollten

Bringen Sie zuerst den Browser in Ordnung: Standard-Playwright wurde von beiden IPs erwischt, die vier Stealth-Tools headful von keiner. Arbeiten Sie headful (auf Servern mit Xvfb), es sei denn, Sie haben gemessen, dass headless bei Ihren Zielen durchkommt. Machen Sie dann die Netzwerkgeschichte stimmig: Zeitzone an die Exit-IP anpassen, WebRTC blockieren oder über den Proxy leiten und bestätigen, dass Ihre Sticky Session wirklich sticky ist. Erst danach lohnt ein Residential-Proxy, und rechnen Sie damit, dass Proxy-bewusste Anbieter viele Residential-IPs trotzdem erkennen. Die IP entscheidet, ob Sie von vornherein als Datacenter-Traffic gelten. Der Browser entscheidet, ob Sie als Bot markiert werden.