Traffic-Limit für das Scraping von Wildberries und Ozon: So verlieren Sie kein monatliches Proxy-Paket über Nacht

Der Verkäufer startet den Preisparser für die Konkurrenz über Nacht und erhält am Morgen die Benachrichtigung: Der Traffic ist aufgebraucht, das Paket ist zu 90 % erschöpft. Kommt Ihnen diese Situation bekannt vor? Meistens ist nicht der Parser selbst schuld, sondern das Fehlen von Limits auf Proxy- und Skriptebene. In diesem Artikel werden wir untersuchen, wie der Traffic „verloren geht“ und wie man Schutzmaßnahmen einrichtet, damit das monatliche Paket an Residential- oder Mobil-Proxys bis zum Ende des Abrechnungszeitraums ausreicht.

Warum der Traffic über Nacht aufgebraucht wird

Das Scraping von Wildberries, Ozon oder Avito scheint eine einfache Aufgabe zu sein: Anfrage gesendet — JSON mit dem Preis erhalten. In der Praxis wird der Traffic jedoch nicht nur für nützliche Daten verwendet. Die Hauptquellen für Überverbrauch sind:

• Bild- und Medienladen. Wenn der Parser die Produktseite vollständig über den Browser öffnet (anstatt eine direkte Anfrage an die API zu stellen), lädt er automatisch Bilder, Videos, Banner — das sind Dutzende von Megabyte pro Produktkarte.
• Wiederholte Anfragen aufgrund von Captchas und Sperren. Der Marktplatz erkennt den Bot, gibt ein Captcha oder eine vorübergehende IP-Sperre aus, das Skript sendet eine Wiederholungsanfrage — der Traffic wird umsonst verbraucht, und die Daten kommen nicht an.
• Fehlendes Caching von Anfragen. Ohne die Logik „bereits in dieser Stunde gescraped — nicht wiederholen“ kann das Skript dieselben Karten mehrmals über Nacht abfragen.
• Parallele Streams ohne Begrenzung. Das Starten von 50-100 Streams gleichzeitig scheint die Arbeit zu beschleunigen, aber der Traffic wird dabei viel schneller verbraucht als geplant, und ein Teil der Anfragen wird einfach blockiert.
• Falsche Wahl des Proxy-Typs. Residential- und Mobil-Proxys werden normalerweise nach Traffic-Volumen (GB) abgerechnet, im Gegensatz zu Datacenter-Proxys, bei denen die Zahlung häufiger nach Anzahl der IPs oder Mietzeit erfolgt. Wenn der Parser auf einen Residential-Pool ohne Kontrolle eingestellt ist, wird das Limit schnell aufgebraucht.

Eine Kombination dieser Faktoren führt dazu, dass ein Skript, das für einen Monat Arbeit ausgelegt ist, das Traffic-Paket in einer nächtlichen Scraping-Session von 10-20 Tausend Produktkarten verbraucht.

Wie der Traffic bei verschiedenen Proxy-Typen berechnet wird

Bevor Sie Limits festlegen, ist es wichtig zu verstehen, wofür Sie tatsächlich bezahlen. Verschiedene Proxy-Typen berücksichtigen den Verbrauch unterschiedlich, und das hat direkte Auswirkungen auf die Sparstrategie.

Proxy-Typ	Abrechnung	Risiko des Überverbrauchs	Wann anwenden
Residential-Proxys	Nach Traffic-Volumen (GB)	Hoch ohne Limits	Scraping mit Umgehung des Anti-Bot-Schutzes von Marktplätzen
Mobile Proxys	Nach Traffic-Volumen oder Zeit	Hoch, Traffic ist teurer	Scraping von mobilen Versionen von Websites, Umgehung strenger Sperren
Datacenter-Proxys	Nach Anzahl der IPs / Mietzeit	Niedrig, Traffic ist normalerweise unbegrenzt	Massenscraping ohne strengen Anti-Bot-Schutz

Wenn Sie Wildberries oder Ozon scrapen, wo der Bot-Schutz aktiv ist, sind Residential- oder Mobil-IP fast immer notwendig — Datacenter-Adressen werden schnell blockiert. Aber gerade wegen der Abrechnung nach Traffic ist es hier besonders wichtig, die Limits im Voraus festzulegen.

Wie viel Traffic tatsächlich für das Scraping benötigt wird

Um ein angemessenes Limit festzulegen, sollten Sie sich an realistischen Zahlen orientieren, nicht an Gefühlen. Die ungefähren Ausgaben in der Praxis:

