状态码本身不限额也不直接提供容错能力，关键在于基于其语义，结合Nginx的proxy_next_upstream、upstream分组与error_page机制实施差异化错误策略：503/504可重试，500需谨慎，400/404禁止重试；通过显式配置http_503等触发重试，并利用error_page实现状态码转换、降级与缓存兜底。
状态码本身不“限额”，也不能直接“平配”容错能力；真正起作用的是你如何基于状态码语义，结合 Nginx 的 proxy_next_upstream、upstream 分组与 error_page 机制，对不同后端节点施加差异化的错误响应策略。核心不是给状态码设限，而是按错误性质分类决策：哪些该重试、重试到哪、失败后怎么兜底。
区分可重试与不可重试错误类型
5xx 错误不能一概而论：
- 适合重试的临时性错误：503（服务不可用）、504（网关超时）——通常因瞬时过载或网络抖动引起，换节点成功率高
- 慎用重试的内部错误：500（服务器内部错误）——可能是代码崩溃、DB 连接池满等，仅当确认是瞬时资源争用且多活部署下其他节点健康时才启用
- 禁止重试的确定性错误：404（资源不存在）、400（参数错误）——问题在客户端，重试只会放大无效请求
用 proxy_next_upstream 精准控制重试触发条件
默认只响应 error timeout，必须显式声明 HTTP 状态码才能触发重试：
- 最小安全集：
proxy_next_upstream error timeout http_503 http_504; - 若需支持 500 重试，确保后端具备多活能力，并加上：
http_500; - 避免写
http_404，除非你有镜像源或静态 fallback 页面 - 注意：只有配置了对应状态码，Nginx 才会把该错误计入
max_fails并影响节点健康判定
通过 upstream 分组 + error_page 实现按状态分流
单一 upstream 无法表达“503 走备用组，500 走降级页”的意图，需配合命名 location：
- 定义主组：
upstream origin_primary { server a:8080 max_fails=2 fail_timeout=30s; } - 定义专用于 5xx 的备用组：
upstream origin_backup_5xx { server b:8080 backup; } - 在 location 中拦截并跳转：
error_page 503 504 = @retry_5xx;<br> location @retry_5xx { proxy_pass http://origin_backup_5xx; }
用 error_page 实现语义转换与柔性兜底
原始错误状态码未必适合暴露给客户端，可通过 error_page 转换或返回缓存：
- 将上游 500 统一转为更准确的 503：
error_page 500 =503 @handle_500;<br> location @handle_500 { default_type application/json; return 503 '{"code":"SERVICE_UNAVAILABLE"}'; } - 对关键路径的 503，启用陈旧缓存：
error_page 503 = @stale_fallback;<br> location @stale_fallback { proxy_cache_use_stale error timeout updating; proxy_pass http://origin_primary; }
