轮询调度不直接控制连接持久化，但影响长连接复用效果；需配合upstream keepalive、HTTP/1.1配置及后端Keep-Alive支持才能实现真正复用，否则仅为“伪长连接”。
轮询调度本身不直接影响连接是否持久化，但它和连接复用机制协同工作时，会显著改变长连接的实际效果——用得好能提升并发吞吐，用得不当反而让持久化失效。
轮询不管理连接生命周期，但决定谁来承接复用连接
轮询只管“下一个请求发给哪台后端”，不关心当前有没有空闲连接、也不判断哪台后端连接数更少。真正控制连接复用的是 keepalive 指令和 HTTP 协议版本。但轮询决定了：这个复用连接是固定打向某台机器，还是在多台之间来回切换。
- 如果后端服务支持长连接（如 REST API 启用了 HTTP/1.1 Keep-Alive），Nginx 的轮询会让每个客户端的多个请求轮流落到不同后端——这会破坏连接复用效果，因为每换一台就要新建 TCP 连接
- 只有当客户端持续发起请求、且 Nginx worker 复用的是同一台后端的空闲连接时，才能真正节省建连开销；轮询本身不保证这点，需要配合
keepalive和稳定的请求节奏 - 例如：6 个连续请求按轮询分发到 A→B→C→A→B→C，若每台后端都只维持少量 keepalive 连接，很可能每次都要新建连接，实际变成“伪长连接”
必须显式开启后端连接复用，否则轮询只是“轮流短连”
默认情况下，Nginx 到后端是短连接。即使客户端用了 Keep-Alive，Nginx 若没配对参数，仍会为每个请求新建 TCP 连接，轮询就失去了复用价值。
- 在
upstream块中加keepalive 32;：每个 worker 最多缓存 32 个空闲连接到后端 - 在
location中设proxy_http_version 1.1;和proxy_set_header Connection "";：告诉后端别关闭连接 - 确保后端服务也启用 Keep-Alive（如 Tomcat 的
connectionTimeout和keepAliveTimeout配置合理）
轮询 + 长连接在不同场景下的表现差异
是否能发挥持久化优势，取决于后端性质和流量模式：
- 静态资源或轻量 API（响应快、无状态）：轮询 + keepalive 效果明显，连接复用率高，延迟稳定
- 长连接网关（如 WebSocket、gRPC）：轮询会导致连接漂移，必须改用
ip_hash或hash $connection_id等粘性策略 - 后端性能不均（比如混用新旧机型）：轮询会把等量请求分过去，但弱机建连慢、复用率低，实际连接开销更大，此时应考虑
least_conn
验证连接是否真被复用，不能只看配置
光写上 keepalive 不代表生效，要实测确认：
- 查 Nginx access 日志，加上
$upstream_addr字段，观察相同客户端 IP 的连续请求是否命中同一后端地址（说明复用成功） - 用
ss -tan | grep :8080 | wc -l查后端端口 ESTABLISHED 连接数，压测时应平稳而非随请求数线性增长 - 抓包看 TCP 层：连续请求间没有 SYN 包，说明连接被复用
