Patchright Deep-Dive: nie wykrywalny Playwright i czyste przejście z proxy residentialnymi

Co to jest Patchright Deep-Dive i dlaczego to nie jest kolejny „stealth plugin”

Patchright Deep-Dive to dogłębna analiza techniczna Patchrighta, forka Playwrighta, który modyfikuje binarkę Chromium tak, aby usunąć najczęstsze sygnały automatyzacji u źródła — zamiast doklejać warstwę JavaScriptowych łatek w czasie działania. Jeśli kiedykolwiek uruchomiłeś Playwrighta z playwright-extra i stealth, a Cloudflare Turnstile i tak cię zablokował, wiesz, że problem nie leży w samym JS, ale w tym, co przeglądarka „mówi” o sobie po stronie sieci i runtime'u.

W tym artykule rozkładamy Patchrighta na czynniki pierwsze: które sygnały wykrywania faktycznie modyfikuje, czego nie łata, dlaczego reputacja IP nadal przeważy nad zamkniętymi wyciekami CDP, jak wyrównać odcisk TLS/HTTP2 do wyjścia residentialnego, i jak uruchomić to wszystko przez ProxyHat w legalnej, autoryzowanej automatyzacji.

1. Sygnały wykrywania, które Patchright celuje

Systemy anty-bot nie opierają się na jednym teście. To kaskada: TLS → HTTP/2 → nagłówki → CDP runtime → właściwości JavaScript → zachowanie → reputacja IP. Patchright atakuje warstwę runtime i flagi uruchomieniowe, czyli te, które klasyczny Playwright zostawia otwarte.

1.1 navigator.webdriver

Standardowy Playwright uruchamia Chromium z flagą --enable-automation, co ustawia navigator.webdriver = true. To najtańszy sygnał — sprawdzany w pierwszych 5 linijkach większości skryptów anty-bot. Patchright usuwa tę flagę z listy argumentów startowych i dodatkowo nadpisuje getter navigator.webdriver na poziomie V8, a nie tylko przez Object.defineProperty w page world — co jest istotne, bo niektóre detektory czytają deskryptor z izolowanego świata i widzą oryginał.

1.2 Wycieki CDP i Runtime.enable

To najważniejsza część. Gdy Playwright podłącza się przez Chrome DevTools Protocol, włącza domeny takie jak Runtime.enable, Page.enable, Network.enable. Każde włączenie domeny ma skutki uboczne widoczne dla strony: Runtime.enable powoduje, że Error.stack zawiera ramki CDP, a console.debug emituje zdarzenia, których „czysty” Chrome nie emituje. Znane wycieki opisano m.in. w dyskusji browser-fingerprinting i w materiałach badaczy fingerprintingu.

Patchright patchuje binarkę Chromium tak, aby:

• nie wysyłała zdarzeń Runtime.executionContextCreated w sposób widoczny dla strony,
• nie zostawiała śladów cdp w Error.captureStackTrace,
• nie modyfikowała window.chrome.cdc_xxx pól, które DataDome i Akamai potrafią czytać.

To jest różnica między „ukryj sygnał w JS” a „nie generuj sygnału wcale”.

1.3 Flagi automatyzacji i --disable-blink-features=AutomationControlled

Patchright wstrzykuje --disable-blink-features=AutomationControlled do linii poleceń Chromium. To wyłącza m.in. modyfikację navigator.webdriver, flagę isAutomation w window.chrome oraz kilka sygnałów w Blink. Dodatkowo usuwa --enable-automation i --disable-extensions z domyślnych argumentów Playwrighta, które same w sobie są sygnałem.

1.4 channel='chrome' i prawdziwy stos TLS/JA3

To kluczowe. Patchright domyślnie używa channel='chrome', co oznacza, że uruchamia prawdziwy Google Chrome zainstalowany w systemie, a nie bundled Chromium. Różnica w TLS jest mierzalna:

• Chromium bundled i Chrome różnią się kolejnością szyfrów w ClientHello,
• Chrome używa GREASE w TLS 1.3 w miejscach, gdzie Chromium dev-build nie zawsze,
• rozszerzenia TLS, w tym application_settings i ALPN, różnią się między kanałami.

Dla ja3/ja4 fingerprintingu to oznacza, że bundled Chromium Playwrighta ma inny odcisk niż 90% ruchu w sieci — co samo w sobie jest sygnałem, zanim jeszcze strona odpali JS.

2. Co Patchright łata, a czego nie łata

Patchright nie jest magicznym pancerzem. Ma wyraźny zakres: runtime CDP i flagi uruchomieniowe. Nie modyfikuje odcisków warstwy prezentacji.

2.1 Co Patchright nie robi

