504 Gateway Timeout : Signification et Comment le Corriger

Qu'est-ce que l'Erreur 504 Gateway Timeout ?

Le 504 Gateway Timeout est un code de statut HTTP qui signifie qu'un serveur agissant comme passerelle ou proxy n'a pas reçu de réponse en temps voulu du serveur upstream. Le proxy a attendu que le serveur upstream réponde, mais cela a pris trop de temps, alors il a abandonné et renvoyé une erreur 504 à votre navigateur.

La définition officielle provient de la RFC 9110 (HTTP Semantics), Section 15.6.5, qui stipule : « Le code de statut 504 (Gateway Timeout) indique que le serveur, en agissant comme passerelle ou proxy, n'a pas reçu de réponse en temps voulu d'un serveur upstream auquel il devait accéder pour traiter la requête. »

Le mot clé est passerelle (gateway). Une erreur 504 implique toujours au moins deux serveurs : celui auquel vous vous êtes connecté (le proxy/passerelle) et celui derrière lui (le serveur upstream/origine) qui n'a pas répondu. Les proxies courants incluent Nginx en tant que proxy inverse, Cloudflare, AWS Application Load Balancer (ALB) et CloudFront.

À Quoi Ressemble l'Erreur 504

Le message d'erreur 504 varie selon le navigateur, le serveur web et le CDN. Voici les messages les plus courants que vous rencontrerez.

• 504 Gateway Timeout

• 504 Gateway Time-out (valeur par défaut de Nginx — utilise un tiret)

• HTTP Error 504 — Gateway Timeout

• Cette page ne fonctionne pas — [domaine] a mis trop de temps à répondre (Chrome / Edge)

• Gateway Timeout (Firefox)

• Error 504

• 504 Gateway Time-out — The server didn't respond in time (Apache avec mod_proxy)

• Error 524: A timeout occurred (spécifique à Cloudflare — techniquement pas un 504, mais la cause racine est la même)

• ERROR — The request could not be satisfied — 504 ERROR (AWS CloudFront)

Quel que soit le texte affiché, la cause sous-jacente est toujours la même : un serveur proxy a attendu que le serveur upstream réponde et celui-ci n'a pas répondu dans la fenêtre de timeout configurée.

Comment l'Erreur 504 Gateway Timeout Se Produit

Pour comprendre l'erreur 504, vous devez comprendre la chaîne de timeout entre votre navigateur et le serveur d'origine. Une requête web typique passe par plusieurs couches, et chaque couche a sa propre configuration de timeout.

Voici un flux de requête typique : Navigateur → CDN (Cloudflare) → Répartiteur de Charge → Nginx → PHP-FPM → Base de Données. Si la requête à la base de données prend 90 secondes et que le proxy_read_timeout de Nginx est réglé à 60 secondes, Nginx cesse d'attendre et renvoie un 504 au répartiteur de charge, qui le retransmet à votre navigateur.

Le serveur qui renvoie le 504 est toujours l'intermédiaire (proxy ou passerelle), jamais le serveur d'origine lui-même. Le serveur d'origine n'a simplement pas répondu à temps — il peut encore être en train de traiter la requête, ou il peut avoir complètement planté.

Causes Courantes de l'Erreur 504 Gateway Timeout

Comprendre la cause racine est le chemin le plus rapide vers la résolution. Voici les raisons les plus courantes pour lesquelles un serveur renvoie une erreur 504, classées par fréquence.

• Serveur d'origine lent — Des scripts PHP exécutant des requêtes complexes à la base de données, générant des rapports ou appelant des APIs tierces lentes peuvent dépasser le timeout du proxy. C'est la cause #1 des erreurs 504.

• Surcharge du serveur — CPU à 100 %, mémoire insuffisante (OOM kills) ou tous les workers PHP-FPM occupés. Le serveur d'origine est actif mais trop surchargé pour répondre à temps.

• Goulot d'étranglement de la base de données — Requêtes SQL lentes, index manquants, verrous de tables ou pools de connexions épuisés. L'application se bloque en attendant la base de données, et le proxy expire.

