Erreur 503 sur WordPress : qui l’envoie vraiment ?

Désactivez vos extensions, passez sur un thème par défaut, montez la mémoire PHP… Voilà ce qu’on vous répond partout quand votre site WordPress affiche une erreur 503. Le hic : la plupart du temps, WordPress n’y est pour rien.

J’ai lu le code de WordPress 7.1.3. Côté visiteur, sur les pages du site, deux chemins seulement y mènent à une 503 : le mode maintenance, et une adresse qui la réclame. Une base de données en panne donne une 500, une erreur fatale de PHP aussi. Quand une page normale vous répond 503, quelqu’un d’autre a donc répondu avant WordPress, ou à sa place.

Ce quelqu’un est l’un des maillons qui séparent le navigateur de PHP : Cloudflare ou un autre CDN, un cache comme Varnish, le serveur web (Nginx, Apache, LiteSpeed), un pare-feu applicatif, une extension de sécurité, les limites de votre hébergement. Chacun signe sa 503 à sa façon.

Je les ai fait répondre un par un le 23 octobre 2026, dans un labo Docker monté sur mon poste. Voici comment les reconnaître, et où lire la preuve.

Que signifie une erreur 503 sur WordPress ?

Le code 503 (Service Unavailable) signifie que le serveur ne peut pas traiter la requête pour l’instant, à cause d’une surcharge passagère ou d’une maintenance programmée. La norme HTTP (RFC 9110, section 15.6.4) ajoute que le serveur peut envoyer un en-tête Retry-After pour dire au client combien de temps attendre.

La même section glisse une note que j’aime bien : un serveur surchargé n’est pas obligé de répondre 503, certains refusent tout simplement la connexion. Une 503 est donc une réponse polie. Le maillon qui vous l’envoie est encore assez vivant pour vous dire non.

Côté Google, la documentation des robots d’exploration (mise à jour le 4 février 2026) est claire : les codes 5xx et 429 font ralentir l’exploration, le contenu reçu avec ces codes est ignoré, et les pages déjà indexées sont conservées… puis finissent par être retirées.

La page de Google sur les codes HTTP ne donne aucune durée ; celle sur la mise en pause d’un site limite la 503 à un ou deux jours. Dix minutes de 503 pendant une mise à jour ralentissent au pire l’exploration un moment. Une 503 qui revient chaque soir à la même heure finit par coûter des pages.

Les 503 que WordPress envoie lui-même

Dans le cœur de WordPress 7.1.3, la 503 que vous risquez de croiser sort de la fonction wp_maintenance(), appelée quand un fichier .maintenance est présent à la racine du site.

Sauf si un fichier wp-content/maintenance.php prend la main, WordPress envoie alors un en-tête Retry-After: 600 et sa page "Briefly unavailable for scheduled maintenance". Voici les lignes, telles qu’elles sont dans wp-includes/load.php :

header( 'Retry-After: 600' );

wp_die(
	__( 'Briefly unavailable for scheduled maintenance. Check back in a minute.' ),
	__( 'Maintenance' ),
	503
);

En anglais, oui, même sur un site en français. Cette fonction passe avant la connexion à la base, où vit la langue choisie dans Réglages > Général. WordPress ne traduit donc le message que s’il connaît la langue plus tôt : constante WPLANG dans wp-config.php, ou installation faite depuis l’archive française de fr.wordpress.org, qui le précise dans wp-includes/version.php.

Ce fichier naît pendant les mises à jour, et WordPress l’ignore dès qu’il a 10 minutes. Je ne refais pas ici le dépannage d’un site bloqué en maintenance : il est détaillé dans mon guide du mode maintenance WordPress.

Le second chemin, celui de l’adresse, m’a pris par surprise. error fait partie des variables publiques de l’adresse, comme p ou s. S’il vaut 403, 500, 502 ou 503, la classe WP (wp-includes/class-wp.php, ligne 464) renvoie ce code tel quel, puis s’arrête sans rien afficher.

Dans le labo, /?error=503 a répondu une 503 de 0 octet, avec X-Powered-By: PHP/8.4.27 et sans Retry-After, derrière Nginx comme derrière Apache. Personne ne tape cette adresse par hasard. Toutefois, sur un site aux permaliens Simple, des 503 vides sur des adresses en ?error= viennent de WordPress, qui obéit à l’adresse : aucune panne là-dessous. Avec des permaliens lisibles, WordPress ignore ce paramètre.

