Fingerprinting HTTP/2 wyjaśniony: Jak protokół zdradza automatyzację w 2026

Fingerprinting HTTP/2 wyjaśniony to dziś jedna z najważniejszych barier dla inżynierów scraping i badaczy bezpieczeństwa. W 2026 roku zaawansowane systemy anti-bot nie czekają, aż Twój kod pobierze HTML — analizują ramki protokołu HTTP/2 i HTTP/3 już w pierwszych 100 ms połączenia. Jeśli Twój klient wysyła HEADER_TABLE_SIZE 4096 zamiast 65536, podczas gdy sygnatura TLS (JA4) twierdzi, że jesteś Chrome 148, system anti-bot nada Ci maksymalny wynik bota zanim jakikolwiek JavaScript zostanie wykonany.

Ten artykuł to techniczny deep-dive dla inżynierów, którzy rozumieją już JA3/JA4 i chcą poznać kolejną warstwę detekcji: fingerprinting na poziomie protokołu H2/H3. Pokażemy, jak prezentować spójny fingerprint przeglądarki, jak łączyć go z odpowiednimi proxy residentyjnymi i jak unikać najczęstszych pułapek implementacyjnych.

Co jest fingerprintowane w HTTP/2: Ramka SETTINGS i nie tylko

Fingerprinting HTTP/2 opiera się na analizie kilku kluczowych ramek i ich parametrów, które każdy klient wysyła podczas nawiązywania połączenia. W przeciwieństwie do fingerprintingu TLS (JA3/JA4), który analizuje ClientHello, fingerprinting H2 analizuje to, co dzieje się po ustanowieniu tunelu TLS — w warstwie aplikacji protokołu HTTP/2.

Ramka SETTINGS

Po nawiązaniu połączenia HTTP/2 klient i serwer wymieniają ramki SETTINGS. Klient wysyła zestaw parametrów konfiguracyjnych, które definiują, jak chce obsługiwać połączenie. Sześć kluczowych wartości tworzy podstawowy fingerprint:

• HEADER_TABLE_SIZE — rozmiar tabeli kompresji nagłówków HPACK. Chrome 148 ustawia 65536, Firefox ustawia 65536, ale httpx domyślnie wysyła 4096. Ta jedna wartość jest natychmiastowym sygnałem automatyzacji.
• ENABLE_PUSH — czy klient akceptuje server push. Chrome wysyła 0 (wyłączone od wersji 88), niektóre biblioteki wysyłają 1 lub pomijają ten parametr.
• MAX_CONCURRENT_STREAMS — maksymalna liczba jednoczesnych strumieni. Chrome ustawia 1000, httpx wysyła 100 lub nie wysyła wcale.
• INITIAL_WINDOW_SIZE — początkowy rozmiar okna kontroli przepływu. Chrome: 6291456 (6 MB), httpx: 33554432 (32 MB) lub 65535.
• MAX_FRAME_SIZE — maksymalny rozmiar ramki. Chrome: 16384, niektórzy klienci: 4194304.
• MAX_HEADER_LIST_SIZE — maksymalna długość listy nagłówków. Chrome wysyła 262144 (256 KB).

Kolejność tych parametrów w ramce SETTINGS jest również istotna. Chrome zawsze wysyła je w określonej kolejności, a biblioteki programistyczne często używają innej. Serwery anti-bot porównują nie tylko wartości, ale i kolejność.

WINDOW_UPDATE

Po ramce SETTINGS klient wysyła WINDOW_UPDATE, które zwiększa rozmiar okna kontroli przepływu dla całego połączenia. Chrome wysyła WINDOW_UPDATE z wartością 15663105 (co daje łączne okno ~16 MB). httpx i inne biblioteki wysyłają inne wartości lub pomijają tę ramkę. To kolejny punkt różnicowania.

Priorytety strumieni (Stream Priority)

HTTP/2 pozwala klientowi określić priorytety strumieni za pomocą ramek PRIORITY. Chrome 148 wysyła specyficzny wzorzec priorytetów dla pierwszych strumieni (np. strumień 0 dla CSS, strumień 1 dla głównego zasobu). Kolejność i zależności priorytetów są reproducible dla danej wersji przeglądarki, ale różnią się między bibliotekami. Akamai i Cloudflare analizują te wzorce jako część fingerprintu H2.

