RST 的高频来源
RST 表示立即中止连接，它本身是结果而不是原因。常见来源包括：端口没有监听、连接状态丢失后仍然收到数据、应用主动中止连接、中间设备因超时或策略注入重置、以及协议栈收到不属于任何连接的数据。定位的关键是把每个 RST 与它前面的报文成对看。
基本信息
| 常见场景 | 端口拒绝、传输中止、空闲后状态失同步 |
|---|---|
| 抓包过滤 | tcp.flags.rst == 1 |
| 细分写法 | tcp.flags.rst == 1 && tcp.flags.ack == 0 |
| 判断方法 | 把 RST 与前置报文成对分析，孤立看无效 |
| 相关字段 | tcp.analysis.flags 可辅助定位 |
典型使用场景
- 连接刚建立就被断开，判断是否为端口或策略问题
- 传输过程中突然失败，确认是应用中止还是设备注入
- 长时间空闲后收到重置，核对保活与老化设置
- 客户端报错「连接被重置」时确认重置来自哪一侧
- 负载均衡健康检查引发的重置与业务流区分
配套过滤
配套过滤
tcp.flags.rst == 1 # 全部重置报文
tcp.flags.rst == 1 && tcp.flags.ack == 0 # 直接重置（不回确认）
tcp.flags.rst == 1 && ip.src == 10.0.0.9 # 只看某一侧发出的重置
tcp.stream == N && tcp.flags.rst == 1 # 指定会话中的重置场景速查
| 出现位置 | 含义 | 后续动作 |
|---|---|---|
| SYN 后立即出现 | 端口未监听或策略拒绝 | 核对监听状态与访问控制 |
| 数据传输中出现 | 连接被中止 | 查应用关闭逻辑与中间设备 |
| 空闲一段时间后出现 | 状态失同步 | 核对老化时间与保活设置 |
| 不对应任何连接 | 协议栈无法匹配 | 检查是否存在半开连接 |
RST 是结果而非原因，先找出「谁先破坏了连接状态」的那一端，再谈处理方案。
负载均衡健康检查失败也会产生重置记录，与业务流区分开再统计。
补充要点
- 统计重置数量时按方向分组，能区分是服务端拒绝还是客户端中止
- 把重置时刻与发布、重启等运维动作对齐，常能立刻找到原因
- 应用主动中止连接属于正常设计时，不应把它统计成异常
- 把重置与前置报文一起导出，是给他人说明问题最有效的方式
对同一目标的大量连接集中出现重置，通常指向端口关闭或策略变更，而不是网络链路问题。