TLS-Fingerabdruck des Parsers: wie man ihn überprüft und nicht auffällt

Sie haben eine teure Wohn-IP genommen, die Rotation eingerichtet und einen realistischen User-Agent eingesetzt – und der Parser landet trotzdem in der Captcha oder erhält eine leere Antwort. Das Problem liegt fast immer nicht an der IP, sondern am TLS-Fingerabdruck: Die Bibliothek, mit der Sie die HTTPS-Anfrage senden, „klingt“ nicht wie ein echter Browser. Antibot-Systeme von Wildberries, Ozon, Cloudflare und Akamai erkennen dies, bevor sie Ihre IP-Adresse überprüfen.

Was ist ein TLS-Fingerabdruck und warum ist er wichtiger als die IP

Wenn ein Client eine HTTPS-Verbindung herstellt, sendet er ein Paket ClientHello – ein Teil des TLS-Handshakes. Darin sind die unterstützten TLS-Versionen, die Cipher Suites, die Reihenfolge der Erweiterungen, elliptische Kurven und Komprimierungsalgorithmen verschlüsselt. Diese Parameter sind einzigartig für jede Kombination „Bibliothek + Betriebssystem + TLS-Stack-Version“.

Chrome, Firefox und Safari bilden das ClientHello auf ihre eigene Weise, und dieses Set ändert sich praktisch nicht von Anfrage zu Anfrage – im Gegensatz zur IP oder zum User-Agent, die leicht durch Text gefälscht werden können. Standard-HTTP-Bibliotheken – requests, urllib3, der Standard-HttpClient in Java, der integrierte TLS-Stack von Node.js – erzeugen ein völlig anderes ClientHello, weil sie OpenSSL oder eine andere Bibliothek anders verwenden als ein Browser.

Deshalb können Sie eine perfekt „saubere“ Wohn-IP anschließen, einen frischen User-Agent eines echten Chrome einsetzen – und trotzdem eine Sperre erhalten. Der Server sieht die IP eines Wohnhauses, sieht den Header „Chrome 124“, aber der TLS-Handshake sagt: „das ist ein Python-Skript“. Die Diskrepanz ist ein direktes Signal für den Antibot.

Wie Antibot-Systeme den Parser anhand von JA3/JA4 erkennen

Um die Parameter des ClientHello in einen kompakten Identifikator zu verwandeln, wird der Algorithmus JA3 (und seine neuere Version JA4) verwendet. Er nimmt die TLS-Version, die Liste der Cipher, Erweiterungen und Kurven, fügt sie zu einer Zeichenkette zusammen und hasht sie mit MD5. Es entsteht ein kurzer Hash wie 769,47-53-5-10...,0-23-65281...,29-23-24,0, der den „Fingerabdruck“ des Clients eindeutig identifiziert.

Antibot-Anbieter (Cloudflare, Akamai, PerimeterX, DataDome – und ihre Pendants, die Wildberries und Ozon verwenden) halten Datenbanken mit bekannten JA3/JA4-Hashes beliebter HTTP-Bibliotheken: requests, aiohttp, Scrapy, Node fetch, Java HttpClient, Go net/http. Wenn der Hash mit einer bekannten Signatur eines „Skripts“ übereinstimmt und nicht mit der Signatur von Chrome/Firefox/Safari – wird die Anfrage als verdächtig markiert, noch bevor das Verhalten analysiert wird.

Danach prüft das System die Übereinstimmung des TLS-Fingerabdrucks mit dem angegebenen User-Agent. Wenn in den Headern steht „Chrome 124 auf Windows“, aber der TLS-Fingerabdruck zu OpenSSL 1.1.1 aus der Standardbibliothek von Python passt – das nennt man TLS/HTTP-Mismatch, eines der zuverlässigsten Signale zur Erkennung von Automatisierung. So werden Parser selbst bei einer perfekten Wohn-IP und korrekten Headern erkannt.

Wie man seinen TLS-Fingerabdruck überprüft: Werkzeuge

Bevor Sie das Problem beheben, müssen Sie sehen, was der Server sieht. Es gibt mehrere öffentliche Dienste, die Ihren JA3/JA4-Hash und die vollständige Liste der ClientHello-Parameter anzeigen:

tls.peet.ws – zeigt JA3, JA4, die Liste der Cipher und Erweiterungen im JSON-Format an, praktisch für die automatische Überprüfung durch ein Skript.
ja3er.com – Datenbank bekannter JA3-Hashes mit Zuordnung zu bestimmten Bibliotheken und Browsern.
browserleaks.com/tls – visuelle Vergleich Ihres Fingerabdrucks mit typischen Browser-Fingerabdrücken.
Wireshark lokal – wenn Sie das rohe ClientHello-Paket bei der Anfrage aus Ihrem Skript sehen möchten.

