优雅降级核心是“分层拦截+内部接管”，需将error_page置于对应location内、用internal命名location兜底、通过=控制状态码，且注意root路径、proxy_intercept_errors等细节。
Location 配置与 error_page 协同实现优雅降级，核心是“分层拦截 + 内部接管”，不跳转、不暴露错误、状态码可控。关键不在重定向，而在用命名 location 做安全、可预测的兜底出口。
明确 error_page 的作用范围和触发条件
error_page 必须写在它要生效的 location 块内，否则不触发。例如：
- 想对 API 请求做降级，就把
error_page 502 503 504 = @api_fallback;放在location /api/ { ... }里面 - 想对静态资源缺失做处理，就在
location ~ \.(js|css|png)$ { ... }中配try_files $uri =404;，再配error_page 404 = @static_fallback; - 不能把 error_page 写在 server 级别就指望它管所有子 location —— 它只对当前块内产生的错误响应起效
用命名 location（@xxx）统一承接降级逻辑
命名 location 是真正的“降级执行单元”，必须加 internal; 防止外部直接访问，同时配合 root 和 try_files 确保内容存在：
location @api_fallback { internal; root /usr/share/nginx/html; try_files /degrade/api-down.json =503; }location @static_fallback { internal; root /usr/share/nginx/html; index fallback.html; try_files /fallback/$uri.html /fallback/index.html =404; }- 不加
internal可能被恶意请求绕过主流程；不用try_files或index容易因路径错位返回 404
状态码控制：用等号（=）决定是否覆盖原始码
error_page 后面的 = 符号直接影响客户端看到的状态码，需按场景选择：
-
error_page 502 = @fallback;→ 返回 502，内容是降级页。适合运维监控识别故障，但前端可能报错 -
error_page 502 =200 @fallback;→ 强制返回 200，内容是降级页。适合 SPA 场景，避免 JS 加载中断或路由异常 -
error_page 404 =200 /fallback/;→ 搭配location /fallback/ { index index.html; }，自动返回/fallback/index.html且状态码为 200
避免常见陷阱：路径、权限与执行顺序
很多降级配置看似正确却无效，往往卡在这些细节：
-
root路径必须覆盖降级文件实际位置，比如root /var/www/app;，那/degrade/maint.html就得真实存在于/var/www/app/degrade/maint.html - 用
alias时注意末尾斜杠：如果写alias /var/www/app/degrade/;，则try_files /maint.html实际查的是/var/www/app/degrade/maint.html；若漏掉末尾/，路径会拼错 - 不要在同一个 location 里混用
return 404和error_page 404——return会立即终止流程，error_page不再有机会执行 - proxy_pass 场景下，必须配
proxy_intercept_errors on;，否则上游返回的 502/503 不会被捕获
