Linux端口耗尽主因是高频短连接导致TIME_WAIT堆积，优化需开启tcp_tw_reuse=1、扩端口范围（1024-65535）、设tcp_fin_timeout=30，并配合长连接与服务端关连；禁用已废弃的tcp_tw_recycle。
Linux端口耗尽常由大量处于 TIME_WAIT 状态的连接引发，尤其在高并发短连接场景（如HTTP负载均衡、微服务调用）下明显。默认内核参数未针对高频建连/断连优化，导致本地端口快速被占满（65535个可用端口），新连接抛出 Cannot assign requested address 错误。
理解 TIME_WAIT 的作用与代价
TIME_WAIT 是TCP四次挥手后主动关闭方维持的状态，持续2×MSL（通常为60秒），主要作用是：
- 确保被动关闭方能重传最后的ACK，避免旧连接的延迟报文干扰新连接
- 防止新连接收到上一个同四元组（源IP+源端口+目标IP+目标端口）的残留数据
问题在于：当客户端频繁发起短连接（如每秒数百次curl请求），每个连接都会留下一个60秒的TIME_WAIT，端口复用被阻塞，很快耗尽本地端口池。
安全有效的优化策略
不建议盲目启用 net.ipv4.tcp_tw_reuse 或缩短 tcp_fin_timeout，需结合业务场景分层调整：
-
优先开启 time_wait 复用：
net.ipv4.tcp_tw_reuse = 1（仅对客户端有效）
允许内核在精确时间戳（PAWS）校验通过时，将处于TIME_WAIT的端口用于新连接（要求目标IP:PORT不同或时间戳更新）。适用于上游是Nginx反代、服务间HTTP调用等典型客户端角色。 -
谨慎启用快速回收（已弃用，慎用）：
net.ipv4.tcp_tw_recycle = 0（必须设为0）
该参数在NAT环境会导致连接失败，Linux 4.12+内核已移除，生产环境严禁开启。 -
扩大可用端口范围：
net.ipv4.ip_local_port_range = 1024 65535
默认起始端口为32768，可提前至1024，增加约3万可用端口（注意避开常用服务端口）。 -
降低TIME_WAIT持续时间（非标准但有效）：
net.ipv4.tcp_fin_timeout = 30
虽不能直接缩短TIME_WAIT时长（RFC规定为2MSL），但可加快连接进入TIME_WAIT前的FIN阶段处理，间接缓解堆积；配合reuse效果更佳。
配套调优与验证方法
单靠TIME_WAIT优化不够，还需协同调整：
- 启用连接复用：HTTP加
Connection: keep-alive，gRPC使用长连接，减少新建连接频次 - 检查应用是否主动关闭连接：避免客户端频繁调用
close()，优先由服务端断连（让服务端承担TIME_WAIT） - 监控确认效果：
ss -ant | grep TIME-WAIT | wc -l查看当前数量netstat -s | grep -i "time wait"查看统计累计值
云环境与容器场景注意事项
在Kubernetes或Docker中，宿主机网络参数仍主导TIME_WAIT行为，但需额外注意：
- Pod使用hostNetwork时，直接继承宿主机参数；否则走CNI网络，TIME_WAIT发生在Pod网络命名空间内，需在对应节点调优
- Service类型为ClusterIP时，kube-proxy的iptables/ipvs规则可能引入额外连接跳转，放大TIME_WAIT数量，可考虑启用ipvs的
strictARP和连接跟踪优化 - 云LB（如AWS ALB、阿里云SLB）后端健康检查若使用HTTP短连接，也会在代理节点产生TIME_WAIT，需同步检查LB配置
