Erreur HTTP 503 (Service Unavailable) : causes et solutions

Qu'est-ce que l'erreur HTTP 503 ?

503 Service Unavailable signifie que le serveur, ou quelque chose placé devant lui, ne peut pas traiter votre requête pour le moment : il est surchargé, en maintenance, limite le débit des requêtes ou n'a aucun backend opérationnel vers lequel la transmettre. La RFC 9110 la définit comme un état temporaire qui devrait disparaître après un certain délai.

Le serveur peut ajouter un en-tête Retry-After indiquant combien de temps attendre. Contrairement à une erreur 500, qui signifie que quelque chose est cassé, un 503 dit « pas maintenant » : c'est pourquoi les sites l'utilisent pour leurs maintenances planifiées.

Souvent, ce n'est même pas votre serveur web qui répond, mais une couche placée devant lui : un répartiteur de charge comme HAProxy, un cache comme Varnish, un CDN comme Cloudflare ou un ingress Kubernetes. Le libellé exact vous dit laquelle (voir ci-dessous).

À quoi ressemble une erreur 503

Le message indique quelle couche a répondu. Voici les plus courants, avec le logiciel qui les affiche :

Quel que soit le libellé, la réponse est la même : cette requête ne peut pas être servie pour le moment, et c'est la couche indiquée dans le tableau qu'il faut examiner.

Causes courantes de l'erreur HTTP 503

Les raisons habituelles pour lesquelles un serveur, ou une couche placée devant lui, renvoie un 503 :

• Surcharge — limites de CPU, de mémoire ou de connexions atteintes lors d'un pic de trafic, d'un contenu viral ou du passage d'un robot d'exploration agressif
• Maintenance planifiée — le site est volontairement hors ligne pour une mise à jour ou une migration ; bien faite, elle s'accompagne d'un en-tête Retry-After
• Aucun backend opérationnel — le répartiteur de charge, le proxy ou l'ingress n'a aucun serveur fonctionnel vers qui envoyer la requête (application plantée, contrôles de santé en échec, aucun pod prêt)
• Limites de débit ou de connexions — limit_req et limit_conn de nginx répondent 503 par défaut : un client ou un robot très actif peut donc en provoquer un
• Une application plantée ou arrêtée — PHP-FPM, Node.js ou Python est à l'arrêt derrière un serveur web qui, lui, tourne ; sous IIS, un pool d'applications arrêté
• Limites de ressources de l'hébergement — un hébergement mutualisé plafonne le CPU, la mémoire et le nombre de processus par compte
• Un plugin, un thème ou une mise à jour — sous WordPress et d'autres CMS, une mauvaise mise à jour peut faire planter l'application ou bloquer le site en mode maintenance
• Une attaque — une attaque DDoS ou un afflux de bots épuise les mêmes ressources qu'un pic de trafic

Solution pour les visiteurs : ce que vous pouvez faire

Si vous visitez le site de quelqu'un d'autre, le problème vient de chez lui. Voici ce que vous pouvez faire :

• Attendez et réessayez — un 503 est censé être temporaire : attendez une minute et rechargez la page une seule fois. Si la page affiche un délai Retry-After ou un message de maintenance, attendez ce délai
• Vérifiez si le site est en panne pour tout le monde — le Vérificateur de site en panne de DNS Robot teste le site depuis l'extérieur de votre réseau
• Consultez la page de statut ou les réseaux sociaux du site — les maintenances planifiées et les pannes y sont généralement annoncées
• Essayez un autre réseau — si le site s'ouvre avec les données mobiles, soit un VPN ou un proxy de votre réseau habituel répond avec le 503, soit le site limite le débit de votre adresse IP

Solution 1 : trouvez quelle couche a envoyé le 503

Avant de redémarrer quoi que ce soit, regardez le message et les en-têtes de la réponse : ils indiquent quelle couche a répondu. Vérifiez depuis l'extérieur avec le Vérificateur d'en-têtes HTTP de DNS Robot ou curl -sI, et regardez l'en-tête server et le corps de la page (voir le tableau ci-dessus).

Redémarrez ensuite la couche qui pose problème, pas seulement le serveur web :

# Restart Nginx
sudo systemctl restart nginx

# Restart Apache
sudo systemctl restart apache2      # Debian/Ubuntu
sudo systemctl restart httpd         # CentOS/RHEL

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm    # Adjust version as needed

# Restart Node.js (PM2)
pm2 restart all

# Restart entire server (last resort)
sudo reboot

Si le 503 revient quelques minutes après un redémarrage, la cause est toujours là : passez aux ressources et aux logs.

Solution 2 : vérifiez les ressources du serveur (CPU, RAM, disque)

Si le serveur est surchargé, un redémarrage n'apporte qu'un répit temporaire. Vérifiez ce qui consomme les ressources.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space
df -h

# Check memory in detail
free -m

# Check active connections
ss -s

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

Si le CPU ou la RAM dépasse 90 %, vous devez optimiser votre application, arrêter les processus incontrôlés ou passer à un serveur plus puissant. Si le disque est plein, supprimez des fichiers de logs, d'anciennes sauvegardes ou des fichiers temporaires.

