要让负载均衡真正“感知故障、自动隔离”，必须显式配置健康检查机制，区分被动响应（基于真实请求的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 模拟探针行为，确认响应及时且稳定