实现Nginx与后端应用集群高可用需四层协同：一是Nginx upstream主动健康检查（max_fails/fail_timeout+backup）；二是后端统一暴露/health探针；三是Keepalived+VIP保障Nginx自身高可用；四是日志监控、指标告警与幂等重试策略。
要实现 Nginx 与后端应用集群的高可用链路维护，核心在于消除单点故障、保障请求连续分发、自动识别并绕过异常节点。这不是只配一个 upstream 就能解决的事，而是需要从 Nginx 本体配置、健康检查机制、上游服务容错策略、以及 Nginx 自身的高可用（防自身宕机）四个层面协同设计。
一、Nginx 层面：健壮的 upstream 配置与主动健康检查
Nginx 默认轮询是被动容错（仅在连接失败或超时后剔除），必须叠加主动探测才能真正“感知”后端是否存活。
- 在
upstream块中启用health_check（需 Nginx Plus）或使用开源版兼容方案（如nginx_upstream_check_module模块，或通过第三方脚本+max_fails/fail_timeout模拟） - 推荐基础可靠写法（开源版通用）：
upstream app_cluster { server 192.168.10.10:8080 weight=3 max_fails=3 fail_timeout=30s; server 192.168.10.11:8080 weight=3 max_fails=3 fail_timeout=30s; server 192.168.10.12:8080 backup; # 故障时启用备用节点 } -
max_fails=3 fail_timeout=30s表示：30 秒内连续失败 3 次，该节点被标记为不可用；恢复后需等待fail_timeout时间才重新加入调度 -
backup节点不参与常规负载，仅当所有非 backup 节点都失效时才启用，适合部署灾备实例
二、后端服务层：统一健康探针与就绪状态暴露
Nginx 的健康检查依赖后端提供稳定、低开销的健康接口（如 /actuator/health 或自定义 /health）。
- 所有后端应用必须暴露标准 HTTP 健康端点，返回
200 OK且响应体含"status":"UP" - 禁止将健康检查指向业务接口（如
/api/user），避免因业务逻辑慢或临时抖动误判为宕机 - 若使用 Spring Boot，确保
management.endpoints.web.exposure.include=health已开启，且路径未被安全拦截
三、Nginx 自身高可用：Keepalived + VIP 防止单点崩溃
即使 upstream 再健壮，若 Nginx 进程或所在机器挂了，整个入口就中断。必须部署至少两台 Nginx 服务器，并用 Keepalived 实现 VIP（虚拟 IP）漂移。
- 主备两台 Nginx 服务器安装相同配置（包括
nginx.conf和upstream列表） - Keepalived 主节点配置关键项：
vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS; auth_pass 123456; } virtual_ipaddress { 192.168.10.100/24 } # 客户端只访问此 VIP track_script { chk_nginx; } } vrrp_script chk_nginx { script "/etc/keepalived/check_nginx.sh" interval 2 weight -20 } -
check_nginx.sh脚本需验证 Nginx 进程存活 + 端口监听（如curl -f http://127.0.0.1/health || exit 1），一旦失败触发降权，触发主备切换 - 备节点
priority设为 90，其余配置（virtual_router_id、auth_pass、virtual_ipaddress）必须完全一致
四、链路可观测性与快速响应
高可用不只是“自动切换”，更是“可查、可溯、可干预”。
- 开启 Nginx access log 与 error log，并集中采集（如 ELK 或 Loki）
- 关键指标监控：
upstream_status（记录每个请求后端返回码）、upstream_response_time、upstream_addr（实际转发目标） - 设置告警规则：例如“连续 5 分钟
upstream_status中 5xx 比例 > 5%” 或 “VIP 所在主机无keepalived进程” - 配置
proxy_next_upstream允许错误重试（谨慎使用）：proxy_next_upstream error timeout http_500 http_502 http_503; proxy_next_upstream_tries 2; proxy_next_upstream_timeout 3s;
注意：仅适用于幂等请求（如 GET/HEAD），POST 类请求不应自动重试
不复杂但容易忽略
