Nginx不支持网络层回退路由，其“回退策略”实为应用层故障转移：通过upstream配置backup节点、proxy_next_upstream定义重试条件（如error/timeout/5xx）、结合max_fails与fail_timeout实现被动健康检查，并可借助map/if按host、header或IP动态切换主备上游。
Nginx 本身不提供“回退路由”这种网络层路径切换能力，它不是路由器或 SD-WAN 设备。所谓“针对特定节点的回退路由策略”，在 Nginx 场景中实际指：当主上游服务（如某台后端节点）不可用时，自动将请求转发到备用节点（failover node），实现应用层的服务冗余与故障转移。
这类策略核心靠 upstream 模块 + 健康检查机制实现，而非传统路由协议中的 IGP/BGP 回退。以下是实用配置方式：
使用 upstream 的 failover 机制定义主备节点
在 http 块中定义带权重和状态控制的 upstream：
upstream backend_cluster {
server 192.168.1.10:8080 weight=5 max_fails=3 fail_timeout=30s;
server 192.168.1.11:8080 weight=1 backup; # 仅当主节点全失效时启用
}-
max_fails=3：连续 3 次失败（如超时、5xx）即标记为不可用 -
fail_timeout=30s：30 秒内不向该节点发请求 -
backup：该节点默认不参与负载，仅在其他非 backup 节点全部不可用时启用
注意：Nginx 开源版不支持主动健康检查（active health check），依赖被动探测（即请求失败触发）。若需主动探活（如定期 GET /health），需使用
nginx-plus或配合第三方模块（如nginx_upstream_check_module）。
按节点特征做条件式回退（如按地域/角色路由）
可通过变量+map+if 实现逻辑判断，例如：优先走本地机房节点，异常时切到异地灾备节点：
map $host $upstream_group {
default "prod_main";
~^api-staging\. example\.com$ "staging_backup";
}
upstream prod_main {
server 10.0.1.100:8000 max_fails=2 fail_timeout=20s;
server 10.0.2.100:8000 backup;
}
upstream staging_backup {
server 10.0.3.200:8000;
}
server {
location /api/ {
proxy_pass http://$upstream_group;
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
proxy_next_upstream_tries 3;
proxy_next_upstream_timeout 10s;
}
}-
proxy_next_upstream：定义哪些响应会让 Nginx 尝试下一个 upstream 节点 -
proxy_next_upstream_tries：最多重试几次（含首次） -
proxy_next_upstream_timeout：重试总耗时上限
结合 real_ip 和自定义 header 做节点级灰度回退
若某类客户端（如特定 CDN 回源、内部调用方）需固定走备用链路，可结合 if 判断 header/IP：
set $fallback_node "";
if ($http_x_forwarded_for ~ "203\.208\.60\.\d+") {
set $fallback_node "cdn_backup";
}
if ($remote_addr ~ "172\.16\.100\.\d+") {
set $fallback_node "internal_backup";
}
upstream cdn_backup { server 192.168.5.50:8080; }
upstream internal_backup { server 192.168.5.51:8080; }
location / {
proxy_pass http://$fallback_node;
proxy_pass http://default_backend;
}⚠️ 注意：if 在 location 中慎用，建议优先用 map 提前计算变量，避免嵌套逻辑出错。
不复杂但容易忽略
