429 Too Many Requests: welke limiet je bezoekers tegenhoudt

Wat de fout betekent

Een 429 betekent: “te veel verzoeken in te korte tijd, probeer het later opnieuw”. De server draait, de pagina bestaat, maar een regel ergens in de keten telt verzoeken en weigert boven een drempel. Vaak stuurt de server een header Retry-After mee met het aantal seconden tot de volgende poging. De browser toont een kale pagina met “429 Too Many Requests”, de foutpagina van Cloudflare of die van de hostingprovider.

Krijg je een 429 van een dienst van iemand anders, een API of een inlogpagina, dan is dat bijna altijd zo bedoeld: wacht de tijd uit Retry-After af, verstuur minder verzoeken tegelijk en lees de limieten in de documentatie van die dienst.

Op je eigen site is een 429 een ander verhaal. Gewone bezoekers halen zelden een drempel; als zij hem toch krijgen, staat een limiet te streng of ziet een regel al je bezoekers als één bron. De rest van dit artikel gaat over dat geval.

Veelvoorkomende oorzaken op de eigen site

1. Een limiet bij de hostingprovider. Shared hosting begrenst het aantal gelijktijdige processen of verzoeken per account; bij een drukke dag of een trage pagina is de grens snel bereikt.
2. Cloudflare Rate Limiting of een WAF-regel. Een regel telt verzoeken per IP-adres en blokkeert boven de drempel. Staat de site achter een bedrijfsnetwerk of een provider met gedeelde adressen, dan delen honderden bezoekers één IP-adres.
3. Een beveiligingsplugin van WordPress. Loginbescherming of “brute force protection” die ook gewone verzoeken telt, een te lage drempel voor wp-login.php, xmlrpc.php of de REST-API, of een regel die bezoekers na een paar pagina’s blokkeert.
4. limit_req in nginx of mod_evasive in Apache. Een zone die per IP-adres telt, met een rate of burst die te laag staat voor pagina’s met veel aanvragen (afbeeldingen, scripts, AJAX).
5. Bots en crawlers als de echte oorzaak. Een scraper of een agressieve crawler vult de limiet, en de regel blokkeert daarna iedereen die hetzelfde adres of dezelfde route gebruikt.
6. Je eigen site die zichzelf aanroept. Cronjobs, een pagebuilder, een cacheplugin die alle pagina’s voorlaadt, of een API-koppeling die in een lus zit.

Als het je eigen site is: eerst controleren

Open de Website down checker: die toont de HTTP-code en de headers van buitenaf. Een 429 vanaf onze locatie in Europa, met één enkel verzoek, betekent dat de limiet niet alleen bij jou geldt. Daarna vanaf de opdrachtregel:

# welke code en welke headers komen terug?
curl -sI https://example.com/ | grep -iE "^HTTP|retry-after|cf-ray|x-ratelimit|server"

# wie stuurt de 429: Cloudflare, de webserver of de applicatie?
curl -s https://example.com/ | head -n 20

Een cf-ray-header en een Cloudflare-foutpagina wijzen op oorzaak 2; een pagina van de hostingprovider op oorzaak 1; een kale regel of een WordPress-pagina op de plugin of de applicatie. Log daarna in via SSH en lees het toegangslog: wie vraagt het meest, en welk pad?

# de drukste IP-adressen van vandaag
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -n 20

# de drukste user agents
sudo awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -n 20

# meldt nginx een limiet?
sudo grep -i "limiting requests" /var/log/nginx/error.log | tail -n 20

limiting requests, excess: … by zone "…" noemt de zone die blokkeert. Staat één IP-adres met duizenden verzoeken bovenaan, dan heb je de bot gevonden: die blokkeer je gericht, in plaats van de limiet voor iedereen te verlagen. Een monitoringdienst hoort hier niet tussen te staan: onze controlebot verstuurt één verzoek per controle.

Oplossingen

1. nginx: de zone ruimer maken of uitzonderen

# in http { }: 10 verzoeken per seconde per adres
limit_req_zone $binary_remote_addr zone=site:10m rate=10r/s;

# in het server- of location-blok: korte pieken toestaan
limit_req zone=site burst=30 nodelay;
limit_req_status 429;

Statische bestanden (afbeeldingen, CSS, JavaScript) hoor je niet te tellen: zet limit_req alleen op de locaties met PHP of de API. Achter een proxy of CDN moet de zone het echte bezoekersadres tellen, anders ziet nginx alle bezoekers als één adres; gebruik daarvoor set_real_ip_from en real_ip_header X-Forwarded-For (of CF-Connecting-IP). Test en herlaad daarna:

