Wat 429 betekent (en het verschil met 503)
Een 429 zegt: "jij specifiek stuurt te veel requests — wacht even". Vaak met een Retry-After-header die zegt hoelang:
HTTP/2 429 Too Many Requests
Retry-After: 60
Content-Type: text/html
# Of met een absolute datum
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT
Een 503 (Service Unavailable) is iets anders: "de server is overbelast voor iedereen". 503 raakt alle bezoekers; 429 is per-client (vaak per IP-adres of API-key).
Korte mnemoniek:
- 429 = jij specifiek hebt te veel verstuurd
- 503 = de server kan even helemaal niets aan
4 plekken waar je 429 ziet (of veroorzaakt)
1. WordPress-login bruteforce-bescherming
Plugins als Wordfence, Limit Login Attempts Reloaded, iThemes Security: na X mislukte logins blokkeer je het IP voor een tijd. Hoort eigenlijk 429 te zijn met een Retry-After, in praktijk versturen sommige plugins 403 of 401 (semantisch verkeerd, maar werkt).
2. API-rate-limits
Externe API's beperken hoeveel requests je per minuut/uur mag doen. Stuur je te veel? 429 met Retry-After. Zelfde voor je eigen REST-API als die voor publieke clients open staat — rate-limiting voorkomt dat één client de hele server platlegt.
3. Cloudflare WAF / Rate-Limit-rules
Cloudflare biedt rate-limiting in de Pro/Business-plans (en beperkt op Free). Configureer een rule als "max 10 requests per minute on /wp-login.php" en alle bezoekers die meer doen krijgen 429. Krachtig tegen bruteforce, maar je moet whitelisten voor je eigen monitoring/uptime-checks.
4. Scraper / bot-protection
Aggressieve scrapers (concurrent stelen je content), AI-crawlers (GPTBot, ClaudeBot — sommigen respecteren robots.txt, anderen niet), en kwaadaardige bots krijgen 429 als ze de pagina-frequentie overschrijden. Vaak via Cloudflare's Bot Fight Mode.
WordPress-login goed beschermen tegen bruteforce
Drie laagjes, samen sluitend. Volgorde van impact (van hoog naar laag):
Laag 1: Cloudflare rate-limit-rule (gratis op Free, beperkt)
Maak een Security > WAF > Rate Limiting Rules met:
- If: URI-Path equals
/wp-login.php - And: Request method = POST
- Then: Block
- Threshold: 5 requests in 1 minuut, per IP
Resultaat: een aanvaller die 100 wachtwoorden per minuut probeert wordt na 5 mislukkingen voor 10 minuten geblokkeerd door Cloudflare — vóórdat je eigen server überhaupt belast wordt.
Laag 2: Server-niveau rate-limiting (Apache mod_evasive of fail2ban)
Voor wie geen Cloudflare gebruikt: fail2ban kijkt naar je access-logs en blokkeert IP's met te veel 401's of 403's via iptables. Werkt fantastisch voor SSH en e-mail; voor HTTP iets meer config nodig.
Apache mod_evasive:
<IfModule mod_evasive24.c>
DOSHashTableSize 3097
DOSPageCount 5
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 600
</IfModule>
Werkt op de meeste shared hosters niet (geen module-toegang), wel op VPS/dedicated.
Laag 3: WordPress-plugin als laatste vangnet
Limit Login Attempts Reloaded — gratis, simpel, doet precies dit. Configureer:
- Allowed retries: 4
- Minutes lockout: 20
- 4 lockouts increase lockout time to: 24 hours
- Hours until retries are reset: 12
Belangrijk: whitelist je eigen IP in de plugin-instellingen vóórdat je 'm activeert. Anders sluit je jezelf buiten als je een wachtwoord verkeerd typt.
Per ongeluk geblokkeerd? Zo kom je weer binnen
Heb je jezelf met te veel mislukte logins of een verkeerd geconfigureerde rate-limit-rule buitengesloten? Vier ontsnappingsroutes:
Optie 1: Wachten
Snelste pad als 't om Limit Login Attempts gaat — default block-tijd is 20 minuten. Drink een kop koffie en probeer weer.
Optie 2: Plugin uitschakelen via FTP
Log in via FTP/SFTP, ga naar /wp-content/plugins/, hernoem limit-login-attempts-reloaded naar limit-login-attempts-reloaded.uit. WordPress laadt 'm dan niet meer en je kunt inloggen. Hernoem terug nadat je toegang hebt en zet je IP op de whitelist.
Optie 3: Database-rij verwijderen
Voor Wordfence: log in via phpMyAdmin/Adminer, ga naar tabel wp_wfBlocks7, verwijder de rij met jouw IP. Of execute DELETE FROM wp_wfBlocks7 WHERE IP = '...'.
Optie 4: Mobiele data
Block geldt per IP. Schakel je laptop over naar je telefoon-hotspot (ander IP), log in, whitelist je echte IP in de plugin, schakel terug.
API-rate-limiting goed implementeren
Bouw je zelf een API en wil je 429 sturen bij overgebruik? Drie regels:
Regel 1: stuur altijd Retry-After mee
HTTP/2 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1714915200
{"error": "rate_limit_exceeded", "message": "Probeer over 60 seconden opnieuw"}
Retry-After in seconden is universeel ondersteund. X-RateLimit-*-headers zijn de-facto standaard (GitHub, Stripe, Twitter doen 't zó) maar niet officieel.
Regel 2: per API-key, niet per IP
IP-based werkt niet voor API's — meerdere klanten kunnen achter één NAT-gateway zitten. Rate-limit per API-key (of per gebruiker als ingelogd). Gebruik Redis of een ander snel store voor de teller.
Regel 3: differentieer endpoints
Login-endpoint mag stricter (5/min) dan een GET-endpoint (60/min). Schrijf-operaties (POST/PUT/DELETE) lager dan lees-operaties.
Cloudflare-rate-limit blokkeert legitiem verkeer
Klant runt een webshop, krijgt klachten dat checkouts mislukken. In Cloudflare-firewall-events zie je een hoop 429's op /checkout/. Wat is er aan de hand?
Drie mogelijke oorzaken:
- NAT-gateways: meerdere klanten die via dezelfde provider (mobiel netwerk, kantoor-VPN) komen — Cloudflare ziet ze als één IP en triggert de threshold
- JS-bundle-requests: een complexe checkout doet 30 AJAX-calls per submit. 30 calls in 5 sec triggert "100 requests per minute" snel
- Bot Fight Mode aan: blokkeert sommige headless-browser-checkouts (bv. PWA's of mobile-app-webviews)
Fixes:
- Verhoog threshold (10 → 60 requests per minuut)
- Bypass-rule voor
/checkout/pad — helemaal geen rate-limit daar - Skip rule voor specifieke User-Agent (je eigen mobiele app)
- Bot Fight Mode uit voor de checkout-flow specifiek
Veelgestelde vragen
Wat betekent 429 Too Many Requests?
De server zegt: "je hebt te veel requests in te korte tijd gestuurd". Vaak met een Retry-After-header. Niet hetzelfde als 503 — 429 is gericht op één client, 503 is server-overload voor iedereen.
Hoe stop ik per ongeluk geblokkeerd te worden op mijn eigen site?
Drie opties: (1) wacht tot de Retry-After-periode voorbij is, (2) log via FTP in en hernoem de plugin-folder tijdelijk, (3) whitelist je eigen IP in de plugin-instellingen voor de toekomst.
Hoe bescherm ik wp-login tegen bruteforce zonder Wordfence?
Drie laagjes: Cloudflare rate-limit op /wp-login.php, Apache mod_evasive of fail2ban op server-niveau, en plugin Limit Login Attempts Reloaded op WordPress-niveau. Vergeet niet je eigen IP te whitelisten.
Wat is de Retry-After-header?
HTTP-header in 429- (of 503-) responses die zegt na hoeveel seconden je weer mag proberen. Twee formaten: aantal seconden (Retry-After: 60) of een absolute datum.
Cloudflare blokkeert mijn webshop checkouts met 429 — wat doe ik?
Drie fixes: verhoog rate-limit-threshold, maak een bypass-regel voor /checkout/, of zet Bot Fight Mode tijdelijk uit. Check Cloudflare-firewall-events om te zien welke rule trigger't.