多层代理全局故障转移需逐层配置容错：第一层入口Nginx基于5xx/error/timeout重试；第二层中间Nginx需双重健康检查与合理超时；第三层通过backup+权重实现灾备降级，并规避超时不收敛、状态码拦截等常见陷阱。
多层代理架构下的全局故障转移，不是靠某一层单独配置就能实现的，而是需要每一层都明确承担自己的容错职责，并在请求链路中逐级传递失败信号。Nginx 本身不支持跨层自动感知下游故障，必须通过参数显式串联各层的重试与剔除逻辑。
第一层：入口 Nginx（面向客户端）需启用请求级重试
这一层不直接探活后端 Nginx 实例，而是对“连接失败、超时、5xx 网关错误”做出反应。关键在于它要信任下一层返回的状态码，并据此触发重试：
-
proxy_next_upstream 必须包含
error timeout http_502 http_503 http_504—— 因为下层 Nginx 若自身后端全挂，通常会返回 502/503；若自己宕机或网络不通，则触发 error/timeout - proxy_next_upstream_tries 建议设为 3～5，覆盖所有可用的中间层节点（如 3 台边缘 Nginx）
- proxy_next_upstream_timeout 设为略大于单次完整请求预期耗时（例如 15s），防止重试拖长整体延迟
- upstream 中每个 server 都应配
max_fails=2 fail_timeout=20s，避免反复试探已失联的中间节点
第二层：中间 Nginx（反向代理到应用集群）需双重容错
这一层既要处理自身与上游的连接问题，也要处理与下游业务服务的通信异常。它既是客户端，也是服务端，因此配置更复杂：
- upstream 指向真实后端（如 Tomcat、Node.js 集群）时，每个 server 行必须带
max_fails=3 fail_timeout=30s，并可加backup应急节点 - location 块中开启
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，确保单次请求失败能换后端重试 - 务必设置
proxy_connect_timeout 5s和proxy_read_timeout 10s，否则默认 60s 会拖慢上层重试节奏 - 若使用 Nginx Plus 或 OpenResty，建议启用主动健康检查（
health_check interval=5 fails=2 passes=2），比被动容错更及时
第三层：全局协调靠 backup + 权重降级策略
当多层都出现局部故障时，仅靠自动重试容易导致雪崩。需引入人工可控的降级路径：
- 在最外层 upstream 中，把灾备集群（如异地机房或容器化备用环境）定义为
server 10.20.30.40:80 backup weight=1，确保只在主链路全部失效时才启用 - 中间层可配置不同 region 的 upstream 分组，用 map 或 if 判断来源地域，优先走就近后端；故障时 fallback 到另一组
- 不推荐用 rewrite 或 return 302 做全局跳转——这会暴露内部结构且破坏客户端连接复用，应始终在 proxy_pass 链路内完成转移
注意事项：避免常见陷阱
多层代理下故障转移容易失效，往往因为以下配置被忽略：
- 超时值未逐层收敛：外层 timeout > 内层 timeout + retry 开销 → 导致外层还没超时，内层已重试多次并返回 504，外层却不再重试
-
HTTP 状态码未透传：中间层若用了
proxy_intercept_errors on并自定义了 error_page，可能把 502 拦截成 200，导致外层无法识别故障 -
keepalive 连接复用干扰健康状态：长连接池中的失效连接不会被立即清理，建议配合
proxy_http_version 1.1和proxy_set_header Connection ''控制复用行为 -
日志缺失定位难：在每层 location 加
log_format detailed '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $upstream_addr $upstream_status $request_time $upstream_response_time';，便于追踪哪一层开始失败
