Patchright Deep-Dive: Unsichtbare Automatisierung mit Residential Proxies

Was ist der Patchright Deep-Dive?

Wenn Sie bereits undetected Playwright-Setup versucht haben, kennen Sie das Problem: Ihr Skript läuft, die Seite lädt, aber Cloudflare Turnstile oder DataDome blockieren Sie nach drei Requests. Der Patchright Deep-Dive zeigt, wie Patchright — ein gepatchter Playwright-Fork — die wichtigsten Headless-Detektionssignale schließt und wie Sie mit Residential Proxies von ProxyHat den verbleibenden IP-Reputations-Filter überwinden. Dieser Artikel richtet sich an Security Researcher und erfahrene Scraping-Engineers, die legitime Automatisierung betreiben — autorisierte Penetrationstests, öffentliche Datenextraktion und Compliance-Audits.

Patchright patcht nicht einfach navigator.webdriver. Es greift tiefer in die Chromium-Kommandozeilen-Flags, das CDP-Protokoll und die Browser-Channel-Auswahl ein. Aber selbst ein perfekt gepatchter Browser scheitert, wenn die IP-Reputation stimmt — deshalb kombinieren wir Patchright mit echten Residential Exit-IPs.

Technischer Kontext: Welche Detektionssignale Patchright angreift

1. navigator.webdriver

Das klassische Signal: Wenn Playwright oder Selenium einen Browser startet, setzt Chromium navigator.webdriver = true. Das W3C WebDriver-Protokoll definiert diese Eigenschaft explizit als true, wenn der Browser ferngesteuert wird. Patchright überschreibt dies nicht nur via Object.defineProperty im JavaScript-Layer — wie es playwright-stealth tut — sondern patcht die C++-Quellen in third_party/blink/renderer/core/, sodass der Wert bereits vor der ersten Script-Ausführung false ist. Das macht einen entscheidenden Unterschied: JS-basierte Overrides sind im V8-Heap sichtbar und können von fortgeschrittenen Detektoren wie puppeteer-extra-plugin-stealth erkannt werden, während ein Source-Level-Patch nicht unterscheidbar ist.

2. CDP Runtime-Lecks (Runtime.enable)

Das ist das subtilste Signal. Wenn Playwright eine Verbindung zum Browser aufbaut, ruft es Runtime.enable und Page.enable über das Chrome DevTools Protocol auf. Diese Aufrufe aktivieren den Instrumentation-Modus, und bestimmte JavaScript-APIs verhalten sich danach anders:

• Error.stack enthält in instrumentierten Kontexten oft zusätzliche Frames oder veränderte Zeilennummern.
• console.log wird an den CDP-Client weitergeleitet, was in echten Browsern nicht passiert.
• Die Runtime.evaluate-Antwortzeit unterscheidet sich von nativer Ausführung um 2–15 ms.

Patchright patcht die CDP-Verbindungslogik so, dass Runtime.enable verzögert oder gar nicht aufgerufen wird, bis es explizit benötigt wird. Das schließt ein Leak, das selbst playwright-stealth offen lässt — denn jenes Plugin operiert ausschließlich im JS-Layer und kann das CDP-Verhalten nicht verändern.

3. Command-Flag Tells und --disable-blink-features=AutomationControlled

Chromium wird von Playwright mit Flags wie --enable-automation, --disable-extensions und --disable-blink-features=AutomationControlled gestartet. Der letzte Flag ist besonders wichtig: Er entfernt die navigator.webdriver-Setzung auf Blink-Ebene. Aber --enable-automation setzt gleichzeitig einen Infobar-Banner und aktiviert das chrome.runtime-Verhalten, das Bot-Detektoren prüfen.

Patchright injiziert --disable-blink-features=AutomationControlled und entfernt gleichzeitig --enable-automation aus der Kommandozeile. Das ist ein feiner, aber kritischer Unterschied: Ein Browser mit --disable-blink-features=AutomationControlled aber ohne --enable-automation sieht aus wie ein normaler User-Start, nicht wie ein automatisierter Test.

4. channel='chrome' und der echte Chrome TLS/JA3-Stack

