Türkei (Türkisch)
Germany (German)
Worldwide (English)
PHP-SchichtLSAPI, PHP-FPM oder lsphp-Prozesse
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
Wenn die Website 503 Service Unavailable zurückgibt, liegt das Problem oft in der Verbindung zwischen Apache und dem PHP-Prozessor, PHP-FPM-Pool, CloudLinux LVE-Limit oder intensiven PHP-Prozessen. Dieser Expertenleitfaden diagnostiziert Einzelsiten- und gesamte Server-Szenarien separat.
[proxy_fcgi:error] AH01079: failed to make connection to backend
mod_lsapi: Connect to backend failed: connect to lsphp failed: 110
Service Unavailable
The server is temporarily unable to service your request.HTTP 503 signalisiert, dass der Server die Anfrage vorübergehend nicht bearbeiten konnte. Dies bedeutet nicht unbedingt, dass der Domainnamen oder der DNS fehlerhaft ist; der Webserver kann funktionieren, während er den PHP-Hintergrund nicht erreichen kann.
Wenn nur ein cPanel-Konto betroffen ist, pröfen Sie zunächst die PHP-Version, die Handlerauswahl, den PHP-FPM-Pool, die .htaccess-Regeln und die CloudLinux-Ressourcengeschichte des Kontos.
Wenn alle PHP-Sites auf dem Server gleichzeitig einen 503 zurückgeben, überprüfen Sie den Apache/LiteSpeed-Dienst, die PHP-FPM-Dienste, den globalen Prozesslimit, den Speicherdruck, die Dateideskriptoren und die kürzlichen EasyApache-Updates.
Verbindung zu lsphp fehlgeschlagen: 110, was normalerweise eine Verbindungstimeout bedeutet. Der lsphp-Prozess antwortet nicht, wird nicht erstellt oder der CloudLinux/Limits-Schicht blockiert den neuen Prozess.
Wenn bei der Öffnung statischer HTML-Dateien PHP-Dateien einen 503-Statuscode zurückgeben, liegt das Problem wahrscheinlich beim PHP-Handler-Schicht und nicht beim Netzwerk. Diese Unterscheidung verhindert unnötige DNS-, SSL- oder Firewall-Eingriffe.
Das Neustarten des Services kann den Zugriff auf die Website vorübergehend ermöglichen; jedoch tritt das Problem wieder auf, wenn die Fehler durch intensive Erweiterungen, fehlerhaftes PHP-Code, Bot-Verkehr oder unzureichende Prozessgrenzen verursacht werden. Die Lösung gilt nur dann als dauerhaft, wenn die Protokolle und die Quellengeschichte gemeinsam überprüft 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: Der Web-Server hat den Antrag vorübigzeitig nicht bearbeiten können.
Mögliche Ursache: PHP-Hintergrundprozess ist geschlossen, Prozesslimit ist voll, Anwendung ist gesperrt oder Wartung/Wiederherstellung ist im Gange.
Bedeutung: Apache mod_lsapi konnte nicht rechtzeitig zur lsphp-Prozess verbinden.
Mögliche Ursache: Zeigt blockierten lsphp, LVE-Grenzwert, intensiven Prozess, Speicherdruck oder LSAPI-Verbindungsproblem an.
Bedeutung: LSAPI hat wiederholt versucht, sich mit dem Backend zu verbinden und die Wartezeit überschritten.
Mögliche Ursache: Die Anwendung ist für eine lange Zeit gesperrt, PHP-Prozesse sind voll oder der entfernte Datenbank/ API antwortet nicht.
Bedeutung: Der PHP-FPM-Pool hat die maximale Anzahl gleichzeitiger Child-Prozesse erreicht.
Mögliche Ursache: Plötzlicher Traffik, langsame PHP-Anfragen, niedrige pm.max_children oder Datenbankverzögerung
Bedeutung: Apache proxy_fcgi konfiguriert PHP-FPM-Socket oder Port konnte nicht verbinden.
Mögliche Ursache: Der PHP-FPM-Dienst ist geschlossen, der Socket-Pfad ist falsch, der Pool wurde nicht erstellt oder es gibt ein Berechtigungsproblem.
Bedeutung: PHP-FPM läuft, kann aber den Skriptpfad als gültigen Dateipfad nicht finden.
Mögliche Ursache: DocumentRoot, Proxy-Zuordnung, Symlink, falsche Rewrite-Regeln oder Dateiberechtigungen.
Bedeutung: Neuer Prozess, Socket oder Systemressource kann vorübergehend nicht getrennt werden.
Mögliche Ursache: NPROC/EP-Grenzwert, Prozesslimit, Dateideskriptorlimit oder Last des Systems.
Bedeutung: PHP oder der Webserver kann keinen neuen Speicherbereich allozieren.
Mögliche Ursache: Echtes RAM-Auslaufen, cgroup/LVE-PMEM-Limit oder übermäßige Prozessanzahl.
Bedeutung: Die PHP-Anwendung ist ohne gültige HTTP-Header beendet worden.
Mögliche Ursache: Fataler Fehler, Zeitablauf, Segfault, Berechtigungsproblem oder vorzeitige Anwendungsbeendigung.
Bedeutung: Es kann nach einer Paketaktualisierung Handler- oder Poolkompatibilitätsprobleme geben.
Mögliche Ursache: Fehlende Pakete, alter FPM-Pool, Dienst neu laden oder falsche Version auswählen.
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 150 /usr/local/apache/logs/error_log
tail -n 150 /usr/local/lsws/logs/error.log 2>/dev/null503 zeigt die Backend-, LSAPI- und proxy_fcgi-Zeilen zum Zeitpunkt an.
/usr/local/cpanel/scripts/restartsrv_httpd --status
systemctl list-units --type=service 'ea-php*-php-fpm.service' --no-pagerTrennt PHP-FPM-Dienste, die mit Apache installiert sind und ob sie funktionieren.
/usr/local/cpanel/bin/rebuild_phpconf --current
/usr/local/cpanel/bin/whmapi1 php_get_vhost_versions | head -n 80Überprüft den Standard-Handler und die PHP-Version für die Domain.
ps -eo user,pid,ppid,%cpu,%mem,etime,cmd --sort=-%cpu | grep -E 'lsphp|php-fpm' | head -n 40Listet CPU-nutzende und lang laufende PHP-Prozesse auf.
free -h
journalctl -k --since '1 hour ago' | grep -Ei 'oom|out of memory|killed process'Trennt die normalen kill-Operationen, die durch systemd aufgrund globaler RAM-Druck durchgeführt werden.
lveinfo --period=1h --by-fault=any --display-username --show-all
lvetopZeigt Konten mit EP-, PMEM-, NPROC-, CPU- oder IO-Fehler an.
/usr/local/cpanel/scripts/check_cpanel_pkgs --fixÜberprüft und repariert modifizierte oder fehlende cPanel-verwaltete Pakete.
find /home/USERNAME -maxdepth 3 -type f -name 'error_log' -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null | sort -r | headGeben Sie USERNAME ein, um die neuesten Anwendungs-Error_Log-Dateien zu finden.
Zuerst bestimmen, ob der Fehler auf einen bestimmten Account oder auf den gesamten Server beschränkt ist; dann die Log-, Handler-, Quellen- und Anwendungs- layer nacheinander überprüfen.
Testen Sie eine statische Datei, eine andere PHP-Datei auf demselben Konto und ein anderes cPanel-Konto, um zu bestimmen, ob das Problem auf der Anwendungs-, Konto- oder globalen Dienstebene liegt.
curl -skI https://alanadi.com/test.html
curl -skI https://alanadi.com/index.phpÜbereinstimmung zwischen Apache/LiteSpeed- und Domain-Error-Log-Einträgen nach dem gleichen Zeitstempel. Die 503-Meldung allein ist nicht die Ursache.
tail -n 200 /usr/local/apache/logs/error_logDie ausgewählte EA-PHP-Version der Domain, der verwendete Handler und der PHP-FPM-Status müssen zueinander kompatibel sein.
/usr/local/cpanel/bin/rebuild_phpconf --currentWenn das globale Problem bestätigt wurde, sollten Sie das zugehörige PHP-FPM-Dienst und dann Apache mit cPanel-Skripten neu starten.
systemctl restart ea-php83-php-fpm
/usr/local/cpanel/scripts/restartsrv_httpdWenn ein EP/NPROC/PMEM-Fehler vorliegt, beheben Sie Bot-Traffic, langsames Abfragen, Cron, Plugins und lang laufende PHP-Prozesse, anstatt nur den Limit zu erhöhen.
lveinfo --period=1h --by-fault=any --display-username --show-allÜberprüfen Sie nach dem Update gestartet wurde, die Paketintegrität. Anschließend überprüfen Sie den HTTP-Code, den Service-Status und die Log-Wiederholung.
/usr/local/cpanel/scripts/check_cpanel_pkgs --fix
curl -skI https://alanadi.com/Zuerst müssen die LVE-Geschichte, die PHP-Version, .htaccess, die Anwendungsfehlerprotokolle und die Plugin/Cron-Prozesse des Kontos untersucht werden. Ein globaler Apache-Neustart sollte nicht die erste Option sein.
lveinfo --user=USERNAME --period=1h --display-username --show-allApache/LiteSpeed, alle EA-PHP-FPM-Dienste, globaler RAM, Prozesszahl und letzte EasyApache-Aktionen werden überprüft.
systemctl --failed --no-pager
free -h
ps -e --no-headers | wc -lNetzwerk und Webserver sind grundsätzlich zugänglich; Handler, PHP-FPM-Socket, lsphp oder PHP-Pakete sind primäre Verdächtige.
echo '<?php echo PHP_VERSION;' > /home/USERNAME/public_html/eka-php-test.phpDiese Situation ist keine dauerhafte Lösung. Lange laufende Anfragen, wp-cron, Angriffsverkehr, Datenbankwartezeiten oder Prozesslimits müssen untersucht werden.
ps -eo user,pid,%cpu,%mem,etime,cmd --sort=-etime | grep -E 'lsphp|php-fpm' | headPHP-Prozesse können den Pool füllen, weil sie auf die Datenbankantwort warten. Im MariaDB-Prozessliste, slow query Log und Disk-IO werden überprüft.
mysqladmin processlist
mysqladmin status
iostat -xz 1 3HTTP 503 signalisiert eine vorübergehende Unverfügbarkeit; jedoch kann sie, wenn die Grundursache nicht behoben wird, unbegrenzt wiederholt werden. Ein Dienstneustart reinigt nur die blockierten Prozesse und löst keine Probleme mit intensivem Code oder Ressourcenlimits.
Zeigt an, dass mod_lsapi innerhalb der angegebenen Zeit nicht auf den lsphp-Hintergrund verbunden werden konnte. Stuck lsphp-Prozesse, CloudLinux-Limits, hoher Traffic oder Speicherdruck sollten untersucht werden.
Sie können die angeschlossenen Links vorübergehend bereinigen. Wenn jedoch der Fehler einem bestimmten Account zuzurechnen ist, kann ein globaler Neustart andere Kunden unnötig beeinträchtigen und die eigentliche Ursache wird sich kurz darauf wiederholen.
Nur der Pool ist tatsächlich aufgefüllt und es gibt genug RAM auf dem Server, um jede neue PHP-Prozess zu handhaben, dann sollte es erhöht werden. Zunächst sollten langsame Anfragen und Datenbankwarteschlangen ermittelt werden.
DNS- und SSL-Probleme erzeugen unterschiedliche Fehlerbildschirme. Eine 503-Antwort zeigt in der Regel an, dass die Anfrage den Webserver erreicht hat, aber am Backend nicht verarbeitet werden konnte.
508 zeigt in der Regel direkt an, dass die LVE-Ressource überschritten wurde. 503 hingegen ist ein allgemeineres Ergebnis der Backend-Verbindung oder -Dienstunverfügbarkeit; LVE-Limit kann auch darunter liegen
Die LVE-Geschichte Ihres Kontos sollte in public_html/error_log, wp-cron, Sicherheits-Plugins, Cache-Plugins und langlaufenden PHP-Prozessen überprüft werden.
Apache oder LiteSpeed, Domainname PHP-FPM-Dienst, MariaDB und CloudLinux-LVE-Schicht sind die grundlegenden Prüfunglen. Das Protokoll sollte angeben, in welcher Schicht eingegriffen werden soll.
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.