HTTP 429 Too Many Requests : attendre, puis réessayer correctement
HTTP 429 Too Many Requests
HTTP 429 Too Many Requests : Retry-After et backoff | We.Inc
Ce que signifie un statut 429, comment lire Retry-After, et du code de nouvelle tentative avec backoff exponentiel et jitter. Planifiez votre propre calendrier de tentatives avec le calculateur.
Une réponse 429 signifie que le serveur vous applique une limite de débit : ce client a envoyé plus de requêtes qu'il n'en autorise sur une fenêtre de temps. Arrêtez d'envoyer pendant un moment. Si la réponse contient un en-tête Retry-After, attendez cette durée ; sinon, réessayez avec un backoff exponentiel et un jitter aléatoire pour que de nombreux clients ne réessaient pas tous au même instant.
Lire une réponse 429
Élément
Ce qu'il indique
Ce que votre client doit faire
Statut 429
Trop de requêtes sur une durée donnée
Mettre ce client en pause, ne pas insister
Retry-After: 120
Attendre 120 secondes (forme délai en secondes)
Patienter au moins cette durée
Retry-After: Wed, 21 Oct 2026 07:28:00 GMT
Attendre jusqu'à cette heure (forme date HTTP)
Soustraire l'heure actuelle, puis patienter
Pas de Retry-After
Le serveur n'a donné aucune indication
Appliquer un backoff exponentiel avec jitter
Cache
Un 429 ne doit pas être stocké par un cache
Ne jamais resservir plus tard un 429 sauvegardé
Définissez le premier délai, le plafond et le nombre de nouvelles tentatives autorisées, puis choisissez un style de jitter. Le calculateur liste la plage d'attente de chaque tentative et le total dans le pire cas, pour voir si votre client abandonne avant que la fenêtre du serveur ne se réinitialise.
Saisissez le délai de base en millisecondes, utilisé avant la première nouvelle tentative.
Saisissez le plafond, la durée maximale d'une seule attente.
Choisissez le nombre de nouvelles tentatives autorisées et un style de jitter.
Lisez les plages par tentative et le total, puis copiez le code correspondant ci-dessous.
Respectez Retry-After plutôt que votre propre calendrier chaque fois que le serveur l'envoie. Il sait quand sa fenêtre se réinitialise, vous non.
Ne réessayez que les requêtes qui peuvent être répétées sans risque. Un POST de paiement relancé sans clé d'idempotence peut débiter deux fois.
Plafonnez le nombre de tentatives en plus du délai, et affichez une erreur claire une fois qu'elles sont épuisées.
Quand vous contrôlez le serveur, renvoyez un 429 avec Retry-After plutôt que d'ignorer ou de ralentir les requêtes en silence, pour que les clients bien conçus puissent s'adapter.
Questions fréquentes
Le 429 est-il une erreur client ou une erreur serveur ?
Il appartient à la classe 4xx : il décrit donc le comportement du client, trop de requêtes. Rien n'est cassé sur le serveur. La solution consiste à envoyer moins de requêtes ou à les étaler.
Que contient Retry-After ?
Soit un nombre de secondes à attendre, comme 120, soit une date HTTP après laquelle vous pouvez réessayer. Votre client doit gérer les deux formes.
Pourquoi ajouter du jitter au backoff exponentiel ?
Sans jitter, tous les clients qui ont échoué au même instant réessaient de nouveau au même instant, ce qui recrée le pic. Une attente aléatoire dans chaque fenêtre étale les nouvelles tentatives.
Pourquoi ma limite de débit nginx renvoie-t-elle 503 au lieu de 429 ?
Le module limit_req rejette avec un 503 sauf si vous le modifiez. Ajoutez limit_req_status 429; à côté de votre ligne limit_req pour que les clients voient le code le plus précis.
Un CDN peut-il mettre en cache une réponse 429 ?
Il ne le doit pas. La RFC 6585 indique que les réponses avec le statut 429 ne doivent pas être stockées par un cache, pour que chaque client reçoive une réponse fraîche une fois la limite levée.
Qui envoie un 429 et pourquoi
Les API, les formulaires de connexion et les endpoints de recherche comptent les requêtes par utilisateur, par clé ou par adresse IP et refusent celles en trop. La spécification laisse le comptage au serveur : une API peut limiter par minute et une autre par jour.
La réponse doit expliquer la limite dans son corps, et peut ajouter Retry-After pour indiquer combien de temps attendre.
Les trois styles de backoff du calculateur
Le backoff exponentiel simple double l'attente à chaque fois jusqu'au plafond : min(cap, base * 2^attempt). Le full jitter choisit une attente aléatoire entre zéro et ce nombre. L'equal jitter en garde la moitié et rend l'autre moitié aléatoire, ce qui garantit une pause minimale.
Le full jitter répartit le mieux la charge, c'est pourquoi c'est un choix par défaut raisonnable. L'equal jitter convient aux clients qui ne doivent jamais réessayer instantanément.
Du code client qui respecte le 429
fetch avec Retry-After et full jitter
Lit les deux formes de Retry-After, se rabat sur le full jitter et s'arrête après un nombre fixe de nouvelles tentatives.
Envoyer un 429 depuis votre propre serveur
nginx : limiter par IP et répondre avec un 429
limit_req rejette avec un 503 par défaut ; limit_req_status le passe à 429.
À quoi ressemble la réponse
Un corps court qui explique la limite, et un Retry-After en secondes.
Calculateur de calendrier de tentatives
Délai de base (ms)
Plafond par attente (ms)
Nouvelles tentatives
Style de jitter
Full jitter
Equal jitter
Sans jitter
Attente avant chaque nouvelle tentative
Tentative
Attente la plus courte
Attente la plus longue
Pire cas avant abandon : {v}
Utilisez des nombres entiers supérieurs à zéro, avec un plafond au moins égal à la base.