HTTP-Header Web Scraping: Nicht mehr blockiert werden

Verstehen Sie zunächst das Modell richtig. Ein Request-Header ist Metadaten, die Ihr Client an eine ausgehende Anfrage anhängt: wer Sie sind, was Sie akzeptieren, woher Sie kommen. Ein Response-Header ist Metadaten, die der Server zurücksendet: Statushinweise, Inhaltstyp, Cache-Regeln und Set-Cookie Anweisungen.

Cookies sind kein separates Protokoll; sie sind ein zustandsbehafteter Header. Der Server gibt sie über Set-Cookie, und Ihr Client sendet sie bei jeder folgenden Anfrage in einem Cookie Header bei jeder folgenden Anfrage. Gemäß RFC 6265 hält dieser Hin- und Rückweg Sitzungen aufrecht, überträgt Authentifizierungstoken, legt den Standort fest und speichert A/B-Buckets.

Beim Web-Scraping von HTTP-Headern sind beide Ebenen wichtig. Wenn du eine davon vermasselst, sieht dein Client bei jedem Aufruf wie neu aus – und genau darauf achtet die Bot-Erkennung. Unser Leitfaden zu HTTP-Cookies erklärt die zugrunde liegenden Mechanismen.

Server bewerten nicht jeden Header gleich. Eine kurze Liste übernimmt die Hauptarbeit in echten Fingerprinting-Stacks, und dieselben Namen tauchen bei allen Erkennungsanbietern auf. Die folgenden H3-Abschnitte behandeln diese Header in etwa nach ihrer Bedeutung für das Web-Scraping von HTTP-Headern, angefangen bei dem, den fast jeder falsch angibt (User-Agent), bis hin zu Client-Hinweisen und Sitzungscookies.

User-Agent identifiziert die Client-Software, das Betriebssystem und die Browser-Engine und ist der erste Header, den Anti-Bot-Systeme prüfen. Standardwerte wie python-requests/2.x oder der axios-Standard werden sofort blockiert, da kein echter Besucher sie sendet. Das in der Praxis häufigste Profil ist Chrome unter Windows, daher ist dies das sicherste Ziel zum Nachahmen.

Zwei Muster scheitern zuverlässig. Das erste ist die Wiederverwendung eines einzigen UA über Millionen von Anfragen hinweg. Das zweite ist das manuelle Bearbeiten eines echten UA, das Verändern einer Ziffer und das Erhalten einer Version, die kein tatsächlicher Browser jemals ausgeliefert hat. Überprüfen Sie zum Zeitpunkt des Schreibens anhand einer aktuellen Chrome- oder Firefox-Version, anstatt eine Versionszeichenfolge aus einem beliebigen Tutorial zu kopieren, einschließlich dieses hier.

Diese drei Angaben geben an, welche Inhalte Ihr Client verarbeiten kann. Accept listet MIME-Typen auf, Accept-Language listet Locales auf, wie z. B. en-US,en;q=0.9, und Accept-Encoding listet Komprimierungsalgorithmen auf (gzip, deflate, br). Echte Browser senden hier umfangreiche, geordnete Werte, wobei sich die genauen Zeichenfolgen zwischen Chrome und Firefox unterscheiden.

Die Fallstricke sind subtil. Eine US-Privathaushalts-IP in Verbindung mit Accept-Language: ru , ist ein Fingerabdruck-Mismatch. Das Senden br (Brotli), aber dann das Versagen beim Dekodieren eines Brotli-Body wirkt ebenso bot-ähnlich. Passen Sie Accept-Language an die Geolokalisierung Ihres Proxys an und geben Sie nur Komprimierungsformate an, die Ihr HTTP-Client tatsächlich transparent dekomprimiert.

Referer teilt dem Server mit, welche Seite den Nutzer zu dieser URL weitergeleitet hat. Ein Aufruf einer tiefen Produktseite ohne Referer überhaupt verdächtig, da echte Besucher in der Regel über eine Suchmaschine, eine Kategorieübersicht oder einen internen Link gelangen. Legen Sie eine plausible Referer , wie z. B. eine Google-Suche oder die eigene Kategorieseite der Website.

