Fiber本身不支持IP级并发连接数限制，因其运行在HTTP层之上，无法干预TCP连接建立；真正有效的方案需在nginx等前置网关层用limit_conn指令，或自定义net.Listener包装器在Accept阶段控制。
Go Fiber 本身不提供 IP 级连接数限制能力
Fiber 的 App 实例和内置中间件（如 limiter.New()）只支持按请求路径、Header、用户标识等维度限流，不识别客户端 IP 的并发连接数。它没有类似 nginx 的 limit_conn 或 net/http 的底层连接池绑定 IP 的机制。所谓“单个 IP 最大连接数”，本质是 TCP 连接层面的控制，Fiber 运行在 net/http 之上但屏蔽了该层细节，无法直接干预。
真正生效的方案只能落在 HTTP 服务器层或前置网关
要限制每个 IP 同时建立的活跃 HTTP 连接数（非请求数），必须在更底层介入：
- 用
nginx做反向代理，在 upstream 配置中启用limit_conn指令，配合limit_conn_zone $binary_remote_addr zone=addr:10m; - 若部署在 Kubernetes，可用
nginx-ingress的nginx.ingress.kubernetes.io/limit-connections注解 - 云厂商如 AWS ALB / Azure Front Door 不支持连接数限制，仅支持 QPS 限流；Cloudflare 则完全不暴露该能力
- 自行包装
http.Server并 hookConnState回调可统计连接，但需手动维护 map + sync.Map + 超时清理，且无法阻断已握手但未发请求的空闲连接
误用 limiter.New() 会导致行为不符合预期
常见错误是把 IP 限流写成这样：
app.Use(limiter.New(limiter.Config{
Max: 10,
Expires: 30 * time.Second,
KeyGenerator: func(c *fiber.Ctx) string {
return c.IP()
},
}))
这实际限制的是「每秒最多 10 个请求」，不是「最多 10 个并发连接」。用户开 20 个浏览器标签页持续长轮询，仍可能维持 20 个连接，而该限流器只在每次 ctx.Next() 时检查请求数，对已建立但挂起的连接无感知。
容易被忽略的点：HTTP/1.1 默认复用连接（keep-alive），一个 TCP 连接可承载多个请求；而 HTTP/2 更是多路复用，单连接承载数十请求。此时“连接数”和“请求频次”完全脱钩，强行混用限流器会失去控制意义。
