HTTP Error 500: Ursachen finden und den Fehler beheben

Ein HTTP Error 500 ist die unangenehmste Fehlermeldung, die eine Website zeigen kann, weil sie nichts erklärt. Der Browser meldet nur "Internal Server Error", die Seite bleibt weiß, und ob ein Plugin, eine Konfigurationsdatei oder der Server selbst schuld ist, steht nirgends. Dieser Beitrag erklärt, was der Statuscode tatsächlich aussagt, welche Ursachen in der Praxis am häufigsten dahinterstecken, wie Sie den Fehler in fünf Schritten eingrenzen und an welcher Stelle bei webhostone der Support übernimmt.

Was bedeutet der HTTP Error 500 genau?

Der Statuscode 500 ist in RFC 9110, Abschnitt 15.6.1 definiert: Der Server ist auf eine unerwartete Bedingung gestoßen, die ihn daran hindert, die Anfrage zu beantworten. Das ist bewusst allgemein gehalten. Der Code sagt nur, dass der Fehler auf der Serverseite liegt und nicht beim Besucher, im Gegensatz zu den 4xx-Codes wie 404 (Seite nicht gefunden) oder 401 (Anmeldung erforderlich). Wichtig für die Fehlersuche: Ein 500 entsteht fast immer in der Anwendung oder ihrer Konfiguration, nicht in der Hardware. Der Webserver läuft, er hat die Anfrage angenommen, und erst bei der Verarbeitung ist etwas schiefgegangen. Die verwandten Codes der 5xx-Reihe grenzen das weiter ein.

Zeigt Ihre Website einen 502, 503 oder 504, lohnt sich zuerst ein Blick auf Auslastung und Laufzeiten. Beim echten 500 dagegen steckt fast immer ein konkreter Fehler im Code oder in einer Konfigurationsdatei, und der lässt sich finden.

Welche Ursachen stecken am häufigsten hinter dem Fehler 500?

Aus den Support-Anfragen bei webhostone lassen sich die Auslöser recht klar sortieren. Die Reihenfolge entspricht ungefähr der Häufigkeit, mit der sie uns begegnen.

Ein Punkt verdient Erklärung: Warum erzeugt ein PHP-Fehler überhaupt einen 500? Auf Produktivsystemen ist die Fehlerausgabe im Browser abgeschaltet, damit Besucher keine Pfade oder Datenbanknamen zu sehen bekommen. Bricht ein Skript dann mit einem Fatal Error ab, hat der Webserver keine Ausgabe, die er ausliefern könnte, und antwortet mit dem Statuscode 500. Die eigentliche Fehlermeldung landet nicht im Browser, sondern im Error-Log. Deshalb führt jede ernsthafte Fehlersuche zuerst dorthin.

Wie finden Sie die Ursache in fünf Schritten?

Die Schritte sind nach Wahrscheinlichkeit und Risiko geordnet: Zuerst kommen die Prüfungen, die am häufigsten treffen und nichts kaputt machen können. Legen Sie trotzdem vor jeder Änderung eine Sicherung von Dateien und Datenbank an.

Schritt 1: Error-Log lesen. Das Log nennt in den meisten Fällen Datei, Zeile und Fehlerart. Bei webhostone finden Sie es im Adminpanel unter Statistiken, Log Dateien und dort beim jeweiligen Projekt unter "Fehler"; die Anleitung Wie finde ich fehlerhafte Aufrufe in der Logdatei? zeigt den Weg. Suchen Sie nach dem Zeitstempel, an dem der Fehler zuletzt auftrat, und lesen Sie den letzten Eintrag davor. "PHP Fatal error: Uncaught Error: Call to undefined function" verweist auf eine fehlende Erweiterung oder eine inkompatible PHP-Version, "Allowed memory size of 134217728 bytes exhausted" auf ein Speicherlimit von 128 MB, "Invalid command" auf die .htaccess.

Schritt 2: .htaccess ausschalten. Benennen Sie die Datei per FTP oder Dateimanager in .htaccess_alt um und laden Sie die Seite neu. Verschwindet der Fehler, liegt die Ursache in der Datei: eine Direktive, die der Server nicht kennt, ein Tippfehler in einer Rewrite-Regel oder ein Block, den ein Plugin unsauber eingetragen hat. Öffnen Sie die Datei, entfernen Sie den zuletzt hinzugekommenen Abschnitt und benennen Sie sie zurück. Wer im Adminpanel NGINX statt Apache als Webserver gewählt hat, kann diesen Schritt überspringen, weil NGINX .htaccess-Dateien nicht auswertet; dafür scheiden solche Regeln dort auch als Ursache aus.

Schritt 3: PHP-Version prüfen. Ist der Fehler nach einem Wechsel der PHP-Version aufgetreten, stellen Sie im Adminpanel für die betroffene Domain die vorherige Version ein; jede Domain kann eine eigene PHP-Version nutzen, sodass Sie den Wechsel projektweise testen können. Läuft die Seite wieder, ist eine Erweiterung nicht kompatibel. Aktualisieren Sie diese Erweiterung oder ersetzen Sie sie, bevor Sie die neue PHP-Version erneut aktivieren. Bleiben Sie nicht dauerhaft auf einer alten Version, denn ohne Sicherheitsupdates wird aus dem Kompatibilitätsproblem ein Sicherheitsproblem.

