nginx 的 upstream 轮询策略（如 round_robin）本身不直接处理长连接复用，而是依赖 http/1.1 或 http/2 协议特性及 keepalive 模块实现。具体做法是在 upstream 块中配置 keepalive 指令设置连接池大小，并在 location 中通过 proxy_http_version 1.1 和 proxy_set_header connection "" 启用客户端到 nginx 的长连接，nginx 会自动复用后端空闲连接。
如何配置 keepalive 连接池以支持高并发长连接
在 upstream 块中添加 keepalive 指令并指定最大空闲连接数，例如 keepalive 32;，这会让 Nginx 维护一个与后端服务器的空闲连接池。当多个请求同时到达时，Nginx 优先从池中取出已建立的长连接转发请求，避免重复握手，从而提升吞吐量并降低延迟。
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
keepalive 32;
}
server {
listen 80;
location /api {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
上述配置中，keepalive 32 表示每个 worker 进程最多保持 32 个与后端的空闲连接。配合 proxy_http_version 1.1 确保使用 HTTP/1.1 协议，默认关闭 Connection: close 头，使连接可复用。若后端返回 Connection: close，该连接将被回收不再复用。
长连接复用对轮询算法的实际影响是什么
启用 keepalive 后，轮询算法仍按顺序分配新请求，但复用连接会打破严格的一一对应关系。因为空闲连接可能属于之前被选中的服务器，后续请求可能命中同一后端，导致负载分布略有不均，但在高并发下整体趋于平衡。这种机制不影响故障转移逻辑，仅优化资源利用率。
# 模拟测试脚本：curl -H "Host: test.example.com" http://localhost/api
运行多次请求观察响应来源，可见部分请求被路由至相同后端实例，这是因为连接池中存在活跃空闲连接。可通过 nginx -T 查看当前 keepalive 状态，或使用 netstat 检查 ESTABLISHED 连接数验证复用效果。若发现连接泄漏，需检查后端是否主动断开或超时设置不当。
当后端服务器返回 Connection: close 时连接复用如何处理
如果后端服务器在响应中携带 Connection: close 头部，Nginx 会立即关闭该连接并不再放入连接池，即使配置了 keepalive 也不会复用此连接。这是标准行为，符合 HTTP 规范，确保兼容性。开发者应确保后端服务正确设置头部，避免意外中断长连接。