Der praktische Test ist einfach: Öffnen Sie tls.peet.ws in einem normalen Chrome und notieren Sie den JA4-Hash. Senden Sie dann eine GET-Anfrage an dieselbe Adresse aus Ihrem Parser (über requests, curl_cffi oder eine andere Bibliothek) über denselben Proxy und vergleichen Sie die Hashes. Wenn sie unterschiedlich sind – sieht der Server den Unterschied zwischen „Browser“ und „Skript“ bei jeder Anfrage, unabhängig davon, wie sauber die IP ist.

Überprüfung in Python: requests, httpx, curl_cffi

Lassen Sie uns praktisch untersuchen, warum Standardbibliotheken in Python den Parser verraten. Eine normale Anfrage über requests:

import requests

resp = requests.get("https://tls.peet.ws/api/all", proxies={
    "https": "http://user:pass@proxy_host:port"
})
print(resp.json()["tls"]["ja4"])
# Das Ergebnis wird sich vom JA4 eines echten Chrome unterscheiden,
# da requests das Standard-ssl-Modul von Python verwendet

Das Problem ist, dass requests und httpx das systemeigene OpenSSL über das Modul ssl verwenden, und die Reihenfolge und die Menge der TLS-Erweiterungen sind festgelegt und stimmen nicht mit Chrome/Firefox überein. Die Lösung ist die Bibliothek curl_cffi, die einen gepatchten Curl mit echten TLS-Profilen von Browsern verwendet:

from curl_cffi import requests as cffi_requests

resp = cffi_requests.get(
    "https://tls.peet.ws/api/all",
    impersonate="chrome124",
    proxies={"https": "http://user:pass@proxy_host:port"}
)
print(resp.json()["tls"]["ja4"])
# Der Hash wird identisch mit dem echten Chrome 124 auf dem Desktop sein

Der Parameter impersonate zwingt curl_cffi, nicht nur das ClientHello, sondern auch die Reihenfolge der HTTP/2-Header (frame order) zu reproduzieren, die ebenfalls in den Fingerabdruck eingeht. Ein ähnlicher Ansatz wird von den Bibliotheken tls-client für Go und undetected-chromedriver für diejenigen verwendet, die über einen echten Browser und nicht über einen HTTP-Client scrapen.

Wenn das Scraping über einen Headless-Browser (Playwright, Puppeteer, Selenium) erfolgt, wird der TLS-Fingerabdruck vom Chromium/Firefox-Engine generiert und stimmt standardmäßig mit dem echten Browser überein. Aber hier gibt es ein anderes Problem – Automatisierungssignaturen auf JS-Ebene (webdriver-Flags, Canvas-Fingerabdruck), daher sind für Headless-Szenarien zusätzlich Patches wie playwright-stealth erforderlich.

TLS + HTTP/2 + Header: warum die Kombination wichtig ist

Der TLS-Fingerabdruck ist nur eine Schicht der Erkennung. Antibot-Systeme vergleichen mehrere Ebenen gleichzeitig:

TLS ClientHello (JA3/JA4) – Satz von Cipher und Erweiterungen.
HTTP/2-Fingerabdruck – Reihenfolge der Pseudo-Header (:method, :path, :authority), Einstellungen des SETTINGS-Frames, Fenstergröße.
HTTP-Header – Reihenfolge und Satz der normalen Header (Accept-Language, Sec-Ch-Ua, Sec-Fetch-*).
User-Agent – muss mit der Version des TLS-Profils übereinstimmen: Wenn der UA „Chrome 124“ sagt, der TLS jedoch zu Chrome 110 passt, ist das auch verdächtig.

Ein häufiger Fehler ist es, den User-Agent auf die neueste Version von Chrome zu aktualisieren, ohne das TLS-Profil in curl_cffi oder einer anderen Bibliothek zu aktualisieren. Eine solche Versionsdiskrepanz ist für den Antibot ebenso deutlich sichtbar wie das vollständige Fehlen von Maskierung. Überprüfen Sie, dass die Version impersonate und die Version im User-Agent übereinstimmen, und aktualisieren Sie beide Parameter synchron, wenn neue Versionen des Browsers veröffentlicht werden.

Ein weiterer Punkt ist die Reihenfolge der Header. Der Browser sendet die Header in einer streng definierten Reihenfolge, während viele HTTP-Bibliotheken sie alphabetisch oder in der Reihenfolge der Hinzufügung im Code sortieren. Selbst wenn die Menge der Header mit dem Browser identisch ist, ist eine falsche Reihenfolge ein zusätzliches Signal für fortschrittliche Antibot-Systeme wie DataDome.

Die Rolle von Proxys: warum eine saubere IP nicht schützt

Eine Wohn-IP löst ein spezifisches Problem – sie verringert die Verdächtigkeit hinsichtlich Geografie, ASN und der Reputation der Adresse. Datacenter-IP-Adressen stehen oft auf schwarzen Listen, da von ihnen massenhaft automatisierter Traffic ausgeht, während Wohn-IP-Adressen echten Anbietern und normalen Nutzern gehören. Für das Scraping von Wildberries, Ozon oder Avito ist dies entscheidend: Ohne eine saubere IP wird die Anfrage allein aufgrund dieses Merkmals blockiert, ohne den TLS zu überprüfen.

