So beheben Sie den Nginx 502 Bad Gateway-Fehler-Nginx-php.cn

Nginx 502-Auslösebedingungen

　Am häufigsten treten 502-Fehler auf, wenn der Backend-Host abstürzt. Es gibt eine solche Konfiguration in der Upstream-Konfiguration: Diese Konfiguration gibt an, auf welche Art von Fehlern Nginx beim Abrufen von Daten von einem Back-End-Host stößt 502s, die je nach Situation angezeigt werden, ist die Standardeinstellung Fehler-Timeout. „Fehler“ bezieht sich auf Abstürze, Verbindungsabbrüche usw. „Timeout“ bezieht sich auf das Zeitlimit für die Leseblockierung, was leichter zu verstehen ist. Normalerweise schreibe ich es vollständig:

proxy_next_upstream error timeout invalid_header http_500 http_503; Aber jetzt muss ich möglicherweise das http_500-Element entfernen, das angibt, dass das Backend einen 500-Fehler zurückgibt Bei einem Fehler wird ursprünglich eine Reihe von Stacktrace-Fehlermeldungen ausgegeben, die jetzt durch 502 ersetzt werden. Aber die Programmierer des Unternehmens glauben nicht, dass es einen Fehler in Nginx gibt. Ich habe wirklich keine Zeit, ihnen das Prinzip von 502 zu erklären ...

Der 503-Fehler kann beibehalten werden, da das Backend Wenn Apache abstürzt, tritt normalerweise ein Fehler auf, aber das abgestürzte Harz ist nur 503 und muss daher beibehalten werden.

Lösung

Wenn Sie auf ein 502-Problem stoßen, können Sie die folgenden zwei Schritte zur Lösung priorisieren.

1. Überprüfen Sie, ob die aktuelle Anzahl der PHP-Fastcgi-Prozesse ausreicht:

netstat -anpo | „Anzahl der Fastcgi-Prozesse“ wird tatsächlich verwendet. Liegt es nahe an der standardmäßigen „Anzahl der Fastcgi-Prozesse“, bedeutet dies, dass die „Anzahl der Fastcgi-Prozesse“ nicht ausreicht und erhöht werden muss.

2. Die Ausführungszeit einiger PHP-Programme überschreitet die Wartezeit von nginx. Sie können die Timeout-Zeit von fastcgi in der Konfigurationsdatei nginx.conf entsprechend erhöhen:

Kopieren Sie den Code:

http {

fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

......

}
......

Wenn das Memory_limit in php.ini niedrig eingestellt ist, tritt ein Fehler auf. Ändern Sie das Memory_Limit von php.ini auf 64 m, starten Sie Nginx neu und stellen Sie fest, dass es ok ist. Es stellt sich heraus, dass PHP nicht über genügend Speicher verfügt.

Wenn das Problem nach dieser Änderung nicht gelöst werden kann, können Sie auf die folgenden Lösungen zurückgreifen:

1 tägliches Besuchsvolumen von rund 3 Millionen PV.

　Situationen wie diese treten in letzter Zeit häufig auf: Die PHP-Seite öffnet sich sehr langsam, die CPU-Auslastung sinkt plötzlich auf ein sehr niedriges Niveau, die Systemlast steigt plötzlich auf ein sehr hohes Niveau und wenn Sie den Datenverkehr der Netzwerkkarte überprüfen, werden Sie Sie werden auch feststellen, dass es plötzlich auf ein sehr niedriges Niveau absinkt. Dieser Zustand dauert nur wenige Sekunden, bevor er wieder auftritt.

　Bei der Überprüfung der Protokolldateien von php-fpm wurden einige Hinweise gefunden.

Code kopieren Der Code lautet wie folgt:

30. September 08:32:23.289973 [Hinweis] fpm_unix_init_main(), Zeile 271: getrlimit(nofile): max:51200, cur:51200 30. September 08:32:23.290212 [Hinweis ] fpm_sockets_in it_main( ), Zeile 371: Verwendung des geerbten Sockets fd=10, „127.0.0.1:9000″ 30. September 08:32:23.290342 [Hinweis] fpm_event_init_main(), Zeile 109: libevent: Verwendung von epoll 30. September 08:32: 23.296426 [Hinweis] fpm_init(), Zeile 47: fpm läuft, PID 30587　

Vor diesen Sätzen gibt es mehr als 1.000 Protokollzeilen zum Schließen und Öffnen untergeordneter Elemente.

Es stellt sich heraus, dass php-fpm einen Parameter max_requests hat, der die maximale Anzahl von Anfragen angibt, die jedes Kind verarbeiten kann, bevor es geschlossen wird. Die Standardeinstellung ist 500. Da PHP Anfragen an jedes untergeordnete Element abfragt, dauert es bei starkem Datenverkehr jedes untergeordnete Element ungefähr gleich lange, bis es max_requests erreicht, was dazu führt, dass alle untergeordneten Elemente praktisch gleichzeitig geschlossen werden.

