Nginx默认轮询策略无需声明算法，仅在upstream块中列出server地址即可；请求按顺序循环分发，配合max_fails和fail_timeout可实现故障自动剔除与恢复。
Nginx 中默认的轮询负载均衡策略不需要额外声明算法，只要在 upstream 块中列出后端服务器，不加任何调度关键字，就自动启用轮询。
核心要点：不写 least_conn、不写 ip_hash、不写 weight，就是轮询。
H3 配置写法很简单
upstream 块里只写 server 地址，每行一个：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}然后在 server 或 location 中引用：
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}Nginx 启动后，请求就会按顺序依次发给这三台机器：第1次→10，第2次→11，第3次→12，第4次→10……循环往复。
H3 可靠性增强建议
轮询本身不感知后端健康状态，但可以搭配两个参数实现自动故障剔除：
-
max_fails：连续失败多少次后标记为不可用 -
fail_timeout：在这段时间内失败达到max_fails次，就暂停转发
例如：
upstream backend {
server 192.168.1.10:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8080 max_fails=3 fail_timeout=30s;
}这样当某台服务连续 3 次超时或返回 5xx，Nginx 会在接下来 30 秒内跳过它，等时间过去再试探恢复。
H3 适用场景和注意事项
- 适合后端服务器硬件配置接近、应用响应时间稳定、无状态服务（如 REST API、静态资源）
- 不适合需要会话保持的场景（比如登录态依赖内存），这时应改用
ip_hash - 轮询不考虑实时负载（CPU、连接数），如果某台机器卡顿，仍会继续分请求过去
- 若需更智能调度，可考虑
least_conn（最少连接）或第三方模块支持的响应时间加权
H3 验证是否生效
重启 Nginx 后，用 curl 连续访问几次，同时查看各后端 access 日志，应该看到请求按顺序逐台出现。也可以用 ab 或 wrk 做小压力测试观察分布。
