RST 来源判断在说什么
连接被重置时，关键不只是「有没有 RST」，而是「谁发的」。三类来源的处理方向完全不同：目标主机内核在端口无监听时回 RST 加 ACK；对端应用崩溃或主动放弃连接时发出 RST；中间设备（防火墙、负载均衡、会话老化）也可能伪造 RST。判断线索有三条：确认号能否与被拒绝的报文对上、TTL 是否与同一路径的正常回包一致、以及报文出现的位置与时间是否与业务行为吻合。
基本信息
| 抓取写法 | tcp[tcpflags] & tcp-rst != 0 |
|---|---|
| 无确认的复位 | tcp[tcpflags] = tcp-rst |
| Wireshark 过滤 | tcp.flags.rst == 1 && tcp.flags.ack == 0 |
| 判断线索 | 确认号对应关系、TTL、链路时延、出现位置 |
| 辅助证据 | 服务端监听状态、应用日志、设备会话表 |
来源判读对照
| 特征 | 来源 | 进一步确认方式 |
|---|---|---|
| 建连即被重置，响应极快 | 目标主机内核，端口未监听 | 在服务端核对监听的地址与端口 |
| 传输中突然重置，此前数据正常 | 对端应用主动放弃或崩溃 | 对照应用日志与进程存活时间 |
| 重置的 TTL 与正常回包不同 | 中间设备伪造 | 对比同路径正常报文的 TTL 与延迟 |
| 重置的确认号对不上任何报文 | 扫描或异常行为 | 查看该地址的其他连接行为 |
| 固定时间间隔出现重置 | 会话老化或空闲超时 | 与设备空闲超时配置比对 |
| 多个客户端同时被同一服务重置 | 服务端重启或资源耗尽 | 核对服务端重启记录与监控指标 |
典型使用场景
- 区分连接被拒绝与连接被中断：前者发生在建连阶段，后者出现在数据传输中
- 核实策略类型：拒绝通常会回重置，丢弃则表现为超时
- 定位会话老化：长连接在固定空闲时长后被断开
- 排查应用异常：进程崩溃时连接会被强制结束
- 识别异常扫描行为：大量建连与复位组合
常用示例
常用示例
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0' -c 20 # 抓复位
tcpdump -i eth0 -nn -ttt 'tcp[tcpflags] & tcp-rst != 0' -c 10 # 加间隔看响应快慢
tcpdump -i eth0 -nn 'host 10.0.0.9 and tcp[tcpflags] = tcp-rst' # 某地址发出的无确认复位
tcpdump -i eth0 -nn -c 30 'port 8080 and tcp[tcpflags] & tcp-rst != 0' # 某端口的复位情况
tcpdump -nn -r a.pcap 'tcp[tcpflags] & tcp-rst != 0' | wc -l # 离线统计数量确认号是最有用的线索：端口未监听时内核回的复位会把确认号设为被拒报文序列号加一，能与前面的 SYN 精确对应；而伪造的复位常常建立在了一个错误的序列号上。
只看单向抓包很难区分内核与中间设备，因为两者产生的报文形式相似。关键故障要在两端同时抓包，并同步记录设备侧的策略与日志。
服务端侧核对
服务端侧核对
ss -lntp | head -20 # 监听端口与进程，确认是否真的在听
ss -tanp | grep -c ESTAB # 当前连接数，判断是否被资源限制
journalctl -u mysvc --since '15 min ago' | tail -30 # 与应用行为按时间对齐判读要点
- 建连阶段的重置几乎总是指向监听或策略问题，先查这两项再说其他
- 传输阶段的重置优先查应用侧，尤其是超时处理与异常分支的关闭逻辑
- 重置同时伴随大量重传，说明连接已被放弃但发送方仍在尝试
- 同一服务在固定时间被重置，重点核对负载均衡的空闲超时与会话保持配置