5xx-Statuscodes erklärt: wenn Ihr Server das Problem ist
Ein 5xx-Statuscode bedeutet, Ihre Infrastruktur ist gescheitert, nicht die Anfrage des Besuchers. Der Server hat die Anfrage angenommen, verstanden, und konnte dann keine gültige Antwort erzeugen, jeder 5xx auf Ihrer Website ist also ein Vorfall, den Sie selbst verschulden.
Was 5xx von 4xx trennt
RFC 9110 definiert 5xx als "Server Error": Der Server ist sich bewusst, dass er einen Fehler gemacht hat oder nicht in der Lage ist, die angeforderte Methode auszuführen. Das ist der gesamte Unterschied. Ein 404 sagt "hier ist nichts". Ein 500 sagt "hier ist etwas, und ich bin kaputtgegangen, während ich es erzeugt habe".
Zwei Folgen ergeben sich daraus. Erstens ist ein 5xx meist wiederholbar, denn dieselbe Anfrage kann eine Sekunde später durchaus gelingen, sobald sich die fehlschlagende Komponente erholt hat. Zweitens behandeln Suchmaschinen einen 5xx als vorübergehendes Signal und drosseln das Crawlen, statt sofort zu deindexieren, während ein über Tage anhaltender 5xx letztlich doch indexierte Seiten kostet.
Welcher Hop fehlgeschlagen ist
Lesen Sie einen 5xx-Code als eine Karte davon, wo die Anfrage gestorben ist. Fast jede moderne Website hat mindestens einen Proxy vor der Anwendung, der Code sagt Ihnen also, welche Seite dieser Grenze fehlgeschlagen ist.
| Code | Wer ihn erzeugt hat | Was passiert ist |
|---|---|---|
| 500 Internal Server Error | Die Anwendung selbst | Unbehandelte Ausnahme oder unerwarteter Zustand in der App |
| 501 Not Implemented | Der Server | Die Anfragemethode wird überhaupt nicht unterstützt |
| 502 Bad Gateway | Der Proxy, das CDN oder der Load Balancer | Das Backend hat geantwortet, aber mit etwas Ungültigem, oder die Verbindung geschlossen |
| 503 Service Unavailable | Der Server oder Proxy, absichtlich | Überlastet oder in Wartung, und lehnt Arbeit absichtlich ab |
| 504 Gateway Timeout | Der Proxy, das CDN oder der Load Balancer | Das Backend hat nie rechtzeitig geantwortet |
| 505 HTTP Version Not Supported | Der Server | Die Protokollversion in der Anfrage wird nicht unterstützt |
502, 503 und 504 tragen den größten diagnostischen Wert, denn jeder benennt einen anderen Fehlschlag desselben Backends: ungültige Antwort, abgelehnte Antwort, keine Antwort. Die 502-Bad-Gateway-Anleitung behandelt den ersten davon ausführlich, einschließlich der Proxy-Protokollzeilen, die den genauen Fehler identifizieren.
Häufige Ursachen hinter 5xx-Antworten
- Anwendungsabstürze. Eine unbehandelte Ausnahme, eine fehlgeschlagene Datenbankverbindung oder ein Null-Wert an unerwarteter Stelle erzeugt 500 auf jeder Route, die den kaputten Codepfad berührt.
- Backend-Prozess läuft nicht. Ein gestoppter App-Server, ein toter PHP-FPM-Pool oder ein Container, der seinen Health-Check nicht bestanden hat, gibt dem Proxy niemanden zum Reden, was als 502 erscheint.
- Ressourcenerschöpfung. Kein Speicher mehr, keine Dateideskriptoren mehr, keine Worker-Threads mehr oder keine Datenbankverbindungen mehr. Startet meist als sporadische Fehler unter Last, bevor es konstant wird.
- Langsame Abhängigkeiten. Eine langsame Abfrage, eine langsame Drittanbieter-API oder ein Kaltstart schiebt die Antwortzeit über das Timeout des Proxys hinaus und wird zu 504.
- Deploys und Neustarts. Jedes Fenster, in dem der alte Prozess gestoppt hat und der neue noch nicht angefangen hat zu bedienen, erzeugt einen Ausbruch von 502 oder 503.
- Konfigurationsfehler. Eine falsche Upstream-Adresse, eine schlechte TLS-Einrichtung zwischen Proxy und Backend, oder eine Protokoll-Fehlanpassung wie HTTP an einen HTTPS-Port zu sprechen.
- Volle Festplatte. Eine unterschätzte Ursache. Protokolle oder temporäre Dateien füllen das Volume, Sitzungen oder Caches hören auf zu schreiben, und die Anwendung beginnt auf scheinbar zufällige Weise zu scheitern.
Wie Sie einen 5xx durcharbeiten
- Bestätigen Sie den Code und seinen Ursprung. Holen Sie Header direkt ab und schauen Sie, welche Komponente die Antwort gezeichnet hat:
Eincurl -sS -o /dev/null -D - https://example.com/Server:- oder CDN-Header auf dem Fehler sagt Ihnen, ob die Edge oder der Ursprung ihn erzeugt hat. - Testen Sie den Ursprung direkt, unter Umgehung des Proxys. Antwortet das Backend mit 200 auf seinem eigenen Port, während die öffentliche URL mit 502 antwortet, liegt der Fehler in der Proxy-Schicht oder der Verbindung zwischen beiden.
- Lesen Sie als Nächstes das Proxy-Fehlerprotokoll, nicht das Anwendungsprotokoll. Reverse-Proxys benennen den Fehlschlag präzise, zum Beispiel
connect() failed (111: Connection refused)oderupstream timed out, was sofort "Backend down" von "Backend langsam" trennt. - Lesen Sie dann das Anwendungsprotokoll. Bei einem 500 ist der Stack-Trace die Antwort. Bei 502 und 504 protokolliert die Anwendung oft überhaupt nichts, und diese Abwesenheit ist selbst aufschlussreich.
- Prüfen Sie Ressourcen auf dem Host. Speicher, Festplatte, Verbindungsanzahl und Worker-Sättigung. Sporadischer 5xx unter Traffic ist fast immer ein erreichtes Limit.
- Schauen Sie, was sich geändert hat. Deploys, Konfigurationsänderungen, Zertifikatserneuerungen und Abhängigkeits-Updates erklären einen großen Anteil plötzlich auftretender 5xx-Fehler.
Sporadische 5xx-Fehler erwischen
5xx-Fehler sind oft sporadisch, was sie von Hand schwer zu erwischen macht: Die Seite, die Sie neu laden, funktioniert, und die, die Ihr Kunde geladen hat, tat es nicht. Eine geplante HTTP-Prüfung läuft kontinuierlich und prüft die Website weit öfter, als Sie es könnten, eine Reihe von Fehlern wird also als Muster sichtbar statt als verstreute Beschwerden. Von vielen Standorten zu prüfen trennt außerdem einen echten Serverfehler von einem Routing- oder Edge-Problem, das nur einen Teil der Welt betrifft, weshalb verteiltes Verfügbarkeits-Monitoring Prüfpunkte über Regionen verteilt nutzt statt eines einzelnen Beobachtungspunkts. Stellt sich heraus, dass der fehlschlagende Code stattdessen 403, 404 oder 429 ist, hat die Anfrage nie ein kaputtes Backend erreicht, und die 4xx-Familienanleitung ist der richtige Ausgangspunkt.