负载均衡 RST 是什么
负载均衡与代理在健康检查失败、会话保持过期、后端被摘除或连接数触顶时会主动发出 RST。识别它的关键在于判断这枚重置报文的来历：它通常紧跟请求且没有任何后端响应，与正常响应的序列号不连续，IP TTL 与响应时延也常与后端实际回包不同。最有力的证据是前后端双侧抓包对照——如果后端侧根本没有记录到这次请求，说明连接在负载均衡处就被终止了。把这类重置当成后端崩溃的证据，会把排查方向彻底带偏。
基本信息
| 常见触发 | 健康检查失败、会话保持到期、后端摘除、连接数限流 |
|---|---|
| 抓包判据 | RST 紧跟请求且其后无任何后端响应 |
| 验证方法 | 前后端双侧抓包对比连接是否被重建 |
| 关注字段 | tcp.flags.reset、RST 的 IP TTL 与帧时间 |
| 旁证 | 发生时刻与健康检查周期吻合 |
典型使用场景
- 定位重置来源：区分是客户端、负载均衡还是后端发出的 RST
- 会话保持核查：确认保持超时时间是否短于业务空闲间隔
- 发布与缩容分析：后端被摘除期间出现批量重置属预期行为
- 限流验证：确认连接数限制触发的拒绝形态是立即重置而不是排队等待
- 与真实故障区分：后端自身崩溃产生的重置通常伴随后端侧记录
线索清单
线索清单
tcp.flags.reset == 1 && tcp.stream == N # 定位重置报文所在流
# 1) RST 是否紧跟请求且其后无后端响应
# 2) RST 的 TTL 是否与后端正常回包一致
# 3) 发生时刻是否与健康检查周期吻合
# 4) 后端侧抓包与日志是否记录到该请求RST 来源判别
| 发出方 | 线索 | 后端是否有记录 |
|---|---|---|
| 客户端 | 本地抓包即见，序列号延续正常 | 有 |
| 负载均衡 | 紧跟请求、TTL 与延迟特征不同于后端、时刻与检查周期吻合 | 无 |
| 后端 | 重置前后有后端正常报文与日志痕迹 | 有 |
代理型负载均衡会保持两条独立的 TCP 会话，前后端的五元组与流编号都不相同，比较时要分别在两侧定位对应业务流，而不是逐包对齐。
把重置的时间戳与设备健康检查间隔对齐看一眼，往往能直接锁定来源；这是投入产出比最高的一个核对动作。