Origin ist sein strengerer Verwandter: Browser fügen ihn an Cross-Origin-POST- und fetch/XHR-Anfragen an. Wenn Sie einen API-Aufruf wiederholen, den Sie in DevTools beobachtet haben, kopieren Sie den Origin Header wortwörtlich, sonst behandelt der Server die Anfrage als gefälscht.

Moderne Chromium-Browser fügen eine Reihe von Sicherheitskontext-Headern hinzu, die in älteren Scraping-Anleitungen ignoriert werden: Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest, und Sec-Fetch-User. Sie beschreiben, ob es sich bei der Anfrage um eine Navigation auf oberster Ebene, eine eingebettete Ressource oder einen Cross-Origin-XHR-Aufruf handelt. Beim direkten Laden einer Seite in einem neuen Tab wird in der Regel Sec-Fetch-Site: none, Sec-Fetch-Mode: navigateund Sec-Fetch-Dest: document.

Client-Hinweise (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform) wiederholen Ihr UA-Profil in strukturierter Form. Die Fingerabdruckprüfung ist einfach: Wenn Ihr User-Agent Chrome unter Windows angibt, Ihr Sec-CH-UA-Platform sagt "macOS", werden Sie markiert. Geben Sie immer User-Agent, Sec-CH-UAund Sec-CH-UA-Platform stammen aus derselben echten Browseraufzeichnung, damit sie intern konsistent bleiben.

Nach der ersten Anfrage Cookie wird zum identitätsreichsten Header, den Sie senden. Anti-Bot-Systeme nutzen ihn, um zu verfolgen, ob eine Sitzung bereits läuft, ob Sie ein Einwilligungsbanner akzeptiert haben und ob Ihr CSRF-Token aus demselben Render stammt wie das Formular, das Sie absenden. Wenn Sie Cookies zwischen den Anfragen löschen, wirken Sie jedes Mal wie ein brandneuer Besucher.

Benutzerdefinierte Header wie x-csrf-token, x-api-key, und Authorization erscheinen an XHR-Endpunkten hinter modernen SPAs. Extrahieren Sie sie aus dem HTML oder einer vorherigen JSON-Antwort und fügen Sie sie dann dem eigentlichen Datenaufruf hinzu. Ohne diesen Schritt gibt die API einen 401-Fehler oder leere Ergebnisse zurück.

Hören Sie auf, Header-Werte zu erraten. Öffnen Sie die Zielseite in einer normalen Chrome- oder Firefox-Sitzung, klicken Sie mit der rechten Maustaste und wählen Sie „Inspect“, wechseln Sie dann zum Tab „Network“. Laden Sie die Seite neu, klicken Sie auf die erste Dokumentanfrage (das HTML) und öffnen Sie das Header-Panel. Der Abschnitt „Request Headers“ ist Ihre Referenz.

Zwei Tricks sparen Zeit. Klicken Sie mit der rechten Maustaste auf die Anfrage und wählen Sie „Als cURL kopieren“, um den vollständigen Aufruf, einschließlich Headern, Cookies und Body, in einen shell-fähigen Befehl zu exportieren. Und entfernen Sie vor der Wiedergabe sitzungsspezifische Werte wie Cookie, x-client-dataund alle einmalig verwendbaren CSRF-Token.

Überprüfen Sie die Wiedergabe, indem Sie sie auf httpbin.org/headers richten, was genau das zurückgibt, was Ihr Client gesendet hat. Wenn die Rückmeldung nicht mit der Erfassung in den DevTools übereinstimmt, schreibt Ihre HTTP-Bibliothek Daten um. Unser Leitfaden zu cURL-Antwort-Headern behandelt detailliertere Überprüfungsmethoden.

Das Muster ist bei jedem HTTP-Client dasselbe: Erstellen Sie ein Wörterbuch mit Header-Namen und -Werten, fügen Sie es der Anfrage hinzu und verwenden Sie eine Sitzung wieder, damit Cookies erhalten bleiben. Die beiden folgenden sprachspezifischen Abschnitte zeigen die Fallstricke auf, die bei großem Umfang zum Problem werden.

Mit requestsübergeben Sie ein headers dict an getund verwende ein Session , damit Cookies über Aufrufe hinweg erhalten bleiben:

import requests

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                  "AppleWebKit/537.36 (KHTML, like Gecko) "
                  "Chrome/<current> Safari/537.36",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
    "Sec-Fetch-Site": "none",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Dest": "document",
}

