HTTP/2 Fingerprinting Wyjaśnione: Przewodnik dla inżynierów 2026

HTTP/2 Fingerprinting wyjaśnione: jak protokół zdradza automatyzację

Jeśli Twoje zapytania HTTP/2 są blokowane zanim jakikolwiek JavaScript się załaduje, problem prawdopodobnie nie leży w CAPTCHA ani w canvas fingerprinting — leży w samej ramce SETTINGS. HTTP/2 fingerprinting to technika, w której serwery anti-bot analizują parametry protokołu transportowego, zanim w ogóle wyślesz pierwszy bajt payloadu. W 2026 roku systemy takie jak Akamai Bot Manager, Cloudflare Bot Management i DataDome wykorzystują te sygnały jako pierwszą linię obrony, często zanim TLS handshake zostanie w pełni zakończony.

Ten przewodnik wyjaśnia, jak działa fingerprinting HTTP/2 na poziomie protokołu, dlaczego popularne biblioteki Pythona i Node.js zdradzają automatyzację, i jak przedstawić spójny fingerprint przeglądarkowy używając curl_cffi przez proxy residential ProxyHat. Skierowany jest do inżynierów scraping i badaczy bezpieczeństwa, którzy potrzebują głębokiego zrozumienia warstwy protokołu.

Co dokładnie jest fingerprintowane w HTTP/2

Fingerprinting HTTP/2 nie polega na analizie treści żądania — polega na analizie struktury połączenia. Każdy klient HTTP/2 musi wysłać ramkę SETTINGS jako część preface'u protokołu, a wartości w tej ramce są implementacyjno-specyficzne. Oznacza to, że Chrome wysyła inne wartości niż Firefox, a Firefox inne niż httpx czy requests.

Ramka SETTINGS i kluczowe parametry

Ramka SETTINGS jest pierwszą ramką HTTP/2 wysyłaną po connection preface. Zawiera parametry konfiguracyjne, które serwer może wykorzystać do fingerprintingu. Najważniejsze z nich to:

• HEADER_TABLE_SIZE — rozmiar tabeli kompresji HPACK. Chrome ustawia 65536 bajtów, Firefox również 65536, ale RFC 9113 określa wartość domyślną 4096 bajtów. Biblioteki takie jak httpx czy h2 używają właśnie 4096.
• INITIAL_WINDOW_SIZE — początkowy rozmiar okna kontroli przepływu. Chrome ustawia 6291456 bajtów, Firefox 131072, a httpx domyślnie 65535.
• MAX_CONCURRENT_STREAMS — maksymalna liczba jednoczesnych strumieni. Chrome ustawia 1000, Firefox 1000, httpx często nie wysyła tego parametru wcale.
• ENABLE_PUSH — czy push jest włączony. Chrome wysyła 0 (wyłączony), wiele bibliotek nie wysyła tego parametru.

Te cztery wartości, w tej konkretnej kolejności, tworzą unikalny wzorzec dla każdego klienta. Serwer anti-bot nie musi dekodować żadnej treści — wystarczy, że porówna wartości SETTINGS z bazą znanych przeglądarek.

WINDOW_UPDATE i priorytety strumieni

Po ramce SETTINGS klient wysyła ramkę WINDOW_UPDATE, która zwiększa rozmiar okna połączenia. Chrome wysyła WINDOW_UPDATE z wartością 15663105 (co daje łączne okno 15728640 bajtów). Ta wartość jest tak specyficzna dla Chrome, że jej brak lub inna wartość natychmiast sygnalizuje, że klient nie jest prawdziwą przeglądarką Chrome.

Priorytety strumieni to kolejny sygnał. HTTP/2 pozwala klientowi przypisać wagi i zależności do strumieni. Chrome wysyła specyficzny wzorzec priorytetyzacji dla żądań CSS, JavaScript i obrazów. Biblioteki HTTP zazwyczaj nie wysyłają żadnych ramek priorytetyzacji, co jest równie charakterystyczne co wysłanie złych wartości.

