Un 504 significa que la página aún se estaba construyendo cuando Nginx dejó de esperar. No se ha caído nada. Algo tardó más de lo que se le permite, y la pregunta honesta es qué.
Encuentra la petición lenta
PHP-FPM escribe un registro de lentitud si se lo pides, y anota la función exacta que se estaba ejecutando cuando se acabó el tiempo. Esa es toda la respuesta: actívalo antes de cambiar cualquier otra cosa.
; in the pool config
request_slowlog_timeout = 5s
slowlog = /var/log/php8.3-fpm-slow.log- Recarga PHP-FPM — systemctl reload php8.3-fpm
- Reproduce la página lenta — Con una petición basta.
- Lee la traza — tail -60 /var/log/php8.3-fpm-slow.log: el marco de arriba es lo que se estaba ejecutando.
Las tres cosas que suele ser
- Una llamada externa sin tiempo de espera. Una pasarela de pago o una API que ha dejado de responder retendrá tu página mientras el socket siga abierto. Cada petición saliente necesita su propio tiempo de espera, y cinco segundos ya es generoso.
- Una consulta sin índice. Una tabla que el año pasado era pequeña ya no lo es. El registro de consultas lentas la nombra.
- Un bucle sobre un directorio. Una carpeta que ha crecido hasta cien mil archivos tarda minutos en listarse.
Subir fastcgi_read_timeout hace desaparecer el error y deja al visitante mirando una pestaña en blanco cinco minutos en vez de uno. Arregla la espera, no el límite.
Cuándo subirlo SÍ es lo correcto
Un solo caso: un trabajo largo y deliberado que has lanzado tú mismo —una migración, una importación grande— en una página que solo usas tú. Súbelo para esa ubicación en concreto, nunca de forma global.
location = /admin/import.php {
fastcgi_read_timeout 600;
}Todo lo que pueda disparar un visitante pertenece a una cola. La página inicia el trabajo y responde de inmediato; el trabajo avisa cuando termina.