　Während dieser Zeit kann Nginx die PHP-Datei nicht zur Verarbeitung an PHP-FPM übertragen, sodass die CPU auf ein sehr niedriges Niveau fällt (keine Notwendigkeit, PHP zu verarbeiten, geschweige denn SQL auszuführen) und die Last auf ein sehr hohes Niveau ansteigt auf hohem Niveau (schließende und öffnende Kinder, Nginx wartet auf PHP-FPM), der Netzwerkkartenverkehr ist ebenfalls auf ein sehr niedriges Niveau gesunken (Nginx kann keine Daten generieren, die an den Client übertragen werden)

　Die Lösung des Problems ist sehr einfach. Erhöhen Sie die Anzahl der Kinder und setzen Sie max_requests auf weniger als 0 oder einen relativ großen Wert:

Öffnen Sie /usr/local/php/etc/php-fpm.conf und erhöhen Sie die folgenden zwei Parameter (entsprechend der tatsächlichen Situation des Server, zu groß wird nicht funktionieren)

Kopieren Sie den Code. Der Code lautet wie folgt:

;5120< value>

600

Dann php-fpm neu starten.

2. Erhöhen Sie die Pufferkapazität

Öffnen Sie das Nginx-Fehlerprotokoll und finden Sie eine Fehlermeldung wie „pstream hat beim Lesen des Antwortheaders vom Upstream einen zu großen Header gesendet“. Nach Überprüfung der Informationen besteht die allgemeine Annahme, dass ein Fehler im Nginx-Puffer vorliegt. Der durch den Seitenverbrauch unserer Website belegte Puffer ist möglicherweise zu groß. Unter Bezugnahme auf die von Ausländern geschriebene Änderungsmethode wird die Einstellung der Pufferkapazität erhöht und das 502-Problem vollständig gelöst. Später passte der Systemadministrator die Parameter an und behielt nur zwei Einstellungsparameter bei: Client-Kopfpuffer und Fastcgi-Puffergröße.

3. request_terminate_timeout

　Wenn 502 hauptsächlich bei einigen Posts oder Datenbankvorgängen auftritt und nicht häufig bei statischen Seitenvorgängen, dann können Sie eine der php-fpm.conf-Einstellungen überprüfen:

request_terminate_timeout

Dieser Wert ist max_execution_time, die schnelle Skriptausführungszeit -cgi.

0s ist geschlossen, was bedeutet, dass es auf unbestimmte Zeit weiter ausgeführt wird. (Ich habe während der Installation eine Nummer geändert, ohne genau hinzusehen) Das Problem ist behoben und die Ausführung wird für lange Zeit fehlerfrei sein. Bei der Optimierung von fastcgi können Sie diesen Wert auch 5 Sekunden lang ändern, um den Effekt zu sehen.

Wenn die Anzahl der PHP-CGI-Prozesse nicht ausreicht, die PHP-Ausführungszeit lang ist oder der PHP-CGI-Prozess abstürzt, tritt ein 502-Fehler auf.

Nginx 502 Bad Gateway-Fehlerlösung 2

Heute meldete mein VPS häufig den Nginx 502 Bad Gateway-Fehler. Nach dem Neustart des VPS erschien dieser erneut, was sehr ärgerlich war. Ich bin etwas verwirrt. Die Website hatte in den letzten zwei Tagen 1290 Besuche ohne Probleme. Warum ist dieses Mal ein 502 fehlerhaftes Gateway aufgetaucht? Deprimierend! ! ! Nach langer Suche habe ich endlich viele relevante Antworten gefunden. Ich hoffe, dass dieser Fehler nach der Änderung nicht erneut auftritt. Da ich leider schon so lange im Internet nach Antworten gesucht habe, muss ich natürlich die nützlichen Dinge aufzeichnen, damit ich beim nächsten Mal nicht noch einmal zu Google gehen muss~

Da ich den LNMP mit einem Klick verwendet habe Installationspaket, ich muss zuerst da sein, wenn es ein Problem gibt. Ich habe das offizielle Forum durchsucht. Es gibt einen offiziellen gepinnten Beitrag wie diesen.

Offizielles lnmp-One-Click-Installationspaket:

Der erste Grund: Derzeit ist das häufigste Problem mit dem lnmp-One-Click-Installationspaket 502 fehlerhaftes Gateway. In den meisten Fällen liegt der Grund darin, dass vor der Installation von PHP einige lib-Pakete vorhanden sind Das Skript wurde möglicherweise nicht installiert, was dazu führte, dass PHP nicht erfolgreich kompiliert und installiert wurde.
Lösung: Sie können versuchen, es manuell gemäß dem Skript im lnmp-One-Click-Installationspaket zu installieren, um herauszufinden, was den Fehler verursacht.

