tcp_max_tw_buckets 是限制内核维护 TIME_WAIT 哈希桶数量的阈值，超限后内核强制回收最老条目以防止内存抖动；反向代理因高频短连接易触发溢出，需配合 tcp_tw_reuse=1、tcp_timestamps=1、tcp_fin_timeout=30 及扩大端口池协同调优。
调优 tcp_max_tw_buckets 是缓解反向代理（如 Nginx、Envoy）因高频短连接产生的大量 TIME_WAIT 的关键一环，但它不是“单独起效”的开关，而是配合复用机制与资源扩容的协同环节。
为什么反代场景特别容易触发 tcp_max_tw_buckets 溢出
反向代理通常作为客户端频繁发起上游请求（例如每秒数百次 HTTP 调用），每次短连接关闭后都会进入 TIME_WAIT 状态，默认持续 2MSL（Linux 通常为 60–120 秒）。若每秒新建 500 个连接，1 分钟内就可能积累 3 万个 TIME_WAIT 条目。而内核默认的 tcp_max_tw_buckets 值常为 32768 或 65536，在高并发下极易触顶。一旦超出，内核会静默丢弃新 TIME_WAIT 条目，同时可能拒绝新连接（表现为 “Cannot assign requested address” 或连接超时）。
tcp_max_tw_buckets 的真实作用和调优逻辑
它不缩短单个连接的等待时间，也不阻止 TIME_WAIT 生成，而是限制内核维护的 TIME_WAIT 哈希桶数量上限。超过该值后，内核会强制回收最老的 TIME_WAIT 条目——这能防止哈希表膨胀导致内存抖动或查找变慢，但不能解决端口耗尽本身。
- 查看当前值：cat /proc/sys/net/ipv4/tcp_max_tw_buckets
- 推荐值范围：对于中高并发反代服务（QPS > 300），建议设为 100000～200000；若内存充足且 QPS 突破 1000，可设为 300000
- 临时生效：sysctl -w net.ipv4.tcp_max_tw_buckets=200000
- 持久化：写入 /etc/sysctl.d/99-tcp-tuning.conf 并执行 sysctl -p
必须同步配置的配套参数（否则单调 buckets 效果有限）
仅增大 buckets 只是“多装点垃圾”，真正缓解端口枯竭需让系统更积极复用和更快释放：
- 启用安全复用：net.ipv4.tcp_tw_reuse = 1（允许 TIME_WAIT socket 用于新 outbound 连接）
- 强制开启时间戳：net.ipv4.tcp_timestamps = 1（tcp_tw_reuse 的硬性前提，也防序列号绕回）
- 适度缩短等待窗口：net.ipv4.tcp_fin_timeout = 30（将 FIN_WAIT2 和 TIME_WAIT 回收基准从 60 秒减至 30 秒，不影响可靠性）
- 扩大本地端口池：net.ipv4.ip_local_port_range = 1024 65535（确认已覆盖全部可用端口，避免默认 32768–61000 的窄区间瓶颈）
验证是否真正生效
调参后不要只看 buckets 值，要观察三组指标是否同步改善：
- TIME_WAIT 实际数量：ss -ant | grep -c TIME_WAIT（应明显低于新设的 buckets 值）
- 端口分配失败统计：netstat -s | grep -i "times exhausted"（该数值应趋近于 0）
- 连接建立成功率：反代日志中的 upstream connect timeout 或 502 错误是否下降
