500 Internal Server Error: Beginnen Sie mit dem error log
Ein 500 Internal Server Error bedeutet, dass ein Webserver auf einen unerwarteten Zustand gestoßen ist und eine Anfrage nicht abschließen konnte. Es handelt sich um einen HTTP status code, also eine Zahl, mit der ein Server das Ergebnis einer Browseranfrage beschreibt; die zugrunde liegende Störung wird dadurch jedoch nicht angegeben. Die größere 5xx-Gruppe umfasst serverseitige Fehler: 502 weist auf eine fehlerhafte Antwort eines vorgeschalteten Servers hin, 503 bedeutet, dass ein Dienst nicht verfügbar oder überlastet ist, und 504 zeigt an, dass bei einer vorgeschalteten Anfrage ein Timeout aufgetreten ist. Ein 500 ist die allgemeine Antwort, wenn der Server das Problem nicht genauer einordnen kann.
Die Anfrage hat die Website bereits erreicht. Ein echter 500-Fehler wird daher nicht durch den Browser des Besuchers, die Auflösung im Domain Name System (DNS) oder das lokale Netzwerk verursacht. Das Leeren des Browser-Cache repariert den Server nicht. Sichtbar sein kann eine Meldung wie „500 Internal Server Error“ oder „HTTP Error 500“, eine vollständig leere Seite oder die WordPress-Meldung „There has been a critical error on this website.“ WordPress kann diese letzte Meldung anzeigen, nachdem ein fatal PHP error abgefangen wurde, also ein Fehler, der ein PHP-Skript zum Abbruch zwingt. Auch eine leere Antwort kann einen 500-Code enthalten. Betreiber können dies im Network-Panel der Browser-Entwicklertools oder mit einer Anfrage über die Kommandozeile überprüfen.
Bevor Sie Änderungen am Server vornehmen, laden Sie die Seite einmal neu und testen Sie sie über ein anderes Gerät, ein anderes Netzwerk oder einen externen Dienst zur Statusprüfung. Eine kurze Lastspitze bei den Ressourcen oder eine inzwischen wieder funktionierende Abhängigkeit kann dazu führen, dass die Störung nur vorübergehend auftritt. Wenn alle den Fehler sehen, liegt das Problem auf dem Server. Wenn nur ein Besucher betroffen ist, hält möglicherweise ein CDN, Proxy oder page cache eine alte Fehlerantwort vor. Ein CDN, also ein Content Delivery Network, speichert Kopien von Website-Inhalten näher bei den Besuchern. Das Leeren des betreffenden Cache kann diesen begrenzten Fall beheben.
Zu den häufigen Ursachen gehören inkompatible Plugins, Erweiterungen oder Themes, etwa Code, der mit der installierten PHP-Version nicht ausgeführt werden kann, oder zwei Komponenten, die dieselbe Funktion deklarieren. Auf Apache-Servern kann eine fehlerhafte .htaccess-Datei jede Adresse unterhalb ihres Verzeichnisses beeinträchtigen, da diese Datei Redirects, URL rewriting und andere lokale Einstellungen steuert. Ein Tippfehler, eine nicht unterstützte Direktive oder eine von einem anderen Server kopierte Einstellung kann bereits ausreichen. Weitere Ursachen sind ausgeschöpfter PHP-Speicher, eine nach einem Upgrade nicht mehr passende PHP-Version, Fehler bei der Datenbankverbindung, hängende Integrationen, fehlerhafte geplante Tasks und ungültige Antworten einer externen Application Programming Interface.
Auch der Dateizugriff kann verantwortlich sein. Der Server kann möglicherweise eine benötigte Datei nicht lesen, oder eine besonders abgesicherte Hosting-Umgebung lehnt zu weit gefasste Berechtigungen ab. Bei vielen Shared-Hosting-Anbietern wird für Dateien der Berechtigungsmodus 644 und für Verzeichnisse 755 erwartet, wobei der Benutzer des Hosting-Kontos als Eigentümer eingetragen ist. Eine auf 777 gesetzte Datei, die weitreichenden Zugriff erlaubt, oder eine Datei im Besitz eines unbekannten Benutzers kann sowohl betriebliche Probleme als auch Sicherheitsrisiken verursachen. Die richtigen Werte können je nach Hosting-Konfiguration variieren. Betreiber sollten daher die Dokumentation ihres Anbieters beachten.
Lesen Sie zuerst das error log. Ein error log ist eine Serveraufzeichnung von Fehlern und nennt häufig die Datei und die Zeile, in der die Verarbeitung angehalten wurde. Hosting-Control-Panels stellen es üblicherweise unter Logs oder Error Log bereit, während Anbieter möglicherweise separate Speicherorte für Apache-, Nginx- oder PHP-FPM-Aufzeichnungen dokumentieren. Wenn diese Informationen nicht ausreichen, aktivieren Sie das anwendungseigene Debug-Logging. In WordPress können die Konstanten für Debugging und Debug-Logging in wp-config.php fatal errors und Hinweise in eine Datei schreiben. Zeigen Sie auf einer öffentlich erreichbaren Live-Website niemals ausführliche Fehlermeldungen an, da diese interne Dateipfade und andere Implementierungsdetails offenlegen können.
Erstellen Sie eine vollständige Sicherung der Dateien und der Datenbank, bevor Sie etwas bearbeiten oder umbenennen. Benennen Sie anschließend .htaccess in .htaccess_old um und testen Sie erneut. Wenn die Website wieder funktioniert, können WordPress-Benutzer eine saubere Datei erstellen, indem sie Einstellungen und anschließend Permalinks speichern. Bei anderen Anwendungen sollten die Direktiven schrittweise wiederhergestellt werden, bis die fehlerhafte Direktive gefunden ist. Um Plugins zu testen, deaktivieren Sie alle und aktivieren Sie anschließend jedes einzeln. Wenn das Dashboard nicht erreichbar ist, verwenden Sie SFTP, eine verschlüsselte Methode zur Dateiübertragung, um wp-content/plugins umzubenennen. Stellen Sie danach den ursprünglichen Ordnernamen wieder her und testen Sie die einzelnen Plugin-Verzeichnisse. Benennen Sie den Ordner des aktiven Themes um, damit WordPress auf ein Standard-Theme zurückfällt.
Wenn das Log meldet, dass der Speicher ausgeschöpft ist, erhöhen Sie das PHP-Speicherlimit über die Hosting-Einstellungen, die Konfiguration oder wp-config.php nur als diagnostische Maßnahme. Eine Komponente, die deutlich mehr Speicher als der Rest der Website verbraucht, bleibt das eigentliche Problem. Wenn der Fehler nach einem PHP-Upgrade aufgetreten ist, wechseln Sie vorübergehend zur vorherigen Version zurück, um die Kompatibilität zu überprüfen, und aktualisieren Sie anschließend den inkompatiblen Code. Eine nicht mehr unterstützte PHP-Version sollte keine dauerhafte Lösung sein. Überprüfen Sie außerdem Berechtigungen, Eigentumsverhältnisse und die letzten Änderungszeiten von Dateien, leeren Sie page cache, object cache, CDN cache und reverse-proxy cache und teilen Sie dem Hosting-Anbieter den genauen Zeitpunkt des Fehlers sowie den Log-Eintrag mit, wenn die Hinweise auf einen Datenbankdienst, ein Modul oder eine Ressourcenbeschränkung außerhalb der Kontrolle des Kontoinhabers hindeuten.
WordPress bietet zwei weitere Wiederherstellungswege. Beschädigte Core-Dateien können ersetzt werden, indem über SFTP eine frische WordPress-Kopie hochgeladen wird, während wp-content und wp-config.php erhalten bleiben. Nach einem unterbrochenen Update kann eine .maintenance-Datei im Website-Root zurückbleiben; durch das Entfernen dieser Datei wird die Website wieder freigegeben. Riskantere Diagnoseschritte, einschließlich einer ausführlichen Fehlerausgabe, sollten besser auf einer staging copy durchgeführt werden, also auf einem privaten Duplikat, das für Tests vor dem Einsatz in der Produktionsumgebung verwendet wird.
Ein 500-Fehler kann auch auf eine compromised website hinweisen. Sucuri berichtet von Mustern wie eingeschleustem PHP-Code am Anfang von index.php, wp-config.php oder der functions.php eines Themes. Solcher Code kann sofort fehlschlagen oder erst dann, wenn er nach einer PHP-Änderung inkompatibel wird. Angreifer können außerdem .htaccess mit Redirects, besucherabhängigen Regeln, php_value-Einstellungen oder auto_prepend_file-Direktiven verändern, die der Server ablehnt. Beschädigte Backdoors und eine unvollständige Entfernung von Malware können zum gleichen Ergebnis führen.
Zu den Warnzeichen gehören ein Fehler ohne vorheriges Update oder ohne Änderung an der Konfiguration, unerklärliche aktuelle Änderungszeiten, Störungen, die nur bestimmte Besucher oder Personen betreffen, die über eine Suchmaschine kommen, unbekannte Dateien, unerwartete .htaccess-Dateien und Log-Einträge, die unbekannten Code nennen. Keines dieser Anzeichen beweist für sich allein eine Kompromittierung, da automatische Updates und Caching ähnliche Hinweise erzeugen können. Wenn unbekannter Code auftaucht, führen Sie einen serverseitigen Malware-Scan oder einen Vergleich der Dateiintegrität mit bekanntermaßen intakten Core-Dateien durch, kontrollieren Sie .htaccess-Dateien in jedem Verzeichnis, prüfen Sie kürzlich erstellte Administratorkonten und untersuchen Sie die Access-Logs rund um den Zeitpunkt des ersten aufgezeichneten Fehlers. Entfernen Sie nach Bestätigung einer Infektion die schädlichen Dateien, ändern Sie die Zugangsdaten für Hosting, SFTP, Datenbank und CMS-Administratoren und schließen Sie die ursprüngliche Eintrittsstelle. Wird lediglich ein sauberes Backup wiederhergestellt, ohne die Schwachstelle zu schließen, kann es zu einer erneuten Infektion kommen.
Ein kurzer Ausfall verursacht wahrscheinlich keine dauerhaften Schäden bei der Suche, da Crawler Anfragen nach Serverfehlern im Allgemeinen erneut versuchen.