FIN_WAIT 状态机速览
主动关闭连接的一方要依次经过三个阶段：发出 FIN 后进入等待对方确认的第一阶段，收到确认后进入第二阶段，收到对方的 FIN 之后再进入超时等待阶段并保持一段时间。如果对端迟迟不发 FIN，连接就会卡在第二阶段，靠内核的超时参数兜底回收。
基本信息
| 适用平台 | TCP 状态机行为，Linux 可用 ss 查看 |
|---|---|
| 状态顺序 | 等待第一阶段 → 等待第二阶段 → 超时等待 |
| 查看命令 | ss -tan 配合状态过滤条件 |
| 兜底参数 | Linux 的 tcp_fin_timeout 控制第二阶段的最长停留 |
典型使用场景
- 理解关闭流程：明确主动关闭方要经历哪些阶段
- 排查连接泄漏：大量停留在第二阶段说明对端不配合关闭
- 对照抓包与状态：抓包看不到状态名，需按 FIN 方向推断
- 评估参数影响：不同内核参数会导致停留时长不同
- 定位两端不对称：一侧已关闭而另一侧仍占用，说明流程没走完
查看方式
查看方式
ss -tan | grep -E 'FIN-WAIT' # 查看处于关闭过程中的连接
sysctl net.ipv4.tcp_fin_timeout # 第二阶段的最长停留时间
ss -s | grep -i timewait # 超时等待状态的数量状态读法
| 状态 | 含义 | 异常信号 |
|---|---|---|
| 第一阶段 | 已发 FIN 等待对方确认 | 长期停留说明对方未应答 |
| 第二阶段 | 对方已确认但未发 FIN | 大量停留说明对端不关闭 |
| 超时等待 | 等待足够久以吸收延迟报文 | 数量异常高需关注连接复用 |
| 已关闭 | 连接结束 | 正常状态 |
停留在第二阶段的连接数量是判断对端行为的重要指标。数量持续偏高，通常说明对端应用完成了半关闭却没有继续关闭连接。
抓包看不到状态名，只能按 FIN 的方向与顺序推断。抓包结论要与本机状态查询的输出对照，才能得出可靠判断。
停留时长受内核参数控制，跨机器对比行为之前先确认参数是否一致，否则很容易把配置差异当成对端异常。