Le client envoie des requêtes trop rapidement.
Quand l’utiliser
Limitation du débit. Incluez un en-tête Retry-After.
Causes courantes et solutions
Vous avez atteint une limite de débit. Lisez l’en-tête Retry-After, en secondes ou sous forme de date HTTP, ainsi que les éventuels en-têtes RateLimit ou X-RateLimit-Remaining, puis espacez vos tentatives avec des délais exponentiels et du jitter au lieu de réessayer immédiatement. Sources courantes : quotas d’API par clé ou par IP, règles de limitation de débit de Cloudflare, limitation des tentatives de connexion, et limit_req de nginx, qui renvoie 503 sauf si vous définissez limit_req_status 429.
De nombreux utilisateurs derrière un même NAT ou proxy d’entreprise peuvent déclencher ensemble une limite par IP. Si votre limiteur tourne derrière un répartiteur de charge, basez-le sur la véritable IP du client issue de X-Forwarded-For, sinon tous les utilisateurs partagent l’adresse et le quota du répartiteur. Côté client, regroupez les requêtes, mettez les réponses en cache, et ajoutez un délai aléatoire aux tâches planifiées pour qu’elles ne se déclenchent pas toutes à la même seconde.
Erreur client (4xx)
Les codes 4xx sont des erreurs client : la requête elle-même est incorrecte, non autorisée ou vise quelque chose qui n’existe pas. Renvoyer la même requête ne servira à rien.
À quoi ça ressemble
HTTP/1.1 429 Too Many RequestsComment l’envoyer
| Node.js / Express | res.status(429).end() |
|---|---|
| Python / Flask | return '', 429 |
| nginx | return 429; |
Comment le vérifier
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/