在使用 Keepalived 实现虚拟 IP(VIP)高可用的过程中,有时会遇到这样一个问题:
✅ Master 节点成功绑定了 VIP,状态正常
❌ 但从外部主机无法 ping 通 VIP,也无法访问服务
本文将分析问题根源,并给出 3 种实际有效的解决办法。
💡 环境信息
- 系统环境:CentOS / RHEL / Ubuntu 等
- Keepalived 版本:v2.2.4
❗问题表现
在 Keepalived 配置完成、Master 节点绑定 VIP 后,从本机可以看到 VIP 存在:
css
ip a | grep <VIP>
但从其他主机 ping VIP 不通,服务如 kube-apiserver(端口 6443)也无法访问。
抓包发现:VIP 收到了请求(ICMP/TCP SYN),但没有回应。

🔍 问题根源:vrrp_strict 模式导致 VIP 不响应
从 Keepalived v2.0 开始,默认启用了一个参数:
vrrp_strict
该参数的作用是 严格遵守 VRRP 协议规范。但在 Linux 下,它反而可能导致:
- VIP 无法响应外部请求(ICMP/TCP/UDP)
- 影响服务可用性
⚠️ 开启 vrrp_strict
会导致以下行为:
-
禁止配置 VIP 为 0 个
-
禁止单播邻居
-
禁止 vrrp_version 2 使用 IPv6
-
禁止使用认证(配置无效)
-
VIP 不会响应流量,除非满足以下条件:
- 优先级为 255
- 使用 vrrp_version 3 且开启
accept
模式
✅ 解决方法
我们根据不同场景,提供 3 种实用解决方案:
方案一:禁用 vrrp_strict
(推荐 ✅)
在配置文件中显式关闭此参数:
arduino
vrrp_strict false
或直接注释

添加位置:
global_defs
段或vrrp_instance
前均可
示例配置:
kotlin
global_defs {
router_id LVS_DEVEL
vrrp_strict false
}
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 1234
}
virtual_ipaddress {
192.168.1.100
}
}
效果:
- VIP 能正常响应外部请求(包括 ping、服务端口等)
- 配置简单,行为直观
方案二:使用 vrrp_version 3 + accept
模式
kotlin
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
version 3
accept
virtual_ipaddress {
192.168.1.100
}
}
注意事项:
accept
是 vrrp3 特有的选项- 要确保所有节点的 keepalived 都支持 v3
- 兼容性略差于方案一
方案三:设置优先级为 255(不推荐 ⚠️)
kotlin
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 255
...
}
问题:
- 所有节点设置 255 会导致无法明确主备切换
- VRRP 会频繁抢占,主备不稳定
适用于 VIP 绑定固定主机的场景 ,但 不适合高可用生产环境
🛠️ 补充建议
1. 确认 VIP 是否绑定成功:
css
ip a | grep 192.168.197.61
2. 启动 Keepalived 后观察日志:
journalctl -u keepalived -f
3. 绑定后主动发送 ARP 广播(可选):
css
arping -U -I eth0 -c 3 192.168.197.61