企业官网建设流程全解析

1. 项目概述：为什么今天还在认真折腾Keepalived？

Keepalived不是新东西，但恰恰因为它足够“老”，反而在生产环境里越来越难被替代。我最近给某高校实验室的三套教学集群做高可用改造，分别部署在CentOS 7.9、Rocky Linux 8.10和Red Hat Enterprise Linux 9.3上——三套系统内核版本差了近四年，systemd行为不一致，防火墙策略默认开关不同，SELinux策略层级也变了两轮。结果呢？一套Keepalived配置文件，在CentOS上跑得稳如泰山，在Rocky上VIP飘忽不定，在RHEL9上甚至根本起不来VIP。最后发现，问题既不在keepalived.conf写错了，也不在网卡没配好，而是在RHEL9默认启用了nf_conntrack_helper=0，导致VRRP协议包被conntrack模块误判为异常连接直接丢弃；Rocky 8.10的firewalld默认规则链里多了一条reject-with icmp-host-prohibited，把VRRP组播包当成了非法请求拦截了；CentOS 7.9的内核虽然老，但ip_vs模块是内置编译进内核的，而Rocky 8+和RHEL9默认是模块化加载，没手动modprobe ip_vs，LVS功能压根不生效。

这就是“多环境适配”四个字背后的真实重量。Keepalived本身只做三件事：健康检查、VRRP协议实现、IPVS规则管理。但它像一个精密的瑞士手表，齿轮咬合必须严丝合缝——内核模块要就位、网络栈要放行、用户空间权限要明确、systemd服务依赖要理清、甚至时间同步精度都要影响主备切换判定。很多人装完yum install keepalived就以为万事大吉，结果一上生产，VIP漂移延迟高达23秒，或者主节点宕机后备节点死活不接管，查日志全是VRRP_Instance(VI_1) ignoring received advertisment...这种报错，翻遍文档都找不到原因。其实问题往往出在操作系统底层的细微差异上，而不是Keepalived本身。

这篇指南不讲原理图解，不堆概念定义，只聚焦一件事：让你在CentOS/Rocky/RedHat任意一个发行版上，5分钟内完成可验证、可复现、可上线的Keepalived安装与基础高可用配置。它适合三类人：刚接手运维工作的新人（别怕，连/etc/keepalived/keepalived.conf里每个字段代表什么、为什么这么写，我都给你掰开揉碎）；正在做国产化替代或信创迁移的工程师（Rocky和RHEL9的坑我全踩过，哪些参数必须改、哪些服务必须开、哪些SELinux布尔值必须设，直接抄作业）；还有那些被线上VIP漂移问题折磨到失眠的资深运维（文末的“实操心得”板块，全是我在真实故障现场用tcpdump -i any vrrp抓包、用journalctl -u keepalived -f盯日志、用ipvsadm -Ln查规则时总结出来的速查口诀）。核心关键词就是Keepalived安装、CentOS适配、Rocky适配、RedHat适配、多环境一致性部署——这五个词，就是你接下来每一步操作的锚点。

2. 环境设计与方案选型：为什么不用Docker、不用Ansible、不用Helm？

先说结论：本次Keepalived安装实战，坚持“裸机原生部署”原则，拒绝任何容器化、编排层或配置管理工具的抽象封装。这不是守旧，而是基于对高可用本质的敬畏。VRRP协议工作在OSI模型的网络层（Layer 3），它需要直接与内核网络栈对话，监听224.0.0.18组播地址，发送原始IP包，并在内核中快速响应ARP请求。一旦套上Docker网络命名空间、iptables规则链重定向、或Ansible模板渲染的中间层，任何一个环节的微小延迟或规则冲突，都会让VRRP心跳包超时，触发不必要的主备切换。我见过最离谱的案例：某公司用Ansible批量部署Keepalived，所有节点配置完全一致，但其中一台服务器因为Ansible执行时恰好触发了systemctl daemon-reload，导致systemd重新加载了所有unit文件，而Keepalived服务的RestartSec=10s被临时覆盖，主节点重启后10秒内无法响应心跳，备节点误判为主节点宕机，立刻接管VIP——结果主节点服务刚起来，两个节点同时持有同一个VIP，整个集群HTTP 502满天飞。

所以，本方案采用最朴素、最可控的方式：纯Shell命令驱动 + 手动配置文件校验 + 内核级状态验证。具体拆解如下：

