轮询是Nginx upstream默认策略，无需显式声明；常见错误包括误加round_robin指令导致启动失败、漏写端口引发502、权重在纯轮询下被忽略、未配max_fails/fail_timeout致故障扩散。
轮询是 Nginx upstream 的默认策略，不用写任何关键字就自动启用——但正因为“太简单”，反而最容易踩坑。很多线上故障不是因为没配，而是配得“看似正确、实则失效”。
误以为要显式声明 round_robin
常见错误是在 upstream 块里加 round_robin 或类似关键词：
-
upstream backend { round_robin; server a; server b; }→ Nginx 启动失败，报错 unknown directive "round_robin" - 轮询是隐式行为：只要没写
ip_hash、least_conn、hash等明确算法，就走轮询 - 不需要、也不能加任何启用指令；写了反而语法报错
忽略端口导致后端连接失败
只写 IP 不写端口，Nginx 默认用 80 端口发起 upstream 连接，而实际后端服务往往监听 8080、3000 等非标端口：
- 错误写法：
server 192.168.1.10;（默认连 80，多数情况不通） - 正确写法：
server 192.168.1.10:8080;，必须显式带端口号 - 尤其注意 Docker 或 Kubernetes 环境中，Service ClusterIP 通常不暴露 80，漏写端口=请求全 502
权重与轮询混用却不理解其逻辑
轮询本身不支持 weight；但加权轮询（Weighted Round Robin）是轮询的增强版，二者常被混淆：
- 纯轮询下写
weight=2无效——Nginx 会忽略该参数，仍按顺序均分 - 只有在加权轮询场景下 weight 才生效，且必须紧贴 server 行：
server 192.168.1.10:8080 weight=3; - weight=3 和 weight=1 的服务器，请求比例≈3:1，不是绝对值，而是相对比值
- 权重不感知实时负载，高权重大机 CPU 95% 时仍照常收请求，直到触发
max_fails才剔除
没配健康检查导致故障扩散
轮询默认不主动探测后端状态，单台宕机后仍会持续尝试转发，造成请求堆积和超时蔓延：
- 必须手动添加容错参数：
max_fails=3 fail_timeout=30s - 例如：
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s; - 含义：30 秒内连续失败 3 次，标记该节点为不可用，暂停 30 秒再试
- 若所有后端都失败，Nginx 会 fallback 到最近成功响应过的节点（不是 bug，是兜底机制）
