Nginx默认轮询不自动剔除返回500的后端节点，仅连接失败或配置max_fails/fail_timeout时标记不可用；需启用主动健康检查（Nginx Plus内置health_check或开源版+nginx_upstream_check_module）或配合proxy_next_upstream重试机制实现容错。
Nginx 本身在默认的 upstream 轮询中**不会自动剔除返回 500 的后端节点**，它只在连接失败（如超时、拒绝连接）或配置了 max_fails/fail_timeout 且发生“健康检查失败”时才临时标记节点为不可用。而 HTTP 状态码 500 属于应用层响应，Nginx 默认不将其视为“失败”，除非你显式启用并配置了主动健康检查（health_check）或使用第三方模块（如 nginx_upstream_check_module）。
启用主动健康检查（推荐，需 Nginx Plus 或开源版 + 模块）
如果你使用的是 Nginx Plus，可直接利用其内置的 health_check 指令，支持基于 HTTP 状态码判断节点健康状态：
- 在
upstream块中添加health_check，并指定match规则匹配 2xx/3xx 响应；未匹配即视为失败 - 示例配置：
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
health_check interval=5 fails=3 passes=2 match=good_status;
}
<p>match good_status {
status 200-399; # 只有返回 2xx 或 3xx 才算健康
}
这样，当某节点持续返回 500 时，健康检查会将其标记为 unhealthy，Nginx Plus 将暂停向其转发请求，直到恢复健康。
开源 Nginx：使用第三方健康检查模块
社区常用的是 nginx_upstream_check_module（需重新编译 Nginx）：
- 该模块支持 TCP/HTTP 检查，并可自定义
rise（成功次数）和fall（失败次数） - 配置示例（HTTP 检查）：
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; # 仅 2xx/3xx 视为存活
}
注意：/health 接口需由后端提供，稳定返回 200；若后端无健康接口，可改用 type=tcp 做连通性检查，但无法感知 500 状态。
绕过方案：后端配合返回特定响应 + Nginx 重试逻辑
若无法启用健康检查，可结合 proxy_next_upstream 实现“遇到 500 就换节点”：
- 设置
proxy_next_upstream error timeout http_500; - 配合
proxy_next_upstream_tries和proxy_next_upstream_timeout控制重试行为 - 注意：这不等于“剔除节点”，而是每次 500 都尝试下一个，对单次请求有效，但故障节点仍参与轮询
location / {
proxy_pass http://backend;
proxy_next_upstream error timeout http_500;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
}
该方式适合临时容错，不能长期隔离问题节点，需搭配监控告警人工干预。
补充建议：日志 + 监控驱动人工/自动下线
通过 Nginx 日志识别高频 500 的后端 IP：
- 在
log_format中加入$upstream_addr和$upstream_status - 用脚本（如 awk + curl）定期分析日志，发现某节点 500 率超标时，调用运维 API 或修改 upstream 配置（reload）临时摘除
- 适用于灰度发布、突发流量等场景下的快速止损