Kolejność pseudo-nagłówków

HTTP/2 używa pseudo-nagłówków zamiast linii żądania HTTP/1.1. Kolejność tych pseudo-nagłówków jest istotna dla fingerprintingu. Standardowa kolejność dla większości przeglądarek to:

1. :method (m)
2. :authority (a)
3. :scheme (s)
4. :path (p)

Chrome i Firefox używają kolejności m,a,s,p. httpx i niektóre inne biblioteki mogą używać kolejności m,p,a,s lub innej, co natychmiast zdradza, że klient nie jest przeglądarką.

Akamai h2 fingerprint i JA4H

Akamai spopularyzował format akamai h2 fingerprint — kompaktowy ciąg znaków, który koduje wszystkie sygnały HTTP/2 w jeden string. Format wygląda mniej więcej tak:

1:65536;2:0;3:1000;4:6291456;6:262144|15663105|0|m,a,s,p

Gdzie segmenty przed pierwszym | to parametry SETTINGS (w formacie id:wartość), drugi segment to WINDOW_UPDATE, trzeci to priorytety, a ostatni to kolejność pseudo-nagłówków. Ten string jest tak unikalny, że Akamai może zidentyfikować konkretną wersję przeglądarki na podstawie samych wartości liczbowych.

JA4H fingerprint to nowszy standard opracowany przez FoxIO, który rozszerza koncepcję fingerprintingu HTTP o więcej sygnałów. JA4H koduje: wersję HTTP, metodę, kolejność nagłówków, kolejność pseudo-nagłówków i parametry SETTINGS w ustrukturyzowany ciąg. Według dokumentacji JA4, format JA4H pozwala na precyzyjną identyfikację klienta z dokładnością do wersji minor. Połączenie JA4 (TLS) i JA4H (HTTP) daje systemom anti-bot pełny obraz klienta w dwóch warstwach jednocześnie.

Dlaczego httpx z JA4 Chrome nadal zostaje zablokowany

To jest najczęstszy błąd, który popełniają inżynierowie scraping: używają biblioteki takiej jak httpx z TLS fingerprintem Chrome (np. przez curl_cffi z impersonate="chrome"), ale nie dostosowują parametrów HTTP/2. Wynik: JA3/JA4 twierdzi, że to Chrome 148, ale ramka SETTINGS mówi coś innego.

Konkretny przykład: httpx używa HEADER_TABLE_SIZE 4096 jako wartości domyślnej, zgodnie z RFC. Chrome 148 używa HEADER_TABLE_SIZE 65536. Kiedy serwer anti-bot otrzymuje połączenie z TLS fingerprintem Chrome 148, ale ramką SETTINGS z HEADER_TABLE_SIZE 4096, natychmiast przypisuje maksymalny bot score — zanim jakikolwiek HTML zostanie wysłany.

To jest tzw. mismatch TLS-h2. Systemy anti-bot w 2026 nie sprawdzają pojedynczych sygnałów — sprawdzają spójność między warstwami. Jeśli Twój TLS mówi Chrome, ale Twój HTTP/2 mówi httpx, jesteś zablokowany. Punkt.

Ten sam problem dotyczy INITIAL_WINDOW_SIZE. Chrome ustawia 6291456 bajtów, httpx domyślnie 65535. Różnica ponad 98% w wartości jednego parametru wystarczy, aby system anti-bot podjął decyzję blokady bez dalszej analizy.

Spójność TLS i HTTP/2: dlaczego JA3/JA4 musi zgadzać się z h2

Fingerprinting TLS (JA3/JA4) i fingerprinting HTTP/2 to dwa niezależne sygnały, ale nowoczesne systemy anti-bot traktują je jako jeden. JA3/JA4 analizuje ClientHello — kolejność i wartości rozszerzeń TLS, oferowanych szyfrów i krzywych eliptycznych. HTTP/2 fingerprinting analizuje ramki SETTINGS i WINDOW_UPDATE. Jeśli te dwa się nie zgadzają, system wie, że masz do czynienia z klientem, który manipuluje swoim fingerprintem.

