Gin 默认不处理慢连接，因其基于net/http封装，请求头未解析完成前无法介入；需手动配置http.Server的ReadHeaderTimeout、ReadTimeout和IdleTimeout等参数实现防护。
Gin 本身不内置慢速死连接（slowloris、长时挂起连接）的检测与主动断开机制，必须依赖底层 HTTP Server 配置或中间件干预。
为什么 Gin 默认不处理慢连接
Gin 是基于 net/http 的轻量封装，所有连接生命周期由 Go 标准库的 http.Server 管理。Gin 的路由和中间件只在请求头解析完成、http.Handler 被调用后才介入——而慢速连接往往卡在 TCP 握手后、请求头未发完或分块发送极慢的阶段，此时 Gin 还没拿到请求上下文。
- Go
http.Server默认没有“连接空闲超时”或“读取请求头超时”的细粒度控制（ReadHeaderTimeout是 Go 1.8+ 加入，但 Gin 不暴露该字段） -
gin.Engine没有提供类似 Nginx 的client_header_timeout或client_body_timeout配置入口 - 所有超时参数（如
ReadTimeout、WriteTimeout）作用于整个请求生命周期，无法区分“卡在 header 阶段”和“正常处理中”
如何给 Gin 加上慢连接防护
核心思路是绕过 Gin 封装，直接配置底层 http.Server 实例，并启用 Go 1.8+ 提供的精确超时字段：
- 使用
http.Server手动启动 Gin 引擎，而非调用router.Run() - 设置
ReadHeaderTimeout（推荐 5–10 秒）：限制客户端发送完整请求头的最大耗时 - 设置
ReadTimeout（建议 ≤30 秒）：从连接建立到读取完全部 body 的总上限（防 slow POST） - 设置
IdleTimeout（推荐 60 秒）：连接空闲（无数据收发）时自动关闭，防 keep-alive 挂死 - 避免只设
WriteTimeout：它不影响连接建立和读取阶段，对慢连接无效
示例代码：
srv := &http.Server{
Addr: ":8080",
Handler: router,
ReadHeaderTimeout: 5 * time.Second,
ReadTimeout: 30 * time.Second,
IdleTimeout: 60 * time.Second,
WriteTimeout: 15 * time.Second,
}
log.Fatal(srv.ListenAndServe())常见误判与性能影响
过度收紧超时参数会导致真实用户被误杀，尤其在弱网、高延迟或大文件上传场景：
-
ReadHeaderTimeout设为 2 秒：可能干掉跨国访问、移动蜂窝网络下的合法请求 -
IdleTimeout小于 30 秒：会频繁中断 HTTP/1.1 keep-alive 连接，增加 TCP 握手开销 - 不要依赖中间件做“慢连接检测”：比如在
gin.HandlerFunc里记录 start time，因为慢连接根本进不来这个函数 - 若需更精细控制（如 per-IP 限速、连接数限制），必须前置到反向代理层（Nginx / Envoy），Gin 层已太晚
真正有效的慢连接防护永远发生在 TCP 层或反向代理层；Gin 只能配合标准库做基础兜底，关键参数必须显式配置 http.Server，且每个超时值都要结合业务 RTT 和上传需求权衡——设得太紧伤用户体验，设得太松留攻击面。
