linux tcptraceroute Linux TCP连接优化

tcp_fin_timeout仅影响新连接的FIN超时时间，对已存在的TIME_WAIT连接无效；需配合tcp_tw_reuse=1和tcp_timestamps=1才能复用端口，且仅适用于客户端主动发起的短连接场景。

tcp_fin_timeout 只影响新连接，不清理已有 TIME_WAIT

直接改 net.ipv4.tcp_fin_timeout 到 30 或 15，不会让当前屏幕上看到的几万个 TIME-WAIT 连接立刻消失。它只决定「新发起关闭」的连接进入 TIME_WAIT 后等待多久才释放端口——旧连接仍按原来的定时器走完剩余时间。

常见错误现象：ss -s 或 netstat -ant | grep TIME_WAIT | 时间等待 wc -l 数值卡住不动，误以为参数没生效。其实只是你还没等到那批老连接自然过期。该参数对服务端被动关闭（如 Nginx 收到请求后关 upstream）基本无效值不宜低于 15：太小可能让对端 ACK/FIN 还没收到就复用端口，引发 RST 或连接失败单独调它，TIME_WAIT 总数大概率还是涨得比释放快tcp_tw_reuse=1 必须配 tcp_timestamps=1 才真正起作用

net.ipv4.tcp_tw_reuse = 1 是唯一能“复用” TIME_WAIT 端口的机制，但它不是开关一开就自动生效——它依赖 net.ipv4.tcp_timestamps = 1 提供的时间戳做安全校验。内核默认开启该选项，但某些云镜像或老旧系统（如 CentOS 7 最小安装）可能关了。

验证方式：sysctl net.ipv4.tcp_timestamps 返回必须是 1；如果不是，得在 /etc/sysctl.conf 显式加一行：net.ipv4.tcp_timestamps = 1。仅对本机发起的 outbound 连接有效（比如 Python 调 API、Nginx 作为代理连后端），不影响 accept() 的服务端行为在 NAT 环境（家用路由器、云 LB）下，若中间设备篡改或丢弃时间戳，会导致新连接被静默拒绝（Connection refused）用 ss -i 查一条 TIME_WAIT 连接，输出里有 ts 字段才算真正启用别碰 tcp_tw_recycle，它已在 4.12+ 内核中彻底移除

很多旧文档还在写 net.ipv4.tcp_tw_recycle = 1，这是危险操作。Linux 4.12 起该参数已被删除，设了也无效；而在 3.10–4.12 之间，它会在 NAT 场景下导致连接随机失败——因为它用每 IP 的时间戳做速率判断，NAT 后所有客户端共享同一个出口 IP，时间戳乱序直接触发丢包。