Fehler 429 beim Parsen: 6 Gründe neben Proxy

Sie wechseln Proxys, kaufen einen neuen Pool von IP-Adressen, und der Parser fällt trotzdem mit dem Fehler 429 Too Many Requests aus? Dies ist eine klassische Situation: 70% der Sperrfälle sind nicht mit der IP-Adresse verbunden, sondern mit der Art und Weise, wie die Anfrage selbst aussieht. Wir untersuchen sechs reale Gründe, warum die Website Sie weiterhin sperrt, selbst nach dem Wechsel des Proxys – und was in jedem Fall zu tun ist.

Was bedeutet der Fehler 429 und warum sind Proxys keine Allheilmittel

Der HTTP-Code 429 Too Many Requests bedeutet formal „Anfragenlimit überschritten“. In der Praxis verwenden Websites – insbesondere Wildberries, Ozon, Avito, Yandex.Market – diesen Code als universelles Signal „wir glauben, dass Sie ein Bot sind“. Der Grund kann in der Anfragefrequenz liegen, aber ebenso gut in den Headern, dem Fingerabdruck des Browsers, dem Fehlen von Cookie-Sessions oder in Limits, die nicht an die IP, sondern an Ihr Konto gebunden sind.

Genau deshalb hilft der Wechsel des Proxys oft nicht: Wenn das System nicht die IP, sondern das Muster der Anfrage (Fingerprint, Header, Klickgeschwindigkeit) blockiert, erhalten Sie von der neuen IP-Adresse nach ein paar Minuten dasselbe 429. Lassen Sie uns jeden Grund im Detail untersuchen und zeigen, wie man ihn überprüfen und beheben kann, ohne einen neuen Proxy-Pool zu kaufen.

Wichtig: Proxys bleiben ein notwendiges Werkzeug – aber nur als Teil eines Systems, nicht als einzige Lösung. Residente und mobile IPs verringern die Wahrscheinlichkeit, auf IP-Reputationsschwarze Listen zu geraten, schützen jedoch nicht vor Blockierungen aufgrund von Verhalten oder Headern.

Grund 1: Zu hohe Anfragefrequenz

Der offensichtlichste, aber auch am häufigsten falsch diagnostizierte Grund. Viele denken: „Da ich den Proxy für jede Anfrage wechsle, ist die Frequenz nicht wichtig.“ Das ist falsch. Moderne Anti-Bot-Systeme (zum Beispiel verwenden Wildberries und Ozon Lösungen auf Cloudflare-Ebene oder eigene WAF) analysieren nicht nur die Frequenz von einer IP, sondern auch die gesamte Last auf einem bestimmten API-Endpunkt oder Produktseite über einen bestimmten Zeitraum aus allen Quellen in Kombination mit Verhaltenssignalen.

Wenn Ihr Parser 50-100 Anfragen pro Sekunde an denselben Katalogbereich sendet, sieht das System einen anomalen Traffic-Anstieg, unabhängig davon, wie viele verschiedene IPs Sie verwenden. Die Lösung besteht nicht im Wechsel des Proxys, sondern in der Einführung von künstlichen Verzögerungen (Throttling) zwischen den Anfragen: 1-3 Sekunden zufällige Verzögerung anstelle eines festen Intervalls, plus exponentielles Backoff bei Erhalt von 429 (Verdopplung der Pause nach jeder Blockierung).

import time, random

def safe_request(session, url):
    for attempt in range(5):
        response = session.get(url)
        if response.status_code == 429:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        return response
    return None

Wenn Sie einen fertigen Parser ohne Code verwenden (zum Beispiel einen Cloud-Service zur Preisüberwachung), überprüfen Sie die Einstellungen für das Intervall zwischen den Anfragen – die meisten solcher Tools haben einen Schieberegler „Scan-Geschwindigkeit“. Eine Reduzierung der Geschwindigkeit um 30-40% beseitigt oft das 429 vollständig, selbst ohne den Proxy zu wechseln.

