Türkei (Türkisch)
Germany (German)
Worldwide (English)
AnwendungPHP-fatales Fehler und Plugin-Konflikte
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
HTTP 500 signalisiert, dass bei der Verarbeitung der Anfrage durch das Anwendungs- oder Webserverprogramm ein unerwarteter Fehler aufgetreten ist. Auf Plesk kann das gleiche 500-Fenster auftreten, wenn ein fehlerhafter .htaccess, ein PHP-Fatal-Fehler, eine Speichergrenze, ein FastCGI-Timeout, ein Dateizugriff oder eine Webkonfiguration vorliegt.
500 Internal Server Error
Allowed memory size of 134217728 bytes exhausted
mod_fcgid: read data timeout in 45 seconds
Premature end of script headers: index.php
Request exceeded the limit of 10 internal redirectsDer 500-Code identifiziert keinen einzelnen Fehler. Der Server hat die Anfrage erhalten, konnte das Verfahren jedoch nicht abschließen. Daher sollte anstelle des Änderns des Fehlerbildschirms der Seite die vollständige Meldung und die Zeitstempel in der Plesk-Domain-Log gefunden werden.
Das Hinzufügen von PHP-Handler-unsupporteten php_value- oder php_flag-Zeilen zu .htaccess kann die Konfigurationsanalyse stoppen.
Die Meldung „Allowed memory size exhausted“ zeigt an, dass die Anwendung den für die Domäne definierten memory_limit-Wert verbraucht hat. Die Erweiterung oder der Prozess, der ihn verbraucht, sollte vor der Erhöhung des Limits untersucht werden.
mod_fcgid-Lesezeitlimit und Premature end of script headers-Nachrichten deuten darauf hin, dass der FastCGI-Prozess ohne Antwort oder die Zeitbegrenzung überschritten wurde.
Too many internal redirects können aufgrund fehlerhafter HTTP→HTTPS-Weiterleitung, www-Weiterleitung oder WordPress-rewrite-Regeln, die einen Loop erzeugen, auftreten.
Das Öffnen von display_errors in der Produktion kann Dateipfade und sensible Informationen den Besuchern offenlegen. Fehlerdetails sollten aus den Domain-Logfiles oder einem temporären Testumgebung, die nur dem Administrator-IP zugänglich ist, abgerufen werden.
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: Bei der Verarbeitung der Anfrage durch den Server ist ein unerwarteter Fehler aufgetreten.
Mögliche Ursache: PHP-fatales Fehler, Web-Konfiguration, Berechtigungs- oder Handler-Probleme.
Bedeutung: Der PHP-Prozess hat den memory_limit-Wert verbraucht.
Mögliche Ursache: Schwere Erweiterung, große Datenverarbeitung, endloser Schleife oder niedriger Grenzwert.
Bedeutung: Die Daten konnten nicht innerhalb der Frist vom FastCGI-Prozess abgerufen werden.
Mögliche Ursache: Langlaufender PHP-Prozess, SQL-Verspätung oder niedriger FcgidIOTimeout.
Bedeutung: CGI/FastCGI-Prozess beendet ohne gültige HTTP-Header zu erzeugen
Mögliche Ursache: Fatales Fehler, Segfault, Berechtigungs- oder Wrapper-Probleme.
Bedeutung: Der verwendete Handler unterstützt die .htaccess php_value-Direktive nicht.
Mögliche Ursache: Die Apache-Mod_php-Regel wurde mit PHP-FPM/FastCGI verwechselt.
Bedeutung: Die Anfrage ist in eine Umleitungs-Schleife auf dem Server geraten.
Mögliche Ursache: Konfliktierende HTTPS, www, Sprach- oder CMS-Umleitungsregeln.
Bedeutung: Der Web-Server kann die Datei nicht lesen oder ausführen.
Mögliche Ursache: Falsche Besitzrechte, 000 Berechtigungen, Zugriff auf das Elternverzeichnis oder SELinux.
Bedeutung: Ein PHP-Code hat eine unbehandelte oder unbehaltene Exception ausgelöst.
Mögliche Ursache: Inkompatibles PHP-Version, fehlende Klasse, beschädigtes Datei oder Update.
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.
tail -n 200 /var/www/vhosts/system/example.com/logs/error_log
tail -n 100 /var/www/vhosts/system/example.com/logs/proxy_error_logZeigt PHP, Apache- und Proxy-Meldungen bei HTTP 500 an.
curl -skIL --max-redirs 15 https://example.com/Der Loop von HTTPS- und www-Regeln wird mit Location-Überschriften angezeigt.
cp -a /var/www/vhosts/example.com/httpdocs/.htaccess /root/htaccess-example.com.bak
grep -nE 'php_value|php_flag|RewriteRule|Redirect' /var/www/vhosts/example.com/httpdocs/.htaccessDie riskanten Direktiven und Anweisungen ohne das File zu löschen auflisten.
plesk bin domain --info example.com | grep -Ei "PHP|Hosting"
grep -R "memory_limit" /var/www/vhosts/system/example.com/conf/ 2>/dev/null | tailDomain-Konfiguration hilft bei der Untersuchung von verwandten Informationen PHP
namei -l /var/www/vhosts/example.com/httpdocs/index.php
stat /var/www/vhosts/example.com/httpdocs/index.phpZeigt die Zugriffsberechtigungen aller Ordner an, die zur Datei führen.
plesk repair web example.com
plesk repair fs example.comDomain-Web-Konfiguration und Plesk erwartete Dateisystemstruktur-Check
php -l /var/www/vhosts/example.com/httpdocs/index.phpÜberprüft das Parse-Fehler-Problem in einer bestimmten PHP-Datei, ohne die Anwendung auszuführen.
Zuerst den Fehlercode finden; dann die .htaccess-, PHP-, Berechtigungs- und Webkonfigurationslayer nacheinander isolieren.
Notieren Sie die vollständige URL, die Zeit und den Prozess, der den 500-Fehler auslöst. Diese Informationen sind notwendig, um die korrekte Anfrage in der Log-Suche zu finden.
Stattdessen auf das erste bedeutungsvolle fatale, ungültige Befehls- oder Zugriffsanforderungsmeldung in der Kette fokussieren.
tail -n 200 /var/www/vhosts/system/example.com/logs/error_logDas File sichern. Neue hinzugefögte PHP- oder Rewrite-Zeilen einzeln isolieren; das File direkt nicht löschen.
Wenn es einen fatalen Fehler oder einen Speicherfehler gibt, überprüfen Sie die Kompatibilität der ausgewählten PHP-Version mit der Erweiterung, dem Thema und der Anwendung.
Verwenden Sie den Plesk-Reparaturbefehl zunächst für interaktive Steuerung; führen Sie umfassende automatische Reparatur ohne Ergebnisse nicht durch.
plesk repair web example.comNachdem die Seite geladen wurde, stellen Sie sicher, dass keine neue fatale Zeile erscheint und dass cron und formartige dynamische Operationen funktionieren.
curl -skI https://example.com/Im wp-content-Ordner wird die Fehlerprotokolldatei auf Plugin- und Themes-Kompatibilität überprüft. Plugins können entweder aus der Datenbank oder aus dem Dateinamen in einem kontrollierten Wege deaktiviert werden.
Neue Direktiven können mit dem Handler inkompatibel sein. Vergleichen Sie Backups und trennen Sie php_value und Rewrite-Regeln.
memory_limit, max_execution_time, Uploadlimits und die Unterstützung der Anwendung für die Verarbeitung in Teilen werden bewertet.
Plesk-Richtlinie, Cloudflare Flexible SSL und CMS-Site-URL-Einstellungen werden gemeinsam überprüft.
curl -skIL https://example.com/Anders als Domain-Fehler; sw-cp-server, sw-engine und /var/log/plesk/panel.log werden überprüft.
Es gibt keine einzelne Ursache. .htaccess-Inkompatibilität, PHP-Fatal-Fehler, Speichergrenze, FastCGI-Timeout und Berechtigungsprobleme sind die häufigsten Gruppen.
Nein. Es ist ein Sicherheitsrisiko und versteckt die Eigenalleerfrage. Die erwartete Eigenalleer- und Berechtigungsstruktur von Plesk sollte aufrechterhalten werden.
Finden und optimieren Sie, welcher URL und Code den Speicher verbraucht. Wenn die Last wirklich hoch ist, kann ein kontrollierter Anstieg der Serverkapazität in Einklang mit der Serverkapazität vorgenommen werden.
Backup kann für eine vorübergehende Diagnose verwendet werden; jedoch werden Sicherheit, Permalink und Umleitungsregeln deaktiviert, daher ist es keine dauerhafte Lösung.
Auf Linux basiert die error_log- und proxy_error_log-Datei normalerweise im Verzeichnis /var/www/vhosts/system/alanadi/logs/. Sie können auch vom Domains > Logs-Bildschirm im Panel aus angezeigt werden.
Inkompatible Code kann gefixt werden, aber zufällige Versionswechsel können neue Probleme verursachen; Anwendung und Erweiterungsanforderungen sollten überprüft werden.
Überprüft die Dateisystemintegrität und die Besitzstruktur von Plesk. Die Ausgabe der Befehlszeilen sollte sorgfältig in der Produktion überprüft 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.