轮询是Nginx默认的无状态负载均衡算法，按upstream中server顺序循环分发请求，需清除weight、ip_hash等干扰配置并统一健康检查参数才能实现真正均匀分配。
直接上手轮询，是掌握 Nginx 集群流量分流最轻量、最可靠的起点。它不依赖复杂状态或实时指标，只要配置干净、后端稳定，就能让请求按固定顺序均匀打到每台机器上。
轮询不是“随机挑”，而是“挨个点名”
轮询背后没有计时器、不看响应快慢、也不统计连接数——只靠一个内部指针，在 upstream 列表里从上到下、循环移动：
- 第 1 个请求 → 发给列表第 1 行的 server
- 第 2 个请求 → 发给列表第 2 行的 server
- 第 3 个请求 → 发给列表第 3 行的 server
- 第 4 个请求 → 列表到底了，指针回开头，再发给第 1 行
这个过程完全确定、无状态、零计算开销。你写三行 server，它就严格走三步一循环。
为什么分得不匀？大概率是配置“动了手脚”
轮询本身不会偏心，但以下几类配置会悄悄覆盖默认行为：
-
weight 参数出现：哪怕只有一行写了
server 192.168.1.10 weight=2;，整个 upstream 就自动降级为加权轮询，不再是均等分配 -
ip_hash 或 hash 指令残留：哪怕注释掉了
# ip_hash，只要这行没删，Nginx 启动时仍可能报错或行为异常；必须整行移除 -
健康检查参数不一致：比如 A 服务器设了
max_fails=1，B 写的是max_fails=5，A 更容易被临时摘除，导致流量集中到 B
三步配出真正均匀的轮询
不需要加新功能，关键是清理和对齐：
- 删掉所有
weight=、backup、down等修饰词，server 行保持最简形态：server 192.168.1.10; - 确认 upstream 块顶部没有任何算法指令（
ip_hash、least_conn、hash $arg_id等全部删除） - 为每台 server 统一加上相同健康探测：
max_fails=2 fail_timeout=15s，避免某台因宽松策略长期“带病上岗”
验证是否生效，别靠猜
在 location 块中加入日志记录，用 $upstream_addr 直接看到每次请求落到哪台 IP：
access_log /var/log/nginx/upstream.log upstream_log;
跑十几条请求后查日志，就能清楚看到是 101→102→103→101 循环，还是卡在某一台——这是判断轮询是否“在线”的唯一硬依据。
