nginx 无法直接自动降级接口，但可通过 error_page 拦截 500/502/503/504 状态码转向 @fallback（返回静态响应或 proxy_pass 到备用服务），结合 upstream 健康检查与 backup 服务器实现被动降级，或用 openresty 的 lua 脚本进行动态决策。
在 Nginx 中无法直接“自动降级”接口（如将失败请求转发到备用服务），但可以通过 状态码匹配 + 重定向/代理切换 + 健康检查 组合实现近似效果。核心思路是：当上游返回特定错误状态码（如 500、502、503、504）时，Nginx 主动拦截并转向降级响应或备用后端。
用 error_page 拦截并重定向到降级逻辑
这是最常用且轻量的方式。Nginx 可捕获 upstream 返回的指定状态码，并触发本地处理：
- 在 location 块中配置
error_page 500 502 503 504 = @fallback - 定义
@fallback内部 location，可返回静态 JSON（如{"code":200,"msg":"服务降级中","data":[]}），或 proxy_pass 到备用服务 - 注意加
=符号才能保持原始状态码；不加则默认返回 302 或 200
结合 upstream 健康检查实现被动降级
仅靠 error_page 是“事后响应”，若需更早规避故障节点，应配合 upstream 的主动探测：
- 使用
health_check（商业版 NGINX Plus）或开源版nginx_upstream_check_module插件 - 配置
max_fails=1 fail_timeout=10s，让 Nginx 自动剔除连续失败的节点 - 搭配
backup标记的服务器，流量会自动切到 backup 节点 —— 这才是真正的“自动降级”
用 Lua 脚本实现动态决策（OpenResty）
若需根据状态码 + 响应体内容 + 请求频率等复杂条件降级，推荐 OpenResty：
- 在
access_by_lua_block或body_filter_by_lua_block中读取ngx.status - 若 upstream 返回 503 且响应体含 “overload”，可立即 rewrite 到 /degraded 接口
- 配合 shared_dict 缓存降级开关，支持人工一键开启/关闭降级模式
注意事项与常见陷阱
这类方案容易忽略的关键细节：
-
error_page不捕获 3xx/4xx（除非显式列出），且不会触发日志中的 upstream_addr 记录 - proxy_next_upstream 默认只重试 502/503/504，需显式添加
http_500才能对 500 重试 - 降级响应务必设置明确的 Cache-Control（如
no-cache），避免 CDN 缓存错误内容 - 不要在降级路径中再调用原 upstream，否则可能形成循环
