Automatyzacja przeglądarki bez blokad: 4 warstwy obrony

Twój skrypt automatyzacji działa lokalnie. Wrzucasz go na serwer i w kilka godzin zaczyna dostawać 403, CAPTCHe albo ciche blokady — każda strona zwraca ten sam pusty szkielet. Kod identyczny. Docelowy serwis się nie zmienił. Zmienił się kontekst, w jakim działa przeglądarka, a systemy anti-bot czytają ten kontekst na czterech niezależnych warstwach.

TL;DR: Automatyzacja jest blokowana, bo systemy anti-bot sprawdzają cztery warstwy: tożsamość przeglądarki (fingerprint), sygnały sieciowe (IP i TLS), wzorce zachowań (mysz, timing) oraz zarządzanie sesją (ciasteczka, stan). Naprawa jednej warstwy zostawia trzy pozostałe otwarte. Strukturalne rozwiązanie to podejście od dołu: zacznij od przeglądarki ze spójnym fingerprintem i routingiem proxy na poziomie silnika, a potem ogarnij zachowanie i sesje w kodzie.

Dlaczego automatyzacja jest blokowana

Systemy anti-bot — Cloudflare, Akamai, PerimeterX, DataDome — nie polegają na jednym teście. Scorują twoją sesję na podstawie wielu sygnałów jednocześnie. Czyste IP z wyciekającą flagą navigator.webdriver i tak zostanie zablokowane. Idealny fingerprint z datacenterowego IP — też. Detekcja jest warstwowa, więc obrona też musi być warstwowa.

Cztery warstwy, od najbardziej fundamentalnej do najbardziej sytuacyjnej:

Warstwa	Co sprawdza	Gdzie naprawić
1. Tożsamość przeglądarki	Fingerprint, flagi automatyzacji, sygnały silnika	Binarka przeglądarki
2. Sieć	Reputacja IP, TLS fingerprint, DNS, WebRTC	Konfiguracja proxy
3. Zachowanie	Ruch myszy, timing, wzorce scrollowania	Kod aplikacji
4. Sesja	Ciasteczka, stan logowania, częstotliwość requestów	Kod aplikacji

Warstwy 1 i 2 to problemy infrastrukturalne. Warstwy 3 i 4 to problemy w kodzie. Większość developerów zaczyna od warstwy 3 (dodawanie losowych opóźnień), podczas gdy warstwy 1 i 2 są szeroko otwarte. Dlatego fix nigdy nie trzyma.

Warstwa 1: Tożsamość przeglądarki

Tu pada większość automatyzacji — i tu większość developerów nie zagląda.

Standardowa instancja Chromium sterowana przez Playwright albo Puppeteer wycieka sygnałami automatyzacji z 20+ powierzchni: navigator.webdriver ustawiony na true, brak obiektu chrome.runtime, stringi WebGL renderera zdradzają headlessowy driver GPU, readbacki Canvas dają deterministyczne hashe, a wyjścia AudioContext nie pasują do prawdziwego sprzętu. Skrypty anti-bot zbierają to wszystko w pierwszych 200 ms ładowania strony — zanim twój kod w ogóle zacznie działać.

Co nie działa

Stealth pluginy jak puppeteer-extra-plugin-stealth czy playwright-stealth łatają niektóre sygnały na poziomie strony. Nadpisują navigator.webdriver JavaScriptem. Problem: systemy anti-bot odczytują sygnały z samego silnika przeglądarki, nie tylko ze strony. JavaScriptowy override navigator.webdriver jest wykrywalny, bo property descriptor różni się od prawdziwej przeglądarki. Canvas i WebGL readbacki idą z pipeline'u GPU, nie z JavaScriptu. Łatki na poziomie strony nie sięgają do silnika.

Losowa rotacja User-Agent zmienia jeden sygnał z 20+. Jeśli twój User-Agent mówi macOS, ale WebGL renderer raportuje linuxowy driver GPU, fonty są windowsowe, a offset strefy czasowej nie pasuje do locale — niespójność jest gorsza niż brak spoofingu.

Tryb headless (--headless) produkuje kompletnie inny fingerprint niż headed Chrome. Wymiary ekranu, ścieżka renderingu GPU, rendering fontów i listy pluginów — wszystko się różni. Część serwisów blokuje headless od razu.

