Was ist Fehler 504 (Gateway Timeout)?

Der 504 erschien zuerst in RFC 2068, der Spezifikation von HTTP/1.1 vom Januar 1997. RFC 1945 für HTTP/1.0 vom Mai 1996 kannte den 502 schon, den 504 noch nicht. Heute definiert ihn RFC 9110 vom Juni 2022 in Abschnitt 15.6.5: Das Gateway „did not receive a timely response“ von dem Server, den es brauchte.

Die Kette der Gateways erklärt der Eintrag zum Fehler 502. Der Wortlaut hängt von der Software ab (nginx betitelt seine Seite „504 Gateway Time-out“), der Code bleibt derselbe.

Jede Schicht, die eine Anfrage weiterreicht, legt fest, wie lange sie auf die nächste wartet. Braucht die Anwendung länger, bricht diese Schicht ab und antwortet mit 504. Cloudflare nennt als Ursachen eine große Datenabfrage, einen lang laufenden Prozess oder einen Server ohne freie Ressourcen.

Standardwerte laut den Herstellern (abgerufen am 13.11.2026):

• nginx: 60 Sekunden für proxy_read_timeout und fastcgi_read_timeout, gezählt zwischen zwei Lesevorgängen.
• Apache httpd: ProxyTimeout übernimmt den Wert von TimeOut, 60 Sekunden.
• AWS Application Load Balancer: 60 Sekunden Leerlauf (idle timeout) und 10 Sekunden für den Verbindungsaufbau.
• Amazon CloudFront: 30 Sekunden Wartezeit auf die Antwort des Ursprungs; bei GET- und HEAD-Anfragen versucht es CloudFront bis zu dreimal.
• Cloudflare: 125 Sekunden, im Enterprise-Tarif bis 6.000.
• PHP: 30 Sekunden für max_execution_time, außerhalb von Windows standardmäßig als CPU-Zeit gemessen; das Warten auf die Datenbank zählt nicht mit.

Das kürzeste Limit gewinnt. Mit nginx bei 60 Sekunden und CloudFront bei 30 bricht CloudFront zuerst ab. Bei einer POST-Anfrage sieht der Besucher dessen 504 nach 30 Sekunden; bei GET und HEAD wiederholt CloudFront den Versuch bis zu dreimal, und der 504 kommt nach rund 90 Sekunden. Das Limit an einer Schicht zu erhöhen, bringt nichts, wenn davor eine Schicht früher abbricht.

Cloudflare antwortet anders: Sind seine 125 Sekunden um, schickt es einen 524, einen eigenen Code, den RFC 9110 nicht definiert.

Eine einzige Schicht kann den 504 aus verschiedenen Gründen liefern. Für seinen Load Balancer nennt AWS diese: Die Verbindung zum Ziel kommt nicht innerhalb von 10 Sekunden zustande, das Ziel antwortet nicht vor Ablauf des Leerlauf-Limits, eine Lambda-Funktion antwortet nicht, oder das Ziel kündigt mehr Bytes an, als es sendet.

CloudFront liefert den 504 auch, wenn eine Firewall seinen Verkehr zum Ursprung blockiert oder der Ursprung aus dem Internet nicht erreichbar ist. Dann ist keine Anwendung langsam: Die Anfrage kommt gar nicht an.

Bei Cloudflare stammt ein 504 mit Logo vom Ursprungsserver; eine leere Seite ohne Logo hat Cloudflare selbst erzeugt.

Rechenbeispiel: Ein Onlineshop mit Cloudflare davor und nginx mit PHP-FPM dahinter exportiert die Bestellungen des Jahres, und die Abfrage läuft 90 Sekunden, ohne etwas zu senden. Nach 60 Sekunden gibt nginx einen 504 zurück, der mit Cloudflare-Logo erscheint, weil er vom Ursprung kommt.

Der Administrator setzt fastcgi_read_timeout auf 180 Sekunden, und der Export läuft durch. Wächst die Datei und braucht die Abfrage mehr als 125 Sekunden, kommt der Fehler als 524 zurück, weil jetzt das Limit von Cloudflare greift. Für solche Prozesse schlägt Cloudflare eine Subdomain ohne Proxy vor.

