500 Internal Server Error

Was dieser Fehler bedeutet und wie du ihn erkennst

• Der Browser zeigt eine leere, allgemeine oder gebrandete Seite mit 500 Internal Server Error an.
• Eine zuvor funktionierende Seite fällt nach einer Codeänderung, der Installation oder Aktualisierung eines Plugins oder Themes, einem Deployment oder einer Konfigurationsänderung aus.
• Nur bestimmte URLs, Formulare, Administrationsseiten oder Website-Funktionen schlagen fehl, während der Rest der Website erreichbar bleibt.
• Ein PHP-, Anwendungs- oder Webserver-Log erfasst zum gleichen Zeitpunkt einen fatalen Fehler, Syntaxfehler, ein Berechtigungsproblem, eine fehlende Abhängigkeit oder das Erreichen eines Ressourcenlimits.
• Wiederholte Anfragen liefern dieselbe 500-Antwort, auch wenn bei einem Ressourcenlimit oder einer Anwendungsabhängigkeit sporadische Fehler auftreten können.

Hauptursachen nach Wahrscheinlichkeit

1. Fehler in Anwendungscode, Plugin, Theme oder Modul — Ein Syntaxfehler, fataler Fehler, inkompatibles Update oder eine nicht behandelte Bedingung kann verhindern, dass die Anfrage abgeschlossen wird.
2. Ungültige Apache-Konfiguration — Eine fehlerhafte oder nicht unterstützte Direktive in .htaccess oder eine Regel, die ein deaktiviertes Modul voraussetzt, kann eine 500-Antwort auslösen. .htaccess gilt für Apache-basierte Setups, nicht für alle Webserver.
3. Falsche Datei- oder Verzeichnisberechtigungen bzw. falsche Eigentümerschaft — Manuelle Uploads, Migrationen und Deployments können dazu führen, dass der Webprozess erforderliche Dateien nicht lesen kann.
4. Erschöpfung des PHP-Speichers oder der Ausführungszeit — Große Importe, aufwendige Abfragen oder ressourcenintensive Erweiterungen können konfigurierte Limits überschreiten; manche Umgebungen liefern in diesem Fall 500 zurück.
5. Fehlende Deployment-Konfiguration oder Abhängigkeiten — Geänderte Datenbankzugangsdaten, eine fehlende Umgebungsvariable, ein nicht verfügbares Paket oder eine inkompatible Laufzeitumgebung können die Anwendung beeinträchtigen.
6. Unvollständige oder beschädigte Anwendungs- oder CMS-Dateien — Ein unterbrochenes Update kann dazu führen, dass erforderliche Core-Dateien fehlen oder beschädigt sind.

So behebst du den Fehler

1. Umfang und Zeitpunkt bestätigen

Laden Sie die genaue URL, die 500 zurückgibt, erneut und notieren Sie den Zeitpunkt einschließlich Zeitzone. Prüfen Sie, ob die gesamte Website ausfällt oder nur eine Route, ein Formular, eine Administrationsseite, eine Plugin-Funktion oder ein bestimmter Anfragetyp betroffen ist. Ein funktionsspezifischer Fehler macht den zugehörigen aktuellen Code und dessen Abhängigkeiten wahrscheinlicher; ein websiteweiter Ausfall deutet eher auf eine Serverkonfiguration, ein Deployment oder Core-Dateien hin.

2. Zuerst die relevanten Logs prüfen

Prüfen Sie das PHP-error_log, das Webserver-Fehlerlog sowie das auf dem Host verfügbare Anwendungs- oder CMS-Log. Häufige Speicherorte sind /var/log/apache2/error.log für Apache und /var/log/nginx/error.log für Nginx, allerdings unterscheiden sich die Strukturen je nach Hosting. Gleichen Sie die Einträge mit dem Zeitpunkt des Fehlers ab und notieren Sie Datei, Zeilennummer, Exception, Upstream-Meldung oder Konfigurationsdirektive. Die allgemeine Browserseite allein reicht nicht aus, um die Ursache zu ermitteln.

3. Eine kürzlich vorgenommene Code- oder Erweiterungsänderung isolieren

Wenn das Log eine Datei, ein Plugin, ein Theme, ein Modul oder eine Deployment-Änderung nennt, machen Sie diese Änderung rückgängig oder deaktivieren Sie die genannte Komponente in einer testbaren Umgebung. Verwenden Sie bei einem CMS den Administrationsbereich, sofern er verfügbar ist. Falls der Administrationsbereich nicht erreichbar ist, können Sie das betreffende Komponentenverzeichnis möglicherweise per SFTP oder über den Dateimanager des Hostings umbenennen. Ändern Sie jeweils nur eine Komponente und testen Sie anschließend die fehlerhafte URL erneut. Verschwindet der Fehler, prüfen Sie vor der erneuten Aktivierung Kompatibilität, Konfiguration und verfügbare Updates.

