backup参数仅在轮询或加权轮询模式下生效，需配合max_fails和fail_timeout将主节点标记为down后才启用，若配置ip_hash或least_conn则被忽略，且upstream必须定义在http块内、proxy_pass名称须严格一致。

upstream里backup参数必须和轮询/加权轮询一起用

backup不是独立调度策略，它只在主节点全部不可用时才启用，且仅对轮询（包括加权轮询）生效。如果你在upstream里加了ip_hash或least_conn，backup服务器会被Nginx直接忽略——配置不报错，但永远不触发。

• ip_hash开启后，所有backup标记失效，因为哈希算法必须保证一致性，不能中途切到备用节点
• least_conn本身不识别backup，写了也没用
• 想用backup，upstream块开头不能有任何调度指令，保持默认轮询行为

backup节点要配max_fails+fail_timeout才能真正“被踢出”

很多人以为只要标了backup，主节点一挂就自动切过去。其实Nginx默认不会主动探测主节点是否宕机，得靠健康检查机制把它们先标记为不可用，backup才会接管。否则请求会持续打到已故障的主节点上，返回502或超时。

Audio Upload Aioz Stream Free

基于 AIOZ Stream API 的免费音频上传技能，通过三步流程（Create → Upload Part → Complete）将本地音频文件上传至 AIOZ 流媒体平台。支持默认快速上传方式，使用默认编码配置，上传完成后返回 HLS 流媒体播放链接。使用 API Key (stream-publ...)进行认证。

下载

• 每个server行必须显式配max_fails=3 fail_timeout=30s（或其他合理值），否则健康检查不生效
• max_fails和fail_timeout必须成对出现，单独写一个等于没写
• backup节点自己也可以配这些参数，但通常没必要——它本就不参与常规流量

proxy_next_upstream不能替代backup逻辑

proxy_next_upstream error timeout只是告诉Nginx：“当前后端返回error或超时时，换下一台重试”。但它不会跳过所有主节点去backup，而是按轮询顺序挨个试，直到耗尽所有主节点才轮到backup。如果主节点响应慢但没超时，它可能一直卡在主节点上。

• 这个指令控制的是单次请求内的重试路径，不是集群级的故障转移开关
• backup生效依赖的是upstream层的节点状态（up/down），不是location里的重试配置
• 真要兜底，得靠max_fails把主节点置为down，而不是指望proxy_next_upstream绕开它们

配置位置错、名称不一致是启动失败最常见原因

upstream块必须定义在http块内，不能塞进server或location里；proxy_pass里的地址必须和upstream名称完全一致（大小写敏感）；backup节点的IP和端口也要写全，尤其非标准端口不能省略。

• 错误示例：upstream写在server块里 → 启动报错：nginx: [emerg] "upstream" directive is not allowed here
• proxy_pass http://Backend;（大写B）但upstream backend { ... }（小写b）→ 502错误，Nginx找不到对应组
• server 192.168.1.104 backup;没写端口 → 如果后端监听8080，实际请求会发到80，大概率失败

backup机制看着简单，但真正起效的前提是：主节点被正确标记为down，而标记依赖健康检查参数的完整配合。漏掉max_fails或放错位置，backup就只是个摆设。