Collection of nginx 502 Bad fault causes and solutions

For example, the website has encountered a 502 error frequently recently, which means it cannot run properly. Most of these problems are caused by PHP-CGI timeout without returning information, or process freezing. Our nginx has been configured to the extreme, and these have been modified earlier, but now it appears again.

After analysis, I opened the nginx Error Log and found an error message like "pstream sent too big header while reading response header from upstream". I checked the information, this error is caused by a bug in the nginx buffer zone. The page consumption on our website may occupy too much buffer space. According to the modification method written by foreigners, the buffer capacity setting was added, and the 502 problem was completely solved. Later, the system administrator adjusted the parameters and kept only two setting parameters: client head buffer, fastCGI buffer size.

Reference: Generation

Http: // www. sudone. com/nginx/nginx_400_bad_request.html

Http: // blog. rackcorp. com /? P = 14

2. When nginx was installed on the Forum at a high load yesterday, 502 Bad Gateway keeps appearing when the Forum uploads images or executes scripts for a long time, most of them are the solution of Master Zhang. His solution is

 

1

http

2

{

3	fastcgi_connect_timeout 300;

4	fastcgi_send_timeout 300;

5	fastcgi_read_timeout 300;

6

}

 

Added the request time for FastCGI. However, I encountered this problem in practice. Setting it to 500 still appears, but it is less than setting it to 120. Later, it was found that this problem mainly occurred in some post or database operations. Static pages would not appear.

The number of CGI processes is also increased through repeated queries and debugging.

Server, IP address query, mobile phone number, proxy, weather forecast, train time, ID card number, plane flight, Xinhua Dictionary query, etc. S6 B4 \) Y & C (\! J)]

Adding 256 may be slow. Memory usage is high. 123cha. COM1 U &}. P1 [7 B % L/\ 0 \

Another item in the php-fpm.conf settings, may not be noticed at that time, accidentally changed this value.

Request_terminate_timeout

The value is max_execution_time, which is the script execution time of fast-CGI.

0 s 123cha.com * s (v, U9 D5 Q6 t; I * z6 u-r

If 0 s is disabled, it is executed infinitely. (When I did not look carefully at fashion, I changed a number)

If the problem is solved, the execution will not go wrong for a long time.

In FastCGI optimization, you can change the value to 5 s. View results

Finally, we found that the 502 error is not an nginx problem,

If the PHP-CGI process is insufficient, the PHP Execution time is long, or the PHP-CGI process is dead, the error 502 will occur.

III,

Nginx PHP (FPM) xcache is running on one server, with an average traffic volume of around 300 PVS per day

Recently, this situation often occurs: the PHP page is very slow to open, the CPU usage suddenly drops to a very low level, the system load suddenly rises to a very high level, view the network card traffic, you will also find that suddenly fell to a very low level. In this case, it takes only a few seconds to recover.

Check the log file of PHP-FPM and find some clues.

Before the preceding statements, there are more than 1000 lines of logs for disabling children and enabling children.

Originally, PHP-FPM has a max_requests parameter, which specifies the maximum number of requests processed by each children will be disabled. The default value is 500. Because PHP round-robin requests to every children, in the case of high traffic volumes, each Childe takes almost the same time to reach max_requests, which causes all children to be shut down at the same time.

During this period, nginx cannot forward the PHP file to PHP-fpm for processing, so the CPU will be reduced to a very low level (no PHP processing or SQL Execution is required ), the load will rise to a very high level (turn off and enable children, nginx and wait for PHP-FPM), Nic traffic will also fall to a very low level (nginx cannot generate data to the client) O "], o w $ q/V1 x * d

It is easy to solve the problem. Increase the number of children and set the value of max_requests to 0 or a relatively large value, and restart PHP-FPM.

 

IV,

There are many causes of nginx 502 errors because of problems with backend servers in proxy mode. These errors are not nginx problems, so you must find the cause from the backend! However, nginx has put all these errors on its own, which makes it highly questionable for nginx promoters. After all, we can understand the word "Bad Gateway? Isn't it bad nginx? People who do not know it will directly put the responsibility on nginx. I hope the next version of nginx will make the error prompt slightly more friendly, at least it's not a simple 502 Bad Gateway statement, and I don't forget to attach my name to it.

The most common occurrence of 502 errors is that the backend host is on the machine. In the upstream configuration, there is a configuration: proxy_next_upstream, which specifies what errors nginx will encounter when retrieving data from a backend host to the next backend host, it indicates that all the situations of 502 will be pulled. The default value is error timeout, error indicates the machine, disconnection, and so on. Timeout indicates read congestion timeout, which is easy to understand. I generally write all of them:

Proxy_next_upstream error timeout invalid_header http_500 http_503;

However, now I may want to remove the http_500 option. When http_500 specifies that the backend will return a 500 error, it will convert it to a host. If the backend JSP fails, a bunch of stacktrace error messages will be printed, it is now replaced by 502. But programmers in the company do not think so. They think that nginx has encountered an error. I really don't have time to explain the 502 principle to them ......

Invalid_header I didn't take it into account, so I also wanted to get it down first.

503 error can be retained, because the backend is usually Apache resin. If Apache crashes, it is error, but resin crashes, it is only 503, so it is necessary to keep it.

 

Yesterday, a friend asked me how to solve the "502 Bad Gateway" error when he changed the Web server to nginx 0.6.31 + PhP 4.4.7 (FastCGI.

I will follow the two steps below to solve the problem, and finally increase the timeout time of FastCGI to 2nd in step 1. Solve the problem:

PS: I envy Thunder's web server, with 16 GB of memory.

1. Check whether the current PHP FastCGI process count 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, it indicates that the number of FastCGI processes is insufficient and needs to be increased.

2. If the execution time of some PHP programs exceeds the nginx waiting time, you can add the FastCGI timeout time in the nginx. conf configuration file, for example:

 

01

......

02

http

03

{

04

......

05	fastcgi_connect_timeout 300;

06	fastcgi_send_timeout 300;

07	fastcgi_read_timeout 300;

08

......

09

}

10

......

 

For detailed solutions, see;Nginx 502 503 error Triggering Conditions and SolutionsTotal