W HTTP/3 (QUIC) priorytety zostały uproszczone do schematu urgency i incremental, ale zasada pozostaje ta sama — wzorzec jest charakterystyczny dla klienta.

Kolejność pseudo-nagłówków (Pseudo-header Order)

HTTP/2 wymaga czterech pseudo-nagłówków: :method, :authority, :scheme, :path. Kolejność, w jakiej klient wysyła te nagłówki, jest częścią fingerprintu. Chrome używa kolejności m,a,s,p (method, authority, scheme, path), podczas gdy httpx używa m,p,s,a lub innej. To zaledwie cztery wartości, ale tworzą silny sygnał.

Kompaktowy fingerprint Akamai

Akamai popularized format kompaktowego ciągu znaków dla fingerprintu H2, który łączy wszystkie powyższe sygnały w jedną wartość. Format wygląda mniej więcej tak:

2:0:0:0:1:0:0:0:0;0;0;0;m,a,s,p

Pierwsza sekcja (przed średnikiem) koduje wartości SETTINGS w kolejności: HEADER_TABLE_SIZE:ENABLE_PUSH:MAX_CONCURRENT_STREAMS:INITIAL_WINDOW_SIZE:MAX_FRAME_SIZE:MAX_HEADER_LIST_SIZE:.... Druga sekcja koduje WINDOW_UPDATE. Trzecia sekcja koduje priorytety. Czwarta sekcja to kolejność pseudo-nagłówków.

Ten ciąg jest porównywany z bazą znanych fingerprintów przeglądarek. Jeśli nie pasuje do żadnej znanej wersji Chrome, Firefox czy Safari — jesteś oznaczony jako bot.

JA4H — ujednolicony fingerprint HTTP

JA4H to rozszerzenie specyfikacji JA4 na warstwę HTTP. Format JA4H łączy sygnały z nagłówków HTTP, kolejności nagłówków, ciasteczek i ustawień HTTP/2 w jeden ciąg znaków. Struktura wygląda następująco:

ge11nn13enus_000000000000_000000000000_000000000000

Gdzie ge to metoda i wersja protokołu (GET, HTTP/2), 11 to liczba nagłówków, nn to liczba ciasteczek, 13 to liczba parametrów zapytania. Kolejne sekcje kodują hashe nagłówków, ciasteczek i parametrów. JA4H jest coraz częściej używane przez WAF-y i systemy anti-bot jako uzupełnienie JA4 (TLS).

Dlaczego niezgodność JA4 i H2 to natychmiastowy wynik bota

Rozważmy konkretny scenariusz: używasz biblioteki httpx z modyfikacją TLS, która emuluje ClientHello Chrome 148. Twój JA4 to t13d1516h2_8daaf6152771_b1864e6f5b27 — idealnie pasujący do Chrome. Serwer widzi to i myśli: „OK, to Chrome 148 na Windows 11".

Potem klient wysyła ramkę SETTINGS:

SETTINGS
  HEADER_TABLE_SIZE: 4096
  ENABLE_PUSH: 1
  MAX_CONCURRENT_STREAMS: 100
  INITIAL_WINDOW_SIZE: 33554432

Chrome 148 nigdy nie wysłałby takich wartości. Chrome wysyła HEADER_TABLE_SIZE: 65536, ENABLE_PUSH: 0, MAX_CONCURRENT_STREAMS: 1000, INITIAL_WINDOW_SIZE: 6291456. Serwer anti-bot natychmiast zauważa sprzeczność: TLS twierdzi Chrome, ale H2 mówi httpx. To jest kategoria natychmiastowej flagi — wynik bota jest maksymalny zanim jakikolwiek bajt HTML zostanie przesłany.

Kluczowa zasada: fingerprint TLS i fingerprint H2 muszą opisywać tego samego klienta. Jeśli JA4 mówi Chrome, a H2 mówi httpx — nie ma znaczenia, jak dobre jest Twoje emulowanie TLS. Jesteś oznaczony.

Którzy klienci Python/Node leakują niezgodne ramki

Oto porównanie popularnych bibliotek HTTP i ich domyślnych sygnałów H2:

Biblioteka	HEADER_TABLE_SIZE	ENABLE_PUSH	MAX_CONCURRENT_STREAMS	Pseudo-header order	Spójność z JA4
httpx (Python)	4096	1	100	m,p,s,a	Nie
requests (Python)	N/A (H1)	N/A	N/A	N/A	N/A
aiohttp (Python)	4096	0	brak	m,p,s,a	Nie
curl_cffi (Python)	65536	0	1000	m,a,s,p	Tak (impersonate)
got (Node.js)	4096	1	100	m,p,s,a	Nie
undici (Node.js)	65536	0	100	m,a,s,p	Częściowo
Playwright (Chromium)	65536	0	1000	m,a,s,p	Tak (prawdziwa przeglądarka)

curl_cffi wyróżnia się, ponieważ używa natywnego silnika TLS BoringSSL (tego samego, co Chrome) i emuluje pełny fingerprint H2 poprzez funkcję impersonate. To czyni go najlepszym wyborem dla programowego emulowania przeglądarki bez uruchamiania pełnej przeglądarki.

TLS i HTTP/2 muszą się zgadzać: Teoria i praktyka zgodności

Zgodność fingerprintów TLS i H2 to nie tylko dopasowanie wartości — to dopasowanie całej historii połączenia. Oto jak wyglądają warstwy, które serwer anti-bot analizuje sekwencyjnie:

1. Warstwa 1: TCP/IP — adres IP, TTL, rozmiar okna TCP. Adresy z zakresów datacenter są natychmiast flagowane.
2. Warstwa 2: TLS (JA3/JA4) — ClientHello, lista szyfrów, rozszerzenia, krzywe eliptyczne. Określa, jaki klient twierdzi, że jest.
3. Warstwa 3: ALPN + H2 SETTINGS — protokół negocjowany i parametry H2. Muszą być spójne z TLS.
4. Warstwa 4: Nagłówki HTTP — User-Agent, Accept-Language, sec-ch-ua. Muszą być spójne z TLS i H2.
5. Warstwa 5: JavaScript / Canvas / WebGL — fingerprint przeglądarki po załadowaniu strony.

Każda warstwa jest sprawdzana pod kątem spójności z warstwami powyżej i poniżej. Jeśli warstwa 2 mówi Chrome, a warstwa 3 mówi httpx — niezgodność. Jeśli warstwa 4 mówi Chrome 148, a warstwa 2 mówi JA4 Firefox — niezgodność.

Według RFC 9113 (specyfikacja HTTP/2), kolejność pseudo-nagłówków nie jest arbitralna — :method musi być pierwszy, a :path i :scheme są obowiązkowe. Ale :authority może pojawić się w różnej pozycji. Przeglądarki ustaliły de facto standard m,a,s,p, a biblioteki programistyczne często używają m,p,s,a. Ta różnica jest detekowalna.

ALPN jako pierwszy sygnał

Nawet zanim ramka SETTINGS zostanie wysłana, ALPN (Application-Layer Protocol Negotiation) w TLS już sygnalizuje intencje. Chrome wysyła h2,http/1.1 w tej kolejności. Niektóre biblioteki wysyłają tylko h2 lub http/1.1. To jest pierwszy punkt kontroli spójności.

Dlaczego proxy residentyjne są nadal wymagane

Nawet jeśli perfekcyjnie emulujesz TLS i H2 — z ramką SETTINGS, WINDOW_UPDATE, priorytetami i pseudo-nagłówkami idealnie pasującymi do Chrome 148 — to wszystko jest bezużyteczne, jeśli Twój adres IP to 34.x.x.x (Google Cloud) lub 52.x.x.x (AWS). Systemy anti-bot przypisują wynik reputacji IP niezależnie od fingerprintu protokołu.

Wynik bota to funkcja co najmniej trzech zmiennych:

bot_score = f(ip_reputation, protocol_fingerprint, behavioral_signals)

Jeśli ip_reputation jest niski (datacenter, VPN, Tor), to nawet idealny protocol_fingerprint nie pomoże — łączny wynik przekracza próg. To dlatego proxy residentyjne są niezbędne: podnoszą ip_reputation do poziomu, który w połączeniu z dobrym fingerprintem protokołu daje wynik poniżej progu detekcji.

Dane z ProxyHat pokazują, że adresy IP z sieci residentyjnych mają wskaźnik sukcesu o 40–60% wyższy przy scraping chronionych stron w porównaniu do adresów datacenter, przy tym samym fingerprint protokołu. Sprawdź naszą listę lokalizacji proxy, aby zobaczyć dostępne geograficzne pule residentyjne.

