要让负载均衡真正“感知故障、自动隔离”，必须显式配置健康检查机制，区分被动响应（基于真实请求的max_fails/fail_timeout和proxy_next_upstream）与主动探测（基于周期性HTTP探针的check指令），并按业务特征调优参数，最后通过停服、重启、curl探针等方式验证生效。
要让负载均衡真正“感知故障、自动隔离”，不能只靠默认轮询，必须显式配置健康检查机制。核心是区分“被动响应”和“主动探测”两类策略，并根据业务特征调优参数。
被动健康检查：用真实请求触发快速隔离
这是最基础、无需额外模块的方案，依赖每次代理请求的返回结果做判断：
- 在 upstream 块中为每个后端 server 显式设置 max_fails 和 fail_timeout，例如：
server 10.0.1.10:8080 max_fails=2 fail_timeout=5s; - 在 location 块中启用 proxy_next_upstream，明确哪些响应应触发重试，例如：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504; - 被标记为 down 的节点不会持续探测，而是等到下一次新请求来临时试探——成功则恢复，失败则继续隔离
主动健康检查：提前发现“假存活”节点
被动检查有滞后性，比如服务进程僵死但无请求打进来，就无法及时剔除。这时需要周期性心跳探测：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 使用 nginx_upstream_check_module（OpenResty 已内置；原生 Nginx 需编译加入）
- 在 upstream 块中添加 check 指令，例如：
check interval=3000 rise=2 fall=2 timeout=1000 type=http uri=/health; - 后端必须提供轻量、稳定、低耗时的健康接口（如
/health），返回 HTTP 200，响应时间建议控制在 200ms 内 - 避免用
/或耗时接口（如导出、上传入口）作为探针，否则可能放大故障或误判
按业务类型调整关键参数
一套参数不适合所有场景，需结合后端行为特征设定：
- 常规 Web 接口（如用户中心）：max_fails=3，fail_timeout=30s，平衡抖动过滤与响应速度
- 高 QPS 网关：max_fails=15，fail_timeout=10s，放宽失败次数，缩短统计窗口
- 慢操作服务（如报表导出）：max_fails=2，fail_timeout=60s，防止单次长耗时被误判为故障
- 关键链路（如支付回调）：max_fails=1，fail_timeout=10s，首次失败即隔离，保障强一致性
验证是否真正生效
配置完成后务必动手验证，不能仅看日志或状态页：
- 手动停掉一台后端服务，观察 Nginx error log 是否出现
upstream failed，并确认后续请求不再转发到该节点 - 重启该服务后，访问
/status（需配置check_status指令）查看其状态是否从 down 变回 up - 用
curl -v --connect-timeout 1 http://back-end-ip/health模拟探针行为，确认响应及时且稳定
