nginx 默认不重试5xx错误，需显式配置proxy_next_upstream并指定http_500/http_502等状态码；重试受tries、timeout、节点健康状态及请求幂等性多重限制，非幂等post应慎用或禁用重试。

Nginx 默认不重试 5xx 错误，也不自动切到其他后端——必须显式配置 proxy_next_upstream 才能触发错误重试，且重试行为受超时、健康状态、HTTP 方法等多重限制。

proxy_next_upstream 必须显式列出错误类型才生效

默认值 proxy_next_upstream error timeout 只覆盖连接失败和超时，http_502、http_503 这类响应码不会触发重试，哪怕后端返回了完整的 502 响应体。

• 常见错误现象：后端挂了返回 502 Bad Gateway，Nginx 直接返回给客户端，没切下一个 upstream
• 正确写法（写在 location 或 upstream 块内）：proxy_next_upstream error timeout http_500 http_502 http_503 http_504;
• 慎加 http_404：业务路径不存在是确定性结果，重试只会放大负载；慎加 non_idempotent：对 POST 请求启用会导致重复提交（如下单、发短信）
• 别写 proxy_next_upstream on：该值已废弃，Nginx 1.21+ 会报配置警告

重试次数和总耗时要分清：tries 和 timeout 不是单次限制

proxy_next_upstream_tries 是整个重试过程最多尝试几次（含首次），proxy_next_upstream_timeout 是从第一次请求发起开始计时的总窗口，超时即终止，不是单次超时。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 典型搭配：proxy_next_upstream_tries 3; + proxy_next_upstream_timeout 30s; + proxy_read_timeout 10s;
• 如果 proxy_read_timeout 设为 15s，而 proxy_next_upstream_timeout 只设 10s，那第二次重试根本发不出去
• 不要设过大：proxy_next_upstream_timeout 60s 容易把长尾延迟暴露给用户，建议 ≤ 2×proxy_read_timeout

upstream 节点健康状态决定“谁可被重试”

重试不是无脑轮询所有节点——Nginx 开源版靠被动失败学习节点可用性，max_fails 和 fail_timeout 控制节点是否进入候选池。

• 节点被标记不可用后，就不会出现在本次重试的候选列表里，哪怕你配了 proxy_next_upstream
• 推荐起点：server 192.168.1.10:8080 max_fails=2 fail_timeout=30s;
• fail_timeout 应 ≥ 2×proxy_read_timeout：防止后端偶发 GC 或抖动被立即摘除
• 务必配 backup 节点：server 192.168.1.13:8080 backup;，只有当所有主节点都被标记为不可用时才启用

POST 等非幂等请求重试风险极高，多数场景应关闭

对已发出 body 的 POST 请求开启重试，等于让后端处理两次——数据库双写、消息重复投递、支付重复扣款都可能由此引发。

• 安全写法：proxy_next_upstream error invalid_header http_500 http_502 http_503 http_504;（去掉 timeout）
• 更彻底做法：proxy_next_upstream off;，适合已知会长耗时或非幂等的接口（如订单创建）
• 日志里查 upstream_status 字段（需在 log_format 中显式添加），确认是否真发生了重试及切换路径

真正容易被忽略的是：重试只在响应未发回客户端前生效。一旦 Nginx 已开始向客户端写响应体（哪怕只是 HTTP 头），proxy_next_upstream 就完全失效——此时再出错，只能靠 error_page + proxy_cache_use_stale 做降级，而不是重试。