问题：客户银企平台放在一台虚拟机，农业银行前置机部署在公司内网一台实体机，兴业银行部署在另一台实体机，兴业银行账号查询余额等业务稳定运行，农行账号查余额经常报错（偶现但是频率较高），在银企平台与银行交互日志中报错堆栈为：

Caused by: java.net.SocketException: Connection reset

 at java.net.SocketInputStream.read(SocketInputStream.java:168)

 at com.kingdee.bos.ebgateway.communication.FilterInputStream.read(FilterInputStream.java:51)

分析流程：

1、看到这个报错，第一反应是农行前置机服务器给银企发送了RST导致连接关闭，但是银行方日志显示是我们（银企）主动关闭了一个连接，日志如下：

2、显然银企和兴业银行前置机能正常稳定交互，说明银企平台本身并无异常，所以这就有点扯不清楚。于是客户那边怀疑是农行前置机那台服务器与银企的网络可能不稳定等问题，就将农行前置机安装到兴业银行前置机同一台服务器，然而该问题依旧。

3、问题到这里，我们在银企服务器，农行前置机服务器（tcp：15999端口）两侧分别用wireshark抓包，如下：

如上分析我们得到结论：

1、前置机看到有一个来自银企端的RST。

2、但是从银企端的抓包看，它并没有发送过RST。

结论只能是中间设备发送的RST，可能是有什么安全策略引发。

4、于是告知客户让去排查是否有第三方中间设备有设置安全策略干预导致，并行我也怀疑是否有中间设备针对某些端口做了控制（要不然为啥兴业银行（8007端口），农行银行（15999端口），就与农行前置机交互有该问题），于是我让将农行前置机开放给我们的15999端口改成15888，再次测试发现问题依旧....

5、当天客户那边排查到了，关闭了他们买了一个第三方的安全控制策略（深信服防火墙）就没有该问题了，非常稳定.......具体是如何设置的怎么样的控制策略暂还不清楚，等现场同事再继续了解同步信息给到我们。

问题进展到这里基本已破案，个人认为跟我第4点的怀疑应该也有关系，只不过可能15888也在控制策略限制范围内。

总结：该类问题从两侧业务日志可能无法准确定位问题根因，于是需要抓包分析（最好是双抓），结合两端的报文才能将tcp流交互流程看的更清晰。