临时端口被打满：TIME_WAIT 堆积导致 Cannot assign requested address 的排查与根治

我干运维 10 年，见过太多"网络看起来好好的，就是时好时坏"的怪病。这次这个不是丢包、不是 MTU、不是 DNS，而是端口号发完了。下面把现象、原理、可复现命令和几个反直觉的坑一次讲清。

一、现象：不是网络抖，是"没有端口号可分配了"

上个月一个出站网关（Go 1.21，4C8G，内核 5.15）出故障：它要调 3 个下游接口，QPS 稳定在 800 左右，P99 平时 40ms，故障时直接飙到 3s 以上，日志里疯狂刷这一条：

dial tcp: cannot assign requested address

诡异的地方在于：CPU 只有 30%、内存空闲一半、网卡零丢包、ping 下游全通。盯着服务端看了半天没毛病。最后一条 ss -s 让我闭嘴了——timewait 那一行有 2 万多个，几乎把 32768–60999 这段端口吃满了。

二、原理：TIME_WAIT 为什么死死占着端口不放

先把机制讲成大白话。

TCP 连接由 4 元组唯一确定：源IP + 源端口 + 目的IP + 目的端口。客户端主动发起连接时，得自己挑一个"源端口"（临时端口）。当这条连接正常四次挥手关掉后，关闭方会把这条连接挂在 TIME_WAIT 状态上一段时间，默认是 60 秒（Linux 由 net.ipv4.tcp_fin_timeout 控制）。

为什么关完还占着不放？因为 TIME_WAIT 要等"最后一个 FIN 的重传窗口 + 2×MSL"过去，确保旧连接在网里的所有报文都死透了，否则新连接可能会"捡"到旧连接的迟到数据包，乱套。

关键数字算给你看：

• 端口范围 32768 60999，一共约 28232 个可用端口；
• 我们对同一个下游目标，800 QPS 短连接、每条挂 60s；
• 理论端口吞吐上限 ≈ 28232 ÷ 60 ≈ 470 连接/秒；
• 800 > 470，必然耗尽。

这就是为什么"CPU 内存都正常却发不出请求"——不是没算力，是没有源端口号可分配了。

三、具体做法（可复现）

1. 先确认是不是端口耗尽：

ss -s                                   # 看 timewait 计数
ss -ant state time-wait | wc -l         # TIME_WAIT 总数
ss -ant | awk 'NR>1{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# 看哪个目标 IP 占的端口最多
sysctl net.ipv4.ip_local_port_range net.ipv4.tcp_fin_timeout net.ipv4.tcp_tw_reuse

2. 治本（我强烈建议）：别用短连接，改长连接 + 连接池 + HTTP keep-alive。 Go 侧把 http.Transport 的 MaxIdleConnsPerHost 调大、DisableKeepAlives 关掉；Java 侧用连接池复用 TCP 连接。连接复用了，TIME_WAIT 自然不涨，这是唯一根治法。

3. 治标（争取时间，不治本）：

# 把端口范围往上扩（默认 32768 60999 → 1024 65535，约多 3 倍端口）
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

# 允许出站连接在 TIME_WAIT 下复用端口（仅对出站有效，且需开启 TCP timestamp）
sysctl -w net.ipv4.tcp_tw_reuse=1

4. 上监控告警： 把 timewait 计数 / 端口使用率进 Prometheus，超过可用端口的 70% 就告警，别等 cannot assign 刷出来了才发现。

四、踩过的坑（全是反直觉的）

1. tcp_tw_reuse 只对"出站"有效，对入站连接没用。很多人以为它万能，结果在入站场景一点效果没有。
2. tcp_tw_recycle 千万别开。它在 4.12 内核已被彻底移除，原因就是它在 NAT/负载均衡后面会按时间戳把正常包当"旧包"丢掉，一开就丢包。
3. 调大端口范围只是把爆炸时间往后推，QPS 再涨照样爆，不是解药。
4. 端口耗尽发生在"发起方"（客户端）侧，不是服务端。这次我们盯着服务端看了半天，纯属找错地方。
5. 对多个目标反而慢一点：4 元组里目的 IP 不同，端口可以复用，所以打 3 个下游比打 1 个下游端口耗尽得慢——这也是为什么"多目标"看起来没那么快爆。

五、结论与可复用清单

一句话：TIME_WAIT 不是 bug，是 TCP 的保险丝；端口耗尽是"发起方短连接 + 高 QPS"的必然结果。

可复用 checklist：

• [ ] 先 ss -s 看 timewait，再下结论是不是端口问题
• [ ] 算一下 可用端口数 ÷ 60s 与 QPS 的比值，超过就预警
• [ ] 长连接 + 连接池 + keep-alive 是根治
• [ ] 调端口范围、开 tcp_tw_reuse（仅出站）是争取时间
• [ ] tcp_tw_recycle 一律不碰
• [ ] timewait 计数进监控，70% 阈值告警
• [ ] 排查时先分清"发起方还是接收方"，别找错端