Beleefd Scrapen Dat Toch Schaalbaar Is: Een Handleiding voor Snelheidsbeperking
Een site bestoken zorgt ervoor dat je geblokkeerd wordt; één verzoek per keer crawlen brengt je nergens. Het schaalbare midden is adaptieve pacing per domein, verspreid over schone IP's — beleefd voor de site, snel voor jou.
Bijna de helft van al het internetverkeer is nu geautomatiseerd, en websites weten dat. Snelheidsbeperking is hun eerste en meest basale verdediging — een snelheidslimiet die bepaalt hoeveel je kunt nemen en hoe snel. De verleiding is om het te zien als een obstakel om met brute kracht doorheen te breken, maar dat zorgt ervoor dat je geblokkeerd wordt. De tegenovergestelde fout, één voorzichtig verzoek per keer crawlen, brengt je op schaal nergens. Het schaalbare antwoord is beleefd scrapen: paceer elk doel zoals een zware maar legitieme gebruiker zou doen, verspreid de belasting over schone IP's, en laat de reacties van de site je snelheid afstemmen. Dit is hoe je snel blijft zonder het verkeer te worden dat iedereen blokkeert.
Weet welke limiet je raakt
Servers tellen je verzoeken tegen een identificator — meestal je IP, soms een API-sleutel of account — over een tijdsvenster, en handelen wanneer je een drempel overschrijdt. De drie gebruikelijke modellen gedragen zich anders: een vast venster telt verzoeken per kalenderminuut; een token bucket geeft je een vast aantal tokens (bijvoorbeeld 100 per minuut) en besteedt er één per verzoek, waardoor je moet wachten wanneer de bucket leeg is; een glijdend venster telt over de laatste rollende 60 seconden op elk moment. Het praktische gevolg is dat een uitbarsting gevaarlijker is dan een gestage stroom — tien verzoeken in één seconde kunnen een limiet overschrijden die honderd verspreid over een minuut niet zouden doen.
Limieten komen ook in smaken. Zachte limieten zijn mild: de server vertraagt je, of retourneert 429 Too Many Requests met een Retry-After header die je precies vertelt hoe lang je moet wachten (Cloudflare's Fout 1015 is dit). Sommige sites tolereren kleine uitbarstingen — toestaan van 100 per minuut maar pas beperken bij 120 — terwijl anderen vroeg beperken, bijvoorbeeld bij 15 per minuut, en pas hard blokkeren bij 30. Harde limieten zijn strikte plafonds: een API die 1.000 verzoeken per uur toestaat sluit je volledig uit zodra je deze overschrijdt. Druk een zachte limiet herhaaldelijk en het escaleert: 429 wordt 403, dan een tijdelijke ban van minuten tot uren waarvan het venster groeit elke keer dat je het triggert, en uiteindelijk een permanente blacklist van je IP of hele subnet.
Lees de reactie, gok niet
De grootste upgrade voor een scraper is reageren op wat de server je vertelt in plaats van een vaste snelheid te gebruiken. Leer de woordenschat: 429 betekent vertragen en eerbiedig Retry-After; 403 betekent dat deze identiteit is gemarkeerd, dus roteer in plaats van opnieuw proberen; 503 is vaak een uitdaging of tijdelijke afwijzing; en een 200 die een CAPTCHA-pagina retourneert is een zachte blokkade, geen succes. Behandel elk anders. De verkeerde zet — dezelfde verbrande IP opnieuw proberen op een 403, of Retry-After negeren en doorgaan bij een 429 — is wat een zachte waarschuwing verandert in een permanente ban. Onze diepgaande analyses over het oplossen van 429's behandelen de reactieafhandeling in 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
Budgeteer verzoeken per domein
Een crawler die veel sites aanraakt, mag nooit één globale snelheid op allemaal toepassen. Een kleine blog en een geharde marktplaats tolereren heel verschillende belastingen, dus geef elk domein zijn eigen budget. Een per-host token bucket is het schone patroon: wijs een conservatieve snelheid per domein toe, vul het in de loop van de tijd aan, en laat verzoeken naar verschillende hosts parallel lopen terwijl verzoeken naar dezelfde host binnen zijn limiet blijven. Begin langzaam bij een nieuw doel en laat de responscodes je vertellen of je kunt versnellen.
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")Verspreid de belasting zodat elk IP beleefd blijft
Hier is de zet die "beleefd" verzoent met "schaalbaar": beleefdheid wordt per IP gemeten, maar je totale doorvoer is de som over IP's. Als een doel 30 verzoeken per minuut per adres tolereert, beperkt één IP je tot 30 — maar tien schone IP's, elk 30 doend, geven je 300 per minuut terwijl elke individuele exit beleefd blijft. Een roterende residentiële gateway doet dit automatisch, door een vers IP per verzoek over 90M+ adressen te geven zodat geen enkele exit ooit agressief lijkt. Dit is geen truc om harder te hameren; het is het verdelen van echte belasting zodat geen enkele server een verdachte piek draagt. De IP-rotatie fundamentals staan in wat IP-rotatie is en waarom het belangrijk is.
Verspreid de belasting over schone roterende IP's
Neem minder, cache meer, kies je uren
Het beleefdste verzoek is het verzoek dat je nooit verstuurt. Drie gewoonten verminderen de belasting zonder je data te kosten. Ten eerste, cache agressief en gebruik voorwaardelijke verzoeken — stuur If-Modified-Since of If-None-Match zodat een ongewijzigde pagina een kleine 304 retourneert in plaats van de volledige inhoud, wat de server en je bandbreedte spaart. Ten tweede, budgeteer concurrentie bewust: een semafoor die lopende verzoeken per domein beperkt, voorkomt dat je per ongeluk uitbarst. Ten derde, plan zware taken voor de daluren van het doel, wanneer je verkeer een kleiner aandeel van hun verkeer is en minder snel een drempel overschrijdt. Gecombineerd kunnen deze het aantal verzoeken dat een taak nodig heeft halveren — de discipline achter onze bredere anti-ban checklist.
Nog iets dat het vermelden waard is: controleer robots.txt en eerbiedig de aangegeven crawlverwachtingen van een site. Beleefdheid is niet alleen zelfbehoud — een goede burger zijn houdt het open web voor iedereen scrapeable. Onze gids over robots.txt in de praktijk behandelt wat het wel en niet bindt.
Veelgestelde vragen
Hoe vermijd ik snelheidsbeperking bij scraping?
Paceer elk domein met zijn eigen verzoekbudget, eerbiedig Retry-After bij 429's, trek je exponentieel terug, en verspreid de belasting over een roterende pool van schone IP's zodat geen enkel adres agressief lijkt. Voeg caching en voorwaardelijke verzoeken toe om minder verzoeken in totaal te sturen, en plan zware taken voor de daluren van het doel.
Wat betekent HTTP 429 en hoe moet ik het afhandelen?
429 Too Many Requests is een zachte snelheidslimiet — de server vraagt je om te vertragen, niet om je te verbannen. Lees de Retry-After header en wacht precies zo lang voordat je het opnieuw probeert; als deze ontbreekt, trek je exponentieel terug. Negeer het nooit en blijf hameren, want herhaalde 429's escaleren naar 403's en vervolgens naar getimede of permanente bans.
Hoeveel verzoeken per minuut is veilig?
Er is geen universeel getal — het hangt volledig af van het doel. Een kleine site tolereert misschien slechts een paar verzoeken per minuut; een grote, veel meer. Begin conservatief (zeg 20–30 per minuut per IP), let op 429's, en pas aan op basis van de reacties. Schaal de totale doorvoer door IP's toe te voegen, niet door de snelheid op één enkele te verhogen.
Tellen roterende proxies als onbeleefd?
Niet wanneer ze worden gebruikt om echte belasting te verdelen. Rotatie houdt elk individueel IP binnen een beleefde snelheid terwijl je totale doorvoer groeit — de server ziet nooit een verdachte piek van één enkel adres. Het wordt pas onbeleefd als je het gebruikt om te overschrijden wat de site redelijkerwijs in totaal kan verwerken; paceer het totaal, niet alleen de per-IP snelheid.
Beleefd en schaalbaar zijn geen tegenpolen. Lees de signalen, eerbiedig Retry-After, budgeteer per domein, cache wat je kunt, en verspreid de rest over schone roterende IP's. Je eindigt sneller dan de roekeloze scraper — omdat jij degene bent die nooit geblokkeerd wordt.