So sieht die Meldung aus
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"Häufige Ursachen
- Langlaufende Requests: große Uploads, Exporte, Reports, Bildverarbeitung.
- PHP-FPM-Pool ist voll (
pm.max_childrenerreicht), neue Requests warten in der Schlange. - Langsame oder gesperrte Datenbankabfragen.
fastcgi_read_timeoutbzw.proxy_read_timeoutzu niedrig für den Anwendungsfall.- Backend auf anderem Host über Netzwerk oder Firewall nicht erreichbar (Verbindungsaufbau läuft in den Timeout).
Prüfen
- Timeouts im nginx-Log finden
grep 'upstream timed out' /var/log/nginx/error.log | tail -n 20 - Prüfen, ob PHP-FPM an seine Grenze stößt
grep -i 'max_children' /var/log/php8.3-fpm.log - Antwortzeit gezielt messen
curl -s -o /dev/null -w 'connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://cloud.beispiel.de/status.php - Laufende, langsame Datenbankabfragen anzeigen
mysqladmin -u root -p processlist
Lösung
- Ursache zuerst beheben: langsame Queries optimieren, Indizes ergänzen, lange Jobs in Cron oder Queue auslagern.
pm.max_childrenpassend zum RAM erhöhen (RAM für PHP geteilt durch Speicher pro Worker).- Timeouts gemeinsam anheben:
fastcgi_read_timeout 300s;in nginx sowiemax_execution_timeundrequest_terminate_timeoutin PHP-FPM. - Bei Reverse-Proxy-Ketten (Load Balancer, Docker, CDN) auf jeder Stufe den Timeout prüfen.
- Nach Änderungen
nginx -t && systemctl reload nginxundsystemctl reload php8.3-fpm.
Häufige Fragen
Soll ich einfach den Timeout auf 3600 Sekunden setzen?
Nein. Das versteckt das Problem und bindet Worker. Höhere Timeouts nur gezielt für bestimmte Locations, etwa Upload- oder Export-Pfade.
Warum bekomme ich 504, obwohl PHP weiterläuft?
nginx bricht nur die Verbindung zum Client ab. Das PHP-Skript läuft weiter, bis max_execution_time oder request_terminate_timeout greift.