“connect: cannot assign requested address”是客户端本地临时端口耗尽所致，根本原因在于频繁短连接产生大量TIME_WAIT状态端口未及时释放；Gin作为服务端不消耗临时端口，问题出在代码中http.Client发起的outbound请求或Nginx upstream连接上。
为什么Gin本身不导致端口耗尽，但压测时却报“connect: cannot assign requested address”
这不是 Gin 框架的问题，而是你用 Gin 写的客户端代码（比如调用其他服务）或 Nginx 反向代理层在发起 outbound 连接时，本地临时端口被大量 TIME_WAIT 占满。Gin 作为 HTTP server，只监听固定端口（如 :8080），它不消耗临时端口；真正耗端口的是你代码里用 http.Client 发起的请求，或者 Nginx 转发时建立的 upstream 连接。
典型场景：Gin 服务 A 调用服务 B，每秒 2000 次短连接，TcpTimedWaitDelay 默认 240 秒 → 理论最大堆积 2000 × 240 = 48 万 个 TIME_WAIT，远超 Windows 默认动态端口范围（1024–5000，仅约 4000 个）。
- 确认是否是 outbound 耗尽：执行
netstat -an | findstr TIME_WAIT | findstr :目标IP，看数量是否持续 > 3000 - 不是
listen失败（那是bind: address already in use），而是connect失败 - Gin 的
router.Run()不会触发该问题；出问题的一定是你的http.Client.Do()或 Nginx upstream
Go 客户端侧：用对 http.Client 才能复用连接、避免端口爆炸
默认 http.DefaultClient 的 Transport 复用能力弱，尤其在高并发短请求下极易新建连接。必须显式配置连接池与超时。
- 设置
MaxIdleConns和MaxIdleConnsPerHost：例如都设为100，否则默认 2，连接几乎不复用 - 务必设
IdleConnTimeout（推荐30s）：防止空闲连接长期占用端口 - 禁用
http.Transport的ForceAttemptHTTP2（除非后端明确支持 HTTP/2），HTTP/1.1 下 keep-alive 更稳定 - 所有
http.Request必须带context.WithTimeout()，避免 goroutine 泄漏拖垮连接池
示例关键配置：
立即学习“go语言免费学习笔记（深入）”；
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 100,
MaxIdleConnsPerHost: 100,
IdleConnTimeout: 30 * time.Second,
// 不要设 DialContext 为自定义函数除非必要，否则可能绕过连接池
},
}Nginx 代理层：proxy_bind + keepalive 是扛住 10W+ 长连接的关键
如果你的 Gin 服务前面挂了 Nginx 做反向代理，且 upstream 是另一组服务，那么 Nginx worker 进程自身会消耗大量临时端口。单 IP + 默认配置撑不过 65535 连接。
- 启用
upstream的keepalive：例如keepalive 32;，让每个 worker 复用最多 32 个到后端的长连接 - 配合
proxy_http_version 1.1和清空Connection头：proxy_set_header Connection ''; - 若仍不够，用
proxy_bind绑定多个内网 IP：proxy_bind 192.168.1.10;，每个 IP 提供独立的 65535 端口空间 - 必须同步调优内核：
net.ipv4.ip_local_port_range = "1024 65535"，否则proxy_bind也白搭
别忽略系统级 TIME_WAIT 回收：tcp_tw_reuse 在 Linux 下比缩短延迟更可靠
Windows 上靠改 TcpTimedWaitDelay 和 MaxUserPort；Linux 下优先开 net.ipv4.tcp_tw_reuse = 1，它允许把处于 TIME_WAIT 的端口重用于新连接（需对方支持 TCP timestamp，现代服务基本都支持）。
-
tcp_tw_reuse比单纯缩短tcp_fin_timeout更安全：不会破坏 TIME_WAIT 的设计语义（防止旧包干扰新连接） - 必须配
net.ipv4.tcp_timestamps = 1（默认开启），否则tcp_tw_reuse不生效 - 不要开
tcp_tw_recycle（已废弃且在 NAT 环境下必然出错） - 验证是否生效：
ss -s | grep -i time_wait，压测中应稳定在 1–2 万以内，而非持续攀升
端口耗尽从来不是单点问题——Gin 代码、HTTP 客户端、Nginx 配置、Linux 内核参数，四者必须协同调整。漏掉任意一环，压测时都会在某个阈值突然崩掉。
