避免轮询过载的关键是添加动态保护机制：启用主动健康检查并设合理失败阈值；限制单节点并发连接与请求速率；辅以least_conn或权重微调；结合后端反馈实现轻量级降级。
轮询本身只是按顺序分发请求，不感知后端实际负载，所以单纯用轮询容易导致某台服务器因响应慢、连接堆积或突发流量而过载。要避免单台被“打死”，关键不是放弃轮询，而是给它加动态保护机制。
启用主动健康检查 + 合理设置失败阈值
轮询默认只在连接失败时临时剔除节点，但很多过载表现是响应变慢、超时增多，而非直接断连。必须开启主动探测：
- 在 upstream 中配置 health_check（需 Nginx Plus）或用开源版的 nginx_upstream_check_module 模块
- 至少设 max_fails=2 和 fail_timeout=10s，让 Nginx 在短时间连续失败后快速隔离异常节点
- 避免把 fail_timeout 设得过长（比如 60s），否则故障节点可能持续吸走流量十几秒
限制单节点并发连接和请求速率
即使节点“活着”，也要防它被压穿。可在 upstream 或 location 级别加限流：
- 用 limit_conn 控制每个后端能接收的最大并发连接数，例如：
limit_conn addr 100; - 用 limit_req 限制单位时间请求数，配合 burst 和 nodelay 防突发打爆
- 对关键接口单独做更严的限流，而不是全站一刀切
搭配 least_conn 或权重微调作补充
纯轮询在后端性能不均时天然失衡。可小幅优化：
- 若部分服务器规格更高，用 weight 参数适度提高其分配比例，减轻弱节点压力
- 在连接耗时差异大的场景（如含数据库操作的接口），改用 least_conn 更稳妥——它看的是当前活跃连接数，比轮询更能反映真实负载
- 不建议混用 weight 和 least_conn，Nginx 不支持两者同时生效
依赖后端反馈做轻量级降级
让后端在自身承压时主动“举手”：
- 后端服务返回特定 HTTP 状态码（如 503 + 自定义 header）时，Nginx 可通过 proxy_next_upstream 触发重试并跳过该节点
- 结合自定义日志字段，用 log_format 记录每次转发的目标和响应时间，便于事后分析哪台节点常成瓶颈
- 避免依赖单一指标，把响应时间、错误率、连接数三者组合判断是否隔离
