Erreur 503 Service Unavailable sur WordPress : solutions

503 Service Unavailable

En anglais : 503 Service Unavailable

Votre site répond par une page presque vide intitulée « 503 Service Unavailable » (« Service Temporarily Unavailable » avec nginx), ou par une phrase comme « The server is temporarily unable to service your request due to maintenance downtime or capacity problems ». L’erreur peut toucher tout le site, seulement l’administration, ou apparaître par intermittence aux heures de pointe.

Contrairement à une erreur 500, le code 503 dit explicitement que le problème est temporaire et que le serveur est en état de répondre plus tard. Ce n’est donc pas, en général, un bogue dans votre code : c’est un service arrêté, saturé ou volontairement fermé. Cette fiche traite le 503 renvoyé par le serveur ; si vous lisez « Brièvement indisponible pour cause de maintenance planifiée », c’est la maintenance de WordPress et la fiche maintenance bloquée vous concerne.

Ce que signifie cette erreur

Le code HTTP 503 « Service Unavailable » fait partie des libellés standards que WordPress connaît (get_status_header_desc() dans wp-includes/functions.php, qui associe 503 à « Service Unavailable », et la classe WP_Http qui le déclare comme constante SERVICE_UNAVAILABLE dans wp-includes/class-wp-http.php). Mais dans la grande majorité des cas, ce n’est pas WordPress qui l’émet : la réponse est produite avant PHP, par l’une de ces couches :

• Le serveur web : nginx renvoie 503 quand une limitation de débit (limit_req, limit_conn) rejette une requête sans autre réglage, car son code par défaut est 503 ; Apache le renvoie quand il ne peut pas joindre son application (mod_proxy_fcgi vers PHP-FPM arrêté) ou quand une règle le demande ;
• Le gestionnaire PHP (PHP-FPM, LiteSpeed, mutualisé CloudLinux) : processus tous occupés, service redémarré, quota de CPU ou de mémoire atteint ;
• Un intermédiaire : CDN, répartiteur de charge, pare-feu applicatif, qui répond lui-même 503 quand il ne parvient plus à joindre votre serveur d’origine ;
• WordPress ou une extension, volontairement : le mode maintenance du cœur (wp_maintenance() dans wp-includes/load.php envoie un en-tête Retry-After: 600 puis wp_die() avec le code 503), ou une extension de « bientôt disponible » qui répond 503 pour que les moteurs de recherche ne référencent pas la page d’attente.

Pour la panne entre le serveur web et PHP, voyez aussi la fiche erreur 502 ; pour un délai dépassé, la fiche erreur 504.

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
Message « Brièvement indisponible pour cause de maintenance planifiée »	Mode maintenance de WordPress resté actif	Présence du fichier .maintenance à la racine du site
Le site est en 503 puis revient seul, surtout aux heures chargées	Saturation de PHP-FPM (tous les processus occupés) ou d’Apache	Journal PHP-FPM : « server reached pm.max_children setting » ; journal Apache : « server reached MaxRequestWorkers setting »
Les images et fichiers statiques s’affichent, les pages PHP échouent	Service PHP arrêté ou planté	systemctl status du service PHP-FPM ; journal du serveur web
503 pour un visiteur ou un robot précis, pas pour les autres	Limitation de débit (limit_req), pare-feu, fail2ban	Journal nginx : « limiting requests, excess » ; règles du WAF ou du CDN
503 sur hébergement mutualisé, avec un message de limite de ressources	Quota de CPU, mémoire ou processus de l’offre atteint	Statistiques d’utilisation dans le panneau de l’hébergeur
503 immédiatement après un déploiement ou un redémarrage	Service en cours de démarrage ou configuration invalide	Test de configuration (nginx -t, apachectl configtest)

Les causes les plus fréquentes

1. La saturation des processus PHP : trop de requêtes simultanées pour le nombre de processus autorisés (pm.max_children), souvent à cause de robots, d’une campagne ou de pages non mises en cache.
2. Le mode maintenance de WordPress resté actif après une mise à jour interrompue.
3. Un service arrêté ou redémarré : PHP-FPM ou Apache tombé (mémoire insuffisante, mise à jour de paquets, configuration invalide).
4. Une limitation de débit trop stricte sur nginx, un WAF, un CDN ou une extension de sécurité qui répond 503 au lieu de 429.
5. Les quotas de l’hébergeur (CPU, mémoire, nombre de processus, entrées/sorties) sur une offre mutualisée.
6. Un script lent qui monopolise les processus : import, sauvegarde, requête SQL lourde, appel à une API externe qui ne répond pas.

Solutions pas à pas

Faites une sauvegarde avant toute modification de configuration, et testez-la (nginx -t, apachectl configtest) avant de recharger un service. Du moins invasif au plus technique :

1. Identifier qui répond 503

Lancez une requête sur la page d’accueil et sur un fichier statique, et regardez les en-têtes de réponse :

curl -sI https://www.exemple.fr/ | head -n 12
curl -sI https://www.exemple.fr/wp-includes/images/blank.gif | head -n 5

