Un 504 significa che la pagina si stava ancora costruendo quando Nginx ha smesso di aspettare. Non è caduto nulla. Qualcosa ha impiegato più tempo di quanto gli sia concesso, e la domanda onesta è: che cosa.
Trova la richiesta lenta
Se glielo chiedi, PHP-FPM scrive un registro delle lentezze e stampa esattamente la funzione che era in esecuzione quando il tempo è scaduto. È tutta lì la risposta: attivalo prima di cambiare qualsiasi altra cosa.
; in the pool config
request_slowlog_timeout = 5s
slowlog = /var/log/php8.3-fpm-slow.log- Ricarica PHP-FPM — systemctl reload php8.3-fpm
- Riproduci la pagina lenta — Basta una sola richiesta.
- Leggi la traccia — tail -60 /var/log/php8.3-fpm-slow.log — la cornice in cima è ciò che era in esecuzione.
Le tre cose che di solito sono
- Una chiamata esterna senza tempo massimo. Un gestore di pagamenti o un'API che ha smesso di rispondere terrà ferma la tua pagina finché il socket resta aperto. Ogni richiesta in uscita ha bisogno di un proprio tempo massimo, e cinque secondi sono già generosi.
- Un'interrogazione senza indice. Una tabella che l'anno scorso era piccola adesso non lo è più. Il registro delle interrogazioni lente la nomina.
- Un ciclo su una cartella. Una cartella cresciuta fino a centomila file impiega minuti solo per essere elencata.
Alzare fastcgi_read_timeout fa sparire l'errore e lascia il visitatore a fissare una scheda bianca per cinque minuti invece che per uno. Correggi l'attesa, non il limite.
Quando alzarlo È la cosa giusta
Un caso solo: un lavoro lungo e voluto che hai avviato tu — una migrazione, un'importazione grossa — su una pagina che usi soltanto tu. Alzalo per quella singola posizione, mai globalmente.
location = /admin/import.php {
fastcgi_read_timeout 600;
}Tutto ciò che un visitatore può far partire va messo in coda. La pagina avvia il lavoro e torna subito indietro; è il lavoro a farsi vivo quando ha finito.