504 Gateway Time-out: Bedeutung, Ursachen und Lösung

Was ist ein 504 Gateway Timeout?

Ein 504 Gateway Timeout ist ein HTTP-Statuscode, der bedeutet, dass ein Server, der als Gateway oder Proxy fungiert, keine rechtzeitige Antwort von einem Upstream-Server erhalten hat. Der Proxy hat auf die Antwort des Upstream-Servers gewartet, aber es hat zu lange gedauert, sodass der Proxy aufgegeben und einen 504-Fehler an Ihren Browser zurückgesendet hat.

RFC 9110 definiert ihn so: „Der Statuscode 504 (Gateway Timeout) zeigt an, dass der Server, während er als Gateway oder Proxy agierte, keine rechtzeitige Antwort von einem Upstream-Server erhalten hat, auf den er zugreifen musste, um die Anfrage abzuschließen“ (RFC 9110 §15.6.5).

Das Schlüsselwort ist Gateway. Ein 504 betrifft immer mindestens zwei Server: den, mit dem Sie verbunden sind (der Proxy/Gateway), und den dahinter liegenden (den Upstream/Origin), der nicht rechtzeitig geantwortet hat. Häufige Proxys sind Nginx Reverse Proxy, Cloudflare, AWS Application Load Balancer (ALB) und CloudFront.

Wie ein 504-Fehler aussieht

Der Wortlaut hängt davon ab, welche Schicht aufgegeben hat:

• 504 Gateway Time-out mit „nginx“ darunter — nginx (schreibt es mit Bindestrich)
• 504 Gateway Time-out · The server didn't respond in time. — die Standardseite von HAProxy
• Gateway Timeout · The gateway did not receive a timely response from the upstream server or application. — Apache vor PHP-FPM (mod_proxy_fcgi). Ein Apache, der ein HTTP-Backend proxyt, zeigt stattdessen Proxy Error · Error reading from remote server (ein 502).
• ERROR · The request could not be satisfied · 504 ERROR — Amazon CloudFront
• Error 524: A timeout occurred — die Cloudflare-Variante: Cloudflare hat Ihren Server erreicht, aber die Antwort kam nicht rechtzeitig
• Diese Seite funktioniert nicht · Die Antwort von example.com hat zu lange gedauert. · HTTP ERROR 504 — Chrome, wenn der 504 keine eigene Seite mitbringt

Egal wie der Text lautet, die Ursache ist dieselbe: Ein Proxy hat auf den Server dahinter gewartet, und die Antwort kam nicht rechtzeitig. (Chrome verwendet denselben Satz „hat zu lange gedauert“ auch, wenn Ihr Browser überhaupt keine Verbindung aufbauen konnte — dann lautet die Überschrift aber „Die Website ist nicht erreichbar“ und der Code ERR_CONNECTION_TIMED_OUT, nicht HTTP ERROR 504: siehe ERR_CONNECTION_TIMED_OUT.)

Wie ein 504 Gateway Timeout entsteht

Um den 504-Fehler zu verstehen, müssen Sie die Timeout-Kette zwischen Ihrem Browser und dem Origin-Server verstehen. Eine typische Webanfrage durchläuft mehrere Schichten, und jede Schicht hat ihre eigene Timeout-Einstellung.

Hier ist ein typischer Anfrage-Ablauf: Browser → CDN (Cloudflare) → Load Balancer → Nginx → PHP-FPM → Datenbank. Wenn die Datenbankabfrage 90 Sekunden dauert und fastcgi_read_timeout in nginx 60 Sekunden beträgt, hört nginx auf zu warten und gibt einen 504 an den Load Balancer zurück, der ihn über das CDN an Ihren Browser weiterreicht.

Der Server, der den 504 zurückgibt, ist meist ein Proxy in der Mitte, nicht die Anwendung selbst. Die Anwendung arbeitet vielleicht noch an der Anfrage — oder sie hängt fest.

