客户端Connection reset by peer怎么办？——可能只是被劫持了

        

网络问题排查基本就是扯皮，扯不清也道不明。

在cdn厂商多年，质量问题排查出来的结论：中间设备劫持连接了。然而客户爸爸们总觉得我们是甩锅，逃避cdn质量问题。最近又碰到一个客户投诉问题，为了让更多的人了解确实存在劫持过程，打算写下此文。

某客户A在我司的cdn之后，被我们节点reset的请求占比高。并且客户的日志分析就有较高的ip聚集性。可是每次被reset的客户ip不固定，客户只有真实用户手机上报的失败信息，不能配合双端抓包。真是“人在家中坐，锅从天上来”，查呗，就是专业干这个活的。

首先，需要客户描述的，分析出关键信息。 reset是关键信息，但啥时候被reset也是非常关键的。比如建联握手的时候给reset，连接关闭的时候给reset了等等。结果客户还真提供了详细场景“真实端用户发送完get请求，还没收到包就给reset了。” 非常关键的信息是在发送完get，还未收到服务端任何数据。

其次，尽量找到疑似现场。 根据客户描述的场景，现在就是要找到疑似现场了。但客户端ip不固定，机器上有其他域名的流量，全量抓包在排查也是大海捞针。客户配合排查的意愿还低。还得自己来啊，刚好组内新开发的定制化的抓包工具，能针对各种场景抓包。

运气不错，还就抓包的疑似现场，如下图所示，发送完get请求还没有发送出数据就被reset关闭连接。但跟客户描述也有小出路，明明是客户发送的reset，并不是我们主动关闭发送的reset。