Ein 504 Gateway Timeout bedeutet: Ein Server, der als Gateway oder Proxy arbeitet, hat auf eine Antwort des Servers dahinter gewartet und irgendwann aufgegeben. Die Anfrage hat Ihr CDN, Ihren Load Balancer oder Webserver erreicht, wurde an die Anwendung weitergereicht, und die Anwendung hat nicht geantwortet, bevor das Zeitlimit ablief.
Der Server hinter dem Proxy läuft oft noch. Er ist nur zu langsam, oder etwas, auf das er wartet, ist es. Das unterscheidet einen 504 von den meisten Ausfällen: Ein Neustart hilft selten auf Dauer. Dieser Leitfaden zeigt, wie Sie herausfinden, welcher Timeout gegriffen hat, was eine Anfrage typischerweise ausbremst und wie Sie die Ursache beheben statt nur das Symptom.
Was ein 504 Ihnen verrät
Eine Anfrage an eine moderne Website durchläuft mehrere Schichten, und jede hat ihr eigenes Limit, wie lange sie auf die nächste wartet:
Ein CDN wie Cloudflare wartet eine feste Zeit auf Ihren Origin-Server.
Ein Load Balancer hat pro Ziel einen Idle- oder Response-Timeout.
nginx wartet auf den Upstream gemäß proxy_read_timeout oder fastcgi_read_timeout, standardmäßig 60 Sekunden.
Die Anwendung hat eigene Limits, etwa max_execution_time in PHP oder einen Worker-Timeout in Gunicorn.
Der 504 kommt von der ersten Schicht, deren Limit abläuft. Die benachbarten Fehler bedeuten etwas anderes: Ein 502 Bad Gateway heißt, dass der Upstream ungültig oder gar nicht geantwortet hat, und ein 503 Service Unavailable heißt, dass der Dienst die Anfrage abgelehnt hat, weil er überlastet oder in Wartung ist.
Den ausgelösten Timeout finden
Messen Sie die Dauer der Anfrage. Ein 504, der immer nach derselben Anzahl Sekunden kommt, deutet auf ein ganz bestimmtes Limit hin:
curl -s -o /dev/null -w „status %{http_code} after %{time_total}s\n“ https://www.example.com/reports
status 504 after 60.04s
Sehen Sie sich dann wie bei jedem 5xx-Fehler die Response-Header und die Fehlerseite an, um zu erkennen, welche Schicht geantwortet hat. Eine schlichte nginx-Seite mit server: nginx bedeutet, dass Ihr eigener Webserver in den Timeout gelaufen ist. Eine Seite im Design des CDN, die Ihren Host nennt, bedeutet, dass das CDN beim Warten auf Ihren Origin-Server aufgegeben hat.
nginx protokolliert den Timeout mit der Adresse, auf die es gewartet hat:
upstream timed out (110: Connection timed out) while reading response header from upstream,
upstream: „fastcgi://unix:/run/php/php8.3-fpm.sock“, request: „GET /reports HTTP/2.0“
Jetzt wissen Sie, welche Seite langsam ist und welcher Teil des Stacks sie warten ließ. Als Nächstes finden Sie heraus, warum.
Häufige Ursachen und wie Sie sie beheben
Langsame Datenbankabfragen
Der häufigste Grund. Eine Abfrage, die bei tausend Zeilen 50 Millisekunden dauerte, braucht bei einer Million 40 Sekunden, weil sie die ganze Tabelle durchsucht. Schalten Sie das Slow Query Log ein und suchen Sie nach den Abfragen der betroffenen Seite:
# MySQL / MariaDB
SET GLOBAL slow_query_log = ‚ON‘;
SET GLOBAL long_query_time = 1;
# PostgreSQL, in postgresql.conf
log_min_duration_statement = 1000
Führen Sie die langsamste Abfrage mit EXPLAIN aus und achten Sie auf vollständige Tabellenscans. Meist hilft ein fehlender Index. Die anderen üblichen Verdächtigen sind Sperren: Eine lange Transaktion oder eine Migration kann eine Tabelle blockieren, während jede Anfrage, die sie braucht, wartet.
Langsame externe APIs
Seiten rufen beim Aufbau oft andere Dienste auf: einen Zahlungsanbieter, einen Versandkostenrechner, eine Suchmaschine, ein CRM. Ist dieser Dienst langsam, ist Ihre Seite langsam, und Ihr Proxy läuft in den Timeout. Setzen Sie für jeden ausgehenden Aufruf einen kurzen Timeout, ein paar Sekunden statt des Standardwerts der Bibliothek, und legen Sie fest, was die Seite zeigt, wenn der Aufruf fehlschlägt. Eine Versandschätzung mit „wird an der Kasse berechnet“ ist besser als ein 504.
Behalten Sie die Dienste im Blick, von denen Sie abhängen. Das Drittanbieter-Monitoring von Uptimecheck verfolgt die Statusseiten von 31 Diensten wie Klarna, Shopify und Cloudflare, sodass ein langsamer Anbieter direkt neben Ihren eigenen Checks auftaucht.
Zu wenige Worker für den Traffic
Sind alle Worker beschäftigt, warten neue Anfragen in einer Warteschlange. Sie sind selbst nicht langsam, sie warten nur, bis sie an der Reihe sind, und die Uhr des Proxys läuft die ganze Zeit. PHP-FPM meldet das in seinem Log mit server reached pm.max_children. Mehr Worker helfen nur, wenn der Server genug Arbeitsspeicher und CPU dafür hat. Oft ist es besser, jede Anfrage kürzer zu machen, damit dieselben Worker mehr davon bedienen, und Seiten zu cachen, die nicht für jeden Besucher anders sind.
Lange Jobs innerhalb einer Web-Anfrage
Exporte, Importe, Berichtserstellung, Bildverarbeitung und der Versand Hunderter E-Mails gehören nicht in eine Web-Anfrage. Sie dauern so lange, wie sie dauern, und früher oder später überschreitet einer davon einen Timeout. Verlagern Sie sie in eine Hintergrund-Warteschlange: Die Anfrage startet den Job und antwortet sofort, und die Seite fragt das Ergebnis ab, oder der Nutzer bekommt eine E-Mail, wenn alles fertig ist.
Der Server selbst ist überlastet
Hohe CPU-Last, Speicherknappheit, die den Server in den Swap treibt, oder eine Festplatte, die nicht hinterherkommt, machen alles gleichzeitig langsam. Ein 504 auf jeder Seite, nicht nur auf einer, deutet darauf hin. Prüfen Sie CPU, Arbeitsspeicher, Swap und Disk-Wartezeit für denselben Zeitraum:
uptime
free -m
iostat -x 5 3
Server-Monitoring speichert diesen Verlauf, sodass Sie sehen, was der Server in der Minute tat, in der die 504-Fehler begannen, statt hinterher zu raten.
Netzwerkprobleme zwischen den Schichten
Erreicht der Proxy den Upstream überhaupt nicht, etwa weil eine Firewall Pakete verwirft statt sie abzulehnen, hängt die Verbindung, bis sie in den Timeout läuft. Das endet in einem 504, nicht in einem 502. Prüfen Sie, ob der Proxy von derselben Maschine aus eine Verbindung zu Adresse und Port des Upstreams aufbauen kann.
Wann ein höherer Timeout richtig ist
Manchmal dauert eine Anfrage aus gutem Grund lange: ein großer Upload, ein Bericht, den ein Admin einmal im Monat anfordert. Dann erhöhen Sie das Limit nur für diesen Pfad und halten die Reihenfolge der Schichten ein, sodass die äußeren länger warten als die inneren:
location /admin/exports/ {
proxy_read_timeout 300s;
proxy_pass http://app;
}
Ein höheres Limit für die ganze Website macht langsame Seiten nicht schneller. Besucher warten nur länger, bevor sie einen Fehler sehen, und langsame Anfragen blockieren Worker länger, was die Warteschlange für alle anderen verschlimmert.
Wie Monitoring 504-Fehler erkennt
Ein 504 kommt selten aus heiterem Himmel. Die Seite wurde mit wachsenden Datenmengen jede Woche ein wenig langsamer, bis sie eines Tages das Limit überschritt. Das ist eine gute Nachricht, denn so können Sie ihn kommen sehen.
Achten Sie auf die Antwortzeit, nicht nur auf den Status. Uptimecheck erfasst die Antwortzeit jedes Checks, aufgeteilt in DNS, Verbindungsaufbau, TLS, Server und Download, sodass Sie sehen, ob der Server langsamer wurde oder das Netzwerk. Ein Alarm bei langsamer Antwort meldet sich, wenn eine Seite Ihr eigenes Limit überschreitet, lange vor dem Timeout des Proxys. Unser Leitfaden zu einer guten Antwortzeit hilft Ihnen, das Limit festzulegen.
Fehler vor dem Alarm bestätigen. Checks laufen bis zu jede Minute aus Stockholm, London und New York, und jeder Fehler wird von einem zweiten Standort bestätigt, damit nicht eine einzelne langsame Anfrage jemanden aus dem Schlaf reißt.
Überwachen Sie die langsamen Seiten direkt. Suche, Checkout, Kontoseiten und Berichte sind die Stellen, an denen 504-Fehler auftreten, und selten die Startseite. Legen Sie Uptime-Monitore für sie an, mit einem Timeout, der dem entspricht, was ein Besucher hinnimmt.
504-Checkliste
Dauer der Anfrage messen: Eine runde Sekundenzahl verrät, welches Limit gegriffen hat.
Header und Fehlerseite lesen, um zu sehen, welche Schicht in den Timeout lief.
Die langsame Seite im Error-Log des Proxys finden.
Für diese Seite nach langsamen Abfragen, Sperren und langsamen externen Aufrufen suchen.
Worker, CPU, Arbeitsspeicher, Swap und Festplatte für dieselben Minuten prüfen.
Den langsamen Teil beschleunigen, cachen oder in einen Hintergrund-Job verlagern.
Timeouts nur für Pfade erhöhen, die zu Recht lange dauern, äußere Schichten länger als innere.
Bei langsamen Antworten alarmieren, damit der nächste 504 auffällt, solange er noch eine Verlangsamung ist.