Türkei (Türkisch)
Germany (German)
Worldwide (English)
AnforderungsflussClient, NGINX und Backend-Verbindungsbrempunkt
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
504 Gateway Timeout, NGINX’s Backend wurde erreicht, aber keine Antwortüberschrift oder Daten wurden innerhalb der festgelegten Zeit erhalten. Diese Anleitung erklärt, wie PHP-FPM, Datenbank, externe API, Import und Anwendungsengpässe ohne Anpassung der Zeitlimite gefunden werden können.
2026/07/17 03:22:51 [error] 2190#2190: *1147 upstream timed out (110: Connection timed out) while reading response header from upstream
upstream: "fastcgi://unix:/run/php/php8.3-fpm.sock"504 zeigt an, dass NGINX’s Upstream-Ziel erreicht wurde, aber keine zeitnah verfügbare Antwort erhalten wurde. Die Grundursache könnte langsames PHP-Code, eine gesperrte Datenbank, externe API, voller Arbeiterpool oder interne unendliche Wartezeit sein.
Die im Log angegebene Phrase 'while connecting to upstream' weist auf ein Problem mit verzögerten Backend-Antworten während der Verbindungsherstellung hin; 'while reading response header from upstream' weist auf ein Problem mit verzögerten Backend-Antworten nach der Verbindungsherstellung hin.
proxy_read_timeout und fastcgi_read_timeout beschränken nicht die Gesamtverarbeitungszeit, sondern die Wartezeit zwischen zwei aufeinanderfolgenden Lesen. Eine Erhöhung seines Wertes kann einige längst laufende Prozesse beenden, aber es wird das Problem der langsamen Abfrage oder des blockierten Arbeiters nicht beseitigen.
Wenn lange Aufgaben wie WordPress-Import, WooCommerce-Bericht, große Sicherung, Videoverarbeitung oder externe API-Aufruf innerhalb eines HTTP-Anfrage ausgeführt werden, ist es gesünder, sie in eine Warteschlange, Cron oder Hintergrundarbeiterarchitektur zu verschieben.
Wenn der 504-Status nur während Spitzenzeiten auftritt, sollten Sie PHP-FPM max_children, Anwendungsarbeiteranzahl, MySQL-Slow-Query, CPU-Ladezeit und Disk-Verzögerung gemeinsam untersuchen.
Messung, wie lange es dauert, bevor die Timeout-Wert erhöht wird; Wartezeit sollte optimiert werden, nicht die Dauer.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Backend hat Verbindung akzeptiert, aber initialen Antwort-Header innerhalb der Zeit nicht produziert.
Mögliche Ursache: Langsame Anwendung, DB-Sperre, vollständiger Worker oder externer API.
Bedeutung: Die TCP/Socket-Verbindung zum Backend konnte innerhalb der angegebenen Zeit nicht hergestellt werden.
Mögliche Ursache: Netzwerk-, Backlog-, Dienstdichte- oder unerreichbares Ziel.
Bedeutung: Antwort begann, aber Datenfluss-Wartezeitlimit überschritten.
Mögliche Ursache: Langsame Stream, große Ausgabe oder Backend-Hang.
Bedeutung: In der PHP-FPM-Pool sind keine idle Worker vorhanden.
Mögliche Ursache: Unzureichende max_children oder langlaufende PHP-Anfragen.
Bedeutung: PHP hat die Ausführungszeitgrenze erreicht.
Mögliche Ursache: Langsame Code, großer Import oder externe Dienstverzögerung.
Bedeutung: Verbindung zur Datenbank während des langen Prozesses abgebrochen.
Mögliche Ursache: Timeout, Paketgröße, Neustart oder Netzwerkproblem.
Bedeutung: Browser-Allgemeine-Timeout-Seite wird angezeigt.
Mögliche Ursache: Proxy, FastCGI oder upstream Antwortverzögerung.
Bedeutung: Der Client-Anfrage wurde aufgrund von Zeitablauf nicht abgeschlossen.
Mögliche Ursache: Langsamer Upload oder Client-Verbindung; upstream 504 sollte nicht verwechselt werden.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
curl -sk -o /dev/null -w 'origin connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n' https://example.com/
curl -s -o /dev/null -w 'backend start=%{time_starttransfer} total=%{time_total}\n' http://127.0.0.1:3000/Zeigt an, ob die Verzögerung vor NGINX oder im Backend liegt.
grep -R "upstream timed out" /var/log/nginx 2>/dev/null | tail -n 100Es sammelt, welche URL und der Upstream-Ziel eine Zeitüberschreitung hat.
nginx -T | grep -nE 'proxy_(connect|read|send)_timeout|fastcgi_(connect|read|send)_timeout'Include-Dateien mit tatsächlichen Ausführungszeiten.
uptime
vmstat 1 5
iostat -xz 1 3 2>/dev/null
free -hÜberwacht CPU, RAM, Warteschlange und Diskus latenz.
ps -eo pid,etimes,%cpu,%mem,cmd --sort=-etimes | head -n 30
mysqladmin processlist 2>/dev/null | head -n 50Zeigt lang laufende Prozesse und Abfragen an.
nginx -t && systemctl reload nginx
curl -skI --max-time 30 https://example.com/Nach Änderungen sicheres Neuladen und Ergebnistest.
Obwohl die Grundursache des NGINX-Fehlers dieselbe ist, variieren Paketpfade, Dienstnamen, Sicherheitsebenen und die Verwaltung virtueller Hosts je nach verwendeter Linux-Distribution oder Plesk-Infrastruktur.
NGINX 504 Gateway Timeout für systemd, Paketpfad und journald-Prüfunglen.
grep -R 'upstream timed out' /var/log/nginx | tail -n 50
systemctl status nginx php8.3-fpm --no-pager
journalctl -u php8.3-fpm -n 100 --no-pagerNGINX 504 Gateway Timeout für SELinux, PHP-FPM-Pool und RHEL-basierte Dienstkontrollen.
grep -R 'upstream timed out' /var/log/nginx | tail -n 50
systemctl status nginx php-fpm --no-pager
journalctl -u php-fpm -n 100 --no-pagerNGINX-Virtualhost-Dateien, die von Plesk generiert werden: nginx 504 gateway timeout-Prüfungle.
grep -R 'upstream timed out' /var/www/vhosts/system/example.com/logs /var/log/nginx 2>/dev/null | tail -n 50
plesk repair web example.com -nZuerst bestimmen Sie, ob die Verzögerung im Verbindungsbereich, im ersten Antwort, im Datenübertragungs- oder im Anwendungsprozessschritt auftritt.
Protokollieren Sie, welcher Endpunkt den 504-Fehler verursacht, die gesamte Website oder wie viele Sekunden es dauert, bis ein 504-Fehler auftritt.
curl -sk -o /dev/null -w '%{http_code} %{time_starttransfer} %{time_total}\n' https://example.com/islemKlassifizieren Sie verbindende, Lesen von Response-Headern oder Lesen von Upstream-Expressionen
grep 'upstream timed out' /var/log/nginx/error.log | tail -n 50Senden Sie die gleiche Anfrage direkt an den Anwendungsport.
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' http://127.0.0.1:3000/islemSlowlog, langsame Anfrage, API-Aufruf und vollständigen Worker-Pool untersuchen.
ps -eo pid,etimes,%cpu,%mem,cmd --sort=-etimes | head -n 30Legen Sie die Dauer entsprechend der erwarteten Aufgabenzeit in der engsten Location-Block fest.
nginx -T | grep -nE 'proxy_read_timeout|fastcgi_read_timeout'Beobachte die Verhaltensweise von Worker und Zeit neben einer einzelnen Anfrage und mehreren gleichzeitigen Anfragen.
for i in {1..5}; do curl -sk -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/islem & done; waitDer Importvorgang kann durch PHP-Zeit, Speicher, DB und externe Medien-Download verzögert werden.
tail -f wp-content/debug.log /var/log/nginx/error.logGroße Tabellen und mangelnde Indizes können langsame Abfragen erzeugen.
mysqladmin processlistUpload-Timeout und Request-Body-Limit sollten getrennt voneinander kontrolliert werden.
nginx -T | grep -nE 'client_max_body_size|client_body_timeout'Die vom Anwendungs-Service an das externe Service übergebene Zeitüberschreitung kann länger sein als die von NGINX.
curl -v --max-time 15 https://api.example.net/healthÜberprüfen Sie den Worker-Pool, die DB-Verbindungsbeschränkung und die CPU-Sättigung.
uptime; free -h; ss -sBackend reagiert nicht ohne Neustart oder Bereitschaft könnte falsch sein.
docker stats --no-stream; docker psNGINX kann den Backend erreichen, aber antwortet innerhalb der angegebenen Zeit nicht. Langsame PHP, Datenbank, externe API, voller Worker-Pool oder Netzwerklatenz sind häufige Ursachen.
Nein. Es kann helfen, wenn der Prozess sehr lange dauern soll; aber es kann nur langsame Abfragen, Sperren oder abgestürzte Worker-Probleme verbergen.
Misst die Wartezeit zwischen zwei aufeinanderfolgenden Lesen vom FastCGI-Server; begrenzt die Gesamtzeit des gesamten Anforderung nicht direkt.
502 zeigt in der Regel an, dass eine Verbindung zum Backend nicht hergestellt werden konnte oder eine ungültige Antwort erhalten wurde; 504 zeigt an, dass eine Verbindung hergestellt wurde, aber innerhalb der angegebenen Zeit keine Antwort erhalten wurde.
NGINX error_log, PHP-FPM slowlog, WordPress debug.log und MySQL processlist sollten innerhalb desselben Zeitrahmens verglichen werden.
Es sollte möglichst unabhängig von HTTP-Anfragen mit WP-CLI, cron, Warteschlange oder Hintergrundarbeiter ausgeführt werden.
Überprüfen Sie gemeinsam max_children, Anwendungsarbeiteranzahl, DB-Verbindungsgrenze, CPU-Ladezeit, RAM und Disk-Verzögerung.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.