HTTP Statuscode 500: Ursache finden

Der HTTP-Statuscode 500 sagt genau eine Sache: Auf dem Server ist etwas schiefgegangen, das die Anfrage nicht bearbeiten ließ. Er sagt nicht, was.

Das ist keine schlechte Implementierung, sondern Absicht. RFC 9110 beschreibt 500 als „Internal Server Error" für den Fall, dass der Server auf eine unerwartete Bedingung gestoßen ist, die ihn an der Bearbeitung hindert — ausdrücklich als Auffangcode, wenn kein spezifischerer 5xx passt. Wer aus dem Code selbst eine Diagnose ableiten will, sucht an der falschen Stelle.

Warum die Seite nichts verrät#

Die echte Fehlermeldung existiert in fast allen Fällen. Sie steht nur nicht auf der Seite.

Der Grund ist Sicherheit. Eine Anwendung, die im Fehlerfall Dateipfade, Datenbanknamen, Versionsnummern oder Teile des Quelltexts ausgibt, liefert jedem Besucher eine Landkarte des Systems. Produktivsysteme schalten die Anzeige deshalb ab und schreiben stattdessen in ein Log. Bei PHP steuern das display_errors und log_errors, bei WordPress zusätzlich die Konstanten in der wp-config.php.

Die Folge im Alltag: Der Betreiber sieht eine leere oder generische Seite, während die Antwort auf seine Frage bereits auf der Platte liegt.

Wo die eigentliche Meldung steht#

Es gibt drei Orte, und sie sind nicht austauschbar.

1. Das Fehlerlog des Webservers. Bei Apache üblicherweise error_log im Verzeichnis der Domain oder unter /var/log/apache2/, bei nginx /var/log/nginx/error.log. Hier landet, was der Webserver selbst bemerkt: kaputte Konfiguration, verweigerte Zugriffe, abgestürzte Prozesse.

2. Das PHP-Fehlerlog. Bei FPM-Setups oft getrennt vom Webserver-Log, der Pfad steht in der Pool-Konfiguration oder in der php.ini unter error_log. Hier steht die interessante Zeile: PHP Fatal error: mit Datei und Zeilennummer.

3. Das Log der Anwendung. WordPress schreibt bei aktiviertem WP_DEBUG_LOG nach wp-content/debug.log, andere Frameworks in eigene Verzeichnisse.

Wer nur Zugriff auf ein Hosting-Panel hat, findet die Logs meist unter „Logs", „Fehlerprotokoll" oder als Download im Dateimanager. Auf der Kommandozeile reicht:

``bash tail -n 50 /var/log/nginx/error.log ``

Entscheidend ist der Zeitstempel. Man ruft die fehlerhafte Seite einmal auf, notiert die Uhrzeit und sucht genau dort. Ältere Einträge gehören zu anderen Vorfällen und führen zuverlässig in die Irre.

Die häufigsten Auslöser#

Fast alles, was in der Praxis eine 500 erzeugt, fällt in wenige Gruppen.

Fataler PHP-Fehler. Ein Syntaxfehler nach einer Bearbeitung, eine aufgerufene Funktion, die es in dieser PHP-Version nicht mehr gibt, eine Klasse aus einem Plugin, das gerade deaktiviert wurde. Im Log erkennbar an Fatal error samt Pfad.

Speicher aufgebraucht. Allowed memory size ... exhausted. Der Prozess wird abgebrochen, der Webserver hat keine gültige Antwort und antwortet mit 500. Das Limit anzuheben behebt das Symptom; die Ursache ist meist eine Routine, die zu viele Daten auf einmal in den Speicher lädt.

Fehlerhafte Serverkonfiguration. Eine .htaccess mit einer Direktive, die das Modul auf diesem Server nicht kennt, erzeugt eine 500 für das gesamte Verzeichnis. Testweise umbenennen zeigt das in einer Minute.

Falsche Dateirechte. Skripte, die für den Webserver-Benutzer nicht lesbar oder ausführbar sind, oder Verzeichnisse mit zu weiten Rechten, die von einer strengen Konfiguration abgelehnt werden.

Datenbank nicht erreichbar. Je nach Anwendung führt das zu einer eigenen Meldung statt zu einer 500 — der Weg dorthin steht in Fehler beim Aufbau einer Datenbankverbindung.

Bei WordPress überlagert der Fehlerschutz das Bild zusätzlich: Statt einer nackten 500 erscheint oft ein einzelner Satz. Wie man an die dahinterliegende Meldung kommt, beschreibt „Es gab einen kritischen Fehler auf deiner Website".

Abgrenzung zu 502 und 504#

Die drei Codes werden im Sprachgebrauch vermischt, meinen aber unterschiedliche Stellen im Ablauf.

• 500 — die Anwendung selbst ist auf einen Fehler gelaufen. Der Server, der antwortet, ist auch der Server, der das Problem hat.
• 502 — ein Proxy hat eine ungültige Antwort von einem vorgeschalteten Dienst erhalten.
• 504 — ein Proxy hat auf die Antwort gewartet und die Zeit war um.

Bei nginx mit PHP-FPM verschiebt sich die Grenze: Stürzt der PHP-Prozess mitten in der Antwort ab, sieht nginx keine gültige Antwort mehr und meldet 502, obwohl die Ursache ein klassischer PHP-Fehler ist. Das Log des Anwendungsprozesses bleibt also auch dort die maßgebliche Quelle.

Ein Punkt, der oft untergeht: Länger anhaltende 5xx-Antworten haben Folgen jenseits der Besucher. Suchmaschinen drosseln das Crawling betroffener Hosts, und Seiten, die im Fehlerzustand abgerufen wurden, können aus dem Index fallen. Warum das passiert, steht in Warum Google Seiten nicht indexiert.

Wenn eine 500 ohne jede eigene Änderung auftaucht und im Log Dateien auffallen, die niemand angefasst hat, ist das ein eigener Verdachtsfall und kein Konfigurationsproblem.