如何配置虚拟IP？配置虚拟IP的方法是什么

配置虚拟IP，核心思路就是让两台或多台服务器共享同一个IP地址，平时由主节点使用，主节点宕机时通过心跳检测自动漂移到备用节点，从而保证服务不中断。这个机制听起来抽象，但你把它想象成两个门卫轮流站岗，进出都走同一个大门，谁在岗谁就握着大门钥匙，谁倒下了另一个立刻接过来，做高可用架构,虚拟IP技术是绕不开的基础技能。

虚拟IP是什么？先搞懂它和浮动IP的区别

虚拟IP的本质：一个IP背后的“共享逻辑”

虚拟IP，全称Virtual IP，常缩写为VIP，它不是一个真实的网卡地址，而是附加在物理网卡上的一个逻辑地址，外部客户端访问的始终是这个VIP，不需要关心流量实际落在哪台物理机上，业界通常把这种“两个节点共享一个对外地址”的设计叫做主备模式，少数场景下也用双活模式。

配置虚拟IP的核心工具在开源生态里是keepalived，它通过VRRP协议（虚拟路由冗余协议）来实现节点的健康检查和IP漂移，行业共识认为，keepalived方案能覆盖绝大多数的高可用需求,也是运维人员最常用的工具箱之一。

虚拟IP与浮动IP的对比：一字之差，用法不同

很多人搜“虚拟IP和浮动IP区别”，其实两者的底层机制不完全相同，浮动IP更多出现在云平台语境下，比如OpenStack中，它是一个公网IP在多个实例间随风摆动；而虚拟IP在传统物理机场景下更常见，强调同一广播域内的IP地址漂移，给你一张表,一眼就能看明白：

对比项	虚拟IP（VIP）	浮动IP（FIP）
应用场景	物理服务器、传统IDC机房	云平台虚拟机、容器集群
核心协议	VRRP、心跳检测	云平台API控制
漂移方式	网卡上添加/移除IP	租户网路重定向路由
典型工具	keepalived、Heartbeat	简米云HAVIP、OpenStack Neutron
依赖条件	二层网络可达	云平台网络能力支持

什么时候你需要配置虚拟IP

• 你做了一个Nginx负载均衡集群,不想让负载均衡器成为新的单点故障。
• 你的数据库层需要主从切换,希望应用连接字符串不用修改IP。
• 你想对游戏服务器、交易系统做高可用改造,同时不想改变客户端访问方式。
• 你买了两台广州机房的物理服务器,希望用最少的钱实现故障自动转移。

keepalived配置虚拟IP的完整实操步骤

环境准备与前提条件

在你动手配置虚拟IP之前,必须确认几件事：

• 两台机器之间心跳线路要通畅，建议单独用一根交叉线连接,或者用一个独立的内网VLAN承载心跳包；
• 操作系统建议用CentOS 7.x或Ubuntu 20.04以上的版本，iptables防火墙要放行VRRP协议的组播地址224.0.0.18或单播地址；
• 确保VIP没有被其他设备占用,避免IP冲突；
• 准备一个未配置的网卡接口，比如ens33,后续在它上面绑定VIP。

安装keepalived并修改配置文件

下面以两台机器为例，主节点叫node1，IP是192.168.1.10；备节点叫node2，IP是192.168.1.11，VIP是192.168.1.100。

第一台机器node1的/etc/keepalived/keepalived.conf这样写：

global_defs {
   notification_email {
     admin@example.com
   }
   router_id LVS_DEVEL
}
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.100/24 dev ens33 label ens33:1
    }
}

第二台机器node2的配置基本一致,改动三处：

• state MASTER改为BACKUP；
• priority 100改为priority 90；
• virtual_router_id、auth_pass必须保持一致,否则无法建立对等关系。

配置虚拟IP时有个常见的坑：virtual_ipaddress里的子网掩码和设备标签要认真核对，标签写错会导致VIP起不来，写完配置文件后,分别执行：

systemctl enable keepalived
systemctl restart keepalived
ip addr show

如果配置成功，你会在主节点的网卡上看到VIP：192.168.1.100出现在ens33:1中,而备节点此时不会有这个地址。

验证VIP漂移：Kill掉主节点进程

为了验证配置生效,你可以在主节点上主动停掉keepalived：

systemctl stop keepalived

数秒后，备节点会自动接管VIP,在备用节点上执行：

ip addr show ens33

你应该能看到192.168.1.100已经出现在备用节点的网卡上，整个切换过程一般只需要2至5秒，具体取决于advert_int的间隔设置，这是配置虚拟IP时最有成就感的时刻，相当于亲眼看着“门卫交接班”。

