500 Internal Server Error: Ursachen & Lösung (nginx, Apache)

Was ist HTTP-Fehler 500?

Der HTTP-Fehler 500 (Internal Server Error) bedeutet, dass auf dem Webserver bei der Bearbeitung Ihrer Anfrage etwas kaputtgegangen ist – und der Server nicht gesagt hat, was. Es ist der allgemeinste Serverfehler.

Der HTTP-Standard definiert ihn in einem Satz: „The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request“ (RFC 9110 §15.6.1), also: Der Server ist auf eine unerwartete Bedingung gestoßen, die ihn daran gehindert hat, die Anfrage zu bearbeiten. Anders als bei einem 503 sagt er nichts darüber, ob das Problem vorübergehend ist.

Fast immer ist es ein Bug, eine fehlerhafte Konfiguration oder ein Absturz im serverseitigen Code, nicht etwas, das der Besucher getan hat. Die Behebung muss vom Betreiber oder Administrator der Website kommen.

Wie ein 500-Fehler aussieht

Der Wortlaut hängt vom Server und von der Anwendung ab:

• 500 Internal Server Error — die Standard-Statuszeile
• 500 Internal Server Error mit „nginx“ darunter — nginx' eigene Fehlerseite
• The server encountered an internal error or misconfiguration and was unable to complete your request. — Apaches Standardseite
• Auf dieser Website ist ein kritischer Fehler aufgetreten. — WordPress' Seite bei einem schwerwiegenden Fehler, wie sie auf deutschen Websites erscheint (englisch: „There has been a critical error on this website.“)
• HTTP Error 500.19 - Internal Server Error — IIS, wo die Zahl nach dem Punkt den Grund nennt (500.19: ungültige Konfigurationsdaten)
• Diese Seite funktioniert nicht · example.com kann diese Anfrage momentan nicht verarbeiten. · HTTP ERROR 500 — Chrome, wenn die 500-Antwort keine eigene Seite mitbringt
• Request failed with status code 500 — Axios und anderer JavaScript-Code, der eine API aufruft
• 500. That's an error. — Googles eigene Fehlerseite

500 Internal Server Error bei nginx

Meistens reicht nginx nur einen 500er weiter, den die dahinterliegende Anwendung geliefert hat (PHP-FPM, Node.js, Python); bei PHP-FPM landet PHPs eigene Fehlermeldung im nginx-Log. nginx erzeugt in einigen Fällen aber auch selbst einen 500er. Diese Zeilen im Fehlerprotokoll sind zu suchen:

# What did nginx log?
sudo tail -n 50 /var/log/nginx/error.log

# Look for loops in the loaded config
sudo nginx -T | grep -nE 'try_files|rewrite'

