Come appare il messaggio
2026/10/23 10:02:41 [error] 1234#1234: *9012 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 198.51.100.7, server: cloud.beispiel.de, request: "POST /index.php/apps/files/ajax/upload.php HTTP/2.0"Cause frequenti
- Richieste lunghe: upload grandi, export, report, elaborazione immagini.
- Il pool PHP-FPM è pieno (
pm.max_childrenraggiunto) e le nuove richieste restano in coda. - Query al database lente o bloccate da lock.
fastcgi_read_timeoutoproxy_read_timeouttroppo bassi per il caso d'uso.- Backend su un altro host irraggiungibile per rete o firewall (la connessione va in timeout).
Verifica
- Trova i timeout nel log di nginx
grep 'upstream timed out' /var/log/nginx/error.log | tail -n 20 - Verifica se PHP-FPM arriva al limite
grep -i 'max_children' /var/log/php8.3-fpm.log - Misura i tempi di risposta
curl -s -o /dev/null -w 'connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://cloud.example.com/status.php - Mostra le query lente in esecuzione
mysqladmin -u root -p processlist
Soluzione
- Prima risolvi la causa: ottimizza le query lente, aggiungi indici, sposta i job lunghi in cron o in una coda.
- Alza
pm.max_childrenin base alla RAM (RAM per PHP diviso memoria per worker). - Alza i timeout insieme:
fastcgi_read_timeout 300s;in nginx emax_execution_timeerequest_terminate_timeoutin PHP-FPM. - Con catene di reverse proxy (load balancer, Docker, CDN) controlla il timeout su ogni livello.
- Dopo le modifiche:
nginx -t && systemctl reload nginxesystemctl reload php8.3-fpm.
Domande frequenti
Metto semplicemente il timeout a 3600 secondi?
No: nasconde il problema e tiene occupati i worker. Alza i timeout solo per location specifiche, come i percorsi di upload o export.
Perché ricevo 504 mentre PHP continua a girare?
nginx chiude solo la connessione verso il client. Lo script PHP continua finché non scattano max_execution_time o request_terminate_timeout.