HTTP-5xx-Serverfehler: Bedeutung, Diagnose und Lösungen

Was dieser Fehler bedeutet und wie du ihn erkennst

Eines oder mehrere der folgenden Symptome können auftreten:

• Eine Website oder API gibt einen HTTP-Statuscode von 500 bis 599 zurück.
• Die Antwort ist ein allgemeiner Serverfehler, ein Anwendungsfehler oder eine gebrandete Seite eines Reverse-Proxys, Load Balancers oder CDNs.
• Nur eine Route, Operation oder ein API-Endpunkt schlägt fehl, während andere Seiten weiterhin funktionieren.
• Der gesamte Dienst wird nicht verfügbar oder gibt nur zeitweise Fehler zurück.
• Anfragen werden langsam, bevor sie mit einem 504 oder einer anderen Gateway-bezogenen 5xx-Antwort enden.
• Die Antwort enthält eine Request-ID, eine Upstream-Kennung oder einen serverspezifischen Fehler-Header, die beim Identifizieren der erzeugenden Ebene helfen können.

Hauptursachen nach Wahrscheinlichkeit

Mögliche Ursachen, von häufigen bis zu selteneren, sind unter anderem:

1. Anwendungsfehler oder fehlgeschlagene Anfrageverarbeitung. Nicht behandelte Anwendungsfehler, ungültige Eingabepfade oder eine fehlerhafte Codeänderung können eine 500-Antwort erzeugen.
2. Kürzlich vorgenommene Deployments oder Konfigurationsänderungen. Ein Release, eine Änderung von Umgebungsvariablen, eine Routing-Änderung oder ein Fehler in der Serverkonfiguration kann eine einzelne Route oder den gesamten Dienst beeinträchtigen.
3. Nicht verfügbare Backend-Prozesse. Ein gestoppter, abstürzender, überlasteter oder nicht erreichbarer Anwendungsprozess kann dazu führen, dass ein Proxy 502 oder 503 zurückgibt.
4. Fehler bei Abhängigkeiten. Datenbankfehler, nicht verfügbare interne Dienste, langsame externe Dienste oder erschöpfte Connection Pools können sich als verschiedene 5xx-Codes bemerkbar machen.
5. Timeouts zwischen Ebenen. Ein Gateway kann 504 zurückgeben, wenn ein Upstream-Dienst nicht innerhalb des konfigurierten Timeouts antwortet; langsame Abhängigkeiten können die eigentliche Ursache sein.
6. Ressourcenknappheit. Hohe CPU- oder Speicherauslastung, erschöpfte Worker-Kapazitäten, voller Speicherplatz oder Verbindungslimits können einen Dienst nicht verfügbar machen oder zu Timeouts führen.
7. Wartungsarbeiten oder beabsichtigter Schutz. Ein Dienst kann während Wartungsarbeiten, beim kontrollierten Abbau von Traffic, bei Rate-Limiting oder zum Schutz vor Überlastung 503 zurückgeben.
8. Ebenenspezifisches Statusverhalten. Derselbe zugrunde liegende Vorfall kann unterschiedliche Codes erzeugen, je nachdem, ob die Anwendung, der Webserver, der Reverse Proxy, der Load Balancer oder das CDN die Antwort generiert hat.

So behebst du den Fehler

1. Fehler präzise erfassen

Notieren Sie den genauen Statuscode, die betroffene URL oder API-Operation, den Zeitpunkt einschließlich Zeitzone, die Häufigkeit, den Response-Body und relevante Response-Header. Bewahren Sie jede Request-ID oder Trace-ID auf. Wenn Sie die Website lediglich besuchen, übermitteln Sie diese Angaben dem Betreiber des Dienstes, statt Servereinstellungen zu ändern.

2. Die Ebene identifizieren, die die Antwort erzeugt

Vergleichen Sie die Fehlerseite oder den JSON-Body, Header, Cookies und Serverkennungen mit einer bekannten erfolgreichen Antwort. Ein frameworkspezifischer Fehler-Body kann auf die Anwendung hindeuten; eine Seite mit dem Branding eines Gateways oder CDNs kann bedeuten, dass die Anfrage fehlschlug, bevor der Origin eine Antwort erzeugt hat. Prüfen Sie die Logs des Reverse-Proxys, Load Balancers oder CDNs, wenn die Origin-Logs keine passende Anfrage enthalten.

3. Einen umfassenden Ausfall von einem routenspezifischen Fehler unterscheiden

Testen Sie einen freigegebenen Health-Endpunkt mit geringer Auswirkung und eine bekanntermaßen nicht betroffene Route. Wenn nur eine Route fehlschlägt, prüfen Sie deren Anwendungscode, Datenzugriffe und anfragespezifische Abhängigkeiten. Wenn jede Route fehlschlägt, priorisieren Sie Prozessstatus, Deployment-Status, Routing, Kapazität und gemeinsame Abhängigkeiten. Aktualisieren Sie einen Produktionsendpunkt nicht wiederholt als Ersatz für einen Health Check.

4. Logs anhand desselben Zeitstempels korrelieren

