nginx轮询负载均衡默认按upstream中server声明顺序循环分发请求，每台服务器权重为1，失效时依据max_fails和fail_timeout自动跳过并重试，适合轻量稳定服务但不适应负载不均或慢响应场景。
nginx轮询负载均衡默认采用顺序循环分发机制，不依赖外部状态或连接数统计，只按配置中upstream块内server指令的声明顺序，逐台分配请求。
轮询的基本工作方式
它把后端服务器看作一个固定顺序的列表，每次收到新请求时，就指向下一台服务器，到达末尾后自动回到开头，形成闭环。这个过程由nginx内部计数器维护，无需共享状态，也不受请求耗时影响。
- 假设有三台服务器 A、B、C，配置顺序为
server A; server B; server C;，则第1、4、7…个请求发给A，第2、5、8…发给B，第3、6、9…发给C - 若某台服务器临时不可用（如返回502/503或超时），nginx会将其标记为“失效”，在一段时间内跳过该节点，失效期过后自动重试
- 所有服务器默认权重为1，未显式配置
weight时，等效于完全均分流量
轮询与服务器状态的关系
轮询本身不感知连接数、响应时间或CPU使用率，但具备基础的容错能力：通过max_fails和fail_timeout参数可控制健康检查行为。
-
max_fails=2 fail_timeout=30s表示：连续2次失败后，在30秒内不再向该服务器转发请求 - 失效期间，轮询逻辑自动绕过该节点，剩余服务器继续按原顺序承接流量
- 30秒后nginx会尝试发送一个探测请求，成功则恢复服务，否则继续隔离
适用场景与局限性
轮询适合部署环境简单、后端服务轻量且响应时间稳定的场景，比如静态资源服务、无状态API网关。
- 优势是配置极简、性能开销低、无额外依赖
- 缺点是对长连接、慢响应服务不够友好——某台服务器可能因处理耗时请求积压大量连接，而轮询仍持续派发新请求
- 当后端服务器硬件差异大（如16核 vs 4核）或负载特征不一致时，单纯轮询会导致实际负载不均
如何验证轮询是否生效
可通过日志或简单测试确认分发行为：
- 在每台后端服务器上记录访问来源IP和时间，观察请求分布是否呈现周期性规律
- 用
curl -I http://nginx-ip/快速发起多次请求，配合upstream中各server的access_log，比对日志时间戳与顺序 - 注意：浏览器可能复用连接（keep-alive），建议用
curl -H "Connection: close"或脚本批量发起独立请求
