Nginx 502 Bad Gateway Error Resolution _nginx

Some websites running on Nginx sometimes appear as "502 Bad Gateway" errors, some times even frequently. The following is a small compilation of some of the Nginx 502 error troubleshooting Methods for reference:

The reason for the Nginx 502 error is more due to a problem with the backend server in Agent mode. These errors are generally not nginx itself problem, must look for the reason from the back end! But nginx all these mistakes in their own body, really let Nginx promoter is questioned, after all, from the word understanding, bad gateway? Is it bad nginx? Let the people who do not understand, will directly put the responsibility on the Nginx body, Hope Nginx the next version will be a little bit more friendly error tips, at least not a simple one now 502 bad Gateway, in addition, also do not forget to attach their name.

Trigger conditions for Nginx 502

The most common occurrence of 502 errors is the back-end host machine. There is a configuration in the upstream configuration: Proxy_next_upstream, which specifies that Nginx will go to the next back-end host when it encounters data from a back-end host, which is written with 502 of all cases pulled, default is error Timeout Error is when the machine, disconnection and so on, timeout is read blocking timeout, more easily understood. I usually write all of them:

Proxy_next_upstream Error timeout invalid_header http_500 http_503; But now maybe I'm going to get rid of http_500, http_500 specifies that the backend returns a 500 error to a host, the back-end JSP error, 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 the time to explain the principle of 502 ...

503 error can be retained, because the back end is usually Apache resin, if the Apache panic is error, but resin panic, is only 503, so it is necessary to retain.

Solutions

If you encounter 502 problems, you can take the following two steps as a priority.

1, see the current number of PHP fastcgi process is sufficient:

Copy Code code as follows:

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

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

2, some of the PHP program execution time than the Nginx wait time, you can appropriately increase the nginx.conf configuration file fastcgi timeout time, such as:

Copy Code code as follows:

HTTP {
Fastcgi_connect_timeout 300;
Fastcgi_send_timeout 300;
Fastcgi_read_timeout 300;
......
}
......

PHP.ini Memory_limit set low will be wrong, modified php.ini memory_limit 64M, restart Nginx, found good, the original is the memory of PHP is not enough.

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

I. Max-children and Max-requests

A server running Nginx PHP (FPM) XCache, the average daily traffic around 300W PV.

Recently, there is often such a situation: PHP page Open very slowly, the CPU usage rate suddenly dropped to very low, the system load suddenly rise to very high, check the traffic card, you will find that suddenly dropped to very low. This situation only lasts a few seconds to recover.

Check the PHP-FPM log file to find some clues.

Copy Code code as follows:

Sep 08:32:23.289973 [NOTICE] Fpm_unix_init_main (), line 271:getrlimit (nofile): max:51200, cur:51200 Sep 30 08:32:23.2 90212 [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 08:32:23.296426 [NOTICE] Fpm_init (), line 47:fpm I s running, PID 30587

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

Originally, PHP-FPM has a parameter max_requests, which indicates that each children will be shut down when the maximum number of requests is processed, and the default setting is 500. Because PHP is the request polling to each children, in large traffic, each childre to the max_requests time spent almost, so that all the children basically at the same moment was closed.

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

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

Open/usr/local/php/etc/php-fpm.conf The following two parameters (according to the actual server, too large or not)

Copy Code code as follows:

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

Then restart the php-fpm.

Second, increase the size of buffer capacity

Open the Nginx error log and discover the "Pstream sent too big header while reading response header from upstream". Looked at the data, to the effect that the nginx buffer has a bug caused by the page consumption of our site may be too large. Reference to the foreigner wrote the modification method increases the buffer capacity size setting, 502 problem thoroughly solves. The system administrator then adjusted the parameters to retain only 2 set parameters: Client head buffer,fastcgi buffer size.

Third, Request_terminate_timeout

If it's mostly in the case of post or database operations, rather than being 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 execution script time of the fast-cgi.

0s

0s to be closed, is to carry out indefinitely. The problem was solved, and there was no error in the execution for a long time. Optimize the fastcgi, can also change this value 5s to see the effect.

There are 502 errors in php-cgi processes, long PHP execution time, or php-cgi process death.

Nginx 502 Bad Gateway Error Resolution 2

Today, my VPS frequently prompts Nginx 502 Bad Gateway error, restart the VPS after the solution appeared again, very annoying. A little think Impassability, the first two days of the site reached 1290 of the traffic is nothing wrong, how this time the 502 bad Gateway? Depressed Ah!!! In search for a long time, and finally found a number of relevant answers, I hope that the changes will not appear this error. Alas, since on the internet for so long the answer, that of course must be useful things recorded, lest I go to Google next time ~

As I was using the LNMP one-button installation package, out of the question must first go to the official forum to search under, really good, the official has such a sticky post, we first see.

LNMP One-button installation package The official:

The first reason: the current LNMP a key installation package more problems is 502 bad Gateway, most of the reason is in the script before installing PHP, some of the Lib package may not be installed, resulting in PHP did not compile the installation success.
Workaround: Try installing it manually according to the script in the LNMP one-click installation package to see what the error is causing.

Second reason:

In php.ini, eaccelerator configuration items must be placed before Zend optimizer configuration, or it may cause 502 bad Gateway

Third reason:

There are 502 problems with the installation process, typically because the default php-cgi process is 5, which can result in 502 due to insufficient phpcgi processes and needs to be modified/usr/local/php/etc/php-fpm.conf Max_ The children value is increased appropriately.

Fourth reason:

PHP execution Timeout, modify/usr/local/php/etc/php.ini change Max_execution_time to 300

Fifth reason:

Insufficient disk space, such as the MySQL log takes up a lot of space

Sixth reason:

To see if the php-cgi process is running

Also has the netizen to give the other solution:

Nginx 502 Bad Gateway means that the requested php-cgi has been executed, but the php-cgi process is terminated for some reason (typically a problem reading the resource), and generally Nginx bad Gateway and php-fpm.conf settings are related.

Php-fpm.conf has two critical parameters, one is Max_children and the other is request_terminate_timeout, but the value is not universal, but it needs to be calculated by itself.
There are 502 problems with the installation process, typically because the default php-cgi process is 5, which can result in 502 due to insufficient phpcgi processes and needs to be modified/usr/local/php/etc/php-fpm.conf Max_ The children value is increased appropriately.

The method of calculation is as follows:

If your server performance is good enough and broadband resources are sufficient, PHP scripts do not have loops or bugs, you can set the request_terminate_timeout directly to 0s. The meaning of 0s is to allow php-cgi to carry on without any time limit. And if you can't do this, which means that your php-cgi may have a bug, or that your broadband isn't enough or that other reasons are causing your php-cgi to die, then it's recommended that you assign a value to Request_terminate_timeout. This value can be set according to the performance of the server. Generally the better performance you can set the higher, 20 minutes-30 minutes can be.
And Max_children This value is how to calculate it? This value is in principle the bigger the better, the php-cgi process will be processed more quickly, the queue of requests will be very little. Setting the Max_children also needs to be set according to the performance of the server, in general, a server normally consumes about 20M of memory per php-cgi.

According to the official answer, to troubleshoot the relevant possibility, and combined with the user's answer, came to the following solution.

1, view the PHP fastcgi number of processes (Max_children value)

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

5 (if shown 5)

2. View current Process

Code: Top
Observe the number of fastcgi processes, if the number of processes used is equal to or higher than 5, indicating the need to increase (depending on the actual situation of your machine)

3, adjust the relevant settings of/usr/local/php/etc/php-fpm.conf

<value name= "Max_children" >10</value>
<value name= "Request_terminate_timeout" >60s</value>
Max_children up to 10 processes, 20MB memory per process, up to 200MB.
The Request_terminate_timeout execution time is 60 seconds, which is 1 minutes.