Un en-tête Retry-After et un corps « Brièvement indisponible… » indiquent la maintenance WordPress. Un en-tête Server: nginx ou Server: Apache avec un corps générique indique le serveur web. Un en-tête Server: cloudflare (ou celui de votre CDN) indique que l’erreur vient de l’intermédiaire. Si le fichier statique répond 200 et la page PHP 503, le problème se situe côté PHP.

2. Écarter le mode maintenance de WordPress

Connectez-vous en SFTP et regardez la racine du site (le dossier qui contient wp-config.php). S’il existe un fichier .maintenance, supprimez-le ; la procédure complète est dans la fiche sur la maintenance bloquée. Si une extension de maintenance est active, désactivez-la en renommant son dossier dans wp-content/plugins/.

3. Lire les journaux et redémarrer le service concerné

Sur un serveur que vous administrez, les journaux disent quelle limite est atteinte (chemins selon la distribution) :

# nginx
sudo tail -n 50 /var/log/nginx/error.log
# Apache (Debian / Ubuntu)
sudo tail -n 50 /var/log/apache2/error.log
# PHP-FPM : repérez le fichier du journal
sudo ls /var/log | grep -i php

# Redémarrage (adaptez le numéro de version de PHP)
sudo systemctl restart php8.2-fpm
sudo systemctl reload nginx     # ou : sudo systemctl reload apache2

Un redémarrage rend le site mais ne soigne pas la cause. Sur un mutualisé, il n’est pas à votre portée : ouvrez un ticket chez l’hébergeur avec l’heure exacte de l’erreur et l’URL.

Pour les lire efficacement, consultez l’article centraliser les logs nginx, PHP et WordPress.

4. Dimensionner PHP-FPM

Si le journal contient « server reached pm.max_children setting (N), consider raising it », tous les processus étaient occupés et les requêtes suivantes ont été refusées ou ont attendu. Augmentez pm.max_children dans le pool du site (fichier du type /etc/php/8.2/fpm/pool.d/monsite.conf), sans dépasser ce que la mémoire permet : divisez la mémoire disponible pour PHP par la consommation moyenne d’un processus (visible avec ps -ylC php-fpm8.2 --sort:rss).

pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

sudo php-fpm8.2 -t && sudo systemctl reload php8.2-fpm

Ajouter des processus ne règle rien si un script lent les monopolise : activez le journal des requêtes lentes avec request_slowlog_timeout = 5s et slowlog = /var/log/php8.2-fpm-slow.log dans le même pool, puis cherchez la page ou l’extension fautive.

5. Régler la limitation de débit sur nginx

Quand une règle limit_req rejette des requêtes, nginx répond 503 par défaut, ce qui fait croire à une panne. Le journal contient alors « limiting requests, excess: … by zone ». Choisissez un code honnête (429) et une rafale (burst) adaptée, en épargnant les zones qui déclenchent beaucoup de requêtes légitimes :

# dans le bloc http
limit_req_zone $binary_remote_addr zone=wpm_req:10m rate=10r/s;

# dans le bloc server
location / {
    limit_req zone=wpm_req burst=30 nodelay;
    limit_req_status 429;
    try_files $uri $uri/ /index.php?$args;
}

Le détail du 429, y compris côté WordPress, est dans la fiche erreur 429.

6. Régler le nombre de connexions d’Apache

Si le journal Apache signale « server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting » (code AH00161), augmentez la limite dans le module de multitraitement actif, toujours en fonction de la mémoire disponible :

# /etc/apache2/mods-available/mpm_event.conf
<IfModule mpm_event_module>
    ServerLimit            8
    ThreadsPerChild       25
    MaxRequestWorkers    200
</IfModule>

Vérifiez avec sudo apachectl configtest, puis rechargez avec sudo systemctl reload apache2. Gardez MaxRequestWorkers cohérent avec ServerLimit × ThreadsPerChild.

7. Réduire la charge à la source

• Installez ou vérifiez un cache de pages : servir une page statique ne mobilise aucun processus PHP.
• Identifiez les robots qui saturent le serveur dans le journal d’accès et limitez-les, comme l’explique l’article crawlers IA qui saturent le serveur.
• Déplacez les tâches lourdes (imports, sauvegardes) hors des heures de pointe, via un vrai cron système.
• Si vous êtes l’éditeur d’un service qui doit se protéger, répondez avec un Retry-After explicite, comme dans répondre 503 avec Retry-After.

8. Sans accès au serveur : que faire ?

Sur un hébergement mutualisé, consultez dans le panneau les statistiques d’utilisation (CPU, mémoire, processus) et le journal d’erreurs, désactivez les extensions par SFTP en renommant wp-content/plugins en plugins.off pour tester, puis demandez à l’hébergeur s’il applique des limites sur votre offre. Si les quotas sont atteints de façon répétée, le problème est de dimensionnement : il faut changer d’offre ou réduire la charge (solution 7).

Prévenir l’erreur

• Mettez en place une supervision externe (sonde sur la page d’accueil) qui vous prévient avant vos visiteurs.
• Activez un cache de pages et, si possible, un cache d’objets pour que le trafic courant ne réveille pas PHP.
• Dimensionnez pm.max_children avec la mémoire réelle, et gardez le journal des requêtes lentes actif.
• Faites répondre vos règles de limitation en 429 avec un en-tête Retry-After, jamais en 503 silencieux.
• Programmez mises à jour et imports hors des pics de trafic.