nginx 502 Bad Gateway error resolution

Some websites that run on Nginx sometimes have "502 Bad Gateway" errors, and sometimes even more frequently. Here are some of the troubleshooting methods for Nginx 502 errors collected by this site for your reference:

The reason for the Nginx 502 error is more likely to be a problem with the back-end server in proxy mode. These errors are generally not the fault of nginx itself, be sure to look at the back end for the cause! But the fact that nginx took all the blame for the mistakes makes the promoters of nginx suspicious. After all, bad gateway? Isn't that bad nginx? I hope that the next version of nginx will make the error prompt a little more friendly, at least not as simple as "502 Bad Gateway" now.

Trigger condition for Nginx 502

The most common occurrence of a 502 error is a backend host crash. There is a configuration in the upstream configuration: proxy_next_upstream. This configuration specifies that nginx will go to the next back-end host when it encounters any errors in fetching data from one back-end host. It says all the cases of 502 will be pulled, and the default is error timeout. error means dead, broken, etc. timeout means read blocked timeout, which is easy to understand. I usually write it all:

proxy_next_upstream error timeout invalid_header http_500 http_503; But now I might want to remove the http_500 item. http_500 specifies that when the backend returns 500 errors, it will go to a host. But the company's programmers didn't think so. They decided that nginx had made a mistake.

The 503 error can be kept, because the backend is usually apache resin, if apache crashes it is error, but resin crashes, it is only 503, so it is still necessary to keep it.

solution

If you encounter a 502 problem, you can prioritize the following two steps to solve it.

1. Check whether the current number of PHP FastCGI processes is sufficient:

netstat -anpo | grep "php-cgi" | wc -l

If the actual number of FastCGI processes used is close to the preset number of FastCGI processes, then the number of FastCGI processes is insufficient and needs to be increased.

2. The execution time of some PHP programs exceeds the waiting time of Nginx, so the timeout time of FastCGI in the nginx.conf configuration file can be appropriately increased, such as

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

memory_limit, php.ini, memory_limit, is changed to 64M. Restart nginx and find that PHP is out of memory.

If this modification does not solve the problem, please refer to the following schemes:

I. max-children and max-requests

nginx php(fpm) xcache runs on one server, with an average daily traffic of around 300W pv.

These days, it often happens that the php page opens slowly, the cpu usage suddenly drops to a low level, the system load suddenly rises to a high level, and if you look at the network card traffic, you will also find that it drops to a low level. It only lasted a few seconds before it recovered.

Checking the log files of php-fpm reveals some clues.

Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200  Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10,  " 127.0.0.1:9000 "   Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll  Sep 30 08:32:23.296426 [NOTICE] fpm_init(), line 47: fpm is running, pid 30587　

At the beginning of these sentences, more than 1000 lines close children and open children's log.

It turns out that php-fpm has a parameter max_requests, which specifies the maximum number of requests per children to be closed. The default setting is 500. Since php polls requests to each children, it takes about the same time for each childre to reach max_requests under high traffic, resulting in all children being shut down at roughly the same time.

During this time, nginx cannot transfer the php file to php-fpm for processing, so cpu will drop to very low levels (no php processing, much less sql execution), the load will rise to very high levels (turn children off and on, nginx waiting for php-fpm), and the network card traffic will drop to very low levels (nginx cannot generate data to transfer to the client),

The solution is simple: increase the number of children and set max_requests to non-0 or a larger value:

Open/usr local/php etc/php - fpm. conf up the following two parameters (according to the actual circumstance of the server, not too much)

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

Then restart php-fpm.

Increase the buffer capacity

Open nginx error log and find "pstream sent too header while reading response header from upstream". There is an bug buffer in the nginx buffer. The page consumption of our website may be too large. The revision method that the reference foreigner writes increased buffer capacity size to set, 502 problem is solved thoroughly. Later, the system administrator adjusted the parameters and kept only two parameters: client head buffer, fastcgi buffer size.

Third, request_terminate_timeout

If this is mainly the case with some post or database operations, rather than with static page operations, take a look at one of the php-fpm.conf Settings:

request_terminate_timeout

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

0s

0s is closed, which means it can execute indefinitely. (changed a number without looking at it carefully when loading) the problem is solved, and the execution will not go wrong for a long time. To optimize fastcgi, you can also change this value to 5s to see what it looks like.

A 502 error occurs when the php-cgi process is insufficient, the php process takes a long time to execute, or the php-cgi process dies.

Nginx 502 Bad Gateway wrong solution 2

Today, my VPS frequently reminds me that Nginx 502 Bad Gateway is wrong. After restarting VPS, it appears again, which is very annoying. A little confused, the website reached 1290 page views in the past two days without any problems, how did this time appear 502 Bad Gateway? Depressed!! After searching for a long time, I finally found many relevant answers. I hope this error will not appear again after the modification. Well, since I've been searching the Internet for answers for so long, of course I'll have to keep a record of what's useful, so I won't have to go back next time

Because I am the use of LNMP one-key installation package, out of the problem must first go to the official forum to search, good, the official has such a top post, we first look.

LNMP one-button installation package official:

The first reason: the problem with the current lnmp one-key package installation is 502 Bad Gateway. In most cases, the reason is that some lib packages in the script may not be installed before the installation of php, so php is not successfully compiled and installed.
Solution: try manually installing it according to the script in the lnmp one-key installation package to see what caused the error.

Second reason:

In php.ini, the eaccelerator configuration item must be placed before the Zend Optimizer configuration, otherwise it may cause 502 Bad Gateway

Third reason:

In installed 502 problems in use process, usually because the default php - cgi process is 5, May 502, because of insufficient use phpcgi process need to modify/usr/local/php etc/php - fpm. conf will max_children value increasing of them.

Fourth reason:

php timeouts, modify/usr/local/php/etc/php ini will max_execution_time 300

instead

Fifth reason:

Insufficient disk space such as mysql logs take up a lot of space

Sixth reason:

See if the php-cgi process is running

Another solution:

Nginx 502 Bad Gateway means that the requested PHP-CGI has been executed, but the PHP-CGI process has been terminated due to some reason (usually a problem reading the resource). Nginx 502 Bad Gateway is generally associated with the php-fpm.conf setting.

Es460en-fpm.conf has two crucial parameters, max_children and request_terminate_timeout, but this value is not generic and needs to be calculated on its own.
In installed 502 problems in use process, usually because the default php - cgi process is 5, May 502, because of insufficient use phpcgi process need to modify/usr/local/php etc/php - fpm. conf will max_children value increasing of them.

The calculation is as follows:

If your server performance is good enough and the bandwidth is sufficient, you can set request_terminate_timeout to 0s if the PHP script does not have a loop or BUG. 0s means to keep PHP-CGI running without a time limit. If you can't do this, then your PHP-CGI may have some BUG, or your PHP-CGI may be suspended for lack of bandwidth or some other reason, then it is recommended that you assign a value to request_terminate_timeout, which can be set according to the performance of the server. In general, the better the performance, the higher you can set it, anywhere from 20 minutes to 30 minutes.
How do you calculate max_children? In principle, the larger the better, the more processes php-cgi have, the faster they will be processed and the fewer requests queued. Setting max_children also depends on the performance of the server. Generally speaking, the amount of memory consumed by each php-cgi is about 20M under normal conditions of a server.

According to the official answer, checked the possibility of the relevant, and combined with the answers of the Internet users, the following solutions.

1. View the number of processes in php fastcgi (max_children value)

Code: netstat-anpo | grep "php-cgi" | wc-l

5 (if shown 5)

2. View the current process

Code: top
Look at the number of fastcgi processes. If the number of processes used is equal to or higher than 5, you need to increase

(depending on the actual condition of your machine)

3, adjust/usr local/php etc/php - fpm.

conf related Settings

< value name max_children > "=" 10 < /value >
< value name request_terminate_timeout > "=" 60s < /value >
max_children up to 10 processes, according to each process 20MB memory, up to 200MB.
The execution time of request_terminate_timeout is 60 seconds, or 1 minute.