Wenn Sie Playwright mit dem Default-Chromium verwenden, erzeugt es einen TLS-ClientHello, der sich von echtem Chrome unterscheidet. Das liegt an unterschiedlichen BoringSSL-Builds und Cipher-Suite-Reihenfolgen. Cloudflare und DataDome fingerprinten den JA3-Hash — eine 32-Zeichen-MD5 über die TLS-ClientHello-Parameter — und vergleichen ihn mit bekannten Browser-Profilen.

Patchright empfiehlt channel='chrome' in der Browser-Launch-Konfiguration. Das bedeutet: Patchright startet den tatsächlich installierten Google Chrome (nicht das gebündelte Chromium), sodass der TLS-Stack identisch mit einem echten Chrome-Browser ist. Der JA3-Hash stimmt mit dem überein, den Millionen echter Chrome-Nutzer produzieren.

Ein falscher JA3-Hash reicht allein aus, um von Cloudflare blockiert zu werden — unabhängig davon, wie gut Ihr JavaScript-Layer gepatched ist.

Was Patchright patcht — und was nicht

Was Patchright schließt

Signal	Patchright-Lösung	Layer
navigator.webdriver	C++ Source-Patch in Blink	Browser-Source
CDP Runtime.enable	Verzögerte/verhinderte CDP-Aktivierung	Protokoll-Layer
--enable-automation Flag	Flag-Entfernung aus Kommandozeile	Launch-Args
TLS/JA3-Stack	channel='chrome' für echten Chrome	Netzwerk-Layer
chrome.runtime	Native Chrome-Erweiterungsumgebung	API-Layer

Was Patchright NICHT patcht

Patchright ist kein Allheilmittel. Folgende Signale bleiben unangepatched und erfordern zusätzliche Maßnahmen:

• Canvas-Fingerprinting: Die Canvas-Rendering-Hashes hängen von GPU, Treiber und Betriebssystem ab. Patchright verändert diese nicht. Canvas-Fingerprints sind pro Maschine einzigartig — wenn Sie von einem Server mit identischem Canvas-Hash 10.000 Requests senden, ist das ein klares Bot-Signal.
• WebGL-Renderer: WEBGL_debug_renderer_info gibt Google SwiftShader oder ähnliche Software-Renderer zurück, die in Headless-Umgebungen typisch sind.
• Font-Enumeration: Die installierten Schriftarten unterscheiden sich zwischen Server- und Desktop-Umgebungen drastisch.
• Verhaltenssignale: Mausbewegung, Scroll-Geschwindigkeit, Tastatur-Timing. Patchright simuliert kein menschliches Verhalten.

Camoufox und playwright-stealth im Vergleich

Camoufox geht einen anderen Weg: Es ist ein ge-Fork-ter Firefox-Build, der Canvas, WebGL und Fonts auf C++-Ebene randomisiert. Camoufox ist stärker bei Fingerprint-Diversifikation, aber schwächer bei TLS-Alignment, da Firefox einen anderen JA3-Hash als Chrome produziert und viele Detektoren Chrome-Profile erwarten.

playwright-stealth ist ein JavaScript-Plugin, das eine Reihe von Overrides injiziert. Es ist leichtgewichtig, aber oberflächlich: Es kann CDP-Lecks nicht schließen und die Overrides sind im V8-Heap sichtbar. Für einfache Seiten reicht es, gegen Cloudflare Turnstile oder DataDome reicht es nicht.

Feature	Patchright	Camoufox	playwright-stealth
navigator.webdriver	Source-Level	Source-Level	JS-Override
CDP Runtime.enable	Gepatched	N/A (Firefox)	Offen
Canvas/WebGL	Nicht gepatched	Randomisiert	Nicht gepatched
TLS/JA3 (Chrome)	Echt via channel='chrome'	Firefox-Stack	Abhängig vom Browser
Verhaltenssignale	Nicht simuliert	Nicht simuliert	Nicht simuliert

Warum IP-Reputation trotzdem zählt — und Residential Proxies Pflicht sind

Nachdem Patchright die CDP-Lecks geschlossen und den JA3-Stack ausgerichtet hat, bleibt ein Signal übrig, das keinen Browser-Patch überlisten kann: die IP-Adresse selbst. Cloudflare Turnstile und DataDome bewerten nicht nur den Browser-Fingerprint, sondern auch:

• ASN-Klassifizierung: Datacenter-IPs von AWS, DigitalOcean, Hetzner oder OVH werden mit 99%+ Wahrscheinlichkeit als Server markiert. Cloudflare pflegt eine ASN-Reputationsdatenbank, die Datacenter-Subnetze automatisch herabstuft.
• Historische Aktivität: Eine IP, die in den letzten 24 Stunden 500+ Requests an Cloudflare-geschützte Seiten gesendet hat, erhält einen Risikoscore, der unabhängig vom Browser-Fingerprint steigt.
• Geo-Konsistenz: Wenn der JA3-Hash zu einem Chrome-Profil passt, das typischerweise aus den USA stammt, aber die IP aus einem Rechenzentrum in Frankfurt kommt, entsteht eine Anomalie.

Residential Proxies lösen dieses Problem, weil sie echte ISP-zugewiesene IP-Adressen verwenden. Ein Residential Exit über Comcast, AT&T oder Deutsche Telekom hat eine ASN, die als ISP klassifiziert ist, nicht als hosting. Der Risikoscore startet niedrig, und wenn Sie die Rate Limits respektieren, bleibt er niedrig.

Ein perfekt gepatchter Patchright-Browser über einer Datacenter-IP wird von Cloudflare Turnstile immer noch blockiert. Der IP-Score wiegt schwerer als jeder Browser-Fingerprint.

Cloudflare Turnstile vs. DataDome: Unterschiedliche Prioritäten

Cloudflare Turnstile priorisiert JA3- und IP-Reputation. Ein sauberer Chrome-JA3 über einer Residential-IP reicht oft aus, um die Challenge ohne Interaktion zu passieren. Turnstile nutzt zusätzlich cf-chl-bypass-Cookies, die nach einem erfolgreichen Pass für 30 Minuten gültig bleiben.

DataDome ist aggressiver bei Verhaltensanalyse und Browser-Konsistenz. Es prüft window.chrome-Eigenschaften, navigator.permissions-Verhalten und die Konsistenz zwischen User-Agent und tatsächlichem Feature-Set. Patchright hilft hier massiv, weil es die window.chrome-Objekt-Hierarchie intakt lässt — im Gegensatz zu Headless-Chromium, wo window.chrome unvollständig ist.

TLS/HTTP2-Fingerprint-Alignment: IP und Fingerprint müssen übereinstimmen

Der JA3-Hash ist nur die halbe Wahrheit. Moderne Bot-Detection-Systeme wie Cloudflare nutzen zusätzlich JA4, das auch ALPN, SNI und Extensions einbezieht, sowie HTTP/2-Fingerprinting über die SETTINGS-Frame-Parameter und die HEADERS-Frame-Pseudoh-Header-Reihenfolge.

Wenn Sie channel='chrome' verwenden, stimmen JA3, JA4 und HTTP/2-Fingerprint mit einem echten Chrome überein. Aber die Konsistenzprüfung geht weiter:

• Geo-Kohärenz: Ein Chrome-JA3 von einer US-Residential-IP sollte zu einem User-Agent passen, der en-US als Sprache deklariert. Ein Mismatch (z. B. ja-JP User-Agent über einer US-IP) ist ein Signal.
• Zeitzone: Intl.DateTimeFormat().resolvedOptions().timeZone muss zur IP-Geo passen. Patchright überschreibt dies nicht — Sie müssen es selbst setzen.
• Accept-Language: Die HTTP-Header müssen zur Browser-Locale konsistent sein.

ProxyHat erlaubt Geo-Targeting auf Länderebene (-country-US) und Stadtebene (-country-DE-city-berlin), sodass Sie die Exit-IP mit dem Browser-Profil abstimmen können. Das ist entscheidend: Ein deutscher Chrome-JA3 über einer Berliner Residential-IP mit de-DE Accept-Language ist ein kohärentes Profil, das von Cloudflare als legitim eingestuft wird.

Praktische Implementierung: Patchright mit ProxyHat Residential Proxies

Im folgenden Beispiel richten wir einen Patchright-Persistent-Context ein, der über einen ProxyHat Residential-Proxy mit sticky Session läuft. Das Szenario: autorisierte SERP-Tracking auf einer Cloudflare-geschützten Seite.

Voraussetzungen

• Python 3.10+
• Patchright installiert: pip install patchright
• Echt installierter Google Chrome auf dem System
• ProxyHat-Konto mit Residential-Traffic

Proxy-URL zusammenbauen

ProxyHat nutzt eine einfache Username-basierte Konfiguration. Für einen sticky US-Residential-Proxy mit Session-ID abc123:

