Nginx多进程模型仅保障单机健壮性，跨节点热备需Keepalived实现VIP漂移；其通过VRRP心跳检测+HTTP健康检查（非仅进程存在）触发主备切换，且主备配置、网络参数及时间必须严格一致。
Nginx 自身的多进程架构（Master-Worker 模型）并不直接提供跨机器的高可用热备能力，它解决的是单机内的稳定性与容错，比如 Worker 进程异常退出时由 Master 进程自动拉起。但真正的“热备”——即主节点宕机后由另一台物理/虚拟服务器无缝接管服务——必须依赖外部机制，最常用、最轻量、生产验证充分的方案就是 Keepalived + Nginx 双机主备。
Master-Worker 模型保障单机健壮性
这是高可用的基础层，不是热备本身，但不可或缺：
- Master 进程不处理请求，只负责管理 Worker 进程生命周期、加载配置、平滑重启
- 每个 Worker 进程独立处理连接，一个崩溃不会影响其他 Worker，Master 会立即补足数量
- 配合
worker_rlimit_nofile、worker_connections和信号控制（如nginx -s reload），可实现零停机配置更新
跨节点热备靠 Keepalived 实现 VIP 漂移
单靠 Nginx 多进程无法应对服务器断电、系统内核崩溃、网卡故障等整机级故障。这时需要 Keepalived 做三件事：
- 在主节点绑定一个虚拟 IP（VIP），所有客户端只访问这个地址
- 主备节点通过 VRRP 协议周期性发送组播心跳（目的地址
224.0.0.18，协议号 112） - 当备节点连续收不到心跳，且自身健康检查（如 curl 访问本地 Nginx）也通过，就立即接管 VIP 并启动服务
健康检查必须穿透到服务层，不能只看进程
很多故障是“Nginx 进程活着，但已不响应请求”，比如后端全挂导致 502 堆积、配置错误引发循环重定向、或 OOM 后卡死。因此 Keepalived 的检测脚本要真实发起 HTTP 请求：
- 写一个
/etc/keepalived/check_nginx.sh，用curl -I http://127.0.0.1:80 -m 3 -f判断是否返回 2xx/3xx 状态码 - 在
vrrp_script中设置interval 2（每2秒检测）、weight -10（失败则降低优先级触发切换） - 避免使用
killall -0 nginx这类仅检查进程存在的方法
配置一致性与关键细节决定成败
主备节点看似“一主一备”，实则必须严格对等，否则切换后行为突变：
- Nginx 配置文件（
/etc/nginx/nginx.conf）完全一致，包括 upstream、proxy_set_header、超时参数等 - Keepalived 的
virtual_router_id、auth_pass、interface（网卡名）三者必须完全相同 - 两台机器需时间同步（
chronyd或ntpd），防火墙放行 VRRP（协议 112）和业务端口（如 80/443）