Le reste du code est sobre : j’ai cherché chaque 503 du cœur avec grep, dans l’image Docker officielle.

En dehors de ces deux chemins, il n’en reste que dans des recoins. Côté administration, la bibliothèque de polices et la page des connecteurs répondent 503 quand leurs fichiers compilés manquent, sur une copie de développement ou une installation incomplète.

Le client IA de WordPress 7, lui, renvoie une erreur 503 à l’extension qui l’appelle. Il le fait quand l’IA est désactivée, qu’un filtre bloque la demande ou que le fournisseur d’IA est injoignable.

Et la base de données ? Sans fichier wp-content/db-error.php pour la remplacer, la fonction dead_db() appelle wp_die() sans préciser de code, et wp_die() met 500 par défaut.

Le labo l’a confirmé : base arrêtée, la page "Error establishing a database connection" sort en 500, au bout de 7,8 secondes derrière Nginx, le temps que PHP renonce à joindre MariaDB. Ce cas a son propre article : l’erreur de connexion à la base de données.

Une erreur fatale de PHP passe, elle, par le gestionnaire d’erreurs du cœur, qui répond 500 lui aussi. Seuls un gabarit wp-content/php-error.php posé à la main, un gestionnaire de remplacement wp-content/fatal-error-handler.php ou le filtre wp_php_error_args peuvent choisir un autre code.

Une extension peut aussi envoyer sa propre 503. C’est même le cas de Wordfence, l’une des extensions de sécurité les plus installées, j’y reviens plus bas.

Le labo : une même panne, 2 codes différents

Arrêtez PHP-FPM derrière Nginx, vous obtenez une 502. Arrêtez-le derrière Apache, vous obtenez une 503. Même panne, même WordPress, 2 codes : le code vous dit quel maillon a constaté la panne, mais pas ce qui est tombé.

Le montage tient dans un fichier docker-compose.yml. WordPress 7.1.3 tourne sur PHP-FPM 8.4.27, servi en même temps par Nginx 1.28.3 et par Apache 2.4.69, qui partagent le même socket PHP. Varnish 7.6.5 se tient devant Nginx, MariaDB 11.4 derrière. Deux processus PHP seulement, pour saturer vite. Tout tourne en local : aucun site en ligne n’a reçu la moindre requête.

Ensuite, j’ai cassé les maillons un par un, en relevant ce que chacun renvoyait, en-têtes compris, et ce qu’il écrivait dans son journal à la même seconde.

Ce que j’ai cassé	Réponse via Nginx	Réponse via Apache	Réponse via Varnish
Fichier .maintenance posé	503 (WordPress)	503 (WordPress)	non mesuré
Base de données arrêtée	500 en 7,8 s	500 en 3,8 s	non mesuré
PHP-FPM arrêté	502	503	200 depuis son cache, ou 502 relayé
Processus PHP tué en pleine requête	502	503	non mesuré
Nginx arrêté	sans objet	sans objet	503 Backend fetch failed
Deux processus PHP occupés 30 s, délai de lecture de 10 s	504	504	non mesuré
Limite de 1 requête par seconde sur wp-login.php, 6 requêtes en 0,1 s	1 fois 200, puis 5 fois 503	non configuré	non mesuré

La ligne "PHP-FPM arrêté" m’a fait sourire. Voici ce que Nginx, puis Apache, ont écrit dans leur journal d’erreurs :

# Nginx
[crit] connect() to unix:/run/php/php-fpm.sock failed (2: No such file or directory) while connecting to upstream

# Apache
[proxy:error] (2)No such file or directory: AH02454: FCGI: attempt to connect to Unix domain socket /run/php/php-fpm.sock (localhost:8000) failed
[proxy_fcgi:error] AH01079: failed to make connection to backend: localhost

Même cause, mot pour mot : le socket de PHP n’existe plus. Nginx en tire une 502 (Bad Gateway, la passerelle n’a rien obtenu de valable), Apache une 503 (service indisponible). Le processus PHP tué en pleine requête donne le même écart : 502 côté Nginx (Connection reset by peer), 503 côté Apache (AH01067: Failed to read FastCGI header).