Prüfen Sie Anwendungs-, Webserver-, Proxy-/Load-Balancer- und Dependency-Logs gemeinsam. Suchen Sie zuerst nach der Request-ID und schränken Sie die Suche anschließend anhand von Zeitstempel und Endpunkt ein. Achten Sie auf Stacktraces, Prozessneustarts, Meldungen über verweigerte Verbindungen, Upstream-Statuscodes, Timeout-Meldungen, fehlgeschlagene Datenbankaufrufe und abgewiesene Verbindungen. Entfernen oder anonymisieren Sie Zugangsdaten, Tokens und sensible Anfrageinformationen, bevor Sie Logs weitergeben.

5. Kürzliche Änderungen und den Zustand des Dienstes prüfen

Überprüfen Sie Deployments, Feature Flags, Konfigurationsänderungen, Zertifikats- oder Routing-Aktualisierungen, Wartungsarbeiten und Änderungen an Abhängigkeiten, die kurz vor Beginn der Fehler vorgenommen wurden. Stellen Sie sicher, dass Backend-Prozesse laufen und ihre Health Checks bestehen. Wenn eine kürzliche Änderung stark mit dem Vorfall korreliert, verwenden Sie das freigegebene Rollback-Verfahren des Dienstes und die erforderliche Autorisierung. Starten Sie Produktionssysteme nicht ohne betriebliche Freigabe neu und führen Sie kein Rollback durch.

6. Abhängigkeiten und Ressourcenknappheit prüfen

Prüfen Sie Erreichbarkeit und Latenz der Datenbank, den Zustand interner Dienste, Antworten externer Abhängigkeiten, die Nutzung des Connection Pools, die Warteschlangentiefe, CPU, Arbeitsspeicher, Speicherplatz, verfügbare Worker und Verbindungslimits. Eine lediglich langsame Abhängigkeit kann einen 504 verursachen, selbst wenn der Anwendungsprozess läuft. Beheben Sie die blockierte oder fehlerhafte Komponente, statt das Symptom durch blindes Erhöhen von Timeouts zu kaschieren.

7. Die Untersuchung anhand des Statuscodes fokussieren

• 500 Internal Server Error: Beginnen Sie mit Anwendungslogs, Serverfehlern, der fehlschlagenden Route und kürzlichen Code- oder Konfigurationsänderungen.
• 502 Bad Gateway: Prüfen Sie die Verbindung vom Proxy zum Upstream und die Upstream-Antwort. Stellen Sie fest, ob das Backend ausgefallen ist, Verbindungen schließt, fehlerhafte Daten zurückgibt oder über eine falsche Route erreicht wird.
• 503 Service Unavailable: Prüfen Sie Wartungsstatus, Readiness- oder Health Checks, Überlastungsschutz, Prozessverfügbarkeit und gemeinsame Abhängigkeiten.
• 504 Gateway Timeout: Ermitteln Sie, wo Zeit verbraucht wird. Prüfen Sie Upstream-Latenz, Datenbank- oder externe Aufrufe, Connection Pools und Timeout-Einstellungen auf jeder Ebene.
• Andere 5xx-Statuscodes: Verwenden Sie die genaue Statusdefinition und die Komponente, die ihn ausgegeben hat. Gehen Sie nicht davon aus, dass jede 5xx-Antwort dieselbe Ursache hat.

8. Die kleinstmögliche autorisierte Lösung anwenden und sicher verifizieren

Beheben Sie das identifizierte Anwendungs-, Konfigurations-, Abhängigkeits- oder Kapazitätsproblem gemäß dem Change-Control-Prozess der Umgebung. Überprüfen Sie anschließend einen einfachen Health-Endpunkt, die zuvor fehlschlagende Operation und repräsentative abhängige Funktionen. Stellen Sie sicher, dass 5xx-Rate und Latenz wieder normal sind, ohne doppelte Schreibvorgänge oder zusätzliche Last zu erzeugen. Wenn die Lösung eine Zustandsänderung wie den Neustart eines Prozesses, das kontrollierte Ableiten von Traffic oder eine Timeout-Änderung umfasst, dokumentieren Sie die erwarteten Auswirkungen und holen Sie vorher die erforderliche Genehmigung ein.

Vorbeugung und Überprüfung der Lösung

• Überwachen Sie 5xx-Rate, Latenz und Verfügbarkeit nach Route, Dienst und der Ebene, die die Antwort erzeugt.
• Verwenden Sie Readiness- und Liveness-Checks, die reale Anforderungen an Abhängigkeiten abbilden, ohne übermäßige Last zu erzeugen.
• Halten Sie Request-IDs oder Trace-IDs über Proxys, Anwendungen und Abhängigkeiten hinweg konsistent.
• Legen Sie an jeder Service-Grenze begrenzte und überprüfte Timeouts sowie Verbindungslimits fest. Verhindern Sie, dass langsame externe Aufrufe alle Worker blockieren.
• Richten Sie Alarme für Ressourcenüberlastung, Prozessabstürze, Datenbanklatenz, erschöpfte Connection Pools und kritischen Speicherplatz ein, bevor daraus weitreichende Ausfälle entstehen.
• Verwenden Sie gestaffelte Deployments, eine gesundheitsbasierte Traffic-Steuerung und ein getestetes Rollback-Verfahren.
• Dokumentieren Sie, welche 5xx-Codes jeder Proxy, jede Anwendung und jede Abhängigkeit ausgeben kann, damit 500, 502, 503 und 504 nicht als austauschbar behandelt werden.
• Testen Sie regelmäßig das Verhalten bei beeinträchtigten Abhängigkeiten und Überlastung in einer dafür autorisierten Umgebung.

Häufig gestellte Fragen