http://user-country-US-session-abc123:PASSWORD@gate.proxyhat.com:8080

Die Session-ID hält die IP für die Dauer der Session stabil — ideal für Multi-Page-Navigation, bei der Login-States oder Cookies über mehrere Requests hinweg konsistent bleiben müssen.

Vollständiges Patchright-Skript

from patchright.sync_api import sync_playwright
import json

# ProxyHat Residential Proxy Konfiguration
PROXYHAT_USER = "user-country-US-session-abc123"
PROXYHAT_PASS = "dein_passwort"
PROXY_URL = f"http://{PROXYHAT_USER}:{PROXYHAT_PASS}@gate.proxyhat.com:8080"

def scrape_protected_page(url: str):
    with sync_playwright() as p:
        # Persistent Context mit echtem Chrome und Residential Proxy
        browser = p.chromium.launch_persistent_context(
            user_data_dir="/tmp/patchright-profile",
            channel="chrome",          # Echter Chrome TLS-Stack
            headless=False,             # Headless ist riskanter; True nur mit zusätzlicher Absicherung
            proxy={
                "server": "http://gate.proxyhat.com:8080",
                "username": PROXYHAT_USER,
                "password": PROXYHAT_PASS,
            },
            args=[
                "--disable-blink-features=AutomationControlled",
                "--no-first-run",
                "--no-default-browser-check",
            ],
            viewport={"width": 1920, "height": 1080},
            locale="en-US",
            timezone_id="America/New_York",
            user_agent=(
                "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                "AppleWebKit/537.36 (KHTML, like Gecko) "
                "Chrome/131.0.0.0 Safari/537.36"
            ),
        )

        page = browser.new_page()

        # Accept-Language mit Locale konsistent halten
        page.set_extra_http_headers({
            "Accept-Language": "en-US,en;q=0.9",
        })

        try:
            response = page.goto(url, wait_until="domcontentloaded", timeout=30000)
            print(f"Status: {response.status}")

            # Auf dynamische Inhalte warten
            page.wait_for_timeout(2000)

            content = page.content()
            print(f"Content length: {len(content)}")

            # Prüfen, ob wir geblockt wurden
            if "cf-challenge" in content.lower() or "datadome" in content.lower():
                print("Block detected — IP oder Fingerprint-Signal noch aktiv")
            else:
                print("Seite erfolgreich geladen")

        except Exception as e:
            print(f"Error: {e}")
        finally:
            browser.close()

if __name__ == "__main__":
    scrape_protected_page("https://example.com/protected-page")

Node.js-Alternative

const { chromium } = require('patchright');

const proxyConfig = {
  server: 'http://gate.proxyhat.com:8080',
  username: 'user-country-US-session-abc123',
  password: 'dein_passwort',
};

(async () => {
  const browser = await chromium.launchPersistentContext(
    '/tmp/patchright-profile',
    {
      channel: 'chrome',
      headless: false,
      proxy: proxyConfig,
      args: [
        '--disable-blink-features=AutomationControlled',
        '--no-first-run',
      ],
      locale: 'en-US',
      timezoneId: 'America/New_York',
      userAgent:
        'Mozilla/5.0 (Windows NT 10.0; Win64; x64) ' +
        'AppleWebKit/537.36 (KHTML, like Gecko) ' +
        'Chrome/131.0.0.0 Safari/537.36',
    }
  );

  const page = await browser.newPage();
  await page.setExtraHTTPHeaders({ 'Accept-Language': 'en-US,en;q=0.9' });

  const response = await page.goto('https://example.com', {
    waitUntil: 'domcontentloaded',
    timeout: 30000,
  });

  console.log('Status:', response.status());
  await browser.close();
})();

curl-Test für schnelle Proxy-Validierung

curl -x http://user-country-US-session-abc123:PASSWORT@gate.proxyhat.com:8080 \
  https://api.ipify.org?format=json

Wenn die zurückgegebene IP eine US-Residential-ASN ist (z. B. Comcast, Charter, AT&T), ist der Proxy korrekt konfiguriert.

Häufige Fehler und Edge Cases

1. Headless-Modus ohne zusätzliche Absicherung