• Canvas/WebGL: nie patchuje renderowania canvas ani WebGL. canvas.toDataURL() zwraca realny odcisk sprzętowy GPU. Jeśli twoja maszyna to serwer bez GPU, odcisk canvas będzie pusty lub nietypowy — sygnał.
• Fonty: nie modyfikuje listy zainstalowanych fontów. document.fonts.check() i pomiar szerokości glifów zdradzają zbiór fontów, który na serwerze Linux różni się od Windows/Mac użytkownika.
• Zachowanie: nie symuluje ruchu myszy, opóźnień, scrolla. Jeśli skrypt klika w 0ms po załadowaniu, DataDome to zmierzy.
• AudioContext: nie modyfikuje OfflineAudioContext fingerprintingu.

2.2 Porównanie: Patchright vs Camoufox vs playwright-stealth

Wniosek: Patchright jest najsilniejszy tam, gdzie chodzi o zamknięcie wycieków CDP i dopasowanie TLS do realnego Chrome. Camoufox jest silniejszy w warstwie prezentacji (canvas, fonty), ale kosztem nietypowego JA3 Firefoksa, który w niektórych segmentach ruchu jest mniejszością. playwright-stealth to warstwa JS, którą nowoczesne detektory czytają z izolowanego świata i omijają.

3. Dlaczego reputacja IP nadal przeważy

Zamknięcie wycieków CDP to warunek konieczny, ale nie wystarczający. Po tym, jak TLS, nagłówki i runtime zgadzają się z realnym Chrome, systemy takie jak Cloudflare Turnstile i DataDome przechodzą do scoringu reputacji IP.

Cloudflare zna pule ASN datacenterów — AWS, GCP, Azure, DigitalOcean, OVH. Ruch z tych puli ma z definicji wyższy risk score, bo większość z nich to boty. DataDome dodatkowo buduje graf powiązań IP: jeśli dany IP wysyłał 50 000 żądań w ciągu godziny na różne strony chronione DataDome, ten IP jest spalony niezależnie od tego, jak czysta jest przeglądarka.

Dlatego po zamknięciu wycieków runtime'u, residential proxy jest wymagany. Exit IP z puli residentialnej ASN (ISP, np. Comcast, Deutsche Telekom, Orange) ma naturalnie niski risk score, bo ruch z niego wygląda jak ruch realnych użytkowników. To jest różnica między „przeglądarka mówi, że jestem człowiekiem” a „sieć mówi, że jestem człowiekiem” — i oba muszą się zgadzać.

Mobile proxy idą krok dalej: ASN operatorów komórkowych (T-Mobile, Verizon) mają najniższe risk score, bo ruch z nich jest z definicji „z telefonu”. W przypadku Turnstile to często różnica między przejściem a challenge.

4. Wyrównanie TLS/HTTP2 do wyjścia residentialnego

Patchright z channel='chrome' daje ci realny ClientHello Chrome. Ale to nie koniec — musisz dopasować całą ścieżkę:

• JA3/JA4: ClientHello musi zgadzać się z wersją Chrome. Patchright to załatwia, jeśli używasz aktualnego Chrome.
• HTTP/2 SETTINGS: kolejność i wartości ustawień HTTP/2 (SETTINGS_HEADER_TABLE_SIZE, SETTINGS_INITIAL_WINDOW_SIZE) są częścią fingerprintingu HTTP/2 (akamai fingerprint). Chrome ma tu specyficzne wartości.
• Header order: kolejność nagłówków żądania (Host, Connection, sec-ch-ua, sec-fetch-*) musi zgadzać się z Chrome. Playwright domyślnie zachowuje kolejność Chrome, ale niektóre modyfikacje ją psują.
• Geo spójność: jeśli IP exit jest w Niemczech, a nagłówek Accept-Language mówi en-US i timezone to UTC, to niespójność, którą DataDome punktuje.

Kluczowa zasada: IP i odcisk muszą się zgadzać. Jeśli używasz residentialnego IP w DE, ustaw timezone='Europe/Berlin', locale='de-DE', i nie nadpisuj Accept-Language. Patchright nie zrobi tego za ciebie — to konfiguracja kontekstu.

5. Praktyczna implementacja: Patchright + ProxyHat residential sticky

Poniżej legalny przykład: autoryzowane badanie bezpieczeństwa publicznej strony, która używa Cloudflare Turnstile. Używamy sticky sesji residentialnej w US, żeby IP nie zmieniało się między żądaniami (ważne dla sesji logowania badacza lub ciągłości testu).

5.1 Konfiguracja proxy URL przez ProxyHat SDK

ProxyHat przyjmuje parametry geo i sesji w nazwie użytkownika. Format:

# HTTP, sticky sesja, US, miasto opcjonalnie
http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080

