haproxy 默认无法对 http/1.1 持久连接实现请求级负载均衡，客户端复用 tcp 连接会导致所有请求被路由至同一后端；可通过服务端主动关闭连接、客户端设置 `request.close = true`，或在 haproxy 中启用 `http-server-close` 模式解决。
HTTP/1.1 协议默认启用 Keep-Alive 机制，允许客户端在单个 TCP 连接上发送多个 HTTP 请求，以提升性能。然而，这一特性在 HAProxy 前置的负载均衡场景中会引发「连接粘连（connection stickiness）」问题：只要客户端不主动断开连接，HAProxy 就会持续将后续请求转发至最初选定的后端服务器——这并非故障，而是其默认行为（http-keep-alive 模式）的自然结果。
在 Go 客户端与服务端长期运行的场景中（如使用 go-martini 的 Web 服务），这种持久连接尤为常见。而 curl 等短生命周期工具能正常轮询，正是因为每次调用都新建并立即关闭 TCP 连接，从而触发 HAProxy 的负载均衡逻辑。
✅ 推荐解决方案：HAProxy 配置 http-server-close
这是最优雅、侵入性最小的方案。它让 HAProxy 在每个 HTTP 请求完成后主动关闭与后端服务器的连接，但保留与客户端的长连接，兼顾性能与均衡性：
backend web_servers
mode http
balance roundrobin
http-server-close # ← 关键配置：断开后端连接，不中断客户端
server srv1 10.0.1.10:8080 check
server srv2 10.0.1.11:8080 check⚠️ 注意：http-server-close 要求后端支持 HTTP/1.1（go-martini 默认满足），且不会影响客户端体验——浏览器、Go HTTP 客户端等仍可复用连接发起新请求，HAProxy 会为每个请求重新选择后端。
? 备选方案：客户端或服务端强制关闭连接
若暂时无法修改 HAProxy 配置，可在 Go 代码中显式禁用 Keep-Alive：
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
客户端侧（发起请求时）：
req, _ := http.NewRequest("GET", "http://haproxy-ip/api", nil)
req.Close = true // 发送 Connection: close 头，通知服务端关闭连接
client := &http.Client{}
resp, _ := client.Do(req)服务端侧（go-martini 中全局设置）：
m := martini.Classic()
m.Use(func(res http.ResponseWriter, req *http.Request) {
// 强制响应头包含 Connection: close
res.Header().Set("Connection", "close")
// 同时建议设置 resp.(http.Flusher).Flush() 若需流式响应
})⚠️ 注意：req.Close = true 仅对当前请求生效；若使用 http.Transport 复用连接池，还需设置 MaxIdleConnsPerHost: 0 或 ForceAttemptHTTP2: false 防止连接复用。
? 总结与最佳实践
- 根本原因：HTTP/1.1 持久连接 + HAProxy 默认 http-keep-alive 模式 → 请求级负载均衡失效。
- 首选修复：在 backend 段启用 http-server-close ——零代码改动、语义清晰、兼容性强。
- 避免滥用：勿使用 http-close（双向关闭），否则将牺牲客户端连接复用优势，增加 TLS 握手和 TCP 建连开销。
- 验证方式：通过 haproxy -vv 确认版本支持（≥1.5），再结合 show stat 查看各 backend 的 scur（当前会话数）是否均匀分布。
正确配置后，即使 Go 客户端长时间运行，HAProxy 也能按预期在多个后端实例间分发请求，真正实现应用层的动态负载均衡。