Quellen: Cloudflare 524, CloudFront-Ursprungseinstellungen, Google Cloud und die Dokumentation des jeweiligen Servers. PHPs eigenes max_execution_time (30 Sekunden) erzeugt keinen 504: Ein Skript, das daran stößt, bricht mit einem Fatal Error ab, der als 500 erscheint. Und unter Linux zählt es die Zeit nicht mit, die mit Warten auf die Datenbank oder andere I/O vergeht — ein Skript, das an einer langsamen Abfrage hängt, kann also weit länger laufen.

Häufige Ursachen für 504 Gateway Timeout

Die üblichen Gründe, warum ein Proxy das Warten aufgibt:

• Eine langsame Anfrage — eine schwere Datenbankabfrage, ein Bericht oder der Aufruf einer langsamen Drittanbieter-API dauert länger als das Timeout des Proxys.
• Ein überlasteter Server — CPU bei 100 %, Speicherdruck oder alle PHP-FPM-Worker belegt, sodass neue Anfragen in einer Warteschlange stehen, bis der Proxy aufgibt.
• Datenbank-Engpässe — langsame Abfragen, fehlende Indizes, gesperrte Tabellen oder ein erschöpfter Verbindungspool.
• Zu niedrige Timeouts — die 60 Sekunden von nginx sind zu kurz für ein Backend, das berechtigterweise länger braucht (ein Export, ein Import, ein großer Upload).
• Netzwerkprobleme zwischen Proxy und Origin — Paketverlust oder eine Firewall, die die Pakete des Proxys stillschweigend verwirft (eine Firewall, die sie ablehnt, ergibt stattdessen 502).
• Das feste Limit eines CDN — Cloudflare wartet bei Free, Pro und Business 125 Sekunden, egal was Ihr nginx erlaubt, und zeigt dann Error 524.
• Eine Traffic-Flut — eine Lastspitze oder ein Angriff bindet die Worker, sodass normale Anfragen nicht rechtzeitig beantwortet werden. (Ein Server, der seine Überlastung erkennt, kann stattdessen mit 503 antworten.)

Lösung für Besucher: Was Sie tun können

Wenn Sie einen 504-Fehler auf einer fremden Website sehen, liegt das Problem auf deren Server — nicht auf Ihrem Gerät. Es gibt jedoch einige Dinge, die Sie versuchen können.

• Eine Minute warten und neu laden — viele 504-Fehler dauern nur so lange wie ein Lastmoment auf dem Server.
• Prüfen, ob die Seite für alle down ist — der Website-Down-Checker öffnet die Seite von 11 Orten aus. Bekommen auch diese einen 504, liegt es an der Website.
• Ein anderes Netzwerk versuchen — mobile Daten statt WLAN oder ohne VPN, falls Ihr eigener Proxy oder Ihr VPN das Gateway ist, das in den Timeout läuft.
• Statusseite oder Social-Media-Konten der Website prüfen — stark besuchte Websites melden Störungen oft dort.

Fix 1: Timeout-Einstellungen erhöhen (Nginx & Apache)

Die häufigste Lösung für 504-Fehler ist die Erhöhung der Timeout-Werte auf Ihrem Reverse Proxy. Wenn Ihr Backend legitimerweise mehr als 60 Sekunden (der Standard) benötigt, muss der Proxy wissen, dass er länger warten soll.

# nginx — reverse proxy to a backend (Node.js, Python, etc.)
location / {
    proxy_pass http://backend;
    proxy_read_timeout 300;
    proxy_send_timeout 300;
}

# nginx — FastCGI (PHP-FPM)
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    include fastcgi_params;
}

# Leave proxy_connect_timeout / fastcgi_connect_timeout at their defaults:
# nginx caps them at about 75 seconds, and a dead backend should fail fast.

Für Apache fügen Sie ProxyTimeout 300 in Ihren VirtualHost ein oder verwenden ProxyPass / http://backend:8080/ timeout=300 für ein einzelnes Backend.

Wichtig: Die Read- und Send-Timeouts messen die Pause zwischen zwei aufeinanderfolgenden Lese- oder Schreibvorgängen, nicht die gesamte Übertragungszeit. proxy_read_timeout 300 bedeutet also „wenn 300 Sekunden lang keine Daten ankommen“, nicht „die gesamte Antwort muss in 300 Sekunden fertig sein“. Laden Sie nach der Änderung neu: sudo nginx -t && sudo systemctl reload nginx.

