Erreur 504 Gateway Time-out : signification et solutions

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 RFC 9110 la définit ainsi : « 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 » (RFC 9110 §15.6.5).

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 texte dépend de la couche qui a abandonné :

• 504 Gateway Time-out avec « nginx » en dessous — nginx (qui l'écrit avec un trait d'union)
• 504 Gateway Time-out · The server didn't respond in time. — la page par défaut de HAProxy
• Gateway Timeout · The gateway did not receive a timely response from the upstream server or application. — Apache devant PHP-FPM (mod_proxy_fcgi). Un Apache qui sert de proxy à un backend HTTP affiche à la place Proxy Error · Error reading from remote server (une 502).
• ERROR · The request could not be satisfied · 504 ERROR — Amazon CloudFront
• Error 524: A timeout occurred — la version de Cloudflare : il a joint votre serveur, mais la réponse n'est pas arrivée à temps
• Cette page ne fonctionne pas · example.com a mis trop de temps à répondre. · HTTP ERROR 504 — Chrome, quand la 504 n'a pas de page à elle

Quel que soit le texte, la cause est la même : un proxy a attendu le serveur placé derrière lui, et la réponse n'est pas arrivée à temps. (Chrome utilise la même phrase « a mis trop de temps à répondre » quand votre navigateur n'a pas pu se connecter du tout, mais le titre est alors « Ce site est inaccessible » et le code ERR_CONNECTION_TIMED_OUT, pas HTTP ERROR 504 : voir ERR_CONNECTION_TIMED_OUT.)

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 fastcgi_read_timeout de nginx est de 60 secondes, nginx cesse d'attendre et renvoie une 504 au répartiteur de charge, qui la retransmet à votre navigateur en passant par le CDN.

Le serveur qui renvoie la 504 est généralement un proxy situé au milieu, pas l'application elle-même. L'application est peut-être encore en train de traiter la requête, ou elle est peut-être bloquée.

Sources : Cloudflare 524, paramètres d'origine CloudFront, Google Cloud et la documentation de chaque serveur. Le max_execution_time de PHP (30 secondes) ne produit pas de 504 : un script qui l'atteint s'arrête sur une erreur fatale, qui s'affiche comme une 500. Et sous Linux, il ne compte pas le temps passé à attendre la base de données ou d'autres entrées-sorties : un script bloqué sur une requête lente peut donc tourner bien plus longtemps.

Causes courantes de l'erreur 504 Gateway Timeout

Les raisons habituelles pour lesquelles un proxy cesse d'attendre :

• Une requête lente — une requête lourde sur la base de données, un rapport ou l'appel d'une API tierce lente prend plus de temps que le délai du proxy.
• Un serveur surchargé — CPU à 100 %, mémoire saturée ou tous les workers PHP-FPM occupés : les nouvelles requêtes attendent dans une file jusqu'à ce que le proxy abandonne.
• Goulots d'étranglement de la base de données — requêtes lentes, index manquants, tables verrouillées ou pool de connexions épuisé.
• Des délais trop courts — les 60 secondes de nginx ne suffisent pas à un backend qui a légitimement besoin de plus (un export, un import, un gros envoi de fichier).
• Un problème réseau entre le proxy et l'origine — perte de paquets, ou un pare-feu qui jette les paquets du proxy sans rien dire (un pare-feu qui les rejette donne plutôt une 502).
• La limite fixe d'un CDN — Cloudflare attend 125 secondes sur les offres Free, Pro et Business, quel que soit le réglage de votre nginx, puis affiche l'Error 524.
• Un afflux de trafic — un pic ou une attaque occupe les workers, si bien que les requêtes ordinaires n'obtiennent pas de réponse à temps. (Un serveur qui se sait surchargé peut répondre 503 à la place.)

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 une minute et actualisez — beaucoup de 504 ne durent que le temps d'un pic d'activité sur le serveur.
• Vérifiez si le site est en panne pour tout le monde — le Vérificateur de site en panne ouvre la page depuis 11 endroits. Si eux aussi obtiennent une 504, le problème vient du site.
• Essayez un autre réseau — les données mobiles au lieu du Wi-Fi, ou sans VPN, au cas où votre propre proxy ou VPN serait la passerelle qui expire.
• Consultez la page de statut ou les réseaux sociaux du site — les sites très fréquentés y signalent souvent leurs pannes.

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_read_timeout 300;
    proxy_send_timeout 300;
}

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

# Leave proxy_connect_timeout / fastcgi_connect_timeout at their defaults:
# nginx caps them at about 75 seconds, and a dead backend should fail fast.

Pour Apache, ajoutez ProxyTimeout 300 dans votre VirtualHost, ou utilisez ProxyPass / http://backend:8080/ timeout=300 pour un seul backend.

Important : les délais de lecture et d'envoi mesurent l'intervalle entre deux opérations de lecture ou d'écriture successives, pas le temps total du transfert. Ainsi, proxy_read_timeout 300 signifie « si aucune donnée n'arrive pendant 300 secondes », et non « la réponse entière doit être terminée en 300 secondes ». Rechargez après les avoir modifiés : sudo nginx -t && sudo systemctl reload nginx.

Derrière un CDN, sa propre limite s'applique toujours : Cloudflare coupe à 125 secondes (de Free à Business) et CloudFront à 30 par défaut. Monter nginx au-delà ne change donc rien pour les visiteurs qui passent par le CDN.

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.3-fpm.log

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

