TIME_WAIT过多导致端口耗尽引发连接错误，本质是本地临时端口被占满；解决需三管齐下：启用tcp_timestamps、tcp_tw_reuse和调优fin_timeout，扩大端口范围并提升tw_buckets上限，禁用已废弃的tcp_tw_recycle。
TIME_WAIT 过多导致“Cannot assign requested address”或“address already in use”错误，本质是本地临时端口被占满，新连接无法分配源端口。这不是异常，而是高频短连接 + 端口复用未开启的典型表现。解决思路是：让端口更快释放、更安全复用、供给更充足。
确认是否真为端口耗尽别一看到 TIME_WAIT 数高就调参数。先验证瓶颈是否存在：运行ss -s，看 time-wait 数量是否远超 established（例如 18000 vs 200）
查当前端口范围：
sysctl net.ipv4.ip_local_port_range，默认常为32768 65535（约 3.2 万个可用端口）
统计实际占用：
ss -tan state time-wait | wc -l，若接近或超过可用端口数，基本可判定端口耗尽若使用 NAT、K8s Service 或 SLB，还需检查 conntrack：cat /proc/sys/net/netfilter/nf_conntrack_count与nf_conntrack_max对比必须启用的三项内核复用机制这是客户端侧（如 Nginx 代理后端、微服务发起调用）最直接有效的缓解手段，三者需同时生效：net.ipv4.tcp_timestamps = 1：开启 TCP 时间戳，是复用前提，防止序列号绕回；现代内核默认开，但建议显式写入配置确保稳定net.ipv4.tcp_tw_reuse = 1：允许将空闲超 1 秒的 TIME_WAIT socket 复用于新的 outbound 连接；仅对主动发起连接的客户端有效，不作用于监听端口net.ipv4.tcp_fin_timeout = 30：将 FIN_WAIT_2 超时设为 30 秒，在不破坏 2MSL 安全性的前提下加快终结节奏；TIME_WAIT 实际仍为 2×MSL（通常 60 秒），但该参数能间接缓解压力并提升连接周转率
持久化操作：
echo "net.ipv4.tcp_timestamps = 1" >> /etc/sysctl.conf，同理追加另两项，再执行sysctl -p生效。
扩大端口供给与哈希表容量每个 TIME_WAIT 占一个本地端口，光靠回收不够，还得给足“地盘”：net.ipv4.ip_local_port_range = 1024 65535：把临时端口范围拉满；避开 0–1023 特权端口即可，多数应用兼容此设置net.ipv4.tcp_max_tw_buckets = 200000：提升 TIME_WAIT 哈希桶上限；默认值（如 32768 或 65536）在高并发下易触发 “time wait bucket table overflow”，导致连接静默丢弃
注意：
tcp_tw_recycle 已废弃且禁用——它在 NAT/SLB/云环境（如 CLB、K8s Service）中会导致连接失败，因依赖客户端时间戳严格递增，而公网用户经网关后 IP 和时间戳不可控。
Windows 系统的对应处理Windows 默认动态端口范围为49152–65535（仅 16384 个），TIME_WAIT 默认持续 240 秒（4 分钟），更容易耗尽：扩大端口范围：以管理员身份运行 CMD，执行netsh int ipv4 set dynamicport tcp start=1025 num=60000表示从 1025 开始分配 60000 个端口（覆盖 1025–61024）
缩短等待时间（可选）：修改注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters，新建 DWORD 值MaxUserPort（设为 65534）和TcpTimedWaitDelay（设为 30，单位秒），修改后需重启系统