sudo nginx -t && sudo systemctl reload nginx

2. Apache: mod_evasive bijstellen

DOSPageCount        20
DOSSiteCount        200
DOSPageInterval     1
DOSSiteInterval     1
DOSBlockingPeriod   60
DOSWhitelist        203.0.113.0/24

De standaardwaarden van mod_evasive zijn bedoeld voor een enkele pagina en blokkeren een moderne site met tientallen bestanden per pagina. Verhoog DOSPageCount en DOSSiteCount, en zet je eigen adressen en die van je monitoring in DOSWhitelist.

3. WordPress: de beveiligingsplugin nakijken

Open de instellingen van de plugin (loginbescherming, firewall, rate limiting) en kijk naar de drempel en naar wat er meetelt. Laat loginbescherming alleen wp-login.php en xmlrpc.php tellen, niet elke paginaweergave. Gebruik je xmlrpc.php niet, schakel het dan uit in plaats van het te begrenzen. Geblokkeerde adressen staan meestal in een lijst in de plugin; geef daar je eigen adres en dat van je monitoring vrij. Twijfel je welke plugin het doet, schakel ze dan één voor één uit (wp plugin deactivate plugin-naam) tot de 429 verdwijnt.

4. Cloudflare: de regel richten op het doel

Open in het Cloudflare-paneel Security en daarna Rate limiting rules en WAF. Lees de gebeurtenissen (Security Events): die noemen de regel, het pad en het adres dat geblokkeerd werd. Pas de regel aan zodat hij alleen het pad telt waar het om gaat (/wp-login.php, /api/), verhoog de drempel, en zet de user agent of de adressen van je monitoring op de toegestane lijst.

5. De bot blokkeren, niet de bezoekers

Heeft het toegangslog één schuldige aangewezen, blokkeer dan dat adres of die user agent gericht:

# nginx: één adres of een hele reeks
deny 198.51.100.23;
deny 198.51.100.0/24;

# of op user agent
if ($http_user_agent ~* "BadBot|Scraper") { return 403; }

Op shared hosting doe je dit meestal in het klantenpaneel (IP-blokkade) of in de .htaccess met Require not ip 198.51.100.23. Zoekmachines en echte bezoekers laat je ongemoeid.

6. De eigen aanroepen terugbrengen

Kijk naar cronjobs, cacheplugins die alle pagina’s voorladen, en koppelingen die om de paar seconden de API aanroepen. Spreid ze in de tijd of laat ze op een eigen pad draaien dat niet onder de limiet valt.

Als het probleem bij je hostingprovider ligt

Is de 429 de foutpagina van de provider, of vind je in je eigen configuratie geen limiet, dan ligt de grens bij het hostingaccount. Stuur dit bericht:

Goedemiddag, sinds ongeveer 13:00 uur (UTC) krijgen bezoekers van mijn website example.com een “429 Too Many Requests”, ook bij een enkel verzoek vanaf verschillende netwerken. In mijn eigen configuratie en plugins staat geen limiet ingesteld. Welke limiet van mijn hostingaccount is hier bereikt (processen, verzoeken per minuut), welk IP-adres of pad veroorzaakt het volgens uw logs, en kan de limiet worden verhoogd of de bron geblokkeerd?

Zodat het niet opnieuw gebeurt

Een 429 komt en gaat met de drukte, en juist daarom merk je het laat. Een HTTP-controle van buitenaf ziet elke 429 bij de eerste ronde en waarschuwt je vóór je klanten. Is het geen limiet maar echte overbelasting, dan antwoordt de server meestal met een 503 Service Unavailable; blokkeert een beveiligingsregel in plaats van een teller, dan zie je een 403 Forbidden. Voor een WordPress-site houdt het WordPress onderhoud op aanvraag plugins en beveiligingsmeldingen in de gaten, zonder contract.

Down? Wij fixen het. Op je eigen server of op shared hosting met SSH-toegang herstelt de Quick Fix kleine configuratiefouten zoals een te krappe limit_req-zone, met eerst een back-up, tegen een vaste prijs, 24 uur per dag, ook in het weekend; de Deep Fix neemt Cloudflare, plugins, bots en proxy-instellingen voor zijn rekening, per blok van 15 minuten; de schatting is de bovengrens. Ligt de limiet bij je hostingprovider, dan krijg je een kant-en-klaar bericht om hem te sturen.