Ein klassischer Fehler beim Skalieren eines Scrapers ist der Kauf von Proxys "nach Augenmaß": Man nimmt 100 IPs, startet den Scraper und erhält nach einer halben Stunde Sperren. Das Problem liegt nicht in der Anzahl der Adressen, sondern darin, dass niemand die tatsächliche Last auf jede IP berechnet. Lassen Sie uns die Formel zur Berechnung des Proxy-Pools untersuchen, die auf RPS (Requests per Second), Verzögerungen und Limits der Zielwebsite basiert — mit konkreten Zahlen und Code in Python.
Warum die Berechnung des Pools nach der Anzahl der IPs ein Fehler ist
Der typische Ansatz eines Anfängers im Scraping: "Ich muss 50.000 Produktkarten sammeln, also kaufen wir 500 Proxys und verteilen die Last." Die Logik scheint sinnvoll, berücksichtigt jedoch das Wesentliche nicht — Websites wie Wildberries und Ozon sperren nicht basierend auf der absoluten Anzahl der Anfragen, sondern auf der Intensität der Anfragen von einer IP in einer bestimmten Zeitspanne. Das bedeutet, dass 500 Proxys, von denen jeder 20 Anfragen pro Sekunde sendet, sofort gesperrt werden — Anti-Bot-Systeme erkennen ein Muster, das einem DDoS-Angriff ähnelt.
Auf der anderen Seite, wenn Sie 50 Proxys haben, aber jeder 1 Anfrage alle 5-10 Sekunden mit zufälligen Pausen sendet und das Verhalten eines Menschen imitiert, können Sie stabil wochenlang scrapen, ohne eine einzige Sperre zu erhalten. Die Anzahl der IPs ist nicht der Grund für Stabilität, sondern eine Folge der richtig berechneten Last. Deshalb sollte die Formel nicht von "wie viele IPs kaufen" ausgehen, sondern von "wie viel RPS erreicht werden muss und welche sichere Last auf einer IP liegt".
Ein weiterer Punkt: Verschiedene Proxy-Typen haben unterschiedliche "Reserven" auf einer IP. Rechenzentrums-Proxys werden schneller bei hoher Anfragefrequenz gesperrt, da ihre Subnetze leicht als Hosting erkannt werden. Residential und mobile IPs sehen aus wie normale Benutzer, und ihnen kann eine etwas höhere Frequenz ohne Risiko einer Sperrung erlaubt werden — aber das bedeutet nicht, dass die Limits völlig ignoriert werden können.
Die grundlegende Formel zur Berechnung des Proxy-Pools
Die Formel zur Berechnung der Anzahl der Proxys im Pool lautet:
N = (RPS_target × Delay_per_ip) / Concurrency_per_ip
Wo:
- N — die erforderliche Anzahl an Proxys im Pool;
- RPS_target — die Zielgeschwindigkeit des Scraping (Anfragen pro Sekunde im gesamten System);
- Delay_per_ip — die minimale sichere Pause zwischen Anfragen von einer IP (in Sekunden);
- Concurrency_per_ip — wie viele parallele Threads Sie auf einer IP zulassen (normalerweise 1, maximal 2 für Residential Proxys).
Die Logik ist einfach: Wenn Sie insgesamt 10 Anfragen pro Sekunde halten möchten und die sichere Pause zwischen Anfragen von einer IP 8 Sekunden beträgt, kann eine IP physisch nur 1 Anfrage alle 8 Sekunden senden, also 0,125 RPS. Um insgesamt 10 RPS zu erreichen, benötigen Sie 10 / 0,125 = 80 Proxys. Das ist die Berechnung, die das Raten von "500 IPs für alle Fälle" ersetzt.
Wie man das Ziel-RPS für das Scraping berechnet
Vor der Berechnung des Pools müssen Sie RPS_target bestimmen — wie viele Anfragen pro Sekunde Sie tatsächlich benötigen, um die Daten in einem angemessenen Zeitraum zu sammeln. Die Formel hier ist umgekehrt:
RPS_target = Total_requests / Time_budget_seconds
Beispiel: Sie müssen 100.000 Produktkarten von Wildberries in 8 Stunden (28.800 Sekunden) sammeln. Wenn für jede Karte 1 Anfrage benötigt wird, ist RPS_target = 100.000 / 28.800 ≈ 3,47 Anfragen pro Sekunde. Das ist nicht so viel, wie es auf den ersten Blick scheint — viele überschätzen die benötigte Geschwindigkeit und kaufen eine übermäßige Anzahl an Proxys.
Wenn die Aufgabe mehrere Arten von Anfragen umfasst (zum Beispiel zuerst die Liste der Kategorien abrufen, dann die Karten, dann die Bewertungen), berechnen Sie das RPS für jeden Schritt separat — sie können parallel mit unterschiedlichen Proxy-Pools laufen, und die Gesamtlast auf der Plattform wird auf verschiedene Endpunkte verteilt.
Limits pro IP: Wie viele Anfragen pro Minute sind sicher
Delay_per_ip ist der wichtigste Parameter in der Formel, und er muss empirisch für jede Website bestimmt werden. Allgemeine Richtwerte, basierend auf der Praxis des Scraping von Marktplätzen:
| Plattform | Sichere Pause zwischen Anfragen von 1 IP | Maximale Anfragen/Min von 1 IP |
|---|---|---|
| Wildberries (API für Karten) | 4-6 Sek | 10-15 |
| Ozon (Produktseiten) | 5-8 Sek | 8-12 |
| Avito (Anzeigen) | 6-10 Sek | 6-10 |
| Yandex.Market | 5-7 Sek | 8-12 |
Diese Zahlen sind ein Ausgangspunkt, keine Dogma. Beginnen Sie mit konservativen Werten (obere Grenze der Pause), überwachen Sie den Prozentsatz der Fehler 429 und 403 und verringern Sie die Pause schrittweise, wenn die Sperren nicht zunehmen. Eine plötzliche Erhöhung des RPS ohne schrittweises Testen ist der häufigste Weg, um den gesamten Proxy-Pool an einem Tag zu verlieren.
Praktische Berechnungen: Wildberries, Ozon, Avito
Lassen Sie uns drei reale Szenarien mit vollständiger Berechnung nach der Formel untersuchen.
Szenario 1: Preisüberwachung auf Wildberries. Die Preise von 20.000 Produkten müssen alle 2 Stunden aktualisiert werden. RPS_target = 20.000 / (2 × 3600) ≈ 2,78 RPS. Bei einer Pause von 5 Sek. pro IP und Concurrency = 1: N = (2,78 × 5) / 1 ≈ 14 Proxys. Für einen Puffer im Falle einer Sperrung von Teilen der IPs wird empfohlen, einen Pool mit einem Faktor von 1,5-2x zu nehmen, also 21-28 Proxys.
Szenario 2: Einmalige Sammlung des Ozon-Katalogs. 500.000 Karten in 24 Stunden. RPS_target = 500.000 / 86.400 ≈ 5,79 RPS. Bei einer Pause von 6 Sek.: N = (5,79 × 6) / 1 ≈ 35 Proxys. Mit Puffer — 50-60 Proxys.
Szenario 3: Echtzeitüberwachung von Wettbewerbern auf Avito. 5.000 Anzeigen, Aktualisierung alle 15 Minuten. RPS_target = 5.000 / 900 ≈ 5,56 RPS. Bei einer Pause von 8 Sek.: N = (5,56 × 8) / 1 ≈ 45 Proxys. Hier ist es wichtig zu beachten, dass Avito aktiv Rechenzentrums-Subnetze sperrt, daher ist es für diese Aufgabe sinnvoller, von Anfang an Residential oder mobile IPs einzuplanen.
Residential, mobile und Rechenzentrums-Proxys in der Formel
Der Typ des Proxys hat direkten Einfluss auf Delay_per_ip und damit auf das endgültige N in der Formel. Rechenzentrums-Proxys sind günstiger und schneller, erfordern jedoch längere Pausen zwischen Anfragen und werden bei erhöhter Frequenz häufiger gesperrt — tatsächlich benötigen Sie für die gleichen 5 RPS möglicherweise 2-3 Mal mehr Rechenzentrums-IPs als Residential.
| Proxy-Typ | Durchschnittlicher Delay_per_ip | Wann verwenden |
|---|---|---|
| Rechenzentrums-Proxys | 8-15 Sek | Offene APIs, Websites ohne strenge Anti-Bot-Maßnahmen |
| Residential Proxys | 4-8 Sek | Wildberries, Ozon, Avito und andere Marktplätze mit Anti-Bot-Maßnahmen |
| Mobile Proxys | 3-6 Sek | Die aggressivsten Schutzmaßnahmen, soziale Netzwerke, mobile APIs |
Für das Scraping von Marktplätzen wie Wildberries und Ozon sind in der Regel Residential Proxys die optimale Wahl — sie bieten ein gutes Gleichgewicht zwischen Preis und Stabilität und ermöglichen kürzere Pausen, ohne dass die Sperren stark ansteigen. Rechenzentrums-Proxys sollten nur für Plattformen ohne aggressive Anti-Bot-Maßnahmen oder für einmalige Aufgaben mit niedrigem RPS in Betracht gezogen werden.
Implementierung des Pools in Python: Code mit Rotation
Im Folgenden finden Sie eine vereinfachte Implementierung eines Proxy-Pools mit Kontrolle der Anfragefrequenz für jede IP. Die Logik: Jeder Proxy speichert die Zeit der letzten Nutzung, und der Scheduler wählt nur die IPs aus, bei denen genügend Zeit seit der letzten Anfrage vergangen ist.
import time
import random
from dataclasses import dataclass, field
from typing import List, Optional
@dataclass
class ProxyNode:
address: str
delay_per_ip: float # sichere Pause in Sekunden
last_used: float = field(default=0.0)
class ProxyPool:
def __init__(self, proxies: List[str], delay_per_ip: float):
self.nodes = [ProxyNode(address=p, delay_per_ip=delay_per_ip) for p in proxies]
def get_available_proxy(self) -> Optional[ProxyNode]:
now = time.time()
available = [
node for node in self.nodes
if now - node.last_used >= node.delay_per_ip
]
if not available:
return None
# wähle zufällig aus den verfügbaren, um ein Warteschlangen-Muster zu vermeiden
node = random.choice(available)
node.last_used = now
return node
def size(self) -> int:
return len(self.nodes)
def calculate_pool_size(rps_target: float, delay_per_ip: float, concurrency: int = 1) -> int:
"""Formel: N = (RPS_target * Delay_per_ip) / Concurrency_per_ip"""
return max(1, int((rps_target * delay_per_ip) / concurrency))
# Beispielverwendung
rps_target = 5.79 # berechnet aus dem Aufgabenvolumen und der Zeit
delay_per_ip = 6.0 # sichere Pause für Ozon
n_proxies = calculate_pool_size(rps_target, delay_per_ip)
print(f"Benötigte Proxys im Pool: {n_proxies}") # ~35, mit Puffer 50-60
In einem realen Scraper muss diese Logik um eine Aufgabenwarteschlange ergänzt werden (z.B. über asyncio oder multiprocessing), damit die Worker auf das Erscheinen eines freien Proxys warten, anstatt mit einem Fehler zu beenden, wenn keine verfügbar sind. Es sollte auch ein exponentieller Backoff bei Erhalt von 429/403 hinzugefügt werden — dies erhöht automatisch die Pause für eine bestimmte IP bei Anzeichen einer Sperrung.
Monitoring und dynamische Anpassung des Pools
Die statische Berechnung nach der Formel ist ein Ausgangspunkt, kein endgültiges Ergebnis. In der realen Nutzung müssen drei Schlüsselmetriken überwacht werden:
- Erfolgsquote — der Prozentsatz erfolgreicher Anfragen (Code 200) von der Gesamtzahl. Ein Rückgang unter 90-95% signalisiert, dass Delay_per_ip erhöht oder Proxys zum Pool hinzugefügt werden müssen;
- Sperrquote — der Anteil der Proxys, die Anzeichen einer Sperrung gezeigt haben (Captcha, 403, Umleitung auf ein Verifizierungsformular) in der letzten Stunde;
- Reales RPS — die tatsächliche Geschwindigkeit der Anfrageverarbeitung, die aufgrund von Timeouts und Wiederholungsversuchen von der berechneten abweichen kann.
Eine praktische Regel: Wenn die Sperrquote 5-7% pro Stunde überschreitet, erhöhen Sie Delay_per_ip um 20-30% und berechnen Sie N nach der Formel neu. Wenn die Erfolgsquote über mehrere Stunden stabil über 98% liegt, können Sie die Pause schrittweise verringern und die Größe des Pools reduzieren — dies spart direkt Budget für Proxys, ohne die Stabilität zu gefährden.
Eine gute Praxis ist es, ein Protokoll für jede IP separat zu führen: die Zeit der letzten erfolgreichen Anfrage, die Anzahl aufeinanderfolgender Fehler, die durchschnittliche Antwortzeit. Dies ermöglicht es, "beschädigte" Proxys automatisch für 30-60 Minuten aus der Rotation auszuschließen, anstatt weiterhin Anfragen über sie zu senden und bei jedem Schritt ein Captcha zu erhalten.
Häufige Fehler bei der Berechnung des Proxy-Pools
Selbst wenn man die Formel kennt, kann man leicht in den Details der Berechnung Fehler machen. Hier ist eine Liste typischer Fehler:
- Ignorieren des Puffers für Sperren. Selbst bei idealer Berechnung werden 5-10% der Proxys aufgrund von Sperrungen oder Netzwerkproblemen vorübergehend nicht verfügbar sein. Fügen Sie immer einen Faktor von 1,3-2x zur Basis-N hinzu;
- Gleicher Delay_per_ip für alle Endpunkte. Die Kategorieseite und die Produktkarte können unterschiedliche Limits haben — berechnen Sie separat;
- Concurrency größer als 1 ohne Tests. Parallele Anfragen von einer IP erhöhen das Risiko einer Sperrung erheblich, insbesondere bei Residential Proxys — beginnen Sie mit Concurrency = 1;
- Fehlende Rotation von User-Agent und Headern. Selbst ein richtig berechneter Proxy-Pool hilft nicht, wenn alle Anfragen mit demselben Browser-Fingerabdruck gesendet werden;
- Feste Pause ohne Jitter. Ein strikt gleichmäßiger Intervall zwischen Anfragen (z.B. genau 5,0 Sek.) ist ein Muster, das leicht von Anti-Bots erkannt wird. Fügen Sie eine zufällige Abweichung von ±20-30% hinzu.
Fazit
Die Formel N = (RPS_target × Delay_per_ip) / Concurrency_per_ip verwandelt die Berechnung des Proxy-Pools von einem Ratespiel in eine Ingenieursaufgabe mit konkreten Zahlen. Bestimmen Sie zunächst die Zielgeschwindigkeit des Scraping basierend auf dem Datenvolumen und der Zeit, finden Sie dann empirisch die sichere Pause für die jeweilige Plattform, und berechnen Sie erst danach die erforderliche Anzahl an IPs — mit einem Puffer von 30-100% für Sperren und Ausfälle.
Dieser Ansatz spart Budget: Anstatt eine übermäßige Anzahl an IPs "für alle Fälle" zu kaufen, zahlen Sie genau für die Menge an Proxys, die erforderlich ist, um das Ziel-RPS ohne Risiko von Sperrungen zu erreichen. Für das Scraping von Marktplätzen und anderen geschützten Websites empfehlen wir, mit Residential Proxys zu beginnen — sie bieten das beste Gleichgewicht zwischen Stabilität und Kosten bei der Arbeit mit den Anti-Bot-Systemen von Wildberries, Ozon und Avito.