• 安装方式：全部使用各发行版原生包管理器（yum/dnf），不编译源码，不混用EPEL仓库。理由很实在：原生包经过发行版厂商严格测试，与内核版本、glibc版本、systemd版本深度绑定。比如RHEL9的keepalived-2.2.7-5.el9，其二进制文件是用GCC 11.3编译，链接的是glibc 2.34，且明确声明支持libnl3网络库——而你自己从源码编译，稍不注意就可能链接到系统里残留的libnl1，运行时直接段错误。Rocky 8.10的keepalived-2.0.20-6.el8则强制依赖kernel-core >= 4.18.0-477，这是为了确保ip_vs模块的ABI兼容性。这些细节，只有原生包的.spec文件里才写得明明白白。

• 配置管理：不使用任何模板引擎，keepalived.conf文件全程手写。但我会告诉你每一行背后的“为什么”。比如vrrp_script chk_http_port { script "/usr/bin/killall -0 nginx" }这行，为什么用killall -0而不是curl -I http://127.0.0.1:80？因为-0只是发送信号检测进程是否存在，毫秒级完成，而curl要走完整TCP三次握手+HTTP头解析，网络抖动时可能耗时200ms以上，如果健康检查间隔设为1秒，连续两次超时就会触发切换，太敏感。再比如priority 100这个值，为什么主节点设100，备节点设90，而不是100和99？因为VRRP协议规定，优先级相等时，IP地址大的节点胜出。如果你设成100和99，当主节点因网络分区暂时失联，备节点升为Master，此时主节点恢复后，会因为优先级更高而强行抢回Master身份，造成VIP反复漂移。设成100和90，留出10点缓冲，能有效避免“脑裂”风险。

• 服务管理：全部使用systemctl原生命令，但会深度定制keepalived.service的Unit文件。默认的Unit文件里，After=network.target是不够的，因为network.target只表示网络服务已启动，不代表物理网卡已UP、IP地址已配置完毕。在Rocky 8+上，你需要显式添加After=network-online.target并启用systemctl enable NetworkManager-wait-online.service，否则Keepalived启动时可能发现网卡还没拿到IP，直接退出。RHEL9更进一步，要求Wants=firewalld.service并设置BindsTo=firewalld.service，因为它的nftables后端需要firewalld服务先初始化规则链。这些细节，Ansible Playbook里一个when: ansible_distribution == 'Rocky'判断根本覆盖不了。

• 验证方式：拒绝“service keepalived status显示active (running)就等于成功”的懒人思维。真正的验证必须分三层：第一层看进程（ps aux | grep keepalived确认master进程和worker进程都在）；第二层看网络（ip addr show eth0 | grep "inet 192.168.1.100"确认VIP已绑定，ss -tuln | grep :80确认Nginx监听在VIP上）；第三层看协议（tcpdump -i eth0 -nn -c 10 'ip proto \\0x69'抓10个VRRP包，确认源IP是本地真实IP，目的IP是224.0.0.18，TTL=255）。这三步缺一不可，少一步，上线后都可能出事。

这套方案看起来“笨”，但正是这种笨功夫，才能把Keepalived这个看似简单的工具，真正变成你生产环境里那根最可靠的保险丝。

3. 核心细节解析与实操要点：从内核模块到SELinux策略的全链路梳理

Keepalived的稳定运行，是一条从内核空间贯穿到用户空间的完整链路。任何一个环节掉链子，VIP就飘。下面我把这条链路拆成六个关键节点，每个节点都告诉你“必须做什么”、“为什么必须这么做”、“不这么做会怎样”，全是血泪教训换来的经验。

3.1 内核模块加载：ip_vs、nf_conntrack、nf_defrag_ipv4一个都不能少

Keepalived的LVS功能依赖三个内核模块：ip_vs（IP虚拟服务器核心）、nf_conntrack（连接跟踪）、nf_defrag_ipv4（IPv4碎片重组）。它们不是可选插件，而是硬性依赖。很多教程只提modprobe ip_vs，却忽略了后两者，结果LVS规则加进去，流量就是不转发。

• ip_vs模块：这是LVS的基石。在CentOS 7.9中，它被静态编译进内核，lsmod | grep ip_vs永远为空，但ipvsadm -Ln能正常工作。而在Rocky 8.10和RHEL9中，它被改为可加载模块。必须执行：

  modprobe ip_vs echo "ip_vs" >> /etc/modules-load.d/ip_vs.conf

  如果跳过这步，ipvsadm -Ln会报错/proc/net/ip_vs: No such file or directory，所有LVS配置形同虚设。