Si votre hébergeur sert vos pages avec Apache et PHP-FPM, une panne de PHP vous arrivera donc en 503, et vous chercherez une surcharge qui n’existe pas… Bonne nouvelle quand même : une seconde après la relance de PHP-FPM, Apache répondait de nouveau 200. Dans cette configuration, il ne met pas le serveur PHP à l’écart.

Varnish, lui, m’a appris autre chose. Pendant que PHP-FPM était à terre, il servait la page d’accueil en 200 depuis son cache (en-tête Age: 19, la copie avait 19 secondes). Les visiteurs de l’accueil ne voyaient rien.

Ceux d’une page absente du cache recevaient le 502 de Nginx, relayé tel quel. Sur les pages en cache, une panne peut ainsi rester invisible tant que la copie tient.

Comment savoir qui a envoyé la 503 ?

Pour savoir qui a envoyé une 503, demandez la réponse complète avec curl, puis lisez la ligne de statut, l’en-tête Server et le texte de la page. Chaque maillon a les siens, et ils ne se ressemblent pas. La commande, à lancer depuis votre poste :

curl -s -o /dev/null -D - https://votre-site.fr/

L’option -D - affiche les en-têtes, même quand la réponse est une erreur, et -o /dev/null jette le corps. Retirez-la pour lire aussi le texte de la page. Attention à curl -I, qui envoie une requête HEAD : sur un serveur LiteSpeed, j’ai déjà vu une page en cache répondre différemment selon la méthode. Je m’en tiens donc à une vraie requête GET.

Sous Windows, tapez curl.exe (dans Windows PowerShell, curl désigne une autre commande) et remplacez /dev/null par NUL.

Qui répond	Ligne de statut (HTTP/1.1)	Indices dans les en-têtes	Texte de la page
WordPress (mode maintenance)	503 Service Unavailable	X-Powered-By: PHP, Retry-After: 600	"Briefly unavailable for scheduled maintenance", ou "Indisponibilité temporaire pour cause de maintenance" si la langue est fixée dans wp-config.php ou par l’archive française
WordPress (adresse en ?error=503, permaliens Simple)	503 Service Unavailable	X-Powered-By: PHP, aucun Retry-After	aucun : page vide, 0 octet
Nginx (limite de débit)	503 Service Temporarily Unavailable	Server: nginx, aucun en-tête de PHP, page de 197 octets	"503 Service Temporarily Unavailable" et la version de Nginx
Apache (PHP injoignable)	503 Service Unavailable	charset=iso-8859-1, Connection: close	"The server is temporarily unable to service your request due to maintenance downtime or capacity problems"
Varnish (serveur d’origine injoignable)	503 Backend fetch failed	Server: Varnish, Retry-After: 5, X-Varnish	"Guru Meditation" et un numéro XID
Wordfence (blocage)	503 Service Temporarily Unavailable (pare-feu : 503 Service Unavailable)	Retry-After égal à la durée du blocage, quand elle est connue	"Your access to this site has been limited by the site owner"
TigerProtect (o2switch)	503 vu du serveur, 404 vu du dehors	non relevés	"Test de sécurité / Security check"
Cloudflare	503	non relevés	contient "cloudflare" ou "cloudflare-nginx"

Nota : en HTTP/2, curl affiche HTTP/2 503 sans libellé. Ajoutez --http1.1 à la commande pour retrouver la ligne de statut complète, ou fiez-vous à Server, à Retry-After et au texte de la page.

Wordfence mérite deux mots de plus, parce que sa 503 sort de PHP et ressemble à s’y méprendre à une panne. Dans son code (version 9.0.2, fichier lib/wfLog.php), la fonction do503() sert les blocages d’adresses IP, la limite de débit (blocage ou ralentissement) et le blocage par pays, avec la ligne "503 Service Temporarily Unavailable". La durée restante part dans Retry-After quand elle est connue. Son pare-feu applicatif, chargé avant le reste de l’extension, répond, lui, par "503 Service Unavailable".

Si votre page parle de "Your access to this site has been limited", ouvrez le trafic en direct de Wordfence (Live Traffic) avant de toucher au serveur : vous y verrez l’adresse bloquée et la règle qui l’a bloquée.

Derrière Cloudflare, ajoutez une étape. La documentation de Cloudflare sur l’erreur 503 donne un test simple : si la page contient "cloudflare" ou "cloudflare-nginx", la 503 vient sans doute de Cloudflare ; sinon, plus probablement de votre serveur. Pour trancher, interrogez l’origine directement, en passant à côté du CDN :

