500 Internal Server Error: Bedeutung und Lösung des Fehlers

Sie klicken auf die Schaltfläche, um eine Bestellung zu bezahlen, und statt der nächsten Seite erscheint ein fast leerer Bildschirm: „500 Internal Server Error“ in fetter Schrift, darunter „nginx“. Auf einer anderen Website zeichnet Chrome seine eigene Seite, „Diese Seite funktioniert nicht“, mit „HTTP ERROR 500“ am unteren Rand. In einer App lauten die Worte anders, etwa „The call failed on the server; see server log for details“, aber die Zahl ist dieselbe.

Im Folgenden: was der Code bedeutet und warum er so wenig sagt, wer die Seite erzeugt hat, die Sie sehen, wie sich ein 500 von 502, 503 und 504 unterscheidet und was Besucher, Website-Betreiber und Skripte dagegen tun sollten.

Was bedeutet 500 Internal Server Error?#

Der HTTP-Standard definiert den Code in einem Satz: Der Server ist auf „eine unerwartete Bedingung gestoßen, die ihn daran gehindert hat, die Anfrage zu erfüllen“ (RFC 9110, Abschnitt 15.6.1). Jeder Code, der mit 5 beginnt, ist ein Serverfehler; der Server weiß also, dass der Fehler bei ihm liegt. 500 ist der Code, den er verwendet, wenn kein genauerer passt.

Deshalb sagt die Meldung so wenig. Der Webserver, das Programm, das Verbindungen annimmt, etwa nginx oder Apache, hat Ihre Anfrage an die Anwendung weitergereicht, die die Seiten baut, und irgendwo in dieser Arbeit ist die Anwendung gescheitert. Der Webserver weiß nur, dass keine brauchbare Seite zurückkam, also antwortet er mit 500; die Einzelheiten stehen in einem Fehlerprotokoll (Error-Log), das nur der Betreiber der Website lesen kann.

Wer hat die Seite geschickt, die Sie sehen?#

Das Aussehen der Fehlerseite verrät, welches Programm aufgegeben hat und wie viel von der Website noch läuft.

Die letzte Zeile haben wir mit einem kleinen Testserver auf unserem eigenen Computer nachgestellt, der jede Anfrage mit Status 500 und ohne Seite beantwortet, geöffnet in Chromium 145: genau dieser Aufbau, mit dem Namen unseres Hosts in der mittleren Zeile und einer Schaltfläche Neu laden. Die deutschen Texte von Überschrift, Host-Zeile und Schaltfläche stehen in der Übersetzungsdatei von Chromium (components_strings_de.xtb); „HTTP ERROR 500“ fügt der Code hinzu, und es wird nie übersetzt.

Wie entsteht ein 500, Schritt für Schritt?#

1. Ihr Browser schickt die Anfrage mit der Adresse, Ihren Cookies und eventuellen Formulardaten.
2. Der Webserver reicht sie an die Anwendung weiter, die Seiten im Moment des Aufrufs baut; statische Dateien liefert er selbst aus.
3. Die Anwendung scheitert mittendrin: ein nicht abgefangener Fehler, eine Datenbank, die nicht antwortet, eine fehlerhafte Konfigurationszeile, ein Skript über seinem Speicherlimit.
4. Etwas antwortet mit 500: die eigene Seite der Anwendung, wenn sie den Fehler abgefangen hat, die allgemeine Seite des Webservers oder eine leere Antwort, wenn sie abgestürzt ist.
5. Ihr Browser zeigt, was er bekommen hat, oder seinen eigenen Bildschirm „Diese Seite funktioniert nicht“, wenn die Antwort leer war.

Was ist der Unterschied zwischen 500, 502, 503 und 504?#

Alle vier sind Serverfehler, aber sie benennen unterschiedliche Teile, die versagt haben. Ein 500 sagt, dass die Anwendung selbst gescheitert ist; 502, 503 und 504 beschreiben ein Gateway, den Server vor der Anwendung (ein Reverse-Proxy, ein Load Balancer oder ein CDN), der die Anfragen der Besucher weiterleitet.

Derselbe Absturz kann als einer der beiden Codes erscheinen: Stirbt die Anwendung, bevor sie antwortet, und steht nginx davor, meldet nginx einen 502; fängt die Anwendung den Fehler ab und antwortet selbst, sehen Sie einen 500. 502 Bad Gateway: Bedeutung und Lösung des Fehlers behandelt die Gateway-Seite.

Liegt ein 500-Fehler an Ihnen?#

