2.排查步骤和思路
2.1 故障现象沟通
对于toB的客户来说，通常在使用我们产品的时候，报错只会反馈一个截图，我们需要向客户沟通或者关键的信息，有利于问题排查。
比如：
- 打开的什么页面，便于自己复现
- 具体报错的接口是哪个？
- 大概的报错时间
- 如果有x-request-id，拿到请求id
- 具体报错的url
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超时。
于是检查nginx上的配置，发现该接口location里面的后端服务器响应时间，proxy_read_timeout时间设置为30s，相当于nginx会等待30s的时间来获得请求的响应，如果在30s内如果响应接收不完，就会报出来504 timeout。
于是，修改了将进行proxy_read_timeout时间修改为了300s，然后reload一下nginx。
- 第二次问题排查
客户反馈访问页面依赖报错504，timeout，于是继续看nginx的日志，怀疑是不是没生效，但是查看日志之后发现报错状态码变了，是499，并且都是request_time为60s，其实就相当与客户端的请求打到了Nginx上，Nginx把请求转到后转服务器A，由于nginx的proxy_connect_timeout 超时时间默认的60s，就会导致Nginx把客户端的请求转到服务器A的时候，就会尝试连接60s，而客户端的响应时间设的是30s，所以造成客户端造成大量超时情况，Nginx报大量的499。
。然后经过查阅之后，发现需要增加参数proxy_ignore_client_abort修改为on，想看看真实情况，于是在报错的location下增加了之后reload了nginx。
继续观察日志，发现日志又变了，是报504 180s。
此时开始怀疑是nginx之后的saas端nginx的的问题，然后根据 x-request-id搜索到日志，发现请求确实到了saas端，但是很明显，日志打印出来的200，请求时长是60s。
于是根据上面的链路情况，怀疑到了saas端和私有端的saas端slb (5) 上，经过客户核实，他们用的阿里云的slb，默认的最大连接请求超时时间为180s，基本上和私有端的nginx里面的日志大量出现180s超时能对应上。
于是提工单给阿里云客服，咨询是否可以调大，结论是不可以，监听器http和https协议的最大只能180s（其实人家是有道理的，这完全是由于我们私有端在澳洲，saas端在欧洲，跨洲访问的结果），但是客服说可以采用tcp协议，能够支持900s，于是新建了一个tcp协议的监听器，连接超时时间也设置为350s（为了与nginx上的proxy_read_timeout区别开），然后把私有端的upstrem转发的地址端口改成新的测试，客户答复访问正常。
- 第三次问题排查
是我太天真了，以为完全解决了，但是第二天客户反馈，随机性还是会出现504超时，期间让客户用浏览器无痕模式打开，清理浏览器缓存，依旧偶尔出现，影响客户体验，因此有了第三次问题排查。
依旧先去查看私有端nginx的日志，无异常，状态码都是200，只是请求响应时间比较长超过60s了。
查看saas端的nginx日志也是正常的。
然后就不理解了，问题出在哪里，然后让客户如果再次出现，就把报错接口的copy url出来，然后手动在服务器请求url，能够复现出来504，并且是nginx给返回的。
于是在私有端一边手动请求，一边tcpdump抓包，发现也是正常的tcp三次握手连接，http正常请求返回，无异常。
但是在请求返回的数据上，发现了一个端倪，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状态，并且断开了和后面服务端的连接（这样可能导致服务端返回数据时，因为连接断开而报错）。
- 解决499问题
- 查看服务端为什么响应这么慢，是否需要优化，或者调大客户端方的连接超时时间，不那么快断开
- 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.总结
- 当前修改配置参数实际上属于非标准操作，本文只是提供一个自己在排查过程的思路方向，每个问题的情况和背景不一样，需要各自结合实际情况来调整。
- 该问题主要还是跨洲访问，没有走专线，网络这边不稳定会导致在请求的时候出现超时问题，然后根据具体的问题现在通过调整配置来临时解决这个问题，让客户能正常使用，客户是上帝。
- 不要畏惧问题，所有的问题总能找到原因，不能一味的归结到是网络的问题，重启大法来解决，我们其实可以定位得更细，需要知其然知其所以然。