Problem polega na tym, że wiele bibliotek HTTP/2 w Pythonie i Node.js nie pozwala na dostosowanie parametrów SETTINGS. Oto krótki przegląd:

Jak widać, tylko curl_cffi z opcją impersonate potrafi wysłać spójny fingerprint Chrome w obu warstwach — TLS i HTTP/2. Wszystkie inne popularne biblioteki wysyłają domyślne wartości RFC, które natychmiast zdradzają automatyzację.

HTTP/3 i QUIC: następna granica fingerprintingu

HTTP/3 działa nad QUIC, który jest protokołem opartym na UDP. Fingerprinting HTTP/3 jest jeszcze w początkowej fazie, ale już teraz systemy anti-bot zaczynają analizować parametry QUIC transport parameters w sposób analogiczny do SETTINGS frame w HTTP/2. Kluczowe parametry QUIC, które są fingerprintowane, to initial_max_data, initial_max_stream_data_bidi_local, max_idle_timeout i active_connection_id_limit.

Chrome wysyła specyficzny zestaw QUIC transport parameters, który różni się od Firefox i od bibliotek takich jak aioquic. Ponieważ QUIC wymaga UDP, większość proxy HTTP nie obsługuje go bezpośrednio — to oznacza, że fingerprinting HTTP/3 jest obecnie mniej istotny dla użytkowników proxy, ale sytuacja może się zmienić, gdy więcej serwerów proxy zacznie obsługiwać UDP forwarding.

Na razie najlepszą strategią jest używanie HTTP/2 przez proxy residential, co zapewnia pełną kontrolę nad fingerprintem i jest szeroko obsługiwane przez wszystkie serwery proxy, w ProxyHat na porcie 8080 (HTTP) lub 1080 (SOCKS5).

Dlaczego proxy residential jest nadal wymagane

Wielu inżynierów uważa, że wystarczy dostosować fingerprint HTTP/2 i problem zniknie. Inni uważają, że wystarczy kupić proxy residential. Obie grupy się mylą — potrzebujesz obu.

Systemy anti-bot w 2026 używają wielowarstwowego scoringu:

• Warstwa IP — reputacja IP, ASN, typ (residential/datacenter/mobile), historia. Datacenter IP od DigitalOcean lub AWS dostaje natychmiast +30 punktów bot score w wielu systemach.
• Warstwa TLS — JA3/JA4 fingerprint, zgodność z deklarowanym User-Agent.
• Warstwa HTTP/2 — ramka SETTINGS, WINDOW_UPDATE, priorytety, kolejność pseudo-nagłówków.
• Warstwa behawioralna — wzorce żądań, tempo, kolejność ładowania zasobów, interakcje z myszą.

Nawet jeśli Twój fingerprint HTTP/2 jest idealny, datacenter IP nadal dostanie wysoki bot score. I odwrotnie — nawet jeśli Twoje IP jest residential z doskonałą reputacją, mismatch TLS-h2 natychmiast Cię zdradzi. Potrzebujesz spójnego fingerprintu protokołu oraz adresu IP residential o dobrej reputacji.

Dlatego ProxyHat oferuje proxy residential, które w połączeniu z curl_cffi dają spójny, niewykrywalny profil. Sprawdź dostępne lokalizacje i cennik, aby dopasować plan do swoich potrzeb.

Praktyczna implementacja: curl_cffi + ProxyHat residential exits

Oto kompletny, uruchamialny przykład w Pythonie, który łączy fingerprint Chrome przez curl_cffi z proxy residential ProxyHat. Ten kod wysyła spójny fingerprint TLS i HTTP/2, zgodny z Chrome.

from curl_cffi import requests

# ProxyHat residential proxy — ustaw swoje dane logowania z dashboard.proxyhat.com
PROXY_URL = "http://user-country-US:YOUR_PASSWORD@gate.proxyhat.com:8080"