Fast nie, und nie an Ihrer Verbindung: Die Anfrage ist angekommen. Ihre Anfrage kann trotzdem der Auslöser sein, etwa ein Formularwert, den der Code nicht erwartet hat, oder ein sehr großer Upload; der Fehler gehört der Website, tritt aber nur bei Ihnen auf, bis die Website ihn behebt. Auch ein veraltetes Cookie oder eine alte Anmeldesitzung kann eine Anwendung durcheinanderbringen; deshalb beseitigt das Löschen der Cookies der Website manchmal einen 500, den Neuladen nicht beseitigt.

Ein Proxy oder VPN verursacht ebenfalls keinen 500: Der Fehler entsteht, nachdem die Anfrage die Website erreicht hat, also lässt ihn auch eine andere IP-Adresse nicht verschwinden.

Was können Sie als Besucher tun?#

1. Laden Sie einmal neu und warten Sie dann ein paar Minuten. Drücken Sie F5 oder die Schaltfläche Neu laden auf der Fehlerseite von Chrome; danach erhöhen Sie nur die Last auf einem Server, der ohnehin kämpft.
2. Probieren Sie eine andere Seite derselben Website. Lädt die Startseite, scheitert aber die Kasse, läuft die Website, und eine Funktion ist kaputt.
3. Öffnen Sie die Website auf dem Smartphone über mobile Daten. Scheitert sie auch dort, ist der Ausfall allgemein, und nichts auf Ihrem Computer wird daran etwas ändern. Den Ausgang mit einem Proxy oder VPN zu wechseln ist derselbe Test; mit einem Residential-Proxy wiederholen Sie ihn in einer Minute aus einem anderen Land.
4. Prüfen Sie die Statusseite der Website. Größere Dienste kündigen Störungen dort an; eine App, die weiter einen 500 zeigt, stößt über ihre API auf dieselbe Störung.
5. Löschen Sie die Cookies der Website, aber nur, wenn der Fehler eine Wartezeit überdauert und Ihnen über mehrere Seiten folgt. In Chrome am Computer: Dreipunkt-Menü > Browserdaten löschen, einen Zeitraum wählen, Cookies und andere Websitedaten ankreuzen, dann Daten löschen (die Schritte bei Google). Das meldet Sie von Websites ab, lassen Sie es also bis zuletzt.
6. Melden Sie den Fehler mit der genauen Adresse, der Uhrzeit, dem, was Sie angeklickt haben, und jeder Anfrage-ID, die auf der Seite steht.

Den Router neu zu starten, DNS-Server zu wechseln oder den Browser neu zu installieren bringt hier nichts: Sie wirken auf den Teil des Wegs, der schon funktioniert hat.

Wenn es Ihre Website ist: Wie finden Sie die Ursache?#

Ein 500 ist für Besucher absichtlich vage, im Protokoll aber nie. Gehen Sie die Punkte der Reihe nach durch; die meisten 500-Fehler enden bei den ersten drei.

1. Lesen Sie zuerst das Fehlerprotokoll. Apache nennt sein Fehlerprotokoll die erste Stelle, an der man bei einem Problem nachsieht; die Direktive ErrorLog legt den Speicherort fest, unter Unix meist eine Datei namens error_log (Apache-Dokumentation zu Protokollen). nginx schreibt standardmäßig nach logs/error.log, PHP in seine eigene error_log-Datei oder in das Protokoll des Webservers. Suchen Sie die Minute des 500: PHP Fatal error: Allowed memory size of 134217728 bytes exhausted ist ein Speicherproblem, Apaches Premature end of script headers ein Skript, das gestorben ist, bevor es eine Seite geschickt hat, und ein Stacktrace nennt Datei und Zeile.
2. Machen Sie die letzte Änderung rückgängig. Ein 500, der direkt nach einem Update, einem Deployment oder einer Änderung an der Konfiguration beginnt, ist diese Änderung, bis das Gegenteil bewiesen ist; setzen Sie sie zuerst zurück.
3. Plugins und Themes. Der Leitfaden von WordPress zum Internal Server Error rät, alle Plugins zu deaktivieren und auf ein Standard-Theme zu wechseln (Häufige WordPress-Fehler); kommt die Website zurück, aktivieren Sie sie nacheinander wieder.
4. Die Datei .htaccess. Unter Apache wird diese Konfigurationsdatei pro Ordner bei jeder Anfrage gelesen, eine einzige fehlerhafte Zeile bricht also jede Seite. Der WordPress-Leitfaden nennt eine beschädigte .htaccess die wahrscheinlichste Ursache: Benennen Sie sie in .htaccess_old um und lassen Sie sie, wenn die Website lädt, unter Einstellungen > Permalinks neu erzeugen. Eine Direktive, die AllowOverride nicht erlaubt, oder ein Syntaxfehler erzeugt einen Serverfehler, dessen Grund im Protokoll steht.
5. PHP-Limits. PHP stoppt ein Skript, das mehr als memory_limit belegt (standardmäßig 128M), und beendet eines, das länger läuft als max_execution_time (standardmäßig 30 Sekunden auf einem Webserver). Erhöhen Sie das Limit in der php.ini oder in den PHP-Einstellungen des Hosters, aber behandeln Sie einen stetig wachsenden Bedarf als Bug.
6. Berechtigungen und Abhängigkeiten. Der Webserver läuft unter einem eigenen Benutzer: Ein Skript, das er nicht lesen kann, oder ein Ordner, in den er nicht schreiben darf, endet in einem 500 statt in einer klaren Meldung. Dasselbe gilt für eine ausgefallene Datenbank, einen abgelaufenen API-Schlüssel oder ein abgelaufenes Zertifikat und eine volle Festplatte; das steht im eigenen Protokoll der Anwendung.
7. Ihr Hosting-Panel. Bei Shared Hosting zeigt das Panel das Protokoll: In cPanel listet die Oberfläche Errors (Fehler) unter Metrics (Metriken) bis zu 300 der neuesten Einträge. Weisen sie auf den Server selbst hin, oder scheitert jede Website auf dem Server, eröffnen Sie beim Hoster ein Ticket mit Uhrzeit, URL und den Protokollzeilen.

