Richten Sie ein einfaches requests-Skript auf eine Cloudflare-geschützte Website und Sie erhalten in der Regel einen 403-Fehler oder eine Challenge-Seite, bevor der eigentliche Inhalt je geladen wird. Das ist kein Fehler in Ihrem Code. Cloudflares Bot-Management sitzt vor Millionen von Websites und tut genau das, wofür es gebaut wurde: Browser von Skripten zu trennen und die Skripte zu verwerfen. Der TLS-Handshake Ihres HTTP-Clients, die gesendeten Header und die verwendete IP-Adresse werden alle als Automatisierung gelesen, und Sie werden im ersten Round-Trip markiert.

Dieser Beitrag handelt davon, öffentliche Seiten zuverlässig und in großem Maßstab abzurufen, ohne diese Abwehrmaßnahmen auszulösen. Es geht nicht darum, Sicherheitsmechanismen zu überwinden, um Daten zu erreichen, auf die man keinen Anspruch hat. Cloudflares Bot-Schutz ist eine legitime Verteidigung gegen DDoS, Credential-Missbrauch und aggressives Scraping, und ein Großteil des blockierten Datenverkehrs verdient die Sperrung. Das Ziel hier ist enger und ehrlich: einen legitimen Crawler öffentlicher Inhalte so erscheinen zu lassen wie den normalen Browser-Traffic, der er ist, damit er nicht in ein Netz gerät, das für Missbrauch gedacht ist. Mit diesem Rahmen gesetzt: So entscheidet Cloudflare, dass Sie ein Bot sind, warum naive Scraper sofort scheitern und was tatsächlich funktioniert, Schicht für Schicht.

Wie Cloudflare entscheidet, dass Sie ein Bot sind

Cloudflare führt nicht eine einzige Prüfung durch. Es stapelt mehrere, und jede betrachtet ein anderes Signal. Es hilft, diese in zwei Gruppen aufzuteilen: passive Prüfungen, die Ihre Anfrage lesen, ohne dass Sie etwas tun, und aktive Prüfungen, die Ihren Client dazu bringen, etwas zu tun, was ein echter Browser kann und ein Skript in der Regel nicht.

Passive Erkennung: Was Ihre Anfrage bereits verrät

Passive Prüfungen erfolgen, bevor eine Seite gerendert wird, an der eingehenden Anfrage.

  • IP-Reputation und Ratenbegrenzung. Cloudflare bewertet die IP, über die Ihr Datenverkehr ausgeht. Adressen in bekannten Hosting- und Cloud-ASNs (Datacenter-Bereiche) haben standardmäßig geringes Vertrauen, und jede einzelne IP, die schnell wiederholte Anfragen stellt, löst schnell eine Ratenbegrenzung aus. Ein sauberes Skript von einem Cloud-Server kämpft bergauf, bevor es auch nur einen einzigen Header sendet.
  • TLS- und JA3-Fingerprinting. Das Allererste, was Ihr Client tut, ist einen TLS-Handshake zu öffnen, und die Form dieses Handshakes (die Cipher-Liste, Erweiterungen und deren Reihenfolge im Client Hello) bildet einen Fingerabdruck, oft als JA3-Hash zusammengefasst. Echtes Chrome und Firefox erzeugen bekannte Fingerabdrücke. Ein Python- oder Go-HTTP-Client erzeugt einen anderen, den kein Browser ausgibt, und Cloudflare kann ihn markieren, bevor die Verbindung abgeschlossen ist.
  • Header- und User-Agent-Konsistenz. Browser senden eine spezifische, geordnete Menge an Headern und einen User-Agent, der zu den übrigen passt. Skripte neigen dazu, einen kurzen Header-Satz zu senden, die Header zu übersehen, die ein Browser immer enthält, oder zu behaupten, Chrome zu sein, während sie ein Header-Profil tragen, das kein Chrome jemals sendet. Cloudflare prüft diese Inkohärenz direkt.

Aktive Erkennung: Was Ihr Client beweisen muss

Wenn die passiven Signale mehrdeutig sind, eskaliert Cloudflare und lässt den Client Arbeit verrichten.

  • JavaScript-Herausforderungen. Cloudflare gibt eine Interstitial-Seite mit verschleiertem JavaScript zurück, das der Client ausführen muss, um ein Freigabe-Token zu erhalten. Ein echter Browser führt es aus und fährt automatisch fort. Ein HTTP-Client, der kein JavaScript ausführt, empfängt nur die Challenge-Seite und bleibt dort stehen.
  • Turnstile und CAPTCHAs. Bei höherem Verdacht präsentiert Cloudflare Turnstile (seinen CAPTCHA-Ersatz) oder eine vollständige Herausforderung. Diese sind speziell dafür konzipiert, von Automatisierung schwer zu lösen zu sein.
  • Verhaltensanalyse. Über die erste Seite hinaus beobachtet Cloudflare das Anfragemuster: Timing, Navigationsreihenfolge und bei interaktiven Herausforderungen Signale wie Zeigerbewegungen. Datenverkehr, der in einem perfekt gleichmäßigen, maschinellen Rhythmus ohne Variation eintrifft, sieht überhaupt nicht wie eine Person aus und wird eskaliert.