Grund 2: Falsche oder fehlende Header

Viele Parser senden Anfragen mit einem minimalen Satz von Headern oder verwenden den standardmäßigen User-Agent der Bibliothek (zum Beispiel „python-requests/2.28.1“). Ein solcher Header verrät sofort einen Bot – ein echter Browser sendet Dutzende von Headern: Accept, Accept-Language, Accept-Encoding, Sec-Fetch-*, Referer und andere in einer bestimmten Reihenfolge.

Wildberries und Ozon vergleichen die Header mit dem erwarteten „Fingerprint“ eines echten Browsers wie Chrome oder Safari. Wenn die Header zu wenige sind, nicht in der richtigen Reihenfolge oder der User-Agent nicht mit den anderen Parametern übereinstimmt (zum Beispiel wird Chrome auf Windows angegeben, aber der TLS-Fingerabdruck ähnelt Python) – wird die Anfrage mit 429 blockiert, unabhängig von der IP.

Header	Typischer Fehler	Lösung
User-Agent	Veraltete Version oder offensichtlich bibliotheksbezogene Zeichenfolge	Aktueller UA eines echten Chrome/Safari, Rotation aus dem Pool
Accept-Language	Fehlt oder stimmt nicht mit der Geolokalisierung der IP überein	ru-RU für russische Marktplätze
Referer	Leer, obwohl echte Übergänge immer mit Referer erfolgen	Die vorherige Katalogseite angeben
Sec-Fetch-*	Völlig fehlend (kein Browser-Client)	Vollständigen Satz aus den DevTools eines echten Browsers kopieren

Am einfachsten ist es, den vollständigen Satz von Headern aus dem Tab Netzwerk in den DevTools eines echten Browsers zu kopieren, indem Sie die gewünschte Seite manuell öffnen, und genau diesen Satz im Parser zu verwenden – unter Berücksichtigung der Reihenfolge der Header, wenn die Bibliothek dies zulässt (zum Beispiel curl_cffi oder httpx mit expliziter Reihenfolge).

Grund 3: Fehlende Rotation von Sessions und Cookies

Ein Fehler, der oft übersehen wird: Der Parser wechselt die IP für jede Anfrage, verwendet aber dieselbe Cookie-Session oder speichert überhaupt keine Cookies. Ein echter Benutzer erhält beim ersten Besuch ein Set von Cookies (Sitzungstoken, Geräte-IDs, Antibot-Schutzmarken wie Cloudflare __cf_bm oder ähnliche bei Ozon/WB) und verwendet diese in allen nachfolgenden Anfragen innerhalb der Sitzung.

Wenn Sie eine Anfrage ohne Cookies senden, die auf einer „aufgewärmten“ Seite erhalten wurden, sieht das Anti-Bot-System eine „null“ Sitzung – und das ist sofort verdächtig, insbesondere bei direkten Anfragen an API-Endpunkte, ohne die Hauptseite zu besuchen. Die Lösung besteht darin, das vollständige Szenario zu emulieren: Zuerst die Hauptseite oder die Kategorieseite laden, Cookies erhalten, 1-2 Sekunden warten und dann erst die gewünschte API oder Produktkarte ansprechen, wobei die Cookies innerhalb derselben Sitzung während der Anfragekette gespeichert werden.

import requests

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Accept-Language": "ru-RU,ru;q=0.9"
})

# Sitzung aufwärmen
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# Hauptanfrage bereits mit Cookies
response = session.get(target_url)

Wenn Sie einen Anti-Detekt-Browser wie Dolphin Anty oder AdsPower verwenden, um Produktkarten manuell oder über integrierte Automatisierung zu überwachen, stellen Sie sicher, dass das Profil Cookies zwischen den Sitzungen speichert und nicht jedes Mal „von Grund auf neu“ gestartet wird – das löst ebenfalls Verdacht im System aus.

