nginx应用层平滑降级通过proxy_next_upstream、fallback location和map指令实现请求级自动切换至备用响应路径，支持静态页、缓存、只读接口等兜底策略，并具备灰度控制、熔断探测与可观测性。
Nginx 实现应用层平滑降级，核心是让后端服务异常时，不直接返回 5xx 错误，而是自动切换到备用响应路径——比如静态兜底页、缓存内容、轻量级降级接口或只读服务。这不同于单纯踢掉故障节点（那是故障转移），而是面向用户感知的“有响应、不报错、可接受”的柔性容灾。
用 proxy_next_upstream + 备用 upstream 实现请求级降级
当主服务返回特定错误码或超时时，Nginx 可将同一请求转发给另一个定义好的 upstream，实现“失败即降级”：
- 在 http 块中定义两个 upstream：一个主服务组，一个降级服务组（如只读 API 或 Nginx 内置 stub）
- 在 location 中启用重试，并明确指定哪些响应应触发降级：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504; - 使用变量动态选择 upstream：
set $backend "main";
if ($upstream_http_x_degraded = "1") { set $backend "fallback"; }
proxy_pass http://$backend;（需配合后端返回 header 控制）
配置 fallback location 返回本地兜底内容
当所有后端都不可用，或你希望彻底绕过后端时，可用 try_files + named location 实现零依赖降级：
- 在 proxy_pass 后添加 proxy_intercept_errors on;，开启错误页面捕获
- 用 error_page 500 502 503 504 = @fallback; 将错误导向命名 location
- 在 @fallback 中返回预置 HTML、JSON 或重定向：
location @fallback {
types { application/json json; }
add_header Content-Type "application/json";
return 200 '{"code":2001,"msg":"服务暂时不可用，已启用降级模式"}';
}
基于请求特征做灰度降级与自动熔断
不是所有用户都该被降级，可通过 map 指令按流量维度精细化控制：
- 按用户标识决定是否启用降级：
map $cookie_user_id $should_degrade {
~^U[0-9]{8} "0"; # VIP 用户不降级
default "1";
} - 结合状态码与响应头判断后端健康度：
proxy_hide_header X-Backend-Status;
proxy_set_header X-Request-Mode $should_degrade;
后端据此跳过耗时逻辑，快速返回简化结果 - 用第三方模块（如 nginx_upstream_check_module）探测后端延迟，当 avg_response_time > 800ms 时，自动将该 server 标为 “slow”，仅用于降级流量
降级生效必须可观测、可验证
平滑降级的价值在于“用户无感”，但运维必须能确认它真实生效：
- 在 access.log 中添加自定义字段记录是否走降级：
log_format degrade '$time_local $uri $status $upstream_addr $request_length → $upstream_http_x_degraded'; - 对降级响应统一打标：
add_header X-Response-Mode "degraded" always;
前端或监控系统可据此统计降级率 - 压测时注入故障（如 kill -9 主服务进程），观察日志中是否出现连续 @fallback 记录，且响应时间稳定在 20–50ms 内，无 5xx 上升
