如何减少 TIME_WAIT 状态的 TCP 连接数
TIME_WAIT 是正常的 TCP 状态。先核对连接失败、端口范围和短连接速率，再通过连接池与 Keep-Alive 优化；不要把 tcp_fin_timeout 当作 TIME_WAIT 超时参数。
一句话回答：先明确——TIME_WAIT 是 TCP 协议的正常设计（主动关闭方等待 2MSL，防止旧包串扰新连接），不能只凭数量判断是否异常。真正需要干预时的优先级：应用层启用 HTTP Keep-Alive / 数据库连接池（治本，让连接复用而非频繁新建）；确认瓶颈后再评估端口范围、出口 IP 与负载分摊，内核参数不应当作通用修复。tcp_tw_recycle 在 NAT 环境下会导致连接失败，不要开。
先确认是不是真问题
ss -s # 看 timewait 总数
ss -ant | grep TIME_WAIT | wc -l
结合新连接失败率、客户端临时端口范围、连接四元组与源地址判断，不能设定通用的“几万以内安全线”。Cannot assign requested address 也可能是绑定了不可用地址，需核对错误上下文。socket 状态与防火墙 conntrack 是不同的统计对象。
治本：应用层连接复用
TIME_WAIT 数量持续偏高通常与连接关闭速率较高有关——每个请求新建 TCP、用完即关，主动关闭方就留一个 TIME_WAIT。
- HTTP 客户端：启用 Keep-Alive（多数库默认开，检查是否被关）；用连接池而不是每次
new client - 数据库：用连接池（HikariCP、pgbouncer），别每次查询新建连接
- 微服务间调用：gRPC/HTTP2 多路复用天然少量连接
- Nginx 反代：配置 upstream
keepalive连接缓存，并为 HTTP/1.1 上游设置proxy_http_version 1.1和空Connection头；仅改请求头不等于建好了上游连接池
可在同等请求负载下比较连接新建率、TIME_WAIT 与错误率；收益取决于原先的连接复用方式，不能预先承诺下降倍数。
持续比较时，可配置观测云 NetStat 采集器记录 tcp_time_wait；需要区分端口时设置 addr_ports 或 ports_match。将这条趋势与连接失败记录一起看，判断复用调整后是否缓解了原先的错误。
缓解：内核参数（Linux）
先只读检查当前配置：
sysctl net.ipv4.tcp_tw_reuse
sysctl net.ipv4.ip_local_port_range
sysctl net.ipv4.ip_local_reserved_ports
当前 Linux 文档中 tcp_tw_reuse 的 0/1/2 分别表示禁用、全局启用、仅 loopback 启用，文档默认值为 2；实际内核与发行版可能不同。官方明确不建议在没有技术专家指导时修改。不要直接复制 tcp_tw_reuse=1 当作“客户端安全”方案。
扩展临时端口范围要同时检查保留端口、监听服务、出口 NAT 及网络命名空间，评估后再变更并保留回滚值。tcp_tw_recycle 已从 Linux 4.12 移除，不要寻找旧配置启用它。tcp_fin_timeout 控制孤儿连接的 FIN_WAIT2 超时，不控制 TIME_WAIT。
架构层：分摊压力
经排查确认临时端口或出口 NAT 资源是瓶颈时（容量取决于实际端口范围、源 IP 与目的四元组，不是固定约 2.8 万条连接）：
- 增加出口 IP（多网卡/多 EIP），让连接四元组分散
- 负载均衡到更多后端节点
- 长连接网关聚合（如 MQ、连接聚合层）
常见问题（FAQ）
Q：TIME_WAIT 和 CLOSE_WAIT 哪个更危险？
A：两者不能仅按状态名判断。短暂 CLOSE_WAIT 也正常；若持续累积，重点检查收到对端 FIN 后应用是否及时关闭 socket、线程是否阻塞及文件描述符是否耗尽。TIME_WAIT 则是正常的关闭保护期。
Q：负载均衡器后面 TIME_WAIT 多正常吗？
A：正常。LB 与后端之间如果每请求新建连接，TIME_WAIT 集中在 LB 上。开启 LB 到后端的连接复用（keepalive）即可显著改善。
Q：TIME_WAIT 会影响性能吗？
A：大量短连接可能增加内存、端口及 NAT/conntrack 压力，但 socket TIME_WAIT 数量不等于 conntrack 使用量。需分别检查资源和错误率；Cannot assign requested address 是排查线索，不是唯一结论。
核查依据
本文依据官方文档核对，示例未在实际业务环境运行；上线前请按部署版本、权限与数据范围验证。
