5 ways to solve a 502 bad gateway error in nginx plus php fpm

  • 2020-05-07 20:50:40
  • OfStack

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 has a problem in processing. nginx sends the correct client request to the back-end php-fpm process, but the php-fpm process fails to properly parse the php code, and finally returns the client 502 error.

The reason for the server's 502 is the connection timeout. We sent a request to the server. Because the server has too many links at the moment, the server cannot give a normal response

So if you have a lot of server concurrency, you can only add more machines and then optimize them in the following way for 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 timeouts.

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 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 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, you can appropriately reduce the following configuration.

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 the computer room has a hardware firewall to prevent access to the domain name

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

request_terminate_timeout=0;

Because this parameter kills the php process directly, and then restarts the php process, the front-end nginx returns 104: Connection reset by peer. This process is very slow, the overall feeling is that the site 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

Said 10000, 1000 road, the most important thing is to program control the timeout, gethostbyname, curl, file_get_contents function to set the timeout.

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


Related articles: