504 Gateway Timeout: Bedeutung und Loesung

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 zurueckgesendet hat.

Die offizielle Definition stammt aus RFC 9110 (HTTP Semantics), Abschnitt 15.6.5: "Der Statuscode 504 (Gateway Timeout) zeigt an, dass der Server, waehrend er als Gateway oder Proxy agierte, keine rechtzeitige Antwort von einem Upstream-Server erhalten hat, auf den er zugreifen musste, um die Anfrage abzuschliessen."

Das Schluesselwort 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. Haeufige Proxys sind Nginx Reverse Proxy, Cloudflare, AWS Application Load Balancer (ALB) und CloudFront.

Wie ein 504-Fehler aussieht

Die 504-Fehlermeldung variiert je nach Browser, Webserver und CDN. Hier sind die haeufigsten Meldungen, auf die Sie stossen werden.

• 504 Gateway Timeout

• 504 Gateway Time-out (Nginx-Standard — verwendet einen Bindestrich)

• HTTP Error 504 — Gateway Timeout

• Diese Seite funktioniert nicht — [Domain] hat zu lange fuer die Antwort gebraucht (Chrome / Edge)

• Gateway Timeout (Firefox)

• Error 504

• 504 Gateway Time-out — Der Server hat nicht rechtzeitig geantwortet (Apache mit mod_proxy)

• Error 524: A timeout occurred (Cloudflare-spezifisch — technisch kein 504, aber gleiche Ursache)

• ERROR — The request could not be satisfied — 504 ERROR (AWS CloudFront)

Unabhaengig vom Wortlaut ist die zugrundeliegende Ursache immer dieselbe: Ein Proxy-Server hat auf die Antwort des Upstream-Servers gewartet, und der Upstream-Server hat nicht innerhalb des konfigurierten Timeout-Fensters geantwortet.

Wie ein 504 Gateway Timeout entsteht

Um den 504-Fehler zu verstehen, muessen Sie die Timeout-Kette zwischen Ihrem Browser und dem Origin-Server verstehen. Eine typische Webanfrage durchlaeuft 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 Nginx's proxy_read_timeout auf 60 Sekunden eingestellt ist, hoert Nginx auf zu warten und gibt einen 504 an den Load Balancer zurueck, der ihn an Ihren Browser weiterleitet.

Der Server, der den 504 zurueckgibt, ist immer der Vermittler (Proxy oder Gateway), niemals der Origin-Server selbst. Der Origin-Server hat einfach nicht rechtzeitig geantwortet — er verarbeitet moeglicherweise noch die Anfrage oder ist komplett abgestuerzt.

Haeufige Ursachen fuer 504 Gateway Timeout

Das Verstaendnis der Grundursache ist der schnellste Weg zur Loesung. Hier sind die haeufigsten Gruende, warum ein Server 504 zurueckgibt, sortiert nach Haeufigkeit.

• Langsamer Origin-Server — PHP-Skripte, die komplexe Datenbankabfragen ausfuehren, Berichte generieren oder langsame Drittanbieter-APIs aufrufen, koennen das Timeout des Proxys ueberschreiten. Dies ist die #1-Ursache fuer 504-Fehler.

• Serverueberlastung — CPU bei 100%, Speichermangel (OOM Kills) oder alle PHP-FPM-Worker belegt. Der Origin-Server ist erreichbar, aber zu ueberlastet, um rechtzeitig zu antworten.

• Datenbank-Engpass — Langsame SQL-Abfragen, fehlende Indizes, Tabellensperren oder erschoepfte Verbindungspools. Die Anwendung haengt beim Warten auf die Datenbank, und der Proxy laeuft in den Timeout.

• Falsch konfigurierte Timeout-Werte — Nginx proxy_read_timeout zu niedrig eingestellt fuer ein Backend, das legitimerweise mehr Zeit benoetigt (z.B. ein Berichtsgenerator oder Datei-Upload-Handler).

• Netzwerkprobleme zwischen Proxy und Origin — Paketverlust, hohe Latenz oder Routing-Probleme zwischen Rechenzentren. Haeufig bei Multi-Region- oder Hybrid-Cloud-Setups.

• Firewall oder Security Group blockiert Traffic — AWS Security Groups erlauben keinen Traffic auf ephemeralen Ports, iptables-Regeln blockieren interne Verbindungen oder eine WAF blockiert legitime Upstream-Anfragen.