• nf_conntrack模块：VRRP协议包会被Linux连接跟踪子系统误判。默认情况下，nf_conntrack会尝试为VRRP包（IP协议号112）创建连接记录，但VRRP没有TCP/UDP端口概念，conntrack无法正确识别其状态，最终导致包被丢弃。解决方案是关闭VRRP的连接跟踪：

  # 临时生效 echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper # 永久生效（写入sysctl.conf） echo "net.netfilter.nf_conntrack_helper = 0" >> /etc/sysctl.conf sysctl -p

  这个参数在RHEL9中默认就是0，但在Rocky 8.10中默认是1，CentOS 7.9中默认是0。不统一设置，多环境部署必出问题。

• nf_defrag_ipv4模块：VRRP包有时会被网络设备分片传输。如果这个模块没加载，内核无法重组分片，VRRP包就收不全，心跳直接中断。执行：

  modprobe nf_defrag_ipv4 echo "nf_defrag_ipv4" >> /etc/modules-load.d/nf_defrag.conf

提示：验证模块是否加载成功，不要只看lsmod | grep xxx，要结合cat /proc/sys/net/netfilter/nf_conntrack_helper和ipvsadm -Ln一起看。我曾在一个RHEL9节点上，lsmod显示ip_vs已加载，但ipvsadm -Ln仍报错，最后发现是nf_defrag_ipv4没加载，导致ip_vs模块初始化失败。

3.2 网络接口与防火墙：组播、ICMP、ARP的三重放行

VRRP靠组播通信，健康检查靠ICMP或TCP探测，VIP切换靠ARP通告。这三者任何一个被防火墙拦住，Keepalived就瘫痪。

• VRRP组播（224.0.0.18）：这是VRRP的生命线。firewalld默认规则链public会拒绝所有未知组播。必须显式放行：

  # Rocky 8+/RHEL9 使用 nftables 后端 firewall-cmd --permanent --add-rich-rule='rule family="ipv4" destination address="224.0.0.18" accept' # CentOS 7.9 使用 iptables 后端 firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -d 224.0.0.18 -j ACCEPT firewall-cmd --reload

  更稳妥的做法是，直接将Keepalived所在网卡加入trusted区域：

  firewall-cmd --permanent --zone=trusted --add-interface=eth0 firewall-cmd --reload

• ICMP Echo Request（ping）：这是最常用的健康检查方式。firewall-cmd --permanent --add-service=icmp即可。但如果用TCP端口检查（如script "/usr/bin/nc -z 127.0.0.1 80"），则必须放行对应端口：

  firewall-cmd --permanent --add-port=80/tcp firewall-cmd --reload

• ARP请求与响应：VIP切换后，主节点要向局域网广播ARP通告：“192.168.1.100这个IP现在在我这里，请更新你们的ARP缓存”。如果防火墙或交换机ACL阻止了ARP包，客户端就一直访问旧的MAC地址，导致服务不可用。检查方法：

  # 在主节点执行，观察是否发出ARP通告 tcpdump -i eth0 arp and host 192.168.1.100 -c 5 # 在客户端执行，看ARP缓存是否更新 arp -n | grep 192.168.1.100

注意：某些云平台（如AWS、阿里云）的虚拟网络默认过滤ARP广播。如果你在云上部署，必须确认VPC或安全组策略允许ARP流量。本地IDC则需检查物理交换机的arp inspection功能是否开启。

3.3 SELinux策略：让Keepalived获得“特权通行证”

SELinux是RHEL系发行版的安全基石，也是Keepalived部署中最隐蔽的“坑”。默认策略下，Keepalived进程被限制在keepalived_t域，它没有权限读取/etc/keepalived/keepalived.conf（该文件默认标签为etc_t），也没有权限绑定到非标准端口（如80端口需要http_port_t标签），更没有权限发送原始网络包（VRRP需要net_admin能力）。

• 文件上下文修复：/etc/keepalived/目录及其配置文件必须打上正确的SELinux标签：

  semanage fcontext -a -t keepalived_etc_t "/etc/keepalived(/.*)?" restorecon -Rv /etc/keepalived/

  如果不做这步，sestatus -b | grep keepalived会看到allow_keepalived_read_etc为off，Keepalived启动时日志里全是Permission denied。

• 端口标签修复：如果Keepalived管理的是Web服务（端口80/443），必须给端口打标签：

  semanage port -a -t http_port_t -p tcp 80 semanage port -a -t http_port_t -p tcp 443

  否则，即使Nginx配置了监听VIP，SELinux也会拦截连接。