Zwei Schichten, zwei Fehlermodi

Eine Anfrage kann auf der passiven Schicht scheitern (falsche IP oder TLS-Signatur, markiert bevor die Seite lädt) oder auf der aktiven Schicht (eine JavaScript-Herausforderung erhalten, die sie nicht ausführen kann). Zu wissen, welche Sie erwischt hat, sagt Ihnen, was zu beheben ist. Eine bessere IP hilft nichts gegen eine nicht ausgeführte Herausforderung, und ein Headless-Browser hilft nichts gegen eine Datacenter-IP, die beim Handshake abgelehnt wurde.

Warum naive Scraper sofort scheitern

Ein einfacher requests.get()- oder httpx-Aufruf scheitert aus Gründen, die nichts mit Ihrer Parsing-Logik zu tun haben. Er öffnet einen TLS-Handshake mit einer Nicht-Browser-Signatur, sendet einen schmalen Header-Satz und kann kein JavaScript ausführen. Er wird also auf der passiven Schicht wegen Fingerabdruck und Headern erwischt, und wenn er das irgendwie umgeht, stockt er auf der aktiven Schicht, weil keine Engine vorhanden ist, um die Herausforderung auszuführen. Die gewünschte Seite wird nie gerendert. Man sieht einen 403-Fehler oder eine Challenge-Interstitialseite, nicht den Inhalt.

Das Einbinden eines einzelnen Datacenter-Proxys behebt das nicht. Es ändert die Exit-IP zu einer anderen Low-Trust-Hosting-Adresse und tut nichts gegen den TLS-Fingerabdruck, die Header oder die fehlende JavaScript-Engine. Man hat eines von vier Signalen geändert, und nicht das, das am wahrscheinlichsten falsch ist. Deshalb ist „Ich habe einen Proxy hinzugefügt und werde immer noch blockiert" ein so häufiger Bericht. Der Proxy war für eine Schicht notwendig und für die anderen irrelevant. Für die umfassendere Version dieses Problems über viele Anti-Bot-Systeme hinweg siehe wie man Websites scrapt, ohne geblockt zu werden.

Was tatsächlich funktioniert, in Prioritätsreihenfolge

Um Cloudflare auf einer öffentlichen Seite zu passieren, müssen Sie die Schichten in etwa dieser Reihenfolge erfüllen. Jeder Punkt unten behebt eine bestimmte Erkennungsschicht, und das Überspringen eines Punktes hinterlässt eine Lücke, die die entsprechende Prüfung findet.

  1. Rotierende Residential-IPs mit niedriger Rate pro IP. Das behebt IP-Reputation und Ratenbegrenzung. Residential Proxies verlassen das Netz über echte Consumer-ISP-Verbindungen, sodass Cloudflare sie als normale Besucher statt als Hosting-Traffic liest. Das Rotieren über einen Pool hält die Anfragerate auf einer einzelnen Adresse niedrig, sodass man auch bei hohem Gesamtvolumen nie eine Ratenbegrenzung auslöst. Siehe Datacenter- vs. Residential-Proxies dafür, warum der Ursprung der IP so wichtig ist, und rotierende Residential-Proxies für das Rotationsmuster.
  2. Eine echte Browser-Engine, die die Herausforderung ausführt. Das behebt die JavaScript-Challenge-Schicht. Puppeteer, Playwright oder Headless Chrome führen das verschleierte Challenge-Skript tatsächlich aus und erhalten das Freigabe-Token, was ein einfacher HTTP-Client nicht kann. Ein Stealth-Plugin reduziert die Headless-spezifischen Merkmale (die Automatisierungs-Flags und Umgebungsbesonderheiten, die einen kontrollierten Browser verraten), sodass die Engine wie ein normaler Browser wirkt.
  3. Kohärente Header und ein passender TLS-Fingerabdruck. Das behebt Fingerprinting- und Header-Konsistenzprüfungen. Der TLS-Handshake und die Header müssen zum behaupteten Browser passen: Wenn Ihr User-Agent Chrome angibt, sollten der JA3-Fingerabdruck und der Header-Satz auch die von Chrome sein. Echte Browser-Engines bekommen das kostenlos richtig hin, was zum Teil erklärt, warum sie passieren, wo ein handgefertigtes Header-Dict es nicht schafft. Für die tieferen Mechanismen siehe Browser-Fingerprinting.
  4. Menschlich dosiertes Verhalten. Das behebt die Verhaltensanalyse. Variieren Sie das Timing der Anfragen, vermeiden Sie eine enge Schleife, und navigieren Sie in einer plausiblen Reihenfolge. Das Ziel ist nicht, eine Person vorzutäuschen, die herumklickt; es geht darum, den perfekt gleichmäßigen, roboterhaften Rhythmus zu vermeiden, der eine Ausführung allein schon markiert. Behandeln Sie sich ändernde Statuscodes als Signal: Eine Ausführung, die 403-Fehler oder Challenge-Seiten zurückzugeben beginnt, signalisiert, dass eine Schicht nicht mehr erfüllt wird. Proxy-Status-Fehlercodes erklärt, wie man sie liest.

