提升Nginx后端服务可用性的核心是实现故障感知与自动绕过，需配置被动健康检查（max_fails、fail_timeout）、匹配业务的负载策略（轮询/ip_hash/least_conn等）、设置backup备用节点，并可选配主动健康检查模块。
提升 Nginx 负载均衡中后端服务的可用性，核心在于让 Nginx 能“感知故障”并“自动绕过”，同时确保流量分发合理、稳定、可恢复。这不是仅靠加几台服务器就能解决的事，关键在配置细节和机制协同。
启用被动健康检查（基础但必须）
Nginx 默认就支持被动健康检查，无需额外模块，但很多人没配对参数。它通过后端响应异常（如超时、502/504）来判断节点是否失效。
- max_fails：连续失败多少次后标记为不可用（默认是 1，建议设为 2–3）
- fail_timeout：标记为不可用后，多久再尝试恢复（默认 10 秒，建议 20–60 秒）
- 示例配置：
server 192.168.1.101 max_fails=3 fail_timeout=45s;
注意：这个机制只在请求实际打到该节点并失败时才触发，属于“事后响应”，适合大多数 Web 场景。
配置合理的负载策略匹配业务特征
选错算法会导致部分后端过载或会话中断，间接降低可用性。
- 普通 HTTP 服务 → 用轮询或加权轮询（性能不均时加 weight）
- 带登录态、购物车等需会话保持 → 必须开启 ip_hash，避免用户反复登录
- 长连接多（如 WebSocket、API 流式响应）→ 使用 least_conn，防止某台机器堆积大量连接
- 后端响应时间波动大 → 可考虑 hash $upstream_http_x_response_time（需自定义变量配合）
错误做法：所有后端都用默认轮询，但其中一台 CPU 已达 95%，却还在持续接收新请求。
加入备用节点与容灾兜底
当所有主节点都不可用时，仍要保障基本服务能力。
- 在 upstream 中声明 backup 服务器：
server 192.168.1.200 backup; - backup 节点默认不参与轮询，仅在所有非 backup 节点失效时启用
- 可搭配降级逻辑（如返回静态维护页），或指向轻量级兜底服务（如缓存层、简单 API 网关）
这一步不是锦上添花，而是故障蔓延前的最后一道缓冲。
主动探测 + 第三方模块（进阶高可靠）
被动检查有延迟，主动健康检查能更早发现问题。推荐使用 nginx_upstream_check_module（需编译安装）：
- 定期向后端 /health 或 /status 接口发送探测请求
- 支持
rise（连续成功几次标记为健康）、fall（连续失败几次标记为异常） - 示例：
check interval=3000 rise=2 fall=3 timeout=1000 type=http; - 配合
check_http_send和check_http_expect_alive可精细控制探测行为
适用于金融、支付、订单等对可用性要求极高的系统。
