time_wait过多导致端口耗尽的本质是本地临时端口被大量占用，新连接因无法分配源端口而失败；需通过启用tcp_timestamps、tcp_tw_reuse、缩短fin_timeout及扩大端口范围来缓解。
TIME_WAIT 过多导致端口耗尽，本质是本地临时端口被大量“占着不放”，新连接因无法分配源端口而失败，典型报错是 bind: cannot assign requested address。这不是系统故障，而是短连接高频发起 + 端口复用机制未启用的必然结果。核心思路不是消灭 TIME_WAIT，而是让端口更快回收、更安全复用、更充分供给。
确认是否真为端口耗尽
别一看到 TIME_WAIT 多就调参数。先定性：
- 运行 ss -s，看输出中
time-wait数量是否远超established（比如 2 万 vs 200） - 查当前端口范围：sysctl net.ipv4.ip_local_port_range，若显示类似
32768 60999，则可用端口约 28k；再统计 TIME_WAIT 数：ss -tan state time-wait | wc -l，若接近或超过该数值，基本可判定端口瓶颈 - 检查连接跟踪（尤其用了 NAT/SLB/K8s Service 的场景）：cat /proc/sys/net/netfilter/nf_conntrack_count 与 nf_conntrack_max 对比，若接近满值，需同步优化 conntrack 表
必须启用的内核复用机制
这是客户端侧（如 Nginx 代理后端、微服务调用）最直接有效的缓解手段，三者需同时配置：
- net.ipv4.tcp_timestamps = 1：开启 TCP 时间戳，是复用前提，也防止序列号绕回。现代内核默认开，但建议显式写入配置确保生效
- net.ipv4.tcp_tw_reuse = 1：允许将空闲超 1 秒的 TIME_WAIT socket 用于新的 outbound 连接。仅对客户端有效，且依赖 timestamps
- net.ipv4.tcp_fin_timeout = 30：将 TIME_WAIT 超时从默认 60 秒缩短为 30 秒。低于 15 秒可能影响可靠性，30 是兼顾安全与效率的常用值
扩大端口供给与管理上限
每个 TIME_WAIT 占一个本地端口，光靠回收不够，还得给足“地盘”：
- net.ipv4.ip_local_port_range = 1024 65535：把临时端口范围拉满。注意部分旧应用可能不兼容低端口（9000 65535
- net.ipv4.tcp_max_tw_buckets = 200000：提升内核 TIME_WAIT 桶上限。默认值（如 32768 或 65536）在高并发下易触发 “time wait bucket table overflow”，导致连接静默丢弃
应用层协同优化不可跳过
内核参数只能缓解，根治要靠连接使用方式升级：
- HTTP 服务务必启用 Keep-Alive：Nginx 配置
keepalive_timeout 65、keepalive_requests 1000；后端代码（如 Python requests）复用 Session 实例 - Nginx 代理上游时，透传长连接：
proxy_http_version 1.1+proxy_set_header Connection '' - 数据库、Redis 等中间件必须使用连接池，禁止每次请求新建连接
- 禁用 tcp_tw_recycle = 0：该参数在任何含 NAT 的环境（包括家用路由器、云 SLB、K8s Service）都会引发连接失败，Linux 4.12+ 已移除，切勿开启
