Summary of solutions for nginx 502 Bad Gateway

Cause

1. PHP FastCGI Process count is insufficient
When the number of concurrent accesses to the website is huge, the number of php fastcgi processes is not guaranteed, because cgi works in a single thread and multiple processes, that is to say, cgi needs to process a page before continuing the next page. If the number of processes is not enough, when the access is huge, cgi processes the previous requests in line, and the subsequent requests will only be abandoned. In this case, nginx may encounter a 502 error from time to time.

2. PHP FastCGI memory is insufficient

When nginx returns a static page, this problem will not occur, because nginx directly returns a static page without php cgi processing. However, when a webpage needs to handle a large number of php complex operations, such as api collection or page collection, php requires a high level, if the configured memory is too small, it will easily cause php to crash.

1. First, determine whether the 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. But pay attention to whether your memory is sufficient to support more processes. If the physical machine memory is not large enough, increasing the number of processes is useless.
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 as follows:
Http
{
......
Fastcgi_connect_timeout 300;
Fastcgi_send_timeout 300;
Fastcgi_read_timeout 300;
......
}
......
An error occurs when memory_limit is set to low in php. ini. After modifying memory_limit of php. ini to 64 MB, restart nginx and check that PHP memory is insufficient.
If the above method still cannot solve the problem, please try to optimize your php program, minimize collection and database operations as much as possible, and speed up its response, sometimes it is caused by the slow response speed of your php program.

3: at present, the lnmp one-click installation package has many problems: 502 Bad Gateway. Most of the reasons are that some lib packages in the script may not be installed before php is installed, as a result, php is not compiled and installed successfully.
Solution:

You can try to manually install the lnmp installation package according to the script in the one-click installation package to see what caused the error. Search for it online or send the error message. Let's analyze the cause of the error.

4:

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

The third reason is:
502 problems occur during installation and use. Generally, the default php-cgi process is five, which may be caused by insufficient phpcgi processes, you need to modify/usr/local/php/etc/php-fpm.conf to add the max_children value as appropriate. (Generally, one php-cgi occupies 20 MB of memory. Set this value based on the memory)
It is also possible that the max_requests value is insufficient.

5:

Php execution time-out. Modify/usr/local/php/etc/php. ini and change max_execution_time to 300.

Fifth reason:
Insufficient disk space. For example, mysql logs occupy a large amount of space.

6:

Check whether the php-cgi process is running

You can use the # top command to view details.

Nginx Reverse proxy solution is a bit different

Open the error log of nginx and find an error message such as "pstream sent too big header while reading response header from upstream". I checked the information, this is caused by a bug in the nginx buffer zone. The page consumption on our website may occupy too much buffer space.

The header returned by apache is too large to be processed by nginx.

The code is as follows:

Copy code

Server { Listen 80; Server_name * .xywy.com; Large_client_header_buffers 4 16 k; # Charset KOI8-R; # Access_log off; Location /{ # Add the three rows, Proxy_buffer_size 64 k; Proxy_buffers 32 32 k; Proxy_busy_buffers_size 128 k; Proxy_set_header Host $ host; Proxy_set_header X-Real-IP $ remote_addr; Proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for; Set $ baiduspider ''; If ($ http_user_agent ~ Baiduspider ){ Set $ baiduspider Baidu;           } ............   For nginx + PHPcgi Fastcgi_connect_timeout 60; Fastcgi_send_timeout 180; Fastcgi_read_timeout 180; Fastcgi_buffer_size 128 k; Fastcgi_buffers' 4 256 k; Fastcgi_busy_buffers_size 256 k; Fastcgi_temp_file_write_size 256 k; Fastcgi_intercept_errors on 011/01/07 11:12:57 [error] 10770 #0: * 38585340 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 116.22.131.154, server: * .xywy.com, request: "GET/ysmp/index. php? Did = 124994 HTTP/1.0 ", upstream:" http: // 127.0.0.1: 8080/ysmp/index. php? Did = 124994 ", host:" xywy.yn16.com"

 

Then there was a new error.

Upstream timed out timeout?

The code is as follows:	Copy code
Server { Listen 80; Server_name * .xywy.com; Large_client_header_buffers 4 16 k; Client_max_body_size 300 m; Client_body_buffer_size 128 k; Proxy_connect_timeout 600; Proxy_read_timeout 600; Proxy_send_timeouts 600; Proxy_buffer_size 64 k; Proxy_buffers 4 32 k; Proxy_busy_buffers_size 64 k; Proxy_temp_file_write_size 64 k; # Charset KOI8-R; # Access_log off;

Request_terminate_timeout

If it is common in some post or database operations, rather than static page operations, you can look at one of the php-fpm.conf settings:

Request_terminate_timeout

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

0 s

If 0 s is disabled, it is executed infinitely. (When I did not look at it carefully, I changed the number.) after 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 to see the effect.