Rotacja IP a sesje sticky

Rotacja IP na każde żądanie zwiększa anonimowość, ale może być sygnałem sama w sobie — prawdziwy użytkownik nie zmienia IP co 200 ms. Lepiej używać sesji sticky (sticky sessions) przez 10–30 minut, co symuluje naturalne zachowanie przeglądarki. ProxyHat obsługuje sesje sticky przez flagę session w nazwie użytkownika.

Implementacja: curl_cffi przez ProxyHat z fingerprintem Chrome H2

Poniżej znajduje się kompletny, działający przykład w Pythonie, który łączy curl_cffi (emulujący fingerprint Chrome 148 TLS + H2) z proxy residentyjnym ProxyHat. To podejście zapewnia spójność na wszystkich warstwach: TLS, H2, nagłówki HTTP i adres IP.

from curl_cffi import requests

# Konfiguracja proxy ProxyHat — residential, USA, sesja sticky
proxy_user = "user-country-US-session-myresearch01"
proxy_pass = "TWOJE_HASLO"
proxy_url = f"http://{proxy_user}:{proxy_pass}@gate.proxyhat.com:8080"

proxies = {
    "http": proxy_url,
    "https": proxy_url,
}

# Nagłówki zgodne z Chrome 148 na Windows 11
headers = {
    "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,"
              "image/avif,image/webp,image/apng,*/*;q=0.8",
    "accept-language": "en-US,en;q=0.9",
    "accept-encoding": "gzip, deflate, br, zstd",
    "sec-ch-ua": '"Chromium";v="148", "Not?A_Brand";v="24", '
                 '"Google Chrome";v="148"',
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": '"Windows"',
    "sec-fetch-dest": "document",
    "sec-fetch-mode": "navigate",
    "sec-fetch-site": "none",
    "sec-fetch-user": "?1",
    "upgrade-insecure-requests": "1",
    "user-agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/148.0.0.0 Safari/537.36",
}

# impersonate="chrome" emuluje pełny fingerprint TLS + H2 Chrome
response = requests.get(
    "https://httpbin.org/headers",
    headers=headers,
    proxies=proxies,
    impersonate="chrome",
    timeout=30,
)

print(f"Status: {response.status_code}")
print(f"Response headers: {dict(response.headers)}")
print(response.json())

Kluczowe elementy tego kodu:

• impersonate="chrome" — curl_cffi automatycznie ustawia JA4, ALPN, SETTINGS H2, WINDOW_UPDATE i pseudo-header order zgodne z najnowszą wersją Chrome.
• gate.proxyhat.com:8080 — brama HTTP ProxyHat. Proxy residentyjny zapewnia adres IP z puli domowych ISP.
• user-country-US-session-myresearch01 — geo-targetowanie na USA + sesja sticky (ten sam IP dla wszystkich żądań w sesji).
• Nagłówki sec-ch-ua i sec-fetch-* są zgodne z Chrome 148 — nie można ich pominąć, bo ich brak jest kolejnym sygnałem automatyzacji.

Weryfikacja fingerprintu

Aby zweryfikować, czy Twój fingerprint H2 jest spójny, użyj serwisu takiego jak BrowserLeaks TLS lub narzędzia akamai-h2-fingerprint. Powinieneś zobaczyć fingerprint H2 pasujący do Chrome, a nie do httpx czy aiohttp.

Wersja SOCKS5

Jeśli preferujesz SOCKS5 (np. dla lepszego wsparcia tunneling UDP w HTTP/3), użyj portu 1080:

proxy_url_socks5 = f"socks5://{proxy_user}:{proxy_pass}@gate.proxyhat.com:1080"

Alternatywa: Playwright przez ProxyHat

Dla maksymalnej wierności fingerprintu, użyj prawdziwej przeglądarki przez Playwright z proxy ProxyHat. To gwarantuje, że wszystkie warstwy — TLS, H2, JS, Canvas, WebGL — są spójne:

from playwright.sync_api import sync_playwright

