nginx轮询负载均衡生效需三个底层机制对齐：upstream必须定义在http块内、proxy_pass地址须协议一致且名称精准匹配、轮询依赖健康状态感知而非静态分配。
轮询负载均衡在 Nginx 中看似简单，但配置稍有偏差就容易出现请求不均、502 错误或完全不生效的情况。真正起作用的不是“写了几行 server”，而是三个底层机制是否对齐。
upstream 必须定义在 http 块内
这是硬性语法要求，不是风格建议。Nginx 只允许 upstream 指令出现在 http 上下文中，一旦放在 server 或 location 里，reload 就会报错：nginx: [emerg] "upstream" directive is not allowed here。
- ✅ 正确结构：http { upstream backend { server 192.168.1.10; } server { location / { proxy_pass http://backend; } } }
- ❌ 错误结构：server { upstream backend { ... } location / { ... } }
- 若用 include 拆分配置，被引入的文件必须以 http { 开头，不能只写一个 upstream 块
proxy_pass 地址必须协议一致且名称精准匹配
proxy_pass 后面的地址不是别名字符串，而是一个带协议的 URI 引用，它必须和 upstream 名称严格对应，且协议（http/https）要与 upstream 中 server 的协议一致。
- ✅ 正确写法：upstream backend { server 192.168.1.10:80; } → proxy_pass http://backend;
- ❌ 常见错误：proxy_pass http://backend/（末尾斜杠会触发 URI 重写，可能破坏路径）
- ❌ 隐蔽错误：upstream 中没写端口，却写成 proxy_pass http://backend:80（触发 DNS 解析，失败即 502）
- 后端若为 HTTPS，upstream 中需写 https://192.168.1.10，proxy_pass 也必须是 https://backend
轮询生效依赖健康状态感知，不是静态分配
Nginx 的轮询不是“固定顺序发包”，而是动态调度——只有被判定为“可用”的服务器才会参与轮询。一台服务器连续失败后会被临时摘除，此时轮询自动降级为剩余可用节点间的分配。
- 默认仅做 TCP 连通性检测；如需更可靠判断，应显式配置健康检查参数
- 推荐组合：max_fails=3 fail_timeout=30s，表示连续 3 次失败后，30 秒内不再调度该节点
- weight 参数只在所有节点都“可用”时才影响比例；某台被标记为 down，它的权重就失效
- 避免设置过低的 max_conns（如 1），否则易因连接池耗尽导致大量请求排队或拒绝
验证轮询是否真正在工作
不能只看配置有没有报错，要观察实际流量分布：
- 开启 Nginx access_log，用 tail -f + awk 统计各后端 IP 出现频次
- 用 ab 或 wrk 发起并发请求（如 ab -n 1000 -c 100 http://your-domain/）
- 检查后端服务自身日志，确认请求确实落到不同机器上，而非全部打到第一台
- 手动停掉一台后端，观察 Nginx 是否自动跳过它，且其余节点请求量上升
