直接检测httpd进程会失效，因为pgrep仅判断进程存在，无法识别服务僵死、端口卡住、503响应等“活着但不可用”状态，必须用curl发起带超时和状态码校验的HTTP请求端到端验证。

能实现秒级故障漂移，但前提是 Apache 本身必须可被 Keepalived 准确感知状态——只靠进程存活检测（pgrep httpd）不够可靠，容易漏判服务僵死、端口卡住、503 响应等“活着但不可用”的情况。

为什么直接检测 httpd 进程会失效

Keepalived 默认不关心 Apache 是否真能处理请求，只看 httpd 进程是否存在。而实际中常见问题包括：

• Apache 子进程全部卡在 Gracefully finishing 状态，pgrep 仍能查到进程，但不再响应新连接
• 配置错误导致 Apache 启动后立即进入 Restarting 循环，ps 看似有进程，curl -f http://127.0.0.1/health 却持续超时
• SELinux 或防火墙拦截了本地健康检查回环流量，脚本返回失败，触发误切换

所以必须用端到端的 HTTP 健康探测替代纯进程检查。

vrrp_script 必须用真实 HTTP 请求验证服务可用性

在 /etc/keepalived/keepalived.conf 中定义脚本时，不要用 pgrep，改用带超时和状态码校验的 curl：

Apache Superset Dashboard and SQL Exploration Skill

Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

下载

vrrp_script chk_httpd {
    script "curl -f --max-time 2 http://127.0.0.1/health 2>/dev/null || exit 1"
    interval 2
    weight -5
}

关键点：

• --max-time 2 防止因后端阻塞导致 Keepalived 主进程 hang 住
• -f 让 curl 在收到非 2xx 响应时直接退出（如返回 503、404）
• /health 路径需在 Apache 的 DocumentRoot 下真实存在，且返回明确的 200 OK（建议用 echo "ok" > /var/www/html/health）
• 确保 Apache 监听 *:80 或 127.0.0.1:80，不能只监听 192.168.x.x:80

主备节点 priority 和 state 配置的隐含逻辑

state MASTER 和 state BACKUP 不是强制角色，真正决定谁持有 VIP 的是 priority 数值 + 抢占行为：

• 两台都设 state BACKUP 是安全做法，避免脑裂；只要 priority 不同（如主 101、备 99），VIP 仍会按权重归属
• 若主恢复后想自动抢回 VIP，必须加 nopreempt 到 vrrp_instance 块外层（不是注释掉它），否则默认启用抢占
• virtual_router_id 必须完全一致（0–255），且同一局域网内不能重复，否则 VRRP 报文被丢弃
• advert_int 1 是心跳间隔（秒），配合 interval 2 的检测脚本，故障发现最快约 2–3 秒

云环境或容器化部署时 VIP 漂移常被静默拦截

公有云（AWS/Aliyun/Tencent Cloud）普遍禁用 VRRP 协议（协议号 112），即使你配置正确，tcpdump -i any vrrp 也看不到任何报文：

• 此时 ip a 看不到 VIP，systemctl status keepalived 显示 active，但日志里反复报 VRRP_Instance(VI_1) Sending/Receiving VRRP packets failed
• 解决方案不是调 Keepalived，而是换架构：用云平台提供的弹性 IP + 自定义脚本 + API 调用实现手动漂移（例如阿里云用 aliyun ecs AssociateEipAddress）
• Kubernetes 场景下，别碰 Keepalived，直接用 Service type=LoadBalancer 或 MetalLB（它才是为云原生设计的 VIP 管理器）

真正落地时，最容易被忽略的是 VRRP 协议在网络层是否可达——不是配置写对了就行，得先确认底层允许它跑起来。