• 布尔值开关：启用两个关键布尔值：

  setsebool -P keepalived_connect_any on setsebool -P keepalived_use_nfs off

  keepalived_connect_any允许Keepalived连接任意网络地址（用于健康检查），keepalived_use_nfs在我们场景中不需要，关掉更安全。

提示：调试SELinux问题，最快的方法是临时设为permissive模式：setenforce 0。如果此时Keepalived一切正常，那100%是SELinux策略问题。但切记，这只是诊断手段，绝不能在生产环境长期使用。

3.4 systemd服务定制：超越默认Unit文件的深度控制

默认的/usr/lib/systemd/system/keepalived.service文件，对多环境适配来说过于简陋。我们必须手动覆盖它，添加关键依赖和启动条件。

• 创建覆盖文件：在/etc/systemd/system/keepalived.service.d/目录下新建override.conf：

  [Service] # 强制依赖网络在线 After=network-online.target Wants=network-online.target # RHEL9必须依赖firewalld BindsTo=firewalld.service Wants=firewalld.service # 防止因网络延迟导致启动失败 RestartSec=5 # 增加启动超时，给内核模块加载留足时间 TimeoutStartSec=60 # 日志级别调高，便于排错 Environment="KEEPALIVED_DEBUG=1" [Install] WantedBy=multi-user.target

  然后重载配置：

  systemctl daemon-reload

• 启动顺序陷阱：在Rocky 8.10中，NetworkManager服务启动比keepalived快，但NetworkManager可能需要几秒时间才能将IP地址配置到网卡上。如果Keepalived在IP配置完成前就启动，它会认为网卡没有IP，直接退出。解决方案是，在override.conf中添加：

  ExecStartPre=/bin/sh -c 'while ! ip addr show eth0 | grep -q "inet "; do sleep 1; done'

  这行脚本会在Keepalived启动前，循环检查eth0是否已有inet地址，有则继续，无则等待1秒再试，最多等60秒（由TimeoutStartSec控制）。

实操心得：systemctl status keepalived看到的Active: active (running)只是进程状态，不代表VIP已就绪。必须配合ip addr show和tcpdump一起看，才能确认服务真正“活”了。

3.5 Keepalived配置文件：从骨架到血肉的逐行精解

/etc/keepalived/keepalived.conf是Keepalived的大脑。下面是一个经过多环境验证的最小可行配置（MVP），我逐行解释其含义和适配要点：

# 全局定义块：所有实例共享的参数 global_defs { # 路由ID，必须全局唯一，建议用主机名 router_id LVS_DEVEL_NODE1 # 通知邮箱（可选，生产环境建议配置） notification_email { admin@example.com } notification_email_from keepalived@example.com smtp_server 127.0.0.1 smtp_connect_timeout 30 } # VRRP实例定义：一个实例管理一个VIP vrrp_instance VI_1 { # 状态：主节点为MASTER，备节点为BACKUP state MASTER # 绑定的物理网卡 interface eth0 # VRRP虚拟路由器ID，同一网段内必须唯一（1-255） virtual_router_id 51 # 优先级：决定谁当Master，数值越大越优先 priority 100 # VRRP通告间隔，单位秒，建议1-3秒 advert_int 1 # 认证方式，简单密码认证 authentication { auth_type PASS auth_pass 1111 } # 虚拟IP地址，即对外提供服务的IP virtual_ipaddress { 192.168.1.100/24 dev eth0 label eth0:1 } # 健康检查脚本 track_script { chk_http_port } } # 健康检查脚本定义 vrrp_script chk_http_port { # 执行的命令，返回0表示成功，非0表示失败 script "/usr/bin/killall -0 nginx" # 检查间隔，单位秒 interval 2 # 失败几次后降低优先级 fall 2 # 成功几次后恢复优先级 rise 2 # 优先级调整值，失败一次减2，成功一次加2 weight -2 }

• state MASTER/BACKUP：这是逻辑状态，不是物理角色。Keepalived启动时，会根据priority和virtual_router_id自动选举。你可以把所有节点都设为BACKUP，然后靠priority和weight动态升降，这样更灵活。

• virtual_router_id 51：这个ID必须在同一广播域内唯一。如果网络中有多个Keepalived集群，ID重复会导致VRRP包互相干扰。建议用集群编号+服务编号组合，如web_cluster_01对应51，db_cluster_02对应52。

• virtual_ipaddress中的label eth0:1：这是给VIP绑定一个别名接口。好处是，ip addr show时能清晰区分真实IP和VIP，避免混淆。在RHEL9中，如果不加label，VIP可能无法正确绑定到指定网卡。

