Jeśli kiedykolwiek próbowałeś zautomatyzować dostęp do strony chronionej przez Cloudflare, prawdopodobnie spotkałeś się z widmem „Just a moment..." i kołem ładowania, które nigdy nie znika. Wewnętrzne mechanizmy Cloudflare Turnstile — niewidoczne wyzwanie, które zastąpiło tradycyjne CAPTCHA — opierają się na wielowarstwowej analizie Twojego połączenia TLS, przeglądarki i reputacji IP. Ten artykuł rozkłada na czynniki pierwsze cały pipeline detekcji: od JA4 TLS fingerprint, przez proof-of-work, po cf_clearance cookie, i pokazuje, jak skonfigurować residential proxies ze sticky session, aby legalnie przejść te kontrole.
Ważne zastrzeżenie prawne: Techniki opisane w tym artykule są przeznaczone do autoryzowanego testowania, badań bezpieczeństwa i dostępu do danych publicznych z poszanowaniem
robots.txti regulaminów serwisów. Próba nieautoryzowanego dostępu może naruszać Computer Fraud and Abuse Act (18 U.S.C. § 1030) oraz RODO/GDPR. Używaj odpowiedzialnie i wyłącznie w ramach legalnych przypadków użycia.
Wewnętrzne mechanizmy Cloudflare Turnstile: co naprawdę się uruchamia
Cloudflare Turnstile nie jest tradycyjnym CAPTCHA. Zamiast prosić użytkownika o rozwiązywanie zagadek wizualnych, uruchamia serię niewidocznych wyzwań (managed challenges) w tle przeglądarki. Cały proces trwa zazwyczaj 200–500ms i składa się z trzech warstw, które razem budują obraz „czy to prawdziwy człowiek". Zrozumienie turnstile internals wymaga spojrzenia na każdą z nich osobno.
- Managed-challenge JavaScript — Cloudflare wstrzykuje skrypt z domeny
challenges.cloudflare.com, który wykonuje kilkadziesiąt testów API przeglądarki w izolowanym środowisku iframe. Skrypt jest silnie zaciemniony (obfuskowany) i zmienia się co kilka dni. - Proof-of-work (PoW) — przeglądarka musi rozwiązać kryptograficzną zagadkę opartą na hashowaniu, co udowadnia, że klient wykonuje realne obliczenia, a nie jest prostym skryptem HTTP wysyłającym statyczne żądanie.
- Browser-API probes — skrypt sprawdza obecność i zachowanie ponad 30 API:
navigator.webdriver,WebGLRenderingContext,OfflineAudioContext,CanvasRenderingContext2D,PerformanceObserver,RTCPeerConnectioni wielu innych.
Po pomyślnym przejściu wszystkich testów, Cloudflare emituje ciasteczko cf_clearance. To ciasteczko jest ściśle powiązane z dwoma sygnałami: adresem IP klienta oraz nagłówkiem User-Agent. Jeśli którykolwiek z tych sygnałów się zmieni między żądaniami, cf_clearance zostaje odrzucone i musisz przejść wyzwanie ponownie.
Proof-of-work w szczegółach
Cloudflare wykorzystuje wariant algorytmu proof-of-work inspirowanego IETF Slowsly draft. Serwer wysyła challenge string i trudność (liczba wymaganych zerowych bitów w haśle). Klient musi znaleźć nonce, który połączony z challenge i zahashowany daje wynik spełniający warunek. W praktyce dla Chrome na desktopie trwa to około 50–150ms, ale dla prostego skryptu Python bez JIT — znacznie dłużej, co jest pierwszym sygnałem automatyzacji.
Browser-API probes — co dokładnie jest sprawdzane
Skrypt Turnstile sprawdza ponad 30 sygnałów z API przeglądarki. Oto najważniejsze z nich:
| Sygnał | Co sprawdza | Wynik dla headless browser |
|---|---|---|
navigator.webdriver |
Czy przeglądarka jest sterowana automatycznie (Puppeteer/Selenium) | true — natychmiastowa flaga |
| Canvas fingerprint | Unikalny hash renderowanego obrazu 2D na ukrytym canvas | Pusty lub identyczny dla wszystkich instancji headless na tej samej maszynie |
| WebGL renderer/vendor | Informacje o GPU z WEBGL_debug_renderer_info |
Google SwiftShader zamiast prawdziwego GPU (np. NVIDIA RTX 4070) |
| AudioContext fingerprint | Hash sygnatury przetwarzania audio OfflineAudioContext | Identyczny dla wszystkich instancji headless na tej samej maszynie |
navigator.plugins |
Lista zainstalowanych wtyczek przeglądarki | Pusta tablica [] w headless Chrome |
navigator.languages |
Preferowane języki z nagłówka i API | Często ["en-US"] zamiast pełnej listy np. ["en-US", "en", "pl"] |
Każdy z tych sygnałów jest porównywany z bazą znanych wzorców przeglądarek. Mismatch w jednym sygnale nie dyskwalifikuje automatycznie, ale obniża trust score. Kilka mismatchy — tak.
Cztery sygnały trust score w Cloudflare Bot Management (JA4)
Za fasadą Turnstile stoi Cloudflare Bot Management — system, który oblicza trust score dla każdego żądania na podstawie czterech głównych sygnałów. Trust score jest liczbą od 1 do 100, gdzie wyższe wartości oznaczają większe prawdopodobieństwo, że ruch pochodzi od prawdziwego użytkownika. Kluczowe dla cloudflare bot management ja4 jest to, że fingerprint TLS jest sprawdzany zanim jakikolwiek nagłówek HTTP zostanie wysłany.
1. JA4 TLS fingerprint
JA4 to ustandaryzowany format fingerprintu TLS, opracowany przez FoxIO. W przeciwieństwie do starszego JA3, JA4 sortuje rozszerzenia TLS przed hashowaniem, co czyni fingerprint bardziej odpornym na reordering i bardziej deterministycznym. Format JA4 składa się z czterech segmentów oddzielonych podkreślnikami:
JA4 = t13d1516h2_8daaf6152771_b0da82dd048e_000000000000
|---s---| |----c----| |----e----| |----k----|
SNI+ALPN Cipher suites Extensions Signature algos
Dla Chrome 120+ na Windows typowy JA4 wygląda tak:
JA4 = t13d1516h2_8daaf6152771_b0da82dd048e_000000000000Dla Python requests z biblioteką urllib3:
JA4 = t13d161400_971bed6d02ca_000000000000_000000000000Różnica w sortowaniu cipher suites (Chrome używa specyficznej kolejności preferencji zdefiniowanej w BoringSSL) i zestawie rozszerzeń (Chrome wysyła extension 10 (supported_groups), extension 51 (key_share), extension 57 (application_settings) w innej pozycji niż Python) sprawia, że Cloudflare może rozróżnić te dwa klienty jeszcze przed wysłaniem jakichkolwiek danych HTTP. To jest rdzeń cloudflare bot management ja4 — identyfikacja klienta na poziomie warstwy transportowej.
2. HTTP/2 SETTINGS frame
Drugim sygnałem jest fingerprint ramki SETTINGS protokołu HTTP/2. Każdy klient HTTP/2 wysyła na początku połączenia ramkę SETTINGS z określonymi parametrami. Cloudflare porównuje te wartości z bazą znanych przeglądarek.
Chrome wysyła:
SETTINGS: HEADER_TABLE_SIZE=65536, ENABLE_PUSH=0,
INITIAL_WINDOW_SIZE=6291456,
MAX_HEADER_LIST_SIZE=262144Python httpx z h2 wysyła:
SETTINGS: HEADER_TABLE_SIZE=4096, ENABLE_PUSH=0,
MAX_CONCURRENT_STREAMS=100,
INITIAL_WINDOW_SIZE=65535,
MAX_FRAME_SIZE=16384Mismatch między zadeklarowanym User-Agent (Chrome) a rzeczywistym fingerprintem HTTP/2 to natychmiastowa flaga krytyczna. Cloudflare wie, że Chrome nigdy nie wysyła MAX_CONCURRENT_STREAMS=100 w SETTINGS.
3. Browser fingerprint (canvas/WebGL/audio)
Trzeci sygnał to klasyczny browser fingerprint zbierany przez JavaScript Turnstile. Cloudflare oblicza hash z:
- Canvas fingerprint — renderuje ukryty obraz 2D na canvas z określonymi parametrami (gradient, tekst, krzywe Beziera) i haszuje wynik piksel po pikselu. Ten hash jest unikalny dla kombinacji GPU + driver + system operacyjnego + wersji przeglądarki. MDN Canvas API dokumentuje te funkcje.
- WebGL fingerprint — pobiera
getParameter(UNMASKED_VENDOR_WEBGL)igetParameter(UNMASKED_RENDERER_WEBGL). Headless Chrome zwracaGoogle Inc. (Google)iANGLE (Google SwiftShader), co jest natychmiast rozpoznawane jako środowisko wirtualne. - AudioContext fingerprint — tworzy
OfflineAudioContext, generuje sygnał oscylatora z określoną częstotliwością i haszuje wynikowy bufor. Ten fingerprint zależy od implementacji DSP w przeglądarce i jest trudny do sfałszowania.
4. IP reputation
Czwartym sygnałem jest reputacja adresu IP. Cloudflare utrzymuje rozległą bazę danych reputacji, która klasyfikuje adresy IP na podstawie:
- ASN (Autonomous System Number) — czy IP należy do dostawcy chmurowego (AWS AS14618, GCP AS15169, Azure AS8075), czy do ISP domowego (Comcast AS7922, Deutsche Telekom AS3320)
- Historycznego ruchu — czy z tego IP obserwowano wcześniej zautomatyzowany ruch, próby abuse, lub ataki
- Typu sieci — datacenter, residential, mobile
- Geografii — czy lokalizacja IP jest spójna z nagłówkami
Accept-Languagei strefą czasową przeglądarki
IP z zakresu datacenter (np. AWS 54.x.x.x, DigitalOcean 159.x.x.x) otrzymuje natychmiast trust score obniżony o 30–50 punktów względem residential IP z tego samego kraju.
Dlaczego Python z UA Chrome zostaje odrzucony natychmiast
To najczęstszy błąd początkujących scraperów próbujących cloudflare turnstile bypass: ustawienie nagłówka User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 w Python requests i nadzieja, że Cloudflare „nie zauważy". Problem polega na tym, że Cloudflare sprawdza User-Agent na samym końcu — najpierw weryfikuje JA4 i HTTP/2 SETTINGS, które są nie do sfałszowania na poziomie nagłówka HTTP.
Oto co Cloudflare widzi, gdy Python requests wysyła żądanie z UA Chrome:
- TLS handshake — JA4 fingerprint wskazuje na Python/urllib3 (inna kolejność cipher suites, brak rozszerzenia
application_settings), nie na Chrome. Mismatch z UA = flaga krytyczna. - HTTP/2 SETTINGS — wartości parametrów są typowe dla
hyper/h2, nie dla Chrome. Druga flaga krytyczna. - Brak JavaScript — Turnstile nie może uruchomić probes, bo klient nie wykonuje JS. Trzecia flaga.
- IP reputation — jeśli IP jest z datacenter, czwarta flaga.
Trust score = 1/100. Cloudflare nie wyświetla nawet wyzwania — po prostu zwraca 403 lub stronę „Just a moment...", która nigdy się nie załaduje, bo klient nie ma silnika JS.
Dlaczego residential proxies są kluczowe dla cf_clearance
Nawet jeśli używasz prawdziwej przeglądarki (Chrome, Firefox) z poprawnym JA4 i HTTP/2 SETTINGS, cf_clearance cookie jest powiązane z adresem IP, na którym zostało uzyskane. To oznacza:
- Jeśli uzyskasz
cf_clearancez IP203.0.113.50, a następnie zmienisz IP na203.0.113.51, cookie zostanie odrzucone. - Jeśli używasz rotujących proxy z rotacją per-request, każde żądanie wymaga ponownego przejścia Turnstile.
- Jeśli Twój proxy ma niestabilny exit IP (częste zmiany w obrębie tego samego ISP), sesje mogą być przerywane.
Dlatego sticky residential sessions są absolutnie konieczne. Oto porównanie typów proxy w kontekście Turnstile:
| Cecha | Datacenter proxy | Residential proxy (sticky) | Mobile proxy |
|---|---|---|---|
| IP reputation (ASN) | Niska — ASN chmurowy (AWS, Azure) | Wysoka — ASN domowego ISP | Bardzo wysoka — ASN operatora komórkowego |
| Stabilność exit IP | d>Wysoka (statyczny)Średnia–wysoka (sticky session) | Niska (NAT, częste zmiany) | |
| Trust score Cloudflare | 30–50/100 | 70–90/100 | 85–95/100 |
| cf_clearance compatibility | Tak, ale niski trust → częstsze wyzwania | Tak — optymalny kompromis | Tak, ale niestabilność IP unieważnia cookie |
| Koszt | $1–3/GB | $3–8/GB | $5–15/GB |
| Latencja | 50–100ms | 100–300ms | 200–500ms |
Residential proxy ze sticky session oferuje najlepszy kompromis: wysoki trust score, stabilny exit IP przez całą sesję i rozsądną latencję. Sprawdź cennik ProxyHat, aby znaleźć plan odpowiadający Twoim potrzebom.
Praktyczna implementacja z ProxyHat sticky sessions
Oto kompletny, legalny workflow do uzyskania i ponownego wykorzystania cf_clearance cookie z wykorzystaniem ProxyHat residential proxies i prawdziwej przeglądarki.
Krok 1: Konfiguracja sticky residential session
ProxyHat pozwala przypiąć sesję do konkretnego exit IP za pomocą flagi -session- w nazwie użytkownika:
# HTTP proxy z sticky session
http://user-session-abc123:pass@gate.proxyhat.com:8080
# SOCKS5 proxy z sticky session
socks5://user-session-abc123:pass@gate.proxyhat.com:1080
# Sticky session z geo-targeting (USA)
http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080
# Sticky session z geo-targeting (Niemcy, Berlin)
http://user-country-DE-city-berlin-session-abc123:pass@gate.proxyhat.com:8080
Sesja abc123 utrzyma ten sam exit IP przez cały czas trwania sesji. To kluczowe — cf_clearance musi być uzyskane i wykorzystane z tego samego IP.
Krok 2: Uruchomienie prawdziwej przeglądarki przez proxy
Używamy Playwright z Chromium, konfigurując proxy na poziomie przeglądarki:
from playwright.sync_api import sync_playwright
import json
PROXY = {
"server": "http://gate.proxyhat.com:8080",
"username": "user-session-abc123",
"password": "pass"
}
with sync_playwright() as p:
browser = p.chromium.launch(
headless=False, # headful dla lepszego fingerprintu
proxy=PROXY
)
context = browser.new_context(
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/120.0.0.0 Safari/537.36",
viewport={"width": 1920, "height": 1080},
locale="en-US"
)
page = context.new_page()
page.goto("https://example-protected-site.com")
# Czekaj na przejście Turnstile (max 15s)
page.wait_for_timeout(15000)
# Pobierz cookies
cookies = context.cookies()
cf_clearance = next(
(c for c in cookies if c["name"] == "cf_clearance"),
None
)
if cf_clearance:
print(f"cf_clearance: {cf_clearance['value']}")
print(f"expires: {cf_clearance['expires']}")
# Zapisz cookies do pliku
with open("cookies.json", "w") as f:
json.dump(cookies, f)
browser.close()
Krok 3: Ponowne wykorzystanie cf_clearance w żądaniach HTTP
Po uzyskaniu cf_clearance możesz użyć go w kolejnych żądaniach HTTP — ale tylko przez ten sam exit IP i z tym samym User-Agent:
import requests
# Ten sam sticky session = ten sam exit IP
proxies = {
"http": "http://user-session-abc123:pass@gate.proxyhat.com:8080",
"https": "http://user-session-abc123:pass@gate.proxyhat.com:8080"
}
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/120.0.0.0 Safari/537.36",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Accept-Language": "en-US,en;q=0.9"
}
cookies = {"cf_clearance": "UZMIxX7gMx..."}
response = requests.get(
"https://example-protected-site.com/api/data",
headers=headers,
cookies=cookies,
proxies=proxies
)
print(f"Status: {response.status_code}")
Krok 4: Weryfikacja z curl
curl -x "http://user-session-abc123:pass@gate.proxyhat.com:8080" \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" \
-H "Cookie: cf_clearance=UZMIxX7gMx..." \
"https://example-protected-site.com/api/data"
Pełną dokumentację parametrów ProxyHat znajdziesz na docs.proxyhat.com. Więcej o dostępnych lokalizacjach proxy na stronie lokalizacji ProxyHat.
Najczęstsze błędy i edge case'y
Błąd 1: Rotacja IP między uzyskaniem a wykorzystaniem cf_clearance
Najczęstszy błąd: scraper uzyskuje cf_clearance z jednego IP, a następnie przełącza proxy (lub sesja wygasa) i próbuje użyć cookie z innego IP. Cloudflare odrzuca je natychmiast. Rozwiązanie: Używaj sticky session przez cały cykl życia cookie (zazwyczaj 30 minut do 2 godzin).
Błąd 2: Niespójność User-Agent
Jeśli uzyskasz cf_clearance z Chrome 120, a następnie użyjesz go z UA Chrome 119 lub Firefox 121, cookie zostanie odrzucone. Cloudflare weryfikuje pełny string UA. Rozwiązanie: Przechowuj User-Agent razem z cookie i zawsze wysyłaj dokładnie ten sam.
Błąd 3: Headless browser bez modyfikacji
Puppeteer i Playwright w trybie headless=True mają domyślnie navigator.webdriver=true i WebGL renderer=SwiftShader. Cloudflare wykrywa to natychmiast. Rozwiązanie: Używaj trybu headful lub zastosuj bibliotekę puppeteer-extra-plugin-stealth, która modyfikuje te sygnały. Możesz też użyć Playwright z flagą --disable-blink-features=AutomationControlled.
Błąd 4: Zbyt częste żądania z tej samej sesji
Nawet z ważnym cf_clearance, Cloudflare monitoruje wzorzec ruchu. 100 żądań na sekundę z jednej sesji spowoduje rate limit lub ponowne wyzwanie. Rozwiązanie: Utrzymuj rozsądny rate limit (5–10 req/s) i dodaj losowe opóźnienia 200–800ms między żądaniami.
Edge case: cf_clearance wygasa
cf_clearance ma zazwyczaj TTL od 30 minut do 2 godzin, w zależności od konfiguracji serwisu. Po wygaśnięciu musisz przejść Turnstile ponownie. Zaimplementuj logikę wykrywania wygaśnięcia (status 403 lub redirect do challenge page) i automatycznego odnawiania tokena z zachowaniem tej samej sticky session.
Edge case: Geolokalizacja vs Accept-Language
Jeśli Twój residential exit IP jest w Niemczech, ale nagłówek Accept-Language wskazuje en-US, Cloudflare może podnieść flagę. Rozwiązanie: Dopasuj Accept-Language do lokalizacji exit IP. ProxyHat pozwala geo-targetowanie na poziomie kraju i miasta — używaj user-country-DE dla niemieckiego IP i ustawiaj Accept-Language: de-DE,de;q=0.9,en;q=0.8.
Kiedy to jest odpowiednie — kwestie prawne i etyczne
Techniki opisane powyżej są odpowiednie, gdy:
- Dostęp do danych publicznych — informacje dostępne bez logowania, niechronione przez paywall. Zobacz nasze use case'y web scrapingu.
- Autoryzowane testy bezpieczeństwa — pentesty z pisemną zgodą właściciela serwisu.
- Monitoring SERP — śledzenie pozycji w wyszukiwarkach. Więcej na stronie SERP tracking.
- Badania akademickie — zbieranie danych do publikacji naukowych z zgodą komisji etycznej.
Nie są odpowiednie, gdy:
- Próbujesz uzyskać nieautoryzowany dostęp do kont innych użytkowników.
- Omijasz paywall lub dostęp premium bez subskrypcji.
- Wykonujesz DDoS lub ataki brute-force na endpointy logowania.
- Scrapujesz dane osobowe w sposób naruszający RODO/GDPR bez podstawy prawnej.
W Stanach Zjednoczonych Computer Fraud and Abuse Act (18 U.S.C. § 1030) penalizuje „nieautoryzowany dostęp" do systemów komputerowych. W Unii Europejskiej RODO ogranicza przetwarzanie danych osobowych. Zawsze sprawdzaj regulamin serwisu (Terms of Service) i robots.txt przed rozpoczęciem automatyzacji.
Kluczowe wnioski
- Cloudflare Turnstile to nie CAPTCHA — to wielowarstwowy system detekcji oparty na JA4 TLS fingerprint, HTTP/2 SETTINGS, browser fingerprint (canvas/WebGL/audio) i IP reputation.
- JA4 fingerprint jest sprawdzany przed jakimikolwiek nagłówkami HTTP — nie da się go sfałszować w Python
requests.- cf_clearance cookie jest powiązane z IP + User-Agent — zmiana któregokolwiek unieważnia token.
- Residential sticky proxy jest konieczny — datacenter IP obniża trust score o 30–50 punktów, a rotujący IP unieważnia cf_clearance.
- Prawdziwa przeglądarka (Chrome/Firefox z Playwright) jest wymagana do przejścia niewidocznych wyzwań Turnstile (PoW + browser probes).
- ProxyHat sticky sessions (
-session-abc123w nazwie użytkownika) utrzymują stabilny exit IP — kluczowe dla utrzymania cf_clearance przez całą sesję.- Etyka i prawo — te techniki są tylko dla autoryzowanego dostępu, badań bezpieczeństwa i dostępu do danych publicznych.
