持续创作，加速成长！这是我参与「掘金日新计划 · 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排查的全过程了。
这里分享了一些，可以进行验证的思路，遇到类似问题的时候，大家伙可以参考一下。
个人理解，可能也不够全面，班门弄斧了。
好了，今天就先到这里了！！！^_^
个人理解，可能也不够全面，班门弄斧了。
如果觉得有收获的，帮忙点赞、评论、收藏一下呗！！！