Hinter einem CDN gilt dessen eigenes Limit weiterhin: Cloudflare bricht nach 125 Sekunden ab (Free bis Business), CloudFront standardmäßig nach 30. nginx darüber hinaus anzuheben, ändert für Besucher, die über das CDN kommen, also nichts.

Fix 2: Langsame Skripte und Datenbankabfragen optimieren

Wenn Ihr Backend konstant das Timeout überschreitet, verdeckt eine Erhöhung des Timeout-Werts nur das Problem. Die eigentliche Lösung besteht darin, das Backend schneller zu machen.

• Langsame Abfragen finden — Aktivieren Sie das MySQL Slow Query Log (slow_query_log = 1, long_query_time = 1) oder verwenden Sie EXPLAIN ANALYZE für verdächtige Abfragen. Fügen Sie fehlende Indizes hinzu, vermeiden Sie SELECT * und paginieren Sie große Ergebnismengen.
• Caching hinzufügen — Verwenden Sie Redis oder Memcached, um teure Abfrageergebnisse zu cachen. Eine Abfrage, die bei jedem Seitenaufruf 5 Sekunden dauert, sollte gecacht werden.
• Schwere Arbeit in Hintergrundjobs verlagern — Berichtserstellung, E-Mail-Versand, Bildverarbeitung und Datenimporte sollten in einer Job-Queue (Celery, Sidekiq, Bull) laufen, nicht im HTTP-Request-Zyklus.
• API-Aufrufe optimieren — Wenn Ihr Backend langsame Drittanbieter-APIs aufruft, fügen Sie Timeouts zu diesen Aufrufen hinzu und implementieren Sie Circuit Breaker, damit eine langsame API nicht alle Anfragen blockiert.
• N+1-Abfragen reduzieren — ORM-generierte Abfragen führen oft Hunderte einzelner Datenbankaufrufe aus. Verwenden Sie Eager Loading oder Batch-Abfragen, um die Roundtrips zu reduzieren.

Fix 3: Serverressourcen prüfen (CPU, RAM, Festplatte)

Wenn der Origin-Server überlastet ist, kann er Anfragen nicht schnell genug verarbeiten, und der Proxy läuft in den Timeout. Prüfen Sie, was Ressourcen verbraucht.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space (full disk = silent failures)
df -h

# Check memory details
free -m

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Check active network connections
ss -s

Wenn CPU oder RAM bei 90%+ liegen, müssen Sie entweder Ihre Anwendung optimieren, unkontrollierte Prozesse beenden oder Ihren Server aufrüsten. Wenn der Festplattenspeicher voll ist, löschen Sie alte Logdateien, Backups oder temporäre Dateien — eine volle Festplatte kann Datenbanken lautlos zum Absturz bringen und kaskadenartige 504-Fehler verursachen.

Fix 4: Fehlerprotokolle prüfen

Fehlerprotokolle sagen Ihnen genau, warum der Proxy 504 zurückgegeben hat. Prüfen Sie immer die Logs, bevor Sie die Ursache erraten.

# Nginx error log (look for "upstream timed out")
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log       # Debian/Ubuntu
tail -50 /var/log/httpd/error_log          # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.3-fpm.log

# System log (OOM kills, crashes)
tail -50 /var/log/syslog

Häufige Log-Meldungen hinter einem 504:

„upstream timed out (110: Connection timed out) while reading response header from upstream“ (nginx) — das Backend hat länger gebraucht als proxy_read_timeout (oder fastcgi_read_timeout). Machen Sie es schneller oder erhöhen Sie das Timeout, wenn das Warten berechtigt ist.

„upstream timed out (110: Connection timed out) while connecting to upstream“ (nginx) — nginx konnte nicht einmal rechtzeitig eine Verbindung aufbauen: eine Firewall, die Pakete verwirft, oder ein Backend, das zu beschäftigt ist, um Verbindungen anzunehmen.