Co działa

Poprawka jest na poziomie binarki przeglądarki. Anti-detect browser łata sygnały fingerprintu wewnątrz silnika Chromium, tak żeby były spójne na wszystkich 20+ powierzchniach: Canvas, WebGL, AudioContext, fonty, właściwości navigator, client rects, urządzenia medialne, wymiary ekranu, strefa czasowa, język i WebRTC — wszystko raportuje wartości pasujące do jednego prawdziwego profilu urządzenia.

Spójność to słowo klucz. Spoofowanie pojedynczych sygnałów tworzy sprzeczności. Zarządzane fingerprint zapewniają, że każdy sygnał opowiada tę samą historię.

Pełny rozkład wszystkich 20+ sygnałów znajdziesz w artykule Browser Fingerprinting: 20+ sygnałów, które systemy anti-bot wykorzystują do wykrywania automatyzacji.

Warstwa 2: Sieć

Czysta tożsamość przeglądarki z oflagowanego IP i tak zostanie zablokowana. Systemy anti-bot sprawdzają warstwę sieciową niezależnie.

Reputacja IP

Datacenterowe IP (AWS, GCP, Azure, DigitalOcean) są skatalogowane. Dostawcy anti-bot utrzymują bazy zakresów IP powiązanych z infrastrukturą cloudową. Requesty z tych zakresów dostają wyższy poziom kontroli albo blokadę niezależnie od fingerprintu przeglądarki.

Residentialne IP od prawdziwych ISP mają znacznie niższe wskaźniki blokad. Różnica jest mierzalna: ten sam skrypt automatyzacji z tym samym fingerprintem przeglądarki może przejść z 90% blokad na datacenterowym IP do poniżej 5% na residentialnym proxy.

TLS fingerprint

Każde połączenie HTTPS zaczyna się od TLS handshake'u. Kolejność cipher suites, rozszerzenia i obsługiwane krzywe w wiadomości ClientHello tworzą TLS fingerprint (JA3/JA4). Standardowy Chromium, headless Chrome i Playwright — każdy produkuje inny hash JA3. Jeśli TLS fingerprint mówi „narzędzie automatyzacji", a User-Agent mówi „Chrome 126 na macOS" — sesja zostaje oflagowana.

Rozwiązanie: użyj binarki przeglądarki, która produkuje prawdziwy chromeowy TLS fingerprint. Proxy na poziomie strony i biblioteki HTTP nie naprawią TLS fingerprintingu, bo handshake zachodzi zanim jakikolwiek JavaScript zostanie uruchomiony.

Dopasowanie geograficzne

Jeśli fingerprint twojej przeglądarki raportuje US English locale ze strefą czasową US, ale IP geolokalizuje się do datacentru we Frankfurcie — systemy anti-bot flagują rozbieżność. Routing proxy musi wyrównywać geografię: lokalizacja IP powinna pasować do strefy czasowej, języka i locale fingerprintu.

Wycieki WebRTC

WebRTC może ujawnić twoje prawdziwe IP nawet przy routingu przez proxy. Requesty STUN omijają konfigurację HTTP proxy i łączą się bezpośrednio, ujawniając źródłowe IP. To trzeba obsłużyć na poziomie przeglądarki, nie w kodzie aplikacji.

Warstwa 3: Wzorce zachowań

Przy warstwach 1 i 2 obsłużonych na poziomie infrastruktury, warstwa 3 to miejsce, gdzie liczy się twój kod.

Systemy anti-bot śledzą, jak sesja wchodzi w interakcję ze stroną. Prawdziwi użytkownicy nie nawigują jak skrypty: nie klikają elementów w 5 ms po załadowaniu strony, nie scrollują ze stałą prędkością 500 px/s i nie odwiedzają 200 stron w 60 sekund bez jakiegokolwiek idle time'u między nimi.

Co zaimplementować

Losowe opóźnienia między akcjami. Nie stały sleep(2000) — zrandomizowany zakres, zróżnicowany per typ akcji.

import random
import asyncio

async def human_delay(min_ms=800, max_ms=2500):
    delay = random.uniform(min_ms, max_ms) / 1000

