等待状态与端口占用
服务重启时报端口已被占用，未必是还有进程在监听：主动关闭连接的一方会进入等待状态并持续约一分钟，这段时间里该连接的四元组不能被复用。关键在于这个状态记录在操作系统而不是进程上，所以进程已经退出，端口看起来仍被占着。服务端在绑定端口前设置地址复用选项属于常规做法，这正是为了让重启不受残留连接影响。
基本信息
| 状态 | 等待关闭，主动关闭方保持约两倍报文最长生存时间 |
|---|---|
| 持续时间 | 常见默认约 60 秒 |
| 典型现象 | 重启即报端口已被占用；大量等待连接堆积 |
| 关键手段 | 地址复用选项、等待连接复用、缩短单次等待时长 |
| 已知变化 | 部分历史内核参数已被移除，且对 NAT 场景有害 |
典型使用场景
- 服务重启失败：区分是进程残留还是等待状态占用
- 客户端端口紧张：高并发短连接场景下评估复用策略
- 发布窗口排错：滚动重启时部分实例报绑定失败
- 参数审查：清理内核配置里已经不再生效的历史项
- 容量分析：把等待连接数纳入连接数总量评估
状态对照
| 状态 | 含义 | 常见触发方 |
|---|---|---|
| 等待关闭 | 主动关闭方等待报文超时回收 | 客户端侧最常见，服务端重启时也出现 |
| 已建立 | 连接正常收发数据 | 业务运行期间 |
| 关闭等待 | 被动关闭方等待本地应用关闭 | 应用未及时关闭连接时堆积 |
核对与处置
核对与处置
# 查看等待状态连接样例
ss -tan state time-wait | head -20
# 统计等待连接数量
ss -tan state time-wait | wc -l
# 查看客户端的等待连接复用开关
cat /proc/sys/net/ipv4/tcp_tw_reuse
# 避免使用已被移除的历史参数，升级内核后该文件可能不存在
ls /proc/sys/net/ipv4/ | grep tw_等待状态本身是保护机制：它确保迟到的报文不会串到新连接上。看到大量等待连接就判定为异常并不准确，需要结合连接总量、业务模型与来源分布一起看。
早期常被推荐的激进回收参数已在新版内核中移除，且在存在 NAT 的环境中会导致客户端连接静默失败。使用前先确认内核版本与对端网络环境，不要照搬旧文章里的优化建议。
稳妥做法
- 服务端绑定端口时启用地址复用选项
- 客户端侧评估等待连接复用是否适用
- 按需检查单次等待时长的内核取值
- 把等待连接数纳入日常监控与容量评估