(summary) Nginx 502 Bad Gateway error triggering conditions and solutions

Some websites that run on Nginx sometimes appear "502 Bad Gateway" errors, even when they occur frequently. Here are some of the Nginx 502 error troubleshooting methods compiled from Google for your reference:

The reason for Nginx 502 error is more because of a problem with the backend server in proxy mode. These errors are generally not the problem of nginx itself, be sure to find the reason from the back end! But Nginx put these mistakes are in their own body, really let Nginx promoter is questioned, after all, from the word understanding, bad gateway? Isn't that bad nginx? Let not understand the people see, will directly put the blame on the Nginx body, I hope nginx next version will be the wrong hint to write a little more friendly, at least not now a simple sentence 502 bad Gateway, also do not forget to attach their own name.

Trigger conditions for Nginx 502

The most common occurrence of a 502 error is the backend host machine. In the upstream configuration, there is a configuration: Proxy_next_upstream, this configuration specifies the Nginx in the data from a backend host to get the error when it will go to the next back-end host, which is written in the 502 will appear all the situation pull, default is error Timeout Error is when the machine, disconnection, and so on, timeout is to read the blocking timeout, more easily understood. I usually write it all up:

Proxy_next_upstream Error timeout invalid_header http_500 http_503;

But now maybe I want to get rid of the http_500, http_500 specifies that the backend returns a 500 error when it turns a host, the back end of the JSP error, it would have printed a bunch of stacktrace error messages, is now replaced by 502. But the company's programmers do not think so, they believe that the nginx error, I really do not have time to explain to them the principle of 502 ...

503 error can be preserved, because the backend is usually Apache resin, if the Apache panic is error, but resin panic, just 503, so it is necessary to keep.

Solutions

If you encounter 502 problems, you can prioritize the following two steps to resolve them.

1. See if the current number of PHP fastcgi processes is sufficient:

Netstat-anpo | grep "php-cgi" | Wc-l

If the number of "fastcgi processes" actually used is close to the preset number of fastcgi processes, then the number of "fastcgi processes" is not sufficient and needs to be increased.

2, some PHP program execution time exceeds the Nginx wait time, can appropriately increase the timeout time in the nginx.conf configuration file fastcgi, for example:

..... http{......fastcgi_connect_timeout 300;fastcgi_send_timeout 300;fastcgi_read_timeout 300; ...} ......

PHP.ini in Memory_limit set low will error, modified php.ini memory_limit for 64M, restart Nginx, found good, the original is the memory of PHP is insufficient.

If this modification does not solve the problem, you can refer to the following scenarios:

First, Max-children and max-requests

An nginx php (FPM) XCache is running on a single server with a daily visit of 300W PV/approx.

Recently, this is often the case: PHP page Open very slow, the CPU usage suddenly dropped to very low, the system load suddenly up to very high, look at the network card traffic, will also find suddenly dropped to very low. This only lasts a few seconds and then it recovers.

Check the log files of php-fpm and find some clues.

Sep 08:32:23.289973 [NOTICE] Fpm_unix_init_main (), line 271:getrlimit (nofile): max:51200, Cur:51200sep 30 08:32:23.29 0212 [NOTICE] Fpm_sockets_init_main (), Line 371:using inherited socket fd=10, "127.0.0.1:9000″sep-08:32:23.290342 [not ICE] Fpm_event_init_main (), line 109:libevent:using epollsep-08:32:23.296426 [NOTICE] Fpm_init (), line 47:FPM is run Ning, PID 30587

In front of these sentences, there are more than 1000 lines of closed children and open children logs

Originally, PHP-FPM has a parameter max_requests, which indicates how many requests per children will be closed and the default setting is 500. Because PHP is polling the request to each children, it takes about the same amount of time for each childre to reach max_requests at large traffic, which causes all children to be shut down essentially at the same moment.

During this time, Nginx can not transfer php files to PHP-FPM processing, so the CPU will be reduced to very low (not to process PHP, not to execute SQL), and the load will rise to very high (close and open children, nginx wait for php-fpm), network card traffic also dropped to very low ( Nginx cannot generate data transfer to client)

Solving the problem is simple, increase the number of children, and set the max_requests to 0 or a larger value:

Open/usr/local/php/etc/php-fpm.conf

Adjust the following two parameters (according to the actual situation of the server, too large or not)

<value name= "Max_children" >5120</value><value name= "max_requests" >600</value>

Then restart PHP-FPM.

Second, increase the buffer capacity size

Open the Nginx error log and discover "Pstream sent too big header while reading response headers from upstream" error message. Look up the information, to the effect that the nginx buffer has a bug caused, our site page consumption may be too large buffer. Refer to the foreigner write modification method increases the buffer capacity size setting, 502 problem solved completely. Later, the system administrator also adjusted the parameters to retain only 2 settings parameters: Client head buffer,fastcgi buffer size.

Third, Request_terminate_timeout

If this is the case when there are several post or database operations, but not common in static page operations, you can look at one of the php-fpm.conf settings:

Request_terminate_timeout

This value is Max_execution_time, which is the fast-cgi execution script time.

0s

0s is closed, is infinite execution goes on. (I changed a number when I did not look closely at the time of loading)

Found that the problem was solved, the execution for a long time will not be wrong.

Optimization fastcgi, you can also change the value of 5s to see the effect.

A 502 error occurs when the number of php-cgi processes is insufficient, the PHP execution time is long, or the php-cgi process dies.

(summary) Nginx 502 Bad Gateway error triggering conditions and solutions