Warum Ihr Scraper nach 10.000 Anfragen versagtdie Fehlermodi, die bei Volumen auftauchen

Ein Scraper, der die erste Seite problemlos durchläuft, bricht bei Volumen oft zusammen. Das Skript läuft sauber gegen zehn URLs im Test, wird ausgeliefert, und dann sinkt die Erfolgsrate irgendwo nach der zehntausendsten Anfrage still: leere Textkörper, CAPTCHA-Weiterleitungen, halb gefüllte Datensätze, ein Worker, der nach stundenlangem Laufen abstürzt. Nichts im Code hat sich geändert. Was sich geändert hat, ist, dass die Website begann, den Traffic als Muster statt als Besucher zu behandeln.

Dieser Leitfaden geht die Fehlermodi durch, die nur bei Volumen auftauchen: IP-Reputation und Sperren, CAPTCHA-Wände, Fingerabdruck- und TLS-Erkennung, Session-Ablauf, Selektor-Drift, JavaScript-gerenderter Inhalt, Ressource-Leaks und fehlende Wiederholungslogik, und paart jeden mit einer konkreten Lösung. Am Ende weiß man, warum sich derselbe Code bei zehn Anfragen und zehntausend anders verhält, und welche dieser Probleme es wert ist, selbst zu lösen, versus sie an eine verwaltete Schicht zu übergeben.

Warum Scraper im großen Maßstab versagen

Bei niedrigem Volumen hat eine Website kaum Grund, sich um einen zu kümmern. Die Handvoll Anfragen vermischt sich mit dem gewöhnlichen Hintergrundverkehr, sodass selbst ein schlampiger Scraper, bare Header, eine IP, kein Timing, durchkommt und einem falsches Vertrauen gibt. Das Problem ist, dass Anti-Bot-Systeme einzelne Anfragen nicht isoliert bewerten. Sie profilieren Verhalten über eine Session und über eine IP hinweg im Laufe der Zeit, und dieses Profil schärft sich, wenn die Anfrageanzahl steigt.

Jenseits von einigen Tausend Anfragen verschieben sich mehrere Dinge gleichzeitig. Das Traffic-Muster wird statistisch verschieden vom menschlichen Surfen, Pro-IP-Schwellen werden ausgelöst, IP-Reputation verschlechtert sich, da die Adresse mehr automatisierte Aktivität protokolliert, und kleine Inkonsistenzen, die eine einzelne Anfrage nie offenbaren würde, akkumulieren sich zu einem überzeugten "das ist ein Bot"-Urteil. Die Abwehr hat sich nicht bei Anfrage 10.000 eingeschaltet; man hat einfach das Volumen überschritten, bei dem sie genug Signal hatte, um zu handeln. Die folgenden Lösungen drängen alle in eine Richtung: jede Anfrage wie einen echten Browser aussehen lassen und die Pipeline die Fehler überleben lassen, die jetzt unvermeidlich sind.

Die Fehlerarten und wie man jede behebt

1. IP-Ratenbegrenzung und Sperren

Die erste Wand ist Volumen von einer einzelnen Adresse. Websites zählen Anfragen pro IP und reagieren, wenn eine Quelle zu beschäftigt aussieht: Rate Limits begrenzen Anfragen in einem Zeitfenster und beginnen, 429er zurückzugeben, und sobald eine Adresse in "missbräuchliches" Territorium wechselt, wird sie vollständig auf die schwarze Liste gesetzt. Reputation verstärkt das Problem. Bot-Mitigation-Systeme verfolgen die ASN hinter einer IP, ob sie aus einem Datacenter-, Residential- oder Mobile-Pool kommt und das historische Verhalten dieses Bereichs, sodass ein markierter Pool jede Adresse darin herunterzieht.

Lösung. Anfragen über viele Adressen verteilen, damit keine einzelne IP eine sperrbare Signatur zeigt. Ein rotierender Proxy-Pool, der Residential- und Datacenter-IPs mischt, verteilt Last, umgeht Pro-IP-Rate Limits und routet durch verschiedene Regionen, um geo-gesperrten Inhalt zu erreichen. Rotation allein ist jedoch kein Allheilmittel: Wenn man schneller rotiert und dabei dasselbe roboterhafte Timing und dieselben Header beibehält, verbrennt man nur Adressen schneller. Man paart Rotation mit dem Pacing im nächsten Abschnitt. Siehe wie man rotierende Proxys verwendet für die Einrichtung.