(Quelle: nginx' eigener Code; ein abgestürztes oder überlastetes Backend ergibt 502 oder 504, nicht 500.)

Häufige Ursachen des HTTP-Fehlers 500

Ein 500er kann von Dutzenden serverseitiger Probleme kommen. Die häufigsten:

• Eine defekte .htaccess-Datei — eine ungültige Direktive oder eine fehlerhafte RewriteRule lässt Apache für dieses Verzeichnis und alles darunter mit 500 antworten.
• Fatale PHP-Fehler — Syntaxfehler, nicht abgefangene Ausnahmen oder Aufrufe nicht definierter Funktionen stoppen das Skript.
• PHP-Speicher- oder Zeitlimits — ein Skript, das memory_limit (standardmäßig 128M) oder max_execution_time (30 Sekunden) überschreitet, wird gestoppt.
• php_value-Zeilen auf einem PHP-FPM-Server — sie funktionieren nur mit Apaches mod_php; unter PHP-FPM lehnt Apache sie mit einem 500 ab.
• Falsche Dateiberechtigungen — PHP kann eine eingebundene Datei nicht lesen, oder ein suPHP-/suEXEC-Host weist Dateien zurück, die für alle beschreibbar sind (777). (Eine Datei, die der Webserver selbst nicht lesen kann, ergibt 403.)
• Ein Plugin oder Theme — eine neue oder aktualisierte Erweiterung für WordPress, Joomla oder Drupal, die die ganze Website abstürzen lässt.
• Fehlgeschlagene Datenbankverbindungen — falsche Zugangsdaten, ein gestoppter Datenbankserver oder zu viele Verbindungen.
• Beschädigte Kerndateien — nach einem fehlgeschlagenen Update oder einem unterbrochenen Upload.
• Eine volle Festplatte — der Server kann keine Logs, Sitzungen oder temporären Dateien mehr schreiben.
• nginx' eigene Auslöser — eine Rewrite-Schleife, eine nicht lesbare Passwortdatei oder ein fehlgeschlagenes Schreiben einer temporären Datei (oft eine volle Festplatte); siehe den nginx-Abschnitt oben.

Lösung für Besucher: Was Sie tun können

Wenn Sie einen 500-Fehler auf einer fremden Website sehen, liegt das Problem auf dem Server — nicht bei Ihnen. Es gibt jedoch einige Dinge, die Sie versuchen können, bevor Sie aufgeben.

• Einmal nach einer Minute neu laden (F5 oder Cmd+R auf dem Mac). Viele 500er dauern nur so lange wie ein Deployment oder ein Neustart.
• Prüfen, ob die Website für alle nicht erreichbar ist — der Website-Down-Checker öffnet die Seite von 11 Orten aus, und der HTTP-Header-Checker zeigt den genauen Statuscode, den unser Server erhält.
• Löschen Sie die Cookies der Website oder versuchen Sie es in einem privaten Fenster. Ein defektes Sitzungs-Cookie kann bei manchen Anwendungen dazu führen, dass nur bei Ihnen jede Seite fehlschlägt.
• Später erneut versuchen — die Behebung liegt auf dem Server, geben Sie dem Betreiber Zeit.
• Betreiber informieren, wenn es stundenlang anhält, mit der Seitenadresse und der Uhrzeit, zu der es passiert ist.

Lösung 1: Server-Fehlerprotokolle prüfen

Fehlerprotokolle sind das wichtigste Debugging-Tool für 500-Fehler. Sie zeigen Ihnen genau, was schiefgelaufen ist, einschließlich Dateipfad, Zeilennummer und Fehlermeldung. Prüfen Sie immer zuerst die Logs, bevor Sie etwas anderes versuchen.

# Apache (PHP errors appear here too, as "AH01071: Got error 'PHP message: …'")
sudo tail -n 100 /var/log/apache2/error.log      # Debian/Ubuntu
sudo tail -n 100 /var/log/httpd/error_log        # RHEL/Alma/Rocky

# nginx (PHP errors appear here as "FastCGI sent in stderr")
sudo tail -n 100 /var/log/nginx/error.log

# PHP errors on RHEL-family PHP-FPM
sudo tail -n 100 /var/log/php-fpm/www-error.log

# PHP-FPM process log (pool restarts, pm.max_children)
sudo tail -n 100 /var/log/php8.3-fpm.log         # Debian/Ubuntu

# WordPress debug log (with WP_DEBUG_LOG on)
tail -n 100 /path/to/wordpress/wp-content/debug.log

Lösung 2: .htaccess testen und reparieren

Eine defekte .htaccess-Datei ist eine klassische Ursache für 500er bei Apache: Ein Tippfehler, eine vom Server nicht unterstützte Direktive oder eine fehlerhafte RewriteRule legt das Verzeichnis lahm. Das Fehlerprotokoll von Apache nennt die .htaccess-Datei und die fehlerhafte Direktive, zum Beispiel Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration.

Der schnellste Test besteht darin, die Datei vorübergehend umzubenennen. Lädt die Website danach, war die .htaccess das Problem.

# Rename to disable .htaccess
mv .htaccess .htaccess_backup

# If site loads, regenerate a clean .htaccess
# For WordPress, go to Settings > Permalinks and click Save

Lösung 3: Dateiberechtigungen korrigieren

Berechtigungen verursachen einen 500er, wenn PHP eine eingebundene Datei nicht lesen kann, oder auf suPHP-/suEXEC-Hosts, die für alle beschreibbare Dateien zurückweisen. Üblich sind 644 für Dateien und 755 für Ordner. Verwenden Sie niemals 777: Das ist ein Sicherheitsrisiko und löst auf suEXEC-/suPHP-Hosts von allein einen 500er aus.

# Set correct directory permissions
find /path/to/webroot -type d -exec chmod 755 {} \;

# Set correct file permissions
find /path/to/webroot -type f -exec chmod 644 {} \;

# WordPress wp-config.php (extra security; 440 only if the PHP user owns the file or is in its group)
chmod 440 wp-config.php

Lösung 4: PHP-Speicher- und Ausführungslimits erhöhen

PHP stoppt Skripte, die das Speicherlimit oder die maximale Ausführungszeit überschreiten, und der Besucher bekommt einen 500er. Die Standardwerte, 128M Speicher und 30 Sekunden, sind für aufwendige Seiten oft zu niedrig.

Erhöhen Sie sie dort, wo Ihr Server sie liest. Bei PHP-FPM bearbeiten Sie die php.ini von FPM (zum Beispiel /etc/php/8.3/fpm/php.ini) und laden php-fpm neu; Änderungen in .user.ini können bis zu 5 Minuten brauchen, bis sie greifen.

# Option 1: php.ini (best)
memory_limit = 256M
max_execution_time = 300

# Option 2: .htaccess (Apache with mod_php only; under PHP-FPM these lines cause a 500)
php_value memory_limit 256M
php_value max_execution_time 300

# Option 3: .user.ini (PHP-FPM and other FastCGI setups)
memory_limit = 256M

# Option 4: wp-config.php (WordPress)
define( 'WP_MEMORY_LIMIT', '256M' );

Lösung 5: Plugins und Theme deaktivieren (CMS)

Wenn Sie WordPress, Joomla oder ein anderes CMS verwenden, ist ein fehlerhaftes Plugin oder Theme eine der häufigsten Ursachen für 500-Fehler. Der schnellste Test besteht darin, alle Plugins gleichzeitig zu deaktivieren und sie dann einzeln wieder zu aktivieren.

# Disable all WordPress plugins (via the file system)
cd /path/to/wordpress/wp-content
mv plugins plugins_disabled

# Or with WP-CLI, without loading the plugin that crashes the site
wp plugin deactivate --all --skip-plugins --skip-themes

# Switch to a default theme (installs it if it was deleted)
wp theme install twentytwentyfive --activate --skip-plugins --skip-themes

# Check WordPress's own files, and reinstall them without touching wp-content
wp core verify-checksums
wp core download --skip-content --force

Lösung 6: Datenbankverbindung prüfen und reparieren

Ein 500-Fehler kann auftreten, wenn die Anwendung keine Verbindung zur Datenbank herstellen kann. Dies geschieht, wenn die Zugangsdaten falsch sind, der Datenbankserver abgestürzt ist oder die Verbindungslimits überschritten wurden.

Überprüfen Sie zuerst Ihre Datenbank-Zugangsdaten in der Konfigurationsdatei (wp-config.php für WordPress, .env für Laravel). Testen Sie dann die Verbindung und reparieren Sie bei Bedarf beschädigte Tabellen.

# Test the MySQL connection
mysql -u username -p -h localhost database_name -e "SELECT 1;"

# Check tables (REPAIR only fixes MyISAM/Aria tables; for InnoDB, restore from a backup)
mysqlcheck -u username -p --check --auto-repair database_name

# WordPress: add to wp-config.php, then visit /wp-admin/maint/repair.php
# Remove this line when you're done: the repair page needs no login.
define( 'WP_ALLOW_REPAIR', true );

Lösung 7: PHP-Versionskompatibilität prüfen

Code, der für eine ältere PHP-Version geschrieben wurde, kann auf einer neueren fatale Fehler auslösen (oder umgekehrt). Nach einem PHP-Upgrade sind entfernte Funktionen und geändertes Verhalten die üblichen Verdächtigen; veraltete Funktionen lösen nur Hinweise aus.

Prüfen Sie, welche PHP-Version Ihre Website tatsächlich verwendet. php -v auf der Kommandozeile kann ein anderes PHP anzeigen als das, das Ihre Website nutzt, schauen Sie also auch im Hosting-Panel oder auf einer temporären phpinfo()-Seite nach:

# Command-line PHP (may differ from the site's PHP-FPM)
php -v

# PHP-FPM versions installed (Debian/Ubuntu)
ls /etc/php/

# Modules loaded in the command-line PHP
php -m

Lösung 8: Festplattenspeicher prüfen

Wenn einem Server der Festplattenspeicher (oder die Inodes) ausgeht, kann er keine Logs, temporären Dateien oder Sitzungsdaten mehr schreiben, und Anfragen scheitern mit 500ern.

# Check disk space, and inodes (they can run out too)
df -h
df -i

# What's using the space?
sudo du -sh /var/log /tmp

# Free space without deleting the log you're reading
sudo find /var/log -name "*.gz" -mtime +14 -delete
sudo journalctl --vacuum-size=200M

500 vs. 502 vs. 503 vs. 504: Was ist der Unterschied?

Der entscheidende Unterschied: 500 = der Server ist intern abgestürzt. 502 = der Proxy hat ungültige Daten vom Backend erhalten. 503 = der Server ist aktiv, aber ausgelastet. 504 = der Proxy hat das Warten aufgegeben. Den genauen Statuscode, den Ihr Server zurückgibt, prüfen Sie mit dem HTTP-Header-Checker von DNS Robot.

Ist der Fehler stattdessen ein 502, kann die Anwendung in Ordnung sein, und das Problem liegt zwischen Proxy und Anwendung. Unser Leitfaden zu 502 Bad Gateway behandelt diesen Fall.

Wie 500-Fehler die SEO beeinflussen

Googles eigene Dokumentation beschreibt, was passiert (Google-Dokumentation zu den Crawlern):

• Das Crawling verlangsamt sich. Bei 5xx-Fehlern senkt Google die Crawling-Rate der Website, im Verhältnis zur Zahl der URLs, die Fehler liefern.
• Indexierte Seiten bleiben zunächst. Bereits indexierte URLs werden eine Zeit lang behalten, URLs, die dauerhaft einen Serverfehler liefern, werden aber entfernt.
• Die Erholung verläuft schrittweise. Sobald der Server wieder mit 2xx antwortet, erhöht Google das Crawling allmählich.
• Verwenden Sie 503 für geplante Ausfallzeiten von ein bis zwei Tagen, mit einem Retry-After-Header (Google), damit der Ausfall als vorübergehend gilt (503-Leitfaden).

So verhindern Sie 500-Fehler

Vorbeugung ist immer besser als Debugging. Befolgen Sie diese Best Practices, um das Risiko von 500-Fehlern auf Ihrer Website zu minimieren.

• Uptime-Monitoring einrichten — Verwenden Sie Tools wie UptimeRobot oder Pingdom, um Ihre Website alle 1-5 Minuten zu überprüfen. Erhalten Sie sofortige Benachrichtigungen, wenn ein 500-Fehler auftritt.
• Änderungen immer in einer Staging-Umgebung testen — Deployen Sie niemals direkt in die Produktion. Testen Sie Plugin-Updates, PHP-Upgrades und Konfigurationsänderungen zuerst in einer Staging-Umgebung.
• Versionskontrolle (Git) verwenden — Committen Sie jede Änderung, damit Sie ein fehlerhaftes Deployment sofort mit einem einzigen Befehl rückgängig machen können.
• Ordnungsgemäße Fehlerbehandlung implementieren — Kapseln Sie Datenbankabfragen und API-Aufrufe in Try-Catch-Blöcken. Protokollieren Sie vollständige Stack-Traces serverseitig für jeden Fehler.
• Festplattenspeicher und Serverressourcen überwachen — Richten Sie Benachrichtigungen für Festplattennutzung über 80 %, hohe CPU-Last und Speicherdruck ein.
• Software aktuell halten — Veraltete CMS-Versionen, Plugins und Server-Software enthalten bekannte Bugs, die Abstürze verursachen.
• Automatisierte Backups pflegen — Testen Sie Ihre Wiederherstellungsprozedur regelmäßig. Ein Backup, das Sie nie getestet haben, ist kein Backup.
• PHP-Limits angemessen setzen — Konfigurieren Sie memory_limit und max_execution_time basierend auf Ihrer tatsächlichen Arbeitslast, nicht auf Standardwerten.
• CI/CD-Pipelines verwenden — Automatisieren Sie Tests vor dem Deployment. Wenn Tests fehlschlagen, sollte das Deployment nicht fortgesetzt werden.