• Valeurs de timeout mal configurées — proxy_read_timeout de Nginx réglé trop bas pour un backend qui a légitimement besoin de plus de temps (ex : générateur de rapports ou gestionnaire d'upload de fichiers).

• Problèmes réseau entre proxy et origine — Perte de paquets, haute latence ou problèmes de routage entre les centres de données. Fréquent dans les configurations multi-régions ou cloud hybride.

• Pare-feu ou security group bloquant le trafic — Security groups AWS ne permettant pas le trafic sur les ports éphémères, règles iptables bloquant les connexions internes ou un WAF bloquant les requêtes upstream légitimes.

• Échec de résolution DNS au niveau du proxy — Le proxy ne parvient pas à résoudre le nom d'hôte du serveur upstream. Sous Nginx, cela se produit lors de l'utilisation de variables dans proxy_pass sans directive resolver.

• Timeout du CDN — Cloudflare impose une limite fixe de 100 secondes sur les plans Free/Pro/Business. Si votre serveur d'origine met plus de 100 secondes à répondre, Cloudflare renvoie l'Error 524 quelle que soit votre configuration Nginx.

• Attaque DDoS — Un flot de requêtes épuise les ressources du serveur, rendant l'origine trop lente pour répondre au trafic légitime dans la fenêtre de timeout du proxy.

Solution pour les Visiteurs : Ce Que Vous Pouvez Faire

Si vous voyez une erreur 504 sur le site web de quelqu'un d'autre, le problème vient de leur serveur — pas de votre appareil. Cependant, voici quelques actions qui valent la peine d'être tentées.

• Patientez et actualisez — La plupart des erreurs 504 sont temporaires. Attendez 30-60 secondes, puis forcez l'actualisation de la page avec Ctrl+Shift+R (Windows/Linux) ou Cmd+Shift+R (Mac).

• Vérifiez si le site est en panne pour tout le monde — Utilisez l'outil HTTP Headers de DNS Robot pour vérifier le code de réponse du serveur depuis un emplacement externe. S'il renvoie 504 pour tout le monde, le problème est côté serveur.

• Essayez en navigation privée ou avec un autre navigateur — Cela élimine les extensions du navigateur, les pages d'erreur en cache et les problèmes de configuration locale.

• Essayez un autre réseau — Passez du Wi-Fi aux données mobiles, ou désactivez votre VPN. Des problèmes de routage entre votre fournisseur d'accès et le serveur peuvent parfois causer un 504.

• Videz votre cache DNS — Des enregistrements DNS obsolètes peuvent diriger les requêtes vers le mauvais serveur. Sous Windows : ipconfig /flushdns. Sous Mac : sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder.

• Consultez la page de statut ou les réseaux sociaux du site — Le site a peut-être publié un avis concernant une panne connue ou une fenêtre de maintenance.

Correction 1 : Augmenter les Paramètres de Timeout (Nginx et Apache)

La correction la plus courante pour les erreurs 504 est d'augmenter les valeurs de timeout sur votre proxy inverse. Si votre backend a légitimement besoin de plus de 60 secondes (la valeur par défaut), le proxy doit savoir qu'il doit attendre plus longtemps.

# Nginx — reverse proxy to a backend (Node.js, Python, etc.)
location / {
    proxy_pass http://backend;
    proxy_connect_timeout 300;
    proxy_send_timeout    300;
    proxy_read_timeout    300;
    send_timeout          300;
}

# Nginx — FastCGI (PHP-FPM)
location ~ \.php$ {
    fastcgi_pass unix:/var/run/php-fpm.sock;
    fastcgi_read_timeout    300;
    fastcgi_send_timeout    300;
    fastcgi_connect_timeout 300;
    include fastcgi_params;
}

Pour Apache avec mod_proxy, ajoutez ProxyTimeout 300 dans votre VirtualHost ou utilisez ProxyPass / http://backend:8080/ timeout=300 pour une configuration par backend.

Important : Ces timeouts mesurent le temps entre deux opérations de lecture/écriture successives, pas le temps total de transfert. Ainsi proxy_read_timeout 300 signifie « si aucune donnée n'arrive pendant 300 secondes », pas « la réponse entière doit être terminée en 300 secondes ». Après avoir modifié les valeurs de timeout, rechargez la configuration : sudo nginx -t && sudo systemctl reload nginx.

Correction 2 : Optimiser les Scripts Lents et les Requêtes de Base de Données

Si votre backend dépasse systématiquement le timeout, augmenter la valeur du timeout ne fait que masquer le problème. La vraie solution est de rendre le backend plus rapide.

• Identifiez les requêtes lentes — Activez le log des requêtes lentes de MySQL (slow_query_log = 1, long_query_time = 1) ou utilisez EXPLAIN ANALYZE sur les requêtes suspectes. Ajoutez les index manquants, évitez SELECT * et paginez les grands ensembles de résultats.

• Ajoutez du cache — Utilisez Redis ou Memcached pour mettre en cache les résultats de requêtes coûteuses. Une requête qui prend 5 secondes à chaque chargement de page devrait être mise en cache.

• Déplacez le travail lourd vers des tâches en arrière-plan — La génération de rapports, l'envoi d'e-mails, le traitement d'images et les importations de données doivent s'exécuter dans une file de tâches (Celery, Sidekiq, Bull), pas dans le cycle de la requête HTTP.

• Optimisez les appels d'API — Si votre backend appelle des APIs tierces lentes, ajoutez des timeouts à ces appels et implémentez des circuit breakers pour qu'une API lente ne bloque pas toutes les requêtes.

• Réduisez les requêtes N+1 — Les requêtes générées par les ORM font souvent des centaines d'appels individuels à la base de données. Utilisez le chargement anticipé (eager loading) ou les requêtes par lots pour réduire les allers-retours.

Correction 3 : Vérifier les Ressources du Serveur (CPU, RAM, Disque)

Si le serveur d'origine est surchargé, il ne peut pas traiter les requêtes assez rapidement, et le proxy expire en attendant. Vérifiez ce qui consomme les ressources.

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

# Check disk space (full disk = silent failures)
df -h

# Check memory details
free -m

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

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

# Check active network connections
ss -s

Si le CPU ou la RAM est à 90 %+, vous devez soit optimiser votre application, soit arrêter les processus hors de contrôle, soit mettre à niveau votre serveur. Si l'espace disque est plein, nettoyez les anciens fichiers de log, les sauvegardes ou les fichiers temporaires — un disque plein peut faire planter silencieusement les bases de données et provoquer des erreurs 504 en cascade.

Correction 4 : Consulter les Logs d'Erreur

Les logs d'erreur vous indiquent exactement pourquoi le proxy a renvoyé un 504. Consultez toujours les logs avant de deviner la cause.

# Nginx error log (look for "upstream timed out")
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

# System log (OOM kills, crashes)
tail -50 /var/log/syslog

Messages courants dans les logs qui causent des erreurs 504 :

"upstream timed out (110: Connection timed out)" (Nginx) — Le serveur upstream n'a pas répondu dans le délai proxy_read_timeout. Augmentez le timeout ou corrigez le serveur upstream lent.

"server reached pm.max_children" (PHP-FPM) — Tous les processus worker PHP sont occupés. Augmentez pm.max_children dans la configuration du pool PHP-FPM.

"connect() failed (111: Connection refused)" (Nginx) — Le serveur upstream ne tourne pas ou n'écoute pas sur le port attendu. Redémarrez le backend.

"Too many connections" (MySQL) — La limite de connexions de la base de données est atteinte. Augmentez max_connections dans la configuration MySQL ou optimisez le pool de connexions.

Correction 5 : Ajuster les Paramètres PHP-FPM

Après avoir modifié les paramètres PHP-FPM, redémarrez le service : sudo systemctl restart php8.2-fpm. Assurez-vous que le fastcgi_read_timeout de Nginx est toujours supérieur ou égal au max_execution_time de PHP. Sinon, Nginx abandonne avant que PHP ne termine, créant une erreur 504.

Correction 6 : Vérifier la Configuration du CDN et du Proxy

Utilisateurs Cloudflare : Si vous êtes sur un plan Free, Pro ou Business et que votre serveur d'origine met plus de 100 secondes à répondre, vous obtiendrez toujours l'Error 524. Les seules options sont : optimiser votre backend pour répondre en moins de 100 secondes, déplacer les tâches longues vers des jobs en arrière-plan, ou passer au plan Enterprise.

Utilisateurs AWS CloudFront : Augmentez le timeout de réponse d'origine dans les paramètres d'origine de votre distribution. La valeur par défaut de 30 secondes est souvent trop basse pour le contenu dynamique.

Utilisez l'outil HTTP Headers de DNS Robot pour vérifier les en-têtes de réponse et identifier quelle couche renvoie le 504. Recherchez des en-têtes comme server: cloudflare, server: awselb/2.0 ou server: nginx pour identifier le proxy.

Correction 7 : Solutions Spécifiques à WordPress

Les sites WordPress sont particulièrement sujets aux erreurs 504 en raison de plugins lourds, de bases de données encombrées et des limites de l'hébergement mutualisé. Voici des corrections ciblées.

• Identifiez les plugins lents — Désactivez tous les plugins, puis réactivez-les un par un. Si vous ne pouvez pas accéder à wp-admin, renommez le dossier plugins via SSH : mv wp-content/plugins wp-content/plugins_disabled. Utilisez le plugin Query Monitor pour identifier les requêtes lentes à la base de données.

• Augmentez la mémoire PHP — Ajoutez define('WP_MEMORY_LIMIT', '512M'); dans wp-config.php. De nombreux plugins ont besoin de plus que les 128 Mo par défaut.

• Installez un plugin de cache — WP Super Cache, W3 Total Cache ou WP Rocket réduisent le traitement côté serveur en servant du HTML statique au lieu d'exécuter PHP à chaque requête.

• Utilisez le cache d'objets — Installez Redis ou Memcached et un plugin d'object cache pour WordPress. Cela met en cache les résultats des requêtes de base de données en mémoire, réduisant la charge MySQL.

• Nettoyez la base de données — Supprimez les anciennes révisions d'articles, les transients, les commentaires de spam et les métadonnées orphelines. Utilisez WP-Optimize ou WP-Sweep. Ajoutez define('WP_POST_REVISIONS', 5); pour limiter les futures révisions.

• Désactivez wp-cron — Le cron virtuel de WordPress s'exécute à chaque chargement de page et peut accumuler des tâches. Ajoutez define('DISABLE_WP_CRON', true); dans wp-config.php et configurez un vrai cron job sur le serveur : */5 * * * * curl -s https://votresite.com/wp-cron.php > /dev/null 2>&1.

504 vs 502 vs 503 vs 408 : Quelle Est la Différence ?

La distinction essentielle : le 502 signifie que le proxy a reçu une mauvaise réponse, tandis que le 504 signifie que le proxy n'a reçu aucune réponse. Le 503 ne nécessite pas de proxy — n'importe quel serveur peut le renvoyer lorsqu'il est surchargé. Le 408 est un timeout côté client (classe 4xx), où le serveur a cessé d'attendre le client.

Si vous voyez un 502 et un 504 en même temps, le serveur upstream est probablement en train de planter. Le 502 se produit lorsque le proxy reçoit une réponse partielle ou corrompue d'un processus mourant, et le 504 se produit lorsque le processus ne répond plus du tout.

L'Erreur 504 Affecte-t-elle le SEO ?

Réponse courte : un 504 bref n'a aucun impact sur le SEO. Un 504 prolongé peut entraîner une désindexation.

Minutes à heures : Aucun impact. Google comprend les erreurs serveur temporaires et ne pénalise pas immédiatement. Si Googlebot ne crawle pas pendant la panne, il ne le remarquera même pas.

Heures à jours : Google réduit la fréquence de crawl pour les sites renvoyant des erreurs 5xx afin de ne pas ajouter de charge à un serveur en difficulté. Les pages peuvent apparaître comme « Erreur serveur (5xx) » dans le rapport d'Indexation des Pages de Google Search Console.

Jours à semaines : Des erreurs 504 persistantes peuvent entraîner la désindexation des pages concernées. Les classements chutent significativement. Selon John Mueller de Google : si un serveur est en panne pendant un jour, les choses peuvent être « en flux » pendant une à trois semaines après la récupération.

Récupération : Une fois que le serveur est à nouveau stable, Google re-crawle et re-indexe automatiquement les pages. Utilisez l'outil d'Inspection d'URL de Google Search Console pour demander la réindexation des pages importantes. Le temps de récupération dépend de la taille du site et de la durée des erreurs.

Comment Prévenir les Erreurs 504 Gateway Timeout

La prévention vaut mieux que le dépannage en urgence. Ces pratiques maintiendront votre serveur en mesure de répondre dans les limites de timeout.

• Mettez en place un monitoring — Utilisez un monitoring de disponibilité (UptimeRobot, Pingdom ou l'outil Ping de DNS Robot) pour détecter les erreurs 504 avant que vos utilisateurs ne les signalent.

• Alignez votre chaîne de timeout — Assurez-vous que timeout CDN >= timeout proxy >= timeout application. Des valeurs désalignées causent des erreurs 504 imprévisibles.

• Implémentez des health checks — Les répartiteurs de charge et les proxies doivent vérifier la santé des serveurs upstream et rediriger le trafic loin des instances qui ne répondent pas.

• Utilisez le cache agressivement — Mettez en cache les ressources statiques, les réponses d'API et les requêtes de base de données. Une réponse en cache n'est jamais assez lente pour causer un 504.

• Auto-scaling — Utilisez la mise à l'échelle horizontale (plus d'instances) pour que les pics de trafic ne submergent pas un seul serveur.

• Déchargez le travail lourd — Déplacez le traitement de fichiers, la génération de rapports, l'envoi d'e-mails et les importations en masse vers des files de tâches en arrière-plan. Ne faites jamais de travail coûteux au sein d'une requête HTTP.

• Surveillez les requêtes lentes — Activez le log des requêtes lentes dans MySQL/PostgreSQL. Configurez des alertes pour les requêtes dépassant 1 seconde.

• Maintenez les dépendances en bonne santé — Surveillez les APIs tierces dont votre backend dépend. Ajoutez des timeouts et des circuit breakers pour qu'une API lente ne provoque pas des erreurs 504 en cascade pour tous les utilisateurs.