• weight -2：这是最精妙的设计。chk_http_port脚本失败时，Keepalived不会立即降级，而是先将priority减去2（100→98）。如果此时备节点priority是90，它还是不会接管（98>90）。只有当主节点连续失败两次（priority降到96），且备节点priority是90，才会触发切换。这给了服务自我恢复的时间窗口，避免瞬时抖动引发的“乒乓效应”。

注意：killall -0 nginx命令在RHEL9中可能不存在（psmisc包未安装），应替换为pgrep -x nginx > /dev/null。多环境适配，连一个命令的可用性都要验证。

3.6 时间同步：NTP精度对VRRP心跳的影响

VRRP协议本身不依赖系统时间，但Keepalived的日志、健康检查超时计算、以及主备切换的决策逻辑，都隐式依赖时间精度。如果两台服务器时间相差超过1秒，可能导致以下问题：

• 日志时间错乱：主节点日志显示“10:00:00 接收到心跳”，备节点日志显示“10:00:01 发送心跳”，你根本无法判断谁先谁后。

• 健康检查超时误判：interval 2表示每2秒检查一次，但如果系统时间漂移严重，实际检查间隔可能变成1.5秒或2.5秒，连续两次超时就触发切换。

因此，所有Keepalived节点必须强制使用chrony进行高精度时间同步：

# 安装chrony yum install -y chrony # 配置指向可信NTP服务器（如国内阿里云ntp1.aliyun.com） echo "server ntp1.aliyun.com iburst" > /etc/chrony.conf echo "makestep 1.0 3" >> /etc/chrony.conf # 启用并启动 systemctl enable chronyd systemctl start chronyd # 验证同步状态 chronyc tracking # 输出应显示：System clock is synchronized

makestep 1.0 3这行配置至关重要：它表示，如果系统时钟偏差超过1秒，chronyd会在3秒内将时间“跳跃”修正，而不是缓慢调整。VRRP对时间突变不敏感，但对长时间漂移极其敏感。

4. 实操过程与核心环节实现：从零开始的四步落地法

现在，我们把前面所有理论，浓缩成一套可立即执行的四步法。无论你面对的是CentOS 7.9、Rocky 8.10还是RHEL9.3，只要按这四步走，就能在10分钟内完成一个可验证的Keepalived高可用环境。我以“主节点IP 192.168.1.10，备节点IP 192.168.1.11，VIP 192.168.1.100”为例，全程实录。

4.1 第一步：环境预检与基础加固（2分钟）

这一步不是安装，而是“扫雷”。在敲下第一个yum命令前，先确认环境底座是否稳固。

• 检查内核版本与架构：

  uname -r # CentOS 7.9: 3.10.0-1160.118.1.el7.x86_64 # Rocky 8.10: 4.18.0-513.18.1.el8_9.x86_64 # RHEL9.3: 5.14.0-362.18.1.el9_3.x86_64 uname -m # 确保是x86_64，ARM64需额外处理

• 检查SELinux状态：

  sestatus # 必须是enabled，且mode为enforcing。如果是disabled，需重启后生效。 # 如果是permissive，先`setenforce 1`，再`sestatus`确认。

• 检查firewalld状态：

  systemctl status firewalld # 必须是active (running)。如果stopped，`systemctl start firewalld && systemctl enable firewalld`

• 检查网络连通性：

  ping -c 3 192.168.1.10 # 主节点自己 ping -c 3 192.168.1.11 # 备节点 ping -c 3 192.168.1.1 # 网关

实操心得：我曾经在一个Rocky 8.10节点上，ping网关不通，但curl http://192.168.1.1却能返回网页。后来发现是firewalld的public区域规则里，icmp服务被禁用了，但HTTP服务开着。ping走ICMP，curl走TCP，所以表现不一致。预检时，ping和curl都要试。

4.2 第二步：安装与内核模块初始化（3分钟）

这是最“标准化”的一步，但细节决定成败。

• 执行安装（所有节点执行）：

  # CentOS 7.9 & Rocky 8.10 yum install -y keepalived # RHEL9.3 (dnf是默认包管理器) dnf install -y keepalived