proxy_config = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US-session-research02",
    "password": "TWOJE_HASLO",
}

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=True,
        proxy=proxy_config,
        args=["--disable-blink-features=AutomationControlled"],
    )
    context = browser.new_context(
        user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                   "AppleWebKit/537.36 (KHTML, like Gecko) "
                   "Chrome/148.0.0.0 Safari/537.36",
        viewport={"width": 1920, "height": 1080},
        locale="en-US",
    )
    page = context.new_page()
    page.goto("https://example.com", timeout=30000)
    content = page.content()
    print(f"Page length: {len(content)}")
    browser.close()

Playwright uruchamia prawdziwy Chromium, więc fingerprint H2 jest natywnie spójny. Proxy ProxyHat zapewnia adres IP residentyjny. To podejście jest cięższe (pamięć ~300 MB na instancję), ale daje najwyższy wskaźnik sukcesu. Więcej o zastosowaniach scraping przeczytasz na naszej stronie przypadków użycia web scraping.

Najczęstsze błędy i przypadki brzegowe

Błąd 1: Emulacja TLS bez emulacji H2

Najczęstszy błąd: programista konfiguruje JA4/JA3 przez modyfikację TLS, ale używa domyślnych ramek H2 z httpx lub aiohttp. Wynik: TLS mówi Chrome, H2 mówi httpx — natychmiastowa flaga.

Błąd 2: Niezgodne nagłówki sec-ch-ua

Nagłówek sec-ch-ua musi być zgodny z wersją Chrome w JA4 i w User-Agent. Jeśli JA4 mówi Chrome 148, a sec-ch-ua mówi v="120" — niezgodność.

Błąd 3: Brak WINDOW_UPDATE

Niektóre biblioteki pomijają ramkę WINDOW_UPDATE po SETTINGS. Chrome zawsze ją wysyła. Brak WINDOW_UPDATE jest sygnałem automatyzacji.

Błąd 4: Zbyt szybkie żądania

Nawet z idealnym fingerprintem, wysyłanie 50 żądań na sekundę z jednego IP jest nienaturalne. Ludzie potrzebują 2–5 sekund między żądaniami. Stosuj opóźnienia time.sleep(random.uniform(2, 5)) między żądaniami.

Błąd 5: Brak obsługi HTTP/3

W 2026 coraz więcej stron obsługuje HTTP/3 (QUIC). Jeśli Twój klient obsługuje tylko HTTP/2, a strona ogłasza HTTP/3 przez Alt-Svc, to brak upgrade'u może być sygnałem. curl_cffi i Playwright obsługują HTTP/3, ale wymaga to konfiguracji.

Błąd 6: Niespójna geolokalizacja IP i Accept-Language

Jeśli Twój proxy ProxyHat jest w Niemczech (country-DE), a Accept-Language to en-US, to niezgodność. Ustaw Accept-Language: de-DE,de;q=0.9,en;q=0.7 i użyj user-country-DE. Sprawdź dostępne lokalizacje, aby dopasować geo do języka.

Odpowiednie zastosowanie: Autoryzowane monitorowanie i badania bezpieczeństwa

Fingerprinting HTTP/2 i emulacja przeglądarki to narzędzia, które mogą służyć zarówno legalnym celom, jak i nadużyciom. ProxyHat promuje wyłącznie etyczne i legalne zastosowania:

• Autoryzowany scraping — zbieranie publicznie dostępnych danych z przestrzeganiem robots.txt i warunków serwisu.
• Badania bezpieczeństwa — testy penetracyjne z wyraźnym autoryzowaniem właściciela systemu.
• Monitorowanie SERP — śledzenie pozycji w wyszukiwarkach dla własnych domen. Zobacz naszą stronę śledzenia SERP.
• Badania rynkowe — agregacja publicznie dostępnych danych cenowych.

W Stanach Zjednoczonych Computer Fraud and Abuse Act (CFAA) kategoryzuje nieautoryzowany dostęp do systemów komputerowych jako przestępstwo federalne. Scraping z naruszeniem warunków serwisu może podlegać CFAA, zwłaszcza jeśli obejmuje omijanie barier technicznych (takich jak systemy anti-bot). W UE, RODO (GDPR) ogranicza przetwarzanie danych osobowych, w tym danych zebranych przez scraping, które mogą identyfikować osoby.

Złota zasada: jeśli nie masz wyraźnej autoryzacji lub danych są publicznie dostępne bez barier technicznych — nie scrapuj. Omijanie systemów anti-bot bez autoryzacji może być nielegalne, niezależnie od technicznej wykonalności.

