彻底弄懂502/503/504（php-fpm+nginx）亲测可用

事业运财运爆棚

已于 2024-12-11 17:36:40 修改

阅读量622

点赞数 4

文章标签： php nginx 开发语言

于 2024-11-01 21:52:31 首次发布

本文链接：https://blog.csdn.net/whf1215847706/article/details/143441116

版权

HTTP响应返回502与504意味着什么？

首先得搞清楚502错误和504错误的区别，以我比较熟悉的PHP为例，502是PHP-FPM（PHP的进程管理器没办法从进程池里找到可分配的进程来处理请求了，就会返回502错误，本质上是PHP进程状态异常—进程不够用了或者PHP服务根本就没开启），这种情况下应该检查PHP服务是否启动了，如果启动了，就要看一下是不是进程池太小，已经全部处于繁忙状态，这种情况下通常将PHP的可用进程数提高数提高就能解决问题；而504错误是网关超时，它代表负责处理HTTP请求的PHP进程超过了约定的最长时间仍未返回处理结果，出现这种异常的原因通常是sql执行的时间太长或代码里出现了死循环之类的问题。

遇到502怎么办？

好了，下面说一下遇到502错误时怎样判断PHP进程数是否够用，办法是很简单的，思路就是看一下目前开启了多少个PHP-CGI进程，再看一下目前非空闲状态的PHP-CGI进程，如果这两个数是接近的，就意味着当出现新请求时，容易引起502错误，需要将前面开启的PHP-CGI进程数增加。命令如下： 1.查看服务器上一共开了多少的 php-cgi 进程

代码语言：javascript

复制

ps -fe |grep "php-fpm"|grep "pool"|wc -l

2.目前有多少个php-cgi进程在处理tcp请求

代码语言：javascript

复制

netstat -anp|grep "php-fpm"|grep "tcp"|grep "pool"|wc -l

在内存容量充足的情况下，这两个数应该拉开一定的差距，如果差距很小，则在有多个新请求过来时，容易出现502错误。

遇到504怎么办？

上面说了，504意味着执行代码超时了，所以最直接的办法是先去看一下数据库的慢日志（slow log），看最新的数据库慢日志记录，如果就是刚刚发生的，并且执行的时间长度是特别长，甚至长到与你服务器网关超时的时间相近的，那不要想了，就是这里的问题，把相应的SQL优化好就行了，如果数据库的慢日志里并没有明显异常的情况，那就得考虑是不是代码里有耗时太长的逻辑，或有与外部接口通讯的代码，因为网络延时或对方响应时间太长，而你的异常机制没做好，导致你的代码一直在等待对方响应，间接造成你的代码超时了。

相信大家都遇到过50X的问题,网上也看了很多文章,总是各种不对,所以今天咱们详解各种出现50X的情況和原
502:Bad Gateway作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。
503:Service Unavailable由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是临时的,并且
将在一段时间以后恢复。如果能够预计延迟时间,那么响应中可以包含一个Retry-After头用以标明这个延迟时
间。如果没有给出这个Retry-After信息,那么客户端应当以外处理500响应的方式处理它。
504:Gateway Time-out作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的
服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DINS)收到响应。
nginx+php出现502bad gateway,一般这都不是nginx的问题,而是由于fastcgi或者php的问题导致的,常见的有
以下几种。
1.php-fpm进程挂掉或者重启,大家可以service php-fpmstop然后再打开php页面就返回502
nginx错误日志:
*153514 connect) to unix:/dev/shm/php-cgi.sock failed (2: No such file or directory) while connecting to upstrea
m
所以平时我们要平滑重启kill-USR2pid就不会报错了
2.php-fpm平滑重启时也是有可能有502的,大家可以打开一个sleep(10)的页面,然后service php-fpm reload
或者kill -USR2 pid测试
php-fpm错误日志:
/phpmianshi.com/test.php' (request: "GET /test.php") executing too slow
主要原因是:php-fpm.conf中process_control_timeout 设置过小造成的
process_control_timeout参数解释

