Neuerdings haben wir Parallels Plesk 12.0.18 im Einsatz, das standardmäßig mit nginx als Reverse Proxy und Apache 2 kommt. Mit der Standardkonfiguration bekommen wir oftmals einen „502 Bad Gateway Error“ der den kompletten Webserver lahm legt. Was ist das?
502 Bad Gateway
Zu Anfang traten bereits bei den kleinsten Aufgaben regelmäßig Timeouts auf und nginx resignierte den Dienst mit der Meldung „502 Bad Gateway“.
Nach folgenden Anpassungen der nginx-Konfiguration, wie weiter unten beschrieben, wurde es schon besser. Komplett hat dies das Problem allerdings noch immer nicht gelöst und viele große Hoster sowie Parallels stehen noch vor diesem Problem. Nun haben wir das Problem lösen können.
Was ist das? 502 Bad Gateway?
Der HTTP Statuscode 502 bedeutet, dass ein Server in der Verbindungskette nicht antwortet oder eine nicht interpretierbare Antwort liefert.
Beim Einsatz von Plesk 12 kommen zwei Webserver zum Einsatz. Einerseits der bekannte Apache 2 Webserver der etwas langsamer ist, dafür aber .htaccess-Dateien verarbeiten kann, andererseits der nginx, der keine .htaccess-Dateien lesen kann und mitunter deshalb schneller ist. Bei Plesk 12 und höheren Versionen wird der nginx-Webserver zur Ausgabe von statischen Dateien (css, js, usw.) verwendet.
Seit des großen Booms des nginx-Servers im Jahr 2014 und der immer größeren Verbreitung von Parallels Plesk als Webserver-Management-Tool sieht man den Gateway-Error im Internet immer öfter – mehr als nervig.
Logfiles
Als allererstes prüfen wir die Logfiles die sich in /var/www/vhosts/kunde/logs/ befinden.
Wichtig sind
- error_log (von Apache 2)
- proxy_error_log (von nginx)
Nginx Error Log
Viele bekommen folgende Fehler:
- recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 123.123.123.123, server: , request: „POST <some url>
- connect() failed (111: Connection refused) while connecting to upstream, client: 213.33.58.2, server: xxx.com, request: „GET /favicon.ico HTTP/1.1“, upstream: „http://<IP>:7080/favicon.ico“, host: „<somehost>“
- upstream timed out (110: Connection timed out) while reading response header from upstream, client: 94.102.220.87, server:<somehost>, request: „GET / HTTP/1.0“, upstream: „http://<IP>:7080/“, host: „<somehost>“
Diese Fehler lassen sich mit folgender Methode jedenfalls beheben.
Nginx Konfiguration
Die Haupt-Config-Dateien von nginx befindet sich bei Plesk 12 unter
- /etc/nginx/nginx.conf
- /etc/sw-cp-server/config
Fügen Sie folgende Einträge in /etc/sw-cp-server/config im http-Block hinzu:
http {
fastcgi_buffers 32 32k;
fastcgi_buffer_size 64k;
fastcgi_read_timeout 600;
fastcgi_send_timeout 600;
}
502 Bad Gateway provozieren
Mit folgender Aufgabe konnten wir den Bad Gateway Error zuverlässig nachstellen und testen.
- Magento Theme hochladen
- Magento Theme aktivieren
- Statische Blöcke importieren – nach dem Importvorgang kommt die Fehlermeldung „Error 502 Bad Gateway – nginx“ auf jeder Website die über Parallels Plesk verwaltet wird bzw. die über den Webserver bedient wird.
- CMS Pages importieren – sofort erscheint „Error 502 Bad Gateway – nginx“
502 Bad Gateway Lösung
Sollte der Fehler nach einigen Minuten automatisch verschwinden und ein Neustart der Dienste nginx und apache2 nichts bringen ist folgendes die Lösung. Wir haben die Firewall Fail2Ban nachträglich aktiviert und standardmäßig einen Jail für apache2 und nginx eingerichtet. Durch bestimmte Aufgaben kann es passieren, dass der Server sich selber blockiert und zwar genau solange wie der Jail aktiv ist – Standardmäßig sind das 300 Sekunden. Deaktivieren Sie einfach die Jails wie im folgenden Bild.
Apache 2 Konfiguration
Damit unser Server überhaupt PHP Dateien interpretierte haben wir folgende Einstellung in der /etc/apache2/apache2.conf eingestellt:
# tell apache to render php first and then html files
DirectoryIndex index.html index.html index.php index.php5
Server neu starten
Abschließend müssen beide Services nur neu gestartet werden:
- service apache2 restart
- service nginx restart
Das Problem gab es bei uns ebenso schon, leider. Abergut das dieser Beitrag online ist, hat uns geholfen und wir sind sehr happy!
Nice Sunday!
Simon
Bei mir hat leider nichts gebracht. Werde das eine oder andere. Leider. Hat jemand noch eine Idee? Werde damit verrückt. Aber es liegt nicht am Fail2ban. IPs sind auf whitliste. Selbst beim Stoppen des Services tut sich nichts.
Plesk hat die Standardeinstellungen in den aktuellen Versionen dahingehend schon geändert. Die /etc/nginx/nginx.conf müsste aber weiter optimiert werden, vor allem in Bezug auf die Komprimierung.
Der obere Absatz könnte etwas erweitert werden. Es liest sich so, als wäre der einzige Unterschied zwischen apache und nginx die Unterstützung von .htaccess Dateien zu denen es im Plesk aber auch einen converter gibt.
nice website man, thanks for information ! Nach 5h Rekonfiguration und Untersuchung des Servers mit diversen anderen Methoden habe ich per Zufall diesen Hinweis gefunden und siehe da. Unser Server hatte seine eigene IP gesperrt, ohne einen Hinweis darauf.
Ich habe jetzt Stunden damit verbracht herauszufinden, wieso alle Seiten unserer Kunden einen 502er bekommen.
Durch Zufall und als ich schon für heute Feierabend machen wollte, habe ich diesen Beitrag entdeckt.
Das Problem war, dass Plesk aus irgendeinem Grund, die eigene IP-Adresse gesperrt hat.
Tausend Dank!!!, Du hast mir das Wochende gerettet ;-)
Gruß Stephan
Danke für den Artikel.
Die Änderung der Werte in der /etc/sw-cp-server/config war die Lösung.
Freundliche Grüsse
Markus
Vielen Dank für diesen Hinwei – auch bei mir war aus irgendeinem Grund die Server-IP in den gesperrten IPs gelandet. Zu den vertrauenswürdigen IPs hinzugefügt – und das Problem ist behoben. Die IPv6-IP war interessanterweise bei den vertrauenswürdigen bereits vorhanden.
Danke, hat mir ein wenig weitergeholfen. Bei mir hat Fail2Ban bzw ModSecurity bei Plesk einfach mal die Serverip in ein Jail gesteckt… Dadurch hatte ich wenn ich nginx laufen hatte nen 502 Error. Zu Vertrauenswürdigen IP’s hinzugefügt und voila Seiten sind wieder aufrufbar auch mit nginx davor geschaltet. Plesk ist schon manchmal komisch
Vielen Vielen Dank.
Nach 5h Rekonfiguration und Untersuchung des Servers mit diversen anderen Methoden habe ich per Zufall diesen Hinweis gefunden und siehe da. Unser Server hatte seine eigene IP gesperrt, ohne einen Hinweis darauf.
Danke Danke Danke.
Vielen Dank für diesen Beitrag, Herr Grundner! Hat mir sehr weiter geholfen.
Beste Grüße,
Benjamin