Ein 500 Internal Server Error bedeutet, dass die Anwendung auf dem Server beim Erstellen der Antwort auf ein Problem gestoßen ist, das sie nicht abfangen konnte. Anders als die meisten anderen Fehler verrät er nicht, was schiefgelaufen ist. So sagt der Server: „Etwas ist kaputt, aber dem Besucher verrate ich nicht, was.“
Die eigentliche Fehlermeldung gibt es trotzdem. Sie steht in einem Log. Dieser Leitfaden zeigt, wo Sie sie finden, welche Ursachen hinter den meisten 500-Fehlern stecken und wie Sie sicherstellen, dass Sie als Erste davon erfahren.
Was ein 500 Ihnen sagt
Ein 500 kommt von der Anwendung selbst oder vom Webserver, der sie ausführt. Die Anfrage hat Ihren Code erreicht, und der Code ist gescheitert: eine nicht abgefangene Exception, ein fataler Fehler, eine Konfiguration, die der Server nicht lesen konnte. Das unterscheidet ihn von den Gateway-Fehlern, bei denen das Problem zwischen zwei Servern liegt:
500 Internal Server Error: Die Anwendung ist bei der Verarbeitung der Anfrage gescheitert.
502 Bad Gateway: Ein Proxy hat von der Anwendung eine ungültige Antwort erhalten. Siehe unseren Leitfaden zu 502.
503 Service Unavailable: Der Dienst ist überlastet oder in Wartung. Siehe unseren Leitfaden zu 503.
504 Gateway Timeout: Die Anwendung hat zu langsam geantwortet. Siehe unseren Leitfaden zu 504.
Ein 500 auf einer einzelnen Seite deutet meist auf einen Bug im Code dieser Seite hin. Ein 500 auf allen Seiten heißt meist, dass etwas Gemeinsames kaputt ist: die Konfiguration, die Datenbankverbindung, eine Datei, die die gesamte Anwendung lädt.
Beginnen Sie mit dem, was sich geändert hat
Die meisten 500-Fehler treten direkt nach einer Änderung auf. Bevor Sie auch nur ein Log lesen, fragen Sie sich, was in der letzten Stunde passiert ist:
Ein Deploy oder ein Merge in den Main-Branch
Ein Update von Plugin, Theme, Framework oder Programmiersprache
Eine Änderung an einer Konfigurationsdatei, an .htaccess oder an Umgebungsvariablen
Ein geändertes Passwort oder ein neuer API-Schlüssel
Ein Server, dessen Festplatte voll ist oder dessen Berechtigungen geändert wurden
Passt der Zeitpunkt, ist das Zurückrollen der Änderung oft der schnellste Weg, die Website wiederherzustellen. Die Ursache suchen Sie danach, ohne dass Kunden zusehen.
Die eigentliche Fehlermeldung finden
Die 500-Seite ist allgemein, das Log ist konkret. Wo Sie suchen, hängt vom Stack ab:
# nginx and Apache
tail -n 50 /var/log/nginx/error.log
tail -n 50 /var/log/apache2/error.log
# PHP-FPM
tail -n 50 /var/log/php8.3-fpm.log
# Applications run by systemd
journalctl -u myapp –since „15 min ago“
# Docker
docker logs –since 15m myapp
Suchen Sie den Zeitstempel der fehlgeschlagenen Anfrage. Der Eintrag daneben nennt meist Datei, Zeile und Grund: eine undefinierte Funktion, eine fehlende Klasse, eine Datenbank, die das Passwort abgelehnt hat.
In WordPress aktivieren Sie das Debug-Log in wp-config.php. Es schreibt Fehler nach wp-content/debug.log, ohne sie Besuchern anzuzeigen:
define( ‚WP_DEBUG‘, true );
define( ‚WP_DEBUG_LOG‘, true );
define( ‚WP_DEBUG_DISPLAY‘, false );
Schalten Sie es danach wieder aus, denn das Log kann groß werden und sensible Details enthalten.
Häufige Ursachen und wie Sie sie beheben
Ein Fehler im Code
Eine nicht abgefangene Exception oder ein fataler Fehler im Code, der die Seite erstellt. Das Log zeigt Datei und Zeile. Typische Auslöser sind eine Funktion, die mit unerwarteten Daten aufgerufen wird, ein Wert, der unerwartet leer ist, und Code, der auf dem Rechner des Entwicklers läuft, aber eine PHP-Erweiterung oder Bibliotheksversion braucht, die der Server nicht hat. Beheben Sie den Code oder rollen Sie auf die letzte funktionierende Version zurück.
Ein Plugin- oder Theme-Update
Bei WordPress und anderen CMS ist ein Plugin- oder Theme-Update die häufigste Ursache. Das Log nennt den Ordner des Plugins. Kommen Sie nicht ins Backend, benennen Sie diesen Ordner per SSH oder SFTP um, um das Plugin zu deaktivieren:
mv wp-content/plugins/some-plugin wp-content/plugins/some-plugin.disabled
Die Website läuft dann ohne das Plugin wieder. Aktualisieren Sie es anschließend erneut, ersetzen Sie es oder schicken Sie dem Entwickler die Fehlermeldung aus dem Log.
Eine fehlerhafte .htaccess-Datei
Unter Apache legt eine einzige falsche Zeile in .htaccess die ganze Website mit einem 500 lahm. Im Error-Log steht Invalid command oder die Direktive, die nicht verstanden wurde. Benennen Sie die Datei zum Testen um und stellen Sie die Zeilen dann einzeln wieder her. In WordPress schreibt das Speichern der Permalink-Einstellungen eine neue Datei.
PHP ohne Arbeitsspeicher
Allowed memory size of 134217728 bytes exhausted bedeutet, dass eine Anfrage mehr Speicher brauchte, als memory_limit erlaubt. Ein höheres Limit kann helfen, aber eine Anfrage, die Hunderte Megabyte braucht, lädt meist zu viele Daten auf einmal. Finden Sie heraus, was sie lädt, bevor Sie ihr mehr geben.
Dateiberechtigungen und Eigentümer
Nach einem Deploy, einer Wiederherstellung oder einer manuellen Kopie können Dateien dem falschen Benutzer gehören. Der Webserver kann dann den Code nicht lesen oder nicht in seine Cache- und Upload-Ordner schreiben, und im Log steht Permission denied. Setzen Sie den Eigentümer wieder auf den Benutzer, unter dem Webserver oder PHP laufen. Verzeichnisse brauchen normalerweise 755 und Dateien 644; lösen Sie das Problem nie mit 777.
Eine volle Festplatte
Ist die Festplatte voll, können Anwendungen keine Sessions, Caches, Uploads oder Logs mehr schreiben und scheitern auf eine Weise, die in einem 500 endet. Prüfen Sie Speicherplatz und Inodes:
df -h
df -i
Alte Logs, Backups und Caches sind die üblichen Verdächtigen. Server-Monitoring mit einem Festplatten-Alarm bei 80 oder 90 Prozent erkennt das Tage, bevor die Website ausfällt.
Fehler bei der Datenbankverbindung
Ein geändertes Passwort, ein ausgefallener Datenbankserver oder ein erreichtes Verbindungslimit. Die Anwendung kann nichts laden und scheitert auf jeder Seite. Das Log nennt den Datenbankfehler. Prüfen Sie, ob die Datenbank läuft, ob die Zugangsdaten in der Konfiguration aktuell sind und wie viele Verbindungen im Vergleich zum Limit offen sind.
Der 500, der 200 zurückgibt
Nicht jede kaputte Seite gibt das zu. Manche Anwendungen fangen den Fehler ab und zeigen eine freundliche „Etwas ist schiefgelaufen“-Seite mit Status 200, und ein CMS kann eine leere Produktliste ausgeben, ohne sich zu beschweren. Für ein Monitoring, das nur auf den Statuscode schaut, sieht alles gut aus.
Prüfen Sie deshalb auch den Inhalt. Ein Uptime-Monitor kann verlangen, dass eine Seite ein Wort enthält, das immer da ist, wenn sie funktioniert, etwa den Produktnamen oder „In den Warenkorb“, und sein Fehlen als Fehler werten. Unsere Checkliste, was Sie überwachen sollten, zeigt, welche Seiten eine solche Prüfung verdienen.
Wie Monitoring 500er erkennt
Ein 500 nach einem Deploy kann stundenlang unbemerkt bleiben, wenn er nur eine Seite trifft. Der Checkout ist kaputt, die Startseite funktioniert noch, und das Team erfährt es aus einer Kunden-E-Mail oder einem Umsatzeinbruch.
Prüfen Sie die Seiten, die Geld verdienen. Richten Sie Uptime-Monitore für Checkout, Login, Registrierung und API ein, nicht nur für die Startseite, mit Inhaltsprüfungen dort, wo ein 200 einen Fehler verbergen kann.
Bestätigen, bevor alarmiert wird. Uptimecheck prüft bis zu jede Minute aus Stockholm, London und New York und bestätigt jeden Fehler von einem zweiten Standort aus, damit eine einzelne fehlgeschlagene Anfrage niemanden alarmiert.
Sehen, was kaputt ist. Der Vorfall enthält die fehlerhafte Antwort mit Statuscode und Fehlerseite sowie einen Screenshot dessen, was ein Besucher gesehen hat.
Ganze Abläufe testen. Ein Login oder Checkout, der bei Schritt drei scheitert, liefert bei Schritt eins 200. Mehrstufige Flows gehen die Schritte durch und zeigen, welcher fehlgeschlagen ist.
Checkliste für 500-Fehler
Fragen Sie, was sich in der letzten Stunde geändert hat, und rollen Sie zurück, wenn der Zeitpunkt passt.
Suchen Sie den Zeitstempel der fehlgeschlagenen Anfrage im Error-Log.
Lesen Sie den Fehler: Datei, Zeile und Grund.
Schließen Sie die üblichen Ursachen aus: ein Plugin, .htaccess, Speicher, Berechtigungen, Festplatte, Datenbank.
Beheben Sie die Ursache und entfernen Sie danach alle Debug-Einstellungen, die Sie aktiviert haben.
Überwachen Sie wichtige Seiten jede Minute, mit Inhaltsprüfungen dort, wo ein 200 einen Fehler verbergen kann.
Testen Sie Logins und Checkouts als Flows, nicht als einzelne Seiten.