Grund 4: Bot-ähnliches Verhalten

Selbst mit perfekten Headern und Cookies kann der Parser sich durch Verhaltensmuster zu erkennen geben: strikte lineare Reihenfolge beim Zugriff auf Produkte (nach ID aufsteigend), identischer Abstand zwischen Anfragen bis zur Millisekunde, Fehlen von „Müll“-Anfragen an statische Ressourcen (Bilder, CSS, JS), die ein normaler Browser automatisch lädt.

Fortgeschrittene Schutzsysteme von Wildberries und Ozon analysieren nicht nur HTTP-Anfragen, sondern auch, ob JavaScript auf der Seite ausgeführt wurde (durch Headless-Erkennung), ob die „Maus“ bewegt wurde, ob gescrollt wurde. Wenn Sie reine HTTP-Anfragen ohne JS-Rendering durchführen und die Website die Ausführung eines Skripts zur Token-Erfassung erwartet (zum Beispiel ein Anti-Bot-JavaScript-Challenge), erhält die Anfrage ohne Ausführung dieses Skripts automatisch 429 oder 403.

Die Lösung hängt vom Umfang ab: Für kleine Mengen eignet sich die Verwendung eines Headless-Browsers (Playwright, Puppeteer) mit Emulation von Mausbewegungen und zufälligen Verzögerungen. Für industrielles Parsen – Randomisierung der Reihenfolge beim Durchlaufen von Produkten, Hinzufügen von „Rausch“-Anfragen an sekundäre Ressourcen, Variabilität der Zeitintervalle nach normaler Verteilung und nicht nach festem Schritt.

Grund 5: TLS/JA3-Fingerabdruck und HTTP/2

Dies ist der „unauffälligste“ technische Grund, von dem 90% der Personen, die ohne tiefgehende technische Ausbildung parsen, nichts wissen. Jeder TLS-Client (Bibliothek requests, curl, urllib) hinterlässt einen einzigartigen Fingerabdruck bei der Herstellung einer HTTPS-Verbindung – eine Reihe unterstützter Verschlüsselungen, Protokollversionen, TLS-Erweiterungen. Dieser Fingerabdruck wird als JA3/JA4-Fingerabdruck bezeichnet.

Anti-Bot-Systeme auf Cloudflare-, Akamai- und eigenen Lösungen großer Marktplätze vergleichen den JA3-Fingerabdruck mit einer Datenbank bekannter Bots und Bibliotheken. Standard-Python-Requests oder Node.js-HTTPS-Module haben einen leicht erkennbaren Fingerabdruck, der sich vollständig vom Fingerabdruck eines echten Chrome unterscheidet. Selbst mit perfekten Headern und Cookies wird die Anfrage genau auf der Ebene des TLS-Handshakes blockiert, bevor der Server die HTTP-Header sieht.

Darüber hinaus verlangen viele Marktplätze HTTP/2 mit bestimmten Parametern (Reihenfolge der SETTINGS-Frames, Priorisierung von Streams) – Bibliotheken, die auf HTTP/1.1 basieren, heben sich automatisch hervor. Die Lösung besteht darin, Bibliotheken zu verwenden, die den Fingerabdruck eines echten Browsers emulieren: curl_cffi (emuliert den TLS-Fingerabdruck von Chrome), tls-client oder vollwertige Headless-Browser auf Chromium-Basis, die per Definition einen „echten“ Fingerabdruck liefern.

pip install curl_cffi

Beispiel: curl_cffi.requests.get(url, impersonate="chrome120") – die Bibliothek setzt automatisch den TLS-Fingerabdruck ein, der dem echten Chrome 120 entspricht.

Grund 6: Limit auf Konto- oder API-Schlüssel-Ebene

