Nginx + Keepalived 自愈能力需构建健康检查、进程恢复、VIP漂移、状态反馈四环节闭环，通过细粒度服务探测、双层健康验证、主动降级策略及可观测运维实现5秒内就地修复优先的自动化响应。
要让 Nginx + Keepalived 具备真正意义上的“自愈能力”，不能只停留在主备切换层面——关键在于把健康检查、进程恢复、VIP 漂移和状态反馈四个环节串成闭环。单靠 Keepalived 默认的进程存活检测远远不够，必须引入细粒度服务级探测，并配合自动化响应动作。
核心自愈逻辑：不只是切 VIP，还要救服务
传统高可用只做“故障转移”，而自愈平台要先尝试“就地修复”。比如 Nginx 工作进程崩溃时，优先触发本地重启；若 3 秒内无法恢复，再触发 VIP 漂移，同时告警并记录上下文。整个过程需在 5 秒内完成，避免业务中断感知。
- Keepalived 的
vrrp_script不应只调用kill -0 $(pidof nginx)，而应执行完整探活脚本：访问/nginx_status端点 + 检查 worker 进程数 + 验证配置语法（nginx -t） - 脚本返回非 0 时，先执行
/usr/local/nginx/sbin/nginx -s reload或-s start；失败后再退出，触发权重下降或状态切换 - 所有操作需记录到独立日志（如
/var/log/keepalived-heal.log），包含时间戳、返回码、前后进程 PID 和nginx -V输出摘要
双层健康检查：Nginx 自身 + 后端真实服务
仅保障 Nginx 进程活着，不代表业务可用。例如 upstream 中某台 Tomcat 崩溃，但 Nginx 仍正常运行，此时用户请求会大量 502。因此需叠加两层探测：
- 第一层（Keepalived 脚本）：验证 Nginx 本身是否可响应 HTTP 请求（如
curl -f http://127.0.0.1:80/healthz，该路径由 Nginx 配置为返回 200） - 第二层（Nginx 内置）：启用
upstream的max_fails=3 fail_timeout=30s，配合proxy_next_upstream error timeout http_502，自动摘除异常后端 - 建议在 Nginx 中暴露
/status接口，整合 stub_status 和自定义后端健康汇总（如 Python 小程序实时读取 upstream 状态并返回 JSON）
配置要点：让 Keepalived 主动“降级”而非被动“宕机”
Master 节点不应等到完全失联才让出 VIP，而应在检测到局部异常时主动降低优先级，触发平滑切换。这需要精细配置 vrrp_script 的 weight 和 fall/rise 参数：
- 例如设置
weight -40，当健康检查连续失败 2 次（fall 2），节点优先级从 100 降至 60，低于 Backup 的 90，立即触发 VIP 迁移 - 恢复时需满足连续 3 次成功（
rise 3），防止网络抖动误判；且迁移后原 Master 不自动抢回 VIP，避免震荡 - 在
vrrp_instance中添加nopreempt（仅 Backup 配置），确保切换后不因短暂恢复而反复漂移
运维增强：可观测性与一键干预通道
自愈能力必须配套可观测手段，否则无法定位根因。建议在部署时同步落地以下能力：
- 每台节点部署轻量采集器（如 Telegraf），上报 Keepalived 状态（
InstanceState）、VIP 绑定接口、最近一次切换时间戳、健康脚本执行耗时 - 在 Nginx 日志中统一打标：
$upstream_addr+$upstream_response_time+ 自定义变量$vip_status（通过 map 模块映射当前是否持有 VIP） - 提供运维快捷入口：例如
heal-nginx.sh脚本，一键执行“重载配置 → 清空 upstream 缓存 → 强制健康检查 → 手动触发 VIP 抢占（仅限维护窗口）”
自愈不是全自动黑盒，而是把人工经验固化为可重复、可审计、可干预的机制。从脚本逻辑、参数阈值到日志字段，每个环节都应留有明确依据和回退路径。