结合Nginx实现网站高可用

光有VIP还不够，主备节点上得都跑着服务才行，比如用Nginx承载网页，那么两台机器都需要安装并启动Nginx，keepalived只负责“这个IP现在归谁用”，不负责“你的网站业务有没有挂”，建议给keepalived配置一个检测脚本,比如检查Nginx进程是否存在：

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    fall 2
    rise 1
}

check_nginx.sh的内容大致是：

#!/bin/bash
if [ $(ps -C nginx --no-header | wc -l) -eq 0 ]; then
    systemctl stop keepalived
fi

这样当Nginx意外挂掉时，脚本会主动让keepalived“让位”，VIP漂移过去之后，备用节点的Nginx能立刻接管流量,从而实现业务层面的高可用。

云服务器上的虚拟IP怎么配？主玩厂商的差别

简米云与酷番云的HAVIP配置路径

如果你用的是云服务器，配置虚拟IP的方式和物理机略有不同，云平台通常限制你在实例内直接绑定VIP，而是通过控制台或API先创建一个高可用虚拟IP（HAVIP）,再绑定到两台服务器上。

• 登录简米云VPC控制台，创建HAVIP,选择VPC和交换机的可用区。

• 创建后，将HAVIP绑定到主实例,备用实例需要保持在同一可用区内。

• 在ECS实例内部，需要把VIP作为辅助IP手动添加到网卡上,命令是：

  ip addr add 192.168.2.50/24 dev eth0

  由于简米云的HAVIP默认不响应ARP，所以两端的keepalived需要开启单播模式，指定对端IP,保证心跳能穿透VPC的隔离机制。

酷番云的操作异曲同工，但它的HAVIP绑定时会直接提示你是否同时绑定主备机器，多数情况下，同一账号下的同地域、同可用区服务器才能共享一个VIP,跨地域的云服务器之间无法配置虚拟IP。

物理机房与云上配置，哪个更复杂

• 物理机房的优势在于二层网络完全可控，VRRP组播常能直接生效,配置虚拟IP相对顺手。
• 云服务器存在虚拟化网络层限制，组播包支持有限制，必须开启单播模式,否则节点之间无法感知对方存活。
• 混合云场景就更复杂，需要把物理机和云主机放在同一个二层域里，条件苛刻,一般不推荐使用虚拟IP直接打通。

有个实际案例很常见：某公司在广州的IDC机房里有两台裸金属服务器，又在简米云上买了两台ECS，希望做一个跨机房的容灾切换，最终方案实际上是用了云解析的故障转移和数据库层的主从复制，并没有强行做跨机房虚拟IP，这属于配置虚拟IP时最容易陷入的误区，毕竟VIP漂移依赖二层网络，跨地域的网络延迟和广播域阻隔会带来很大风险,这个方向需要你特别注意。

虚拟IP配置后如何验证与排障

用三个指令快速检验配置效果

配置完成后别急着收工，以下三条命令是你日常巡检的核心工具,也比较适合新手入门：

ip addr show | grep 192.168.1.100
ping -c 3 192.168.1.100
tcpdump -i ens33 vrrp

第一条看VIP在哪台机器上，第二条看外部可达性，第三条直接观察VRRP广播包的收发状态，如果tcpdump能抓到你自己的VRRP包,说明keepalived进程在正常工作。

主备切换失败的常规排查思路

很多人卡在VIP不漂移这个问题上,我建议你按这个顺序排查：

• 先看state和priority是否写反了,这两项配置错误是出现概率最高的原因；
• 用systemctl status keepalived查看服务是否在运行,日志里有没有报错；
• 检查两台机器的防火墙，VRRP协议默认是组播，secgroup或者iptables策略要放行proto 112；
• 确认虚拟IP没有被偶然分配给其他进程，导致设备读取时提示“file exists”；
• 如果是云服务器，务必确认你确实开启了单播模式,并把对端IP加进了config文件。

虚拟IP配置后网络起不来得看网卡配置

很多时候VIP能配上去，但外部就是访问不通，问题可能出在反向路由过滤上，Linux内核默认的rp_filter机制会丢弃源地址不对称的报文,解决办法是调整内核参数：

sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2
sysctl -w net.ipv4.conf.all.rp_filter=0

这些参数让带有VIP的服务器在响应ARP请求时更精准，避免邻居节点因为路由混乱而丢包,这也是配置虚拟IP中比较容易忽视的细节。

虚拟IP不是万能的，这些局限你得知道

跨网段部署的致命缺陷