Die Dauer verrät die Schicht. curl mit der Option -w und den Variablen %{http_code} und %{time_total} zeigt Code und Sekunden. Bei Standardwerten deutet ein 504 nach 30 Sekunden bei einer POST-Anfrage, oder nach rund 90 bei GET und HEAD wegen der drei Versuche, auf CloudFront, einer nach 60 auf nginx oder einen AWS Load Balancer und ein 524 um 125 Sekunden auf Cloudflare. AWS empfiehlt zusätzlich, auf jedem Server die Zeit bis zum ersten Byte zu messen, die TTFB.

Das Log bestätigt es: Läuft das Limit ab, schreibt nginx laut Quellcode „upstream timed out“.

In der Search Console trennt die Crawling-Statistik „Serverfehler (5XX)“, wohin der 504 gehört, von „Zeitüberschreitung der Seite“, also Anfragen, bei denen die Zeit für den Seitenabruf überschritten wurde.

Ein langes Limit lässt langsame Prozesse fertig werden, ein kurzes zeigt den Fehler früher. AWS empfiehlt, das Leerlauf-Limit der Anwendung höher zu setzen als das des Load Balancers: Schließt die Anwendung die Verbindung zuerst, kann der Load Balancer einen 502 zurückgeben.

Für SEO folgt der 504 der allgemeinen 5xx-Regel: Googles Doku zu Statuscodes (4. Februar 2026) beschreibt 500, 502 und 503 einzeln, den 504 nicht. Die Crawler werden langsamer, ignorieren den Inhalt und behalten indexierte URLs, „but eventually dropped“, ohne Frist. Was bei einem Serverfehler über Tage passiert, steht im Eintrag zum Fehler 503.

Ein anderer Fall ist ein Server, der Googlebot gar nicht antwortet. Google behandelt „network timeouts“, zurückgesetzte Verbindungen und DNS-Fehler ähnlich wie 5xx, doch ohne Antwort gibt es keinen Statuscode. Laut Googles Seite zu Netzwerkfehlern wird das Crawling sofort langsamer, und indexierte URLs, die nicht erreichbar sind, fallen „within days“ aus dem Index.

Quelle: RFC 9110 (Juni 2022); Cloudflare, „Error 524“ (abgerufen am 13.11.2026).

Der 500 ist der allgemeine Serverfehler, der 503 meldet Überlastung oder Wartung.

RFC 9110 verlangt eine „timely“ Antwort, nennt aber keine Sekundenzahl. Bei Standardwerten löst eine Antwort nach 45 Sekunden hinter CloudFront einen 504 aus und kommt hinter Cloudflare normal an.

Cloudflare fasst 502 und 504 weiter als die RFC, nämlich als „unable to establish contact“ mit dem Ursprungsserver.

• Miss mit curl, nach wie vielen Sekunden der 504 kommt, und vergleiche das mit den Limits jeder Schicht.
• Such im Proxy-Log die Zeile aus derselben Minute und im Log der Anwendung die langsame Anfrage.
• Nimm lange Aufgaben aus der Webanfrage heraus, in eine Warteschlange oder einen Cronjob, und frag ihren Status per Polling ab.
• Muss ein langer Vorgang auf derselben Verbindung bleiben, schick mindestens ein Byte, bevor das Leerlauf-Limit abläuft, wie AWS empfiehlt.
• Pass die Limits erst danach an, von der Anwendung nach außen, damit keine äußere Schicht früher abbricht.
• Prüf nach dem Fix in der Search Console den Hoststatus.
• Wenn du die Seite nur besuchst: Lade sie später neu; funktioniert sie bei anderen, prüf VPN, Proxy oder DNS, wie MDN rät.

• Protokolliere am Ursprung die Antwortzeit jeder Anfrage, wie Cloudflare empfiehlt.
• Halte das tatsächliche Limit jeder Schicht in einem Dokument fest, vom CDN bis PHP.

• Das nginx-Limit erhöhen, während davor ein CloudFront nach 30 Sekunden abbricht.
• Einen 504 suchen, obwohl Cloudflare einen 524 zeigt.
• Annehmen, dass max_execution_time von PHP nach 30 Sekunden Echtzeit abbricht.
• Annehmen, dass Google eine feste Zahl von Tagen abwartet, bevor URLs mit 504 aus dem Index fallen.

Dieser Eintrag entstand im November 2026 mit Unterstützung von KI, auf Grundlage der RFCs, der Doku von Google und der Search Console sowie der Doku von MDN, nginx, Apache, AWS, Cloudflare und PHP. Die Zeitlimits wurden am 13.11.2026 geprüft. Er enthält keine Kundendaten.