Zwei Vorstellungen, bevor irgendein Skript läuft
Alles, was über Browser-Fingerprinting geschrieben wird, betrifft Dinge, die eine Seite messen kann: Canvas, WebGL, Schriftarten, Bildschirmgröße. Das alles passiert, nachdem die Verbindung steht.
Bis dahin hat dein Client bereits zwei Aussagen über sich gemacht, die er nicht zurücknehmen kann. Das TLS-ClientHello nennt, welche Cipher Suites, Erweiterungen, elliptischen Kurven und ALPN-Protokolle er unterstützt — und in welcher Reihenfolge. Die HTTP/2-Präambel nennt die Werte seines SETTINGS-Frames, seine Fenstergröße beim Window Update und die Reihenfolge, in der er Header-Pseudofelder sendet.
Keines von beiden ist eine Behauptung über Identität. Beides ist eine Folge davon, welche TLS-Bibliothek und welcher HTTP-Stack in die Binärdatei kompiliert wurden. Genau das macht sie für Erkennungsanbieter so wertvoll: Ein User-Agent-String ist ein Satz, den jeder tippen kann; ein ClientHello ist eine Struktur, aus der man tatsächlich gebaut sein muss.
JA3, und warum Chrome es kaputt gemacht hat
JA3, 2017 von Salesforce veröffentlicht, nimmt fünf Felder aus dem ClientHello — TLS-Version, Cipher Suites, Erweiterungen, elliptische Kurven und Kurvenformate —, hängt sie in Wire-Reihenfolge aneinander und bildet einen MD5. Ergebnis ist ein 32 Zeichen langer Hash, der für einen bestimmten Client-Build stabil ist.
Sechs Jahre lang funktionierte das gut, dann hat Chrome es erledigt. In Chrome 110, ausgeliefert im Januar 2023, begann Google, die Reihenfolge der TLS-Erweiterungen zu randomisieren — bei jeder Verbindung, ausdrücklich gegen Ossifikation und gegen Fingerprinting. Weil JA3 die Erweiterungsliste in Wire-Reihenfolge hasht, ergibt eine zufällige Reihenfolge jedes Mal einen anderen Hash. Chrome ging über Nacht von einem JA3 zu praktisch unbegrenzt vielen.
Das hatte eine Folge, auf die in der Antidetect-Szene niemand gern hinwies: Eine Zeit lang war ein stabiler JA3 selbst verdächtig, weil echtes Chrome keinen mehr hatte.
JA4 und die JA4+-Familie
JA4, 2023 von FoxIO veröffentlicht, behebt das Reihenfolgeproblem auf die naheliegende Art: Es sortiert Cipher und Erweiterungen vor dem Hashen. Randomisiere die Wire-Reihenfolge, so viel du willst; die sortierte Liste bleibt gleich, und damit ist der Fingerprint wieder stabil.
Er ist zudem lesbar statt undurchsichtig. Ein JA4 ist eine 36 Zeichen lange Zeichenkette in drei Teilen, und der erste Teil ist für Menschen lesbar: Protokoll und TLS-Version, SNI-Präsenz, Anzahl von Ciphern und Erweiterungen sowie der ALPN-Wert. Du kannst einen JA4 ansehen und erkennen, dass ein Client 15 Cipher über TLS 1.3 mit ausgehandeltem h2 angeboten hat, noch bevor du den Hash nachschlägst.
JA4 ist der Anker einer größeren Familie, und zwei Geschwister zählen hier:
- JA4H fingerprintet die HTTP-Anfrage selbst — Methode, Version, Headernamen in Reihenfolge, Cookie-Präsenz und den Wert von
Accept-Language. Es erwischt einen Client, dessen Header nicht zum behaupteten Browser passen. - JA4L misst die Latenz zwischen Handshake-Schritten. Es ist am schwersten zu fälschen, weil es kein Wert ist, den du sendest — es ist die physische Zeit, die dein Stack zum Antworten braucht, und ein Zwischenglied, das TLS terminiert und neu aufbaut, verändert sie, ob du willst oder nicht.
Stand 2026 läuft JA4 unter anderem bei Cloudflare, Akamai und AWS WAF im Produktivbetrieb. Betrachte es als flächendeckend eingesetzt, nicht als aufkommende Technik.
HTTP/2: der Akamai-Fingerprint
HTTP/2 verrät genauso viel wie TLS — und wird von denen, die unauffällig bleiben wollen, seltener geprüft.
Am gebräuchlichsten ist das Format von Akamai, mit vier durch Pipes getrennten Teilen:
- SETTINGS-Frame — die Parameter, die der Client sendet, und ihre Werte, in Reihenfolge. Chrome, Firefox und Safari senden jeweils einen anderen Satz. Jede HTTP-Bibliothek ebenfalls.
- WINDOW_UPDATE — die anfängliche Fenstererhöhung auf Verbindungsebene.
- Priority-Frames — ob der Client sie sendet und wie er den Baum aufbaut.
- Reihenfolge der Pseudo-Header — die Abfolge von
:method,:authority,:scheme,:path. Chrome nutztm,a,s,p. Die meisten Bibliotheken nicht.
Der letzte Punkt ist fast komisch wirksam. Die HTTP/2-Spezifikation schreibt keine Reihenfolge vor, also wählte jede Implementierung ihre eigene und behielt sie bei. Eine Anfrage, die sich als Chrome ausgibt und ihre Pseudo-Header anders sortiert, hat sich widersprochen, bevor der Server einen einzigen echten Header gelesen hat.
Warum das nicht über die Browseroberfläche zu beheben ist
Das ist der Teil, bei dem Deutlichkeit angebracht ist, denn er widerspricht viel Marketing — fairerweise auch dem dieser Branche insgesamt.
Die Fingerprint-Einstellungen deines Antidetect-Browsers — Canvas-Modus, WebGL-Vendor, Zeitzone, Schriftarten — wirken im Renderer. Der TLS-Handshake passiert im Netzwerkstapel, in einem anderen Prozess, bevor der Renderer überhaupt beteiligt ist. Es gibt keine Einstellung, die ihn ändert, weil im Profil nichts zu ändern ist: Den Handshake erzeugt BoringSSL, so wie es in die Binärdatei kompiliert wurde.
Daraus folgt die einzige wirklich gute Nachricht dieses Artikels: Wenn du einen echten Chromium-Build steuerst, sind deine TLS- und HTTP/2-Fingerprints bereits die von Chrome. Puppeteer über echtes Chrome, Playwright über echtes Chrome und jeder Chromium-basierte Antidetect-Browser zeigen denselben Handshake wie das Chrome auf deinem Desktop, weil es derselbe Code ist. Automatisierungsflags ändern daran nichts.
Die Clients, die auf dieser Schicht auffliegen, sind die, die gar keine Browser sind: requests, axios, httpx, Gos net/http, curl. Sie setzen einen Chrome-User-Agent und liefern dann ein ClientHello, das kein Chrome je erzeugt hat. Genau diese Diskrepanz sollte JA4 finden.
Was Proxys mit dem Handshake machen
Deine Proxy-Wahl zählt hier, und die meisten Anleitungen bekommen diese Unterscheidung falsch.
| Proxy-Typ | Wirkung auf den TLS-Fingerprint |
|---|---|
| SOCKS5 | Keine. Leitet TCP-Bytes unverändert weiter; dein ClientHello erreicht den Server intakt. |
| HTTP CONNECT | Keine. Öffnet einen Tunnel; TLS wird darüber Ende zu Ende ausgehandelt. |
| MITM / TLS-terminierend | Vollständig. Der Proxy führt seinen eigenen Handshake, also sieht der Server dessen Fingerprint, nicht deinen. |
Die Fehlerquelle ist die letzte Zeile, und sie ist nicht immer etwas, wofür du dich entschieden hast. Unternehmens-Inspektionsappliances, manche „SSL-optimierenden“ Proxy-Dienste und jedes lokale Debug-Werkzeug der Charles- oder Fiddler-Familie terminieren TLS. Liest sich der Fingerprint eines Browsers plötzlich exotisch, such zuerst nach einem Interceptor, bevor du irgendetwas anderes prüfst.
Ergänzend: JA4L macht sogar einen transparenten Proxy teilweise sichtbar, weil der zusätzliche Hop Zeit kostet. Das lässt sich nicht wegkonfigurieren. Es ist ein Grund, einen Proxy geografisch nahe am behaupteten Ausgang zu bevorzugen statt eines, der über drei Kontinente geroutet wird.
Flags, die zählen, und Flags, die nicht zählen
Eine wiederkehrende Frage ist, ob Chrome-Startflags den Handshake ändern. Meistens nicht, und die Ausnahmen sollte man kennen.
Ohne Wirkung auf TLS: --headless, --no-sandbox, --disable-gpu, --disable-dev-shm-usage, die Fenstergröße und die ganze Familie der Renderer-Flags. Sie ändern, wie Seiten gezeichnet und wie der Prozess isoliert wird, nicht wie BoringSSL einen Server begrüßt.
Echte Wirkung: --disable-http2 erzwingt einen Rückfall auf HTTP/1.1, wodurch der HTTP/2-Fingerprint verschwindet und durch etwas Selteneres und damit Auffälligeres ersetzt wird — ein modernes Chrome, das h2 ablehnt, ist ungewöhnlich. --ssl-version-min und Verwandte verändern direkt, was im ClientHello angeboten wird. Optionen, die QUIC abschalten, ändern, welche Protokolle in welcher Reihenfolge versucht werden.
Die Faustregel: Klingt ein Flag danach, als berühre es den Netzwerkstapel, geh davon aus, dass es deinen Fingerprint ändert, und prüfe das, bevor du es produktiv setzt.
Wie du deinen prüfst
Drei öffentliche Endpunkte sagen dir in unter einer Minute, wo du stehst:
- tls.peet.ws/api/all — liefert deinen JA3, JA4, den vollständigen Akamai-HTTP/2-Fingerprint und deine Header-Reihenfolge als JSON. Die vollständigste Einzelansicht.
- browserleaks.com/tls — dasselbe Terrain, freundlicher aufbereitet.
- scrapfly.io/web-scraping-tools/ja3-fingerprint — nützlich, um einen Client mit bekannten Browsersignaturen zu vergleichen.
Der Test, auf den es wirklich ankommt, braucht zwei Fenster. Öffne eine dieser URLs in deinem gewöhnlichen Desktop-Chrome und dann noch einmal über das Werkzeug, das du prüfst. Vergleiche JA4 und den HTTP/2-Fingerprint Feld für Feld. Stimmen sie überein, ist diese Schicht nicht dein Problem, und deine Aufmerksamkeit gehört stattdessen der CDP-Fläche und der Frage, ob dein Fingerprint zusammenpasst. Unterscheiden sie sich, hilft dir keine noch so feine Canvas-Einstellung.