Erreur 503 : surcharge, maintenance ou limite d'hébergement ?

Ce que signifie l'erreur

Avec un 503, le serveur web dit : « Je suis là, mais je ne peux pas vous servir pour l'instant. » Contrairement au 502, rien n'est forcément cassé. Le serveur envoie le 503 volontairement, dans trois situations : il est en mode maintenance, il a atteint une limite qu'on lui a fixée (connexions, workers, bande passante, débit), ou il est si chargé qu'il refuse des requêtes pour ne pas tomber tout à fait. Les moteurs de recherche considèrent un 503 bref comme temporaire et ne désindexent pas le site.

Causes fréquentes

1. Mode maintenance resté bloqué. Pendant une mise à jour, WordPress crée un fichier .maintenance et répond 503 tant qu'il existe. Mise à jour interrompue : le fichier reste, et l'erreur avec lui. Laravel, Magento et Drupal ont un interrupteur comparable.
2. Surcharge. Plus de requêtes que les workers n'en traitent : MaxRequestWorkers d'Apache atteint, pm.max_children de PHP-FPM épuisé, ou une base de données si lente que chaque worker attend.
3. Une limite d'hébergement. Les hébergeurs mutualisés plafonnent les secondes CPU, les processus simultanés ou les « entry processes » par compte. Limite atteinte, votre site répond 503.
4. Un backend sorti de la rotation. Derrière un répartiteur de charge ou un CDN, 503 signifie qu'aucun backend n'a passé le contrôle de santé. Cloudflare affiche sa propre page 503 quand le serveur d'origine est surchargé.
5. Bots et scrapers. Un crawler qui aspire des milliers de pages ou une attaque par force brute sur wp-login.php consomme les workers ; les vrais visiteurs reçoivent 503.
6. Disque ou mémoire pleins. Le service tourne mais ne peut plus écrire sessions, cache ou logs ; certaines applications répondent alors 503.

Si vous êtes visiteur

Attendez une minute et rechargez ; un 503 est le plus souvent bref. Si un site reste des heures en 503, son exploitant a un mode maintenance bloqué ou un problème de capacité ; lui seul peut agir.

Si c'est votre site : vérifier d'abord

Lancez le Site down checker pour confirmer le 503 depuis l'extérieur et voir si c'est un CDN ou votre serveur qui l'a envoyé. Puis tranchez : une mise à jour a-t-elle été lancée ces dernières minutes ? Si oui, c'est le mode maintenance. Sinon, c'est la capacité.

Sur votre propre serveur :

# le serveur web tourne-t-il seulement ?
systemctl status nginx
systemctl status apache2

# charge, mémoire, disque
uptime
free -m
df -h

# qui martèle le site ?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Charge bien au-dessus du nombre de cœurs, mémoire presque épuisée ou une seule IP avec des milliers de requêtes : chacun explique un 503.

Solutions sur votre propre serveur

1. Sortir d'un mode maintenance bloqué

WordPress : supprimez le fichier .maintenance à la racine du site et ouvrez la page. Si elle s'est interrompue, une extension ou le cœur est peut-être à moitié installé ; relancez la mise à jour avec WP-CLI :

rm /var/www/example.com/.maintenance
wp core verify-checksums
wp plugin update --all

Laravel : php artisan up. Drupal : drush state:set system.maintenance_mode 0.

2. Arrêter le flot

Bloquez l'IP ou le réseau suspect, puis limitez le débit pour que le suivant n'y arrive plus.

# bloquer une adresse (Debian/Ubuntu avec ufw)
sudo ufw deny from 203.0.113.45

Limitation de débit dans nginx pour la page de connexion :

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Apache : mod_evasive ou mod_qos font la même chose ; fail2ban bannit les récidivistes.

3. Donner de la capacité au serveur

Si la charge vient de vrais visiteurs et non d'un abus, relevez les limites de workers autant que la mémoire le permet. Apache (mpm_event) : MaxRequestWorkers. PHP-FPM : pm.max_children. Vérifiez d'abord la mémoire par worker (ps -ylC php-fpm8.3 --sort:rss), puis testez et rechargez :

sudo apachectl configtest && sudo systemctl reload apache2
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

Activez un cache de pages (WordPress : une extension de cache ou le cache FastCGI de nginx) pour qu'un pic ne lance plus PHP à chaque requête. Une page en cache coûte une fraction de milliseconde ; sans cache, des centaines.

4. Libérer le disque

sudo du -xh --max-depth=1 /var | sort -h | tail
sudo journalctl --vacuum-size=200M
sudo apt clean

Vieux logs, sauvegardes sur le même disque, journal de débogage qui enfle : les suspects habituels.

5. Derrière un répartiteur de charge

Si tous les backends échouent en même temps au contrôle de santé, c'est en général l'URL de contrôle qui est cassée (page supprimée, redirection vers HTTPS non suivie), pas chaque backend.

Si le problème est chez votre hébergeur

Sur un hébergement mutualisé, vous ne pouvez relever aucune limite. Demandez à votre hébergeur laquelle vous avez atteinte, et si c'est votre trafic ou un autre compte du même serveur :

Bonjour, mon site example.com répond « 503 Service Unavailable » depuis environ 9 h 10 (UTC). Je n'ai lancé aucune mise à jour, le site n'est pas en mode maintenance. Pourriez-vous me dire si mon compte a atteint une limite de ressources (CPU, processus, mémoire) ou si le serveur est surchargé ? Si c'est mon compte : quelle limite, et depuis quand ?

Si la réponse est régulièrement « limites atteintes », mettez le site en cache ou passez à une offre plus large.

Pour que cela ne se reproduise pas

Un 503 s'annonce : la charge monte, la mémoire se raréfie, une IP commence à inonder. Les vérifications du site attrapent le 503 dès qu'il apparaît ; l'agent serveur montre charge, mémoire et disque avant. Sur votre propre serveur ou un hébergement mutualisé avec accès SSH, l'intervention rapide libère de l'espace disque et redémarre un service bloqué, à prix fixe ; l'intervention approfondie met en place limitation de débit et cache, 24 h/24, pour que le serveur tienne la prochaine fois.