参数含义是设置子进程接受主进程复用信号的超时时间.控制子进程处理来自master的信号的时间,默认为0.如果
正在处理请求,很可能会收到错误报警。建议将此参数设置为相同的值request_terminate_timeout,以便worker
有时间完成处理请求,否则将会中断。
3.request_terminate_timeout设置的过小,php没有执行完就被中断,大家可以设置小一点,写一个sleep脚本
测试
php-fpm错误日志:
[18-May-2020 19:37:47] WARNING: [pool www] child 7906, script/data/wwwroot/mianshiphp/test.php' (reques
t: "GET /test.php") executing too slow (1.295579 sec), logging [18-May-2020 19:37:47] WARNING: [pool www] c
hild 7906, script '/data/wwwroot/mianshiphp/test.php' (request: "CGET /test.php") execution timed out (1.62924
7 sec), terminating [18-May-2020 19:37:47] WARNING: [pool wwwchild 7906 exited on signal 15 (SIGTERM) aft
er 72.682120 seconds from start
4.nginx fastcgi_read_timeout设置过小,返回504
比如:设置fastcgi_read_timeout=1,php脚本sleep(3),则返回504
php-fpm错误日志:
[18-May-2020 20:01:47] WARNING: [pool www] child 12044, script '/data/wwwroot/mianshiphp/test.php' (reque
st: "GET /test.php") executing too slow (1.235212 sec), loggirng
5.当服务器压力过大,没有更多的php-fpm处理请求时,返回504
比如设置php-fpm进程数为1,压力测试ab-n 100-c 20 http://phpmianshi.com/?id=90
有文章说,压力过大,没有足够的php-fpm处理时会返回502,我这里测试是不对的,而是部分请求返回了200,其
他请求返回了504
说明当php-fpm不足时,是有一个等待队列存在的。已经接到请求的php-fpm会返回200,长时间得不到php-fpm
处理的请求就返回了504,
那么这个等待队列是什么呢?分析如下:
其实就是php-fpm.conf中的listen.backlog配置,当backlog队入列满了,会出现502错误,
首先查看php活跃的套接字:ss-In |grep-E'php|Netid"
Netid State Recv-Q Send-Q Local Address:Port
2768 /dev/shm/php-cgi.sock 79562794
Peer Address:Port
u_str_LISTEN
* 0
关注Recv-Q和Send-Q这两个字段。
LISTEN状态:Recv-Q表示的当前等待服务端调用 accept完成3三次握手的listenbacklog数值,也就是说,当客户
端通过connect(去连接正在listen()的服务端时,这些连接会一直处于这个queue里面直到被服务端accept0;S
end-Q表示的则是最大的listenbacklog数值,这就就是上面提到的min(backlog,somaxconn)的值。
于是修改listen.backlog=1,同时开ab-n5-c52https://www.phpmianshi.com/backlog.php测试,发现所有
请求又都返回200了
ss -In |grep -E 'php/Netid'
Netid State
Recy-Q Send-Q Local Address:Port
Peer Address:Port
u str LISTEN 3
3
2768 /dev/shm/php-cai.sock 79562794
过一会Recv-Q慢慢减少到0,所有请求执行完成,说明php-ffpm并没有拒绝后两次请求
具体原因如下:
当queue满了之后,服务器并不会按照理论所述,不再对SYN进行应答,返回 ETIMEDOUT。根据这篇文档的描
述,服务器会随机的忽略收到的SYN,建立起来的连接数可以无限的增加,只不过客户端会遇到延时以及超时的
情况。
总结:适当增加max_children还是有用的,这样的话php-fpm能同时处理的请求增加,客户端的延迟等待时间也会
相应的减小。
6.当遇到这个状态码的时候表示服务临时不可用,比如nginx配:置了频率限制而client端又超过了配置的限制后就会
收到503的响应。
其他待补充...
总结:
解决问题的最好的方式还是自己去看nginx和fastcgi的errorlog。
最后做个总结:php-cgi进程数不够用、php执行时间长、或者是php-cgi进程死掉,都会出现502错误。
当nginx收到了无法理解的响应时,就返回502。当nginx超过自己配置的超时时间还没有收到请求时,就返回504错误。

公司一台测试服务器，最近出现504和502问题:(环境LNMP,php编译安装，Fastcgi模式），问题不难解决，但这里分享一下自己的排查思路和处理问题的方式。

504 Gateway Time-out，nginx 502 bad gateway

一、分析问题：

Nginx 504 Gateway Time-out的含义是没有请求到可以执行的PHP-CGI。

Nginx 502 Bad Gateway的含义是请求的PHP-CGI已经执行，但是由于读取资源的等没有执行完毕而导致PHP-CGI进程终止。

二、排查步骤：

1）查看Nginx是否可以正常解析php文件（解析正常）

2）查看Nginx访问日志和php日志(日志报错，锁定问题）

2.1.1）Nginx相关日志

failed (104: Connection reset by peer) while reading...
timed out (110: Connection timed out) while reading response...
2.1.2）php相关日志

WARNING: child 25718 exited on signal 15 (SIGTERM) after 21008.883410 seconds from start
3）查看php和nginx相关配置（Fastcgi相关参数）

......

3.1.1）Nginx和Fastcgi常用相关参数：

fastcgi_connect_timeout 60;

#指定连接到后端FastCGI 的超时时间。

fastcgi_send_timeout 60;

#向FastCGI 传送请求的超时时间，这个值是指已经完成两次握手后向FastCGI 传送请求的超时时间。

fastcgi_read_timeout 300;

#接收FastCGI 应答的超时时间，这个值是指已经完成两次握手后接收FastCGI 应答的超时时间。

fastcgi_buffer_size 4k;

#指定读取FastCGI 应答第一部分需要用多大的缓冲区，一般第一部分应答不会超过1k，由于页面大小为4k，所以这里设置为4k。

fastcgi_buffers 8 4k;

#指定本地需要用多少和多大的缓冲区来缓冲FastCGI 的应答。

fastcgi_busy_buffers_size 8k;

#默认值是fastcgi_buffers 的两倍。

fastcgi_temp_file_write_size 8k;

#在写入fastcgi_temp_path 时将用多大的数据块，默认值是fastcgi_buffers 的两倍。

fastcgi_cache TEST

#开启FastCGI 缓存并且为其制定一个名称。

fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;

#为指定的应答代码指定缓存时间，如上例中将200，302 应答缓存一小时，301 应答缓存1 天，其他为1 分钟。

fastcgi_cache_min_uses 1;

#缓存在fastcgi_cache_path 指令inactive 参数值时间内的最少使用次数，如上例，如果在5 分钟内某文件1 次也没有被使用，那么这个文件将被移除。
3.1.2）查看进程使用情况

netstat -autpn|grep "php-cgi"|wc -l
3.1.3）查看Nginx和Fastcgi相关配置

fastcgi_connect_timeout 60;
fastcgi_send_timeout 60;
fastcgi_read_timeout 60;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
调整时间，根据之前经验300s足够，最主要的设置是前三条：

fastcgi_connect_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_read_timeout 300s;
3.1.4)调php相关参数：

php.ini

max_execution_time = 60
php-fpm.conf:

request_terminate_timeout=300s
#默认是0
3.1.4.1）上述参数作用

两项都是用来配置PHP脚本的最大执行时间的。当超过这个时间时，PHP-FPM不只会终止脚本的执行，还会终止执行脚本的Worker进程。因此Nginx发现与自己通信的连接断掉了，就会返回给客户端502错误。

3.1.4.2）参数具体配置方式：

如果服务器性能足够好，且宽带资源足够充足，PHP脚本没有系循环或BUG的话你可以直接将”request_terminate_timeout”设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。

”max_children”也需要根据服务器的性能进行设定，一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右，可根据自己的配置具体定义。

3.1.5）502和504可能存在的其它问题

3.1.5.1）Nginx的max_fail，fail_timeout问题

3.1.5.2）网络偶然问题

3.1.5.3）参数配置冲突问题（eg:php.ini和php-fpm，Nginx配置Fastcgi指定了相关参数）