headless=True ist riskant, weil Headless-Chrome zusätzliche Signale erzeugt: navigator.webdriver ist schwerer zu verbergen, Permissions API verhält sich anders, und User-Agent enthält HeadlessChrome. Patchright patcht einige dieser Signale, aber Headless bleibt ein Risikofaktor. Wenn möglich, nutzen Sie headless=False mit einem virtuellen Display (Xvfb) auf Servern.

2. Sticky Session ohne Timeout-Management

Eine ProxyHat-Session wie session-abc123 hält die IP stabil, aber die zugrunde liegende Residential-IP kann nach 10–30 Minuten rotieren, je nach ISP-Verfügbarkeit. Wenn Sie eine Session über Stunden hinweg nutzen, kann die IP mid-flight wechseln, was zu Session-Cookie-Invalidierung führt. Setzen Sie eine neue Session-ID nach spätestens 30 Minuten.

3. User-Agent / Locale / Timezone-Mismatch

Der häufigste Fehler: US-Residential-IP mit de-DE Locale und Berliner Zeitzone. Das ist ein sofortiges Anomalie-Signal. Stimmen Sie alle drei auf die Geo-Location der Exit-IP ab.

4. Zu hohe Request-Rate

Auch mit sauberem Fingerprint und Residential-IP: 100 Requests pro Sekunde von einer einzigen IP löst Rate-Limiting aus. Eine realistische menschliche Rate liegt bei 1–5 Requests pro Sekunde. ProxyHat erlaubt bis zu 100 concurrent sessions — verteilen Sie die Last über mehrere Sessions.

5. Fehlendes Canvas/WebGL-Management

Wenn Sie denselben Patchright-Profil-Ordner für tausende Requests wiederverwenden, bleibt der Canvas-Hash konstant. Das ist nicht per se ein Problem, aber wenn Sie von derselben IP-Gruppe viele Requests mit identischem Canvas-Hash senden, ist das ein Cluster-Signal. Nutzen Sie separate Profil-Verzeichnisse pro Session.

ProxyHat-spezifische Konfiguration

ProxyHat bietet drei Proxy-Typen, die für Patchright-Setups relevant sind:

• Residential Proxies: Echte ISP-IPs, ideal für Cloudflare Turnstile und DataDome. Siehe Pricing für Traffic-basierte Pläne.
• Mobile Proxies: 4G/5G-Carrier-IPs mit noch höherer Reputation. Ideal für Social-Platform-Automatisierung.
• Datacenter Proxies: Schnell und günstig, aber ungeeignet für bot-geschützte Seiten. Nutzen Sie diese für ungeschützte APIs oder interne Tests.

Für Patchright-Setups gegen Cloudflare oder DataDome sind Residential Proxies die richtige Wahl. Die Geo-Targeting-Optionen finden Sie auf der ProxyHat Locations-Seite.

Weitere technische Details zur ProxyHat-API finden Sie in den offiziellen ProxyHat-Docs. Für Web-Scraping-Anwendungsfälle siehe Web-Scraping, für SERP-Tracking SERP-Tracking.

WO das angemessen ist — und wo nicht

Patchright mit Residential Proxies ist ein mächtiges Werkzeug. Wie jedes Werkzeug muss es ethisch und legal eingesetzt werden.

Angemessene Use Cases

• Autorisierte Security Research: Penetrationstests mit schriftlicher Erlaubnis des Ziel-Systembesitzers.
• Public-Data-Automatisierung: Extraktion öffentlich zugänglicher Daten gemäß robots.txt und geltendem Recht (GDPR, CCPA).
• SERP-Tracking: Ranking-Monitoring für SEO-Zwecke mit respektierbaren Request-Raten.
• Preisvergleich und Marktanalyse: Aggregation öffentlicher Produktpreise für legitimate business intelligence.
• QA-Automatisierung: Testen eigener oder kundenfreundlich autorisierter Web-Anwendungen.

NICHT angemessen

• Credential Stuffing oder Login-Brute-Force: Das ist illegal und ein Missbrauch des Tools.
• Betrug bei Ticketing oder Sneaker-Releases: Das verletzt die AGB der Plattformen und ist in vielen Gerichtsbarkeiten strafbar.
• Scraping login-walled Inhalte ohne Erlaubnis: Das verletzt ToS und potenziell das Computer Fraud and Abuse Act (CFAA) oder das deutsche Digitale-Gesetz.
• Spam oder Social-Media-Manipulation: Account-Erstellung in Masse und Engagement-Manipulation.