# curl_cffi z impersonate="chrome" wysyła spójny fingerprint TLS i HTTP/2
# odpowiadający prawdziwej przeglądarce Chrome
session = requests.Session(impersonate="chrome")

response = session.get(
    "https://httpbin.org/headers",
    proxies={"https": PROXY_URL, "http": PROXY_URL},
    timeout=30
)

print(f"Status: {response.status_code}")
print(f"Headers: {response.json()}")

Dla żądań wymagających sesji sticky (ten sam IP dla wielu żądań), użyj flagi session:

from curl_cffi import requests

# Sticky session — ten sam IP dla wszystkich żądań w sesji
PROXY_URL = "http://user-country-US-session-mytask123:YOUR_PASSWORD@gate.proxyhat.com:8080"

session = requests.Session(impersonate="chrome")

# Wszystkie żądania w tej sesji wychodzą z tego samego IP
for url in ["https://example.com/page1", "https://example.com/page2"]:
    response = session.get(url, proxies={"https": PROXY_URL, "http": PROXY_URL})
    print(f"{url}: {response.status_code}")

Dla geo-targetowania na poziomie miasta:

from curl_cffi import requests

# Geo-targeting: Berlin, Niemcy
PROXY_URL = "http://user-country-DE-city-berlin:YOUR_PASSWORD@gate.proxyhat.com:8080"

session = requests.Session(impersonate="chrome")
response = session.get(
    "https://ipinfo.io/json",
    proxies={"https": PROXY_URL, "http": PROXY_URL}
)
print(response.json())

Jeśli wolisz SOCKS5, ProxyHat oferuje port 1080:

from curl_cffi import requests

# SOCKS5 proxy
PROXY_URL = "socks5://user-country-US:YOUR_PASSWORD@gate.proxyhat.com:1080"

session = requests.Session(impersonate="chrome")
response = session.get(
    "https://httpbin.org/ip",
    proxies={"https": PROXY_URL, "http": PROXY_URL}
)
print(response.json())

Weryfikacja fingerprintu

Zanim uruchomisz scraping na produkcji, zweryfikuj swój fingerprint. Użyj endpointu takiego jak https://tls.peet.ws/api/all, który zwraca Twój JA3, JA4 i akamai h2 fingerprint:

from curl_cffi import requests

PROXY_URL = "http://user-country-US:YOUR_PASSWORD@gate.proxyhat.com:8080"
session = requests.Session(impersonate="chrome")

response = session.get(
    "https://tls.peet.ws/api/all",
    proxies={"https": PROXY_URL, "http": PROXY_URL}
)
data = response.json()

print(f"JA4: {data.get('tls', {}).get('ja4', 'N/A')}")
print(f"Akamai h2: {data.get('http2', {}).get('akamai_fingerprint', 'N/A')}")
print(f"Pseudo-header order: {data.get('http2', {}).get('pseudo_header_order', 'N/A')}")

Spodziewaj się wartości takich jak 1:65536;2:0;3:1000;4:6291456;6:262144|15663105|0|m,a,s,p dla akamai h2 fingerprint, co potwierdza, że Twój klient wysyła spójny fingerprint Chrome.

Typowe błędy i przypadki brzegowe

Błąd 1: Mieszanie curl_cffi z httpx

Niektórzy inżynierowie używają curl_cffi dla TLS fingerprint, ale potem przełączają się na httpx dla wygody API. To nie działa — httpx ma swój własny stos HTTP/2, który wysyła własną ramkę SETTINGS z wartościami domyślnymi. Używaj curl_cffi przez cały czas trwania sesji.

Błąd 2: Nieaktualny impersonate target

Chrome aktualizuje swoje parametry SETTINGS między wersjami. curl_cffi obsługuje wiele wersji — upewnij się, że używasz najnowszej. Jeśli celujesz w Chrome 148, ale curl_cffi wysyła fingerprint Chrome 116, system anti-bot może to wykryć jako anomalię wersji.