curl -s -o /dev/null -D - --resolve votre-site.fr:443:203.0.113.10 https://votre-site.fr/

Remplacez 203.0.113.10 par l’adresse IP de votre serveur, celle que vous trouvez dans la zone DNS de Cloudflare. Si l’origine répond 200 pendant que le site public répond 503, regardez chez Cloudflare.

Sa documentation y voit un problème de connectivité dans l’un de ses centres de données, ou un Worker qui dépasse ses limites de calcul ou de mémoire. Ses règles de limite de débit répondent, elles, en 429 par défaut, et n’acceptent qu’un code compris entre 400 et 499.

Dernier cas, rassurant celui-là : des 503 qui n’apparaissent que dans les statistiques de Cloudflare. D’après la même page, ce sont des préchargements ratés de Speed Brain, et vos visiteurs ne les voient jamais.

Une boutique chez o2switch : la 503 que personne ne voyait

Juillet 2026, une boutique WooCommerce que je maintiens chez o2switch, derrière Cloudflare. Le 19, à 12 h 00, ma sonde de surveillance tombe sur une 500 en page d’accueil. Vers 12 h 01, tout est revenu. Rien de cassé, aucune commande perdue…

Le journal d’accès du domaine raconte autre chose. Entre 11 h 59 et 12 h 00, il compte environ 120 000 requêtes, à peu près 1 000 par seconde, presque toutes sur xmlrpc.php : 111 540 réponses 508, 8 848 réponses 500, et 48 réponses 503. Le 5 juillet, même film en plus court, environ 74 000 requêtes dont 68 196 en 508.

Les 508 viennent de CloudLinux, le système qui découpe un serveur mutualisé en comptes étanches : quand un compte atteint sa limite de processus d’entrée (les connexions qu’il sert en même temps), le serveur web ne peut plus y faire entrer de requête et répond 508, comme l’explique la documentation de LiteSpeed sur CloudLinux.

Les 500 portent le message "Error establishing a database connection" : WordPress ne joint plus sa base. Et les 503 ?

Le journal ne dit pas qui les a envoyées. La même page de LiteSpeed prévient qu’un compte bridé en mémoire ou en nombre de processus reçoit des 500 ou des 503 : CloudLinux faisait un suspect crédible. J’ai voulu en avoir le cœur net.

Depuis le serveur lui-même, avec curl et --resolve vers 127.0.0.1 pour passer à côté de Cloudflare, /xmlrpc.php et /wp-login.php répondaient 503 avec une page "Test de sécurité / Security check" de 6 278 octets. La page d’accueil, elle, répondait 200.

C’était TigerProtect, le pare-feu maison d’o2switch. Sa "Sécurité par défaut" place ces deux adresses derrière un test que seul un vrai navigateur sait passer. Vu de l’extérieur, la chaîne des pages d’erreur transformait d’ailleurs cette 503 en 404, ce qui n’aidait pas.

Or Jetpack, qui relie la boutique à WordPress.com, est un robot. Il échouait au test depuis au moins le 4 juillet, sans bruit.

De temps en temps, WordPress.com relançait une vérification, puis partait en rafale de nouvelles tentatives. Chaque appel rejeté faisait rendre à WordPress la page 404 complète du thème, requêtes en base comprises. À 1 000 par seconde, le compte saturait en quelques instants.

Dans le cPanel, la règle "Sécurité par défaut d’o2switch" s’active ou se coupe en bloc, sans liste blanche d’adresses IP : la lever pour xmlrpc.php passe par le support.

J’ai donc coupé les rafales en amont, par une règle de limite de débit chez Cloudflare sur le seul chemin /xmlrpc.php : 50 requêtes par 10 secondes et par adresse IP, puis 10 secondes de blocage, ce que permet le plan gratuit.

Une rafale à 1 000 requêtes par seconde dépasse ce seuil en un instant. Cloudflare prévient que ses compteurs peuvent prendre quelques secondes de retard, et que des requêtes en trop passent encore pendant ce temps. Le but reste d’arrêter le gros de la rafale chez Cloudflare, avant l’hébergement.