Eine Technik, die es wert ist, erwähnt zu werden, damit man sie überspringen kann: Die IP des Origin-Servers direkt anzugreifen, um Cloudflare zu umgehen. Sie taucht in älteren Anleitungen als „Origin-IP-Entdeckung" auf, und es ist weder ein zuverlässiger noch ein ratsamer Ansatz. Die meisten Origins sind so konfiguriert, dass sie Datenverkehr ablehnen, der nicht über Cloudflare kam, die entdeckte IP veraltet, und der ganze Ansatz wirkt eher wie feindliches Vorgehen als wie legitimer Zugriff auf eine öffentliche Seite. Bleiben Sie auf dem Weg, der die Seite so lädt, wie ein Besucher es würde.

Cloudflare-Signal vs. was es passiert

Erkennungssignal Was ein naives Skript tut Was es passiert
IP-Reputation Verlässt einen Datacenter-ASN Rotierende Residential-IPs wirken wie echte Nutzer
Ratenbegrenzung Viele Anfragen von einer IP Niedrige Rate pro IP, verteilt über einen Pool
TLS / JA3-Fingerabdruck Nicht-Browser-Handshake-Signatur Der native Handshake einer echten Browser-Engine
Header-Konsistenz Dünne oder nicht passende Header Kohärente Header, die dem behaupteten Browser entsprechen
JavaScript-Herausforderung Kann das Skript nicht ausführen Puppeteer / Playwright / Headless Chrome
Verhaltensanalyse Gleichmäßige, maschinelle Schleife Variiertes, menschlich dosiertes Anfrage-Timing

Liest man diese Tabelle durch, ist das Fehlermuster offensichtlich: Ein naiver Scraper scheitert in jeder Zeile, und ein einzelner Proxy behebt nur die ersten zwei. Man braucht gleichzeitig Abdeckung in allen Zeilen, und darin liegt der Engineering-Aufwand.

Das selbst umsetzen und was es kostet

Man kann den vollständigen Stack intern aufbauen. Einen Pool rotierender Residential-IPs aufsetzen, eine Flotte von Headless-Chrome-Instanzen mit einem Stealth-Plugin betreiben, um die Herausforderungen zu lösen, TLS- und Header-Profile kohärent mit der emulierten Browser-Version halten und den Datenverkehr dosieren. Es funktioniert. Es ist aber auch eine dauerhafte Wartungslast: Stealth-Plugins driften hinter Browser-Releases, Challenge-Skripte ändern sich, Fingerabdrücke werden neu klassifiziert, und die Headless-Flotte muss mit dem Volumen skalieren. Für einen einmaligen Abruf kann das in Ordnung sein. Für eine Pipeline, die weiterhin funktionieren muss, wartet man nun Anti-Bot-Infrastruktur statt das zu entwickeln, was die Daten nutzt.

Die Alternative ist, alle vier Schichten hinter einem einzigen Endpunkt zusammenzufassen, sodass der Code eine einfache HTTP-Anfrage bleibt. Das ist es, was der Crawlbase Smart AI Proxy tut.

Crawlbase Smart AI Proxy

Cloudflare erwartet eine vertrauenswürdige IP, einen echten Browser-Handshake, eine ausgeführte Herausforderung und menschlich dosierten Datenverkehr, alles auf einmal. Smart AI Proxy vereint Residential-Rotation, JavaScript-Rendering, Fingerabdruck-Kohärenz und Challenge-Handling in einem einzigen Backconnect-Endpunkt, sodass man einen normalen HTTP-Client auf einen einzelnen Host zeigt, statt einen Proxy-Pool und eine Headless-Flotte zu betreiben. Testen Sie zunächst eine geschützte öffentliche Seite im kostenlosen Tarif.