2. CAPTCHA-Sperren

Wenn eine Website Automatisierung vermutet, hört sie auf zu blockieren und beginnt zu challengen: reCAPTCHA, hCaptcha, FunCaptcha oder ein Klick-und-Zieh-Puzzle. Bei Volumen erscheinen diese nicht nur beim Login, sondern mitten im Crawl auf gewöhnlichen Inhaltsseiten, und ein Scraper, der auf einen stößt, stagniert einfach, oder schlimmer, folgt der Weiterleitung und beginnt Challenge-Seiten zu sammeln, als wären es Daten.

Lösung. Die dauerhafte Lösung ist, die Challenge von vornherein zu vermeiden, indem man wie ein echter Browser aussieht: realistische Header, beibehaltene Cookies, getaktete Anfragen und eine vertrauenswürdige IP. CAPTCHAs im Nachhinein zu lösen ist ein Verlierrennen; sie zu verhindern ist der Gewinn. Wenn eine auftaucht, erkennt man sie explizit, behandelt eine Challenge-Seite als Fehler statt als Erfolg und routet um sie herum statt sie zu parsen. Wie man CAPTCHAs beim Web Scraping umgeht behandelt die Mechanik.

3. Fingerprint- und TLS-Erkennung

Moderne Erkennung geht weit über das Zählen von Anfragen hinaus. Anti-Bot-Systeme profilieren die Anfrage selbst: die Reihenfolge und Vollständigkeit der Header, den TLS-Handshake, den der Client erzeugt (seine JA3-Signatur), Client Hints und ob all das mit dem User-Agent übereinstimmt, den man angibt. Ein Scraper, der einen Chrome-User-Agent über den TLS-Fingerabdruck eines Python-HTTP-Clients sendet, widerspricht sich selbst, und diese Diskrepanz ist trivial zu markieren. Verhaltens-Signale häufen sich an, da eine Session, die nie eine Maus bewegt, nie ein sekundäres Asset lädt und Anfragen nach einem Metronom abfeuert, als synthetisch erscheint.

Lösung. Von einer sauberen IP zu kommen reicht nicht aus; die Anfrage muss von Ende zu Ende wie ein echter Browser lesen. Man sendet ein vollständiges, konsistentes Header-Set, bewahrt Cookies über die Session und stellt nie eine Kombination aus Headern und TLS zusammen, die kein echter Browser erzeugt. Einen Fingerabdruck über jedes Attribut hinweg konsistent zu halten ist wirklich schwer, was genau die Lücke ist, die Detektoren ausnutzen, sodass das einer der stärksten Gründe ist, an eine Schicht auszulagern, die echte Browser-Fingerabdrücke für einen pflegt. Browser-Fingerprinting erklärt, womit man es zu tun hat.

4. Ablauf von Sitzungen und Cookies

Lange Läufe führen einen Fehler ein, den kurze Tests nie erreichen: Sessions werden abgestanden. Authentifizierte Cookies laufen ab, CSRF-Tokens rotieren und session-gebundener Zustand, der an eine einzelne IP gebunden ist, bricht in dem Moment, in dem man zu einer neuen Adresse mitten im Ablauf rotiert. Ein Scraper, der sich zu Beginn eines Million-Seiten-Jobs authentifiziert hat und annahm, die Session würde halten, sammelt in Stunde zwei Weiterleitungen zu einer Login-Seite.

Lösung. Sessions bewusst verwalten. Man meldet sich einmal an, bewahrt die Cookies und wiederverwendet diese Session statt sich bei jeder Anfrage neu zu authentifizieren, erkennt aber auch Ablauf, beobachtet die Login-Weiterleitung oder das gelöschte Token und erneuert Zugangsdaten vor dem nächsten Batch. Wenn ein Ablauf eine Session an eine IP bindet, pinnt man diese Session an eine einzelne klebrige Adresse statt darin zu rotieren, sodass die Website einen konsistenten Besucher für die Lebensdauer der Session sieht.

5. Selektor-Drift durch Markup-Änderungen

