How to solve the nginx 502 Bad Gateway error?

Trigger conditions of nginx 502

The most common occurrence of 502 error is that the back-end host crashes. In the upstream configuration, there is such a configuration: proxy_next_upstream, which specifies that nginx will go to the next backend host when it encounters any error in fetching data from one backend host, and it is written that all situations of 502 will occur, and the default is error timeout. Error means crashing, disconnection and the like, and timeout means reading congestion timeout, which is easier to understand. I usually write it all down:

proxy_next_upstream error timeout invalid_header http_500 http_503; But now I may have to get rid of http_500. http_500 specifies that when the backend returns 500 errors, it will turn to a host. If the jsp of the backend makes an error, it would have printed a bunch of stacktrace error messages, but now it has been replaced by 502. But the company's programmers don't think so. They think nginx made a mistake. I really don't have time to explain the principle of 502 to them ...

503 service unavailable can be kept, because the backend is usually apache resin. If apache crashes, it is an error, but resin crashes, which is only 503, so it is still necessary to keep it.

solution

If you encounter the 502 problem, you can give priority to solving it according to the following two steps.

1. Check whether the current number of php fastcgi processes is enough:

The copy code code is as follows:

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

If the number of fastcgi processes actually used is close to the preset number of fastcgi processes, it means that the number of fastcgi processes is not enough 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 nginx.conf configuration file can be appropriately increased, for example:

The copy code code is as follows:

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

If the memory_limit in php.ini is set low, an error will occur. The memory_limit of php.ini is changed to 64m, and nginx is restarted. It turns out that php is out of memory.

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

I. max-children and max-requests

Nginx php(fpm) xcache is running on a server, and the average daily traffic is about 300w pv.

Recently, it often happens that the php page opens slowly, the cpu utilization rate suddenly drops to a very low level, and the system load suddenly rises to a very high level. If you look at the network card traffic, you will find that it suddenly drops to a very low level. This situation only lasted for a few seconds and then recovered.

Checking the log file of php-fpm found some clues.

The copy code code is as follows:

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　

In front of these sentences, there are more than 1000 lines to close the children and open the children's log.

Originally, php-fpm has a parameter max_requests, which indicates that each children will be closed after processing the maximum number of requests. The default setting is 500. Because php polls requests to each child, it takes almost the same time for each child to reach max_requests under heavy traffic, which causes all childre to be closed at the same time.

During this period, nginx can't transfer the php file to php-fpm for processing, so the cpu will drop to a very low level (without processing php, let alone executing sql), while the load will rise to a very high level (closing and opening children, nginx waiting for php-fpm), and the network card traffic will also drop to a very low level (nginx can't generate data to transmit to the client).

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

Open/usr/local/PHP/etc/PHP-fpm.conf to increase the following two parameters (according to the actual situation of the server, it will not work if it is too large).

The copy code code is as follows:

5120600　　

Then restart php-fpm.

Second, increase the buffer capacity.

Open the error log of nginx, and find the error prompt of pstream sent too big header while reading response header from upstream. I checked the information to the effect that there is a bug in nginx buffer, and the page consumption of our website may be too large. Referring to the revision method written by foreigners, the buffer capacity setting was increased, and the 502 problem was completely solved. Later, the system administrator adjusted the parameters and only kept two setting parameters: client head buffer and fastcgi buffer size.

Third, the request_terminate_timeout

If 502 occurs mainly in some post or database operations, rather than in static page operations, you can check one of the php-fpm.conf settings:

request_terminate_timeout

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

0s

0s means to close, which means to go on indefinitely. (I changed a number without looking carefully when I installed it at that time.) The problem has been solved, and it will not go wrong for a long time. In optimizing fastcgi, you can also change this value for 5s to see the effect.

502 errors will occur when the number of php-cgi processes is not enough, php takes a long time to execute, or php-cgi processes die. Solution to nginx 502 bad gateway Error 2

Today, my vps frequently reminds me that nginx 502 bad gateway is wrong, and it reappears after restarting the vps, which is very annoying. I'm a little puzzled. Two days ago, the website reached 1290 visits without any problems. Why did 502 bad gateway appear this time? Depressed! ! ! After searching for a long time, I finally found a lot of relevant answers. I hope this mistake will not appear again after the revision. Well, since I've been looking for the answer on the Internet for so long, of course, I have to record something useful, so as not to go to Google next time ~

Since I have adopted the lnmp one-click installation package, if there is a problem, I must go to the official forum to search first. That's great. The official has such a top post. Let's have a look first.

Lnmp one-click installation package official:

The first reason: at present, there are many problems with one-click installation packages of lnmp, which is 502 bad gateway. In most cases, the reason is that some lib packages in the script may not be installed before installing php, resulting in the failure to compile and install php successfully. Solution: You can try to install it manually according to the script in the lnmp one-click installation package to see what the error is.

The second reason:

In php.ini, the eaccelerator configuration item must be placed before zend optimizer configuration, otherwise it may also cause 502 bad gateway.

The third reason:

In the process of installation and use, there are 502 problems, generally because the default number of php-cgi processes is five, which may be caused by insufficient phpcgi processes. It is necessary to modify/usr/local/PHP/etc/PHP-fpm.conf to increase the max_children value appropriately.

The fourth reason:

Php execution timed out. Modify /usr/local/php/etc/php.ini to change max_execution_time to 300.

The fifth reason:

Insufficient disk space, such as mysql logs taking up a lot of space.

The sixth reason:

See if the php-cgi process is running.

Some netizens also gave another solution:

Nginx 502 bad gateway means that the requested php-cgi has been executed, but the php-cgi process is terminated due to some reason (generally the problem of reading resources). Generally speaking, nginx 502 bad gateway is related to the setting of php-fpm.conf.

Php-fpm.conf has two crucial parameters, one is max_children and the other is request_terminate_timeout, but this value is not universal and needs to be calculated by itself. In the process of installation and use, there are 502 problems, generally because the default number of php-cgi processes is five, which may be caused by insufficient phpcgi processes. It is necessary to modify/usr/local/PHP/etc/PHP-fpm.conf to increase the max_children value appropriately.

The calculation method is as follows:

If your server performance is good enough, broadband resources are sufficient, and there are no loops or bugs in the php script, you can directly set the request_terminate_timeout to 0s. 0s means to keep php-cgi running without time limit. If you can't do this, that is to say, there may be a bug in your php-cgi, or your broadband is not enough or other reasons cause your php-cgi to fake death, then I suggest you assign a value to request_terminate_timeout, which can be set according to the performance of the server. Generally speaking, the better the performance, the higher you can set it, from 20 minutes to 30 minutes. And how is the value of max_children calculated? In principle, the larger the value, the better. If there are more processes in php-cgi, it will be processed quickly, and there will be fewer requests queued. Setting max_children also needs to be set according to the performance of the server. Generally speaking, the memory consumed by each php-cgi in a server is about 20m.

According to the official answer, the relevant possibilities were investigated, and the following solutions were obtained by combining the answers of netizens.

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

Code: netstat-anpo | grephp-CGI | WC-l

5 (if 5 is displayed)

2. View the current process

Code: top Observe the number of fastcgi processes. If the number of processes used is equal to or higher than 5, it means that it needs to be increased (depending on the actual situation of your machine).

3. Adjust the related settings of/usr/local/PHP/etc/PHP-fpm.conf.

1060smax_children has at most 10 processes, with 20mb of memory per process and 200mb at most. The execution time of request_terminate_timeout is 60 seconds, which is 1 minute.