with requests.Session() as s:
    s.headers.update(headers)
    r = s.get("https://httpbin.org/headers")
    print(r.json())

Der Haken: requests behält die Reihenfolge der Header nicht zuverlässig bei, was eine bekannte Schwachstelle beim Fingerprinting darstellt. Für das Web-Scraping von HTTP-Headern in großem Maßstab sollten Sie httpx, das die exakte Einfügungsreihenfolge aus Ihrem Dict beibehält und HTTP/2 unterstützt. Erstellen Sie das Dict in derselben Reihenfolge, wie sie DevTools anzeigt, und das Wire-Image bleibt konsistent.

In Node.js axios und native fetch ein headers Objekt. Verwenden Sie eine axios-Instanz wieder, um Standardwerte gemeinsam zu nutzen, und verwenden Sie einen Cookie-Speicher (axios-cookiejar-support oder ähnliches), damit Sitzungen über mehrere Anfragen hinweg bestehen bleiben:

import axios from "axios";

const client = axios.create({
  headers: {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " +
                  "AppleWebKit/537.36 (KHTML, like Gecko) " +
                  "Chrome/<current> Safari/537.36",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.9",
    "Sec-Fetch-Site": "none",
    "Sec-Fetch-Mode": "navigate",
    "Sec-Fetch-Dest": "document",
  },
});

const { data } = await client.get("https://httpbin.org/headers");
console.log(data);

Achten Sie auf axios-Standardwerte wie X-Requested-With: XMLHttpRequest, die die Bibliothek preisgeben. Überschreiben oder löschen Sie diese explizit. Unser ausführlicher Einblick in Axios-Header behandelt Muster zur Umgehung der Erkennung auf der Anforderungs-Ebene.

Header-Namen sind laut RFC nicht groß-/kleinschreibungsabhängig, aber ihre Groß-/Kleinschreibung und Reihenfolge sind ein eindeutiger Fingerabdruck. Echtes Chrome sendet User-Agent mit genau dieser Groß-/Kleinschreibung an einer bestimmten Stelle relativ zu Accept und Sec-Fetch-*. Python requests schreibt Namen traditionell in Kleinbuchstaben und garantiert keine Reihenfolge; httpx behält alles bei, was man ihm gibt; axios ist im Allgemeinen originalgetreu, fügt aber seine eigenen Standardwerte hinzu, wenn man diese nicht entfernt.

Das ist jedoch nur die halbe Wahrheit. Selbst mit einem perfekten Header-Satz ist Ihr TLS-Handshake ein einzigartiger Fingerabdruck. JA3 und das neuere JA4 hashen die von Ihrem Client angebotenen Verschlüsselungssuiten, Erweiterungen und elliptischen Kurven. Ein Python-TLS-Stack, der vorgibt, Chrome zu sein, aber die Verschlüsselungsreihenfolge von OpenSSL anbietet, ist eine offensichtliche Lüge; auf tlsfingerprint.io können Sie sehen, wie leicht dies zu erkennen ist.

Abhilfemaßnahmen: Verwenden Sie einen HTTP/2-fähigen Client mit realistischen TLS-Einstellungen (curl_cffi, tls-client in Python; undici mit benutzerdefiniertem TLS in Node) oder weichen Sie auf einen Stealth-Proxy oder eine verwaltete API aus, die die TLS-Schicht für Sie übernimmt.

Im großen Maßstab erfolgt die Rotation von HTTP-Headern beim Web-Scraping auf Sitzungsebene, nicht auf Anforderungsebene. Behalten Sie einen realistischen Headersatz für die Lebensdauer seiner Cookies bei und tauschen Sie ihn erst aus, wenn Sie eine neue Identität starten. Ein Austausch User-Agent während einer Sitzung ist an sich schon ein Erkennungssignal.

Erstellen Sie einen Pool mit Hunderten von echten Header-Sätzen aus aktuellen Chrome-, Firefox-, Edge- und Safari-Builds. Aktualisieren Sie diesen bei Browser-Updates, da Sie sonst durch die Verwendung der User-Agent-Zeichenfolge aus dem Vorjahr auffallen. Kombinieren Sie die Header-Rotation mit der Proxy-Rotation, damit weder die IP-Adresse noch die Header allein zu einem stabilen Schlüssel werden. Unser Leitfaden zur Vermeidung von IP-Sperren und die Python-Requests-Proxy-Anleitung behandeln die Proxy-Seite.