Die Crawler von Google werden bei 5xx-Fehlern langsamer und lassen URLs, die weiter scheitern, irgendwann fallen; ein 500, der bleibt, kostet also Rankings. Eine Überwachung, die jede Minute ein paar wichtige Seiten abruft, warnt Sie zuerst; Prüfungen von ein paar festen, dedizierten Adressen über einen Datacenter-Proxy lassen sich auf dem Server freigeben und aus Ihrer Fehlerstatistik heraushalten.

Wie sollte ein Skript oder Scraper mit einem 500 umgehen?#

Behandeln Sie einen 500 als vorübergehend, aber nicht als kostenlos: Wiederholen Sie ein paarmal mit wachsenden Pausen und geben Sie diese Adresse dann auf.

• Begrenzen Sie die Wiederholungen und verlängern Sie die Pause. Eine Sekunde, dann zwei, dann vier, und nach drei oder vier Versuchen aufhören; eine Schleife, die auf dieselbe Adresse einhämmert, verschlimmert den Ausfall.
• Ein 500 unter Last heißt: langsamer werden. Beginnt die Website, 500-Fehler zu liefern, während Ihr Crawler mit hoher Parallelität läuft, senken Sie die Zahl paralleler Anfragen. Wechseln Sie nie die IP-Adresse, um durchzukommen: Die Anwendung scheitert für alle.
• Protokollieren Sie den Antwortinhalt. Ein JSON-Fehler, eine Anfrage-ID oder ein Stacktrace sagt, ob der Fehler bei Ihnen liegt (ein falscher Parameter) oder bei der Website, und unterscheidet einen echten 500 von einer Sperre: Ein 403 oder ein 429 mit einer Prüfseite ist eine Entscheidung über Ihren Datenverkehr, kein Serverfehler. 429 Too Many Requests: Was ist ein Rate-Limit-Fehler? behandelt diese Fälle.

Das Beispiel unten setzt die Regeln mit Pythons Requests-Bibliothek um. Wir haben es gegen unseren lokalen Testserver laufen lassen, dessen Seite /flaky zweimal 500 und dann 200 liefert und dessen Seite /text immer 500 liefert (Python 3.13, Requests 2.34):

import time

import requests

URL = "http://127.0.0.1:18500/flaky"  # unser lokaler Testserver; tragen Sie hier die gewünschte Seite ein
PROXIES = None  # oder {"http": "http://user:pass@pr.proxynet.io:8000", "https": "http://user:pass@pr.proxynet.io:8000"}
ATTEMPTS = 4  # eine Obergrenze: ein 500, der anhält, ist das Problem der Website, nicht Ihres


def fetch(url):
    wait = 1.0
    for attempt in range(1, ATTEMPTS + 1):
        r = requests.get(url, proxies=PROXIES, timeout=20)
        if r.status_code in (403, 429):
            raise RuntimeError(f"{url}: HTTP {r.status_code} is a block or a rate limit, not a server error")
        if r.status_code < 500:
            return r
        print(f"attempt {attempt}: HTTP {r.status_code} {r.reason}, body: {r.text.strip()[:60]!r}")
        if attempt < ATTEMPTS:
            time.sleep(wait)
            wait *= 2  # 1 s, 2 s, 4 s
    raise RuntimeError(f"{url}: HTTP 500 after {ATTEMPTS} attempts, skip it and come back later")


r = fetch(URL)
print(f"HTTP {r.status_code}: {r.text.strip()}")

Ausgabe für /flaky:

attempt 1: HTTP 500 Internal Server Error, body: '{"error":"database connection lost"}'
attempt 2: HTTP 500 Internal Server Error, body: '{"error":"database connection lost"}'
HTTP 200: ok