• DNS-Aufloesung scheitert am Proxy — Der Proxy kann den Upstream-Hostnamen nicht aufloesen. Bei Nginx passiert dies, wenn Variablen in proxy_pass ohne eine resolver-Direktive verwendet werden.

• CDN-Timeout — Cloudflare hat ein festes 100-Sekunden-Limit bei Free/Pro/Business-Plaenen. Wenn Ihr Origin laenger als 100 Sekunden braucht, gibt Cloudflare Error 524 zurueck, unabhaengig von Ihrer Nginx-Konfiguration.

• DDoS-Angriff — Eine Flut von Anfragen erschoepft die Serverressourcen und macht den Origin zu langsam, um legitimen Traffic innerhalb des Proxy-Timeouts zu beantworten.

Loesung fuer Besucher: Was Sie tun koennen

Wenn Sie einen 504-Fehler auf einer fremden Website sehen, liegt das Problem auf deren Server — nicht auf Ihrem Geraet. Es gibt jedoch einige Dinge, die Sie versuchen koennen.

• Warten und aktualisieren — Die meisten 504-Fehler sind voruebergehend. Warten Sie 30-60 Sekunden und fuehren Sie dann eine erzwungene Aktualisierung mit Strg+Umschalt+R (Windows/Linux) oder Cmd+Umschalt+R (Mac) durch.

• Pruefen, ob die Seite fuer alle nicht erreichbar ist — Verwenden Sie das HTTP-Headers-Tool von DNS Robot, um den Antwortcode des Servers von einem externen Standort aus zu pruefen. Wenn er fuer alle 504 zurueckgibt, ist das Problem serverseitig.

• Inkognito oder anderen Browser versuchen — Schliesst Browser-Erweiterungen, gecachte Fehlerseiten und lokale Konfigurationsprobleme aus.

• Anderes Netzwerk versuchen — Wechseln Sie von WLAN zu mobilen Daten oder deaktivieren Sie Ihr VPN. Routing-Probleme zwischen Ihrem ISP und dem Server koennen manchmal 504-Fehler verursachen.

• DNS-Cache leeren — Veraltete DNS-Eintraege koennen Anfragen an den falschen Server leiten. Unter Windows: ipconfig /flushdns. Unter Mac: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder.

• Statusseite oder soziale Medien der Website pruefen — Die Website hat moeglicherweise eine bekannte Stoerung oder ein Wartungsfenster gemeldet.

Fix 1: Timeout-Einstellungen erhoehen (Nginx & Apache)

Die haeufigste Loesung fuer 504-Fehler ist die Erhoehung der Timeout-Werte auf Ihrem Reverse Proxy. Wenn Ihr Backend legitimerweise mehr als 60 Sekunden (der Standard) benoetigt, muss der Proxy wissen, dass er laenger warten soll.

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

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

Fuer Apache mit mod_proxy fuegen Sie ProxyTimeout 300 in Ihren VirtualHost ein oder verwenden Sie ProxyPass / http://backend:8080/ timeout=300 fuer eine Backend-spezifische Konfiguration.

Wichtig: Diese Timeouts messen die Zeit zwischen zwei aufeinanderfolgenden Lese-/Schreibvorgaengen, nicht die gesamte Uebertragungszeit. proxy_read_timeout 300 bedeutet also "wenn 300 Sekunden lang keine Daten ankommen" und nicht "die gesamte Antwort muss innerhalb von 300 Sekunden abgeschlossen sein". Nach dem Aendern der Timeout-Werte laden Sie die Konfiguration neu: sudo nginx -t && sudo systemctl reload nginx.

Fix 2: Langsame Skripte und Datenbankabfragen optimieren

Wenn Ihr Backend konstant das Timeout ueberschreitet, verdeckt eine Erhoehung des Timeout-Werts nur das Problem. Die eigentliche Loesung 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 fuer verdaechtige Abfragen. Fuegen Sie fehlende Indizes hinzu, vermeiden Sie SELECT * und paginieren Sie grosse Ergebnismengen.

• Caching hinzufuegen — 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, fuegen 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 fuehren oft Hunderte einzelner Datenbankaufrufe aus. Verwenden Sie Eager Loading oder Batch-Abfragen, um die Roundtrips zu reduzieren.

