微信公众号：运维开发故事，作者：double冬

1、背景

本文主要是写的最近比较影响深刻的一次排查客户访问业务前端域名，报504，timeout错误问题的记录，该客户为私有化部署，给客户部署的服务存在跨洲调用，没有专线，澳洲调用欧洲的服务情况，可能存在网络延迟比较大，需要排查504的具体原因，然后通过优化参数临时解决

2、排查步骤和思路

2.1 故障现象沟通

对于toB的客户来说，通常在使用我们产品的时候，报错只会反馈一个截图，我们需要向客户沟通或者关键的信息，有利于问题排查

img

比如：

• 打开的什么页面，便于自己复现

• 具体报错的接口是哪个？

• 大概的报错时间

• 如果有x-request-id，拿到请求id

• 具体报错的url

img

2.2 梳理整个访问请求的链路

我们需要了解，浏览器上的请求链路，才能更好的去排查问题，比如我遇到的这个问题，请求链路是这样的

客户机器访问浏览器域名 -> 私有端域名cdn(1) -> 私有端 SLB(2) -> 私有端 nginx(3)-> saas端服务域名cdn (4) -> saas端 SLB (5) -> saas 端nginx(6) -> saas端业务后端服务

每个公司的业务情况不一样，根据自己的实际情况梳理

2.3 查看日志

• 第一次问题排查

通过第一步故障现象的沟通，获取的内容，然后去看链路上nginx(3)，即私有端nginx的日志，想确认请求是否到达了服务器，根据 x-request-id搜索到日志，时间点和path也能对上，状态码是504，请求时间是30s，页面多次刷新都是30s超时

img

于是检查nginx上的配置，发现该接口location里面的后端服务器响应时间，proxy_read_timeout时间设置为30s，相当于nginx会等待30s的时间来获得请求的响应，如果在30s内如果响应接收不完，就会报出来504 timeout

img

于是，修改了将进行proxy_read_timeout时间修改为了300s，然后reload一下nginx

img

• 第二次问题排查

客户反馈访问页面依赖报错504，timeout，于是继续看nginx的日志，怀疑是不是没生效，但是查看日志之后发现报错状态码变了，是499，并且都是request_time为60s，其实就相当与客户端的请求打到了Nginx上，Nginx把请求转到后转服务器A，由于nginx的proxy_connect_timeout 超时时间默认的60s，就会导致Nginx把客户端的请求转到服务器A的时候，就会尝试连接60s，而客户端的响应时间设的是30s，所以造成客户端造成大量超时情况，Nginx报大量的499

img

然后经过查阅之后，发现需要增加参数proxy_ignore_client_abort修改为on，想看看真实情况，于是在报错的location下增加了之后reload了nginx

img

继续观察日志，发现日志又变了，是报504 180s

img

此时开始怀疑是nginx之后的saas端nginx的的问题，然后根据 x-request-id搜索到日志，发现请求确实到了saas端，但是很明显，日志打印出来的200，请求时长是60s

img

于是根据上面的链路情况，怀疑到了saas端和私有端的saas端slb (5) 上，经过客户核实，他们用的阿里云的slb，默认的最大连接请求超时时间为180s，基本上和私有端的nginx里面的日志大量出现180s超时能对应上

img

于是提工单给阿里云客服，咨询是否可以调大，结论是不可以，监听器http和https协议的最大只能180s（其实人家是有道理的，这完全是由于我们私有端在澳洲，saas端在欧洲，跨洲访问的结果），但是客服说可以采用tcp协议，能够支持900s，于是新建了一个tcp协议的监听器，连接超时时间也设置为350s（为了与nginx上的proxy_read_timeout区别开），然后把私有端的upstrem转发的地址端口改成新的测试，客户答复访问正常

• 第三次问题排查

是我太天真了，以为完全解决了，但是第二天客户反馈，随机性还是会出现504超时，期间让客户用浏览器无痕模式打开，清理浏览器缓存，依旧偶尔出现，影响客户体验，因此有了第三次问题排查

依旧先去查看私有端nginx的日志，无异常，状态码都是200，只是请求响应时间比较长超过60s了

img

img

查看saas端的nginx日志也是正常的

img

然后就不理解了，问题出在哪里，然后让客户如果再次出现，就把报错接口的copy url出来，然后手动在服务器请求url，能够复现出来504，并且是nginx给返回的

img

于是在私有端一边手动请求，一边tcpdump抓包，发现也是正常的tcp三次握手连接，http正常请求返回，无异常

img

img

但是在请求返回的数据上，发现了一个端倪，server并不是nginx，我们的nginx因为修改过名字，叫Sws，所以刚才请求的时候nginx 504 timeout，不是我们业务侧返回的，然后就怀疑到了请求链路上私有端 SLB(2) 上，于是找客户确认，访问的域名虽然走了cdn加速，但是会回源到这个slb上，然后监听器的连接超时时间设置的的确是60s，然后客户修改成180s，之后两天没有出现过超时的问题了