Realistyczny ruch myszy. Przesuń kursor do elementu przed kliknięciem zamiast teleportować. Niektóre systemy anti-bot śledzą sekwencje eventów myszy i flagują kliknięcia bez poprzedzających eventów mousemove.

async def move_and_click(page, selector):
    element = await page.query_selector(selector)
    box = await element.bounding_box()
    # Move to element with some randomness in the endpoint
    x = box["x"] + box["width"] * random.uniform(0.3, 0.7)

Scrollowanie. Scrolluj stopniowo, nie od razu do dokładnej pozycji elementu. Prawdziwi użytkownicy przejeżdżają cel i wracają.

Pacing requestów. Jeśli uderzasz w tę samą domenę, rozłóż requesty tak, żeby sesja nie wyglądała jak crawler. 2-5 sekund między nawigacjami to rozsądna baza dla większości serwisów.

Warstwa 4: Zarządzanie sesją

Ostatnia warstwa to stan. Systemy anti-bot śledzą sesje w czasie i flagują wzorce, których żaden prawdziwy użytkownik nie produkuje.

Persistencja ciasteczek

Prawdziwe przeglądarki akumulują ciasteczka przez wiele wizyt. Sesja, która przychodzi z zerową liczbą ciasteczek, akceptuje je wszystkie, a potem pojawia się pięć minut później znowu z zerową liczbą — jest ewidentnie zautomatyzowana. Zachowuj stan ciasteczek między uruchomieniami za pomocą izolowanych profili przeglądarki.

Stan logowania

Jeśli twoja automatyzacja loguje się na konto, utrzymuj tę sesję. Logowanie, wykonanie jednej akcji i wylogowanie wielokrotnie z różnych fingerprintów flaguje konto.

Izolacja sesji

Przy wielu równoczesnych sesjach (scrapowanie różnych sekcji, obsługa wielu kont) każda sesja potrzebuje własnego izolowanego kontekstu: osobne ciasteczka, osobny local storage, osobny fingerprint. Cross-kontaminacja między sesjami — gdy ciasteczka z sesji A wyciekają do sesji B — to częsta przyczyna blokad w równoległej automatyzacji.

from playwright.async_api import async_playwright

async def isolated_session(profile_name, target_url):
    async with async_playwright() as p:
        # Connect to Clawbrowser with an isolated profile

Rate limiting

Monitoruj swoje wzorce requestów na pojedynczy cel. Jeśli robisz 1000 requestów na godzinę do tej samej domeny, żadne zarządzanie fingerprintem nie pomoże. Ustaw rozsądne limity per domena i rotuj sesje przy zbliżaniu się do progów. Można to osiągnąć rozkładając obciążenie między wiele kont, każde z osobnym profilem przeglądarki i proxy.

Składamy to razem

Warstwy 1 i 2 to infrastruktura. Nie powinno się ich rozwiązywać w kodzie aplikacji. Anti-detect browser z zarządzanymi fingerprintami i wbudowanym routingiem proxy obsługuje obie warstwy na poziomie silnika, więc twój kod zajmuje się tylko warstwami 3 i 4.

Clawbrowser to fork Chromium, który obsługuje te warstwy infrastruktury: łatki fingerprintu na poziomie silnika na 20+ powierzchniach, wbudowany routing proxy z dopasowaniem geograficznym, zapobieganie wyciekom WebRTC i natywne wsparcie CDP. Twój kod Playwright lub Puppeteer łączy się z nim jak z każdą inną instancją Chrome.

from playwright.async_api import async_playwright
import random, asyncio

async def scrape_with_clawbrowser():
    async with async_playwright() as p:

Zacznij od skopiowania promptu instalacyjnego z clawbrowser.ai i wklejenia go do swojego agenta AI — setup zajmuje mniej niż dwie minuty.

Warstwy są niezależne. Jeśli dostajesz blokady, zdiagnozuj, która warstwa jest przyczyną. Jeśli potwierdziłeś, że fingerprint jest czysty i IP nie jest oflagowane, problem jest w twoim kodzie behawioralnym albo zarządzaniu sesją. Jeśli zachowanie jest realistyczne, ale wciąż dostajesz blokady — problem jest w tożsamości przeglądarki albo warstwie sieciowej. Pracuj od dołu.

Krok po kroku diagnostykę przy pojawieniu się CAPTCHA znajdziesz w artykule Dlaczego twoja automatyzacja wywołuje CAPTCHA: diagnostyka 7 sygnałów.