Kluczowe wnioski

• Fingerprinting HTTP/2 analizuje ramkę SETTINGS, WINDOW_UPDATE, priorytety strumieni i kolejność pseudo-nagłówków — wszystkie te sygnały są wysyłane zanim HTML zostanie pobrany.
• Spójność między JA4 (TLS) i fingerprintem H2 jest krytyczna. Jeśli TLS mówi Chrome, a H2 mówi httpx — natychmiastowy wynik bota.
• curl_cffi z impersonate="chrome" jest najlepszą biblioteką programową do emulowania spójnego fingerprintu Chrome TLS + H2.
• Proxy residentyjne są niezbędne — perfekcyjny fingerprint protokołu z adresu datacenter nadal zostanie oflagowany przez reputację IP.
• ProxyHat zapewnia adresy residentyjne przez gate.proxyhat.com:8080 z geo-targetowaniem i sesjami sticky w nazwie użytkownika.
• Używaj tych technik wyłącznie do autoryzowanego monitorowania, badań bezpieczeństwa i legalnego scrapingu publicznych danych.

Gotowy, aby zacząć? Sprawdź naszą stronę cennika i wybierz pakiet proxy residentyjnych odpowiedni dla Twoich potrzeb. Pełną dokumentację techniczną znajdziesz w dokumentacji ProxyHat.

FAQ

Czym jest fingerprinting HTTP/2?

Fingerprinting HTTP/2 to technika identyfikacji klienta HTTP na podstawie parametrów protokołu H2 wysyłanych w ramce SETTINGS, ramce WINDOW_UPDATE, priorytetach strumieni i kolejności pseudo-nagłówków. Każda przeglądarka wysyła te wartości w charakterystyczny, powtarzalny sposób, co pozwala serwerom rozróżniać prawdziwe przeglądarki od bibliotek programistycznych takich jak httpx czy aiohttp. Akamai popularized format kompaktowego ciągu znaków łączącego wszystkie te sygnały.

Dlaczego fingerprinting HTTP/2 ma znaczenie dla użytkowników proxy?

Nawet z idealnym proxy residentyjnym, jeśli Twój klient HTTP wysyła ramkę SETTINGS niezgodną z przeglądarką (np. HEADER_TABLE_SIZE 4096 zamiast 65536), system anti-bot natychmiast oznacza żądanie jako automatyczne. Proxy ukrywa adres IP, ale fingerprint H2 zdradza typ klienta. Dlatego proxy i emulacja fingerprintu muszą być stosowane razem — jedno bez drugiego nie wystarcza.

Który typ proxy działa najlepiej przy fingerprintingu HTTP/2?

Proxy residentyjne są najlepsze, ponieważ zapewniają adresy IP z puli domowych ISP, które mają wysoką reputację w systemach anti-bot. Proxy datacenter, nawet z perfekcyjnym fingerprintem H2, są często oflagowane ze względu na niską reputację IP. Proxy mobilne są jeszcze lepsze dla zastosowań wymagających maksymalnej wiarygodności, ale są droższe i mają wyższe opóźnienia.

Jak unikać blokad przy implementacji fingerprintingu HTTP/2?

Używaj biblioteki curl_cffi z impersonate="chrome" przez proxy residentyjne ProxyHat (gate.proxyhat.com:8080), ustawiaj sesje sticky na 10–30 minut, stosuj opóźnienia 2–5 sekund między żądaniami, dbaj o zgodność nagłówków sec-ch-ua z wersją Chrome w JA4, i dopasuj geolokalizację proxy do nagłówka Accept-Language. Nigdy nie wysyłaj więcej niż 5–10 żądań na sekundę z jednej sesji.

Czy fingerprinting HTTP/3 (QUIC) różni się od HTTP/2?

Tak. HTTP/3 używa QUIC (UDP) zamiast TCP, a fingerprinting obejmuje dodatkowo parametry transportu QUIC. Priorytety strumieni zostały uproszczone do schematu urgency/incremental. Zasada pozostaje jednak ta sama: parametry protokołu są charakterystyczne dla klienta i muszą być spójne z fingerprintem TLS (w QUIC — z certyfikatem i parametrami handshake QUIC). curl_cffi z impersonate obsługuje również HTTP/3.