Sogar ein makellos funktionierender Scraper bricht in dem Moment, in dem das Ziel neu gestaltet wird. Websites benennen Klassen um, strukturieren das DOM um und ordnen Endpunkte neu an, um ihr eigenes Produkt zu verbessern, und jede solche Änderung kann einen Selektor stumm abbrechen, von dem der Parser abhing. Bei Volumen ist das kein "ob" sondern ein "wann", und über viele Websites hinweg passiert es ständig: Skripte, die gestern funktionierten, geben heute leere Felder zurück, ohne Fehler, der es ankündigt.

Lösung. Defensiv parsen. Man bevorzugt stabile, semantische Selektoren und dauerhafte Attribute gegenüber spröden, tiefen CSS-Pfaden, die jedes Redesign verschieben wird. Man validiert jede Extraktion, behauptet, dass erforderliche Felder vorhanden und gut typisiert sind, sodass ein fehlendes Feld eine Warnung auslöst statt ein Null in den Datensatz zu schreiben. Man hält Parser modular, sodass die Änderung einer Website einen Parser berührt, nicht die gesamte Pipeline.

6. JavaScript-gerenderte Inhalte

Viele Websites liefern eine fast leere HTML-Hülle und malen den echten Inhalt mit JavaScript nach dem Laden, oft aus einem nachfolgenden API-Aufruf. Ein einfacher HTTP-Fetch greift die Hülle und der Parser findet nichts, weil die Daten nie in der heruntergeladenen Quelle waren. Das erzeugt den verwirrend­sten Fehler bei Volumen: ein sauberes 200 OK auf einer Seite, die funktional leer ist, sodass der Scraper Erfolg meldet, während der Datensatz sich mit Leerzeichen füllt.

Lösung. Zwei Wege funktionieren. Erstens öffnet man den Browser-Netzwerk-Tab und sucht nach der internen JSON-API, die die Seite aufruft; diesen Endpunkt direkt zu treffen ist schneller und weit stabiler als Rendering, und viele "JavaScript-Websites" sind dünne Frontends über einer API, die man abfragen kann. Wenn die Daten nur nach dem Rendering erreichbar sind, steuert man einen headless Browser oder verwendet eine API, die für einen rendert und das fertige HTML zurückgibt. In jedem Fall validiert man den Textkörper vor dem Parsen, da ein 200 mit 700 Bytes und einem "Just a moment"-Titel eine stille Blockierung ist, kein Ergebnis. Siehe wie man JavaScript-Websites crawlt.

7. Speicher- und Verbindungslecks

Manche Scraper werden überhaupt nicht blockiert; sie kollabieren unter dem eigenen Gewicht. Eine Schleife, die pro Anfrage eine neue Verbindung öffnet, ohne zu poolen oder zu schließen, erschöpft Dateideskriptoren und Sockets. Jede Antwort im Speicher anzusammeln, bevor man schreibt, bläht den Prozess auf, bis er beendet wird. Zu hoch eingestellte Parallelität überlastet den eigenen Rechner, bevor sie je das Ziel überlastet. Nichts davon zeigt sich in einem Zehn-URL-Test, weil der Leak Stunden und Tausende von Iterationen braucht, um fatal zu werden.

Lösung. Ressourcen als endlich behandeln. Eine gepoolte HTTP-Session wiederverwenden statt jedes Mal eine neue Verbindung zu öffnen, und sicherstellen, dass Antworten verbraucht und geschlossen werden, damit Sockets zum Pool zurückkehren. Ergebnisse beim Vorankommen in den Speicher streamen statt den vollständigen Datensatz im Arbeitsspeicher zu halten. Parallelität pro Host und insgesamt auf ein Niveau begrenzen, das der eigene Rechner und das Ziel aufrechterhalten können. Das sind gewöhnliche Engineering-Gewohnheiten, aber bei Volumen sind sie der Unterschied zwischen einem Prozess, der tage­lang läuft, und einem, der über Nacht stirbt.

8. Keine Retry- oder Backoff-Logik

Bei Volumen sind vorübergehende Fehler keine Randfall; sie sind konstant. Timeouts, getrennte Verbindungen, gelegentliche 429er oder 503er. Ein Scraper ohne Wiederholungslogik wirft diese Zeilen weg. Ein Scraper, der sofort und aggressiv wiederholt, ist schlimmer, weil eine enge Wiederholungsschleife den Traffic genau in dem Moment verstärkt, in dem die Website bereits zurückdrängt, was die Blockierung beschleunigt. Dieser "Retry Storm" ist einer der häufigsten Wege, wie ein Scraper sich selbst herunterbringt.

