Vous avez activé la limitation de débit (rate limiting), vous bloquez les IP qui envoient trop de requêtes, et pourtant votre serveur s’effondre dès qu’une vraie attaque arrive. Ce n’est pas que la limitation de débit ne fonctionne pas — c’est qu’elle résout un problème différent de celui qui vous attaque.
Ce que la limitation de débit par IP fait bien
Compter les requêtes par IP et bloquer celle qui dépasse un seuil fonctionne très bien contre un attaquant isolé : quelqu’un qui lance un script de force brute contre votre connexion, ou un scraper agressif depuis une seule machine. Dans ce cas, couper cette IP précise résout le problème instantanément.
Pourquoi ça échoue face à un vrai DDoS
Un botnet, ce n’est pas une IP, ce sont des milliers
Une attaque par déni de service distribué (DDoS) n’envoie pas tout son trafic depuis une seule source — elle le répartit sur des centaines ou des milliers de machines différentes, chacune envoyant relativement peu de requêtes. Si votre règle est “bloquer après 50 requêtes par minute depuis la même IP”, un botnet bien réparti n’atteindra jamais ce seuil sur une seule IP, même si le total cumulé fait tomber votre serveur.
Chaque nouvelle IP repart de zéro
Même si vous bloquez chaque IP dès qu’elle dépasse la limite, l’attaquant continue simplement d’en ajouter de nouvelles. La limitation de débit par IP est conçue pour arrêter un abus isolé, pas pour reconnaître que le trafic total du site a explosé à cause d’une attaque coordonnée.
Ce qu’un mode conçu pour ça fait différemment
Compter le trafic global, pas par origine
Au lieu de surveiller chaque IP séparément, cette approche mesure combien de requêtes le site reçoit au total sur une courte fenêtre de temps. Si ce total dépasse ce qui est normal pour votre site, une réponse se déclenche — sans avoir besoin d’identifier au préalable laquelle des milliers d’IP est “la coupable”, parce qu’il n’y en a pas une seule.
Un défi léger plutôt qu’un serveur à genoux
Quand le volume global explose, au lieu de laisser chaque requête exécuter WordPress en entier (requête base de données, chargement des plugins, etc.), un petit défi est servi — un défi qu’un navigateur normal résout instantanément, mais qui arrête la majorité du trafic automatisé avant qu’il ne consomme de vraies ressources serveur.
Ce que ce type de protection ne remplace pas
Il est important d’être honnête sur les limites : cette couche est conçue pour protéger les pages normales du site contre un pic de trafic massif, pas pour blinder les formulaires, les paiements ou l’API à elle seule — ces parcours ont besoin de leur propre protection dédiée, précisément parce qu’on ne veut pas interrompre un achat réel en plein milieu avec un défi.
Questions fréquentes
La limitation de débit par IP sert-elle encore à quelque chose ?
Oui, elle reste utile contre la force brute, le scraping agressif ou les abus depuis une source précise — ce n’est simplement pas le bon outil contre une attaque distribuée sur des milliers d’IP.
Ai-je besoin des deux en même temps ?
Elles se complètent : la limitation par IP couvre l’abus individuel, et une couche de trafic global couvre le scénario où aucune IP précise ne ressort, mais où le total du site, si.
Une attaque DDoS peut-elle faire tomber n’importe quel WordPress sans protection dédiée ?
Oui — sans aucune couche mesurant le volume total, WordPress traite chaque requête individuellement (base de données comprise), et un volume suffisamment élevé épuise les ressources du serveur même si chaque requête paraît inoffensive en soi.