Höfliches Scraping, das dennoch skaliert: Ein Playbook zur Ratenbegrenzung
Eine Website zu bombardieren führt zu einer Sperre; eine Anfrage nach der anderen zu crawlen bringt nichts. Der skalierbare Mittelweg ist eine adaptive Taktung pro Domain, verteilt über saubere IPs — höflich zur Seite, schnell für Sie.
Nahezu die Hälfte des gesamten Internetverkehrs ist mittlerweile automatisiert, und Websites wissen das. Ratenbegrenzung ist ihre erste und grundlegendste Verteidigung — eine Geschwindigkeitsbegrenzung, die entscheidet, wie viel Sie nehmen können und wie schnell. Die Versuchung besteht darin, sie als Hindernis zu betrachten, das man mit roher Gewalt durchbrechen kann, aber das führt zu einer Sperre. Der gegenteilige Fehler, eine vorsichtige Anfrage nach der anderen zu stellen, bringt auf großer Skala nichts. Die skalierbare Antwort ist höfliches Scraping: Taktieren Sie jedes Ziel, wie es ein schwerer, aber legitimer Nutzer tun würde, verteilen Sie die Last über saubere IPs und lassen Sie die Antworten der Website Ihre Geschwindigkeit anpassen. So bleiben Sie schnell, ohne zum Verkehr zu werden, der alle blockiert.
Wissen, welches Limit Sie erreichen
Server zählen Ihre Anfragen gegen einen Identifikator — normalerweise Ihre IP, manchmal einen API-Schlüssel oder ein Konto — über ein Zeitfenster und reagieren, wenn Sie einen Schwellenwert überschreiten. Die drei gängigen Modelle verhalten sich unterschiedlich: Ein festes Fenster zählt Anfragen pro Kalenderminute; ein Token-Bucket gibt Ihnen eine feste Anzahl von Tokens (z.B. 100 pro Minute) und verbraucht eines pro Anfrage, was zu einer Wartezeit führt, wenn der Bucket leer ist; ein gleitendes Fenster zählt über die letzten rollenden 60 Sekunden zu jedem Zeitpunkt. Das praktische Ergebnis ist, dass ein Ausbruch gefährlicher ist als ein stetiger Strom — zehn Anfragen in einer Sekunde können ein Limit auslösen, das hundert über eine Minute verteilt nicht tun würden.
Limits gibt es auch in verschiedenen Ausprägungen. Weiche Limits sind sanft: Der Server verlangsamt Sie oder gibt 429 Too Many Requests mit einem Retry-After-Header zurück, der Ihnen genau sagt, wie lange Sie warten sollen (Cloudflares Fehler 1015 ist dies). Einige Websites tolerieren kleine Ausbrüche — erlauben 100 pro Minute, drosseln aber erst bei 120 — während andere früh drosseln, z.B. bei 15 pro Minute, und erst bei 30 hart blockieren. Harte Limits sind strikte Obergrenzen: Eine API, die 1.000 Anfragen pro Stunde erlaubt, sperrt Sie vollständig, sobald Sie diese überschreiten. Drücken Sie ein weiches Limit wiederholt, eskaliert es: 429 wird zu 403, dann zu einem temporären Verbot von Minuten bis Stunden, dessen Fenster jedes Mal wächst, wenn Sie es auslösen, und schließlich zu einer dauerhaften Blacklist Ihrer IP oder des gesamten Subnetzes.
Lesen Sie die Antwort, raten Sie nicht
Das größte Upgrade für einen Scraper ist, auf das zu reagieren, was der Server Ihnen sagt, anstatt eine feste Rate zu verwenden. Lernen Sie das Vokabular: 429 bedeutet langsamer werden und Retry-After respektieren; 403 bedeutet, dass diese Identität markiert ist, also rotieren Sie, anstatt es erneut zu versuchen; 503 ist oft eine Herausforderung oder eine temporäre Ablehnung; und ein 200, das eine CAPTCHA-Seite zurückgibt, ist eine weiche Blockade, kein Erfolg. Behandeln Sie jede anders. Der falsche Schritt — dieselbe verbrannte IP bei einem 403 erneut zu versuchen oder Retry-After zu ignorieren und bei einem 429 weiterzumachen — ist das, was eine weiche Warnung in ein dauerhaftes Verbot verwandelt. Unsere tiefen Einblicke in die Behebung von 429s behandeln die Antwortverarbeitung im Detail.
import time, requests
def polite_get(session, url, max_tries=4):
for attempt in range(max_tries):
r = session.get(url, timeout=20)
if r.status_code == 200 and "captcha" not in r.text.lower():
return r
if r.status_code == 429: # obey the server
wait = int(r.headers.get("Retry-After", 2 ** attempt))
time.sleep(wait)
continue
if r.status_code in (403, 503): # this exit is burned
rotate_ip(session) # fresh IP, then retry
time.sleep(2 ** attempt) # exponential backoff
continue
return r
return None
Budgetieren Sie Anfragen pro Domain
Ein Crawler, der viele Websites berührt, sollte niemals eine globale Rate auf alle anwenden. Ein kleiner Blog und ein gehärteter Marktplatz tolerieren völlig unterschiedliche Lasten, also geben Sie jeder Domain ihr eigenes Budget. Ein Token-Bucket pro Host ist das saubere Muster: Weisen Sie jeder Domain eine konservative Rate zu, füllen Sie sie im Laufe der Zeit auf und lassen Sie Anfragen an verschiedene Hosts parallel laufen, während Anfragen an denselben Host innerhalb seines Limits bleiben. Beginnen Sie langsam bei einem neuen Ziel und lassen Sie die Antwortcodes Ihnen sagen, ob Sie beschleunigen können.
import time
from collections import defaultdict
class DomainLimiter:
def __init__(self, per_min=30):
self.gap = 60.0 / per_min # min seconds between hits per host
self.last = defaultdict(float)
def wait(self, host):
now = time.time()
delay = self.gap - (now - self.last[host])
if delay > 0:
time.sleep(delay)
self.last[host] = time.time()
# 30 req/min to any single host; different hosts proceed independently
limiter = DomainLimiter(per_min=30)
limiter.wait("example.com")Verteilen Sie die Last, damit jede IP höflich bleibt
Hier ist der Schritt, der "höflich" mit "skaliert" in Einklang bringt: Höflichkeit wird pro IP gemessen, aber Ihr Gesamtdurchsatz ist die Summe über die IPs. Wenn ein Ziel 30 Anfragen pro Minute pro Adresse toleriert, begrenzt Sie eine IP auf 30 — aber zehn saubere IPs, die jeweils 30 machen, geben Ihnen 300 pro Minute, während jeder einzelne Ausgang höflich bleibt. Ein rotierendes Wohn-Gateway macht dies automatisch, indem es bei jeder Anfrage eine frische IP über 90M+ Adressen bereitstellt, sodass kein einzelner Ausgang jemals aggressiv aussieht. Dies ist kein Trick, um härter zu hämmern; es ist die Verteilung echter Last, sodass kein einzelner Server einen verdächtigen Anstieg erfährt. Die Grundlagen der IP-Rotation finden Sie in was IP-Rotation ist und warum sie wichtig ist.
Verteilen Sie die Last über saubere rotierende IPs
Nehmen Sie weniger, cachen Sie mehr, wählen Sie Ihre Stunden
Die höflichste Anfrage ist die, die Sie nie senden. Drei Gewohnheiten reduzieren die Last, ohne dass Ihnen Daten verloren gehen. Erstens, cachen Sie aggressiv und verwenden Sie bedingte Anfragen — senden Sie If-Modified-Since oder If-None-Match, sodass eine unveränderte Seite ein kleines 304 zurückgibt, anstatt den gesamten Inhalt, was den Server und Ihre Bandbreite schont. Zweitens, budgetieren Sie die Konkurrenz bewusst: Ein Semaphor, das die laufenden Anfragen pro Domain begrenzt, verhindert versehentliche Ausbrüche. Drittens, planen Sie schwere Jobs für die Nebenzeiten des Ziels, wenn Ihr Verkehr einen kleineren Anteil an ihrem ausmacht und weniger wahrscheinlich einen Schwellenwert auslöst. Zusammen können diese die Anfragen, die ein Job benötigt, halbieren — die Disziplin hinter unserer umfassenderen Anti-Ban-Checkliste.
Noch eine Sache, die es wert ist, klar gesagt zu werden: Überprüfen Sie robots.txt und respektieren Sie die angegebenen Crawling-Erwartungen einer Website. Höflichkeit ist nicht nur Selbstschutz — ein guter Bürger zu sein, hält das offene Web für alle scrape-fähig. Unser Leitfaden zu robots.txt in der Praxis behandelt, was es bindet und was nicht.
Häufig gestellte Fragen
Wie vermeide ich Ratenbegrenzung beim Scraping?
Taktieren Sie jede Domain mit ihrem eigenen Anfragenbudget, respektieren Sie Retry-After bei 429ern, ziehen Sie sich exponentiell zurück und verteilen Sie die Last über einen rotierenden Pool sauberer IPs, sodass keine einzelne Adresse aggressiv wirkt. Fügen Sie Caching und bedingte Anfragen hinzu, um insgesamt weniger Anfragen zu senden, und planen Sie schwere Jobs für die Nebenzeiten des Ziels.
Was bedeutet HTTP 429 und wie sollte ich damit umgehen?
429 Too Many Requests ist eine weiche Ratenbegrenzung — der Server bittet Sie, langsamer zu werden, nicht Sie zu sperren. Lesen Sie den Retry-After-Header und warten Sie genau so lange, bevor Sie es erneut versuchen; wenn er fehlt, ziehen Sie sich exponentiell zurück. Ignorieren Sie ihn niemals und machen Sie weiter, denn wiederholte 429er eskalieren zu 403ern und dann zu zeitlich begrenzten oder dauerhaften Sperren.
Wie viele Anfragen pro Minute sind sicher?
Es gibt keine universelle Zahl — es hängt vollständig vom Ziel ab. Eine kleine Seite toleriert möglicherweise nur wenige Anfragen pro Minute; eine große, weitaus mehr. Beginnen Sie konservativ (sagen wir 20–30 pro Minute pro IP), achten Sie auf 429er und passen Sie sich den Antworten an. Skalieren Sie den Gesamtdurchsatz, indem Sie IPs hinzufügen, nicht indem Sie die Rate auf einer einzelnen erhöhen.
Zählen rotierende Proxies als unhöflich?
Nicht, wenn sie verwendet werden, um echte Last zu verteilen. Rotation hält jede einzelne IP innerhalb einer höflichen Rate, während Ihr gesamter Durchsatz wächst — der Server sieht nie einen verdächtigen Anstieg von einer einzelnen Adresse. Es wird nur dann unhöflich, wenn Sie es verwenden, um das zu überschreiten, was die Seite insgesamt vernünftigerweise handhaben kann; takten Sie das Gesamte, nicht nur die Rate pro IP.
Höflich und skalierbar sind keine Gegensätze. Lesen Sie die Signale, respektieren Sie Retry-After, budgetieren Sie pro Domain, cachen Sie, was Sie können, und verteilen Sie den Rest über saubere rotierende IPs. Sie sind schneller als der rücksichtslose Scraper — weil Sie derjenige sind, der nie gesperrt wird.