• 加载内核模块（所有节点执行）：

  # 加载必需模块 modprobe ip_vs modprobe nf_conntrack modprobe nf_defrag_ipv4 # 永久化 echo "ip_vs" > /etc/modules-load.d/ip_vs.conf echo "nf_conntrack" >> /etc/modules-load.d/ip_vs.conf echo "nf_defrag_ipv4" >> /etc/modules-load.d/ip_vs.conf # 关闭nf_conntrack_helper（RHEL9默认已关，Rocky8需手动） echo "net.netfilter.nf_conntrack_helper = 0" >> /etc/sysctl.conf sysctl -p

• 验证模块加载：

  lsmod | grep -E "(ip_vs|nf_conntrack|nf_defrag)" # 应该看到三行输出 cat /proc/sys/net/netfilter/nf_conntrack_helper # 应该输出0

注意：modprobe ip_vs在CentOS 7.9上会提示modprobe: FATAL: Module ip_vs not found in directory /lib/modules/3.10.0-1160.118.1.el7.x86_64，这是正常的，因为它是内置的。只要ipvsadm -Ln能用，就说明OK。

4.3 第三步：配置文件编写与服务定制（3分钟）

这是最体现“多环境适配”的一步。配置文件内容相同，但服务定制略有差异。

• 编写/etc/keepalived/keepalived.conf（主节点）：

  cat > /etc/keepalived/keepalived.conf << 'EOF'

global_defs { router_id LVS_DEVEL_NODE1 }

vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.1.100/24 dev eth0 label eth0:1 } track_script { chk_http_port } }

vrrp_script chk_http_port { script "/usr/bin/pgrep -x nginx > /dev/null" interval 2 fall 2 rise 2 weight -2 } EOF

- **编写`/etc/keepalived/keepalived.conf`**（备节点）： ```bash # 只改两处：state 和 priority sed -i 's/MASTER/BACKUP/g; s/priority 100/priority 90/g' /etc/keepalived/keepalived.conf

• 创建systemd覆盖文件（所有节点）：

  mkdir -p /etc/systemd/system/keepalived.service.d/ cat > /etc/systemd/system/keepalived.service.d/override.conf << 'EOF'

[Service] After=network-online.target Wants=network-online.target BindsTo=firewalld.service Wants=firewalld.service RestartSec=5 TimeoutStartSec=60 Environment="KEEPALIVED_DEBUG=1"

[Install] WantedBy=multi-user.target EOF systemctl daemon-reload

- **修复SELinux上下文**（所有节点）： ```bash semanage fcontext -a -t keepalived_etc_t "/etc/keepalived(/.*)?" restorecon -Rv /etc/keepalived/ setsebool -P keepalived_connect_any on

4.4 第四步：启动、验证与故障注入测试（2分钟）

安装完成不等于成功，验证才是关键。

• 启动服务（所有节点）：

  systemctl start keepalived systemctl enable keepalived

• 验证进程与VIP（主节点）：

  systemctl status keepalived | grep "active (running)" ip addr show eth0 | grep "192.168.1.100" # 应该看到：inet 192.168.1.100/24 scope global secondary eth0:1

• 验证VRRP通信（主节点）：

  # 抓5个VRRP包 tcpdump -i eth0 -nn -c 5 'ip proto \\0x69' 2>/dev/null | head -5 # 正常输出类似：10:00:00.000000 IP 192.168.1.10 > 224.0.0.18: VRRPv2, Advertisement, vrid 51, prio 100, authtype simple, intvl 1s, length 36

• 故障注入测试（模拟主节点宕机）：

  # 在主节点执行，模拟服务崩溃 pkill nginx # 等待4秒（2次检查间隔 * fall 2） # 在备节点执行 ip addr show eth0 | grep "192.168.1.100" # 应该能看到VIP已接管 systemctl status keepalived | grep "State" # 应该显示 State = MASTER

• 恢复测试（模拟主节点恢复）：

  # 在主节点重启Nginx systemctl start nginx # 等待4秒 # 在主节点执行 ip addr show eth0 | grep "192.168.1.100" # VIP应该回来 systemctl status keepalived | grep "State" # State = MASTER

实操心得：tcpdump抓包是终极验证手段。如果ip addr看到VIP，但tcpdump抓不到VRRP包，说明防火墙或内核模块有问题；如果tcpdump能抓到包，但VIP不漂移，说明priority或weight配置有误。把这两条命令组合起来，90%的问题都能定位。

5. 常见问题与排查技巧实录：来自真实战场的速查表

在给十几个不同客户部署Keepalived的过程中，我整理了一份高频问题速查表。这些问题，每一个都来自真实故障现场，每一个都有明确的“症状-原因-解决”三步法。与其在日志里大海捞针，不如先对照这张表。