• Anfrage an die API der Produktkarte (JSON, ohne Bilder): 5-30 KB pro Karte. Bei 10.000 Karten — etwa 50-300 MB.
• Seitenladung des Produkts über einen Headless-Browser mit Bildern: 1-3 MB pro Karte. Bei denselben 10.000 Karten — 10-30 GB.
• Preisüberwachung einmal pro Stunde für 1000 SKU: bei vereinfachten Anfragen — etwa 1-5 GB pro Tag, bei vollständiger Seitenladung — 50-100 GB pro Tag.

Der Unterschied zwischen „leichtem“ und „schwerem“ Scraping ist um ein Vielfaches. Daher ist der erste Schritt zur Einsparung von Traffic — das Laden von Bildern, Videos und externen Skripten dort, wo es möglich ist, zu deaktivieren und direkt mit der API des Marktplatzes oder der mobilen Version der Website zu arbeiten, die weniger wiegt als die Desktop-Version.

Limits in Anti-Detect-Browsern und Proxy-Managern

Für diejenigen, die über einen Anti-Detect-Browser (z. B. Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) oder einen eigenen Proxy-Manager scrapen, ist der einfachste Weg, den Verbrauch zu begrenzen, Limits auf Profil- und Proxy-Anbieter-Kontoebene festzulegen.

1. Loggen Sie sich in das persönliche Konto Ihres Proxy-Anbieters ein und suchen Sie den Abschnitt zur Verwaltung des Traffics oder der Limits für Sub-Nutzer/Ports.
2. Erstellen Sie ein separates Sub-Konto oder einen Port für das Scraping — verwenden Sie nicht denselben Proxy-Pool wie für das Farming von Konten in Instagram oder TikTok. Die Trennung nach Aufgaben zeigt sofort, wohin der Traffic fließt.
3. Setzen Sie ein tägliches oder stündliches Traffic-Limit für dieses Sub-Konto — zum Beispiel 5 GB pro Tag, anstatt das gesamte monatliche Paket in einer Sitzung zu verbrauchen.
4. Deaktivieren Sie im Anti-Detect-Browser das automatische Laden von Bildern für Profile, die ausschließlich zur Datensammlung verwendet werden, nicht zur visuellen Ansicht von Seiten.
5. Planen Sie den Start der Profile so, dass das Scraping nicht in einer langen Sitzung erfolgt, sondern in kurzen Intervallen mit Pausen — dies verringert das Risiko einer Sperre und gibt Zeit, den Traffic-Verbrauch zwischen den Starts zu überwachen.

Dieser Ansatz ist besonders wichtig für Agenturen und Freelancer, die gleichzeitig mehrere Marktplätze scrapen: Ohne die Trennung nach Sub-Konten ist es schwierig zu verstehen, welches Projekt den Traffic „verbraucht“.

Traffic-Limit auf Skriptebene und API

Wenn der Parser selbst in Python oder Node.js geschrieben ist, können und sollten Limits direkt in den Code integriert werden — dies ermöglicht eine genauere Kontrolle als die Einstellungen der Benutzeroberfläche des Proxy-Anbieters.

Ein Beispiel für einen einfachen Traffic-Zähler in Python unter Verwendung von requests:

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # Limit 5 GB pro Tag
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("Tägliches Traffic-Limit erreicht, Scraping gestoppt")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# Beispielaufruf
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("Verbrauchter Traffic:", round(used_bytes / 1024 / 1024, 2), "MB")

Die Logik ist einfach: Das Skript zählt das Volumen jeder Antwort in Bytes und stoppt, sobald das festgelegte Limit erreicht ist. Dies schützt vor Situationen, in denen das Skript aufgrund eines Fehlers in einer Schleife oder einer endlosen Wiederholung von Anfragen das monatliche Traffic-Paket in wenigen Stunden „verbraucht“.

Zusätzlich sollte Folgendes hinzugefügt werden:

• Exponentialverzögerung bei Fehlern (Retry mit Backoff) — anstatt die Anfrage sofort bei einem Captcha oder einer Sperre zu wiederholen, wartet das Skript einen ansteigenden Zeitraum (5 Sek., 15 Sek., 60 Sek.), was die Anzahl der nutzlosen Anfragen verringert.
• Begrenzung der Anzahl paralleler Streams — zum Beispiel nicht mehr als 10-20 gleichzeitige Verbindungen über den Proxy-Pool, um keine Sperren zu provozieren und den Traffic nicht umsonst zu verbrauchen.
• Deaktivierung des Ladens von Ressourcen im Headless-Browser — wenn das Scraping über Selenium oder Puppeteer erfolgt, können in den Browsereinstellungen das Laden von Bildern, Schriftarten und CSS blockiert werden, sodass nur HTML/JSON-Antworten verbleiben.

