nginx网关高可用需双层保障：后端层用max_fails/fail_timeout+proxy_next_upstream实现被动健康检查，或nginx_upstream_check_module做主动探测；网关层用keepalived+vip漂移，配合自定义脚本检测nginx进程及上游链路状态，三端/health逻辑对齐，并通过kill进程、停后端等实测验证。
要让 Nginx 真正扛住微服务网关入口的重担，不能只靠多配几台机器，必须把健康检查和故障转移这两件事做实、做细。核心思路是：对内（后端服务）用 Nginx 主动或被动探测保连通性，对外（网关自身）靠 Keepalived 管 VIP 漂移保入口不中断。
后端服务层：Nginx 自身实现健康检查
开源版 Nginx 不支持原生主动探活，但可通过配置参数实现可靠的被动健康检查：
- 在 upstream 块中为每个后端节点设置 max_fails=3 fail_timeout=30s，表示 30 秒内连续失败 3 次即标记为不可用
- 配合 proxy_next_upstream error timeout http_500 http_502 http_503 http_504，让请求在异常时自动转发到下一个节点
- 若需主动探测（如定期 GET /health），可编译安装 nginx_upstream_check_module（Tengine 或手动打补丁），启用 check 指令，避免依赖商业版 Nginx Plus
Nginx 实例层：Keepalived 确保网关自身高可用
单台 Nginx 崩溃或卡死，用户就全量失联——这是最危险的单点。Keepalived 的作用就是让两台 Nginx 共享一个虚拟 IP（VIP），主挂了，备立刻接棒：
- 主节点 priority 100，备节点 priority 90；virtual_router_id 必须同网段唯一，interface 明确指定物理网卡（如 ens33）
- 仅靠 VRRP 心跳不够：Nginx 进程卡死但系统仍在运行，VRRP 仍认为主节点“活着”，VIP 不会漂移。必须叠加自定义检测脚本
- 写一个脚本每 2 秒请求 http://127.0.0.1:80/health，返回非 200 则执行 keepalived -v -d 或直接降权（如 priority 减 20），一旦低于备节点值，立即触发切换
健康端点与协同逻辑要对齐
/health 接口不是摆设，它得真实反映 Nginx 作为网关的可用状态：
- 该接口应不仅检查自身进程，还要尝试 proxy_pass 到至少一个关键后端（如认证服务），确保上游链路基本通畅
- Keepalived 的检测脚本、Nginx 的 upstream health check、后端服务自身的 /health 三者响应逻辑要一致：比如都要求 200 OK，超时都设为 1s，失败阈值对齐
- 避免“假健康”：例如 Nginx 还在响应 200，但 upstream 所有节点已被标记为 down，此时 /health 却没报错——这就失去了意义
验证与兜底不能省
配置写完不验证，等于没配。每次上线前必须走通故障路径：
- 手动 kill -9 nginx 主进程，观察 VIP 是否在 3–5 秒内漂移到备机（通过 ip addr show 查看）
- 停掉某台后端服务，确认 Nginx access 日志不再向其转发请求，且 upstream 模块日志显示 “unavailable”
- 加一层基础监控：用 curl 定期调用 /health，配合 Prometheus + Alertmanager 告警；同时采集 keepalived 状态（如 vrrp_instance_state）、Nginx active conn、upstream server state
