nginx的502和504

迈不过友情╰ 2022-01-20 01:35 242阅读 0赞

问题：最近bi系统因为oom和tomcat假死会不定时页面502和504  
5月28  14.18.05 502 Bad GateWay  
5月29  10.05.53 504 GateWay Time-Out  
5月16  13.22.17 504 GateWay Time-Out   oom  
3.23  11.55.56  502 Bad GateWay

## 502 Bad Gateway ##

作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。  
1）在 php.ini 和 php-fpm.conf 中分别有这样两个配置项：max\_execution\_time 和 request\_terminate\_timeout。  
这两项都是用来配置PHP脚本的最大执行时间的。当超过这个时间时，PHP-FPM不只会终止脚本的执行，还会终止执行脚本的Worker进程，所以Nginx会发现与自己通信的连接断掉了，就会返回给客户端502错误。或者是tomcat请求和等待对列均已满，连接根本没有建立成功也会返回502.  
解决 ：调整php.ini 和 php-fpm.conf两个配置项：max\_execution\_time 和 request\_terminate\_timeout  
2）后台tomcat最大连接数已经达到最大请求数，新进来的连接tomcat直接拒绝。此时nginx应该也是返回502

## 504 Gateway Time-out ##

作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。  
504 的错误的产生原因:  
1）Tomcat没有超时，而你的 Nginx 超时了。由于你使用 Nginx 的反向代理功能，所以，这个时候 Nginx 就是相当于一个网关 Gateway。此时应该修改nginx.conf的超时配置：  
　  fastcgi\_connect\_timeout 300s;  
　　fastcgi\_send\_timeout 300s;  
　　fastcgi\_read\_timeout 300s;  
　　这里规定了PHP-CGI的连接、发送和读取的时间，300秒足够用了  
2）504也可能是由于nginx默认的fastcgi进程响应的缓冲区太小造成的, 这将导致fastcgi进程被挂起, 如果你的fastcgi服务对这个挂起处理的不好, 那么最后就极有可能导致504   
　　现在的网站, 尤其某些论坛有大量的回复和很多内容的, 一个页面甚至有几百K，默认的fastcgi进程响应的缓冲区是8K, 我们可以设置大点，即在nginx.conf里, 加入:  
　　fastcgi\_buffers 8 128k  ：表示设置fastcgi缓冲区为8×128k现在的网站  
借鉴：https://www.jianshu.com/p/cd7e7e87bdbf

## 502转成504 ##

在 php.ini 和 php-fpm.conf 中分别有这样两个配置项：max\_execution\_time 和 request\_terminate\_timeout。  
这两项都是用来配置一个 PHP 脚本的最大执行时间的。当超过这个时间时，PHP-FPM不只会终止脚本的执行，还会终止执行脚本的Worker进程。所以Nginx会发现与自己通信的连接断掉了，就会返回给客户端502错误。  
PHP-FPM设置的脚本最大执行时间已经够长了，但执行耗时PHP脚本时，发现Nginx报错从502变为504了。这是为什么呢？  
因为我们修改的只是PHP的配置，Nginx中也有关于与上游服务器通信超时时间的配置。  
以Nginx超时时间为90秒，PHP-FPM超时时间为300秒为例，则会报504 Gateway Timeout错误，Nginx错误访问日志如下：  
 2018/09/19 00:55:51 \[error\] 27600\#0: \*78877 upstream timed out (110: Connection timed out) while reading response header from upstream,   
 client: 192.168.1.101, server: test.com, request: "POST /index.php HTTP/1.1", upstream: "fastcgi://unix:/dev/shm/php-fcgi.sock:",   
 host: "test.com", referrer: "http://test.com/index.php"

网络问题分析过程可以参考下面文章------记一次生产环境Nginx间歇性502的事故分析过程：  
https://xiezefan.me/2017/09/27/nginx-502-bug-trace/

参考：[https://www.jianshu.com/p/cd7e7e87bdbf][https_www.jianshu.com_p_cd7e7e87bdbf]

[https://xiezefan.me/2017/09/27/nginx-502-bug-trace/][https_xiezefan.me_2017_09_27_nginx-502-bug-trace]

[https://www.cnblogs.com/xiamidong/p/4105583.html][https_www.cnblogs.com_xiamidong_p_4105583.html]

[https_www.jianshu.com_p_cd7e7e87bdbf]: https://www.jianshu.com/p/cd7e7e87bdbf
[https_xiezefan.me_2017_09_27_nginx-502-bug-trace]: https://xiezefan.me/2017/09/27/nginx-502-bug-trace/
[https_www.cnblogs.com_xiamidong_p_4105583.html]: https://www.cnblogs.com/xiamidong/p/4105583.html