Bevor eine Anfrage versendet wird, prüfe, was deine Bibliothek unaufgefordert sendet. Häufige verräterische Merkmale:

• User-Agent: python-requests/<version> oder die axios-Standard-UA
• X-Requested-With: XMLHttpRequest von axios
• Accept: */* anstelle einer echten MIME-Liste
• Connection: close wenn echte Browser Keep-Alive verwenden
• Proxy-eingespeist Via, X-Forwarded-For, und Forwarded

Ersetzen Sie die ersten vier durch realistische Werte und testen Sie Ihren Proxy httpbin.org/headers , um die letzte Gruppe zu erfassen.

Die Debug-Schleife für das Web-Scraping von HTTP-Headern ist kurz. Wenn Sie einen 403-, 429-Fehler oder einen leeren Body erhalten, der Browser aber einwandfrei rendert, arbeiten Sie diese Liste der Reihe nach ab:

1. Vergleichen Sie die Header. Vergleichen Sie Ihre DevTools-Erfassung httpbin.org/headers Zeile für Zeile.
2. Ändere den User-Agent in eine andere aktuelle Chrome- oder Firefox-Zeichenkette und versuche es erneut.
3. Überprüfe „Accept-Encoding“. Wenn du br, stellen Sie sicher, dass Ihr Client diese entpackt; andernfalls lassen Sie sie weg.
4. Überprüfen Sie die Cookies. Vergewissern Sie sich, dass Cookie mit der von dir vorbereiteten Sitzung übereinstimmt.
5. Wiederholen Sie den Vorgang mit cURL von Copy as cURL. Wenn cURL funktioniert und Ihr Code nicht, liegt der Unterschied in Ihrem Client. Wenn cURL ebenfalls fehlschlägt, liegt es an der IP oder TLS, nicht an den Headern.

Manuelles Web-Scraping mit HTTP-Headern hat seine Grenzen. Eskalieren Sie, wenn einer der folgenden Fälle eintritt:

• TLS- oder JA3/JA4-Blockierungen, die selbst bei perfekten Headern bestehen bleiben. Die Lösung finden Sie weiter unten.
• Parallelität von mehr als einigen hundert Sitzungen, bei der neue UA-Pools und Cookie-Jars zu einem eigenen Dienst werden.
• Rotationskosten in Ingenieursstunden, die die Gebühren eines verwalteten Endpunkts pro Erfolg übersteigen.
• Schwierige Ziele hinter einem Unternehmens-Bot-Management, das Sitzungen an einen vollständigen Browser-Fingerabdruck bindet.

Eine verwaltete Scraper-API oder ein Stealth-Proxy verwaltet Header, TLS, IPs und Wiederholungsversuche hinter einem Endpunkt, sodass Ihr Code die Parsing-Logik beibehält. Unser Leitfaden für 2026 zum Web-Scraping ohne Blockierung deckt den gesamten Eskalationspfad ab.

• Standard-Bibliotheks-Header sind das deutlichste Indiz. Ersetzen Sie python-requests/x.y UAs, axios-Standardeinstellungen und X-Requested-With vor allem anderen.
• Erfassen Sie, erfinden Sie nichts. Beziehen Sie Header-Sätze aus DevTools oder Copy as cURL, entfernen Sie sitzungsspezifische Werte und validieren Sie anhand von httpbin.org/headers.
• Interne Konsistenz ist wichtiger als bloßer Realismus. User-Agent, Sec-CH-UA, Sec-CH-UA-Platform, und Accept-Language müssen alle denselben Browser, dasselbe Betriebssystem und denselben Standort beschreiben.
• Reihenfolge und TLS sind genauso wichtig wie die Werte. Bevorzuge httpx in Python requests in Python und verwende einen TLS-treuen Client (oder eine verwaltete API), wenn JA3/JA4-Fingerprinting im Spiel ist.
• Rotieren Sie pro Sitzung, nicht pro Anfrage. Behalten Sie einen Header-Satz für die Lebensdauer des Cookies bei, aktualisieren Sie den Pool bei Browser-Updates und kombinieren Sie dies mit Proxy-Rotation.

In der Regel, weil die Header nicht das einzige Signal sind. Ihr TLS-Handshake (JA3/JA4), die HTTP/2-Frame-Reihenfolge, die IP-Reputation und fehlende Sitzungscookies erstellen alle unabhängig voneinander einen Fingerabdruck Ihres Clients. Selbst bytegenaue Header scheitern, wenn der darunterliegende TLS-Stack „Python“ statt „Chrome“ angibt. Wiederholen Sie die Anfrage mit cURL: Wenn cURL erfolgreich ist und Ihr Code nicht, liegt die Ursache unterhalb der Header-Ebene.

Wechseln Sie pro Sitzung, nicht pro Anfrage. Ein echter Besucher behält während eines gesamten Besuchs denselben Browser bei, daher ist eine Sitzung, die User-Agent , ist an sich schon verdächtig. Behalte einen Header-Satz für die Lebensdauer seines Cookie-Pools bei und wähle dann einen neuen für die nächste Sitzung. Aktualisiere den zugrunde liegenden Pool alle paar Wochen, sobald Chrome und Firefox neue stabile Versionen veröffentlichen.

Ja, teilweise. Ein Headless-Browser sendet automatisch realistische Header, einschließlich Sec-CH-UA und Sec-Fetch-*, sodass du den Großteil der manuellen Arbeit überspringen kannst. Du musst dennoch den Headless-Modus User-Agent (der oft HeadlessChrome), eine plausible Accept-Language für die geografische Lage Ihres Proxys festlegen und das navigator.webdriver Flag über ein Stealth-Plugin oder ein Start-Flag deaktivieren.

Ja. Verwaltete Scraping-APIs und Stealth-Proxy-Netzwerke wählen pro Ziel einen realistischen Header-Satz aus, ordnen ihn einer privaten IP-Adresse und einem TLS-Profil zu und rotieren alles synchron. Sie senden die Ziel-URL, sie geben den HTML- oder JSON-Code zurück. Der Kompromiss besteht zwischen den Kosten pro Anfrage und dem Entwicklungsaufwand für den Aufbau und die Wartung Ihres eigenen Header-, Proxy- und Fingerprinting-Stacks.

Isolieren Sie jeweils eine Variable. Wiederholen Sie zunächst Ihre genaue Anfrage curl --resolve von derselben IP-Adresse aus; wenn cURL erfolgreich ist, liegt das Problem in den Headern oder der Reihenfolge deines HTTP-Clients. Wechsle als Nächstes zu einer anderen privaten IP-Adresse mit denselben Headern; wenn die Blockierung aufgehoben wird, wurde die IP-Adresse markiert. Wenn beides nicht hilft, ist der TLS-Handshake der wahrscheinlichste Übeltäter.

Das Web-Scraping von HTTP-Headers ist nicht der glamouröseste Teil der Entwicklung eines Scrapers, aber es ist der Teil, der bei geringem Aufwand den höchsten Ertrag bringt. Erfassen Sie echte Browser-Headers, senden Sie sie in der Reihenfolge, in der der Browser sie verwendet hat, und behalten Sie User-Agent, Sec-CH-UAund Accept-Language intern konsistent halten, pro Sitzung statt pro Anfrage rotieren und die Standardwerte der Bibliothek entfernen, die nach Automatisierung schreien. Diese Vorgehensweise beseitigt die meisten einfachen 403- und 429-Fehler, noch bevor du überhaupt auf einen Proxy zurückgreifen musst.

Darüber hinaus stößt die manuelle Feinabstimmung an ihre Grenzen. JA3/JA4-Fingerabdrücke, Bot-Management in Unternehmen und hohe Parallelität verlagern die Arbeit unter die Header-Ebene, und das ist der richtige Moment, um mit der manuellen Entwicklung aufzuhören und einen Managed Service damit zu beauftragen. Wenn sich Ihr Stack an diesem Punkt befindet, verwaltet die Scraper-API von WebScrapingAPI Header, TLS-Profile, private IP-Adressen und Wiederholungsversuche hinter einem einzigen Endpunkt, sodass Sie die Parsing-Logik beibehalten und den Wettlauf um Fingerabdrücke hinter sich lassen können. Beginnen Sie dort, wenn manuelle Header nicht mehr die kostengünstigste Option sind.