Wat rate limiting is, hoe fixed window, sliding window, token bucket en leaky bucket verschillen, met een live simulator, de status 429, Retry-After en een Nginx-voorbeeld.
Rate limiting begrenst hoeveel verzoeken één bezoeker, sleutel of IP-adres binnen een bepaalde tijd mag sturen. Verzoeken boven die grens worden geweigerd, meestal met HTTP-status 429 Too Many Requests en een Retry-After-header die zegt wanneer het opnieuw kan. Het beschermt inlogformulieren, contactformulieren en API's tegen stortvloeden en uit de hand lopende rekeningen.
De vier gangbare algoritmen voor rate limiting
Heeft uw site een inlogpagina, een contactformulier, een checkout of een API die andere apps aanroepen, dan gaat iemand die vroeg of laat bestoken, per ongeluk of met opzet. Rate limiting is de regel die zegt hoeveel te veel is. Hieronder kunt u op knoppen drukken om verzoeken te sturen en zien hoe elk algoritme ze accepteert of weigert, en daarna een werkende Nginx-configuratie kopiëren.
RFC 6585 definieert 429 Too Many Requests als de status voor een client die binnen een bepaalde tijd te veel verzoeken heeft gestuurd. Het antwoord kan een Retry-After-header bevatten die de client vertelt hoe lang hij moet wachten.
Standaard beantwoordt de module limit_req geweigerde verzoeken met 503. Met de directive limit_req_status kunt u dat veranderen in 429, wat de meeste API's verkiezen omdat het de aanroeper precies vertelt wat er gebeurde.
Nog niet. De velden RateLimit en RateLimit-Policy komen uit een Internet-Draft van een IETF-werkgroep die in oktober 2026 nog in bewerking was, dus sommige diensten sturen in plaats daarvan oudere X-RateLimit-headers. Behandel ze als nuttige hints.
Met een token bucket kan een aanroeper opgespaarde tokens in één piek uitgeven, waarna het tempo terugzakt naar het bijvultempo. Een leaky bucket strijkt verkeer glad tot een vaste uitstroom. Nginx documenteert dat zijn module limit_req de leaky bucket-methode gebruikt.
Nee. Het gaat goed om met misbruik vanaf een paar bronnen, maar verkeer verspreid over duizenden adressen vraagt ook om bescherming bij uw host of CDN. Rate limiting is één laag, niet de hele verdediging.
Dit geeft elk IP-adres 5 verzoeken per seconde op het inlogpad, met een piek van 10 die direct wordt bediend, en beantwoordt extra verzoeken met 429 in plaats van de standaard 503.
De zone van 10m bewaart de tellers; volgens de documentatie past in één megabyte ongeveer 16 duizend toestanden van 64 bytes.
Voor één server past een token bucket in een paar regels. Bewaar tellingen in een gedeelde opslag als u meer dan één server draait.
Elke sleutel krijgt 10 tokens die met 1 per seconde bijvullen. Een geweigerde aanroep krijgt 429 en een Retry-After in hele seconden.
Status 429 met een Retry-After van 30 seconden.
Elk algoritme staat ongeveer 5 verzoeken per 5 seconden toe (of een bucket van 5 die met 1 per seconde beweegt). Stuur verzoeken, laat tijd verstrijken en kijk wat er doorkomt.
Algoritme
Fixed window
Sliding window
Token bucket
Leaky bucket
Stuur 1 verzoek
Stuur een piek van {n}
Wacht 1 seconde
Opnieuw beginnen
Tijd: {v} s
Toegestaan: {n}
Geweigerd met 429: {n}
Verzoekenlog
t={v}s toegestaan
t={v}s geweigerd (429)
Nog geen verzoeken. Druk op een knop hierboven.
Een lesmodel met stappen van hele seconden. Echte limiters meten in milliseconden.
Gratis beginnen · Geen creditcard nodig