启用tcp_tw_reuse=1是解决Go短连接端口耗尽最有效的内核级手段，但必须配套开启tcp_timestamps=1，否则完全不生效；它仅对客户端有效，依赖PAWS机制安全复用TIME_WAIT端口。
启用 net.ipv4.tcp_tw_reuse 对 go 程序基本没副作用，但必须配套开启 net.ipv4.tcp_timestamps，否则它完全不工作。
为什么 Go 程序常需要开 tcp_tw_reuse
Go 的 HTTP 客户端默认复用连接（http.Transport），但遇到服务端主动关闭、或设置了 Connection: close、或超时强制断开时，Go 会调用 close() 主动终止连接——这就让本地端口进入 TIME_WAIT。高并发短连接场景（如微服务间频繁调用、Prometheus 抓取、健康检查）下，TIME_WAIT 套接字快速堆积，容易触发：
-
dial tcp: lookup xxx: no such host（DNS 缓存未命中时重试加剧端口消耗） -
socket: too many open files（文件描述符耗尽，因每个TIME_WAIT占一个 socket） -
connect: cannot assign requested address（本地端口范围ip_local_port_range耗尽）
这些不是 Go 代码写得有问题，而是内核层面的资源回收节奏跟不上 Go 的连接发起速度。
tcp_tw_reuse=1 却没效果？先查 tcp_timestamps
tcp_tw_reuse 是个“条件触发器”，它依赖 TCP 时间戳选项来判断新旧连接是否安全可复用。只要 tcp_timestamps 关闭，设成 1 也白搭：
- 检查当前值：
sysctl net.ipv4.tcp_timestamps，输出不是1就得开 - 临时启用：
sudo sysctl -w net.ipv4.tcp_timestamps=1 - 注意：该参数默认在大多数发行版中已开启，但某些精简内核或容器镜像可能关闭
- Go 程序本身不控制这个，必须由宿主机或容器运行时环境保证
Go 应用层要不要配 SO_REUSEADDR？不用
SO_REUSEADDR 是 socket 级选项，作用是允许 bind() 重用处于 TIME_WAIT 的 *监听端口*（比如重启 Web 服务时快速绑定 80 端口）。而 tcp_tw_reuse 解决的是 *客户端主动发起连接时复用本地源端口*，两者作用对象完全不同：
- Go 的
http.Client或自定义net.Dialer不需要、也不应该手动设置SO_REUSEADDR - 如果你在 Go 里用
net.ListenTCP启动服务，监听端口冲突时才考虑SetReuseAddr(true)，但这和tcp_tw_reuse无关 - 混淆这两者是线上调优最常见的误操作之一
永久生效要改配置文件，别只靠 sysctl -w
临时命令 sysctl -w net.ipv4.tcp_tw_reuse=1 在容器重启、节点重启后就失效。Go 服务常部署在容器中，若基础镜像没预置该参数，每次启动都得重新注入：
- 推荐写入
/etc/sysctl.d/99-go-optimization.conf（比直接改sysctl.conf更清晰） - 内容只需一行：
net.ipv4.tcp_tw_reuse = 1 - 然后执行
sudo sysctl --system加载全部/etc/sysctl.d/下的配置 - Docker 中可通过
--sysctl运行时传入，但需注意：只有 privileged 容器或启用了NET_ADMINcap 才能修改
真正容易被忽略的是：Go 程序跑在容器里时，tcp_tw_reuse 是作用于容器网络命名空间的，不是宿主机。如果用的是 host 网络模式，才和宿主机共享参数；否则必须确保容器内对应的 /proc/sys/net/ipv4/... 可写且已设置。
