502-, 503- und 504-Fehler: Was jeder einzelne tatsächlich bedeutet

502, 503 und 504 bedeuten alle ungefähr „Der Server konnte Ihnen im Moment keine echte Antwort geben“, weshalb sie so oft miteinander verwechselt werden. Aber jeder Code grenzt das Problem anders ein, und das korrekte Lesen der Zahl spart Zeit bei der Fehlersuche auf der falschen Ebene.

Die schnelle Unterscheidung

• 502 Bad Gateway – ein Server, der als Gateway oder Proxy fungiert, hat eine ungültige Antwort vom Server dahinter erhalten.
• 503 Dienst nicht verfügbar – der Server ist aktiv, weigert sich jedoch derzeit absichtlich, die Anfrage zu bearbeiten (überlastet oder in Wartung).
• 504 Gateway Timeout – ein Server, der als Gateway oder Proxy fungiert, hat innerhalb seines Zeitlimits keine Antwort vom Server dahinter erhalten.

Das Muster: 502 und 504 umfassen beide zwei Server – einen Proxy/Load Balancer/CDN vorne und einen Anwendungsserver dahinter. 503 ist normalerweise nur ein Server, der Ihnen direkt mitteilt, dass er nicht bereit ist.

502 Schlechtes Gateway

Was passiert: Ein Reverse-Proxy, Load-Balancer oder CDN (wie Cloudflare oder Nginx, das als Gateway fungiert) hat Ihre Anfrage an den eigentlichen Anwendungsserver weitergeleitet und eine Antwort erhalten, die er nicht verstehen konnte oder die fehlerhaft war – keine Stille, sondern eine tatsächlich fehlerhafte Antwort.

Häufige Ursachen: – Der Anwendungsserver (Knoten, PHP-FPM, ein Backend-Prozess) ist während der Anfrage abgestürzt oder wurde neu gestartet. – Ein falsch konfigurierter Reverse-Proxy, der auf den falschen Port oder die falsche Adresse zeigt. – Das Backend hat eine Antwort zurückgegeben, die gegen die grundlegende HTTP-Formatierung verstößt. – Ein CDN oder WAF vor der Site ist falsch konfiguriert und lehnt eine legitime Backend-Antwort ab.

Was Sie überprüfen sollten, wenn es sich um Ihre Website handelt: Überprüfen Sie die Protokolle Ihres Anwendungsservers auf Abstürze oder Neustarts zum Fehlerzeitpunkt. Bestätigen Sie, dass Ihre Reverse-Proxy-Konfiguration (nginx proxy_pass, Load-Balancer-Ziel usw.) auf ein Backend verweist, das tatsächlich auf dem erwarteten Port ausgeführt wird.

503 Dienst nicht verfügbar

Was passiert: Der Server hat Ihre Anfrage einwandfrei erhalten, teilt Ihnen jedoch ausdrücklich mit, dass er sie derzeit nicht verarbeiten kann. Im Gegensatz zu 502/504 ist dies normalerweise beabsichtigt – ein Server gibt seinen eigenen Zustand an und nicht ein Proxy, der sich darüber beschwert, was dahinter steckt.

Häufige Ursachen:

• Geplante Wartung – viele Plattformen geben bei der Bereitstellung oder Aktualisierung absichtlich 503 zurück, oft mit einem Retry-After-Header.
• Überlastung – zu viele gleichzeitige Anfragen für die Kapazität des Servers, häufig bei Verkehrsspitzen (Verkauf, viraler Post, DDoS).
• Ressourcenerschöpfung – Der Server hatte nicht mehr genügend Arbeitsspeicher, Datenbankverbindungen oder Arbeitsprozesse, um neue Anfragen zu verarbeiten.
• Ratenbegrenzung – einige Setups geben 503 statt 429 zurück, wenn ein Client (oder ein Upstream-Dienst) Anfragen zu schnell sendet.

Was Sie überprüfen sollten, wenn es sich um Ihre Website handelt: Wenn dies während einer Bereitstellung auftritt, kann es sich innerhalb von Sekunden bis Minuten von selbst auflösen. Wenn das Problem weiterhin besteht, überprüfen Sie die Ressourcennutzung des Servers (CPU, Arbeitsspeicher, Verbindungspoollimits) und überprüfen Sie die Protokolle Ihres Prozessmanagers auf Worker, die nicht gestartet werden können oder getötet werden.

504 Gateway-Timeout

Was passiert: Gleiches Zwei-Server-Setup wie 502, aber anstatt eine fehlerhafte Antwort vom Backend zu erhalten, hat der Proxy innerhalb der zugewiesenen Wartezeit überhaupt nichts erhalten. Es ist der „Gateway“-Geschwister eines einfachen Verbindungszeitlimits.

Häufige Ursachen: – Das Backend braucht zu lange, um die Anfrage zu verarbeiten – eine langsame Datenbankabfrage, ein nicht optimiertes Skript oder eine Abhängigkeit (API, Drittanbieterdienst), die selbst langsam oder ausgefallen ist. – Das Backend ist überlastet und zu beschäftigt, um rechtzeitig zu reagieren, obwohl es nicht abgestürzt ist. – Eine Proxy-Timeout-Einstellung, die für einen recht langsamen (aber funktionierenden) Vorgang, wie das Hochladen einer großen Datei oder die Generierung umfangreicher Berichte, zu aggressiv ist.

Was Sie überprüfen sollten, wenn es sich um Ihre Website handelt: Erstellen Sie direkt ein Profil für den langsamen Endpunkt und umgehen Sie dabei den Proxy, um zu sehen, ob das Backend selbst langsam ist oder ob das Problem lediglich in der Proxy-Ebene liegt. Überprüfen Sie, ob eine bestimmte Abhängigkeit (Datenbank, externe API) beeinträchtigt ist, da dies die häufigste Ursache dafür ist, dass ein Backend langsamer wird und nicht direkt abstürzt.

Bist du es oder sind sie es?

Alle drei davon sind per Definition serverseitige Fehler – sie werden nicht durch Ihren Browser, Ihr DNS oder Ihr lokales Netzwerk verursacht, was sie klar von Problemen wie ERR_CONNECTION_TIMED_OUT oder DNS_PROBE_FINISHED_NXDOMAIN] unterscheidet. Wenn Sie einen 502-, 503- oder 504-Fehler sehen, liegt die Lösung (sofern Sie einen beheben können) fast nie bei Ihnen – bei einem vorübergehenden 503-Fehler funktioniert die Aktualisierung gelegentlich, bei einem dauerhaften Problem müssen Sie jedoch nur darauf warten, dass die Website das Problem löst.

Um zu bestätigen, dass es nicht nur an Ihnen liegt – einige CDN- oder regionale Edge-Knoten geben gelegentlich einen fehlerhaften Gateway-Fehler aus, während andere in Ordnung sind – führen Sie die Site durch eine unabhängige Statusprüfung, um den Live-HTTP-Statuscode von einem Server außerhalb Ihres eigenen Netzwerks zusammen mit der Antwortzeit und dem SSL-Status in derselben Ansicht anzuzeigen.