Für /text werden vier Versuche ausgegeben, und das Skript endet mit:

RuntimeError: http://127.0.0.1:18500/text: HTTP 500 after 4 attempts, skip it and come back later

Über einen Proxy tragen Sie in PROXIES die Adresse aus dem Endpoint-Generator ein; die Logik ändert sich nicht, weil der 500 vom Ziel kommt. Welche Codes Sie wiederholen und bei welchen Sie aufhören sollten, von 403 bis 504, steht in HTTP-Statuscodes beim Web Scraping: 403, 407, 429, 503.

Wo Ihnen ein 500 begegnen kann#

• Ein schlichtes „500 Internal Server Error“ mit „nginx“ darunter auf einer kleinen Website, oft direkt nach einem Update ihres CMS oder von PHP.
• In einer App wie Discord oder einer Banking-App, deren Bildschirme die eigene API des Dienstes aufrufen und die Zahl zeigen, die sie zurückgegeben hat.
• Die Meldung „The call failed on the server; see server log for details“ in einer Java-Webanwendung: der feste Text, den das GWT-Framework mit einem 500 schickt, wenn ein Serveraufruf scheitert.

Häufige Fehler#

• Jede Sekunde neu laden. Die Anwendung scheitert bereits; mehr Anfragen verlangsamen sie weiter und verdecken den Moment, in dem sie sich erholt.
• Betreiber: memory_limit erhöhen, ohne das Protokoll zu lesen. Ein höheres Limit verbirgt ein Speicherleck eine Woche lang, dann ist der 500 zurück.
• Betreiber: Besuchern den Stacktrace zeigen. Ein Debug-Modus, der in der Produktion eingeschaltet bleibt, druckt Dateipfade und Datenbankdetails auf die Fehlerseite.
• Scraper: bei einem 500 die IP wechseln. Die Website scheitert für jede Adresse; wiederholen Sie mit Pausen oder überspringen Sie die Seite.

Entscheidungshilfe#

Häufige Fragen#

Ist ein 500 Internal Server Error mein Fehler?#

Nein. Der Code bedeutet, dass die eigene Software der Website bei der Verarbeitung Ihrer Anfrage gescheitert ist; Ihre Verbindung und Ihr Browser haben ihren Teil erledigt. Ihre Eingabe kann einen vorhandenen Bug auslösen, aber ihn zu beheben bleibt Aufgabe der Website.

Wie lange dauert ein 500-Fehler?#

Es gibt keine feste Dauer. Ein Neustart oder ein kurzer Aussetzer der Datenbank ist in Sekunden vorbei; ein fehlerhaftes Update oder eine defekte .htaccess-Datei bleibt, bis der Betreiber es bemerkt und behebt.

Was bedeutet „500 Internal Server Error nginx“?#

nginx ist das Webserver-Programm vor der Website, und die Seite ist seine allgemeine Fehlerseite: Die Anwendung hinter nginx ist gescheitert, und nginx hatte keine richtige Antwort zum Weitergeben.

Was bedeutet „The call failed on the server; see server log for details“?#

Es ist der feste Text, den das GWT-Framework, das manche Java-Webanwendungen verwenden, mit Status 500 schickt, wenn eine Anfrage an den Server einen Fehler auslöst. Das Protokoll, auf das er verweist, können nur die Betreiber der Website lesen; für Sie ist es ein gewöhnlicher 500.

Warum zeigt Discord oder eine andere App einen 500-Fehler?#

Apps holen ihre Daten über die API des Dienstes, und antwortet sie mit 500, zeigt die App die Zahl. Die Störung liegt beim Dienst; prüfen Sie seine Statusseite und versuchen Sie es später.

Behebt das Löschen der Cookies einen 500-Fehler?#

Manchmal, wenn die Anwendung an einem veralteten Cookie oder einer alten Sitzung scheitert. Versuchen Sie es erst nach Neuladen und Warten; die meisten 500-Fehler liegen auf dem Server, und das Löschen von Daten ändert daran nichts.

Fazit#

Ein 500 Internal Server Error bedeutet, dass die Anwendung der Website auf ein Problem gestoßen ist, mit dem sie nicht umgehen konnte, und der Server statt der Seite einen allgemeinen Fehler geschickt hat. Besucher laden einmal neu, warten und testen von einem anderen Gerät; Betreiber lesen das Fehlerprotokoll und arbeiten sich zurück durch die letzte Änderung, Plugins, .htaccess, PHP-Limits und Berechtigungen; Skripte wiederholen mit wachsenden Pausen und erzwingen nie etwas mit neuen Adressen. Die Proxy-Typen vergleichen Sie auf unserer Proxy-Seite.