Ein funktionierendes Beispiel mit Smart AI Proxy

Der Smart AI Proxy ist ein Backconnect-Gateway: ein Host und Port, auf den man einen normalen HTTP-Client zeigt, mit Rotation, Rendering, Fingerabdruck-Kohärenz und Challenge-Handling serverseitig. Man übergibt sein Zugriffstoken als Proxy-Benutzernamen. Aus Sicht des Codes ist es einfach ein Proxy, sodass die nachstehende Anfrage wie jedes andere requests.get() aussieht.

Installieren Sie zunächst die einzige Abhängigkeit.

bash
pip install requests

Leiten Sie dann eine Anfrage an eine Cloudflare-geschützte öffentliche Seite durch das Gateway. Das Token wird in die Proxy-URL eingefügt, und derselbe Proxy wird sowohl für HTTP- als auch für HTTPS-Datenverkehr verwendet.

python
import requests

# Backconnect gateway: token as the username, rotation and rendering server-side.
proxy_url = "http://[email protected]:8012"
proxies = {"http": proxy_url, "https": proxy_url}

url = "https://example.com/protected-page"
resp = requests.get(url, proxies=proxies, verify=False)

print(resp.status_code)
print(resp.text[:500])

Ersetzen Sie YOUR_CRAWLBASE_TOKEN durch Ihr eigenes Token aus dem Dashboard. Das Gateway löst die Seite so auf, wie es ein echter Browser täte, mit Residential-IP, browser-geformtem Handshake, ausgeführter Herausforderung wenn eine erscheint, und gibt Ihrem Skript das gerenderte HTML zurück. Ihr Code berührt nie einen Proxy-Pool oder einen Headless-Browser; er stellt einen normalen GET-Request und liest das Ergebnis. Das verify=False-Flag überspringt die lokale Zertifikatsverifizierung für die Proxy-Verbindung, was bei dieser Art von Gateway erwartet wird.

Wenn Sie dieselbe Abdeckung ohne die Proxy-ähnliche Schnittstelle wünschen, bieten das Muster der rotierenden Proxies und die Crawling API dieselbe Engine über eine Anfrage-URL, was manche Pipelines bevorzugen.

Der ehrliche Teil: AGB und Legalität

Ob Sie eine bestimmte Website scrapen dürfen, hängt von deren Nutzungsbedingungen und der Rechtsprechung ab, in der Sie und die Website tätig sind, und das ist eine echte Einschränkung, keine Fußnote. Dass Cloudflare vor einer Website steht, entscheidet die Frage nicht für sich, aber die eigenen Regeln der Website tun es. Einige Grundsätze, an denen man festhalten sollte: Nur öffentliche Daten sammeln, robots.txt der Website und die angegebenen Ratenerwartungen respektieren und niemals Inhalte hinter Authentifizierung oder personenbezogene Daten ohne Rechtsgrundlage anstreben. Öffentliche Seiten für Analysen sind eine Sache; das Ernten von login-geschützten oder personenbezogenen Informationen ist eine andere, und Letzteres ist der Bereich, in dem rechtliche und ethische Risiken leben. Wenn ein Projekt mehr als öffentliche Daten benötigt, ist die richtige Antwort eine offizielle API oder eine Vereinbarung mit der Website, kein aggressiverer Scraper. Wenn Sie bei legitimem Zugriff auf interaktive Herausforderungen stoßen, behandelt CAPTCHAs beim Web Scraping umgehen diesen Teil im gleichen verantwortungsvollen Rahmen.

Zusammenfassung

Wichtigste Erkenntnisse

  • Cloudflare stapelt Prüfungen. IP-Reputation und Ratenbegrenzung, TLS- und Header-Fingerprinting, JavaScript-Herausforderungen und Verhaltensanalyse lesen jeweils ein anderes Signal, aufgeteilt in passive und aktive Schichten.
  • Naive Scraper scheitern auf jeder Schicht. Ein einfacher HTTP-Client sendet einen Nicht-Browser-Handshake, dünne Header und kann die Herausforderung nicht ausführen, sodass er markiert wird, bevor die Seite geladen wird.
  • Eine Lösung pro Schicht. Rotierende Residential-IPs beheben Reputation und Rate, eine echte Browser-Engine behebt die Herausforderung, kohärente Header und TLS beheben Fingerprinting, und menschliches Pacing behebt das Verhalten.
  • Origin-IP-Tricks überspringen. Den Origin direkt anzugreifen ist fragil und feindlich; bleiben Sie auf dem Weg, der die öffentliche Seite wie ein Besucher lädt.
  • Bleiben Sie bei öffentlichen Daten. Die Legalität hängt von AGB und Rechtsprechung ab; respektieren Sie robots und Rate, und berühren Sie niemals auth-geschützte oder personenbezogene Daten.

