HTTP 500 signalisiert, dass der Webserver die Anfrage nicht abgeschlossen hat; ein weißer Bildschirm bedeutet, dass der PHP-Fehler vor seiner Darstellung für den Besucher beendet wurde. Beide Symptome können durch eine Erweiterungs- oder Themenfehler, sowie durch .htaccess, PHP-FPM, Berechtigungs- und Webserver-Konfigurationsprobleme verursacht werden.
HTTP/1.1 500 Internal Server Error
PHP Fatal error
Premature end of script headers
AH01071: Got error 'Primary script unknown'
Der 500-Server ist ein allgemeiner Fehlercode. Der weiße Bildschirm ist der leere Antworttext; der HTTP-Code kann sogar 200 sein. Daher sind der Antwortcode und die Fehlerlog wichtiger als die Browseransicht.
Beschädigte oder nicht unterstützte .htaccess-Direktive auf Apache kann vor dem Start von WordPress 500 erzeugen; die vorhandene Datei sollte vor dem Aktualisieren der Permalink-Regeln gesichert werden.
PHP-fatales Fehler, Speicherauslastung und maximale Ausführungszeit können sowohl 500 als auch leere Seiten erzeugen. Die WordPress-Debug-Protokolldatei sollte gleichzeitig wie die Domain-PHP-Fehlerprotokolldatei überprüft werden.
Erreicht nur das Plugin, der Kurzcode, das Theme-Template oder die große Abfrage, wenn eine bestimmte Seite oder ein bestimmter Prozess einen Fehler zurückgibt. Wenn der gesamte Site betroffen ist, werden PHP-Handler, FPM und Webserver überprüft.
Cloudflare-520/521-ähnliche Fehler in der Zwischenschicht dürfen nicht mit WordPress-500 verwechselt werden. Der Ursprungsserver sollte direkt getestet und die CDN-Schicht getrennt werden.
Das HTTP-Code auf 200 zwingen oder das Fehlerbildschirm verstecken ist keine Lösung. Die Anwendung, PHP- und Webserver-Logdateien sollten durchsucht werden, um herauszufinden, an welchem Layer die Anfrage abgeschnitten wurde.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Der Server hat die Anfrage nicht abgeschlossen und hat einen allgemeinen 500-Fehler zurückgegeben.
Mögliche Ursache: PHP-fatales Fehler, .htaccess, Berechtigungen oder Web-Konfiguration.
Bedeutung: WordPress/PHP wurde ohne Ausgabe beendet.
Mögliche Ursache: Fataler Fehler, Speicherüberlauf oder leeres Template.
Bedeutung: Der FastCGI/PHP-Prozess hat ohne gültigen Header geschlossen.
Mögliche Ursache: Absturz, Timeout, Berechtigung oder falsches PHP-Binär.
Bedeutung: PHP-Hauptspeicherlimit wurde erreicht.
Mögliche Ursache: Schwere Erweiterung, Import, Elementor oder Schleife.
Bedeutung: Die PHP-Ausführung hat die Zeitbegrenzung überschritten.
Mögliche Ursache: Langsame Abfrage, externe API oder große Operation.
Bedeutung: Apache verwendet PHP-Handler, der die .htaccess-php_value-Direktive nicht akzeptiert.
Mögliche Ursache: Legacy .htaccess-Einstellungen mit FPM/FastCGI.
Bedeutung: PHP-FPM kann den gewünschten Skriptpfad nicht finden oder darauf zugreifen.
Mögliche Ursache: Falsche Dokumentenwurzel, Socket oder Berechtigung.
Bedeutung: Der Server ist in einen Umleitungszyklus geraten.
Mögliche Ursache: Falsche .htaccess-, canonical- oder SSL-Regel.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
curl -sSIk https://example.com/
Zeigt den echten HTTP-Code und die Weiterleitungs-Kette an.
tail -n 150 wp-content/debug.log 2>/dev/null
Zeigt WordPress/PHP-fatale Fehlerzeilen an.
tail -n 150 /var/log/apache2/error.log 2>/dev/null
tail -n 150 /var/log/nginx/error.log 2>/dev/null
Zeigt warum die Anfrage des Web-Servers abgelehnt wurde.
cp .htaccess .htaccess.once && mv .htaccess .htaccess.devre-disi
Prüfunglierter Test für beschädigte Rewrite- oder Direktivmöglichkeit.
wp plugin deactivate --all
Es beendet nur vorübergehend alle Plugins in einem Backup und geplanten Test.
wp core verify-checksums
Ermittelt modifizierte oder fehlende WordPress-Kern-Dateien.
Die Grundursache des WordPress-Fehlers ist dieselbe, aber Protokollpfade, PHP-Einstellungsbildschirme und Dienstverwaltung variieren je nach verwendeter Hosting-Infrastruktur.
In cPanel werden 500 Quellen über Metrics > Errors, MultiPHP und File Manager getrennt.
cd /home/KULLANICI/public_html && wp rewrite flush --hardPlesks Domains > Logs und PHP-Einstellungen vereinfachen die Analyse von 500-Fehlern auf Domänenbasis.
plesk repair web example.comAuf einem panellosen Server werden die Webserver, PHP-FPM und WordPress-Protokolle gleichzeitig überwacht.
nginx -t 2>/dev/null || apachectl configtestÜberprüfen Sie den HTTP-Code, finden Sie den Log, trennen Sie die .htaccess- und PHP-Schichten; testen Sie dann die Komponenten in einem kontrollierten Rahmen.
Überprüfen Sie, ob der weiße Bildschirm ein 500er-Fehler oder eine leere 200er-Antwort mit curl ist.
curl -sSIk https://example.com/Vergleichen Sie die gleiche Sekunde im Domain-Fehler-Log, PHP-Log und debug.log.
tail -n 150 wp-content/debug.logDas File vorübig umbenennen, ohne es zu löschen, und das Ergebnis vergleichen.
cp .htaccess .htaccess.onceSchalten Sie das im Log sichtbare Komponenten vorher aus; Gruppenabschaltung sollte die letzte Option sein.
wp plugin list --status=activeÜberprüfen Sie die Version, den FPM-Dienststatus, den Speicher und die Timeout-Werte.
php -v && php -i | grep memory_limitNachdem das Problem behoben wurde, reinigen Sie die Rewrite-Regeln und den Anwendungs-Cache.
wp rewrite flush --hardDer Admin-Speicher, die Dashboard-Erweiterungen und die REST/AJAX-Logs werden untersucht.
curl -sSIk https://example.com/wp-admin/Vorlage, Kurzcode, Produkt-Erweiterung und record-spezifische Daten werden untersucht.
wp post get IDSchließe das neue Plugin via FTP oder WP-CLI und prühe den Log wieder.
wp plugin deactivate EKLENTIÜberprüfen Sie inkompatible Erweiterungen/Themen und fehlende PHP-Erweiterungen.
php -mBestimmen Sie, wo der Loop startet, indem Sie einen direkten Anforderung an den Origin-IP/hosts senden und ihn direkt testen.
curl -sSIk --resolve example.com:443:ORIGIN_IP https://example.com/Der allgemeine HTTP-Code, der anzeigt, dass die Serveranfrage nicht abgeschlossen wurde; der genaue Grund kann im Fehlerprotokoll gefunden werden.
Wenn die PHP-Fehleranzeige geschlossen ist, werden keine Details zum fatalen Fehler angezeigt und eine leere Antwort kann auftreten.
Anstatt zu löschen, ist es sicherer, einen Backup zu erstellen und WordPress dauerhafte Linkregeln vorübergehend umzubenennen und dann neu zu generieren.
Dies ist für Testzwecke möglich, aber es kann die Zahlungs-, Sicherheits- und Cache-Funktionen beeinflussen; das verdächtige Plugin im Log sollte zuerst angegangen werden.
Ja; PHP-Fatal-Fehler, Verbindungstimeout oder schwerer Abfrage 500 kann erstellt werden.
Es hilft nur, wenn die Grenze wirklich niedrig ist. Es sollte keine Speicherlecks oder falschen Schleifen verbergen.
Cloudflare kann einen Ursprungfehler anzeigen oder eigene 52x-Codes erzeugen; der Ursprung muss direkt getestet werden.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.