„server reached pm.max_children setting“ (PHP-FPM) — alle Worker sind belegt, also warten Anfragen in der Warteschlange. Erhöhen Sie pm.max_children nur, wenn der RAM dafür reicht; andernfalls suchen Sie die langsamen Anfragen, die Worker blockieren.

„Too many connections“ (MySQL) — das Verbindungslimit ist ausgeschöpft. Neue Verbindungen scheitern sofort (ein 500, etwa WordPress' „Error establishing a database connection“), während die Abfragen, die die Verbindungen halten, oft genau die langsamen hinter Ihren 504-Fehlern sind.

Fix 5: PHP-FPM-Einstellungen anpassen

Bei PHP-Anwendungen (WordPress, Laravel, Magento) halten Sie die Timeouts als Kette, jede Schicht etwas länger als die dahinter: fastcgi_read_timeout von nginx ≥ request_terminate_timeout von PHP-FPM ≥ max_execution_time von PHP.

Starten Sie PHP-FPM nach Änderungen neu (sudo systemctl restart php8.3-fpm, Version anpassen). Ist fastcgi_read_timeout in nginx kürzer als die Limits von PHP, gibt nginx zuerst auf, und Besucher bekommen einen 504, während PHP noch arbeitet.

Fix 6: CDN- und Proxy-Konfiguration prüfen

Liegt Ihre Website hinter einem CDN wie Cloudflare oder AWS CloudFront, hat das CDN eigene Timeout-Einstellungen, die Ihre Serverkonfiguration übersteuern können.

Cloudflare: Bei Free, Pro und Business gibt Cloudflare auf und zeigt Error 524, wenn Ihr Origin nicht innerhalb von 125 Sekunden zu antworten beginnt (Cloudflare). Cloudflares eigener Rat: die Anfrage beschleunigen, lange Jobs in den Hintergrund verlagern oder sie über eine Subdomain mit „Nur DNS“ (graue Wolke) ausliefern; Enterprise-Pläne können das Limit anheben.

CloudFront: Erhöhen Sie das Antwort-Timeout des Ursprungs in den Ursprungseinstellungen der Distribution (AWS). AWS rät, zuerst den langsamen Ursprung zu beheben. Bei GET- und HEAD-Anfragen versucht CloudFront es beim Ursprung erneut (standardmäßig 3 Verbindungsversuche), sodass der Ursprung dieselbe Anfrage mehrmals sehen kann, bevor der Besucher den 504 bekommt.

Welche Schicht den 504 geschickt hat, zeigen die Antwort-Header im HTTP-Header-Checker: server: awselb/2.0 ist ein AWS Load Balancer, x-cache: Error from cloudfront ist CloudFront und server: nginx ist nginx. Hinter Cloudflare steht in jeder Antwort server: cloudflare, dort ist der Code selbst (524 oder 504) der Hinweis.

Fix 7: WordPress-spezifische Lösungen

WordPress-Seiten sind besonders anfällig für 504-Fehler aufgrund schwerer Plugins, Datenbank-Aufblähung und Shared-Hosting-Limits. Hier sind gezielte Lösungen.

• Langsame Plugins identifizieren — Deaktivieren Sie alle Plugins und aktivieren Sie sie nacheinander wieder. Wenn Sie nicht auf wp-admin zugreifen können, benennen Sie den plugins-Ordner per SSH um: mv wp-content/plugins wp-content/plugins_disabled. Verwenden Sie das Query Monitor Plugin, um langsame Datenbankabfragen zu identifizieren.
• Caching-Plugin installieren — WP Super Cache, W3 Total Cache oder WP Rocket reduziert die serverseitige Verarbeitung, indem statisches HTML ausgeliefert wird, anstatt PHP bei jeder Anfrage auszuführen.
• Object Caching verwenden — Installieren Sie Redis oder Memcached und ein WordPress Object Cache Plugin. Dies cached Datenbankabfrageergebnisse im Speicher und reduziert die MySQL-Last.
• Datenbank aufräumen — Löschen Sie alte Post-Revisionen, Transients, Spam-Kommentare und verwaiste Metadaten. Verwenden Sie WP-Optimize oder WP-Sweep. Fügen Sie define('WP_POST_REVISIONS', 5); hinzu, um zukünftige Revisionen zu begrenzen.
• wp-cron auf einen echten Cronjob umstellen — Seitenaufrufe stoßen WP-Cron an, und WP-Cron führt fällige Aufgaben in einer Loopback-Anfrage aus, die einen eigenen PHP-Worker belegt. Fügen Sie define('DISABLE_WP_CRON', true); in wp-config.php ein und lassen Sie den Server alle 5 Minuten wp cron event run --due-now ausführen.

504 vs 502 vs 503 vs 408: Was ist der Unterschied?

Diese HTTP-Fehlercodes werden oft verwechselt. Das bedeutet jeder einzelne tatsächlich.

Der entscheidende Unterschied: 502 heißt, der Proxy hat eine kaputte Antwort bekommen oder die Verbindung wurde abgelehnt oder geschlossen; 504 heißt, der Timer des Proxys ist abgelaufen, während der Upstream stumm blieb. Ein 503 braucht keinen Proxy — jeder Server kann ihn bei Überlastung senden. Ein 408 ist ein clientseitiger Timeout (4xx-Klasse), bei dem der Server nicht länger auf den Client gewartet hat.

Sehen Sie 502 und 504 gemeinsam, kämpft das Backend wahrscheinlich: Anfragen, die in den Timeout laufen, ergeben 504, Worker, die abstürzen oder beendet werden, ergeben 502.

Wenn Sie statt des 504 einen 502 sehen, geht unser Leitfaden zu 502 Bad Gateway die nginx-Fehlerlog-Meldungen durch, die ihn erklären — inklusive eines echten Falls auf dieser Website.

Beeinflusst ein 504-Fehler die SEO?

Googles Dokumentation beschreibt, was 5xx-Fehler bewirken (Google-Dokumentation zu Crawlern):

• Das Crawling wird langsamer — für die gesamte Website, im Verhältnis zur Zahl der URLs, die Serverfehler zurückgeben.
• Indexierte Seiten bleiben zunächst erhalten, aber URLs, die dauerhaft einen Serverfehler liefern, werden schließlich entfernt.
• Das Crawling erholt sich allmählich, sobald der Server wieder mit 2xx antwortet.

Wie Sie 504-Gateway-Timeout-Fehler vermeiden

Vorbeugung ist besser als Brandbekämpfung. Diese Praktiken halten Ihren Server innerhalb der Timeout-Limits.

• Monitoring einrichten — ein Uptime-Monitor, der wichtige Seiten alle paar Minuten lädt, erkennt 504-Fehler, bevor Ihre Nutzer sie melden.
• Timeout-Kette abstimmen — Stellen Sie sicher, dass CDN-Timeout ≥ Proxy-Timeout ≥ Anwendungs-Timeout. Nicht übereinstimmende Werte verursachen unvorhersehbare 504-Fehler.
• Health Checks implementieren — Load Balancer und Proxys sollten Upstream-Server per Health Check prüfen und Traffic von nicht reagierenden Instanzen weglenken.
• Aggressiv cachen — Cachen Sie statische Assets, API-Antworten und Datenbankabfragen. Eine gecachte Antwort ist nie langsam genug, um einen 504 zu verursachen.
• Auto-Skalierung — Verwenden Sie horizontale Skalierung (mehr Instanzen), damit Traffic-Spitzen nicht einen einzelnen Server überwältigen.
• Schwere Arbeit auslagern — Verlagern Sie Dateiverarbeitung, Berichtserstellung, E-Mail-Versand und Massenimporte in Hintergrund-Job-Queues. Führen Sie nie teure Operationen innerhalb eines HTTP-Requests aus.
• Langsame Abfragen überwachen — Aktivieren Sie das Slow Query Logging in MySQL/PostgreSQL. Setzen Sie Alarme für Abfragen, die 1 Sekunde überschreiten.
• Abhängigkeiten gesund halten — Überwachen Sie Drittanbieter-APIs, von denen Ihr Backend abhängt. Fügen Sie Timeouts und Circuit Breaker hinzu, damit eine langsame API nicht kaskadierende 504-Fehler für alle Nutzer verursacht.