Was bedeutet HTTP 504?
Ein Gateway hat nicht rechtzeitig die benötigte Antwort seines Upstreams erhalten. Der sichtbare HTTP-Endpunkt antwortet mit dem Fehler; das Backend kann noch arbeiten. Das unterscheidet 504 von einer Browsermeldung, bei der überhaupt keine rechtzeitige HTTP-Antwort ankommt.
Was Besucher tun können
Warte etwas und teste einen unkritischen Seitenaufruf. Nach einer Zahlung oder einem Formularversand zuerst den tatsächlichen Vorgangsstatus prüfen. Ein Gateway kann aufgeben, während der Auftrag im Backend später doch abgeschlossen wird.
Tritt der Fehler immer bei derselben Aktion auf, melde diese zusammen mit Zeit und URL. Browser-Erweiterungen zu deaktivieren ist bei einem reproduzierbaren 504 weniger naheliegend als eine Prüfung durch den Betreiber.
Betreiber: Wo vergeht die Zeit?
Korreliere Proxy- und Anwendungslogs mit Request-IDs. Prüfe, ob der Request den Upstream erreicht und ob er dort auf Datenbanklocks, langsame Abfragen, externe Dienste oder einen freien Worker wartet. Durchschnittswerte können einzelne sehr langsame Requests verdecken.
Vergleiche die Timeout-Kette von CDN, Load Balancer, Webserver und Anwendung. Ein vorgelagertes Limit kann kürzer sein als das der Anwendung. Prüfe auch Verbindungsaufbau und DNS im Backend-Netz, bevor du ausschließlich Ausführungszeit vermutest.
nginx, lange PHP-Aufrufe und WordPress
Bei FastCGI ist fastcgi_read_timeout relevant, bei HTTP-Upstreams proxy_read_timeout. Die genaue Bedeutung richtet sich nach der nginx-Dokumentation; es ist nicht einfach eine universelle maximale Gesamtlaufzeit.
Lange Importe, Backups und Plugin-Aufrufe gehören häufig in kontrollierte Hintergrundjobs mit sichtbarem Status. Optimiere die langsame Abhängigkeit und begrenze deren Laufzeit. Ein höherer Timeout kann Worker länger binden und die Warteschlange vergrößern.
504 gegenüber 502 und Browser-Timeout
502 beschreibt eine nicht gültige Upstream-Antwort; 503 eine vorübergehende Nichtverfügbarkeit. ERR_CONNECTION_TIMED_OUT ist eine Browsermeldung und kein HTTP-Statuscode. Ein externer Check liefert ein Vergleichssignal, kann aber deine Sitzung und deren langsamen Vorgang nicht nachbilden.
Häufige Fragen
Ist nach 504 die Aktion abgebrochen?
Nicht sicher. Das Backend kann weiterarbeiten. Prüfe den Vorgangsstatus, bevor du erneut sendest.
Ist mehr Timeout immer besser?
Nein. Ohne Ursachenprüfung kann es Ressourcen länger belegen und weitere Requests ausbremsen.
Kann eine externe API die Ursache sein?
Ja. Prüfe Dauer und Fehler der ausgehenden Aufrufe sowie deren eigene Timeouts und Retry-Regeln.