Aber IP und TLS-Fingerabdruck sind zwei unabhängige Schutzschichten, die unterschiedliche Probleme lösen. Die IP sagt dem Server „von wo“ die Anfrage kam, der TLS-Fingerabdruck sagt „womit“ sie gesendet wurde. Daher ist die Kombination aus einer sauberen IP und dem richtigen TLS-Profil das Minimum für stabiles Scraping. Für Aufgaben mit hoher Anfragefrequenz und aggressiven Antibots ist es besser, Wohnproxies zu verwenden, da sie einen niedrigen Prozentsatz an Sperren aufgrund der IP-Reputation bieten, aber unbedingt mit einer Bibliothek kombiniert werden sollten, die das TLS-Profil eines echten Browsers korrekt reproduziert.

Für die Überwachung von Preisen auf Marktplätzen, wo Geschwindigkeit und Volumen der Anfragen wichtig sind, werden oft Datacenter-Proxys in Kombination mit TLS-Maskierung über curl_cffi verwendet – das ist günstiger als Wohnproxies und ausreichend effektiv, wenn das Antibot-System der Website nicht zu aggressiv ist. Und für Aufgaben, bei denen die Website aktiv mobile Netzwerke überprüft (z.B. Scraping von mobilen Versionen von Anwendungen über APIs), werden mobile Proxys verwendet – sie bieten eine zusätzliche Vertrauensstufe aufgrund der Reputation der Mobilfunknetze.

Checkliste zur Konfiguration des Parsers ohne Erkennung

Fassen Sie die Überprüfung in einen einheitlichen Prozess zusammen, bevor Sie den Parser in der Produktion starten:

Messen Sie den JA4-Hash Ihres Skripts über tls.peet.ws und vergleichen Sie ihn mit einem echten Browser derselben Version.
Verwenden Sie eine Bibliothek mit Unterstützung für TLS-Impersonation: curl_cffi (Python), tls-client (Go), CycleTLS (Node.js).
Synchronisieren Sie die Version des TLS-Profils (impersonate) mit der Version im User-Agent.
Überprüfen Sie die Reihenfolge der HTTP-Header – sie sollte mit dem echten Browser übereinstimmen und nicht alphabetisch sein.
Verbinden Sie eine saubere Wohn- oder mobile IP entsprechend der Geografie Ihrer Aufgabe.
Richten Sie die IP-Rotation getrennt vom TLS-Profil ein – koppeln Sie nicht das eine an das andere.
Aktualisieren Sie regelmäßig das TLS-Profil, wenn neue Versionen von Chrome veröffentlicht werden – alte Signaturen gelangen schneller in die Datenbanken der Antibots, als man denkt.
Für Szenarien mit JS-Überprüfungen (Cloudflare Challenge) verwenden Sie einen Headless-Browser mit Stealth-Patches anstelle eines reinen HTTP-Clients.

Vergleich von Bibliotheken und Werkzeugen

Werkzeug	TLS-Fingerabdruck des Browsers	Geschwindigkeit	Wann verwenden
requests / httpx	Nein, gibt Skript aus	Hoch	Websites ohne TLS-Erkennung, interne APIs
curl_cffi	Ja, exakte Kopie	Hoch	Marktplätze, Antibot Cloudflare/Akamai
tls-client (Go)	Ja	Sehr hoch	Hohe Last, massenhaftes Scraping
Playwright / Puppeteer	Ja, echte Engine	Niedrig	JS-Rendering, Cloudflare Challenge, komplexe SPAs
Scrapy (Standard)	Nein	Hoch	Websites ohne strenge Antibot-Schutzmaßnahmen

Fazit

Der TLS-Fingerabdruck ist eine Schutzschicht, die viele Parser vollständig ignorieren, indem sie Ressourcen auf die Suche nach der perfekten IP und dem perfekten User-Agent verwenden, aber vergessen, dass die Struktur des TLS-Handshakes die Automatisierung früher verrät, als der Server die Header überprüft. Die Lösung besteht darin, Bibliotheken mit Unterstützung für TLS-Impersonation (curl_cffi, tls-client) zu verwenden, die Version des Profils mit dem User-Agent zu synchronisieren und den endgültigen JA4-Hash vor dem Start im großen Maßstab zu überprüfen.

Die IP bleibt dennoch ein wichtiger Faktor – ohne eine saubere Adresse hilft selbst der perfekte TLS-Fingerabdruck nicht, eine Sperre aufgrund der Netzwerk-Reputation zu umgehen. Für das Scraping von Marktplätzen und die Preisüberwachung ist es sinnvoll, die richtige TLS-Konfiguration mit Wohnproxies zu kombinieren – diese Kombination schließt beide Schichten der Erkennung ein und senkt deutlich den Prozentsatz an Sperren bei langen Scraping-Sitzungen.