Solution 3 : consultez les logs d'erreur

Les logs indiquent exactement pourquoi le 503 s'est produit. Lisez les dernières lignes avec les commandes ci-dessous, puis cherchez-y ces messages :

# Nginx error log
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log      # Debian/Ubuntu
tail -50 /var/log/httpd/error_log         # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# WordPress debug log (if WP_DEBUG_LOG is enabled)
tail -50 /var/www/html/wp-content/debug.log

# System log
tail -50 /var/log/syslog

« limiting requests » ou « limiting connections » (nginx) — limit_req ou limit_conn a rejeté la requête ; la réponse est un 503, sauf si vous définissez limit_req_status ou limit_conn_status.

« max_children » (PHP-FPM, par ex. « server reached pm.max_children setting ») — tous les workers PHP sont occupés : Apache répond 503, tandis que nginx répond 502 ou 504.

« AH01114 » / « failed to make connection to backend » (mod_proxy d'Apache) — Apache n'a pas pu joindre le backend et a répondu 503.

« Too many connections » (MySQL) — la limite de connexions de la base de données est atteinte.

Les messages « no live upstreams » et « upstream timed out » de nginx relèvent du 502 Bad Gateway et du 504 Gateway Timeout, pas du 503.

Solution 4 : désactivez les plugins et thèmes (WordPress / CMS)

Sous WordPress et d'autres CMS, un plugin gourmand peut épuiser les workers PHP ou les limites de ressources de votre hébergeur, ce qui donne un 503 (un plugin qui plante donne plutôt une erreur 500). Si le 503 est apparu après la mise à jour ou l'installation d'un plugin, commencez par celui-ci.

Si vous ne pouvez pas accéder au tableau de bord d'administration WordPress, désactivez les plugins via le système de fichiers ou la base de données.

# Disable all plugins by renaming the plugins folder
cd /var/www/html/wp-content
mv plugins plugins_disabled

# If the site loads, rename it back and re-enable plugins one by one
mv plugins_disabled plugins

# To disable a single plugin
mv plugins/problem-plugin plugins/problem-plugin.disabled

Après avoir identifié le plugin défectueux, mettez-le à jour, remplacez-le par une alternative ou contactez son développeur. Vérifiez également si votre version de PHP est compatible : certains plugins ne fonctionnent plus après une mise à jour de PHP sur le serveur.

Bloqué sur « Indisponibilité temporaire pour cause de maintenance » (« Briefly unavailable for scheduled maintenance » sur un site en anglais) ? WordPress crée un fichier .maintenance à la racine du site pendant les mises à jour et l'ignore dès qu'il a plus de 10 minutes. Supprimez-le pour rétablir le site plus tôt ; si le message reste affiché, cherchez un fichier wp-content/maintenance.php ou une copie de la page en cache.

Solution 5 : augmentez les limites PHP et serveur

Si votre serveur manque de workers PHP ou atteint les limites de mémoire, vous devez augmenter les limites dans votre configuration.

; PHP-FPM pool (e.g. /etc/php/8.2/fpm/pool.d/www.conf); the default ships with pm.max_children = 5
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

; php.ini (defaults: memory_limit = 128M, max_execution_time = 30)
memory_limit = 256M
max_execution_time = 300

Redémarrez ensuite PHP-FPM (sudo systemctl restart php8.2-fpm, avec votre version) pour charger les nouvelles limites.

Solution 6 : vérifiez votre CDN ou votre répartiteur de charge

Si vous utilisez Cloudflare, un autre CDN ou un répartiteur de charge, le 503 peut venir de lui plutôt que de votre serveur.

La règle de Cloudflare (son guide sur l'erreur 503) :

• La page contient « cloudflare » ou « cloudflare-nginx » — c'est Cloudflare qui l'a générée : vérifiez qu'aucun Worker ne dépasse ses limites de CPU ou de mémoire, puis contactez le support Cloudflare en joignant la sortie de /cdn-cgi/trace
• Aucune mention de Cloudflare — votre serveur d'origine a renvoyé le 503 et Cloudflare l'a transmis : consultez les logs de l'origine et demandez à votre hébergeur s'il limite le débit des adresses IP de Cloudflare

Avec HAProxy, un répartiteur de charge cloud ou un ingress Kubernetes, vérifiez les backends : un 503 à ce niveau signifie généralement qu'aucun backend n'a pu prendre la requête (pour un Application Load Balancer d'AWS, que le groupe cible n'a aucune cible enregistrée). La Recherche DNS de DNS Robot confirme que votre domaine pointe toujours là où vous l'attendez.

Solution 7 : vérifiez les attaques DDoS ou de bots

Un pic soudain de trafic provenant de bots ou une attaque DDoS peut submerger votre serveur. Vérifiez vos logs d'accès pour détecter des schémas suspects.

# Count requests per IP in the last 1000 lines
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Requests per minute (use -f1-4 for per second)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | sort -rn | head -10

# Block an abusive IP (-I puts the rule first, before any ACCEPT rules)
sudo iptables -I INPUT -s 1.2.3.4 -j DROP

# Or in nginx's server block:
# deny 1.2.3.4;

Si une seule adresse ou une petite plage envoie des milliers de requêtes, bloquez-la au niveau du pare-feu. Derrière Cloudflare ou un autre CDN, faites d'abord apparaître la véritable IP du visiteur dans vos logs (set_real_ip_from et real_ip_header CF-Connecting-IP dans nginx), sinon vous bloquerez le CDN au lieu de l'attaquant. Face à une attaque de grande ampleur, le mode « I'm Under Attack » de Cloudflare ou la protection DDoS de votre hébergeur filtre le trafic avant qu'il ne vous atteigne.

Solution 8 : corrigez les problèmes de connexion à la base de données

Quand la base de données n'a plus de connexions disponibles ou s'arrête, l'application placée devant elle peut échouer. Certaines applications répondent alors 503 ; WordPress affiche plutôt « Erreur lors de la connexion à la base de données » (« Error establishing a database connection » sur un site en anglais). Vérifiez directement la base de données :

# Check if MySQL/MariaDB is running (the unit is mysqld on RHEL, mariadb for MariaDB)
sudo systemctl status mysql

# Restart MySQL
sudo systemctl restart mysql

# Check current connections vs limit
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

# Increase max connections (temporary)
mysql -e "SET GLOBAL max_connections = 200;"

# Check for long-running queries
mysql -e "SHOW PROCESSLIST;" | head -20

Si vous voyez de nombreuses connexions dormantes, votre application ne ferme pas correctement les connexions à la base de données. Si des requêtes de longue durée bloquent les autres, optimisez ces requêtes ou arrêtez-les pour débloquer la base de données.

Solution 9 : contactez votre hébergeur

Si vous êtes sur un hébergement mutualisé, un WordPress managé ou une plateforme comme Squarespace, Wix ou Shopify, vous n'avez peut-être pas accès aux logs du serveur ni la possibilité de redémarrer les services. Dans ces cas, le 503 peut être causé par l'infrastructure de l'hébergeur.

Contactez le support de votre hébergeur et fournissez :

• L'URL exacte qui renvoie un 503
• Quand l'erreur a commencé — notez la date et l'heure
• Ce qui a changé — avez-vous installé un plugin, mis à jour un thème ou modifié des paramètres DNS ?
• Si c'est intermittent ou constant — les erreurs 503 intermittentes suggèrent des limites de ressources ; les erreurs 503 constantes suggèrent un plantage ou une mauvaise configuration

503 vs autres erreurs HTTP

L'erreur 503 est souvent confondue avec d'autres erreurs serveur. Voici comment elles se distinguent.

La différence clé : le 503 est censé être temporaire, et un en-tête Retry-After peut indiquer pour combien de temps. Pour l'exploration, Google traite les erreurs 5xx et 429 de la même façon : ses robots ralentissent, et les URL indexées sont conservées un temps, puis retirées si les erreurs persistent (Google Search Central).

Pour les erreurs côté proxy, voir 502 Bad Gateway et 504 Gateway Timeout ; pour les limites de débit, 429 Too Many Requests.

Comment prévenir les erreurs 503

Mieux vaut prévenir que guérir. Voici les bonnes pratiques pour éviter les erreurs 503.

• Surveillez les ressources du serveur — Configurez des alertes pour CPU > 80 %, RAM > 85 % et disque > 90 %. Des outils comme UptimeRobot, Pingdom ou Grafana fournissent des notifications instantanées.
• Utilisez un CDN — Cloudflare, Fastly ou AWS CloudFront mettent en cache les ressources statiques et absorbent les pics de trafic, réduisant la charge sur le serveur d'origine.
• Activez la mise en cache — Utilisez Redis, Memcached ou Varnish pour mettre en cache les requêtes de base de données et les pages générées. Utilisateurs WordPress : installez un plugin de cache comme WP Super Cache ou W3 Total Cache.
• Auto-scaling — Si vous utilisez un hébergement cloud (AWS, GCP, Azure, DigitalOcean), configurez l'auto-scaling pour ajouter des serveurs supplémentaires lors des pics de trafic.
• Limitez le débit des bots — Configurez nginx ou Cloudflare pour limiter le débit des robots d'exploration et des scrapers agressifs avant qu'ils ne surchargent votre serveur.
• Optimisez les requêtes de base de données — Les requêtes lentes monopolisent connexions et workers. Ajoutez des index, optimisez les jointures et mettez les résultats en cache dans Redis ou Memcached.
• Utilisez une page de maintenance adaptée — Pendant les déploiements, renvoyez un 503 avec un en-tête Retry-After au lieu de laisser le serveur planter. Cela préserve le SEO et informe les utilisateurs.
• Maintenez vos logiciels à jour — Mettez à jour votre CMS, vos plugins, PHP et votre base de données vers les dernières versions stables pour éviter les bugs connus et les problèmes de sécurité.