nginx故障转移需proxy_next_upstream与tries/timeout、max_fails/fail_timeout、上游多节点及幂等性控制协同：显式配置error/timeout/502-504/invalid_header触发重试，禁用404/403/500；tries≤3且timeout≤10s；每个server设max_fails=3 fail_timeout=30s；仅get/head默认重试。
要让 Nginx 在后端失败时真正实现故障转移，proxy_next_upstream 不能单独使用，必须和重试限制、健康标记、上游定义协同配置。它本身只决定“什么时候换节点”，不控制“换几次”或“换到哪儿”，也不提前避开坏节点。
明确哪些失败才触发重试
默认只对 error（连接拒绝、TCP reset、DNS失败）和 timeout（连接或响应超时）重试。生产环境建议显式加上：
- http_502、http_503、http_504：网关类错误，说明后端服务已不可用或过载，适合重试
- invalid_header：后端返回空响应或缺失 Status 行，大概率是进程假死，应切换
- 避免加 http_404、http_403、http_500：前者是路径/权限逻辑结果，后者多为业务异常，重试无意义且增加负载
严格限制重试行为边界
不设限的重试会拖慢响应、放大故障。两个参数必须成对配置：
WeChat macOS Proxy
下载
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
- proxy_next_upstream_tries 3：最多尝试 3 次（含首次），即最多轮询 3 个不同节点。设为 0 或不写等于不限制，风险极高
- proxy_next_upstream_timeout 10s：从第一次请求发出开始计时，总耗时超 10 秒就直接返回错误（如 502）。该值应略大于 proxy_read_timeout × 期望有效尝试次数，例如 read_timeout=5s，tries=3，timeout 设为 10–12s 较合理
upstream 必须启用被动健康检查
proxy_next_upstream 是“失败后兜底”，不是“提前绕开”。若不配合 max_fails 和 fail_timeout，Nginx 仍会把新请求轮询到已宕机但尚未被标记的节点，每次都要先失败再重试。
- 在 upstream 的每个 server 行后加：max_fails=3 fail_timeout=30s
- 连续 3 次失败（由 proxy_next_upstream 触发的 error/timeout/5xx 都会计入）后，该节点被临时剔除，30 秒内不再参与调度
- 可选加 backup 节点，仅当所有主节点不可用时才启用，作为最后一道防线
注意请求方法是否幂等
Nginx 默认只对 GET 和 HEAD 请求重试。POST、PUT、DELETE 等非幂等方法不会自动重试——这是安全机制。
- 除非后端已做请求 ID 去重，否则不要强行开启非 GET 方法重试
- 若真需开启，需额外关闭缓冲：proxy_buffering off 和 proxy_request_buffering off（Nginx ≥ 1.7.11），但极易引发数据重复，不推荐