3、排查过程中的知识点

3.1 在nginx中 499状态码的定义和处理方法

• 查看Nginx源码

当客户端主动关闭链接时，http状态代码中没有可以表示该状态的，但在nginx又需要记录，所以自定义了一个499这个状态来表示。

*
* HTTP does notdefine the code for the case when a client closed
* the connectionwhile we are processing its request so we introduce
* own code to logsuch situation when a client has closed the connection
* before we even tryto send the HTTP header to it
* 
*/
#define NGX_HTTP_CLIENT_CLOSED_REQUEST 499

所以显然，客户端端主动关闭请求或者客户端网络断掉时，于是nginx就记录了499状态，并且断开了和后面服务端的连接（这样可能导致服务端返回数据时，因为连接断开而报错）

img

• 解决499问题

1、查看服务端为什么响应这么慢，是否需要优化，或者调大客户端方的连接超时时间，不那么快断开

2、proxy_ignore_client_abort参数调整

这个参数表示忽略客户端终止情况，默认为off关闭状态，当客户端网络中断请求时，nginx 服务器中断其对后端服务器的请求，并立即记录 499 日志。

设置为 on 开启，则nginx会忽略客户端中断，并一直等着代理服务执行返回，记录后端返回的请求的状态。

        location =/api { 
            proxy_ignore_client_abort   on; 
            proxy_pass  http://service_backends;
        } 

这个参数的意思是：在客户端主动关闭连接后， nginx 与分发服务器的连接是否保持连接。如果参数设置了on，则客户端如果断开连接，nginx也不会断开与后端服务端的连接，nginx会等待后端处理完(或者超时)，然后记录「后端的返回信息」到日志。所以，如果后端返回 200，就记录 200 ；如果后端放回 5XX ，那么就记录 5XX 。如果超时(默认60s，可以用 proxy_read_timeout 设置)，Nginx 会主动断开连接，记录 504。

注意：开启后nginx只会在读取超时时关闭连接，默认为60s，可能出现请求连接挤压的情况，所以默认情况下是关闭。如果开启必须设置好proxy_read_timeout超时时间，并且nginx最好别做反向代理以外的事情。

这个方案只是解决了两个问题：（1）nginx上499的错误（2）服务端因为连接断开报Broken pipe的错误

所以最好的方法还是优化服务端

3.2 nginx中的时间解释

这个时间有没有取决于nginx的日志格式log_format里是否配置

• request_time:指的就是从接收用户请求的第一个字节到发送完响应数据的时间，即$request_time 包括接收客户端请求数据的时间、后端程序响应的时间、发送响应数据给客户端的时间。(request processing time in seconds with a milliseconds resolution; time elapsed between the first bytes were read from the client and the log write after the last bytes were sent to the client 。)

• up_resp_time/upstream_response_time:指nginx从后端获取结果的处理时间，从nginx和后端建立连接开始，到关闭连接为止，连接的后端地址为upstream_addr值。(keeps times of responses obtained from upstream servers; times are kept in seconds with a milliseconds resolution. Several response times are separated by commas and colons like addresses in the $upstream_addr variable)

• up_addr/upstream_addr:后端服务地址。

• request_time时间肯定是要比up_resp_time要大的。

3.3 nginx中proxy相关的参数解释

• proxy_connect_timeout :后端服务器连接的超时时间_发起握手等候响应超时时间(代理连接超时)默认60s

• proxy_read_timeout:它决定了nginx会等待多长时间来获得请求的响应(代理接收超时)默认值60s

• proxy_send_timeout :后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据(代理发送超时)默认值60s

4、总结

• 当前修改配置参数实际上属于非标准操作，本文只是提供一个自己在排查过程的思路方向，每个问题的情况和背景不一样，需要各自结合实际情况来调整

• 该问题主要还是跨洲访问，没有走专线，网络这边不稳定会导致在请求的时候出现超时问题，然后根据具体的问题现在通过调整配置来临时解决这个问题，让客户能正常使用，客户是上帝

• 不要畏惧问题，所有的问题总能找到原因，不能一味的归结到是网络的问题，重启大法来解决，我们其实可以定位得更细，需要知其然知其所以然

公众号：运维开发故事

github：https://github.com/orgs/sunsharing-note/dashboard

博客**：https://www.devopstory.cn**

爱生活，爱运维

我是冬子先生，《运维开发故事》公众号团队中的一员，一线运维农民工，云原生实践者，这里不仅有硬核的技术干货，还有我们对技术的思考和感悟，欢迎关注我们的公众号，期待和你一起成长！