4. .htaccess nur unter Apache testen

Wenn das Log auf einen .htaccess-Parserfehler hinweist oder der Fehler nach einer Änderung an einer Apache-Regel begann, erstellen Sie eine Sicherung und benennen Sie .htaccess vorübergehend über SFTP oder den Dateimanager des Hostings in .htaccess.bak um. Testen Sie die Seite erneut. Funktioniert sie, stellen Sie die Datei sorgfältig wieder her oder erstellen Sie sie neu und fügen Sie benutzerdefinierte Direktiven schrittweise hinzu. Eine nicht unterstützte Direktive oder ein fehlendes Apache-Modul kann die zugrunde liegende Ursache sein. Wenden Sie diesen Schritt nicht bei einem reinen Nginx-Setup an, da .htaccess dort nicht zur Konfiguration von Anfragen verwendet wird.

5. Berechtigungen und Eigentümerschaft sorgfältig korrigieren

Wenn das Log einen Fehler bei Berechtigungen oder Eigentümerschaft meldet, vergleichen Sie den betroffenen Pfad mit einer funktionierenden Datei oder den dokumentierten Einstellungen des Hosting-Anbieters. 644 für Dateien und 755 für Verzeichnisse sind häufige Einstellungen, die korrekten Werte hängen jedoch vom Host und vom Deployment-Modell ab. Korrigieren Sie den betroffenen Pfad per SFTP, SSH oder über den Dateimanager des Hostings. Machen Sie Dateien oder Verzeichnisse nicht als Abkürzung global beschreibbar.

6. PHP- und Ressourcenlimits der Anwendung untersuchen

Wenn das Log auf eine Speichererschöpfung, eine maximale Ausführungszeit oder ein ähnliches Limit hinweist, ermitteln Sie den Vorgang, der die Ressource verbraucht, etwa einen großen Import oder eine aufwendige Plugin-Aufgabe. Passen Sie memory_limit oder max_execution_time in der zutreffenden php.ini, .user.ini, Hosting-Einstellung oder Deployment-Konfiguration nur an, wenn Ihr Host dies erlaubt. Reduzieren Sie außerdem die Arbeitslast oder beheben Sie den ineffizienten Vorgang; eine reine Erhöhung des Limits verschiebt den Fehler möglicherweise nur.

7. Deployment-Einstellungen und erforderliche Dateien vergleichen

Vergleichen Sie bei Fehlern, die nach einem Deployment oder einer Migration begonnen haben, Umgebungsvariablen, Datenbankzugangsdaten, Laufzeitversionen, installierte Abhängigkeiten, Dateipfade und erzeugte Konfigurationen mit der funktionierenden Umgebung. Stellen Sie sicher, dass erforderliche Dateien vorhanden sind und die Anwendung die konfigurierte Datenbank oder den konfigurierten Dienst erreichen kann. Verwenden Sie die im Log genannte fehlende Variable, das fehlende Paket oder den Verbindungsfehler als Ausgangspunkt, statt nicht zusammenhängende Einstellungen zu ändern.

8. Beschädigte Dateien erst nach Sicherung der Belege wiederherstellen

Wenn ein unvollständiges Update oder eine beschädigte Core-Datei angezeigt wird, speichern Sie das relevante Log und eine Kopie der aktuellen Dateien, bevor Sie Reparaturen vornehmen. Stellen Sie anschließend bekannte fehlerfreie Dateien wieder her oder führen Sie den vom System unterstützten Update-Prozess erneut aus; verwenden Sie, falls vorhanden, ein Backup. Testen Sie die ursprüngliche URL erneut und prüfen Sie, ob kein neuer passender Fehler in das Log geschrieben wird.

Vorbeugung und Überprüfung der Lösung

• Sichern Sie Dateien und Datenbank, bevor Sie ein Plugin, Theme, Modul oder eine CMS-Komponente installieren oder aktualisieren.
• Testen Sie Code- und .htaccess-Änderungen nach Möglichkeit auf einer Staging-Kopie und bewahren Sie eine bekannte funktionierende Konfiguration für ein Rollback auf.
• Stellen Sie Konfigurationsvariablen und Abhängigkeiten in den verschiedenen Umgebungen einheitlich bereit und überprüfen Sie nach Migrationen, ob alle erforderlichen Dateien vorhanden sind.
• Überwachen Sie PHP-, Anwendungs- und Webserver-Fehlerlogs, statt sich ausschließlich auf externe Verfügbarkeitsprüfungen zu verlassen.
• Nehmen Sie jeweils nur eine Änderung vor, dokumentieren Sie, was geändert wurde, und testen Sie die genau betroffene URL erneut.
• Bewahren Sie detaillierte Diagnosedaten in serverseitigen Logs auf, statt sie Besuchern auf einer Produktionswebsite anzuzeigen.

Häufig gestellte Fragen