VRRP协议的组播报文是二层协议，理论上限定在同一广播域，一旦你的两台机器跨越了不同的VLAN或网段，VIP就无法正常漂移，即便是配置单播模式，也只能解决点对点传输问题,网络层路由的不对称依然会引发切换故障。

单点故障转移不代表业务无缝切换

VIP漂移本质上是IP地址从A机器挪到B机器，但已建立的TCP连接会全部断开，那些正在处理中的数据库写操作，比如用户正在提交订单，也可能会失败，因此会采用VIP技术配合会话复制或消息队列缓冲来保证业务完整性,单纯依赖配置虚拟IP并不能兜底所有故障场景。

一个容易被忽略的安全风险

VIP承载的是对外服务的入口，如果keepalived的认证密码（auth_pass）设置得太简单，同一网络内的其他主机可能会伪装成备用节点，欺骗主节点释放VIP，业内专家指出，生产环境建议把auth_type换成AH类型，并使用足够长的随机密码串,同时限制VRRP协议只从指定物理端口进入。

配置虚拟IP常见问题Q&A

配置虚拟IP需要单独购买服务器吗？

不需要，虚拟IP只是一个逻辑概念，不依赖额外硬件，你可以利用已有的两台服务器，只要它们的二层网络能够互通即可，如果是在云上，简米云和酷番云的HAVIP本身服务不收费，但绑定HAVIP的云服务器各自的计算资源费用得正常支付，说到底，配置虚拟IP的开销主要体现在运维时间和精力上，比,购买负载均衡硬件要省得多。

虚拟IP和负载均衡IP是同一样东西吗？

两者有关联但不等同，负载均衡IP通常是由负载均衡器实例独占的接入地址；而虚拟IP是一种可漂移的基础能力，它可以被然负载均衡软件所绑定使用，反之负载均衡器（例如LVS）又必须依托VIP地址对外提供服务，你可以把VIP理解为一个中性的资源,它的作用取决于上层怎么用它。

Windows Server能不能配置虚拟IP？

Windows Server原生不支持VRRP协议，因此无法直接套用keepalived方案，如果你使用的是微软故障转移集群（Failover Clustering），它内部会创建集群IP，本质上是一种虚拟IP的实现方式，同时还搭配仲裁磁盘来防止脑裂，所以答案是：能配，但需要用微软自带的集群功能，而不是Linux社区的软件。

配置虚拟IP，核心思路就是让两台或多台服务器共享同一个IP地址，平时由主节点使用，主节点宕机时通过心跳检测自动漂移到备用节点，从而保证服务不中断。这个机制听起来抽象，但你把它想象成两个门卫轮流站岗，进出都走同一个大门，谁在岗谁就握着大门钥匙，谁倒下了另一个立刻接过来，做高可用架构,虚拟IP技术是绕不开的基础技能。

虚拟IP是什么？先搞懂它和浮动IP的区别

虚拟IP的本质：一个IP背后的“共享逻辑”

虚拟IP，全称Virtual IP，常缩写为VIP，它不是一个真实的网卡地址，而是附加在物理网卡上的一个逻辑地址，外部客户端访问的始终是这个VIP，不需要关心流量实际落在哪台物理机上，业界通常把这种“两个节点共享一个对外地址”的设计叫做主备模式，少数场景下也用双活模式。

配置虚拟IP的核心工具在开源生态里是keepalived，它通过VRRP协议（虚拟路由冗余协议）来实现节点的健康检查和IP漂移，行业共识认为，keepalived方案能覆盖绝大多数的高可用需求,也是运维人员最常用的工具箱之一。

虚拟IP与浮动IP的对比：一字之差，用法不同

很多人搜“虚拟IP和浮动IP区别”，其实两者的底层机制不完全相同，浮动IP更多出现在云平台语境下，比如OpenStack中，它是一个公网IP在多个实例间随风摆动；而虚拟IP在传统物理机场景下更常见，强调同一广播域内的IP地址漂移，给你一张表,一眼就能看明白：

对比项	虚拟IP（VIP）	浮动IP（FIP）
应用场景	物理服务器、传统IDC机房	云平台虚拟机、容器集群
核心协议	VRRP、心跳检测	云平台API控制
漂移方式	网卡上添加/移除IP	租户网路重定向路由
典型工具	keepalived、Heartbeat	简米云HAVIP、OpenStack Neutron
依赖条件	二层网络可达	云平台网络能力支持

什么时候你需要配置虚拟IP