# SOCKS5
socks5://user-country-US-session-abc123:pass@gate.proxyhat.com:1080

Flagi łączysz myślnikiem w username: user-country-US-session-abc123. session-abc123 utrzymuje ten sam exit IP dla kolejnych żądań w sesji.

5.2 Patchright w Pythonie przez ProxyHat

from patchright.sync_api import sync_playwright

PROXY_URL = "http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080"

def run():
    with sync_playwright() as p:
        browser = p.chromium.launch_persistent_context(
            user_data_dir="/tmp/patchright-profile",
            channel="chrome",          # prawdziwy Chrome, nie bundled Chromium
            headless=False,            # headless=False = silniejszy stealth
            proxy={"server": PROXY_URL},
            locale="en-US",
            timezone_id="America/New_York",
            viewport={"width": 1920, "height": 1080},
            args=[
                "--disable-blink-features=AutomationControlled",
                "--disable-features=IsolateOrigins,site-per-process",
            ],
        )
        page = browser.new_page()
        page.goto("https://example-protected.com/", wait_until="domcontentloaded")
        # tu: autoryzowany test — np. pomiar czasu challenge Turnstile
        page.wait_for_timeout(5000)
        print(page.title())
        browser.close()

run()

Kluczowe punkty:

• channel="chrome" — uruchamia realny Chrome, nie Chromium. Wymaga Chrome zainstalowanego w systemie.
• headless=False — headless Chrome ma różnice w WebGL i fontach, które są sygnałem. Jeśli musisz headless, użyj headless="new" (nowy headless Chrome), który jest bliżej headed.
• launch_persistent_context — trwały profil zachowuje cookies i localStorage, co wygląda jak powracający użytkownik, a nie świeża maszyna.
• timezone_id i locale dopasowane do US exit IP.

5.3 curl do szybkiego testu proxy

curl -x http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080 \
  https://api.ipify.org

# SOCKS5
curl -x socks5://user-country-US-session-abc123:pass@gate.proxyhat.com:1080 \
  https://api.ipify.org

Używaj tego, żeby zweryfikować exit IP przed uruchomieniem Patchrighta. Jeśli IP nie odpowiada US ASN, nie trać czasu na uruchomienie przeglądarki.

5.4 Node.js wariant

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

const PROXY_URL = 'http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080';

(async () => {
  const browser = await chromium.launchPersistentContext('/tmp/patchright-profile', {
    channel: 'chrome',
    headless: false,
    proxy: { server: PROXY_URL },
    locale: 'en-US',
    timezoneId: 'America/New_York',
    args: ['--disable-blink-features=AutomationControlled'],
  });
  const page = await browser.newPage();
  await page.goto('https://example-protected.com/', { waitUntil: 'domcontentloaded' });
  console.log(await page.title());
  await browser.close();
})();

6. Typowe błędy i przypadki brzegowe

6.1 headless=True z channel='chrome'

Nadal masz różnice w WebGL i navigator.permissions. Jeśli strona sprawdza navigator.permissions.query({name:'notifications'}) w headless, wynik różni się od headed. Rozwiązanie: headless='new' lub uruchom na maszynie z Xvfb.

6.2 Nadpisywanie Accept-Language

Nie ustawiaj extraHTTPHeaders z Accept-Language: en-US, jeśli IP jest w DE. Chrome sam ustawi nagłówek na podstawie locale. Nadpisanie tworzy duplikat lub niespójność, którą DataDome wykrywa.

6.3 Brak opóźnień behawioralnych

Patchright nie symuluje zachowania. Jeśli skrypt klika w 50ms po domcontentloaded, to sygnał. Dodaj page.wait_for_timeout(random(800, 2400)) między akcjami i użyj page.mouse.move() z krzywą Béziera, a nie page.click() bez ruchu.

6.4 Sticky sesja zbyt długa

Sticky sesja session-abc123 utrzymuje ten sam IP tak długo, jak sesja żyje. Jeśli wykonasz 10 000 żądań z tego IP, spalisz go. Rotuj sesję co np. 50–100 żądań w scraping masowym, lub użyj sesji per-konwersja w testach autoryzowanych.

6.5 Brak weryfikacji exit ASN

Zanim uruchomisz Patchrighta, sprawdź ASN exit IP przez https://api.ipify.org i bazę ASN. Jeśli exit trafia na datacenter ASN (np. AWS), cała twoja konfiguracja stealth jest bezcelowa. ProxyHat residential powinien dawać ASN ISP. Sprawdź na /pl/locations dostępne lokalizacje.

7. Gdzie to jest odpowiednie — a gdzie nie

Patchright + residential proxy to narzędzie, nie licencja. Odpowiednie zastosowania:

• Autoryzowane badania bezpieczeństwa — pentesty z pisemnym zgodą właściciela strony, testy własnych wdrożeń Cloudflare.
• Publiczna, dozwolona automatyzacja danych — strony, które nie zakazują scrapingu w ToS i nie są za paywall/login, zgodnie z robots.txt.
• QA własnych aplikacji — testy e2e własnych produktów chronionych Turnstile/DataDome.
• Zgodność z RODO/CCPA — nie pobieraj danych osobowych bez podstawy prawnej. Zobacz wytyczne gdpr.eu i FTC Privacy & Security.

Nieodpowiednie: logowanie na cudze konta, omijanie paywalli, masowe tworzenie kont, carding, ticketing w naruszeniu ToS, oszustwa reklamowe, manipulacja ankietami. To nie jest problem techniczny — to problem prawny i etyczny. ProxyHat nie wspiera takich zastosowań.

8. Konfiguracja ProxyHat i linki wewnętrzne

Dla pełnej konfiguracji konta, listy lokalizacji i cennika:

• Cennik ProxyHat — plany residential, mobile, datacenter.
• Web scraping z ProxyHat — wzorce rotacji i zarządzania sesjami.
• Śledzenie SERP — specyfika Google i wyszukiwarek.
• Lokalizacje proxy — dostępne kraje i miasta.
• Dokumentacja ProxyHat — pełne API i SDK.

Najważniejsze wnioski

Patchright zamyka wycieki CDP i flagi automatyzacji u źródła — to warstwa konieczna, ale nie wystarczająca. Reputacja IP przeważy, gdy runtime jest czysty, dlatego residential proxy jest wymagany przeciw Turnstile i DataDome. Dopasuj TLS (channel='chrome'), timezone, locale i Accept-Language do exit IP. Nie nadpisuj nagłówków ręcznie. Rotuj sesję, nie IP-per-request, jeśli zależy ci na ciągłości. Używaj tego tylko w autoryzowanych, zgodnych z prawem zastosowaniach.

• Patchright > playwright-stealth w warstwie CDP; Camoufox > Patchright w warstwie canvas/fontów.
• channel='chrome' daje realny JA3/JA4 Chrome — nie używaj bundled Chromium do stealth.
• Residential exit ASN (ISP) jest warunkiem koniecznym; datacenter IP jest spalony niezależnie od przeglądarki.
• Sticky sesja przez session-xxx w username ProxyHat — rotuj co 50–100 żądań.
• Zachowanie nadal liczy: ruchy myszy, opóźnienia, scroll. Patchright tego nie symuluje.

FAQ

Co to jest Patchright Deep-Dive?

Patchright Deep-Dive to techniczna analiza forka Playwrighta o nazwie Patchright, który modyfikuje binarkę Chromium, aby usunąć sygnały automatyzacji u źródła — w tym navigator.webdriver, wycieki CDP (Runtime.enable) i flagi takie jak --enable-automation. W odróżnieniu od wtyczek JS, Patchright patchuje runtime i V8, dzięki czemu detektory czytające właściwości z izolowanego świata nie widzą śladów automatyzacji.

Dlaczego Patchright Deep-Dive ma znaczenie dla użytkowników proxy?

Ponieważ zamknięcie wycieków CDP to tylko połowa zadania. Systemy takie jak Cloudflare Turnstile i DataDome po sprawdzeniu runtime'u przechodzą do scoringu reputacji IP. Jeśli exit IP pochodzi z datacenter ASN (AWS, OVH), ma wysoki risk score i przeglądarka — choćby perfekcyjnie ukryta — zostanie zablokowana. Patchright bez residential proxy mija się z celem.

Który typ proxy działa najlepiej z Patchrightem?

Residential proxy z opcją sticky sesji i geo-targetingiem kraju/miasta. Exit IP z ASN ISP ma naturalnie niski risk score, bo ruch wygląda jak ruch realnych użytkowników. Mobile proxy (ASN operatorów komórkowych) mają jeszcze niższy score, ale są droższe. Datacenter proxy są bezużyteczne przeciw Turnstile/DataDome, niezależnie od konfiguracji Patchrighta.

Jak unikać blokad przy implementacji Patchright Deep-Dive?

Używaj channel='chrome' (prawdziwy Chrome, nie bundled Chromium), headless=False lub headless='new', dopasuj timezone i locale do exit IP, nie nadpisuj Accept-Language ręcznie, rotuj sticky sesję co 50–100 żądań, dodaj opóźnienia behawioralne i ruchy myszy między akcjami. Sprawdzaj ASN exit IP przed uruchomieniem przeglądarki. Nigdy nie używaj datacenter IP do stron chronionych Cloudflare/DataDome.