Erreur 504 Gateway Timeout : trouver ce qui ralentit

Ce que signifie l'erreur

Avec un 504, le serveur web en façade (nginx, Apache, un répartiteur de charge, un CDN) abandonne l'application derrière lui : la requête a été transmise, le backend travaillait encore quand le compteur en façade a expiré. La différence avec le 502 Bad Gateway : le backend est joignable, il est seulement trop lent. Délais habituels : 60 secondes dans nginx (fastcgi_read_timeout, proxy_read_timeout) et Apache (ProxyTimeout), 100 secondes chez Cloudflare.

Relever le délai est rarement la solution. Quelque chose prend trop de temps, et c'est cela qu'il faut trouver.

Causes fréquentes

1. Une requête SQL lente. Une extension qui compte les lignes d'une table énorme à chaque page, un index manquant, une table wp_options pleine de transients expirés. Sous charge, les attentes s'additionnent.
2. Un appel externe qui pend. L'application interroge un prestataire de paiement ou un service d'e-mail, et ce service est lent ou down. Sans délai propre, votre page attend avec lui.
3. Trop peu de workers. Tous les workers PHP-FPM sont pris dans des requêtes lentes ; les nouvelles font la queue jusqu'à ce que la façade abandonne. Vu de l'extérieur, c'est un timeout.
4. Cron ou sauvegarde au premier plan. Une sauvegarde, un import, un sitemap énorme : générés dans une requête web, ils dépassent n'importe quel délai.
5. Swap. Le serveur manque de mémoire, il swappe, tout devient dix fois plus lent : charge élevée, processeur peu occupé.
6. Réseau entre la façade et le backend. Rare, mais un 504 à chaque requête avec un backend inactif y fait penser.

Si vous êtes visiteur

Rechargez après une minute. Si le site est lent plutôt que down, essayez une autre page ; une seule page lourde est peut-être en cause.

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

Lancez le Site down checker : il donne le code HTTP et le temps de réponse vus de l'extérieur. Un site qui met 30 secondes aujourd'hui affichera un 504 demain.

Sur votre propre serveur, voici où chercher le temps perdu :

# des timeouts dans les logs ?
sudo tail -n 30 /var/log/nginx/error.log | grep -E 'timed out|timeout'

# que fait PHP ? (nécessite pm.status_path dans le pool)
curl -s 'http://127.0.0.1/fpm-status?full' | grep -E 'state|request URI|duration' | head -40

# MySQL/MariaDB : quelles requêtes tournent, depuis quand ?
sudo mysql -e 'SHOW FULL PROCESSLIST;'

# mémoire et swap
free -m
vmstat 1 5

Une liste pleine de la même requête, ou des colonnes si/so non nulles, nomment la cause.

Solutions sur votre propre serveur

1. Activer le journal des requêtes lentes et corriger la requête

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 2;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Après quelques minutes, sudo mysqldumpslow -s t /var/log/mysql/slow.log | head liste les pires requêtes. Ajoutez l'index manquant, ou remplacez l'extension qui lance la requête. Sur WordPress, la table d'options qui enfle est un classique : wp transient delete --all aide souvent.

2. Donner un délai aux appels externes

Chaque appel HTTP de votre application a besoin de son propre délai, plus court que celui du serveur web. En PHP avec cURL : CURLOPT_CONNECTTIMEOUT à 5 et CURLOPT_TIMEOUT à 10. Sur WordPress, wp_remote_get() accepte un argument timeout. Si un service tiers est down, la page doit s'afficher en version réduite, pas mourir.

3. Sortir les longs traitements de la requête

Sauvegardes, imports, exports, sitemaps et envois d'e-mails vont dans une tâche cron ou une file d'attente, pas dans une page. Sur WordPress, désactivez le pseudo-cron et installez le vrai :

// wp-config.php
define('DISABLE_WP_CRON', true);

# crontab -e
*/5 * * * * cd /var/www/example.com && wp cron event run --due-now >/dev/null 2>&1

4. Ajuster les délais, avec mesure

Si une page a légitimement besoin de plus de temps (un export, un rapport), relevez le délai pour elle seule, pas globalement :

location = /wp-admin/export.php {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
}

Apache : ProxyTimeout 300 dans un bloc <Location>. Mettez max_execution_time de PHP à la même valeur, sinon PHP abandonne le premier avec un 500. Puis sudo nginx -t && sudo systemctl reload nginx.

5. Arrêter de swapper

ps aux --sort=-%mem | head

Si chaque worker PHP-FPM prend 150 Mo et que vous en lancez 30 sur un serveur de 4 Go, le compte n'y est pas. Baissez pm.max_children, ajoutez de la mémoire, ou corrigez l'extension qui la dévore.

6. Mettre en cache

Un cache de pages (cache FastCGI de nginx, une extension WordPress, Varnish) sert les visiteurs sans toucher à PHP ni à la base de données. La plupart des 504 sous charge disparaissent dès que les pages les plus vues en sortent.

Si le problème est chez votre hébergeur

Sur un hébergement mutualisé, vous pouvez corriger requêtes lentes et extensions, mais pas les délais du serveur ni la charge des voisins :

Bonjour, mon site example.com renvoie « 504 Gateway Timeout » depuis environ 16 h (UTC). Des pages rapides jusqu'ici dépassent maintenant le délai. Je n'ai rien modifié. Pourriez-vous vérifier si le serveur de base de données ou le pool PHP de mon compte est surchargé, ou si un autre compte génère une forte charge ?

Pour que cela ne se reproduise pas

Un 504 est un site lent devenu encore plus lent, et le temps de réponse se mesure bien avant le timeout. Les vérifications du site l'enregistrent à chaque passage ; posez une alerte dessus et vous verrez la tendance bien avant que les visiteurs ne voient une erreur. Le monitoring serveur ajoute charge, mémoire et swap depuis l'intérieur. Sur votre propre serveur ou un hébergement mutualisé avec accès SSH, l'intervention approfondie trouve la requête lente ou l'appel qui pend et le corrige, 24 h/24, facturée par tranches de 15 minutes, prix affiché avant la commande ; l'intervention rapide, à prix fixe, redémarre un service arrêté.