proxy_pass本身不负责健康检查，它仅转发请求到upstream；健康检查需在upstream块中配置health_check指令（nginx 1.19+）或通过max_fails/fail_timeout实现被动检查，且/health探测路径由nginx主动发起而非proxy_pass指定。
proxy_pass 本身不负责健康检查，它只是把请求转发到上游服务器组（upstream），真正的健康检查由 upstream 块内的配置或 location 中的 health_check 指令控制。所以“用 proxy_pass 配置健康检查地址”这个说法不准确——你需要的是：在 upstream 中定义后端地址，并配合健康检查机制，让 Nginx 主动探测这些地址是否可用。
下面分两类常见场景说明怎么做：
✅ 使用 Nginx 官方主动健康检查（Nginx Plus 或开源版 1.19+ with http_upstream_module + health_check）
这是最标准、无需编译第三方模块的方式（注意：开源版 Nginx 从 1.19.0 起才原生支持 health_check 指令；低于该版本需用 nginx_upstream_check_module）。
http {
# 定义上游服务器组
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
# 启用主动健康检查
health_check
interval=5s # 每5秒探一次
fails=3 # 连续3次失败标记为不健康
passes=2 # 连续2次成功恢复为健康
timeout=1s # 单次探测超时1秒
uri=/health # 探测路径（后端必须返回 2xx/3xx）
match=health_ok; # 可选：自定义匹配规则
}
# 定义匹配规则（可选，更精细控制）
match health_ok {
status 200;
header Content-Type = "application/json";
body ~ ".*\"status\":\"up\".*";
}
server {
listen 80;
location / {
proxy_pass http://backend; # ← 这里指向 upstream 名称，不是具体地址
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
⚠️ 注意：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_pass http://backend中的backend是 upstream 名字，不是 URL； - 健康检查的
/health地址是发给每个server的（比如http://192.168.1.10:8080/health），不需要也不应该写在proxy_pass里； - 后端服务必须真实提供
/health接口，返回合法 HTTP 状态码（默认只认 2xx–3xx）和可选的内容校验。
✅ 使用被动健康检查（所有 Nginx 版本都支持，无需额外模块）
适用于没有主动探测能力的环境，靠实际业务请求反馈判断：
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 {
location / {
proxy_pass http://backend;
proxy_connect_timeout 3s;
proxy_send_timeout 5s;
proxy_read_timeout 5s;
# 出现错误或超时，自动转给下一个后端
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
}
}
✅ 效果：
- 第一次请求打到某台后端，若连接失败、超时或收到 5xx，Nginx 就记一次失败；
- 达到
max_fails次后，在fail_timeout时间内不再将新请求发给它； - 不会主动发
/health，但对业务无侵入，适合快速上线。
❌ 常见误区纠正
-
proxy_pass http://192.168.1.10:8080/health—— 这只是把所有用户请求都强行转发到/health，不是健康检查，而是破坏了业务逻辑； - 在
proxy_pass后面加参数或 query 来“模拟检查” —— Nginx 不解析也不执行，纯属无效配置； - 以为
proxy_next_upstream开启就等于有主动探测 —— 它只是出错后重试，不提前规避故障节点。
不复杂但容易忽略：健康检查生效的前提是，你得让 Nginx 知道该去哪探、怎么判、多久探一次——这些全在 upstream 或 location 里配，跟 proxy_pass 的值无关。