Błąd 3: Brak WINDOW_UPDATE

Niektóre implementacje pomijają ramkę WINDOW_UPDATE, ponieważ RFC nie wymaga jej wysłania. Ale Chrome zawsze ją wysyła. Jej brak jest silnym sygnałem automatyzacji, porównywalnym z brakiem ramki priorytetyzacji.

Błąd 4: Niezgodność User-Agent z fingerprintem

Jeśli Twój fingerprint HTTP/2 mówi Chrome, ale Twój User-Agent mówi Firefox, system anti-bot natychmiast to wykrywa. Upewnij się, że User-Agent, JA3/JA4 i h2 fingerprint wszystkie wskazują na tę samą przeglądarkę i tę samą wersję.

Błąd 5: Ignorowanie nagłówków drugorzędnych

Nawet przy spójnym fingerprintie HTTP/2, kolejność nagłówków HTTP (nie pseudo-nagłówków) jest również analizowana. Chrome wysyła nagłówki w specyficznej kolejności: sec-ch-ua, sec-ch-ua-mobile, sec-ch-ua-platform, upgrade-insecure-requests, user-agent, accept. Jeśli Twoja kolejność się różni, to jest kolejny sygnał. curl_cffi z impersonate obsługuje to automatycznie.

Odpowiedzialne użycie: legalne monitorowanie i badania bezpieczeństwa

Fingerprinting HTTP/2 i proxy residential to potężne narzędzia, ale muszą być używane odpowiedzialnie. Oto zasady, których powinieneś przestrzegać:

• Autoryzowane monitorowanie — scraping cen, SERP tracking i monitorowanie dostępności są legalne, gdy są wykonywane na danych publicznie dostępnych bez naruszania ToS. Dowiedz się więcej o SERP tracking i web scrapingu z ProxyHat.
• Badania bezpieczeństwa — autoryzowane pentesty i badania podatności wymagają pisemnej zgody właściciela systemu.
• Przestrzeganie robots.txt — zawsze sprawdzaj robots.txt przed scrapingiem i respektuj jego dyrektywy.
• GDPR i CCPA — jeśli scrapujesz dane osobowe, musisz przestrzegać odpowiednich przepisów ochrony danych. W UE, GDPR wymaga podstawy prawnej dla przetwarzania danych osobowych. W Kalifornii, CCPA nakłada podobne obowiązki.
• CFAA — w USA, Computer Fraud and Abuse Act może mieć zastosowanie do scrapingu, który omija mechanizmy autoryzacji. Skonsultuj się z prawnikiem, jeśli nie jesteś pewien statusu prawnego swojej działalności.

Nigdy nie używaj tych technik do oszustw, omijania płatności, kradzieży danych ani żadnej działalności, która narusza prawa innych. ProxyHat nie toleruje nadużyć — zapoznaj się z naszą dokumentacją na docs.proxyhat.com.

Najważniejsze wnioski

• HTTP/2 fingerprinting analizuje ramkę SETTINGS (h2 settings frame), WINDOW_UPDATE, priorytety strumieni i kolejność pseudo-nagłówków — zanim jakikolwiek HTML zostanie przesłany.
• Akamai h2 fingerprint i JA4H fingerprint kodują te sygnały w kompaktowy string, który jednoznacznie identyfikuje klienta z dokładnością do wersji.
• Mismatch TLS-h2 (np. JA4 Chrome + HEADER_TABLE_SIZE 4096 zamiast 65536) skutkuje maksymalnym bot score przed załadowaniem strony.
• Tylko curl_cffi z impersonate wysyła spójny fingerprint Chrome w warstwach TLS i HTTP/2 w Pythonie.
• Proxy residential jest nadal wymagane — fingerprinting protokołu sam nie wystarczy, bo reputacja IP jest niezależnym sygnałem scoringowym.
• Zawsze przestrzegaj robots.txt, ToS i przepisów ochrony danych (GDPR, CCPA, CFAA).