linux下nginx高可用需双层健康检查：一是编译nginx_upstream_check_module实现后端主动探测，二是用keepalived保障nginx节点自身存活，二者缺一不可。
Linux 下 Nginx 本身不带主动健康检查能力，原生的 max_fails + fail_timeout 属于被动容错机制，只能靠真实请求失败来判断，无法提前发现后端宕机或服务卡死。要实现真正高可用的健康检查结构，必须组合两个层面：Nginx 内部对后端服务器的主动探测（需编译模块），以及 Nginx 所在节点自身的存活保障（需搭配 Keepalived）。两者缺一不可。
一、Nginx 主动健康检查（后端服务级）
依赖第三方模块 nginx_upstream_check_module，需重新编译 Nginx：
- 确认当前 Nginx 版本（
nginx -v），下载对应 patch（如 1.26.3 用 v0.4.0 兼容版） - 在源码根目录执行
patch -p1 ，路径和 <code>-p参数错会导致编译报undefined reference to 'ngx_http_upstream_check_init' -
configure时必须加入：--add-module=../nginx_upstream_check_module-master/（路径必须真实存在） - upstream 块中，
check指令必须紧贴某台server行之后、单行书写（或用\续行），且同一 upstream 内只允许出现一次 - HTTP 类型必须配全：
check_http_send和check_http_expect_alive，否则探针发不出去；Host 头需与后端实际域名一致
示例配置：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
check interval=3000 rise=2 fall=3 timeout=1000 type=http;
check_http_send "HEAD /health HTTP/1.1\r\nHost: api.example.com\r\nConnection: close\r\n";
check_http_expect_alive http_2xx http_3xx;
}
二、Nginx 进程自身高可用（节点级）
仅靠 upstream 健康检查不能防止 Nginx 自身崩溃或机器宕机，必须引入 Keepalived 实现 VIP 漂移：
- 编写健康检查脚本
/etc/keepalived/check_nginx.sh，用curl -s --head验证 Nginx 是否能正常响应，比ps检测更可靠 - 在
vrrp_script中调用该脚本，设置interval 2、rise 1、fall 2，避免误切 -
vrrp_instance中启用track_script，并合理配置priority和state（主备模式下 master 优先级更高） - 确保两台 Keepalived 节点使用相同
virtual_router_id和子网内可通信的interface
三、关键联动与验证要点
高可用结构不是孤立配置，需关注协同效果：
- Keepalived 的 VIP 流量进来后，由本地 Nginx 转发——所以 Nginx 必须监听
0.0.0.0:80或 VIP 地址，不能只绑127.0.0.1 - 后端服务的
/health接口应返回轻量、快速、无副作用的响应（如 200 OK），避免拖慢检查周期 - 建议同时启用
--with-http_stub_status_module，通过/status页面观察 upstream 状态，确认 server 是否被标记为down - 故障模拟时，先停一台后端服务，观察 Nginx 日志是否触发
check fail；再杀本机 nginx 进程，观察 VIP 是否在 2–3 秒内漂移到备用节点