Messages de log fréquents derrière une 504 :

« upstream timed out (110: Connection timed out) while reading response header from upstream » (nginx) — le backend a mis plus de temps que proxy_read_timeout (ou fastcgi_read_timeout). Accélérez-le, ou augmentez le délai si l'attente est légitime.

« upstream timed out (110: Connection timed out) while connecting to upstream » (nginx) — nginx n'a même pas réussi à se connecter à temps : un pare-feu qui jette les paquets, ou un backend trop occupé pour accepter les connexions.

« server reached pm.max_children setting » (PHP-FPM) — tous les workers sont occupés, les requêtes attendent donc dans la file. N'augmentez pm.max_children que s'il reste de la RAM pour cela ; sinon, trouvez les requêtes lentes qui monopolisent les workers.

« Too many connections » (MySQL) — la limite de connexions est atteinte. Les nouvelles connexions échouent immédiatement (une 500, comme le « Error establishing a database connection » de WordPress), tandis que les requêtes qui les occupent sont souvent les requêtes lentes à l'origine de vos 504.

Correction 5 : ajuster les Paramètres PHP-FPM

Pour les applications PHP (WordPress, Laravel, Magento), gardez des délais en chaîne, chaque couche un peu plus longue que celle qui se trouve derrière elle : le fastcgi_read_timeout de nginx ≥ le request_terminate_timeout de PHP-FPM ≥ le max_execution_time de PHP.

Après avoir modifié les paramètres de PHP-FPM, redémarrez-le (sudo systemctl restart php8.3-fpm, en adaptant la version). Si le fastcgi_read_timeout de nginx est plus court que les limites de PHP, nginx abandonne en premier et les visiteurs obtiennent une 504 alors que PHP travaille encore.

Correction 6 : vérifier la configuration du CDN et du proxy

Si votre site se trouve derrière un CDN comme Cloudflare ou AWS CloudFront, ce CDN a ses propres délais d'attente, qui peuvent l'emporter sur la configuration de votre serveur.

Cloudflare : sur les offres Free, Pro et Business, si votre origine n'a pas commencé à répondre au bout de 125 secondes, Cloudflare abandonne et affiche l'Error 524 (Cloudflare). Les conseils de Cloudflare : accélérer la requête, déplacer les tâches longues en arrière-plan, ou les servir depuis un sous-domaine en DNS uniquement (nuage gris) ; les offres Enterprise peuvent relever la limite.

CloudFront : augmentez le délai de réponse de l'origine dans les paramètres d'origine de la distribution (AWS). AWS conseille de corriger d'abord l'origine lente. Pour les requêtes GET et HEAD, CloudFront réessaie l'origine (3 tentatives de connexion par défaut) : l'origine peut donc recevoir plusieurs fois la même requête avant que le visiteur n'obtienne la 504.

Pour savoir quelle couche a envoyé la 504, examinez les en-têtes de réponse avec le Vérificateur d'en-têtes HTTP : server: awselb/2.0 désigne un répartiteur de charge AWS, x-cache: Error from cloudfront CloudFront, et server: nginx nginx. Derrière Cloudflare, chaque réponse indique server: cloudflare : c'est alors le code lui-même (524 ou 504) qui vous renseigne.

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.
• 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.
• Confiez wp-cron à une vraie tâche cron — ce sont les visites qui déclenchent WP-Cron, et il exécute les tâches dues dans une requête de bouclage (loopback) qui occupe un worker PHP à elle seule. Ajoutez define('DISABLE_WP_CRON', true); dans wp-config.php, puis faites exécuter wp cron event run --due-now par le serveur toutes les 5 minutes.

504 vs 502 vs 503 vs 408 : quelle est la différence ?

Ces codes d'erreur HTTP sont souvent confondus. Voici ce que chacun signifie réellement.

La distinction essentielle : la 502 signifie que le proxy a reçu une réponse défectueuse, ou que la connexion a été refusée ou fermée ; la 504 signifie que le minuteur du proxy a expiré pendant que l'upstream restait muet. La 503 n'a pas besoin de proxy : n'importe quel serveur peut l'envoyer quand il est surchargé. La 408 est un délai dépassé côté client (classe 4xx) : le serveur a cessé d'attendre le client.

Si vous voyez des 502 et des 504 ensemble, le backend est probablement en difficulté : les requêtes qui expirent donnent des 504, et les workers qui plantent ou sont tués donnent des 502.

Si c'est la 502 que vous voyez plutôt que la 504, notre guide de l'erreur 502 Bad Gateway passe en revue les messages du log d'erreurs de nginx qui l'expliquent, avec un cas réel survenu sur ce site.

L'erreur 504 affecte-t-elle le SEO ?

La documentation de Google décrit l'effet des erreurs 5xx (documentation des robots d'exploration de Google) :

• L'exploration ralentit sur l'ensemble du site, proportionnellement au nombre d'URL qui renvoient des erreurs serveur.
• Les pages indexées sont d'abord conservées, mais les URL qui renvoient une erreur serveur de façon persistante finissent par être retirées.
• L'exploration reprend progressivement dès que le serveur répond de nouveau en 2xx.

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 une surveillance — un outil de surveillance de disponibilité qui charge les pages clés toutes les quelques minutes repère les 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.