HTTP/2 Fingerprinting erklärt: Protokoll-Signaturen erkennen und konsistent halten

HTTP/2 Fingerprinting erklärt: Was Anti-Bot-Systeme auf Protokollebene sehen

Wenn ein HTTP-Client die erste Verbindung zu einem geschützten Server aufbaut, trifft eine Entscheidung in Millisekunden statt — lange bevor HTML geladen wird. Moderne Anti-Bot-Systeme wie Akamai Bot Manager, Cloudflare Bot Management und DataDome kombinieren TLS-Fingerprints (JA3/JA4) mit HTTP/2-Protokoll-Signalen, um einen Bot-Score zu berechnen. Ein Client, dessen TLS-Handshake als Chrome 148 aussieht, aber im HTTP/2 SETTINGS-Frame einen HEADER_TABLE_SIZE von 4096 sendet, wird mit maximaler Bot-Wahrscheinlichkeit eingestuft. Dieser Artikel erklärt, wie HTTP/2 Fingerprinting funktioniert, welche Signale erfasst werden und wie Sie einen browser-konsistenten Fingerprint mit residentiellen Proxies kombinieren.

Die Grundlagen des h2 SETTINGS Frame

HTTP/2 beginnt jede Verbindung mit einem SETTINGS-Frame, in dem der Client seine Betriebsparameter bekanntgibt. Anti-Bot-Vendors zeichnen die Reihenfolge und Werte dieser Parameter auf und vergleichen sie mit bekannten Browser-Profilen. Die wichtigsten Felder sind:

• HEADER_TABLE_SIZE (0x01): Maximale Größe der HPACK-Header-Tabelle. Chrome verwendet typischerweise 65536, Firefox 65536, httpx defaultet auf 4096.
• ENABLE_PUSH (0x02): Server-Push aktivieren (0 oder 1). Chrome sendet 0.
• MAX_CONCURRENT_STREAMS (0x03): Maximale gleichzeitige Streams. Chrome sendet 1000, Firefox 1000.
• INITIAL_WINDOW_SIZE (0x04): Anfangs-Fenstergröße für Flow Control. Chrome sendet 6291456, Firefox 131072.
• MAX_FRAME_SIZE (0x05): Maximale Frame-Payload-Größe. Chrome sendet 16384.
• MAX_HEADER_LIST_SIZE (0x06): Maximale Header-Listengröße. Chrome sendet 262144.

Die Reihenfolge, in der diese Felder gesendet werden, ist browserspezifisch. Chrome sendet sie in einer anderen Sequenz als Firefox oder Safari. Die RFC 9113 schreibt keine verbindliche Reihenfolge vor, weshalb jeder Client sie frei wählen kann — und genau diese Freiheit erzeugt unterscheidbare Fingerprints.

Akamai HTTP/2 Fingerprint und JA4H

Akamai war der erste große Vendor, der einen kompakten h2 Fingerprint-String einführte. Dieser String kodiert die SETTINGS-Parameter, WINDOW_UPDATE-Werte und die Pseudo-Header-Reihenfolge in einem durch Trennzeichen separierten Format. Ein typischer Chrome-String sieht so aus:

1:65536;2:0;4:6291456;5:16384;6:262144

Dieser String repräsentiert die SETTINGS-Frame-Inhalte: Feld 1 (HEADER_TABLE_SIZE) = 65536, Feld 2 (ENABLE_PUSH) = 0, Feld 4 (INITIAL_WINDOW_SIZE) = 6291456, Feld 5 (MAX_FRAME_SIZE) = 16384, Feld 6 (MAX_HEADER_LIST_SIZE) = 262144. Fehlende Felder (wie Feld 3, MAX_CONCURRENT_STREAMS) werden weggelassen, was ebenfalls ein Signal ist.

Das JA4H-Fingerprint-Format, entwickelt von FoxIO als Teil der JA4-Familie, erweitert diesen Ansatz um eine strukturierte Hash-basierte Darstellung. JA4H kombiniert HTTP-Methode, HTTP-Version, Header-Reihenfolge und Akamai-h2-String in einem einheitlichen Format. Die Spezifikation ist auf GitHub dokumentiert und wird zunehmend von WAFs und SIEM-Systemen als Klassifikationsmerkmal verwendet.

