← Terug naar kennisbank HOSTING

429 Too Many Requests — uitgelegd en gebruikt

De HTTP-status die zegt: "je stuurt me te snel te veel requests — wacht even". Het primaire wapen tegen WordPress-login-bruteforce, API-misbruik en scraper-bots. Goed geconfigureerd houdt 't aanvallers buiten zonder legitiem verkeer te raken; verkeerd geconfigureerd blokkeert 't je eigen klanten tijdens een drukke checkout. Deze gids legt uit waar 429 vandaan komt, hoe je 'm correct opzet voor WordPress en API's, en wat je doet als je per ongeluk je eigen IP hebt geblokkeerd.

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.