• 我的Nginx负载均衡集群,不想让负载均衡器成为新的单点故障。
• 我的数据库层需要主从切换,希望应用连接字符串不用修改IP。
• 我想对游戏服务器、交易系统做高可用改造,同时不想改变客户端访问方式。
• 我买了两台广州机房的物理服务器,想用最少的投入实现故障自动转移。

keepalived配置虚拟IP的完整实操步骤

环境准备与前提条件

动手配置虚拟IP之前,必须确认几件事：

• 两台机器之间心跳线路要通畅，建议单独用一根交叉线连接,或者用一个独立的内网VLAN承载心跳包；
• 操作系统建议用CentOS 7.x或Ubuntu 20.04以上的版本，iptables防火墙要放行VRRP协议的组播地址224.0.0.18或单播地址；
• 确保VIP没有被其他设备占用,避免IP冲突；
• 准备一个已配置好的网卡接口，比如ens33,后续在它上面绑定VIP。

安装keepalived并修改配置文件

下面以两台机器为例，主节点叫node1，IP是192.168.1.10；备节点叫node2，IP是192.168.1.11，VIP是192.168.1.100。

第一台机器node1的/etc/keepalived/keepalived.conf这样写：

global_defs {
   notification_email {
     admin@example.com
   }
   router_id LVS_DEVEL
}
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.1.100/24 dev ens33 label ens33:1
    }
}

第二台机器node2的配置基本一致,改动三处：

• state MASTER改为BACKUP；
• priority 100改为priority 90；
• virtual_router_id、auth_pass必须保持一致,否则无法建立对等关系。

配置虚拟IP时有个常见的坑：virtual_ipaddress里的子网掩码和设备标签要认真核对，标签写错会导致VIP起不来，写完配置文件后,分别执行：

systemctl enable keepalived
systemctl restart keepalived
ip addr show

如果配置成功，你会在主节点的网卡上看到VIP：192.168.1.100出现在ens33:1中,而备节点此时不会有这个地址。

验证VIP漂移：Kill掉主节点进程

为了验证配置生效,你可以在主节点上主动停掉keepalived：

systemctl stop keepalived

数秒后，备节点会自动接管VIP,在备用节点上执行：

ip addr show ens33

你应该能看到192.168.1.100已经出现在备用节点的网卡上，整个切换过程一般只需要2至5秒，具体取决于advert_int的间隔设置，这是配置虚拟IP时最有成就感的时刻，相当于亲眼看着“门卫交接班”。

结合Nginx实现网站高可用

光有VIP还不够，主备节点上得都跑着服务才行，比如用Nginx承载网页，两台机器都需要安装并启动Nginx，keepalived只负责“这个IP现在归谁用”，不负责“你的网站业务有没有挂”，建议给keepalived配置一个检测脚本,比如检查Nginx进程是否存在：

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    fall 2
    rise 1
}

check_nginx.sh的内容大致是：

#!/bin/bash
if [ $(ps -C nginx --no-header | wc -l) -eq 0 ]; then
    systemctl stop keepalived
fi

这样当Nginx意外挂掉时，脚本会主动让keepalived“让位”，VIP漂移过去之后，备用节点的Nginx能立刻接管流量,从而实现业务层面的高可用。

云服务器上的虚拟IP怎么配？主流厂商的差别

简米云与酷番云的HAVIP配置路径

如果你用的是云服务器，配置虚拟IP的方式和物理机略有不同，云平台通常限制用户在实例内直接绑定VIP，而是通过控制台或API先创建一个高可用虚拟IP（HAVIP）,再绑定到两台服务器上。

• 登录简米云VPC控制台，创建HAVIP,选择VPC和交换机的可用区。

• 创建后，将HAVIP绑定到主实例,备用实例需要保持在同一可用区内。

• 在ECS实例内部，需要把VIP作为辅助IP手动添加到网卡上,命令是：

  ip addr add 192.168.2.50/24 dev eth0

  由于简米云的HAVIP默认不响应ARP，两端keepalived需要开启单播模式，指定对端IP,保证心跳能穿透VPC的隔离机制。

酷番云的操作异曲同工，但它的HAVIP绑定时会直接提示你是否同时绑定主备机器，多数情况下，同一账号下的同地域、同可用区服务器才能共享一个VIP,跨地域的云服务器之间无法配置虚拟IP。

物理机房与云上配置，哪个更复杂

• 物理机房的优势在于二层网络完全可控，VRRP组播常能直接生效,配置虚拟IP相对顺手。
• 云服务器存在虚拟化网络层限制，组播包支持有限制，必须开启单播模式,否则节点之间无法感知对方存活。
• 混合云场景就更复杂，需要把物理机和云主机放在同一个二层域里，条件苛刻,一般不推荐使用虚拟IP直接打通。