Echtzeit-Überwachung des Verbrauchs

Ein Limit ohne Überwachung funktioniert schlechter, da Sie erst nach dem Stoppen des Skripts von einem Problem erfahren. Um den Verbrauch in Echtzeit zu überwachen:

• Aktivieren Sie Benachrichtigungen in Ihrem persönlichen Konto des Proxy-Anbieters, wenn 50 %, 80 % und 100 % des monatlichen Traffic-Pakets erreicht sind — die meisten Dienste unterstützen solche Alarme per E-Mail oder in Telegram.
• Führen Sie ein einfaches Protokoll im Skript: Schreiben Sie die Traffic-Menge stündlich in eine Datei oder Datenbank, um Verbrauchsspitzen zu sehen und schnell die Quelle des Problems zu finden.
• Trennen Sie den Traffic nach Aufgaben über separate Sub-Konten oder Labels — separat für das Scraping von Wildberries, separat für Ozon, separat für Avito. Dies vereinfacht die Analyse, welches Projekt den meisten Traffic verbraucht.
• Vergleichen Sie den Verbrauch mit dem erwarteten Datenvolumen: Wenn für 10.000 Karten 20 GB anstelle der berechneten 300 MB verbraucht wurden, bedeutet das, dass irgendwo zusätzliche Ressourcen geladen werden oder wiederholte Anfragen stattfinden.

Checkliste zur Kontrolle des Traffic-Budgets

Häufige Fehler von Anfängern

In der Praxis lassen sich die meisten „verbrannten“ Traffic-Pakete auf mehrere typische Fehler zurückführen:

• Scraping „über Nacht ohne Aufsicht“ ohne Limits starten. Das Skript läuft 8-10 Stunden ohne Unterbrechung, und wenn irgendwo eine Schleife mit wiederholten Anfragen entsteht, wird der Traffic ununterbrochen bis zum Morgen verbraucht.
• Ein gemeinsamer Proxy-Pool für alle Aufgaben. Das Farming von Konten in Instagram, das Testen von Werbung in Facebook Ads und das Scraping von Ozon verwenden denselben Traffic — es ist unmöglich zu verstehen, was genau ihn verbraucht.
• Ignorieren von Captchas. Anstatt die Anfragefrequenz bei den ersten Anzeichen eines Captchas zu reduzieren, bohrt das Skript weiterhin mit der gleichen Intensität auf die Website ein und verbraucht Traffic für nutzlose Antworten mit Fehlercodes.
• Auswahl von Residential-Proxys, wo Datacenter-Proxys ausreichend wären. Wenn der Marktplatz Datacenter-IP nicht streng blockiert, ist die Überzahlung für Traffic aus dem Residential-Pool nicht gerechtfertigt — für weniger geschützte Ziele sind Datacenter-Proxys mit einem anderen Abrechnungsmodell geeignet.
• Fehlender Testlauf. Bevor Sie das vollständige Scraping für Tausende von Karten starten, sollten Sie das Skript auf 50-100 Karten ausführen und den tatsächlichen Traffic-Verbrauch messen, um auf das gesamte Volumen zu extrapolieren.

Fazit

Traffic für das Scraping „verbraucht sich“ nicht aufgrund des Datenvolumens, sondern aufgrund fehlender Kontrolle: Überflüssige Bilder, wiederholte Anfragen bei Sperren, parallele Streams ohne Begrenzungen und ein gemeinsamer Proxy-Pool für alle Aufgaben. Die Lösung besteht darin, den Traffic nach Projekten zu trennen, tägliche Limits auf Proxy-Kontoebene festzulegen, einen Verbrauchszähler in das Skript zu integrieren und die Überwachung mit Benachrichtigungen einzurichten, bevor das Paket tatsächlich aufgebraucht ist.

Wenn Sie Marktplätze mit aktivem Bot-Schutz wie Wildberries oder Ozon scrapen, empfehlen wir die Verwendung von Residential-Proxys zur Umgehung von Sperren und zusätzlich mobilen IPs für die empfindlichsten Szenarien bezüglich des Anti-Bot-Schutzes — aber in beiden Fällen sollten Sie unbedingt die Traffic-Limits im Voraus festlegen, damit das monatliche Paket nicht in einer einzigen nächtlichen Sitzung aufgebraucht wird.