Tony Wang11 Min. LesezeitWebsites scrapen, die Bots blockieren: Cloudflare, DataDome & PerimeterX
Warum Scraper von Cloudflare, DataDome und PerimeterX blockiert werden — und wie du durchkommst: Stealth-Browser, IP-Rotation, Clearance-Wiederverwendung.
Für den größten Teil des Webs ist Scraping ein gelöstes Problem: URL abrufen, HTML parsen, fertig. Die interessanten Websites — die mit Preisen, Listings, Reviews und Beständen, die es wert sind, gesammelt zu werden — sind genau die, die dich nicht lassen. Sie sitzen hinter Cloudflare, DataDome, PerimeterX (jetzt HUMAN), Akamai oder Kasada, und sobald ein Script eine Seite anfragt, bekommt es ein CAPTCHA, ein „checking your browser"-Interstitial oder ein glattes 403. Der schwierige Teil beim modernen Scraping ist nicht das Parsen der Seite. Es ist, die Seite überhaupt zu bekommen.
Dieser Guide erklärt, wie diese Mauer wirklich funktioniert — welche Signale diese Systeme prüfen und warum ein normaler HTTP-Client bei jedem einzelnen auffliegt — und wie ein Scraper dann zuverlässig durchkommt, ohne so zu tun, als wäre das Problem einfacher, als es ist.
Die vier Schichten der Bot-Erkennung
Anti-Bot-Anbieter verlassen sich nicht auf eine einzige Prüfung. Sie bewerten jede Anfrage über mehrere unabhängige Schichten hinweg, und eine Anfrage muss auf allen menschlich aussehen. Die Schichten zu verstehen ist das ganze Spiel, denn jede schließt eine andere Klasse naiver Scraper aus.
| Schicht | Was sie prüft | Warum ein normaler Scraper scheitert |
|---|---|---|
| IP-Reputation | Ist die Adresse residential/mobile (vertrauenswürdig) oder Datacenter (verdächtig)? Hat sie zu viele Anfragen gestellt? | Scraper laufen auf Cloud-Servern und Datacenter-Proxies — Bereiche, die diese Anbieter auf einen Blick markieren |
| TLS-/HTTP-Fingerprint | Passen der TLS-Handshake und die HTTP/2-Frame-Reihenfolge zu einem echten Browser (JA3/JA4, Akamai-Fingerprint)? | requests, curl und die meisten HTTP-Libraries haben einen Fingerprint, der nichts mit Chrome zu tun hat, egal welche Header |
| JavaScript-Sensor | Ein Script sucht nach navigator.webdriver, Headless-Verräten, fehlenden APIs, Canvas-/WebGL-/Font-Eigenheiten | Headless-Automatisierung verrät dutzende Signale; ein HTTP-Client führt gar kein JavaScript aus, also meldet sich der Sensor nie zurück |
| Verhalten | Anfrage-Takt, Maus/Scrollen, Navigationsmuster, Cookie-Kontinuität | Scripts treffen Seiten schneller und mechanischer als ein Mensch, aus einer Session ohne Historie |
Der Grund, warum „setz einfach einen realistischen User-Agent" schon vor Jahren aufgehört hat zu funktionieren, ist, dass der User-Agent ein einzelner String in der unwichtigsten Schicht ist. Du kannst behaupten, Chrome 140 zu sein, so viel du willst; wenn dein TLS-Handshake Python sagt und deine IP AWS sagt, bist du bei zwei Prüfungen durchgefallen, bevor die Seite überhaupt lädt.
Was die Anbieter tatsächlich tun
Die großen drei verhalten sich unterschiedlich genug, dass es sich lohnt zu wissen, welche Mauer man vor sich hat.
- Cloudflare stellt ein Managed Challenge und, bei Erfolg, ein
cf_clearance-Cookie, das an deine IP und deinen User-Agent gebunden ist. Bestehe das Challenge, und das Cookie kauft dir ein Zeitfenster mit Zugriff — wechsle die IP, und es ist ungültig. - DataDome bewertet die Anfrage in Echtzeit und setzt ein
datadome-Cookie; es ist aggressiv gegenüber Datacenter-IPs und Wiederholungen eines Fingerprints über zu viele Anfragen hinweg. - PerimeterX / HUMAN betreibt einen JavaScript-Sensor, der ein Signal-Payload per POST sendet und ein Clearance-Cookie der
_px3-Familie gewährt. Es ist stark IP-gebunden: Ein Cookie, das auf einer IP erzeugt und von einer anderen präsentiert wird, wird als Diebstahl gelesen und härter blockiert als gar kein Cookie.
Der gemeinsame Nenner: Eine Clearance — das Cookie, das sagt „dieser Client hat bestanden" — wird nur verdient, indem man das Challenge in einem echten Browser ausführt, und sie ist an die IP gebunden, die sie verdient hat. Diese eine Tatsache bestimmt die gesamte Strategie.
Welche Mauer, welcher Fix
Jeder Anbieter hinterlässt einen eigenen Fingerprint — ein verräterisches Cookie oder eine Block-Meldung — und gibt einem anderen Hebel nach. Das ist der grobe Feldführer:
| Mauer | Woran du sie erkennst | Was durchkommt | Schwierigkeit |
|---|---|---|---|
| Cloudflare | cf_clearance / __cf_bm Cookies, ein „Checking your browser…"-Interstitial | Ein echter Browser, der das Managed Challenge löst; danach cf_clearance wiederverwenden | Niedrig–mittel |
| DataDome | datadome-Cookie, ein 403 mit einer DataDome-CAPTCHA-Seite | Vertrauenswürdige IP + echter Fingerprint; IPs rotieren — es bestraft Wiederholung | Mittel |
| PerimeterX / HUMAN | _px* Cookies, „Access to this page has been denied" | Ein Browser, der den JS-Sensor ausführt; die Clearance ist IP-gebunden, also frische IPs im Rennen | Mittel–hoch |
| Akamai Bot Manager | _abck / bm_sz / ak_bmsc Cookies | Echter TLS-Fingerprint + Browser; das _abck-Cookie muss validieren, sonst bist du shadow-geblockt | Hoch |
| Kasada | x-kpsdk-* Header, ein kpsdk-Sensor-Script | Vollständige Browser-Ausführung des Sensors; gehört zu den am schwersten headless zu bestehenden | Hoch |
Das Muster wiederholt sich: Jeder von ihnen will letztlich einen echten Browser sehen, von einer IP, der er vertraut, der sich wie ein Mensch verhält. Die Mauern unterscheiden sich hauptsächlich darin, wie streng jede dieser drei Prüfungen ist.
Wie du zuverlässig durchkommst
Der Fehler, den die meisten Scraper machen, ist, eine Sache zu tun — einen Stealth-Browser oder einen Residential-Proxy — für jede Anfrage. Das ist langsam und teuer bei einfachen Seiten und trotzdem fragil bei den schweren. Das zuverlässige Muster ist Eskalation: fang günstig an, und klettere nur so weit hoch, wie dich eine bestimmte Website dazu zwingt.
- Chrome-imitiertes HTTP. Eine einfache Anfrage, aber mit einem TLS- und HTTP/2-Fingerprint, der zu echtem Chrome passt. Das allein räumt die Fingerprint-Schicht aus dem Weg und reicht für eine überraschend große Zahl „geschützter" Websites — zu einem Bruchteil der Kosten eines Browsers.
- Ein echter Stealth-Browser. Wenn die Seite ausgeführtes JavaScript braucht — ein Cloudflare- oder PerimeterX-Challenge — übergib sie an eine Flotte gehärteter Browser-Engines mit gepatchten Automation-Verrätern und echten Fingerprints. Verschiedene Engines schlagen verschiedene Anbieter, also zählt es mehr, über eine Flotte zu racen oder zu rotieren, als auf eine einzige zu setzen.
- Eine frische IP. Anti-Bot ist IP-Reputation-first, also ist der ertragreichste Zug, wenn der aktuelle Exit markiert ist, schlicht eine andere Adresse. Mehrere Anfragen gleichzeitig durch einen rotierenden Pool zu feuern — und die erste zu nehmen, die mit der echten Seite zurückkommt — macht aus einem Münzwurf eine nahezu sichere Sache, denn eine frische IP kommt meist durch, während andere blockiert werden.
Nicht alle Adressen sind gleich, und hier kommen die Kosten ins Spiel. IPs kommen in Reputations-Stufen, und je vertrauenswürdiger die Stufe, desto mehr kostet sie:
- Datacenter-IPs sind günstig und reichlich vorhanden, aber am stärksten markiert — ganze Bereiche sind bekanntermaßen Clouds und Hosting-Providern zugeordnet, also misstrauen Anbieter ihnen standardmäßig.
- Residential-IPs sind echte Heim-Breitband-Adressen, die über Proxy-Netzwerke bezogen werden. Sie sehen aus wie gewöhnliche Besucher, tragen weit mehr Vertrauen und kosten spürbar mehr.
- Mobile-IPs sind carrier-NAT'te 4G/5G-Adressen — die vertrauenswürdigsten von allen, weil tausende echter Handys sich eine Adresse teilen, sodass ihre Blockierung riskiert, echte Kunden zu blockieren. Sie sind auch die teuersten, meist pro Gigabyte Traffic statt pro Adresse abgerechnet.
Der Reflex bei einer harten Mauer ist, direkt zu den teuersten IPs zu greifen. Der günstigere Zug ist der, um den es in diesem ganzen Abschnitt geht: Lehn dich auf den Stack — eskaliere zu einem echten Browser, race mehrere Datacenter-IPs gleichzeitig, und verwende eine Clearance wieder, sobald du sie verdienst — damit du so oft wie möglich über günstige Adressen durchkommst und nur für die Ziele auf Residential oder Mobile zurückfällst, die es wirklich verlangen. Du zahlst für Reputation genau dann, wenn die Seite dich dazu zwingt, und keine Anfrage früher.
Zwei Verfeinerungen machen das nicht nur zuverlässig, sondern auch schnell:
- Verwende die Clearance wieder. Wenn ein Browser ein
cf_clearance- oder DataDome-Cookie verdient, cache es pro Domain für seine kurze Lebensdauer und häng es an spätere Anfragen von derselben IP an. Eine günstige Engine kann dann eine Clearance mitnutzen, die eine teure bezahlt hat — höhere Erfolgsrate, niedrigere Kosten. - Zähle nur eine echte Seite als Erfolg. Eine Challenge-Seite, eine „checking your browser"-Hülle und ein 403 geben alle ein
200mit Bytes im Body zurück. Ein Scraper, der diese als Erfolg behandelt, gibt dir Müll und lernt nichts. Den Unterschied zu erkennen — und zu eskalieren, statt die Hülle zurückzugeben — ist das, was eine gut aussehende Zahl von Daten unterscheidet, die du nutzen kannst.
Ein durchgerechnetes Beispiel: eine PerimeterX-geschützte Seite
So setzen sich die Teile bei einem echten, sturen Ziel zusammen — einer News-Website hinter PerimeterX, wo eine Datacenter-Exit-IP so oft benutzt worden war, dass die Mauer sie bereits markiert hatte.
- Eine Engine, eine markierte IP: Einen einzigen Stealth-Browser zu bitten, die Seite von dieser verbrannten IP abzurufen, gelang nur etwa 1 von 6 Mal. Die Engine war fähig; die IP war der Flaschenhals.
- Frische IPs racen: Vier Anfragen für dieselbe Seite gleichzeitig zu feuern, jede durch eine andere Exit-IP, und die erste zu nehmen, die den echten Artikel zurückgab, hob den Erfolg auf 5 von 6 — und es war schneller, weil der Gewinner meist in ein paar Sekunden zurückkam, während die blockierten Versuche abgebrochen wurden.
- Die Clearance wiederverwenden: Sobald ein Browser das Clearance-Cookie von PerimeterX verdient hatte, ritt selbst eine leichtgewichtige Engine, die die Mauer nie allein schlägt, auf diesem gecachten Cookie direkt zur vollständigen Seite. Die teure Anfrage bezahlte die Clearance; die günstigen lösten sie ein.
Keines davon ist für sich eine Wunderwaffe. Das Ergebnis kommt daher, sie zu stapeln — zu einem Browser eskalieren, frische IPs racen, wiederverwenden, was funktioniert — und daraus, sich zu weigern, eine Challenge-Seite als Sieg zu zählen. Diesen letzten Punkt bekommt man leicht falsch hin: Die naive Variante gibt ein 200 voller Nichts zurück und meldet eine großartige Erfolgsrate.
Selbst bauen oder kaufen?
Du kannst das alles selbst zusammenbauen, und für ein einzelnes Ziel ist es ein vernünftiges Wochenendprojekt: ein Stealth-gepatchter Browser, ein Proxy, ein Cookie-Cache. Die Kosten zeigen sich später, als Tretmühle.
Es zu bauen bedeutet, eine Flotte gepatchter Browser-Engines zu besitzen (die Patches werden mit jedem Chrome-Release veraltet), ein Residential- oder Mobile-Proxy-Budget (die Position, die tatsächlich deine Obergrenze setzt), die Eskalationslogik, die pro Website die günstigste Methode wählt, eine Erfolgserkennung, die sich nicht von Challenge-Seiten täuschen lässt, und eine stehende Verpflichtung, das alles jedes Mal neu zu fixen, wenn ein Anbieter ein Erkennungs-Update ausliefert — was deren Vollzeitjob ist und für dich eine Nebenquest, die die eigentliche Aufgabe ständig unterbricht.
Es zu kaufen — eine Managed Scraping API — tauscht diese Tretmühle gegen einen Preis pro Anfrage. Der ehrliche Vergleich ist nicht „API-Credits gegen kostenlosen Code"; es ist „API-Credits gegen eine Proxy-Rechnung plus die Ingenieurswochen, die du damit verbringst, Detection-Bypässe zu warten, statt dein Produkt zu shippen." Für ein oder zwei einfache Websites gewinnt DIY. Für eine sich bewegende Liste geschützter Ziele, die du zuverlässig halten musst, ist die Wartung das Produkt — und das ist der Teil, den es sich lohnt auszulagern.
Wo Crawlora hineinpasst
Genau auf diesem Modell ist Crawloras Web Scraping API gebaut. Ein einziger /web/scrape-Aufruf eskaliert von selbst — Chrome-imitiertes HTTP, dann eine Flotte von Stealth-Browser-Engines, dann frische IPs gleichzeitig im Rennen — erfasst Clearance-Cookies und verwendet sie pro Domain wieder, und gibt eine Seite erst zurück, wenn bestätigt ist, dass sie echter Inhalt ist und kein Challenge. Du bekommst sauberes Markdown zurück (oder HTML, Links und Metadaten), und dir wird berechnet, was erfolgreich ist.
Eine Anfrage ist ein Aufruf — frag nach den Formaten, die du willst, und lass es eskalieren:
curl -X POST "https://api.crawlora.net/api/v1/web/scrape" \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/product/123",
"formats": ["markdown", "links", "metadata"],
"render": "auto"
}'
render: "auto" ist der Eskalations-Schalter: Es startet mit Chrome-imitiertem HTTP und klettert nur dann zur Stealth-Browser-Flotte (und frischen IPs) hoch, wenn die Seite es verlangt, sodass du keine Browser-Preise für Seiten zahlst, die keinen Browser brauchen. Derselbe Aufruf aus Python:
import requests
resp = requests.post(
"https://api.crawlora.net/api/v1/web/scrape",
headers={"x-api-key": "YOUR_API_KEY"},
json={
"url": "https://example.com/product/123",
"formats": ["markdown", "links", "metadata"],
"render": "auto", # escalate HTTP -> stealth browser -> fresh IP as needed
},
timeout=60,
)
data = resp.json()["data"]
print(data["markdown"]) # clean article text, not raw HTML
print(data["metadata"]["title"]) # parsed page metadata
Wenn du einfach nur wissen willst, womit du es zu tun hast, bevor du eine Zeile Code schreibst, jag eine URL durch den kostenlosen can-I-scrape-this-site-Checker: Er meldet, welchen Schutz eine Website nutzt und wie schwer es sein wird, sie zu sammeln.
Ein abschließender Hinweis zum Rahmen: Alles hier gilt für öffentliche Seiten. Bot-Erkennung ist kein Login, und daran vorbeizukommen ist nicht dasselbe wie in private Daten einzubrechen — aber die verantwortungsvolle Linie bleibt: nur öffentliche Daten, unter Respektierung der Terms und Robots-Direktiven jeder Website, und persönliche oder urheberrechtlich geschützte Inhalte in Ruhe gelassen. Zur rechtlichen Landschaft siehe ist Web Scraping 2026 legal; zur verwandten Frage von gesperrten Artikeln siehe wie Paywalls wirklich funktionieren.
Scrape die Websites, die alle anderen blockieren
Ein API-Aufruf — automatisch eskalierende Stealth-Browser, rotierende IPs und Clearance-Wiederverwendung — der sauberes Markdown zurückgibt und nur berechnet, was erfolgreich ist. 2.000 kostenlose Credits pro Monat, ohne Karte.
Häufig gestellte Fragen
Wie erkennen und blockieren Websites Scraper?
Moderne Anti-Bot-Systeme prüfen vier Schichten gleichzeitig: die Reputation der IP (Datacenter-Bereiche werden markiert, Residential und Mobile gelten als vertrauenswürdig), den TLS- und HTTP/2-Fingerprint (ein echter Chrome-Handshake sieht anders aus als einer von Python oder curl), einen JavaScript-Sensor, der den Browser auf Automation-Verräter abtastet (Headless-Flags, fehlende APIs, Canvas-/WebGL-Eigenheiten), und Verhalten über die Zeit. Eine Schicht nicht zu bestehen bringt ein CAPTCHA oder eine Block-Seite, also wird ein Scraper, der nur den User-Agent fälscht, sofort gestoppt.
Warum wird mein Scraper von Cloudflare oder DataDome blockiert?
Fast immer sind es die IP und der Fingerprint. Anfragen von einem Cloud-Server (AWS, GCP, ein Datacenter-Proxy) sitzen in Bereichen, die diese Anbieter als verdächtig behandeln, und ein Nicht-Browser-HTTP-Client hat einen TLS-/JS-Fingerprint, der nicht zu einem echten Chrome passt. Cloudflare, DataDome und PerimeterX kombinieren diese Signale — der Fix ist also kein besserer User-Agent-String, sondern ein echter Browser-Fingerprint von einer vertrauenswürdigen IP.
Kann man eine Website scrapen, die von Cloudflare, DataDome oder PerimeterX geschützt ist?
Oft, ja, für öffentliche Seiten — aber es ist probabilistisch, nicht garantiert. Der zuverlässige Ansatz eskaliert nur so weit, wie eine Website es verlangt: zuerst eine Chrome-imitierte HTTP-Anfrage, dann ein echter Stealth-Browser, der das Challenge ausführt, dann eine frische IP, falls die aktuelle markiert ist. Sobald ein Browser ein Clearance-Cookie verdient, können günstigere Anfragen es wiederverwenden. Die härtesten, IP-strengen Websites brauchen Residential- oder Mobile-Egress, um zuverlässig zu bleiben.
Ist es legal, Websites zu scrapen, die Bots blockieren?
Das Scrapen öffentlich zugänglicher Seiten ist weitgehend vertretbar, und eine Bot-Erkennungsmauer ist selbst keine Zugriffskontrolle auf private Daten, wie es ein Login ist. Aber das Gesetz hängt davon ab, was du sammelst und wie du es nutzt — respektiere die Terms und Robots-Direktiven jeder Website, vermeide personenbezogene Daten und urheberrechtlich geschützte Inhalte in großem Maßstab, und nutze das nie, um an einem Login oder einer Paywall vorbeizukommen. Das ist keine Rechtsberatung.