Häufig gestellte Fragen

Warum bekommt mein Scraper einen 403-Fehler von Cloudflare, selbst mit einem Proxy?

Ein Proxy ändert nur die IP, was eines von vier Signalen ist, die Cloudflare prüft. Wenn Sie einen Datacenter-Proxy verwendet haben, ist die IP immer noch Low-Trust; und in jedem Fall sind Ihr TLS-Fingerabdruck, Ihre Header und die fehlende JavaScript-Engine unverändert. Um den 403-Fehler zu beheben, braucht man in der Regel eine rotierende Residential-IP plus eine echte Browser-Engine, die die Herausforderung ausführt, nicht nur eine andere Exit-Adresse.

Was ist JA3 oder TLS-Fingerprinting und warum markiert es mein Skript?

Ihr TLS-Handshake hat eine erkennbare Form, die Cipher-Liste, Erweiterungen und deren Reihenfolge, die zu einem Fingerabdruck gehasht werden kann, oft JA3 genannt. Echte Browser erzeugen bekannte Fingerabdrücke, während Python- und Go-HTTP-Clients solche erzeugen, die kein Browser ausgibt. Cloudflare kann diesen Unterschied während des Handshakes erkennen, bevor Ihre Anfrage die Seite erreicht, weshalb ein Skript selbst mit perfekten Headern scheitern kann.

Brauche ich einen Headless-Browser, um Cloudflare zu umgehen?

Man braucht etwas, das die JavaScript-Herausforderung ausführt, was ein einfacher HTTP-Client nicht kann. Das kann ein eigenes Headless Chrome, Puppeteer oder Playwright sein (idealerweise mit einem Stealth-Plugin), oder ein Gateway, das serverseitig rendert. Ein verwalteter Endpunkt, der Rendering und IP in einer Anfrage kombiniert, vermeidet das eigenständige Betreiben und Skalieren einer Browser-Flotte.

Reichen rotierende Residential-Proxies allein aus, um Cloudflare zu passieren?

Sie beheben IP-Reputation und Ratenbegrenzung, aber nicht die JavaScript-Challenge- oder Fingerprinting-Schichten. Wenn eine Website nur passive IP-Prüfungen durchführt, kann Residential-Rotation ausreichen; wenn sie eine aktive Herausforderung bereitstellt, braucht man immer noch eine Browser-Engine, um sie auszuführen. Behandeln Sie die IP als notwendig, aber nicht immer ausreichend, und passen Sie den Rest des Stacks an die tatsächlich angetroffene Challenge-Stufe an.

Das hängt von den Nutzungsbedingungen der Website und Ihrer Rechtsprechung ab, nicht davon, ob Cloudflare präsent ist. Auf öffentliche Daten zuzugreifen und dabei robots.txt und vernünftige Ratenbegrenzungen zu respektieren ist generell vertretbarer als das Sammeln von auth-geschützten oder personenbezogenen Daten, was echte rechtliche und ethische Risiken mit sich bringt. Im Zweifelsfall bei öffentlichen Inhalten bleiben und für alles darüber hinaus eine offizielle API oder Vereinbarung anstreben.

Sollte ich die Origin-IP finden, um Cloudflare ganz zu umgehen?

Nein. Die sogenannte Origin-IP-Entdeckung ist fragil und feindlich: Die meisten Origins lehnen Datenverkehr ab, der nicht über Cloudflare kam, die IP veraltet, und der Ansatz zielt auf die Umgehung des Schutzes ab, statt auf den legitimen Zugriff auf die öffentliche Seite. Laden Sie die Seite stattdessen so, wie es ein Besucher tun würde, mit einer vertrauenswürdigen IP und einer echten Browser-Engine.

Jetzt loslegen

Crawlen Sie jede Website im großen Maßstab, ohne gegen die Infrastruktur zu kämpfen.

Crawlbase übernimmt Proxys, Fingerprints und CAPTCHAs, damit Ihr Team Datenpipelines ausliefert, statt Crawl-Infrastruktur zu pflegen. 1.000 Anfragen kostenlos, keine Karte erforderlich.

Self-Service · Kein Verkaufsgespräch erforderlich · Enterprise-Crawl-Volumen verfügbar