5 ways to fix the 502 bad gateway error in nginx plus php fpm

There are many reasons for the presence of nginx 502, but most of them can be attributed to the insufficient number of resources. That is to say, the back-end php-fpm process has problems. nginx sent the correct client request to the back-end php-fpm process, but the php-fpm process failed to properly parse the php code, and finally returned to the client 502 error.

The reason why the server appears 502 is the connection timeout. We sent a request to the server. Because the server has too many links at present, the server could not give a normal response

So if you have a lot of server concurrency, you can only add machines and optimize them in the following ways to get better results. But if you don't have a lot of concurrency and you have 502,1 it can all come down to configuration issues, script timeout issues.

1. Insufficient number of php-fpm processes

Use netstat-napo |grep "php-fpm" | wc-l to view the current number of fastcgi processes. If the number is close to the upper limit configured in conf, you will need to increase the number of processes.

You can adjust the number of php-fpm sub-processes to 100 or more, depending on the server's memory, or just 200 on a server with 4G memory.

2. Turn up the number of open files in linux kernel

You can use these commands (must be an root account)

echo 'ulimit -HSn 65536' >> /etc/profile
echo 'ulimit -HSn 65536' >> /etc/rc.local
source /etc/profile

3. Script execution time timeout

If for some reason the script waits too long to return and the incoming request cannot be processed, it can be configured as follows.

nginx.conf is mainly as follows

fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;

php-fpm.conf is as follows

request_terminate_timeout = 10s

4. Small cache Settings

Modify or add configuration to nginx.conf

proxy_buffer_size 64k;
proxy_buffers  512k;
proxy_busy_buffers_size 128k;

5.recv() failed (104: Connection reset by peer) while reading response header from upstream

Possible cause of network packet loss in the computer room or hardware firewall blocking access to the domain name

But the most important thing is to set a timeout in your program, so don't use php-fpm's request_terminate_timeout,

request_terminate_timeout=0;

Because this parameter will kill the php process directly, and then restart the php process, the front-end nginx will return 104: Connection reset by peer. This process is very slow, the overall feeling is that the website is very stuck.

May 01 10:50:58.044162 [WARNING] [pool www] child 4074, script '/usr/local/nginx/html/quancha/sameip/detail.php' execution timed out (15.129933 sec), terminating
May 01 10:50:58.045725 [WARNING] [pool www] child 4074 exited on signal 15 SIGTERM after 90.227060 seconds from start
May 01 10:50:58.046818 [NOTICE] [pool www] child 4082 started

The most important thing is to control the timeout in the program, gethostbyname, curl, file_get_contents, gethostbyname, file_get_contents and so on.

The other is to say, this thing is to increase the interactivity of the site, but use more reaction is slow, if you website timeout and use more say, can shut it down.