Dans la même minute, la boutique avait donc répondu 508, 500 et 503, et le déclencheur ne figurait au journal sous aucun de ces trois codes : vue du dehors, la 503 de TigerProtect sortait en 404. Pas une seule extension à désactiver.

Les vérifications possibles en mutualisé

Sur un hébergement mutualisé, vous lisez le journal d’accès de votre domaine, le journal d’erreurs PHP de votre site et la consommation de votre compte. Vous ne lisez ni le journal d’erreurs du serveur web, ni les règles du pare-feu de l’hébergeur, ni le détail de ses limites. Ce qui est à votre portée, dans un cPanel :

• le journal d’accès du domaine, avec l’heure, l’adresse, le chemin et le code de chaque requête : c’est lui qui m’a donné les 111 540 réponses 508 ;
• le journal d’erreurs PHP (error_log), et le debug.log de WordPress si vous l’activez : pour cela, n’hésitez pas à consulter mon article sur le débogage de WordPress ;
• la page de consommation des ressources, quand l’hébergeur l’affiche, qui dit si le compte a touché ses limites (mémoire ou processus simultanés, par exemple) et à quelle heure ;
• l’interface du pare-feu de l’hébergeur (TigerProtect chez o2switch), où vous activez ou coupez des règles sans voir leur contenu.

Le reste vous échappe : le journal d’erreurs du serveur web (celui d’Apache, qui écrit AH01079), l’état des processus PHP, les règles internes du pare-feu. Sur un serveur OpenLiteSpeed que j’administre, le journal stderr.log du serveur n’est même pas lisible par les comptes des sites hébergés. Il faut les droits de l’administrateur…

Alors, que dire au support ? Le ticket que j’ai rédigé en juillet annonçait tout dans son objet : le test de sécurité de TigerProtect sur xmlrpc.php, Jetpack bloqué, les saturations en 508. Suivaient les heures, les chemins et les volumes. Un ticket qui dit "mon site affiche une 503" ne donne au support rien à chercher.

Sur la même boutique, en avril, j’avais noté dans mon rapport de maintenance des "erreurs 503 ponctuelles en clics rapides successifs". Je n’en ai jamais eu l’explication écrite : depuis le compte, aucun journal ne la donne.

Ma méthode pour trouver l’origine d’une 503

Je remonte la chaîne depuis le navigateur jusqu’à PHP, et je ne touche à WordPress qu’en dernier. Une 503 se diagnostique en quelques minutes quand on interroge le bon maillon, et en une soirée quand on désactive des extensions au hasard.

1. Notez l’heure exacte et les adresses touchées. Une 503 limitée à wp-login.php, xmlrpc.php ou /wp-admin/ pointe d’abord vers une protection : limite de débit, pare-feu, extension de sécurité.
2. Lisez la signature avec curl, depuis votre poste, et comparez-la au tableau plus haut.
3. Contournez le CDN avec --resolve. Si l’origine répond 200, cherchez du côté de Cloudflare : un Worker, ou un incident dans l’un de ses centres de données.
4. Ouvrez le journal du maillon désigné : error.log de Nginx (cherchez limiting requests), journal d’erreurs d’Apache (AH01079), varnishlog (FetchError), trafic en direct de Wordfence, ou, en mutualisé, le journal d’accès et la page des ressources.
5. Seulement alors, WordPress : un fichier .maintenance de moins de dix minutes, ou une extension de maintenance, puis les extensions et le thème, avec le debug.log ouvert. Désactiver des extensions n’a de sens que si la 503 sort de PHP.

Pour les autres pannes classiques (écran blanc, erreur 500, redirections en boucle), mon récapitulatif des erreurs WordPress reste la porte d’entrée.

Mon avis : durcir d’abord, migrer si ça revient

Quand une 503, ou sa cousine la 508, vient de la charge sur un hébergement mutualisé, je durcis d’abord. Si ça revient malgré tout, je quitte le mutualisé. Dans cet ordre : migrer un site qui se laisse marteler par des robots revient à déplacer le problème sur une facture plus grosse.

Durcir, pour moi, veut dire quatre gestes :

