Français
Comment résoudre l’erreur 429 “Too Many Requests”
Comment résoudre l’erreur 429 “Too Many Requests”
L’erreur HTTP 429 “Too Many Requests” est un code de réponse de limitation de débit envoyé par un serveur lorsqu’un utilisateur (ou un client) dépasse le nombre de requêtes autorisées dans un délai donné. Ce statut fait généralement partie des mécanismes de sécurité, de protection des API ou d’anti-DDoS.
Dans les environnements de production, il peut interrompre les services, briser les intégrations API ou affecter le référencement. Ce guide avancé explique comment diagnostiquer, prévenir et résoudre l’ erreur 429 du point de vue du client et du serveur.
Quelles sont les causes de l’erreur 429 ?
Scénarios courants :
Un utilisateur/robot envoie trop de requêtes HTTP (appels API, chargements de pages, etc.)
Votre application fait du scraping ou interroge un service tiers de manière trop agressive
Les pare-feu d’application web (WAF) ou les proxys inversés (par exemple, Cloudflare, Nginx) imposent des limites de débit
Le serveur ou les API utilisent des bibliothèques de limitation de débit (par exemple, express-rate-limit, mod_evasive, etc.)
Des bots ou des robots d’indexation inondent le site web ou le point d’accès
Étape 1 : Identifier la source
✅ 1. Vérifier les en-têtes de réponse
Les serveurs envoient souvent un en-tête Retry-After avec une réponse 429 :
HTTP/1.1 429 Too Many Requests
Retry-After: 60Cela indique au client combien de temps il doit attendre (en secondes) avant de réessayer.
✅ 2. Vérifier les journaux d’accès
Pour Apache :
cat /var/log/apache2/access.log | grep "429"Pour Nginx :
cat /var/log/nginx/access.log | grep "429"Cela permet d’identifier les IP ou les points d’extrémité qui déclenchent la limite.
✅ 3. Utiliser les outils de surveillance
Journaux de Fail2Ban
Événements du pare-feu Cloudflare
Journaux au niveau de l’application (Laravel, Express, Django, etc.)
Analyse des limites de taux (si vous utilisez une passerelle API)
Étape 2 : Corrections côté serveur
A. Limitation du débit de Nginx (si activée)
Nginx peut être configuré comme suit :
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s ;location /api/ {limit_req zone=api_limit burst=10 nodelay ;}Solution :
Augmenter le taux ou le nombre de requêtes (burst)
Appliquer à des chemins spécifiques (par exemple, /api/) plutôt que globalement
Inscrire sur liste blanche les adresses IP internes connues
B. Apache (mod_evasive ou mod_security)
Si mod_evasive est actif :
sudo nano /etc/apache2/mods-enabled/evasive.confAjuster :
DOSPageCount 10
DOSSiteCount 100
DOSBlockingPeriod 10➡️ Augmentez les seuils ou désactivez-les pour des IP de confiance spécifiques.
C. Règles Cloudflare / CDN
Si vous êtes derrière Cloudflare, vérifiez :
Règles de limitation du débit dans Sécurité > WAF
Mode de lutte contre les bots
Règles de pare-feu bloquant sur la base de l’agent utilisateur ou de l’IP
Solution :
Réduire la sensibilité
Mettre sur liste blanche les IP des serveurs ou certains agents utilisateurs
Créer des règles personnalisées pour les robots d’exploration et les partenaires sûrs
D. Limitation du débit au niveau de l’application
Vérifiez si votre application applique des limites à l’aide de bibliothèques telles que :
Node.js : express-rate-limit
Laravel : ThrottleRequests
Django : drf-extensions ou middleware
Mettez à jour la configuration, comme par exemple :
rateLimit({
windowMs: 1 * 60 * 1000, // 1 minute
max: 100, // limite chaque IP à 100 requêtes par minute
})➡️ Ajustez les limites, ajoutez une liste blanche d’utilisateurs/IP ou augmentez le quota en fonction des jetons d’authentification.
Étape 3 : Corrections côté client (lors de la consommation d’API)
Si votre application est le client et reçoit des 429 :
✅ Mettre en place un backoff exponentiel
Réessayer automatiquement les demandes avec des délais croissants :
const retryAfter = (attempt) => Math.pow(2, attempt) * 1000;✅ Respecter les en-têtes Retry-After
if (response.status === 429) {
const wait = response.headers['retry-after'] * 1000;
setTimeout(() => retryRequest(), wait) ;
}✅ Ajouter une limitation de débit au client
Limitez vos propres requêtes en cas de sondage :
// Utiliser lodash ou un throttling personnalisé
_.throttle(() => fetchData(), 1000) ;Étape 4 : Considérations relatives au référencement
Un statut 429 servi aux robots des moteurs de recherche peut nuire à votre classement.
solution :
Servez plutôt un état 503 (service indisponible) avec Retry-After
Utilisez le fichier robots.txt pour limiter le taux d’exploration :
User-agent : *
Crawl-delay : 10Dans Cloudflare : Allez dans Bots > Crawl Management
Étape 5 : Protéger sans bloquer les utilisateurs légitimes
Au lieu d’imposer des limites sévères à 429 :
Utiliser des CAPTCHAs pour les activités suspectes
Mettez en place des délais progressifs plutôt qu’un blocage brutal
Utilisez des limites de débit basées sur l’utilisateur plutôt que sur l’IP pour les utilisateurs connectés
Fournir un accès authentifié avec des limites de débit plus élevées (par exemple, via des clés API ou des jetons)
Conclusion
L’erreur 429 Too Many Requests est un outil utile mais parfois perturbant. Il est essentiel de comprendre d’où elle provient – serveur, CDN ou application – pour la résoudre. Grâce à une configuration adéquate, à la journalisation et au respect des limites côté client, il est possible de concilier protection et convivialité.
Articles connexes