Fix 3: Serverressourcen pruefen (CPU, RAM, Festplatte)

Wenn der Origin-Server ueberlastet ist, kann er Anfragen nicht schnell genug verarbeiten, und der Proxy laeuft in den Timeout. Pruefen 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, muessen Sie entweder Ihre Anwendung optimieren, unkontrollierte Prozesse beenden oder Ihren Server aufruesteten. Wenn der Festplattenspeicher voll ist, loeschen Sie alte Logdateien, Backups oder temporaere Dateien — eine volle Festplatte kann Datenbanken lautlos zum Absturz bringen und kaskadenartige 504-Fehler verursachen.

Fix 4: Fehlerprotokolle pruefen

Fehlerprotokolle sagen Ihnen genau, warum der Proxy 504 zurueckgegeben hat. Pruefen 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.2-fpm.log

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

Haeufige Log-Meldungen, die 504 verursachen:

"upstream timed out (110: Connection timed out)" (Nginx) — Der Upstream-Server hat nicht innerhalb von proxy_read_timeout geantwortet. Erhoehen Sie entweder das Timeout oder beheben Sie den langsamen Upstream.

"server reached pm.max_children" (PHP-FPM) — Alle PHP-Worker-Prozesse sind belegt. Erhoehen Sie pm.max_children in der PHP-FPM-Pool-Konfiguration.

"connect() failed (111: Connection refused)" (Nginx) — Der Upstream-Server laeuft nicht oder hoert nicht auf dem erwarteten Port. Starten Sie das Backend neu.

"Too many connections" (MySQL) — Das Datenbank-Verbindungslimit ist erschoepft. Erhoehen Sie max_connections in der MySQL-Konfiguration oder optimieren Sie das Connection Pooling.

Fix 5: PHP-FPM-Einstellungen anpassen

Nach dem Aendern der PHP-FPM-Einstellungen starten Sie den Dienst neu: sudo systemctl restart php8.2-fpm. Stellen Sie sicher, dass Nginx's fastcgi_read_timeout immer groesser oder gleich PHP's max_execution_time ist. Andernfalls gibt Nginx auf, bevor PHP fertig ist, was einen 504 verursacht.

Fix 6: CDN- und Proxy-Konfiguration pruefen

Cloudflare-Nutzer: Wenn Sie einen Free-, Pro- oder Business-Plan haben und Ihr Origin laenger als 100 Sekunden braucht, erhalten Sie immer Error 524. Die einzigen Optionen sind: Backend optimieren, damit es innerhalb von 100 Sekunden antwortet, langwierige Aufgaben in Hintergrundjobs verlagern oder auf Enterprise upgraden.

AWS CloudFront-Nutzer: Erhoehen Sie das Origin-Response-Timeout in den Origin-Einstellungen Ihrer Distribution. Der Standard von 30 Sekunden ist fuer dynamischen Content oft zu niedrig.

Verwenden Sie das HTTP-Headers-Tool von DNS Robot, um die Antwort-Header zu pruefen und zu identifizieren, welche Schicht den 504 zurueckgibt. Achten Sie auf Header wie server: cloudflare, server: awselb/2.0 oder server: nginx, um den Proxy zu lokalisieren.

Fix 7: WordPress-spezifische Loesungen

WordPress-Seiten sind besonders anfaellig fuer 504-Fehler aufgrund schwerer Plugins, Datenbank-Aufblaehung und Shared-Hosting-Limits. Hier sind gezielte Loesungen.

• Langsame Plugins identifizieren — Deaktivieren Sie alle Plugins und aktivieren Sie sie nacheinander wieder. Wenn Sie nicht auf wp-admin zugreifen koennen, 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.

• PHP-Speicher erhoehen — Fuegen Sie define('WP_MEMORY_LIMIT', '512M'); in wp-config.php hinzu. Viele Plugins benoetigen mehr als die Standard-128MB.

• 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 auszufuehren.

• 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 aufraeumen — Loeschen Sie alte Post-Revisionen, Transients, Spam-Kommentare und verwaiste Metadaten. Verwenden Sie WP-Optimize oder WP-Sweep. Fuegen Sie define('WP_POST_REVISIONS', 5); hinzu, um zukuenftige Revisionen zu begrenzen.

