Nginx 多进程架构本身不提供双机热备，需与 Keepalived 配合实现：Master 进程守护 Worker，保障单机服务可用；Keepalived 通过 VRRP 和 HTTP 健康检查触发 VIP 漂移，实现主备切换；配置一致是前提，否则高可用失效。
Nginx 本身的多进程架构（Master + Worker 模型）并不直接提供双机热备能力，它解决的是单机内高可靠性和稳定性问题；而双机热备（主备自动切换）依赖的是外部机制——主要是 Keepalived 基于 VRRP 协议实现的 VIP 漂移。二者是协作关系：Nginx 的进程健壮性为“服务层可用”打底，Keepalived 则负责“网络层可用”和故障接管。
真正支撑高可用双机热备落地的，是 Nginx 多进程特性与 Keepalived 配合后形成的分层可靠性：
Master 进程不处理请求，只做调度与守护
Nginx Master 进程不响应客户端连接，只负责管理 Worker 进程生命周期、读取配置、平滑重启、日志轮转等。这意味着：
- 即使某个 Worker 进程异常退出，Master 会立即拉起新进程，服务不中断
- Master 自身极轻量、极少崩溃，大幅降低单机“假死但进程在”的概率
- 这为 Keepalived 的健康检查（如 curl https://www.php.cn/link/fa01bbe3dc5821c4227e9e1d3c823e83 curl 能通，基本说明服务可响应
Worker 进程无状态、可快速重建
每个 Worker 是独立的事件驱动进程，不共享内存（除共享内存区外），彼此隔离。这带来两个关键优势：
- 故障影响范围被限制在单个 Worker 内，不会蔓延至整个 Nginx 实例
- 切换时无需同步会话或状态，备机上的 Nginx 启动即具备完整服务能力，与主机行为完全一致
与 Keepalived 健康检查形成闭环
单纯依赖进程存在（killall -0 nginx）不可靠，而 Nginx 的 HTTP 响应能力恰恰是最佳探测点：
- 健康检查脚本（如 /etc/keepalived/nginx_check.sh）用 curl 访问本地 80 端口，本质是在验证 Master+Worker 协同工作的最终输出
- 若返回 200，说明监听正常、配置加载成功、上游可达（如果是反代）、静态资源可读——这是端到端的服务健康信号
- 一旦失败，Keepalived 降低本节点 priority，触发 VIP 漂移，把流量导向另一台同样具备该能力的 Nginx 实例
配置一致性是多进程发挥效用的前提
两台机器上 Nginx 必须做到：
- 完全相同的 nginx.conf（含 listen、server_name、upstream、proxy_set_header 等）
- 相同的 root 路径、证书文件位置、日志路径（便于排查）
- 同样的启动方式（systemctl 或二进制命令）、同样的用户权限（如 nginx 用户）
否则，即使进程都 running，切换后可能返回 502、跳错地址、或展示不同页面——多进程再稳也救不了配置偏差
不复杂但容易忽略
