要全面拦截并容错后端5xx错误，需精准区分可重试（502/503/504）与慎用重试（500）场景，禁用403/404重试；配置proxy_next_upstream error timeout http_502 http_503 http_504、tries和timeout限流；启用upstream健康检查；结合proxy_read_timeout实现“慢即错”；仅对幂等请求（GET/HEAD）启用重试。
要让 proxy_next_upstream 真正“全面拦截并容错后端 5xx 报错”，不能只写 http_500 http_502 http_503 http_504 就完事。关键在于：精准识别哪些 5xx 属于可重试场景、哪些必须快速失败，再搭配超时控制、健康检查和幂等保障，才能既提升可用性，又不掩盖真实故障。
只对真正可重试的 5xx 开启重试
不是所有 5xx 都适合重试：
- 502 / 504：网关层问题（后端崩溃、连接中断、超时），典型瞬时故障，必须重试
- 503：服务过载或主动熔断，若多活部署且负载不均，重试常能落到健康节点
- 500：谨慎加入——仅当确认是局部异常（如某节点缓存损坏、临时依赖抖动），而非全局业务错误（如 DB 死锁、空指针）
- 避免 http_404 / http_403：这是确定性业务结果，重试只会放大无效流量
基础配置必须显式声明并设限
以下配置应放在 location 或 server 块中，作用于具体 proxy_pass 路由：
WebChat Voice Proxy
下载
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
-
proxy_next_upstream error timeout http_502 http_503 http_504;—— 明确覆盖连接失败、读头超时、以及三类典型网关级错误 -
proxy_next_upstream_tries 3;—— 最多重试 2 次（共最多 3 个节点），防雪崩 -
proxy_next_upstream_timeout 10s;—— 从首次请求发出起计时，超时即返回最终错误，不卡住客户端
upstream 必须启用被动健康检查
否则每次请求仍会轮询到已宕机节点，白白触发重试。在 upstream 块中为每个节点加上：
-
max_fails=3 fail_timeout=30s;—— 连续 3 次失败（含 502/503/504/timeout/error）后，该节点被摘除 30 秒 - 至少两个主节点，避免单点；可选加
backup节点作兜底
配合 proxy_read_timeout 实现“慢即错”逻辑
很多“504”实际是后端自己返回的，但有些慢响应根本没返回状态码，靠 proxy_read_timeout 主动截断更可靠：
-
proxy_read_timeout 8s;—— 等响应头超时即判定为timeout，触发重试 - 该值需略大于后端 P95 处理时长，但不能过大（建议 6–12s），否则拖累整体延迟
- 与
proxy_next_upstream error timeout http_504组合，覆盖“Nginx 自身超时”和“后端自报 504”两类慢场景
非幂等请求需额外防护
GET/HEAD 默认安全可重试；但 POST/PUT 等写操作重试极危险：
- 生产环境强烈建议：仅对
GET和HEAD启用 5xx 重试 - 若必须支持写操作重试，后端必须实现幂等（如通过
Idempotency-Key去重） - Nginx 1.9.13+ 可加
non_idempotent参数启用非幂等重试，但不推荐作为默认策略