Schritt 4: Erweiterungen und Theme abschalten. Nennt das Log eine Datei in einem Plugin- oder Theme-Verzeichnis, deaktivieren Sie genau diese Erweiterung. Kommen Sie nicht mehr ins Backend, benennen Sie das Verzeichnis der Erweiterung per FTP um; das System behandelt sie dann als deinstalliert. Ist der Verursacher unbekannt, deaktivieren Sie alle Erweiterungen und schalten sie einzeln wieder zu, bis der Fehler zurückkehrt.

Schritt 5: Dateirechte und Vollständigkeit prüfen. Verzeichnisse brauchen in der Regel die Rechte 755, Dateien 644. Die Rechte 777 sind nicht großzügig, sondern gefährlich: Auf Servern, auf denen Skripte unter dem Benutzer des Kunden laufen, verweigert der Webserver die Ausführung weltweit schreibbarer Skripte und antwortet ebenfalls mit 500. Fehlen nach einem unterbrochenen Update Dateien, laden Sie den Systemkern aus dem Originalpaket erneut hoch, ohne die Konfigurationsdatei und das Upload-Verzeichnis zu überschreiben.

Was ist bei WordPress, TYPO3 und Shopware anders?

WordPress zeigt seit Version 5.2 statt der weißen Seite den Hinweis "Es gab einen kritischen Fehler auf dieser Website" und schickt eine E-Mail mit einem Link in den Wiederherstellungsmodus an die Admin-Adresse. Über diesen Link kommen Sie ins Backend, auch wenn das Frontend einen 500 liefert, und können das fehlerhafte Plugin deaktivieren. Funktioniert die Mail nicht, hilft der FTP-Weg: Das Verzeichnis wp-content/plugins vorübergehend in plugins_alt umbenennen, anmelden, zurückbenennen und die Plugins einzeln aktivieren. Mit den Konstanten WP_DEBUG und WP_DEBUG_LOG in der wp-config.php schreibt WordPress zusätzlich ein eigenes Protokoll nach wp-content/debug.log. TYPO3 protokolliert nach var/log und bietet mit dem Install Tool einen Zugang, der auch dann erreichbar ist, wenn das Backend nicht mehr lädt. Dort lassen sich alle Caches leeren und die Systemumgebung prüfen. Nach einem Deployment sind bei TYPO3 wie bei Shopware fehlende Composer-Abhängigkeiten die häufigste Ursache: Der vendor-Ordner wurde nicht mit übertragen oder mit einer anderen PHP-Version erzeugt. Shopware 6 reagiert außerdem empfindlich auf zu kleine Speicherlimits; ein memory_limit unter 512 MB führt bei Kategorieindizierung und Plugin-Installation regelmäßig zu abgebrochenen Skripten, die als 500 erscheinen.

Wer behebt den HTTP Error 500: Sie oder der Hoster?

Die Antwort hängt davon ab, wo der Fehler entstanden ist und welches Hosting-Modell Sie nutzen. Der Webserver, PHP, die Datenbank und das Betriebssystem sind beim Hoster, Ihre Anwendung und deren Konfiguration bei Ihnen. Die folgende Übersicht zeigt, wie sich das bei webhostone verteilt.

Im Webhosting ist der 500 fast immer ein Anwendungsfehler, den Sie mit den fünf Schritten oben selbst finden. Wenn nicht, hilft der Support beim Lesen des Logs. Beim Managed Server geht der Support einen Schritt weiter und prüft PHP-FPM, Speicherlimits und Dienste direkt auf dem System, weil er es selbst betreibt. Damit die Hilfe schnell greift, sollten Sie bei der Anfrage drei Dinge mitschicken: die betroffene URL, den Zeitpunkt des letzten Fehlers und was unmittelbar davor geändert wurde, etwa ein Update oder eine neue Erweiterung. Erreichbar ist er an Werktagen per Telefon und LiveChat, für Notfälle rund um die Uhr, und die Server stehen seit 1998 ausschließlich in Deutschland.

Wie vermeiden Sie den Fehler 500 nach dem nächsten Update?

Die meisten 500er entstehen bei Änderungen. Vier Gewohnheiten senken das Risiko deutlich. Erstens: Vor jedem Update eine Sicherung anlegen, und zwar von Dateien und Datenbank, damit ein Zurücksetzen in Minuten möglich ist. Zweitens: Updates nacheinander einspielen und zwischendurch die Seite prüfen, statt zehn Plugins auf einmal zu aktualisieren; sonst wissen Sie hinterher nicht, welches den Fehler verursacht hat. Drittens: Vor dem Umschalten der PHP-Version die Kompatibilität aller Erweiterungen prüfen, idealerweise auf einer Kopie der Website unter einer Subdomain, die Sie im Adminpanel anlegen können. Viertens: Das Error-Log gelegentlich auch dann lesen, wenn kein Fehler sichtbar ist. Warnungen über veraltete Funktionen ("Deprecated") kündigen an, was bei der nächsten PHP-Version zum Fatal Error wird. Wenn eine Erweiterung nicht mehr gepflegt wird und deshalb den Wechsel auf eine aktuelle PHP-Version blockiert, ist das ein Grund, sie zu ersetzen, nicht ein Grund, die PHP-Version einzufrieren. Für Fälle, in denen der Umbau Zeit braucht, bietet webhostone als Zwischenlösung eventuell den Langzeitsupport für ältere PHP-Versionen mit weiter gepflegten Sicherheitsupdates. Kontaktieren Sie und gerne hierzu.