nginx 不直接支持按后端状态码动态调整负载均衡策略，但可通过健康检查、proxy_next_upstream、map 分流、openresty 动态权重及外部网关等组合方案间接实现。
nginx 本身不直接支持“根据后端返回的状态码动态调整负载均衡策略”，但可以通过组合使用 健康检查、状态码映射 和 upstream 动态分组 等机制，间接实现类似效果。核心思路是：让 nginx 感知后端异常（如大量 5xx），自动降权或剔除故障节点，再配合重试与 fallback，达到“按状态码响应调度”的目的。
利用 upstream 健康检查识别异常节点
nginx 的商业版（NGINX Plus）原生支持基于 HTTP 状态码的主动健康检查，开源版则需借助 ngx_http_upstream_check_module（第三方模块）或通过 proxy_next_upstream 配合被动健康检查模拟。
- 启用被动健康检查：在
upstream块中配置proxy_next_upstream error timeout http_500 http_502 http_503 http_504;，当后端返回这些状态码时，nginx 自动转发请求到下一个服务器 - 设置失败计数与超时：
max_fails=3 fail_timeout=30s，连续 3 次失败（含 5xx）则该节点被标记为不可用 30 秒 - 注意：仅靠 passive 检查无法“实时感知”服务降级（如大量 200 但业务逻辑失败），需结合应用层埋点或自定义监控
用 map + split_clients 实现状态码导向的流量分流
若需更精细控制（例如：将所有 429 请求导流至限流处理集群），可在 proxy_pass 前用 map 提取响应状态码，并结合变量选择不同 upstream。
- 先在 http 块中定义状态码映射：
map $upstream_status $backend_group { ~^[5] $upstream_critical; ~^[4] $upstream_slow; default $upstream_normal; } - 声明多个 upstream 分组（normal / slow / critical），各自配置不同权重或节点
- 在 location 中用
proxy_pass http://$backend_group;实现动态路由 —— 注意此方式依赖$upstream_status，需开启proxy_intercept_errors off并确保错误页未覆盖原始状态码
结合 lua-resty-upstream-healthcheck 做动态权重调整
使用 OpenResty 可以更灵活地实现“根据历史 5xx 比率动态降低节点权重”。例如：
- 周期性采集每个 upstream server 的最近 100 次响应状态码
- 若某节点 5xx 占比 >20%，调用
healthcheck.set_weight()将其权重设为 1（默认 100） - 恢复逻辑：持续 5 分钟无 5xx，则权重逐步回升
- 需注意 lua 共享字典存储状态，避免 worker 间数据不一致
替代方案：前置网关统一处理状态码逻辑
真正复杂的“状态码驱动调度”更适合由专用网关（如 Kong、Traefik）或 service mesh（Istio）承担。nginx 更适合作为轻量级反向代理，把状态码感知和决策逻辑下沉到上游服务或独立监控系统。
- 例如：应用在 header 中返回
X-Backend-Quality: poor，nginx 用map $upstream_http_x_backend_quality $route {...}路由 - 或通过 Prometheus + Alertmanager 触发脚本更新 nginx upstream 配置并 reload（适合低频变更场景）
- 避免在 nginx 中做复杂状态判断，否则影响吞吐与可维护性
不复杂但容易忽略：状态码调度本质是服务治理问题，nginx 是执行层，关键在可观测性建设与闭环反馈机制。