Wenn Sie über die offizielle oder halb-offizielle API des Marktplatzes arbeiten (zum Beispiel die API des Verkäufers von Wildberries oder die Ozon Seller API), kann 429 nicht an die IP, sondern an das Verkäuferkonto oder den API-Token gebunden sein. In diesem Fall ist der Wechsel des Proxys völlig sinnlos – das Limit wird serverseitig an Ihre Kontokennung gebunden gespeichert, und jede IP von diesem Konto erhält dasselbe Limit.

Eine solche Situation ist typisch für Verkäufer, die gleichzeitig die Preise von Wettbewerbern über ihr persönliches Konto überwachen und die API für die Abfrage von Beständen nutzen – beide Anfrageflüsse summieren sich auf das Gesamtkonto-Limit. Die Lösung besteht darin, die Last zeitlich zu verteilen, die offiziellen API-Quoten wirtschaftlicher zu nutzen (Daten cachen, die sich nicht jede Minute ändern) und für die reine Überwachung der Preise von Wettbewerbern einen separaten nicht autorisierten Anfragefluss zu verwenden, der nicht an das Verkäuferkonto gebunden ist.

Dies zu überprüfen ist einfach: Wenn 429 weiterhin auftritt, selbst wenn Sie von einer neuen, sauberen IP ohne Cookies aus vorherigen Sitzungen anfragen, aber Sie in einem anderen Tab in Ihrem persönlichen Konto angemeldet sind – ist das Limit höchstwahrscheinlich kontobezogen.

Wie man die tatsächliche Ursache diagnostiziert

Bevor Sie die Infrastruktur ändern, führen Sie eine Diagnose nach folgendem Algorithmus durch. Öffnen Sie zunächst die Seite manuell in einem normalen Browser und stellen Sie sicher, dass 429 nicht auftritt, wenn Sie sich wie ein echter Benutzer verhalten – dies bestätigt, dass das Problem auf der Seite des Parsers liegt und nicht eine globale Blockierung der Region ist.

Vergleichen Sie dann die Header Ihres Parsers mit den Headern eines echten Browsers über die DevTools (Tab Netzwerk → Als cURL kopieren). Wenn der Unterschied minimal ist, überprüfen Sie den TLS-Fingerabdruck über Dienste wie tls.peet.ws – senden Sie eine Anfrage mit Ihrer Bibliothek und vergleichen Sie den JA3-Hash mit dem eines Referenzbrowsers. Wenn die Anfrage in der Phase des TLS-Handshakes fehlschlägt (die Verbindung wird vor Erhalt der HTTP-Antwort abgebrochen) – liegt der Grund im Fingerabdruck und nicht in der Frequenz oder den Headern.

Überprüfen Sie anschließend, ob das Limit an die IP oder an das Konto gebunden ist: Stellen Sie eine Anfrage von einer neuen, sauberen IP ohne Authentifizierung. Wenn 429 verschwindet – lag das Problem an der Reputation der vorherigen IP oder an der Frequenz von dieser Adresse. Wenn 429 bleibt – suchen Sie den Grund in den Headern, TLS oder Verhalten und nicht in den Proxys.

Checkliste zur Behebung von 429 ohne Proxy-Wechsel

Fügen Sie zufällige Verzögerungen von 1-4 Sekunden zwischen den Anfragen anstelle eines festen Intervalls hinzu.
Kopieren Sie den vollständigen Satz von Headern eines echten Browsers, einschließlich Sec-Fetch-* und Accept-Language.
Speichern und übergeben Sie Cookies innerhalb einer Sitzung, beginnend mit dem Aufwärmen der Hauptseite.
Überprüfen Sie den TLS-Fingerabdruck Ihrer Bibliothek – verwenden Sie curl_cffi oder einen Headless-Browser anstelle eines reinen HTTP-Clients.
Randomisieren Sie die Reihenfolge beim Durchlaufen der Seiten und fügen Sie „Rausch“-Anfragen an statische Ressourcen hinzu.
Teilen Sie die Last des API-Kontos und der anonymen Preisüberwachung auf verschiedene Ströme auf.
Implementieren Sie exponentielles Backoff bei Erhalt von 429, anstatt die Anfrage sofort zu wiederholen.
Ändern Sie erst nach Überprüfung aller oben genannten Punkte den Proxy oder erweitern Sie den IP-Pool.

