抓 RST 在做什么
RST 是 TCP 用来强制终止连接的报文，出现在三类场合：目标端口没有进程监听时内核直接回 RST；应用进程崩溃或主动放弃连接时会发 RST；中间设备（防火墙、负载均衡、会话老化）也可能伪造 RST 让连接提前结束。抓取写法是 tcp[tcpflags] & tcp-rst != 0，再叠加地址与端口限定。判断 RST 的真实来源要看三条线索：确认号能否与被拒绝的报文对上、TTL 是否与正常回包一致、链路时延是否符合预期。
基本信息
| 抓取写法 | tcp[tcpflags] & tcp-rst != 0 |
|---|---|
| 精确写法 | tcp[tcpflags] = tcp-rst（无 ACK 的复位） |
| Wireshark 等价 | tcp.flags.rst == 1 |
| 来源线索 | 确认号对应关系、TTL、IP 标识、链路时延 |
| 常见场景 | 端口未监听、进程退出、会话老化、策略拒绝 |
RST 的四类来源
| 现象 | 可能来源 | 判读依据 |
|---|---|---|
| SYN 之后立刻收到 RST 加 ACK | 目标主机内核，端口无进程监听 | 响应极快，确认号等于 SYN 序列号加一 |
| 正常数据传输中突然 RST | 对端应用崩溃或主动放弃 | 此前有正常数据往来，RST 无预警出现 |
| RST 的 TTL 与正常包明显不同 | 中间设备伪造复位 | TTL 或链路时延与该路径正常回包不符 |
| 无前置握手的 RST | 扫描探测或劫持行为 | 序列号随机，找不到对应的连接上下文 |
典型使用场景
- 排查连接被重置：确认是服务端关闭、端口未监听还是中间设备插手
- 核对防火墙策略：拒绝类策略通常表现为 RST，静默丢弃则表现为超时
- 定位会话老化：负载均衡或防火墙的会话表超时会让长连接突然中断
- 排查进程异常：应用崩溃时连接会被重置，结合服务端日志时间点对齐
- 识别扫描行为：大量来自少数源地址的建连加复位组合
常用示例
常用示例
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0' -c 20 # 抓复位报文
tcpdump -i eth0 -nn 'tcp[tcpflags] & tcp-rst != 0 and port 8080' # 限定端口
tcpdump -i eth0 -nn 'host 10.0.0.9 and tcp[tcpflags] & tcp-rst != 0' # 限定主机
tcpdump -i eth0 -nn -ttt 'tcp[tcpflags] & tcp-rst != 0' -c 10 # 加间隔，看响应速度
tcpdump -i eth0 -nn -c 5 'tcp[tcpflags] = tcp-rst' # 只看不带确认的复位
tcpdump -nn -r a.pcap 'tcp[tcpflags] & tcp-rst != 0' | wc -l # 离线统计复位数量端口未监听时返回 RST 是协议的正常设计，不是故障。它比静默超时友好得多：失败会立刻暴露，客户端不必等到超时才放弃，排障时能省下大量等待时间。
抓到 RST 不能立刻断定服务崩溃。传输过程中段的 RST 更值得追查应用日志与进程状态；建连阶段的 RST 则要先看端口是否在监听、策略是否配置为拒绝。
配合判断
配合判断
ss -lntp # 确认端口是否真有进程监听，以及监听地址
ss -tanp | head -30 # 看当前连接状态分布
journalctl -u mysvc --since '10 min ago' # 与 RST 时间点对齐，核对进程是否重启或崩溃判读要点
- 建连阶段立刻 RST：先查监听与策略，再看是否被安全设备拒绝
- 传输阶段 RST：重点查对端应用日志与进程存活情况
- 多个客户端在同一时刻被同一服务重置：优先怀疑服务端重启或资源耗尽
- RST 只在固定时间间隔出现：典型会话老化或空闲超时行为，与业务空闲时长对比即可验证
- RST 的序列号与被拒绝报文对不上时，来源可疑，需要结合 TTL 与链路时延继续判断
- 同一连接反复建立又立刻被重置：先确认端口与监听地址，再怀疑客户端连错了目标