轮询本身不产生抖动，本质是连接状态与后端服务能力脱节；需排查“谁在切、为何切错、切后是否真能通”三层，聚焦健康检查误判、连接复用失效及tcp层重建问题。
轮询（round-robin）本身不产生抖动，但轮询切换时的瞬时连接抖动，本质是连接状态与后端实际服务能力脱节的表现——比如某次请求刚被分到节点A，而A正因GC、锁竞争或连接池耗尽短暂不可用；又或者客户端复用旧连接，Nginx却已将该连接路由到刚下线的节点。排查需聚焦“谁在切”“为何切错”“切后是否真能通”三层。
确认抖动是否真实由轮询策略触发
很多所谓“轮询抖动”，其实是健康检查误判或连接复用失效的副产品：
- 检查 error.log 中是否密集出现 upstream timed out 或 connection refused，若集中在同一时间点且对应不同 upstream 地址，说明不是轮询本身问题，而是后端批量失联
- 启用 $upstream_addr 和 $upstream_response_time 到 access_log，观察抖动窗口内是否出现“同一客户端连续两次请求落到不同后端，且第二次响应时间突增＞300ms”
- 用 ss -tn state established | grep :端口 在各后端统计 ESTABLISHED 连接数，若轮询切换前后某节点连接数骤降再陡升，说明连接未平滑迁移，而是被强制中断重建
检查健康检查是否在“假性摘除”节点
轮询本身无状态，但 Nginx 的健康检查会动态修改可用节点集合——一旦误判，就会导致批量重调度，引发抖动：
- 确认 max_fails 和 fail_timeout 设置是否过激：跨机房链路中，max_fails=1 fail_timeout=1s 极易把一次网络毛刺当成节点宕机
- 验证健康检查路径返回码是否稳定：比如配置了 health_check /health，但后端 /health 接口依赖数据库连接池，在高峰期可能偶发超时返回 503
- 若使用 nginx_upstream_check_module，需单独测试 check 接口（如 curl http://node:8080/check）是否可访问、响应头是否含 status:up
验证长连接复用是否与轮询冲突
轮询默认不绑定连接，但客户端若保持 HTTP/1.1 长连接，Nginx 可能复用已有 upstream 连接池——当后端节点被健康检查临时摘除，连接池却未及时清空，就会导致后续请求打到“逻辑已下线、物理仍存活”的节点：
- 检查是否启用 keepalive：upstream 块中若有 keepalive 32，需确保 proxy_http_version 1.1 和 proxy_set_header Connection '' 同时存在，否则连接无法复用
- 观察 $connection_requests 日志变量：若某客户端连续请求中该值持续增长（如从 1 → 47），说明连接未被轮询重新分配，而是被长期复用——此时应配合 keepalive_requests 50 主动断连
- 禁用 ip_hash 或 hash $remote_addr consistent 等固定路由策略，它们会掩盖轮询行为，让抖动表现为“部分用户稳定、部分用户频繁失败”
抓包定位切换瞬间的真实行为
仅看日志不够，必须看到 TCP 层的实际流向：
- 在 Nginx 机器上运行：tcpdump -i any 'host 后端IP and port 后端端口' -w roundrobin.pcap，复现抖动时刻
- 用 Wireshark 打开 pcap，过滤 tcp.flags.syn == 1，查看 SYN 包是否在轮询切换后集中爆发——若大量新连接在同一毫秒建立，说明旧连接池失效，被迫重建
- 对比 SYN 时间与 Nginx access_log 中 time_local，确认是 Nginx 主动发起新连，还是客户端重试触发
