Nginx高可用依赖upstream块配合健康检查与负载均衡策略，proxy_pass仅作转发指令；正确写法是proxy_pass http://my_backend，指向upstream名称，而非具体地址，并需配置max_fails、fail_timeout、proxy_next_upstream等参数及超时、重试、Header透传等配套项。
proxy_pass 本身不直接实现高可用切换，它只是请求转发指令；真正的后端高可用依赖 upstream 块配合健康检查与负载均衡策略，proxy_pass 再指向该 upstream 名称即可。
用 upstream 定义可切换的后端组
高可用不是靠单个 proxy_pass 实现的，而是把多个后端服务注册进一个 upstream 组，让 Nginx 能自动识别、剔除异常节点，并在剩余节点间分发请求。
- 定义 upstream 时使用 health_check（需启用 stream 或 http 模块的 health check 功能，或搭配第三方模块如 nginx-plus、nginx-module-vts）
- 或使用 max_fails 和 fail_timeout 让 Nginx 主动标记失效节点：例如
server backend1:8080 max_fails=3 fail_timeout=30s; - 支持多种调度算法：轮询（默认）、
ip_hash（会话保持）、least_conn（最少连接）、hash $remote_addr（客户端 IP 哈希）
proxy_pass 必须指向 upstream 名称，而非具体地址
一旦 upstream 配置完成，proxy_pass 就不再写死 IP 或域名，而是引用 upstream 名——这样所有转发逻辑（包括失败重试、权重调整、自动剔除）才真正生效。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 正确写法：
proxy_pass http://my_backend;，其中my_backend是 upstream 块名 - 错误写法：
proxy_pass http://backend1:8080;—— 这绕过了 upstream，等于放弃高可用能力 - 若需 fallback 到备用集群，可用
proxy_next_upstream error timeout http_500;触发重试，并配合多个 upstream + if 判断（需谨慎，推荐用 mirror 或 split_clients 更稳妥）
关键配套配置不能少
仅靠 upstream + proxy_pass 不足以保障高可用，还需补充以下几项：
-
超时控制：设置
proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout，避免卡死阻塞后续请求 -
重试机制：启用
proxy_next_upstream并明确触发条件（如error timeout http_502 http_503），让失败请求自动转给其他节点 -
真实 IP 透传：必须加
proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For，否则后端无法准确判断来源，影响日志与限流 -
协议与 Host 保持：
proxy_set_header Host $host;和X-Forwarded-Proto $scheme;确保后端生成的跳转链接、鉴权逻辑不出错
验证是否真正生效
高可用不是配完就自动运行的，需主动验证：
- 手动停掉某台后端服务，观察访问是否持续成功、响应时间是否平稳上升而非陡增或报错
- 查 Nginx 错误日志：
tail -f /var/log/nginx/error.log，确认是否有upstream timed out或no live upstreams类提示 - 用
curl -I检查响应头中Server字段是否来自不同后端，确认流量确实在轮转 - 若启用了状态页（如 stub_status 或 vts 模块），可实时查看各 upstream 成员的请求计数与失败次数