Co nie działa (i dlaczego)

Podejście	Dlaczego nie działa
Flaga `--headless`	Produkuje inny fingerprint niż headed Chrome. Wiele serwisów blokuje headless z miejsca.
Stealth pluginy	Łatają sygnały na poziomie strony. Sygnały na poziomie silnika pozostają odsłonięte. Wykrywalne w ciągu miesięcy od każdego releasu.
Losowa rotacja User-Agent	Zmienia 1 sygnał z 20+. Tworzy niespójność z innymi sygnałami fingerprintu.
Rotacja samych IP	Naprawia warstwę 2, ale zostawia warstwę 1 szeroko otwartą. Czyste IP z wyciekającą tożsamością przeglądarki i tak zostanie zablokowane.
Dodanie `sleep(5)` wszędzie	Naprawia jeden aspekt warstwy 3. Nie adresuje warstw 1, 2 ani reszty warstwy 3.

Wspólny mianownik: każde podejście naprawia jeden sygnał w jednej warstwie. Systemy anti-bot sprawdzają wszystkie cztery warstwy jednocześnie. Częściowe fixy nie przeżywają na produkcji.

FAQ

Czy Cloudflare wykrywa Playwright?

Tak. Standardowy Playwright na stockowym Chromium jest wykrywalny przez Cloudflare Turnstile i Bot Management w ciągu sekund. Detekcja działa głównie na warstwie 1 (tożsamość przeglądarki): navigator.webdriver, artefakty CDP, różnice w renderingu WebGL i TLS fingerprinting. Szczegółowy rozkład znajdziesz w artykule Dlaczego twoje skrypty Playwright są blokowane przez Cloudflare.

Czy potrzebuję residentialnych proxy?

Przy serwisach z agresywnymi systemami anti-bot — tak. Datacenterowe IP są skatalogowane przez dostawców anti-bot i podlegają wyższej kontroli. Residentialne proxy od prawdziwych ISP znacząco redukują wskaźniki blokad. Ale residentialne IP z wyciekającym fingerprintem i tak zostanie zablokowane. Proxy naprawiają warstwę 2, nie warstwę 1.

Czy tryb headless jest zawsze wykrywany?

Nowoczesny headless Chrome (--headless=new) jest bliżej trybu headed niż stara implementacja, ale różnice pozostają w renderingu GPU, metrykach ekranu i dostępności fontów. Serwisy z zaawansowaną detekcją (Cloudflare, Akamai, DataDome) wciąż potrafią odróżnić sesje headless. Dla wartościowych celów, tryb headed z odpowiednim anti-detect browserem to niezawodny wybór.

Jak szybko mogę scrapować bez blokad?

Nie ma uniwersalnej liczby. Zależy od rate limitów docelowego serwisu i czułości detekcji. Rozsądny punkt startowy: 2-5 sekund między nawigacjami na tej samej domenie, zrandomizowane w tym zakresie. Monitoruj swój wskaźnik blokad i zwolnij, jeśli rośnie. Niektóre serwisy tolerują 1 request na sekundę. Inne flagują cokolwiek powyżej 1 requesta na 10 sekund z jednej sesji.

Czy automatyzacja przeglądarki dla AI agentów ma te same problemy z detekcją?

Tak. Frameworki AI agentów — Claude Code, Codex, Cursor, Hermes Agent — sterują przeglądarkami przez CDP. Systemy anti-bot sprawdzają tożsamość przeglądarki, nie to, czy komendy pochodzą od człowieka czy agenta. AI agent łączący się ze standardową instancją Chrome jest blokowany z tych samych powodów co skrypt Playwright. Szczegóły konfiguracji dla agentów znajdziesz w artykule CDP Browser dla AI agentów: przewodnik dla developerów.

Zacznij od fundamentów

Automatyzacja przeglądarki jest blokowana, bo systemy anti-bot sprawdzają cztery warstwy, a większość automatyzacji adresuje tylko jedną lub dwie. Naprawiaj od dołu: najpierw tożsamość przeglądarki, potem sieć, potem zachowanie, potem sesje. Pierwsze dwie warstwy to problemy infrastrukturalne, które należą do przeglądarki, nie do twojego kodu.