Nginx默认轮询不支持主动健康检查，仅依赖被动机制（max_fails/fail_timeout和proxy_next_upstream）实现容错；需配合keepalive或升级至Nginx Plus/开源check模块才能实现主动探测。
默认轮询（Round Robin）是 Nginx 最基础的负载均衡策略，但它本身不自带主动健康检查功能。也就是说，只要后端服务器在配置列表中，Nginx 就会持续向其转发请求，哪怕该服务已宕机或响应超时——这会导致用户请求失败、体验下降。要真正实现“智能轮询”，必须配合显式的健康检查机制。
理解默认轮询的局限性
Nginx 开源版的 upstream 块启用 round_robin（默认即启用）后，仅按顺序分发请求，不探测后端状态。它依赖两个被动机制来应对异常：
- 失败重试（fail_timeout + max_fails）：某台服务器连续失败指定次数后，被临时标记为不可用，进入“失效期”；
- 连接超时与响应超时（proxy_connect_timeout / proxy_read_timeout）：影响单次请求是否被判定为失败，但不改变服务器长期可用性判断。
注意：这些不是“定期探活”，而是“出错后封禁”，属于被动容错，无法提前发现隐患（如进程僵死但端口仍通）。
用 keepalive + 被动检查构建轻量健壮性
对多数中小规模应用，合理配置被动健康检查即可显著提升稳定性：
- 在
upstream中为每台 server 显式设置max_fails=2 fail_timeout=10s，表示 10 秒内失败 2 次即暂停转发； - 全局或 location 级别配置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，让特定错误码也触发重试； - 启用
keepalive 32（连接池）可减少建连开销，间接降低因瞬时拥塞导致的误判。
示例片段：
upstream backend {
server 192.168.1.10:8080 max_fails=2 fail_timeout=10s;
server 192.168.1.11:8080 max_fails=2 fail_timeout=10s;
}
location / {
proxy_pass http://backend;
proxy_next_upstream error timeout http_500 http_502;
proxy_connect_timeout 5s;
proxy_read_timeout 10s;
}
进阶方案：用 nginx-plus 或开源模块实现主动探测
若需真正的主动健康检查（如定时 HTTP GET 探针），有两条路径：
-
Nginx Plus（商业版）：原生支持
health_check指令，可配置间隔、URI、状态码、响应体匹配等，实时更新服务器状态； -
开源替代：nginx_upstream_check_module（需重新编译 Nginx）：提供类似功能，支持 TCP/HTTP 检查，配合
check_http_send和check_http_expect_alive实现精细控制。
例如使用 check 模块后，可添加：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
check interval=3 rise=2 fall=5 timeout=1 type=http;
check_http_send "HEAD /health HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
验证与日常可观测性建议
无论采用哪种方式，上线后务必验证效果：
- 手动停掉一台后端，观察
curl -I http://your-nginx是否自动切到另一台，且nginx -T | grep upstream不显示异常节点被跳过； - 查看 Nginx 错误日志（
error_log），搜索no live upstreams或connect failed，确认降级行为符合预期； - 在生产环境部署简单监控：用脚本定期调用
stub_status或解析upstream_zabbix类模块暴露的指标，跟踪各 server 的fails和unavailable状态。