Wenn Sie sich fragen, ob Ihr Use Case legitim ist: Wenn Sie eine schriftliche Erlaubnis haben oder ausschließlich öffentliche Daten extrahieren, sind Sie auf der sicheren Seite. Im Zweifel: Konsultieren Sie einen Anwalt.

Key Takeaways

• Patchright schließt CDP-Lecks, navigator.webdriver und Kommandozeilen-Flags auf Source-Ebene — tiefer als playwright-stealth, aber nicht so umfassend wie Camoufox bei Canvas/WebGL.
• channel='chrome' ist Pflicht — nur ein echter Chrome-TLS-Stack erzeugt den korrekten JA3/JA4-Hash, den Cloudflare erwartet.
• IP-Reputation schlägt Browser-Fingerprint — selbst ein perfekt gepatchter Browser über einer Datacenter-IP wird von Cloudflare Turnstile blockiert. Residential Proxies sind nicht optional.
• Geo-Konsistenz ist entscheidend — IP-Land, Locale, Zeitzone und Accept-Language müssen übereinstimmen. ProxyHat Geo-Targeting macht dies einfach.
• Sticky Sessions für Multi-Page-Flows — -session-abc123 hält die IP stabil, aber rotieren Sie die Session alle 20–30 Minuten.
• Ethische Nutzung ist nicht verhandelbar — autorisierte Forschung und öffentliche Datenextraktion nur.

Häufige Fragen (FAQ)

Was ist Patchright Deep-Dive?

Der Patchright Deep-Dive ist die detaillierte technische Analyse des undetected Playwright-Forks Patchright. Er untersucht, welche Detektionssignale — navigator.webdriver, CDP Runtime.enable, Kommandozeilen-Flags, TLS/JA3-Stack — auf Source-Ebene gepatched werden und wie Residential Proxies den verbleibenden IP-Reputations-Filter schließen. Ziel ist es, Security Researchern und Scraping-Engineers eine konkrete Implementierungsgrundlage zu geben.

Warum ist Patchright Deep-Dive für Proxy-Nutzer relevant?

Patchright allein reicht nicht aus, um bot-geschützte Seiten zu passieren. Selbst wenn alle Browser-Fingerprint-Signale geschlossen sind, bewerten Cloudflare Turnstile und DataDome die IP-Reputation unabhängig. Datacenter-IPs werden als Server klassifiziert und blockiert, unabhängig vom Browser. Residential Proxies von ProxyHat liefern echte ISP-IPs, die den IP-Score niedrig halten — das schließt die Lücke, die Patchright nicht patchen kann.

Welcher Proxy-Typ funktioniert am besten für Patchright?

Residential Proxies sind die beste Wahl für Patchright-Setups gegen Cloudflare oder DataDome. Sie bieten echte ISP-ASNs, die nicht als Hosting klassifiziert werden. Mobile Proxies haben eine noch höhere Reputation, sind aber teurer und langsamer. Datacenter Proxies sind für bot-geschützte Seiten ungeeignet, eignen sich aber für ungeschützte APIs oder interne Tests. Für die meisten Use Cases sind Residential Proxies mit Geo-Targeting und sticky Sessions der optimale Kompromiss.

Wie vermeidet man Blocks bei der Patchright-Implementierung?

Drei Schichten sind entscheidend: (1) Patchright mit channel='chrome' für echten TLS-Stack, (2) Residential Proxy mit Geo-Targeting, das zur Browser-Locale passt, (3) konsistente Header und moderate Request-Raten (1–5 Requests/Sekunde). Vermeiden Sie Headless-Modus ohne zusätzliche Absicherung, rotieren Sie sticky Sessions alle 20–30 Minuten, und nutzen Sie separate Profil-Verzeichnisse pro Session, um Canvas-Hash-Clustering zu verhindern.

Kann Patchright Headless-Chrome vollständig tarnen?

Patchright patcht viele Headless-Signale, aber Headless bleibt ein Risikofaktor. navigator.webdriver wird auf Source-Ebene geschlossen, aber Permissions API, User-Agent-Suffix und bestimmte window.chrome-Eigenschaften können noch Hinweise liefern. Für maximale Tarnung nutzen Sie headless=False mit Xvfb auf Servern. Das erzeugt einen echten Rendering-Kontext, der von Headless-Chrome unterscheidbar ist.