Gin默认HTTP长连接会静默断开，因其依赖的http.Server不启用TCP keepalive，而OS默认2小时探测远超NAT/防火墙5–30分钟阈值，导致中间设备静默清理连接；必须通过net.ListenConfig显式设置KeepAlive，并协同配置ReadTimeout、WriteTimeout和IdleTimeout（均须小于中间设备超时）才能真正保活。
为什么 Gin 默认 HTTP 长连接会静默断开
Gin 本身不干预 http.Server 的底层行为，它只是注册 Handler；真正决定连接是否“保活”的是 Go 标准库的 http.Server 和操作系统 TCP 栈。默认情况下：http.Server 不启用 TCP keepalive，OS 层探测间隔通常是 2 小时（Linux /proc/sys/net/ipv4/tcp_keepalive_time），而中间设备（Nginx、ALB、NAT 网关）普遍在 5–30 分钟就清理空闲连接——结果就是服务端还认为连接活着，客户端发请求时直接收到 connection reset by peer。
必须用 net.ListenConfig 设置 TCP keepalive，不能只改 http.Server
仅给 http.Server 设置 IdleTimeout 不够，它只管应用层空闲，不管 TCP 连接是否被中间设备踢掉。真正在底层触发探测的是 socket 的 SO_KEEPALIVE 和 TCP_KEEPIDLE 等选项，必须在监听器创建前注入：
-
net.ListenConfig{KeepAlive: 30 * time.Second}只控制“开始探测前的空闲等待”，设为 0 会继承系统默认（通常无效） - 更细粒度控制（如
TCP_KEEPINTVL、TCP_KEEPCNT）需用Control回调 +syscall.SetsockoptInt，尤其在容器或云环境里，conntrack超时（如 4 分钟）可能比 OS 探测还早生效 - 别用
http.ListenAndServe—— 它绕过ListenConfig，等于没配
http.Server 的三个 Timeout 必须协同设置
ReadTimeout、WriteTimeout、IdleTimeout 各司其职，配错会导致连接提前关闭或无法回收：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
ReadTimeout：从 Accept 开始，到读完请求头为止（不含 body 流式读取），建议 ≤ 10s -
WriteTimeout：从响应开始写入，到写完全部数据为止，建议 ≤ 10s -
IdleTimeout：连接空闲（无新请求）最大时长，**这是保活关键**，必须小于中间设备超时（如 Nginxproxy_read_timeout设为 300s，则此处设 ≤ 240s） - 三者都设为 0 表示不限制 → 文件描述符泄漏风险极高
Gin 场景下容易忽略的两个实操细节
很多人以为配完 http.Server 就万事大吉，但在 Gin 实际部署中，还有两个高频翻车点：
立即学习“go语言免费学习笔记（深入）”；
- Nginx 代理层必须同步调大超时：默认
proxy_read_timeout 60s、proxy_send_timeout 60s，若后端IdleTimeout设了 240s，但 Nginx 先断，Gin 根本收不到断连通知 - 客户端发起的 SSE 或长轮询请求，需手动 flush 响应头：
c.Writer.WriteHeader(http.StatusOK)+c.Writer.(http.Flusher).Flush()，否则浏览器卡在 pending 状态，不是连接问题，而是 HTTP 协议阶段卡住
真正起作用的从来不是某个单一参数，而是从 socket 层（ListenConfig）、HTTP 层（http.Server）、反向代理层（Nginx）、客户端协议层（SSE/长轮询 flush）这四层全部对齐超时窗口。漏掉任意一层，保活就失效。