有个实际案例很常见：某公司在广州的IDC机房里有两台裸金属服务器，又在简米云上买了两台ECS，希望做一个跨机房的容灾切换，最终方案实际上是用了云解析的故障转移和数据库层的主从复制，并没有强行做跨机房虚拟IP，这属于配置虚拟IP时最容易陷入的误区，毕竟VIP漂移依赖二层网络，跨地域的网络延迟和广播域阻隔会带来很大风险,这个坑需要你特别注意。

虚拟IP配置后如何验证与排障

用三个指令快速检验配置效果

配置完成后别急着收工，以下三条命令是你日常巡检的核心工具,也比较适合新手入门：

ip addr show | grep 192.168.1.100
ping -c 3 192.168.1.100
tcpdump -i ens33 vrrp

第一条看VIP在哪台机器上，第二条看外部可达性，第三条直接观察VRRP广播包的收发状态，如果tcpdump能抓到你自己的VRRP包,说明keepalived进程在正常工作。

主备切换失败的常规排查思路

很多人卡在VIP不漂移这个问题上,建议按这个顺序排查：

• 先看state和priority是否写反了,这两项配置错误是出现概率最高的原因；
• 用systemctl status keepalived查看服务是否在运行,日志里有没有报错；
• 检查两台机器的防火墙，VRRP协议默认是组播，安全组或iptables策略要放行proto 112；
• 确认虚拟IP没有被偶然分配给其他进程，导致设备读取时提示“file exists”；
• 如果是云服务器，务必确认你确实开启了单播模式,并把对端IP加进了config文件。

虚拟IP配置后网络起不来得看网卡配置

很多时候VIP能配上去，但外部就是访问不通，问题可能出在反向路由过滤上，Linux内核默认的rp_filter机制会丢弃源地址不对称的报文,解决办法是调整内核参数：

sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2
sysctl -w net.ipv4.conf.all.rp_filter=0

这些参数让带有VIP的服务器在响应ARP请求时更精准，避免邻居节点因为路由混乱而丢包,这也是配置虚拟IP中比较容易忽视的细节。

虚拟IP不是万能的，这些局限你得知道

跨网段部署的致命缺陷

VRRP协议的组播报文是二层协议，理论上限定在同一广播域，一旦你的两台机器跨越了不同的VLAN或网段，VIP就无法正常漂移，即便配置单播模式，也只能解决点对点传输问题,网络层路由的不对称依然会引发切换故障。

高可用转移不代表业务无缝衔接

VIP漂移本质上是IP地址从A机器挪到B机器，但已建立的TCP连接会全部断开，那些正在处理中的数据库写操作，比如用户正在提交订单，也可能会失败，因此会采用VIP技术配合会话保持或消息队列缓冲来保证业务完整性,单纯依赖配置虚拟IP并不能覆盖所有故障场景。

一个容易被忽略的安全风险

VIP承载的是对外服务的入口，如果keepalived的认证密码（auth_pass）设置得太简单，同一网络内的其他主机可能会伪装成备用节点，欺骗主节点释放VIP，业内专家指出，生产环境建议把auth_type换成AH类型，并使用足够长的随机密码串,同时限制VRRP协议只从指定物理端口进入。

配置虚拟IP常见问题Q&A

配置虚拟IP需要单独购买服务器吗？

不需要，虚拟IP只是一个逻辑概念，不依赖额外硬件，你可以利用已有的两台服务器，只要它们的二层网络能够互通即可，如果是在云上，简米云和酷番云的HAVIP本身服务不收费，但绑定HAVIP的云服务器各自的计算资源费用得正常支付，配置虚拟IP的开销主要体现在服务器资源和运维精力上,比购买硬件负载均衡设备要省得多。

虚拟IP和负载均衡IP是同一样东西吗？

两者有关联但不等同，负载均衡IP通常是由负载均衡器实例独占的接入地址；而虚拟IP是一种可漂移的基础能力，它可以被负载均衡软件所绑定使用，反过来负载均衡器（例如LVS）又必须依托VIP地址对外提供服务，你可以把VIP理解为一个中性的资源,它的作用取决于上层怎么用它。

Windows Server能不能配置虚拟IP？

Windows Server原生不支持VRRP协议，因此无法直接套用keepalived方案，如果使用微软故障转移集群（Failover Clustering），它内部会创建集群IP，本质上是一种虚拟IP的实现方式，同时还搭配仲裁磁盘来防止脑裂，所以答案是：能配，但需要用微软自带的集群功能,而不是Linux社区的软件。