RST 判读是什么
复位报文是连接被强制中断的信号，也是排障中最容易被误读的一类报文。判读要回答三个问题：是谁发出的、发生在哪个阶段、有没有可能是中间设备伪造。响应建连请求的复位通常意味着端口没有监听或被策略拒绝；传输过程中出现的复位多是应用异常退出或主动中断；长时间空闲之后出现的复位，往往来自中间设备清理会话表。先分清这三种情形，再去找对应的责任方。
基本信息
| 适用平台 | 图形化抓包工具及其命令行版本 |
|---|---|
| 过滤字段 | 复位标志等于 1，可再叠加地址与端口条件限定范围 |
| 判读三要素 | 发出方地址、发生阶段、是否伴随确认标志 |
| 常见来源 | 服务端应用、客户端应用、负载均衡与防火墙等中间设备 |
| 留证要点 | 记录复位报文的帧号、时间与前后文，便于与对方核对 |
典型使用场景
- 连接刚建立就被中断，判断是端口没监听还是策略拒绝
- 传输中途连接突然断开，确认是应用异常还是链路问题
- 长连接空闲一段时间后断开，排查中间设备的会话老化
- 用户报「连接被重置」但服务端日志没有记录，用抓包确认复位来自哪一侧
- 验证修复：调整会话保持或超时参数后，重新抓包确认复位消失
定位与判读
定位与判读
tcp.flags.reset == 1 # 全部复位报文
tcp.flags.reset == 1 && ip.src == 10.0.0.5 # 指定发出方
tcp.flags.reset == 1 && tcp.flags.ack == 1 # 带确认的复位，多为进程主动中断
tcp.flags.syn == 1 && tcp.flags.reset == 1 # 对建连请求直接复位
tcp.flags.reset == 1 && tcp.time_delta > 60 # 长时间空闲后出现的复位
tcp.stream eq 12 && tcp.flags.reset == 1 # 单条会话内的复位形态与根因
| 形态 | 含义 | 常见根因 |
|---|---|---|
| 响应建连请求的复位 | 端口不可用 | 端口无监听、被策略拒绝或服务未就绪 |
| 传输中段的复位 | 连接被强行中断 | 应用崩溃或主动中止、连接被对端清理 |
| 长时间空闲后复位 | 会话过期 | 中间设备会话老化或保活探测失败 |
| 序号异常的复位 | 不是正常协议行为 | 多为中间设备注入或伪造 |
| 复位后立刻重连 | 客户端重试行为 | 属正常重试逻辑，重点看第一次复位原因 |
判读复位报文要结合前后文：只看单帧只能知道「被断了」，把复位帧与它之前的最后几帧一起看，才能判断触发条件。报文详情里的序列号分析面板会标注该复位对应的是哪一帧。
不要看到复位就归咎对端服务：复位报文可能由链路上任意一台设备发出，源地址也不一定可信。先确认发出方与链路位置，再去找对应责任方，否则沟通方向从一开始就是错的。