500 Internal Server Error: Ursachen, Logs und Unterschied zu 502

Warum 500 Ihnen so wenig verrät

RFC 9110 definiert 500 als einen unerwarteten Zustand, der den Server daran gehindert hat, den Request zu erfüllen. Das ist absichtlich weit gefasst. Alles, womit die Anwendung nicht gerechnet hat, von einer Null-Referenz über eine fehlgeschlagene Datenbankverbindung bis zu einer Konfigurationsdatei, die sich nicht parsen lässt, landet unter derselben Zahl.

Die Vagheit ist auch ein Sicherheitsmerkmal. Eine 500-Seite sollte niemals Stacktraces, Dateipfade, SQL-Fragmente oder Bibliotheksversionen öffentlich preisgeben, denn genau das sind die Details, die ein Angreifer will. Der Code bleibt also in der Antwort generisch, und die Details gehen in ein Log, das nur Sie lesen können. Dieser Kompromiss ist richtig, und er macht ein Wissen nützlicher als jedes andere: wo Ihre Logs liegen.

500 gegenüber 502, 503 und 504

Alle vier sind Serverfehler, werden aber von unterschiedlichen Komponenten erzeugt und verweisen auf unterschiedliche Probleme. Das richtig zu unterscheiden spart den größten Teil der Debugging-Zeit.

• 500 kommt von der Anwendung selbst. Etwas lief und warf eine Ausnahme. Das Anwendungslog hat einen Stacktrace.
• 502 kommt von einem Proxy vor der Anwendung, der eine ungültige Antwort oder eine geschlossene Verbindung vom Backend erhielt. Das Backend protokolliert oft nichts, weil es den Request nie fertigstellte. Siehe die 502-Anleitung.
• 503 ist eine Ablehnung, kein Absturz. Der Server ist überlastet oder in Wartung und lehnt Arbeit absichtlich ab, meist mit Retry-After.
• 504 ist ein Timeout. Das Backend war erreichbar, hat aber nicht innerhalb des Limits des Proxys geantwortet. Der Request läuft im Hintergrund oft noch weiter.

Eine grobe Eselsbrücke: 500 heißt, Ihr Code ist kaputtgegangen, 502 heißt, Ihr Backend ist tot oder fehlerhaft, 503 heißt, Ihr Server sagt absichtlich Nein, 504 heißt, Ihr Backend ist zu langsam. Die ganze Familie wird in der 5xx-Übersicht verglichen.

Was einen 500 verursacht

• Unbehandelte Ausnahmen im Anwendungscode. Die größte einzelne Kategorie. Ein Null-Wert, eine fehlgeschlagene Typkonvertierung, ein Array-Index außerhalb des Bereichs, eine Division durch null auf einem Pfad, den niemand getestet hat.
• Datenbankfehler. Connection-Pool erschöpft, Anmeldeinformationen rotiert, die Datenbank neu gestartet, eine Abfrage, die in einen Deadlock läuft oder ein Timeout erreicht.
• Fehlende oder defekte Abhängigkeiten nach einem Deployment. Ein Paket, das nicht installiert wurde, eine Datei, die der Build nicht kopiert hat, eine Umgebungsvariable, die in Staging existiert und in Produktion nicht.
• Syntaxfehler in der Konfiguration. Bei Apache erzeugt eine einzige ungültige Direktive in einer .htaccess-Datei für jeden Request unter diesem Verzeichnis 500.
• Dateiberechtigungen und -besitz. Die Anwendung kann eine Konfigurationsdatei nicht lesen oder nicht in ein Cache-, Sitzungs- oder Upload-Verzeichnis schreiben.
• Ressourcenlimits. Ein Speicherlimit, ein Ausführungszeitlimit oder eine volle Festplatte. Diese erzeugen typischerweise zeitweise 500er, die mit dem Traffic zusammenhängen.
• Fehler bei Drittanbieter-APIs, die der Code ohne Fallback aufruft, sodass ein entfernter Ausfall zu Ihrer Fehlerseite wird.

Wie Sie einen 500 diagnostizieren

1. Bestätigen Sie den Code und wer ihn erzeugt hat. Eine gebrandete Fehlerseite kann den echten Status verbergen:

   curl -sS -o /dev/null -D - https://example.com/failing-page

   Prüfen Sie die Statuszeile und jeden Server- oder CDN-Header. Ist der Fehler von einem Edge-Netzwerk signiert und antwortet der Ursprung mit 200, sehen Sie überhaupt keinen 500 aus Ihrer Anwendung.
2. Öffnen Sie zuerst das Anwendungslog. Dort steht der Stacktrace. Framework-Logs, der Plattform-Log-Stream oder das stdout des Containers, je nachdem, was Ihr Stack verwendet, und gleichen Sie nach Zeitstempel und Request-Pfad ab.
3. Dann das Fehlerlog des Webservers. Apache error_log, nginx error.log, oder das Windows-Ereignisprotokoll für IIS. Hat die Anwendung nie etwas protokolliert, geschah der Fehlschlag, bevor Ihr Code lief, was auf Konfiguration oder die Laufzeitumgebung verweist.
4. Reproduzieren Sie es gezielt. Stellen Sie fest, ob der 500 eine URL, eine HTTP-Methode, einen Nutzer oder alles betrifft. Ein 500 nur bei POST bedeutet meist Formularverarbeitung oder einen Schreibpfad. Ein 500 nur bei einem Nutzer bedeutet meist dessen Daten.
5. Schalten Sie detaillierte Fehler in einer nicht öffentlichen Umgebung ein. Nie in Produktion. Reproduzieren Sie in Staging mit vollständiger Fehlerausgabe, was aus einem generischen 500 eine konkrete Zeilennummer macht.
6. Prüfen Sie, was sich geändert hat. Das letzte Deployment, ein Konfigurations-Push, eine Zertifikatsverlängerung, ein Abhängigkeits-Update oder eine Datenbankmigration. War die Website vor einer Stunde noch in Ordnung, steckt die Antwort fast immer in der letzten Änderung.
7. Prüfen Sie die Host-Ressourcen. Speicherplatz, Arbeitsspeicher und Verbindungsanzahl. Eine mit Logs vollgelaufene Festplatte erzeugt 500er, die völlig unabhängig vom Code wirken.

Die 500er, die nur eine einzige Seite zurückgibt

Die meisten 500er legen nicht die ganze Website lahm. Eine Route, ein Formular oder eine Region bricht, während die Startseite weiter lädt, sodass von außen nichts falsch aussieht und die Fehler Tage später als verlorene Anmeldungen auftauchen. Eine geplante HTTP-Prüfung auf den wichtigen Seiten, nicht nur der Startseite, vergleicht den zurückgegebenen Code mit dem erwarteten und schlägt Alarm, sobald eine Route mit 500 zu antworten beginnt. Benachrichtigungen können per E-Mail, SMS, Sprachanruf, Slack, Telegram und mehr eintreffen, sodass ein nächtlicher Ausfall den Bereitschaftsdienst erreicht, statt auf den Morgen zu warten. HostTracker überwacht Websites seit 2004.