HTTPQUERY
Deutsch

504 Gateway Timeout

Verwendung

Der Statuscode 504 Gateway Timeout bedeutet, dass der Server als Proxy oder Gateway für einen Upstream-Server fungiert. Nach dem Empfang der HTTP-Anfrage hat der Server versucht, die Anfrage an den Upstream-Server weiterzuleiten, erhielt jedoch innerhalb der zulässigen Zeit keine Antwort.

Dies hängt mit dem Statuscode 502 Bad Gateway zusammen. Ein 502 zeigt an, dass der Upstream-Server eine ungültige Antwort zurückgegeben hat, während ein 504 anzeigt, dass überhaupt keine Antwort empfangen wurde.

Plattformspezifische Timeouts fallen unterschiedlich aus. Die Shopify-API erzwingt ein Anfrage-Timeout von 10 Sekunden und gibt 504 Gateway Timeout zurück, wenn innerhalb dieses Zeitfensters keine Antwort bereitsteht. Entwickler, die mit der Shopify-API arbeiten, müssen Abfragen optimieren und für Vorgänge, die dieses Limit überschreiten, Hintergrundverarbeitung einsetzen.

SEO-Auswirkung

Googlebot wertet 5xx-Fehler als Signal, die Crawl-Rate für die gesamte Site vorübergehend zu senken. Zuvor indexierte URLs bleiben zunächst erhalten, doch bei längerer Ausfallzeit entfernt Google sie aus dem Index. Jeglicher Inhalt, der mit einer 504-Antwort ausgeliefert wird, wird ignoriert. Google fasst 500, 502 und 503 in seiner Dokumentation ausdrücklich als Serverfehler zusammen. Ein 504 fällt unter denselben allgemeinen 5xx-Fehler. Ein 5xx-Fehler bei der robots.txt-Datei ist weitaus gravierender, selbst wenn jede andere Seite der Site 200 zurückgibt. Google stoppt das Crawling für bis zu 12 Stunden und greift anschließend für bis zu 30 Tage auf eine zwischengespeicherte Kopie zurück. Besteht der Fehler fort, deindexiert Google die Site vollständig. Auch Bingbot behandelt 5xx-Antworten als Crawl-Fehler. Anhaltende 5xx-Fehler verhindern die Indexierung in Bing.

Beispiel

Der Client fordert eine Ressource an, und der Server antwortet mit dem Statuscode 504 Gateway Timeout, weil der Upstream-Server keine HTTP-Antwort zurückgegeben hat.

Anfrage

GET /news HTTP/1.1
Host: example.com

Antwort

HTTP/1.1 504 Gateway Timeout
Content-Type: text/html; charset=UTF-8
Content-Length: 128

<html>
  <head>
    <title>Gateway Timeout</title>
  </head>
  <body>
    <p>The server is not responding.</p>
  </body>
</html>

Behebung

Beim Proxy ist das Warten auf die Antwort des Backends abgelaufen. Die Lösung besteht entweder darin, das Timeout zu erhöhen oder das Backend schneller zu machen.

Erhöhen Sie die Proxy-Timeouts.

In nginx beträgt das Standard-Timeout 60 Sekunden. Erhöhen Sie die entsprechenden Direktiven im server- oder location-Block:

Setzen Sie in Apache ProxyTimeout 300 im Virtual Host oder in der globalen Konfiguration. Bei Verwendung von mod_proxy_fcgi steuert der timeout-Parameter der ProxyPassMatch-Direktive die Wartezeit.

Gleichen Sie die Backend-Timeouts ab. Der Backend-Prozess benötigt ein gleich hohes oder höheres Timeout. Erhöhen Sie für PHP max_execution_time in der php.ini und request_terminate_timeout in der PHP-FPM-Pool-Konfiguration. Setzen Sie für Node.js server.timeout. Verwenden Sie für Gunicorn —timeout.

Optimieren Sie den langsamen Backend-Vorgang. Ein Timeout ist das Symptom eines langsamen Vorgangs. Profilieren Sie die Anfrage, um den Engpass zu finden:

Beachten Sie plattformseitig vorgegebene Timeouts. Gehostete Plattformen erzwingen harte Limits, die kürzer sind als typische Proxy-Standardwerte. Shopify setzt eine Obergrenze von 10 Sekunden. Lagern Sie Vorgänge, die das Plattformlimit überschreiten, in Hintergrund-Jobs aus und fragen Sie die Ergebnisse per Polling ab, statt die HTTP-Anfrage zu blockieren.

Prüfen Sie den Netzwerkpfad. Überprüfen Sie die Verbindung zwischen Proxy und Backend mit curl oder telnet. Paketverluste, DNS-Verzögerungen oder Firewall-Regeln auf zwischengeschalteten Hops tragen allesamt zu Timeouts bei. Führen Sie traceroute aus, um langsame Netzwerkabschnitte zu identifizieren.

Fügen Sie Caching hinzu. Bei idempotenten Anfragen vermeidet das Caching der Antwort auf der Proxy-Ebene wiederholte langsame Backend-Aufrufe. Sowohl Nginx proxy_cache_path als auch Apache mod_cache verringern die Last auf dem Upstream.

Code-Referenzen

.NET

HttpStatusCode.GatewayTimeout

Rust

http::StatusCode::GATEWAY_TIMEOUT

Rails

:gateway_timeout

Go

http.StatusGatewayTimeout

Symfony

Response::HTTP_GATEWAY_TIMEOUT

Python3.5+

http.HTTPStatus.GATEWAY_TIMEOUT

Java

java.net.HttpURLConnection.HTTP_GATEWAY_TIMEOUT

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_GATEWAY_TIMEOUT

Angular

@angular/common/http/HttpStatusCode.GatewayTimeout