Gin中间件防不了慢速连接攻击，因为攻击发生在TCP连接建立后、HTTP请求头解析完成前，此时gin.Context尚未创建，中间件根本无法执行；真正防护需在net/http Server层（如ReadHeaderTimeout）或Nginx层（如client_header_timeout+reset_timedout_connection）。
为什么 Gin 中间件本身防不了慢速连接攻击
慢速连接攻击（如 Slowloris、Slow HTTP POST）不依赖高并发或高频请求，而是通过维持大量“半开”连接——比如只发部分 HTTP 头、长时间不发完 body 或不关闭连接，让服务器持续等待，最终耗尽连接池或文件描述符（fd）。Gin 的 gin.Context 在收到完整 HTTP 请求后才被创建，而这类攻击在 TCP 连接建立后、HTTP 解析完成前就卡住了，Gin 根本没机会运行任何中间件。
换句话说：RateLimitMiddleware、ipBlacklist 这类基于 gin.Context 的中间件，在慢速连接阶段完全不生效。它们防御的是应用层（七层）的 CC/高频请求，不是传输层（四层）的连接耗尽。
真正起作用的是 Go net/http 服务层和 Nginx 前置防护
要防慢速连接，必须在 Gin 启动的 http.Server 层或更外层（如反向代理）设限。Go 标准库提供关键参数：
-
ReadTimeout：从连接建立到读完全部 request header 的最大时长（注意：不包含 body） -
ReadHeaderTimeout：仅限制读取 header 的时间，比ReadTimeout更精准，推荐使用 -
WriteTimeout：从 response.WriteHeader 开始到写完全部 body 的最大时长 -
IdleTimeout：空闲连接（keep-alive 状态下无新请求）的最大保持时间
示例配置：
srv := &http.Server{
Addr: ":8080",
Handler: r, // gin.Engine
ReadHeaderTimeout: 8 * time.Second,
WriteTimeout: 15 * time.Second,
IdleTimeout: 25 * time.Second,
}
若部署在 Nginx 后，更应优先用 Nginx 的 client_header_timeout 和 reset_timedout_connection on，它能在内核层面更快释放异常连接，避免 Go 服务线程被阻塞。
不要试图在 Gin 中间件里“检测慢速连接”
有人尝试在中间件里记录 c.Request.RemoteAddr + 时间戳，再查超时连接——这无效。原因有三：
- 超时连接根本不会进入中间件，
c对象压根没生成 - 即使能拿到连接，Go 的
net.Conn不暴露底层读状态，无法判断是“真慢”还是“网络延迟” - 手动维护连接状态会引入竞态和内存泄漏，违背 Go 的并发模型设计初衷
正确做法是：把防御下沉到基础设施层。Nginx 配置 client_header_timeout 8s + reset_timedout_connection on，Go 服务配好 ReadHeaderTimeout，再配合系统级 ulimit -n 和 net.core.somaxconn 调优。Gin 中间件只管它该管的事：鉴权、日志、SQL 注入/XSS 过滤。
例外：仅当攻击已穿透前置层并表现为“长耗时 handler”时，中间件才可补救
如果慢速攻击绕过了 Nginx 或直接打到 Go 服务（如内网直连），且表现为某个接口执行时间异常长（例如上传大文件时客户端故意断续发送），这时可在中间件中加粗粒度超时控制：
r.GET("/upload", func(c *gin.Context) {
// 设置 context 超时，仅对 handler 内部有效
ctx, cancel := context.WithTimeout(c.Request.Context(), 30*time.Second)
defer cancel()
c.Request = c.Request.WithContext(ctx)
<pre class="brush:php;toolbar:false;">// 后续业务逻辑需主动检查 ctx.Err()
if err := handleUpload(c); err != nil {
if errors.Is(err, context.DeadlineExceeded) {
c.AbortWithStatusJSON(http.StatusRequestTimeout, gin.H{"error": "upload timeout"})
return
}
}
})
但注意：这防的是 handler 执行慢，不是连接慢；它不能回收已被占用的 fd，只能避免 goroutine 泄漏。真正的防线永远在 http.Server 配置和反向代理上。
