TIME_WAIT占满端口导致bind(80)失败，主因是主动关闭连接过多未回收，其时长由MSL（通常240秒）决定，tcp_fin_timeout仅影响FIN_WAIT_2；tcp_tw_reuse对server端bind无效，缓解需扩端口范围、启用tcp_timestamps并合理使用SO_REUSEADDR。
TIME_WAIT 占满本地端口导致 bind(80) 失败
不是端口被其他进程占着，而是本机主动关闭的连接太多、还没回收完，netstat -ant | grep TIME_WAIT | wc -l 轻松上万。Linux 默认 tcp_fin_timeout 是 60 秒，但 TIME_WAIT 实际持续 2×MSL（通常 240 秒），所以改 tcp_fin_timeout 对 TIME_WAIT 时长**完全没用**——这是最常踩的误解。
-
tcp_fin_timeout只控制 FIN_WAIT_2 状态超时，不影响 TIME_WAIT - 真正决定 TIME_WAIT 持续时间的是内核编译时定死的 MSL（一般 60 秒），不可调
- bind 失败报错通常是：
Address already in use，但lsof -i :80查不到占用进程
tcp_tw_reuse 不是万能开关，得看场景
tcp_tw_reuse 允许复用处于 TIME_WAIT 的 socket，但只在「客户端发起连接」时生效（即本机作为 client 调用 connect()），对 server 端 bind() + listen() 绑定 80 端口**毫无帮助**。所以你开了它却还是 bind 失败，很正常。
- 生效前提：socket 必须是 client 端，且目标地址+端口+源地址+源端口四元组与某个 TIME_WAIT 连接完全一致
- server 端监听 80，靠的是
bind()到 *:80，不涉及四元组复用逻辑 - 想让 server 快速重启并 bind 80，该用
SO_REUSEADDR（应用层）或net.ipv4.ip_local_port_range扩大临时端口池
真正能缓解 80 端口 bind 失败的配置组合
核心思路不是“加速回收 TIME_WAIT”，而是“减少新连接打满本地端口”或“绕过绑定冲突”。生产环境建议这样配：
- 开
net.ipv4.tcp_tw_reuse = 1：对 upstream 是 client 的场景（如 Nginx 代理后端）有用 - 设
net.ipv4.ip_local_port_range = 1024 65535：扩大可用临时端口范围，避免快速耗尽 - 加
net.ipv4.tcp_fin_timeout = 15：虽不缩 TIME_WAIT，但能缩短 FIN_WAIT_2，间接减少半关闭连接堆积 - 必须配
net.ipv4.tcp_timestamps = 1：因为tcp_tw_reuse依赖时间戳选项做安全校验，没它就无效
为什么把 tcp_fin_timeout 改成 15 容易出问题
这个值太小会干扰正常连接关闭流程。当对方没收到 FIN-ACK 或丢包重传时，本端过早释放连接状态，可能造成 RST、连接中断或数据丢失。尤其在高丢包、高延迟链路（如跨公网调用）下更明显。
- 15 秒远低于常见网络 RTT + 重传窗口，FIN_WAIT_2 阶段可能还没等到对方 ACK 就强制关了
- 如果服务同时做 client 和 server（比如反向代理），client 侧连接不稳定，反而增加重试和连接数
- 真正要压 TIME_WAIT 数量，优先查是不是短连接滥用（比如 HTTP 没开 keepalive）、后端响应慢拖长连接生命周期
TIME_WAIT 本身不是 bug，是 TCP 正常机制；压数量不如理清连接模型。改内核参数前，先确认是不是代码里每秒建几百个 HTTP 连接还从不复用。