Lösung. Wiederholen, aber exponentiell zurückrudern und Jitter hinzufügen, damit die Wiederholungen nicht in einer synchronisierten Welle ankommen. Die Anzahl der Versuche begrenzen, jeden Retry-After-Header respektieren und aufhören, Status-Codes zu wiederholen, die nie erfolgreich sein werden. Ein kleiner Wrapper reicht aus:

import random, time, requests

def fetch(url, attempts=5, base=1.0, cap=30.0):
    for n in range(attempts):
        r = requests.get(url, timeout=30)
        if r.status_code < 400:
            return r
        if r.status_code in (400, 404):
            break  # never going to succeed; do not retry
        delay = min(cap, base * 2 ** n) + random.uniform(0, base)
        time.sleep(delay)  # exponential backoff with jitter
    return None

Dieselbe Idee gilt für Throttling: normale Anfragen mit einer kleinen Jitter-Verzögerung zwischen ihnen pacen, sodass selbst der erfolgreiche Traffic nicht auf einem perfekt gleichmäßigen Takt ankommt, den ein Detektor einrasten kann.

Rotation und Rendering auslagern

Man blickt auf die acht Lösungen zurück und ein Muster entsteht: Die meisten der schwierigsten haben überhaupt nichts mit den eigenen Daten zu tun. Rotation, Fingerabdruck-Konsistenz, CAPTCHA-Vermeidung und Rendering sind undifferenzierte Infrastruktur, ein Wettrüsten, das man gegen jeden Anbieter bei jedem Ziel aufrechthält, getrennt von der Extraktionslogik, die tatsächlich Wert für einen schafft. Alles selbst aufzubauen ist möglich, aber es ist eine ständige Steuer auf Engineering-Zeit, die mit jeder Website, die man hinzufügt, wächst.

Das ist der natürliche Punkt zur Auslagerung. Eine verwaltete Crawling-Schicht trägt Rotation, realistische Fingerabdrücke, optionales JavaScript-Rendering, Challenge-Behandlung und intelligente Wiederholung hinter einer einzelnen Anfrage und gibt sauberes HTML zurück. Man behält das Parsen und die Geschäftslogik, die genuinen die eigenen sind, und lässt die Schicht die Teile absorbieren, die nur existieren, um die Anfrage durchzubringen. Für den breiteren Katalog von Problemen und Kompromissen geht unser Leitfaden zu Web-Scraping-Herausforderungen und -Lösungen breiter.

Monitoring und Alerting

Der Fehlermodus, der bei Volumen am meisten schmerzt, ist der, den niemand sieht. Ein Scraper degradiert zu 200-Antworten mit leeren Textkörpern und halb gefüllten Datensätzen, und die Lücke taucht erst auf, wenn ein nachgelagerter Bericht falsch aussieht, Tage später. Die Lösung ist, Stille laut zu machen. Den Scraper als lebendiges System instrumentieren: Erfolgs- und Fehlerraten pro Domain, Block- und CAPTCHA-Raten, Textkörpergrößen und Durchsatz verfolgen, sodass ein kriechender Anstieg bei 403ern oder ein plötzlicher Rückgang der durchschnittlichen Antwortgröße innerhalb von Minuten eine Warnung auslöst statt nach einem kaputten Lauf. Beim Vorankommen validieren und warnen, wenn ein erforderliches Feld über einen Batch hinweg fehlt, denn eine Strukturänderung sollte einen benachrichtigen, nicht still die Daten vergiften. Die eigentlichen Kosten des Scrapings sind selten der erste Build; es ist, ihn im Laufe der Zeit ehrlich zu halten.

Verantwortungsvolles Scraping

Unblockiert zu bleiben ist zum Teil Zurückhaltung. Man beschränkt sich auf öffentliche Daten, den Inhalt, den jeder ohne Konto sehen kann, und meidet alles hinter einem Login oder alles, das eine Person identifiziert. Man liest die robots.txt des Ziels und dessen angegebene Rate-Erwartungen und hält das Volumen niedrig genug, dass man die Server nicht belastet, da zu schnelles Scrapen eine Website genuinen beeinträchtigen oder zum Absturz bringen kann. Datenschutzgesetze wie DSGVO und CCPA regeln, was man über Personen sammeln darf, und die Nutzungsbedingungen einer Website können Scraping vollständig verbieten, also prüft man beides vor einem großen Lauf. Ein Scraper, der sich wie ein guter Bürger verhält, ist auch einer, der weit länger unblockiert bleibt.