Der zweite Grund:

In php.ini muss das Eaccelerator-Konfigurationselement vor der Zend-Optimiererkonfiguration platziert werden, sonst kann es auch zu einem fehlerhaften 502-Gateway kommen

Der dritte Grund:

Erscheint während der Installation und Verwendung Das 502-Problem wird im Allgemeinen dadurch verursacht, dass der Standard-php-cgi-Prozess 5 ist. Der 502 kann durch unzureichende phpcgi-Prozesse verursacht werden. Sie müssen /usr/local/php/etc/php-fpm.conf ändern, um den max_children-Wert entsprechend zu erhöhen.

Vierter Grund:

PHP-Ausführungszeitüberschreitung, ändern Sie /usr/local/php/etc/php.ini, um max_execution_time auf 300 zu ändern.

Fünfter Grund:

Unzureichender Speicherplatz, z. B. das MySQL-Protokoll nimmt viel Platz ein

Der sechste Grund:

Überprüfen Sie, ob der PHP-CGI-Prozess ausgeführt wird

Einige Internetnutzer gaben auch eine andere Lösung:

Nginx 502 fehlerhaftes Gateway bedeutet, dass das angeforderte PHP-CGI ausgeführt wurde, aber aus irgendeinem Grund Der Grund (normalerweise ein Problem beim Lesen von Ressourcen) wird nicht abgeschlossen und der PHP-CGI-Prozess wird beendet. Im Allgemeinen hängt das fehlerhafte Nginx 502-Gateway mit den Einstellungen von php-fpm.conf zusammen.

php-fpm.conf hat zwei entscheidende Parameter, einen ist max_children und der andere ist request_terminate_timeout, aber dieser Wert ist nicht universell und muss von Ihnen selbst berechnet werden.
Ein 502-Problem tritt während der Installation und Verwendung auf. Im Allgemeinen liegt es daran, dass der Standard-PHP-CGI-Prozess 5 ist. Dies kann durch unzureichende PHPCGI-Prozesse verursacht werden. Sie müssen /usr/local/php/etc/php-fpm ändern. conf. Der max_children-Wert wird entsprechend erhöht.

Die Berechnungsmethode lautet wie folgt:

Wenn die Leistung Ihres Servers gut genug ist, die Breitbandressourcen ausreichen und das PHP-Skript keine Schleifen oder Fehler aufweist, können Sie request_terminate_timeout direkt auf 0s setzen. Die Bedeutung von 0 besteht darin, PHP-CGI ohne zeitliche Begrenzung weiter ausführen zu lassen. Und wenn Sie dies nicht tun können, das heißt, Ihr PHP-CGI hat möglicherweise einen Fehler, Ihre Bandbreite reicht nicht aus oder andere Gründe führen dazu, dass Ihr PHP-CGI einfriert, dann wird empfohlen, einen Wert zuzuweisen to request_terminate_timeout. Dieser Wert kann entsprechend der Leistung des Servers festgelegt werden. Im Allgemeinen gilt: Je besser die Leistung, desto höher können Sie sie einstellen, zwischen 20 und 30 Minuten.
Und wie wird der Wert von max_children berechnet? Grundsätzlich gilt: Je größer der Wert, desto besser. Je mehr PHP-CGI-Prozesse vorhanden sind, desto schneller werden sie verarbeitet und es stehen weniger Anfragen in der Warteschlange. Das Festlegen von max_children muss auch entsprechend der Leistung des Servers festgelegt werden. Im Allgemeinen beträgt der von jedem PHP-CGI auf einem Server verbrauchte Speicher unter normalen Umständen etwa 20 m.

Anhand der offiziellen Antworten haben wir die entsprechenden Möglichkeiten geprüft und in Kombination mit den Antworten der Internetnutzer die folgenden Lösungen gefunden.

1. Überprüfen Sie die Anzahl der Prozesse von php fastcgi (max_children Wert)

Code: netstat -anpo | Prozess

Code: top

Beobachten Sie die Anzahl der verwendeten Fastcgi-Prozesse. Wenn die Anzahl der verwendeten Prozesse gleich oder höher als 5 ist, bedeutet dies, dass sie erhöht werden muss (abhängig von der tatsächlichen Situation Ihrer Maschine)

3. Passen Sie die Einstellungen für /usr/local/php/etc/php-fpm an.

max_children kann bis zu 10 Prozesse haben, mit 20 MB Speicher pro Prozess, bis zu 200 MB.
Die Ausführungszeit von request_terminate_timeout beträgt 60 Sekunden, also 1 Minute.

Das obige ist der detaillierte Inhalt vonSo beheben Sie den Nginx 502 Bad Gateway-Fehler. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!