场景描述
5月1号中午收到求助，客服反馈 APP 上面某些功能无法使用，业务 RD 反馈访问第三方公司服务有问题并且及时联系了第三方公司，访问的URL举例如下，http://abc.k8s.vip/hackness/selfie_hack_detect 和 http://abc.k8s.vip/identity/selfie_idnumber_verification 会出现 Connection reset（这里把第三方公司的域名替换为abc.k8s.vip，保护下第三方公司隐私
），但第三方公司反馈他们业务正常，未发现异常，他们把问题反馈到运维这边，其实看到出现 Connection reset，只是猜测应该问题很好定位。
抓包分析
出现问题时，不要上来就说，不是我的问题，我这里没有问题，是你那边的问题，网络同学也不要说网络没有问题，是业务代码的问题，说是没有任何意义的，相互扯皮也是浪费时间，涉事双方或多方，在线上业务出现问题时，最重要的是证明自己所负责的没有问题，如果有业务日志足以证明的情况下，可以拿日志说话，用实事数据说话，还有就是经常性的网络问题时，在ping、telnet、traceroute、mtr都无法查到问题的情况下，可以通过抓包分析问题出在了什么地方。
图 1：客户端抓包
如果不会抓包，可以Google或者百度下，稍微有经验的人，一眼就可以判断问题出在什么地方。客户端与服务器端三次握手正常，当客户端向服务器端 PUSH 数据的时候，服务器端不再响应，而是从数据包看是发了RST，异常断链，出现这种情况，如果服务器端也抓个包，就可以更容易分析问题了，可惜，第三方没有提供抓的包。到这里，我初步判断是中间防火设备、或者ACL策略导致出现了问题。（全军覆没，没有一个正确处理的数据包）
此时由于我方访问第三方的是http，而第三方提供了https，第三方工作人员建议尝试使用https，修改代码上线后，再次抓包。（数据包通信正常）
图 2：客户端抓包
再次抓包，发现数据包通信正常了，但反馈业务还无法使用，通过日志发现，除一核心接口外，其它接口均正常，哪个不行的接口使用 Curl https 可以访问，说明第三方业务 https 正常，但为什么使用线上代码，不可以呢？通过对比 RD 得出结论是部分代码使用 http 框架有问题（暂且认为是这个原因），RD 修改代码，肯定来不及。为什么第三方的http不可以呢？
与某云技术交涉过程
此时第三方的同学也没有闲着，他们与某云技术支持去沟通了，为什么访问他们的 SLB 有问题，把图 1 客户端抓包截图，给某云后，给的答复如下。
从数据包看，肯定是中间设备进行了拦截，因为客户那边反馈，直接Curl也没有问题，把我司出口IP全部提供给了某云技术，由他们去查，答复如下。
从上面的回复看，也证明了判断，并且也说明了三次握手成功。
并且给出了可能拦截的原因，如下。
到这里基本上可以判断是某云给拦截了，但为什么修改成https后，通信就正常了呢，再次与某云技术确认，他们给出了拦截原因，并且说拦截与协议无关，就说明无论访问http或者https时，都会访问到。
再次与他们交涉，最终也证实了我的想法。某云拦截策略与协议有关，http进行了拦截，https没有进行拦截，https都是加密数据，估计是没有办法
解决
第三方提醒我们，需要使用 https 去访问他们（ https 我司代码有问题），但需要先恢复业务，第三方把我司出口公网 IP，添加到某云的白名单中，业务再由 https 修改加 http 后，访问正常了。
结论
RD 同学反馈业务代码已经多日未更新、第三方反馈代码也未有变更操作、网络同学也反馈、网络未做调整、与第三方连通性正常（ telnet 和 ping ），为什么会导致 Connection reset 呢？此时通过抓包分析，往往可以解决问题，本次故障发现了三个问题：
1. 把我司出口 IP，添加到某云白名单中，即可通过 http 访问，业务可快速恢复（目前采用）；
2. RD 反馈的使用 https 无法访问的问题，需要 RD 修改使用的框架，这个后续解决（排期解决）；
3. 为什么我司会去攻击阿里云，阿里监控到了什么，已经由安全部对线上的服务器进行排查（安全介入）。
您的关注是写作的动力
往期分享
警惕！四层、七层负载乱用，Java lettuce连接池故障一例