Häufig gestellte Fragen

Warum funktioniert mein Scraper im Test, scheitert aber im großen Maßstab?

Frühe Tests erzeugen nicht genug Traffic, um die Schwellenwerte einer Website auszulösen, sodass selbst ein schlampiger Scraper besteht. Sobald man anhaltende Volumen fährt, wird der Traffic leicht zu profilieren und kleine Inkonsistenzen in Headern, Timing, Fingerabdruck und Session-Verhalten akkumulieren sich zu einem überzeugten Bot-Urteil. Der Code hat sich nicht geändert; man hat einfach den Punkt überschritten, an dem die Abwehr genug Signal hatte, um zu handeln.

Warum erhalte ich 200-OK-Antworten, aber die Daten fehlen?

Das ist gewöhnlich eine stille Blockierung oder nicht gerenderter Inhalt. Der Server gibt einen gültigen Status zurück, aber der Textkörper ist ein Platzhalter, eine Challenge-Seite oder eine leere JavaScript-Hülle statt des echten Inhalts. Die Antwort vor dem Parsen validieren: die Textkörpergröße prüfen und auf verräterische Titel wie "Just a moment" achten, damit ein stiller Fehler zu einem lauten wird statt zu einem Null im Datensatz.

Behebt das Rotieren von Proxys Rate Limiting von allein?

Nicht allein. Rotation verteilt Anfragen, damit keine einzelne IP ein Pro-IP-Limit auslöst, aber wenn man dasselbe roboterhafte Timing und dasselbe Header-Set über den Pool beibehält, ist das Muster noch erkennbar und man verbrennt nur schneller Adressen. Man paart Rotation mit Jitter-Pacing und realistischen, konsistenten Anfragen, damit jede Adresse wie ein gewöhnlicher Besucher aussieht.

Wie sollten Wiederholungsversuche gehandhabt werden, damit sie das Blockieren nicht verschlimmern?

Mit exponentiellem Backoff und Jitter wiederholen, die Anzahl der Versuche begrenzen und jeden Retry-After-Header respektieren. Sofortige, aggressive Wiederholungen erzeugen einen Storm, der Traffic genau dann verstärkt, wenn die Website bereits zurückdrängt, was die Blockierung beschleunigt. Außerdem überspringt man das Wiederholen von Status-Codes wie 404, die nie erfolgreich sein werden.

Wann sollte ich JavaScript rendern, statt rohes HTML abzurufen?

Rendern, wenn die benötigten Daten nach dem Laden von JavaScript gemalt werden oder wenn die Website auf Skripte angewiesen ist, um Session-Cookies zu setzen oder das echte HTML zu entsperren. Bevor man zu einem headless Browser greift, prüft man, ob die Seite ihre Daten von einer internen JSON-API lädt, die man direkt aufrufen kann, da das schneller und weit stabiler ist. Rohe Fetches sind in Ordnung, wenn der Inhalt bereits in der Quelle vorhanden ist.

Wann lohnt sich das Auslagern an eine verwaltete Crawling API?

Wenn die Wartung von Rotation, Fingerabdrücken, Rendering und Challenge-Behandlung mehr kostet als die Daten wert sind, oder wenn man über viele Websites hinweg skaliert und nicht jede einzelne patchen kann. Eine verwaltete Schicht trägt diese Infrastruktur hinter einer einzelnen Anfrage, sodass das eigene Team auf Extraktion und Geschäftslogik fokussiert bleibt statt auf die undifferenzierte Arbeit, Anfragen durchzubringen.

IK

Ian Kalvin

Technical Support Engineer · Crawlbase

Technical Support Engineer bei Crawlbase, der von der Front darüber schreibt, was beim Scraping und bei Proxy-Setups im Produktivbetrieb tatsächlich kaputtgeht.

NZ

Neil Zamora

Senior Architect · Crawlbase

Senior Architect bei Crawlbase mit Fokus auf den Systemen hinter großflächigem Crawling: Proxy-Rotation, Anti-Bot-Resilienz und den APIs, die diese Komplexität verbergen.