持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第31天,点击查看活动详情
1.写在前面
在上周某天6点的时候,同事A,过来找了我!!!(内心:该死的下班6点)
同事A说:“阿深,你好呀,有个问题,可以帮我看下嘛?”
我:“嗯嗯,行。”(屁颠屁颠就去到了同事A的工位)
我内心:“这,我还能拒绝嘛?什么鬼玩意,怎么总是在下班的时候找我?”
然后看到同事A,正在远程实施人员B的电脑,处理某个网站的问题。
同事A就说:“我这边通过nginx+tomcat的环境下,通过域名访问网站,出现页面某个请求,超过15s的时候,就会出现504 gateway timeout的问题”。
这么一听,心想:“这不就是nginx超时了嘛,配置一下nginx,估计就能解决。”
嘿嘿,哥们也能准时下班了吧!!!^_^
我就说,这个配置一下nginx的超时时间,应该就可以了吧。
可是同事A说,我已经配置过了,已经增加了nginx的超时时间了。但是还是会出现超时。
我:“这。。。可能这问题,就不简单了!!!”
看来,还是不能准时下班了。
那就开始问题的寻找吧,开干!!!
2.问题排查
2.1nginx.conf配置修改
网上大部分的都是这样的答案:
- nginx.conf
keepalive_timeout 600;
fastcgi_connect_timeout 600;
fastcgi_send_timeout 600;
fastcgi_read_timeout 600;
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
还是不行,一样出现504的异常
那就再搜索网上答案,加buffer缓冲
proxy_buffer_size 16k;
proxy_buffers 4 64k;
proxy_busy_buffers_size 128k;
proxy_temp_file_write_size 128k;
#读取fastcgi应答第一部分需要多大缓冲区,该值表示使用1个128kb的缓冲区读取应答第一部分(应答头)
fastcgi_buffer_size 128k;
#指定需要多少和多大的缓冲区来缓冲fastcgi应答请求
#设置nginx的fastcgi缓冲区为8x128k
fastcgi_buffers 8 128k;
#默认值是fastcgi_buffers的两倍
fastcgi_busy_buffers_size 256k;
#写入缓存文件使用多大的数据块
fastcgi_temp_file_write_size 256k;
加上了,还是不行,一样出现504的异常
这就有点头疼了!!!
2.2nginx.conf配置,是否被使用?
然后,就在想,修改的nginx.conf配置文件,是否被使用到呢?
nginx -t
通过上面的命令,查看nginx启动时,所用到的配置文件。
答案,确实是我们用到的配置文件。
2.3nginx.conf配置,是否生效?
我们先关闭nginx进程
nginx -s stop
然后通过域名,再访问网站。
好家伙,这个时候,居然还能正常访问。
然后,我就问同事A,你们是有多个nginx的嘛?
同事A的回答是,不是吧,我们只有一个nginx的。
我说,但是我已经关闭了nginx了,还是正常访问到。你这肯定是有多个nginx的了。
然后看了一下ssh连接工具。
好家伙,被我逮到了吧,你这明显有两个nginx了。
同事A,一脸懵逼(可能他也是接手以前同事的项目,估计也不是很熟悉整个框架)
行,那我们再讲nginx2的进程关闭了。
再次访问系统,已经是无法访问到了。
哎,到这里,咋们好像看到了曙光!!!^_^
估计这里生效的就只有nginx2的服务器里面的nginx。
这说明了啥?
说明了我们之前修改的nginx.conf配置文件,一直都改错地方了。
这里,咋们马上再修改nginx2服务器的nginx。看看效果!!!
还是不行,还是报了504 gateway timeout的错。
瞬间,又失去了准时下班的机会了!!!行吧,继续找吧!!!
2.4查看nginx的日志文件,是否又报错?
tail -f log/access.log
tail -f log/error_log.log
分别查看了访问日志,错误日志,均无发现又异常的信息
也没有看到超时的字眼。
哎呀,这就奇怪了?难道是tomcat报的超时?
2.5查看tomcat的日志文件,是否又报错?
- 查看日志命令
tail -f log/catalina.out
也是很奇怪,没看到有报错的信息。
这就蒙圈了呀!!!
不过,问题还是得解决!!!
不知不觉,时间快到7点了,咋办呢?
这个时候,同事A的电话响起,好家伙,他女朋友打电话来催他了。
哎,这个是好事呀,我说:你这个问题紧急嘛?要不明天再看看?
同事A,马上说不紧急,毕竟他也想走了。
哈哈,大家都不咋想加班!!!行,给个台阶大家,先溜了,第二天再看看吧。
2.6验证直接访问tomcat,看下是否会出现超时问题?
第二天上班,继续处理这个问题。
我们先测试一下,直接访问tomcat,看下会不会出现超时的问题?
直接ip加端口访问,好家伙,不通呀。我就问同事A,什么情况?网络不通的嘛?
同事A反馈说,他也不太清楚。
我想了一下,是不是开了防火墙,然后把防火墙关了,直接ip+端口访问,通了。
然后测试下,那个功能,这个接口,正常了!!!
好像问题越来越近了!!!
那就说明了,不是tomcat的问题了,是nginx的问题了。
真相越来越近了!!!
2.7验证nginx的问题?
- 超时15s的问题(ajax方向找)
该项目,用的是传统的jquery,这个ajax,我记得默认是不会设置超时时间的呀。
默认值为0
,表示没有超时。
- 超时15s的问题(nginx配置方向找)
我查看了nginx下的conf文件夹,里面所有的配置文件,都没有出现15这个字眼。
验证到这里,我们也是有点懵逼了。好像找不到原因了。
难道是nginx的问题?
行,那我们重新安装一个新的nginx。
2.8重新安装nginx,进行验证?
接着,我们重新装了个nginx。
好家伙,还是出现了15s超时!!!
验证到这里,有点放弃的感觉!!!
突然直接,灵机一动:
我们刚才直接测试tomcat的时候,是直接通过ip+端口,进行访问的。
那我们这里也试一下,直接通过ip+端口,访问nginx。
2.9ip+端口,直接访问nginx,进行验证?
直接访问项目:192.168.4.xxx:8090/llsydn
因为nginx监听的端口为8090,通过这个域名访问,出现了有写js,css加载不了。
这里估计进行了防盗链的处理。
行吧,那我们再将nginx的端口改为80,然后再访问一便。
进入到项目,然后测试下,那个功能,这个接口,正常了!!!
哇,这就行了?
看到这里,哥们大概知道问题所在了:
通过域名访问,就报了504 gateway timeout
通过ip+端口直接访问nginx,就无问题。
这就说明了,不是我们nginx的问题,也不是tomcat的问题。
是域名的问题,罪魁祸首是域名。
应该是域名,转发到我们的服务器的时候,域名那边做了配置,15s超时。
行吧,既然发现了问题。我就叫同事A,将相关测试的结果,直接反馈给实施人员B。
叫实施人员B,去处理域名转发的问题了。
问题解决了,完美!!!
哈哈,今天能准时下班了吧?
3.总结
很多时候,我们遇到问题的时候,要尝试从不同的方向进行验证。
程序员,还是得不断折腾,才能有进步吧。
哈哈,有时候遇到得问题,不一定都是咋们的问题,有可能是别人的问题。
咋们对自己还是得有点信息,哈哈!!!
好了,以上就是一次线上ngix的504 gateway timeout排查的全过程了。
这里分享了一些,可以进行验证的思路,遇到类似问题的时候,大家伙可以参考一下。
个人理解,可能也不够全面,班门弄斧了。
好了,今天就先到这里了!!!^_^
个人理解,可能也不够全面,班门弄斧了。
如果觉得有收获的,帮忙点赞、评论、收藏
一下呗!!!