大量 TIME_WAIT 连接导致端口耗尽的 tcp_tw_reuse + tcp_fin_timeout 组合调优

tcp_tw_reuse单独开启无效，因仅对客户端主动发起的新连接生效，且需tcp_timestamps=1及对方支持时间戳；服务端被动接收连接不触发该机制。

为什么 tcp_tw_reuse 单独开没用

很多运维一看到 TIME_WAIT 占满端口，第一反应是改 net.ipv4.tcp_tw_reuse = 1，但发现连接还是卡住——因为这个参数只对「客户端主动发起的新连接」生效，且必须满足时间戳（tcp_timestamps）开启、对方也支持时间戳两个前提。如果服务端是 nginx/java 等被动接收连接的场景，它根本不会触发 tcp_tw_reuse 的逻辑。

常见错误现象：ss -s 显示大量 TIME_WAIT，netstat -an | grep :80 | wc -l 接近 65535，但 tcp_tw_reuse = 1 后新建连接仍失败。

• tcp_tw_reuse 不影响服务端 TIME_WAIT 的回收时机，只影响客户端能否复用本地四元组
• 必须同时启用 net.ipv4.tcp_timestamps = 1（默认通常已开，但要确认）
• 若后端是老设备或中间有不支持时间戳的负载均衡器，tcp_tw_reuse 会静默失效

tcp_fin_timeout 改小真能加速 TIME_WAIT 消失？

不能。这是一个长期被误解的点：net.ipv4.tcp_fin_timeout 控制的是「FIN_WAIT_2」状态的超时时间，和 TIME_WAIT 完全无关。TIME_WAIT 的持续时间固定为 2×MSL（linux 默认 60 秒），由内核硬编码决定，无法通过 sysctl 修改。

你把 tcp_fin_timeout 改成 5，只会让那些卡在 FIN_WAIT_2 的连接更快关闭，对堆积如山的 TIME_WAIT 连接毫无影响。

• 检查当前真实 TIME_WAIT 超时：执行 cat /proc/sys/net/ipv4/tcp_fin_timeout 并忽略它的名字——它不控制 TIME_WAIT
• 真正影响 TIME_WAIT 存续时间的只有 MSL，而 Linux 内核里写死为 30 秒，所以 TIME_WAIT 实际持续 60 秒
• 试图靠调小 tcp_fin_timeout 缓解端口耗尽，属于找错靶子

真正有效的组合：tcp_tw_reuse + tcp_tw_recycle？别碰 tcp_tw_recycle

tcp_tw_recycle 在 4.12+ 内核中已被彻底移除，且在启用了 NAT 的环境（包括大部分云厂商 VPC、docker bridge、k8s CNI）下会导致连接随机失败——因为它依赖时间戳做“快速回收”，而 NAT 后多个客户端的时间戳可能乱序，内核直接丢包。

目前唯一安全、通用的缓解路径，是让客户端尽量复用连接，而不是拼命开新连接：

• http 场景：确保客户端（curl、浏览器、SDK）开启 Keep-Alive，并设置合理的 max_keepalive_requests 和 keepalive_timeout
• TCP 层面：短连接高频请求的服务（如上游调用下游 API），改用连接池（如 go 的 http.Transport.MaxIdleConns、python 的 urllib3.PoolManager）
• 如果必须短连，且客户端可控，可启用 tcp_tw_reuse + tcp_timestamps = 1，并确认对方网络栈兼容

端口耗尽时该先查什么，而不是急着调参

盲目调 tcp_tw_reuse 或幻想改 tcp_fin_timeout 能救火，往往掩盖了更关键的问题：连接是不是本就不该这么多？

先运行这几条命令定位根因：

ss -tan state time-wait | head -20

看 TIME_WAIT 连接的目标 IP 和端口是否集中（比如全打向某台下游 DB 或 redis），说明是某个上游服务异常高频建连；

ss -s | grep -i "time-wait"

对比 time-wait 数量和 tw bucket allocation 是否接近上限（后者反映哈希桶冲突压力）；

• 如果 TIME_WAIT 全来自本机 client → 检查应用层是否缺少连接复用
• 如果全来自外部 client → 服务端本身不产生 TIME_WAIT，问题在客户端，调服务器参数无意义
• 若 ss -s 显示 hash limit 被 hit，说明连接数远超预期，需查流量突增或攻击

调参只是补救，连接模型设计不合理，再怎么压 TIME_WAIT 也会在别的地方崩掉。