后端偶尔超时，客户端却拿到了200；另一次返回504，日志里又只有一个后端地址。要解释这两种结果，先看Nginx有没有机会切到下一台服务器，以及请求是否已经发给了原来的上游。
先弄清哪些错误会切换上游
默认的proxy_next_upstream error timeout;涵盖建立上游连接、发送请求、读取响应头时发生的相关错误和超时。上游自己返回的HTTP 500、502或503要按状态单独配置。客户端看到502，不代表上游发回了一个HTTP 502响应。连接被拒绝也可能由Nginx生成502。
切换的前提是Nginx还没向客户端发送响应。响应开始传输后上游中途断开，代理不能换一台机器把已发送的半段响应重来一遍。
用三项配置约束只读入口
在专门承载只读请求的location内可从proxy_next_upstream error timeout http_502 http_503;、proxy_next_upstream_tries 2;和proxy_next_upstream_timeout 3s;入手，前提是上游组确有备用节点。2表示包含首次请求在内的尝试上限，还有没有可用节点会影响实际次数。
3秒限制切换上游的时间窗口，不能拿来当整个请求的总时限。proxy_read_timeout限制相邻两次读取之间的空闲时间；连接、发送、读取超时应各自结合业务延迟预算配置。
写入接口要先考虑幂等
POST、LOCK和PATCH已发给一个上游后，默认不会切到下一台；显式启用non_idempotent会放宽这道保护。上游可能已写入数据库，只是没来得及返回响应。仅靠客户端收到超时无法判定写入失败。
订单、回调等入口应先有可靠的幂等键和服务端去重。需要禁止Nginx在该入口切换时可用proxy_next_upstream off;。同时检查客户端或外层网关是否也在重试。
从日志区分一次请求和多次尝试
在访问日志临时加入$request_id $upstream_addr $upstream_status $upstream_connect_time $upstream_header_time $upstream_response_time，对照错误日志与应用端同一请求ID。多值记录按位置比对，区分首次失败、备用节点接手与最终对外状态。
先跑sudo nginx -t，确认通过再用发行版对应方式平滑重载。验收时既要看只读请求能切换，也要看写接口的业务记录未重复。可在萤光云或LightNode的隔离实例模拟后端超时。
上线后怎么判断设置有效
预发环境分别模拟拒绝连接、返回503、发出响应后断流，记录每种情况的上游尝试次数与最终状态。上线先观察错误率和尾部延迟；若备用节点负载陡增，回滚本次重试配置并检查主节点健康。
FAQ
只有一个上游也能切换吗？ 没有可用候选时无法切到另一台。
tries设为0等于关闭吗？ 0取消该指令的次数上限；关闭切换用off。
404该加进去吗？ 业务资源不存在时通常没有切换价值，先弄清状态来源。
延长读取超时能解决断流吗？ 只能影响读操作间的空闲等待，不能弥补已发送的响应。
关闭请求缓冲会怎样？ Nginx开始把请求体发给上游后，不能再把该请求交给下一台。
温馨提示
保留变更前配置和一组失败请求ID。每次只调整一类超时或切换条件，方便把延迟变化和具体设置对应起来。