• couper XML-RPC si rien ne s’en sert, ou ne l’ouvrir qu’aux adresses de Jetpack si la boutique en dépend (la marche à suivre est dans mon article sur xmlrpc.php) ;
• poser une limite de débit sur wp-login.php et xmlrpc.php, sur le serveur ou chez Cloudflare, même avec le plan gratuit. Sous Nginx, ajoutez limit_req_status 429; : vos propres refus ne se confondront plus avec une panne dans les journaux ;
• mettre en cache ce qui ne l’est pas, à commencer par les pages lourdes que les robots demandent en boucle. En juillet, la page 404 rendue en entier à chaque requête rejetée a coûté plus cher que les requêtes elles-mêmes ;
• surveiller le site de l’extérieur avec le vrai code HTTP, toutes les quelques minutes. C’est ma sonde, et non un visiteur, qui a vu la 500 de midi.

Si les 503 ou les 508 reviennent quand même, le site a dépassé son hébergement. Un compte mutualisé partage ses limites avec d’autres, et vous cache les journaux qui disent qui a répondu. Un serveur à vous, géré par vous ou par un infogéreur, vous les rend.

Questions fréquentes

Une erreur 503 nuit-elle au référencement ?

Pas si elle est brève. D’après Google, les codes 5xx ralentissent l’exploration, le contenu reçu avec une 503 est ignoré et les pages déjà indexées restent dans l’index un temps, puis en sortent si l’erreur persiste. Google ne chiffre la durée que pour une mise en pause volontaire, un ou deux jours au plus. Quelques minutes de maintenance ralentissent au pire l’exploration, une 503 qui dure des jours ou revient chaque soir finit par faire sortir des pages.

Combien de temps dure une erreur 503 ?

Le temps de la cause. L’en-tête Retry-After donne une indication : 600 secondes pour le mode maintenance de WordPress (qui ignore le fichier .maintenance au bout de 10 minutes), 5 secondes pour Varnish, la durée du blocage pour Wordfence. La limite de débit de Nginx n’en envoie pas : le délai dépend du débit réglé (une requête par seconde dans le labo).

Pourquoi la 503 ne touche-t-elle que wp-login.php ou xmlrpc.php ?

Parce que ce sont les adresses que les protections surveillent. Une limite de débit Nginx, un blocage de Wordfence ou le test de navigateur d’un pare-feu d’hébergeur répondent 503 sur ces chemins, pendant que le reste du site répond 200. Regardez d’abord le journal de la protection, pas WordPress.

Quelle différence entre une erreur 502 et une erreur 503 ?

Moins qu’on ne le croit. Dans mon labo, la même panne de PHP-FPM a donné une 502 derrière Nginx et une 503 derrière Apache. La 502 dit qu’une passerelle n’a rien obtenu de valable du serveur suivant, la 503 qu’un serveur se déclare indisponible. Le code renseigne sur le maillon qui répond, le journal sur la cause.

Qui écrit "503 Service Temporarily Unavailable" ?

Nginx, quand sa limite de débit refuse une requête, et Wordfence, quand il bloque une adresse IP. Apache et WordPress écrivent "503 Service Unavailable", Varnish "503 Backend fetch failed". Le libellé n’apparaît qu’en HTTP/1.1 : en HTTP/2, lisez plutôt l’en-tête Server et le texte de la page.

Sources

Sources lues le 23 octobre 2026 ; labo Docker monté sur mon poste le même jour, captures et journaux conservés. Versions du labo : Nginx 1.28.3, branche ancienne, messages identiques dans le code actuel ; Varnish 7.6.5, version qui n’est plus suivie. Le code de Wordfence a été lu dans l’archive officielle de la version 9.0.2.

• Norme HTTP : RFC 9110, section 15.6.4 "503 Service Unavailable"
• Google : traitement des codes HTTP par les robots d’exploration
• Code de WordPress 7.1.3 : wp_maintenance() et wp_is_maintenance_mode() dans load.php, dead_db() et wp_die() dans functions.php, variable error et WP::send_headers() dans class-wp.php, référence de la fonction wp_maintenance()
• Serveurs web : module ngx_http_limit_req_module de Nginx et directive limit_req_status, module mod_proxy_fcgi d’Apache 2.4
• Varnish 7.6 : configuration intégrée builtin.vcl (page d’erreur et Retry-After)
• Wordfence : page de l’extension sur WordPress.org
• Cloudflare : erreur 503, origine ou Cloudflare, règles de limite de débit, délai des compteurs et limites du plan gratuit et paramètres de ces règles (code de réponse 429 par défaut)
• LiteSpeed : CloudLinux et l’erreur 508 Resource Limit Reached