nginx被动健康检查依赖proxy_next_upstream、max_fails和fail_timeout三者协同：前者定义失败重试条件（如error/timeout/5xx），后两者在fail_timeout窗口内累计max_fails次失败后标记节点down并暂停调度30秒，新请求触发试探恢复。
Nginx 本身不提供主动探测后端健康状态的机制（如定期发心跳请求），但可以通过 proxy_next_upstream 配合超时、错误响应等条件，实现“被动健康检查”——即在请求失败时自动尝试下一个 upstream 节点，并结合 max_fails 和 fail_timeout 实现故障节点的临时剔除。
proxy_next_upstream 的作用与触发条件
该指令定义在请求转发到某个 upstream server 失败后，是否尝试重试其他节点。它不决定“是否健康”，而是决定“失败后要不要换人”。常见触发条件包括：
- error：与后端建立连接、发送请求或读取响应头时发生网络/系统级错误（如 Connection refused、Timeout）
-
timeout：连接、写入或读取超时（需配合
proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout） - http_500、http_502、http_503、http_504：收到这些状态码时也视为失败（注意：默认不包含 5xx，必须显式声明）
- invalid_header：后端返回空或非法响应头（如无 Status 行）
upstream 中配置故障剔除的关键参数
仅靠 proxy_next_upstream 不足以自动剔除节点，必须搭配 max_fails 和 fail_timeout 才能标记节点为“不可用”并暂停转发：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
max_fails=3：在
fail_timeout时间窗口内，连续失败 3 次，则标记该 server 为不可用 - fail_timeout=30s：时间窗口长度；同时它也是“不可用状态”的持续时间 —— 30 秒后自动恢复探测（下一次请求会尝试连接，成功则重新启用）
- 未设置
max_fails时默认为 1；未设置fail_timeout默认为 10 秒
示例 upstream 配置：
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 backup;
}
location 中启用重试逻辑
在 proxy_pass 所在 location 块中，明确启用需要的失败类型：
location / {proxy_pass http://backend;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
proxy_connect_timeout 5s;
proxy_send_timeout 10s;
proxy_read_timeout 10s;
}
- proxy_next_upstream_tries：最多重试几次（含首次），默认为 0（不重试），设为 3 表示最多试 3 个节点
- proxy_next_upstream_timeout：整个重试过程总耗时上限，超时后直接返回错误（如 502）
- 三个
proxy_*_timeout值共同影响单次请求的失败判定，进而触发proxy_next_upstream
注意事项与常见误区
- 该机制是“被动”的：节点只有在被选中且请求失败后才可能被标记为不可用，不会主动探测空闲节点
- 5xx 错误需显式列出，否则即使后端返回 503，也不会触发重试或计数
-
backup服务器只在所有非 backup 节点都不可用时才启用，适合做灾备节点 - 若后端短暂卡顿但未断连，可能返回 200 + 异常 body，此时
proxy_next_upstream不生效（因未命中任何触发条件），需结合业务层校验或使用 ngx_http_upstream_check_module（第三方模块）做主动健康检查