Wann Proxys dennoch benötigt werden und welche zu wählen sind

Nach der Behebung aller sechs Gründe bleiben Proxys ein wichtiges Element der Infrastruktur – jedoch als Mittel zur Skalierung und nicht als einzige Möglichkeit, Blockierungen zu bekämpfen. Wenn Ihre Aufgabe darin besteht, Tausende von Wildberries- und Ozon-Karten parallel von verschiedenen „virtuellen Benutzern“ zu überwachen, benötigen Sie einen Pool von IPs mit guter Reputation, um keine Historie von Blockierungen auf einer Adresse anzusammeln.

Für die Massenüberwachung von Preisen und Katalogen von Marktplätzen sind residente Proxys am besten geeignet – sie verwenden echte IPs von lokalen Anbietern, weshalb Anti-Bot-Systeme die Anfragen als Traffic von normalen Käufern und nicht von Rechenzentren wahrnehmen. Dies ist entscheidend, da Wildberries und Ozon seit langem schwarze Listen für IP-Bereiche von Rechenzentren führen.

Wenn die Aufgabe mit der Überprüfung der mobilen Version der Website, der Arbeit über die Marktplatz-App oder der Werbung in TikTok Ads und Facebook Ads mit geografischer Genauigkeit bis zur Stadt verbunden ist, sind mobile Proxys relevant – sie haben das höchste Vertrauensniveau bei den meisten Schutzsystemen, da die IPs echten Mobilfunkbetreibern gehören.

Für weniger empfindliche Aufgaben – zum Beispiel das Parsen von offenen Katalogen ohne Authentifizierung in kleinen Mengen – können Rechenzentrums-Proxys verwendet werden: Sie sind deutlich günstiger und schneller, erfordern jedoch eine sorgfältigere Konfiguration der Header und des TLS-Fingerabdrucks, da sie selbst ein höheres Risiko bergen, unter Verdacht zu geraten.

Proxy-Typ	Wann löst es 429	Wann hilft es nicht
Residente	IP bereits aufgrund von Reputation auf der schwarzen Liste	Blockierung aufgrund von TLS-Fingerabdruck oder Headern
Mobile	Maximale Vertrauenswürdigkeit der IP für empfindliche Szenarien erforderlich	Limit ist an das Konto und nicht an die IP gebunden
Rechenzentrum	Einfaches Parsen offener Seiten ohne Authentifizierung	Strenge Anti-Bot-Systeme mit Überprüfung der Reputation von Bereichen

Fazit

Der Fehler 429 beim Parsen wird selten mit einem einzigen Klick auf „Proxy wechseln“ behoben. In den meisten Fällen liegt das Problem in der Anfragefrequenz, unvollständigen Headern, fehlenden Cookie-Sessions, erkennbaren TLS-Fingerabdrücken, Verhaltensmustern oder Limits, die an das Konto und nicht an die IP-Adresse gebunden sind. Führen Sie eine Diagnose zu jedem der sechs Punkte in diesem Artikel durch, bevor Sie Ihr Budget für die Erweiterung des Proxy-Pools ausgeben.

Wenn der technische Teil richtig konfiguriert ist – die Header mit einem echten Browser übereinstimmen, der TLS-Fingerabdruck die Bibliothek nicht verrät und die Anfragen das natürliche Verhalten eines Benutzers imitieren – werden Proxys zu einem wirklich effektiven Werkzeug zur Skalierung. Für die Preisüberwachung auf Wildberries und Ozon in industriellen Mengen empfehlen wir, mit residierenden Proxys zu beginnen: Sie bieten das beste Gleichgewicht zwischen Kosten und Vertrauensniveau der Anti-Bot-Systeme.