Un 504 signifie que la page était encore en construction quand Nginx a cessé d'attendre. Rien n'a planté. Quelque chose a pris plus de temps qu'il n'en a le droit, et la vraie question est : quoi.

Trouvez la requête lente

PHP-FPM écrit un journal des lenteurs si vous le lui demandez, et il indique la fonction exacte qui tournait quand le temps s'est écoulé. C'est toute la réponse : activez-le avant de changer quoi que ce soit d'autre.

; in the pool config
request_slowlog_timeout = 5s
slowlog = /var/log/php8.3-fpm-slow.log
  1. Rechargez PHP-FPM — systemctl reload php8.3-fpm
  2. Reproduisez la page lente — Une seule requête suffit.
  3. Lisez la trace — tail -60 /var/log/php8.3-fpm-slow.log — la trame du haut est ce qui tournait.

Les trois choses que c'est en général

  • Un appel externe sans délai. Une passerelle de paiement ou une API qui ne répond plus retiendra votre page aussi longtemps que la connexion reste ouverte. Chaque requête sortante a besoin de son propre délai, et cinq secondes est déjà généreux.
  • Une requête sans index. Une table qui était petite l'an dernier ne l'est plus. Le journal des requêtes lentes la nomme.
  • Une boucle sur un répertoire. Un dossier qui a grossi jusqu'à cent mille fichiers met des minutes à se lister.
Relever fastcgi_read_timeout fait disparaître l'erreur et laisse le visiteur fixer un onglet vide cinq minutes au lieu d'une. Corrigez l'attente, pas la limite.

Quand le relever EST la bonne chose

Un seul cas : un travail long et voulu que vous avez lancé vous-même — une migration, un gros import — sur une page que vous seul utilisez. Relevez-le pour ce seul emplacement, jamais globalement.

location = /admin/import.php {
    fastcgi_read_timeout 600;
}
Tout ce qu'un visiteur peut déclencher appartient à une file. La page lance le travail et rend la main aussitôt ; le travail signale quand il a fini.