服务器上执行连接统计，发现数万条TIME_WAIT，业务又偶发“Cannot assign requested address”或代理连接失败，很容易把两者直接画等号。TIME_WAIT本身是TCP正常设计，只有结合临时端口、目标集中度和实际错误，才能判断是否造成容量问题。
TIME_WAIT为什么存在
主动关闭连接的一方通常会在一段时间内保留TIME_WAIT，用来处理延迟报文并确保最后确认可以重发。它避免旧连接的残留数据被误认为新连接数据。单纯追求把TIME_WAIT变成零，会破坏协议安全边界。
端口耗尽看的是连接组合
出站TCP连接通常使用本地临时端口，并由源IP、源端口、目标IP、目标端口和协议等共同区分。大量短连接集中访问同一目标时，本地可用组合可能耗尽；增加源IP或目标分散会改变容量，但不是替代连接复用的第一选择。
哪些错误更像端口耗尽
| 证据 | 说明 |
|---|---|
| Cannot assign requested address | 系统无法分配合适本地地址或端口 |
| 临时端口范围使用率很高 | 需要结合目标四元组统计 |
| 新建连接失败，已有连接正常 | 符合端口或连接表容量特征 |
| 扩大源地址后立即改善 | 提示出站组合容量相关，但仍需找短连接原因 |
大量短连接从哪里来
应用每次请求创建新客户端、禁用Keep-Alive、连接池生命周期过短、服务发现频繁重建、代理认证不支持复用或错误重试，都可能增加建连率。统计每秒新建连接、请求数与复用率，比只看当前TIME_WAIT数量更有意义。
连接池要复用也要更新
复用可减少TCP和TLS握手，但连接不能永久保留。代理、负载均衡和上游都有空闲超时，DNS或节点也会变更。设置合理的池大小、最大空闲时间和连接寿命，并让它们与路径中最短超时协调。
为什么只改内核参数风险大
缩短TIME_WAIT、强制复用或扩大端口范围可能暂时缓解，但不同操作系统参数语义不同，NAT、多目标和时间戳条件也影响安全性。生产变更必须基于官方文档、压测和回滚，不能照抄过时的“网络优化清单”。
HTTP/2能减少连接数吗
HTTP/2可在单连接上并发多个流，理论上减少到同一目标的连接，但代理前后可能使用不同协议，单连接故障影响范围也更大。相关边界可参考HTTP/2多路复用与代理连接池。
TLS握手成本也要计入
短连接不仅占用端口，还增加CPU、证书验证和握手延迟。开启会话恢复可以降低部分成本，但不能取代连接池。客户端恢复失败或频繁切换代理节点时，建连率仍会升高。
代理节点可能是另一侧耗尽
客户端本地端口正常，代理到上游的出站端口却可能耗尽。必须分别统计前端和后端连接，记录代理源IP、上游目标和错误位置。多租户代理还要区分某个业务的连接风暴与全局容量。
建议的排查流程
- 收集业务错误、时间和失败发生的连接段；
- 统计ESTABLISHED、TIME_WAIT、新建速率与临时端口范围；
- 按目标IP和端口分组，确认是否集中耗尽；
- 检查客户端和代理连接池、Keep-Alive与重试；
- 优先减少无效短连接，再评估端口范围或源地址扩容；
- 通过持续压测验证端口、CPU、文件描述符和延迟。
如何估算端口是否真的够用
不要只用“临时端口数量除以并发”做静态估算，还要统计每秒新建连接、平均连接时长、主动关闭方、TIME_WAIT保留时间及同一目标集中度。用生产流量分位数建立模型，再预留发布、故障重试和节点缩容时的峰值余量。若客户端通过NAT或代理，还要分别计算每一层的源地址与端口容量。
修复后怎样验证
在固定请求量下比较新建连接率、连接池命中、TIME_WAIT、端口分配失败和P95延迟，再逐步提高并发。验证应覆盖上游节点切换、DNS更新和短时故障，确认客户端不会在异常时关闭复用并同步重试。只有业务错误消失且容量指标留有余量，才能认为问题真正改善。
结论
TIME_WAIT多是现象，不是自动成立的故障结论。只有出现端口分配失败、目标连接高度集中并与业务错误对齐，才应按临时端口容量处理；长期优化仍应优先修复短连接和连接池设计。