• wp-cron deaktivieren — WordPress' virtueller Cron laeuft bei jedem Seitenaufruf und kann Aufgaben aufstauen. Fuegen Sie define('DISABLE_WP_CRON', true); zu wp-config.php hinzu und richten Sie stattdessen einen echten Server-Cronjob ein: */5 * * * * curl -s https://yoursite.com/wp-cron.php > /dev/null 2>&1.

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

Der entscheidende Unterschied: 502 bedeutet, der Proxy hat eine fehlerhafte Antwort erhalten, waehrend 504 bedeutet, der Proxy hat ueberhaupt keine Antwort erhalten. Ein 503 erfordert keinen Proxy — jeder Server kann ihn bei Ueberlastung zurueckgeben. Ein 408 ist ein clientseitiger Timeout (4xx-Klasse), bei dem der Server aufgehoert hat, auf den Client zu warten.

Wenn Sie gleichzeitig einen 502 und einen 504 sehen, stuerzt der Upstream-Server wahrscheinlich ab. Der 502 tritt auf, wenn der Proxy eine unvollstaendige oder fehlerhafte Antwort von einem sterbenden Prozess erhaelt, und der 504 tritt auf, wenn der Prozess komplett nicht mehr reagiert.

Beeinflusst ein 504-Fehler die SEO?

Kurze Antwort: Ein kurzer 504 hat keine SEO-Auswirkung. Ein langanhaltender 504 kann zur Deindexierung fuehren.

Minuten bis Stunden: Keine Auswirkung. Google versteht voruebergehende Serverfehler und bestraft nicht sofort. Wenn Googlebot waehrend des Ausfalls nicht crawlt, bemerkt es ihn nicht einmal.

Stunden bis Tage: Google reduziert die Crawl-Frequenz fuer Websites, die 5xx-Fehler zurueckgeben, um einen kaempfenden Server nicht zusaetzlich zu belasten. Seiten koennen als "Serverfehler (5xx)" im Seitenindexierungsbericht der Google Search Console erscheinen.

Tage bis Wochen: Anhaltende 504-Fehler koennen zur Deindexierung betroffener Seiten fuehren. Rankings fallen deutlich. Laut Googles John Mueller kann es nach der Wiederherstellung ein bis drei Wochen "im Fluss" sein.

Wiederherstellung: Sobald der Server wieder zuverlaessig ist, crawlt und indexiert Google die Seiten automatisch erneut. Verwenden Sie das URL-Inspectionstool der Google Search Console, um die Neuindexierung wichtiger Seiten anzufordern. Die Wiederherstellungszeit haengt von der Groesse der Website und der Dauer der Fehler ab.

Wie man 504 Gateway Timeout Fehler vermeidet

Vorbeugung ist besser als Brandbekaempfung. Diese Praktiken halten Ihren Server innerhalb der Timeout-Limits.

• Monitoring einrichten — Verwenden Sie Uptime-Monitoring (UptimeRobot, Pingdom oder das Ping-Tool von DNS Robot), um 504-Fehler zu erkennen, bevor Ihre Nutzer sie melden.

• Timeout-Kette abstimmen — Stellen Sie sicher, dass CDN-Timeout >= Proxy-Timeout >= Anwendungs-Timeout. Nicht uebereinstimmende Werte verursachen unvorhersehbare 504-Fehler.

• Health Checks implementieren — Load Balancer und Proxys sollten Upstream-Server per Health Check pruefen 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 ueberwaeltigen.

• Schwere Arbeit auslagern — Verlagern Sie Dateiverarbeitung, Berichtserstellung, E-Mail-Versand und Massenimporte in Hintergrund-Job-Queues. Fuehren Sie nie teure Operationen innerhalb eines HTTP-Requests aus.

• Langsame Abfragen ueberwachen — Aktivieren Sie das Slow Query Logging in MySQL/PostgreSQL. Setzen Sie Alarme fuer Abfragen, die 1 Sekunde ueberschreiten.

• Abhaengigkeiten gesund halten — Ueberwachen Sie Drittanbieter-APIs, von denen Ihr Backend abhaengt. Fuegen Sie Timeouts und Circuit Breaker hinzu, damit eine langsame API nicht kaskadierende 504-Fehler fuer alle Nutzer verursacht.