Nginx upstream 健康检查与失败转移

发布时间:2025-12-03 10:08

## 场景 Nginx 反代多台后端时，默认行为是被动健康检查：某台后端请求失败了才把它标记为不可用，切换过程中总有若干请求成为代价。理解 upstream 的失败判定参数，配合 backup 节点做好预案，才能把单台后端故障对用户的影响压到接近无感。这套机制完全在配置层完成，后端应用不需要做任何配合改造，这也是它被广泛使用的原因。 ## 步骤清单 典型的 upstream 配置如下。 ``` upstream app { server 10.0.0.11:8080 max_fails=3 fail_timeout=10s; server 10.0.0.12:8080 max_fails=3 fail_timeout=10s; server 10.0.0.13:8080 backup; } ``` max_fails 与 fail_timeout 是一对：在十秒窗口内失败满三次，该节点在接下来的十秒内不再被选中，窗口滚动后重新给机会。backup 标记的节点平时不接流量，其余节点全部不可用时才启用，适合放一台配置较低但能兜底的机器。 ## 验证 验证失败转移要看得见计数。开启代理日志或使用状态接口，观察请求在后端间的分配；手动停掉一台后端，压一轮请求确认全部落到其余节点，恢复后再观察它何时重新上线。值得注意被动检查的判定只认转发失败与超时，后端返回五错误码并不算失败，需要把返回码也纳入判定时，得在 location 层加代理下一跳的触发条件。 ## 注意事项 fail_timeout 调得过短，后端会在抖动中反复横跳；调得过长，真故障的摘除又太慢，初始值建议从十秒起步按观察调整。重试机制要把幂等性考虑进去：非幂等的写请求被自动重发，可能造成重复写入，宁可让其失败也别盲目重试。健康检查之外，慢节点是另一类隐患，它没死但响应缓慢，默认参数不会摘除它，需要超时参数配合处理。顺云上多台云服务器做后端池时，把这套参数与控制台的监控告警一起配齐，某台后端指标异常时告警先响、摘除机制随后兜底，故障切换就不再是碰运气的事。