Warum ein mismatched h2 Frame den Bot-Score maximiert

Stellen Sie sich folgendes Szenario vor: Ein Scraper verwendet tls-client oder curl_cffi, um einen Chrome-JA3-Fingerprint zu emulieren. Der TLS-Handshake sieht aus wie Chrome 148 auf Windows 11. Aber die HTTP-Bibliothek darunter (z. B. httpx oder h2) sendet ihre eigenen Standard-SETTINGS.

RFC 9113 definiert HTTP/2, aber die Bibliotheken, die es implementieren, haben eigene Defaults. httpx mit dem h2-Backend sendet typischerweise:

• HEADER_TABLE_SIZE = 4096 (statt Chrome's 65536)
• INITIAL_WINDOW_SIZE = 65535 (statt Chrome's 6291456)
• MAX_CONCURRENT_STREAMS = 100 (statt Chrome's 1000)
• MAX_FRAME_SIZE = 16384 (gleicht zufällig mit Chrome überein)

Das Anti-Bot-System sieht: TLS sagt Chrome, h2 sagt Python-Bibliothek. Das ist ein Korrelationsbruch. Die Wahrscheinlichkeit, dass ein echter Chrome-Browser einen h2-Frame sendet, der httpx entspricht, liegt bei praktisch null. Der Bot-Score springt auf den Maximalwert, noch bevor der Server eine einzige HTML-Zeile zurückgibt.

Ein korrekter TLS-Fingerprint allein reicht nicht aus. Anti-Bot-Systeme kreuzvalidieren TLS-Signaturen gegen HTTP/2-Settings und Pseudo-Header-Reihenfolge. Ein einzelnes abweichendes Feld reicht aus, um die Verbindung zu flaggen.

Pseudo-Header-Reihenfolge: m,a,s,p vs. p,m,a,s

HTTP/2 verwendet Pseudo-Header (:method, :authority, :scheme, :path), die vor den regulären Headern gesendet werden. Die Reihenfolge ist browserspezifisch:

• Chrome: :method, :authority, :scheme, :path (m,a,s,p)
• Firefox: :method, :path, :scheme, :authority (m,p,s,a)
• Safari: :method, :scheme, :authority, :path (m,s,a,p)

Python-Bibliotheken wie httpx senden häufig :authority nicht korrekt oder in der falschen Reihenfolge. Der h2-Default ist oft :method, :path, :scheme, :authority — was keinem echten Browser entspricht. Ein Bot-Detektor vergleicht diese Reihenfolge gegen eine Datenbank und kann die Bibliothek in < 5 ms identifizieren.

WINDOW_UPDATE und Stream-Priorität als zusätzliche Signale

Neben dem SETTINGS-Frame sendet der Client nach dem Connection Preface ein WINDOW_UPDATE-Frame, das die Flow-Control-Fenstergröße anpasst. Chrome sendet typischerweise ein WINDOW_UPDATE mit einem Increment von 15663105 für Connection-Level und 15663105 für Stream-Level. httpx sendet oft gar kein WINDOW_UPDATE oder einen anderen Wert.

Die Stream-Priorität (Priority Frames und HEADERS-Frame Priority-Flags) war in HTTP/2 ursprünglich als komplexes Abhängigkeitsbaum-Modell konzipiert. Chrome 148 hat sich dem vereinfachten Modell angenähert, das in RFC 9218 beschrieben wird. Die Priority-Signale umfassen:

• PRIORITY Frame: Weight-Werte zwischen 1 und 256
• HEADERS Frame Priority: Stream-Dependency und Weight
• PRIORITY_UPDATE Frame: Urgency (0-7) und Incremental

Ein Client, der keine Priority-Frames sendet oder falsche Weight-Werte verwendet, ist ein weiteres Erkennungsmerkmal. Die meisten Python-Bibliotheken ignorieren Stream-Priorität vollständig.

TLS (JA3/JA4) und HTTP/2 müssen übereinstimmen

Der JA3-Fingerprint hasht die TLS-ClientHello-Parameter: TLS-Version, Cipher-Suites, Extensions, Elliptic Curves und Elliptic Curve Point Formats. JA4 ist die neuere, strukturierte Version, die das Format q13d1512h2_... verwendet, wobei q für QUIC/DTLS steht, 13 für TLS 1.3, d für den SNI-Typ und die nachfolgenden Segmente Cipher- und Extension-Listen kodieren.

Die kritische Erkenntnis: JA3/JA4 und HTTP/2-Fingerprint müssen zum gleichen Browser-Profil gehören. Ein Client, der Chrome's JA3 sendet, aber Firefox's h2 SETTINGS, ist sofort verdächtig. Die folgende Tabelle zeigt, welche Kombinationen funktionieren und welche sofort erkannt werden:

Welche Python/Node-Clients leaken mismatched Frames?

httpx mit dem Standard h2-Backend ist der häufigste Übeltäter. Es verwendet die h2-Bibliothek von Python-hyper, die ihre eigenen Defaults sendet, die keinem Browser entsprechen. aiohttp hat ähnliche Probleme — es sendet HTTP/2-Settings, die von der zugrundeliegenden h2-Bibliothek geerbt werden.

Node.js-Clients wie got mit HTTP/2-Unterstützung oder node-fetch verwenden die native http2-Bibliothek, die wiederum eigene SETTINGS sendet. Die Node.js http2-Implementation sendet HEADER_TABLE_SIZE 4096 und INITIAL_WINDOW_SIZE 65535 — identisch mit httpx und damit sofort erkennbar.

curl_cffi ist die Ausnahme: Es verwendet die tatsächliche BoringSSL/Curl-Implementation und kann Chrome's h2-Settings und TLS-Handshake gemeinsam emulieren. Das ist der primäre Grund, warum es bei Scraping-Engineers beliebt ist.

Warum residentielle Proxies trotzdem erforderlich sind

Selbst wenn Ihr h2-Fingerprint perfekt mit Chrome 148 übereinstimmt und Ihr JA3 korrekt ist, reicht das nicht aus. Anti-Bot-Systeme bewerten auch die IP-Reputation. Ein Datencenter-IP-Block von AWS, DigitalOcean oder Hetzner wird mit einem Basis-Bot-Score von 50-70 von 100 starten, bevor überhaupt Protokoll-Signale ausgewertet werden.

Residentielle Proxies bieten IPs, die von ISPs an echte Haushalte vergeben wurden. Die IP-Reputation ist neutral bis positiv, weil die Anti-Bot-Vendors diese IPs nicht als Datencenter-Traffic klassifizieren. Die Kombination aus kohärentem Protokoll-Fingerprint und residentialer IP ergibt den niedrigsten Bot-Score.

Mobile Proxies sind noch besser geeignet, weil sie aus Carrier-IP-Ranges stammen und von Anti-Bot-Systemen die höchste Vertrauensstufe erhalten. Für die meisten Use-Cases sind jedoch residentielle Proxies ausreichend und kosteneffizienter.

Praktische Implementierung: curl_cffi mit ProxyHat residentiellen Exits

Im Folgenden zeigen wir eine funktionierende Implementation in Python, die curl_cffi mit ProxyHat-residentiellen Proxies kombiniert, um einen kohärenten Chrome-148-Fingerprint zu emittieren. Dies ist für autorisiertes Monitoring, Sicherheitsforschung und legitime Datensammlung gedacht.

from curl_cffi import requests

# ProxyHat residentieller Proxy mit US-Geo-Targeting
proxy_url = "http://user-country-US:PASSWORD@gate.proxyhat.com:8080"

# curl_cffi impersonate=chrome emuliert Chrome's TLS-Handshake (JA3/JA4)
# UND HTTP/2-Settings (SETTINGS-Frame, WINDOW_UPDATE, Pseudo-Header)
session = requests.Session(impersonate="chrome")

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

response = session.get(
    "https://example.com/api/data",
    proxies=proxies,
    timeout=30,
)

print(f"Status: {response.status_code}")
print(f"JA4H konsistent: {response.http_version == 'h2'}")

Dieses Snippet sendet einen vollständigen Chrome-148-Stack: TLS-Handshake mit den korrekten Cipher-Suites und Extensions, HTTP/2 SETTINGS-Frame mit HEADER_TABLE_SIZE=65536, INITIAL_WINDOW_SIZE=6291456, WINDOW_UPDATE mit Chrome's Increment-Werten und Pseudo-Header in der Reihenfolge m,a,s,p. Der ProxyHat-residentielle Exit stellt eine ISP-IP bereit, die nicht als Datencenter klassifiziert wird.

Sticky Sessions für zustandsbehaftete Interaktionen

Für Login-Flows oder mehrstufige Formulare benötigen Sie eine konsistente IP über mehrere Requests. ProxyHat unterstützt Sticky Sessions über den Username:

from curl_cffi import requests
import uuid

session_id = str(uuid.uuid4())
proxy_url = f"http://user-session-{session_id}-country-DE:PASSWORD@gate.proxyhat.com:8080"

session = requests.Session(impersonate="chrome")
proxies = {"http": proxy_url, "https": proxy_url}

# Alle Requests in dieser Session nutzen dieselbe IP
r1 = session.get("https://example.com/login", proxies=proxies)
r2 = session.post("https://example.com/auth", proxies=proxies, data={...})

Geo-Targeting auf Stadtebene

Für SERP-Tracking und lokalisierte Datensammlung können Sie ProxyHat auf eine bestimmte Stadt eingrenzen:

proxy_url = "http://user-country-DE-city-berlin:PASSWORD@gate.proxyhat.com:8080"

Weitere Details zu verfügbaren Standorten finden Sie auf der ProxyHat-Locations-Seite.

HTTP/3 (QUIC) Fingerprinting: Die nächste Ebene

HTTP/3 basiert auf QUIC, das über UDP läuft und ein eigenes Fingerprinting-Profil erzeugt. Der QUIC-ClientHello wird direkt in das erste QUIC-Paket kodiert und enthält TLS 1.3-Parameter. Der JA4-Fingerprint für QUIC beginnt mit q statt t, was die Transport-Schicht kennzeichnet.

Chrome 148 verwendet standardmäßig HTTP/3, wenn der Server es über den Alt-Svc-Header anbietet. Ein Client, der nur HTTP/2 spricht, kann verdächtig sein, wenn der echte Browser HTTP/3 verwenden würde. curl_cffi unterstützt QUIC über die impersonate="chrome"-Option, aber die Proxy-Unterstützung für UDP-basierte Protokolle ist begrenzt — HTTP-Proxies tunneln in der Regel nur TCP.

Für HTTP/3 über Proxies benötigen Sie einen SOCKS5-Proxy, der UDP-Forwarding unterstützt. ProxyHat bietet SOCKS5 auf Port 1080:

from curl_cffi import requests

# SOCKS5 für HTTP/3 / QUIC
proxy_url = "socks5://user-country-US:PASSWORD@gate.proxyhat.com:1080"

session = requests.Session(impersonate="chrome")
proxies = {"http": proxy_url, "https": proxy_url}

# curl_cffi versucht HTTP/3, wenn der Server es anbietet
response = session.get("https://example.com", proxies=proxies)

Häufige Fehler und Edge Cases

1. HTTP/1.1 Fallback als Signal

Wenn ein Client nur HTTP/1.1 spricht (z. B. Standard-requests-Bibliothek), ist das selbst ein Signal. Chrome 148 verhandelt über ALPN immer h2 oder h3. Ein Client, der nur HTTP/1.1 anbietet, ist mit hoher Wahrscheinlichkeit eine Bibliothek. Verwenden Sie immer einen Client, der HTTP/2 über ALPN verhandelt.

2. Falsche Accept-Encoding-Header

Chrome sendet Accept-Encoding: gzip, deflate, br, zstd. httpx sendet oft nur gzip, deflate. Das Fehlen von br (Brotli) und zstd (Zstandard) ist ein weiterer Korrelationsbruch, der den Bot-Score erhöht. curl_cffi mit impersonate="chrome" setzt diese Header automatisch korrekt.

3. Connection-Reuse über verschiedene IPs

Wenn Sie eine HTTP/2-Verbindung über einen Proxy aufbauen und dann den Proxy wechseln, während die Verbindung offen ist, kann die Ziel-IP wechseln, was Server-seitig als anomales Verhalten erkannt wird. Verwenden Sie für jede Proxy-IP eine neue Session.

4. Zu viele gleichzeitige Streams

Chrome sendet MAX_CONCURRENT_STREAMS=1000, aber die meisten Server limitieren auf 100-128. Wenn Ihr Client 500 gleichzeitige Streams öffnet, obwohl der h2-Fingerprint Chrome meldet, ist das ein Verhaltenssignal. Halten Sie die Concurrency im Rahmen des realistischen Browser-Verhaltens.

5. Canvas und WebGL Fingerprinting als ergänzende Signale

Wenn Sie einen Headless-Browser verwenden, müssen auch Canvas- und WebGL-Fingerprints konsistent sein. Headless Chrome hat einen leeren Canvas-String und einen SwiftShader-WebGL-Renderer, der sofort erkannt wird. Tools wie undetected-chromedriver oder patchright patchen diese Signale, aber sie müssen mit dem h2-Fingerprint übereinstimmen.

Legitime Verwendung und rechtliche Hinweise

Die hier beschriebenen Techniken sind für autorisiertes Monitoring, Sicherheitsforschung, Penetration Testing mit schriftlicher Erlaubnis und legitime Datensammlung im Rahmen der jeweiligen Nutzungsbedingungen gedacht. Sie sind nicht für Betrug, Account-Takeover, Credential Stuffing oder Umgehung von Zugangskontrollen ohne Autorisierung bestimmt.

Im US-Rechtsraum kann unbefugter Zugriff auf Computersysteme nach dem Computer Fraud and Abuse Act (CFAA) strafbar sein, auch wenn nur öffentlich zugängliche Endpoints abgefragt werden, wenn dies gegen ausdrückliche Nutzungsbedingungen verstößt. In der EU fällt die Verarbeitung personenbezogener Daten unter die DSGVO (GDPR), auch wenn die Daten öffentlich abrufbar sind.

Praxisempfehlung: Prüfen Sie robots.txt, lesen Sie die Nutzungsbedingungen, dokumentieren Sie Ihre Autorisierung und vermeiden Sie die Verarbeitung personenbezogener Daten ohne Rechtsgrundlage. Bei SERP-Tracking und Preis-Monitoring gelten in vielen Fällen berechtigte Interessen, aber die Beweislast liegt bei Ihnen.

Weitere Informationen zu ProxyHat-Anwendungsfällen finden Sie auf unseren Seiten zu Web Scraping und SERP-Tracking. Die vollständige API-Dokumentation finden Sie unter docs.proxyhat.com.

Key Takeaways

• HTTP/2 Fingerprinting erfasst SETTINGS-Frame, WINDOW_UPDATE, Stream-Priorität und Pseudo-Header-Reihenfolge. Jedes Feld ist browserspezifisch und wird von Anti-Bot-Systemen mit TLS-Fingerprints (JA3/JA4) kreuzvalidiert.
• Ein Korrelationsbruch zwischen TLS und h2 ist sofort erkennbar. httpx mit h2-Backend sendet HEADER_TABLE_SIZE=4096, während Chrome 65536 sendet — das reicht für max Bot-Score vor HTML-Laden.
• curl_cffi mit impersonate="chrome" ist die beste Python-Option für kohärente TLS- und h2-Fingerprints, da es BoringSSL/Curl direkt verwendet.
• Residentielle Proxies sind erforderlich, weil Protokoll-Spoofing allein die IP-Reputation nicht löst. Datencenter-IPs starten mit einem Bot-Score von 50-70.
• HTTP/3 (QUIC) ist die nächste Ebene — Clients, die kein QUIC sprechen, können verdächtig sein, wenn der echte Browser HTTP/3 verwenden würde.
• Legalität beachten: CFAA im US-Raum, DSGVO in der EU, robots.txt und Nutzungsbedingungen respektieren.

Bereit für kohärente Fingerprints mit residentiellen Exits? Sehen Sie sich die ProxyHat-Preise an oder testen Sie die Implementation mit dem obigen Code-Snippet.