HTTP 429 Too Many Requests: wacht en probeer goed opnieuw
HTTP 429 Too Many Requests
HTTP 429 Too Many Requests: Retry-After en backoff | We.Inc
Wat een status 429 betekent, hoe u Retry-After leest, en retry-code met exponential backoff en jitter. Plan uw eigen retry-schema met de calculator.
Een 429-response betekent dat de server u een rate limit oplegt: deze client stuurde binnen een tijdvenster meer requests dan is toegestaan. Stop een tijdje met versturen. Bevat het antwoord een Retry-After-header, wacht dan zo lang; zo niet, probeer opnieuw met exponential backoff plus willekeurige jitter, zodat niet veel clients tegelijk opnieuw proberen.
Een 429-response lezen
Onderdeel
Wat het zegt
Wat uw client moet doen
Status 429
Te veel requests binnen een bepaalde tijd
Pauzeer deze client, blijf niet bestoken
Retry-After: 120
Wacht 120 seconden (vertraging in seconden)
Slaap minstens zo lang
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT
Wacht tot dat tijdstip (vorm als HTTP-datum)
Trek de huidige tijd af en slaap dan
Geen Retry-After
De server gaf geen hint
Exponentiële backoff met jitter
Caching
Een cache mag een 429 niet opslaan
Lever nooit later een opgeslagen 429
Stel de eerste vertraging, het maximum en het aantal toegestane retries in, en kies dan een jitterstijl. De calculator toont de wachtmarge voor elke poging en het totaal in het slechtste geval, zodat u ziet of uw client opgeeft voordat het venster van de server opnieuw begint.
Voer de basisvertraging in milliseconden in, de vertraging vóór de eerste retry.
Voer het maximum in, de langste tijd dat één wachtperiode ooit mag duren.
Kies hoeveel retries u toestaat en een jitterstijl.
Lees de marges per poging en het totaal, en kopieer daarna de bijbehorende code hieronder.
Volg Retry-After boven uw eigen schema wanneer de server die stuurt. De server weet wanneer zijn venster opnieuw begint en u niet.
Probeer alleen requests opnieuw die veilig herhaald kunnen worden. Een opnieuw verstuurde betaal-POST zonder idempotency-key kan twee keer afschrijven.
Begrens zowel het aantal retries als de vertraging, en toon een duidelijke foutmelding als ze op zijn.
Beheert u de server zelf, geef dan 429 met Retry-After terug in plaats van requests stilletjes te laten vallen of te vertragen, zodat nette clients zich kunnen aanpassen.
Veelgestelde vragen
Is 429 een clientfout of een serverfout?
Het valt in de 4xx-klasse, dus het beschrijft het gedrag van de client: te veel requests. Op de server is niets kapot. De oplossing is minder requests sturen of ze spreiden.
Wat bevat Retry-After?
Ofwel een aantal seconden om te wachten, zoals 120, ofwel een HTTP-datum waarna u het opnieuw mag proberen. Uw client moet beide vormen aankunnen.
Waarom jitter toevoegen aan exponential backoff?
Zonder jitter probeert elke client die op hetzelfde moment faalde, ook weer op hetzelfde moment opnieuw, wat de piek opnieuw veroorzaakt. Een willekeurige wachttijd binnen elk venster spreidt de retries.
Waarom geeft mijn nginx rate limit 503 in plaats van 429?
De module limit_req weigert met 503, tenzij u dat verandert. Voeg limit_req_status 429; toe naast uw limit_req-regel, zodat clients de nauwkeurigere code zien.
Kan een CDN een 429-response cachen?
Dat mag niet. RFC 6585 zegt dat responses met statuscode 429 niet door een cache opgeslagen mogen worden, zodat elke client een vers antwoord krijgt zodra de limiet vervalt.
Wie 429 stuurt en waarom
API's, inlogformulieren en zoekendpoints tellen requests per gebruiker, per key of per IP-adres en weigeren de extra. De specificatie laat het tellen over aan de server, dus de ene API begrenst per minuut en de andere per dag.
De response hoort de limiet in de body uit te leggen, en kan Retry-After toevoegen om te zeggen hoe lang u moet wachten.
De drie backoffstijlen in de calculator
Gewone exponential backoff verdubbelt de wachttijd elke keer tot het maximum: min(cap, base * 2^attempt). Full jitter kiest een willekeurige wachttijd tussen nul en dat getal. Equal jitter houdt de helft vast en maakt de andere helft willekeurig, wat een minimale pauze garandeert.
Full jitter spreidt de belasting het best, daarom is het een verstandige standaard. Equal jitter past bij clients die nooit direct opnieuw mogen proberen.
Clientcode die 429 respecteert
fetch met Retry-After en full jitter
Leest beide vormen van Retry-After, valt terug op full jitter en stopt na een vast aantal retries.
Zelf 429 sturen vanaf uw server
nginx: begrenzen per IP en antwoorden met 429
limit_req weigert standaard met 503; limit_req_status zet dat om naar 429.
Hoe de response eruitziet
Een korte body die de limiet uitlegt, en een Retry-After in seconden.
Calculator voor retry-schema's
Basisvertraging (ms)
Maximum per wachttijd (ms)
Retries
Jitterstijl
Full jitter
Equal jitter
Geen jitter
Wachttijd vóór elke retry
Retry
Kortste wachttijd
Langste wachttijd
Slechtste geval voordat u opgeeft: {v}
Gebruik hele getallen boven nul, met een maximum dat minstens zo groot is als de basis.