轮询是nginx默认负载均衡策略，按顺序分发请求，需配置多个server且默认权重为1；但需手动添加max_fails、fail_timeout和proxy_next_upstream等参数提升容错性，并注意ip复用、权重混淆、dns固化等常见问题。
轮询是 Nginx 默认启用的负载均衡策略，无需额外声明，只要在 upstream 块中列出多个后端服务器，Nginx 就会自动按顺序分发请求。它简单、公平、无状态，适合大多数基础集群场景，但实际使用中容易忽略几个关键细节和优化点。
轮询的基本配置与默认行为
轮询不需要显式写 round_robin 关键字，只要 upstream 中有多个 server 行，即生效：
示例配置：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
此时三台服务器权重均为 1，Nginx 按照 1→2→3→1→2→3 的循环顺序分配请求。注意：
– 端口未指定时默认为 80；
– 所有 server 默认参与调度，不加 backup 或 down 标记；
– 不支持基于响应时间或当前连接数的动态调整，纯静态顺序。
让轮询更可靠：故障感知与自动剔除
默认轮询只做 TCP 连通性探测（三次握手成功即认为健康），无法识别应用层异常（如服务假死、HTTP 500 响应）。需手动增强健壮性：
- 添加
max_fails=3 fail_timeout=30s：连续 3 次失败（超时或连接拒绝）后，该节点被临时摘除 30 秒 - 搭配
proxy_next_upstream error timeout http_500：当后端返回错误或超时，Nginx 自动重试下一个节点（对客户端透明） - 避免仅依赖日志观察——建议开启
log_format记录$upstream_addr和$upstream_status，便于定位分发路径与失败节点
常见误区与避坑建议
看似简单，但轮询在生产环境常因配置疏忽导致流量倾斜或单点压力突增：
-
IP 复用干扰测试结果：浏览器或 curl 默认复用连接（keepalive），可能多次请求命中同一后端。验证时建议加
-H "Connection: close"或用ab/wrk工具压测 -
权重未归零却误以为“等权”：若某 server 行写了
weight=1，其他没写，它们仍是等权；但若混用weight=2和无 weight，则权重比为 2:1，不再是纯轮询 -
DNS 解析导致地址固化：若 upstream 中写的是域名（如
server app1.example.com;），Nginx 启动时只解析一次。建议用 IP + 定期 reload，或启用resolver配合valid参数实现动态 DNS 刷新
何时该放弃轮询？
轮询不是万能解法。以下情况建议切换策略：
- 后端服务器 CPU/内存明显不均（如一台 16C，另两台 4C）→ 改用加权轮询
- 业务强依赖会话（如登录态、购物车）且未做共享存储 → 必须启用
ip_hash - 存在长连接或慢请求堆积，担心某节点连接数过高 → 考虑
least_conn - 需要按 URL 或 Header 路由 → 应结合
map模块做条件 upstream 分流，而非依赖轮询本身
