nginx不能直接根据响应状态码调度流量，但可通过proxy_next_upstream按5xx等状态码重试、健康检查剔除异常节点、map动态切换upstream、日志联动外部系统调整权重等方式间接实现。
在 Nginx 中，不能直接通过响应状态码“调度”流量——状态码是服务处理完请求后返回的结果，不是路由决策的输入条件。但可以利用状态码作为反馈信号，结合健康检查、重试机制或上游服务标记，间接实现基于状态码的流量分发或故障转移。
利用 upstream 健康检查 + 状态码反馈
Nginx 自带的 health_check（需 stream 或 http 模块启用）或第三方模块（如 nginx-plus 的主动健康检查）可定期探测上游服务，依据返回的状态码判断节点可用性：
- 若某台后端连续返回
5xx，Nginx 可将其从可用列表中临时剔除 - 配置示例中可通过
match定义成功条件，例如只把200视为健康响应 - 普通开源版 Nginx 需配合
proxy_next_upstream在出现特定状态码时自动重试其他节点
proxy_next_upstream：按状态码触发重试与切换
这是最常用且无需额外模块的方式。当当前 upstream server 返回指定状态码时，Nginx 会尝试下一个 server：
proxy_next_upstream error timeout http_500 http_502 http_503 http_504;- 注意：
http_500等仅对 proxy_pass 返回的状态码生效，不适用于 upstream 主动返回的非错误码（如业务返回的404或429） - 若希望对业务自定义状态码（如
429）也触发重试，需搭配proxy_intercept_errors on和自定义 error_page，再用 rewrite 或 internal 重定向到备用 location
用 map + return 实现状态码驱动的逻辑跳转
虽然不能“根据响应码调度”，但可在请求发出前，基于客户端特征（如 header、参数）预判可能路径；而真正想响应不同状态码时，可通过 map 提前映射策略：
- 例如将请求头中的
X-Traffic-Strategy: fallback映射为备用 upstream 名称 - 再配合
proxy_pass http://$upstream_name实现动态 upstream 切换 - 若后端已返回某个状态码（比如日志中发现大量 429），可人工调整 map 规则或 upstream 权重，实现“事后调度”
结合日志与外部系统做闭环调度
单纯靠 Nginx 难以实时感知并响应状态码分布变化，但可通过日志分析形成调度依据：
- 配置
log_format记录$status和$upstream_addr - 用 ELK / Prometheus + Grafana 监控各 upstream 的失败率
- 当某节点 5xx 超过阈值，调用 Nginx API（需启用
ngx_http_api_module）或 reload 配置，降低其权重甚至摘除
不复杂但容易忽略：状态码本身是结果，调度的关键在于提前定义规则、设置重试边界、并打通可观测性链路。真正可靠的流量调度，从来不是单靠一个字段决定，而是状态码 + 健康信号 + 业务语义的组合判断。
