Nginx高可用集群实战：Keepalived+虚拟IP实现主备自动切换

1. 为什么要搭建Nginx高可用集群

1.1 单点故障的现实困境

很多人刚开始接触Nginx时，都是在单台服务器上部署，做反向代理、静态资源托管、负载均衡转发。这套玩法在开发环境和中小流量场景下没什么问题，但当它真正扛起生产流量时，一个最现实的问题就会浮出水面：这台Nginx挂了，整个服务入口也就没了。

我见过不少线上事故，Nginx所在服务器因为磁盘写满、内核参数被调崩、或者单纯是云服务商底层物理机维护导致重启，结果前端页面直接白屏，接口全部超时。最难受的是，这种故障往往不是业务代码的问题，而是基础设施层面的单点瓶颈。你明明有十台应用服务器在后面跑得好好的，却因为最前面这一台代理挂了，整个集群对外不可用。

这就是单点故障（Single Point of Failure）的本质：整个链路中只要有一个环节不具备冗余能力，它就成为整个系统的短板。而Nginx作为流量入口，承担着反向代理、负载均衡、SSL终止、静态资源响应等职责，它的可用性直接决定了用户能不能访问到你的服务。

所以，搭建Nginx高可用集群并不是“大公司才需要做的事”，而是任何对可用性有要求的业务都应该具备的基础能力。哪怕你的业务日活只有几千，一次Nginx宕机导致的半小时故障，也足以让口碑受损。

1.2 高可用集群能解决什么问题

高可用集群的核心目标只有一个：当集群中的某台机器出现故障时，系统能在尽可能短的时间内自动恢复服务，且对用户无感知或仅感知极短的闪断。

具体到Nginx场景，高可用集群要解决三个层面的问题：

• 自动故障转移：主节点宕机后，备用节点能自动接管流量，不需要人工登录服务器去改DNS、改路由或者手动切换。
• 入口IP的漂移：对外提供服务的入口地址（虚拟IP）不发生变化。客户端访问的还是同一个IP，但背后处理请求的物理机器已经悄悄换了。
• 健康感知与自愈：集群不仅能感知“进程死了”，还能感知“服务不可用”——比如Nginx进程还在，但后端应用全部超时，这时候也需要触发切换。

这三件事做扎实了，你的Nginx入口就从“一台机器”变成了“一台有备胎的机器”，可用性从单机的99.9%向集群的99.99%迈进。

1.3 Nginx高可用在整个架构中的位置

我们需要先理清一个概念：Nginx高可用集群不等于业务高可用。它解决的是入口层的冗余问题，而业务层的高可用还需要应用集群、数据库主从、缓存集群等共同配合。

以一个典型的Web架构为例：

用户 → DNS → 虚拟IP（VIP）→ Nginx主/备集群 → 应用服务器集群 → 数据库/缓存

在这个链路中，Nginx高可用集群处于流量入口的位置。它对外暴露一个虚拟IP（VIP），通过Keepalived等工具实现主备节点的自动切换。当主Nginx宕机时，备用Nginx自动绑定VIP并接管流量。

这里有一个很重要的认知：Nginx高可用集群不仅仅解决了“进程挂了”的问题，它还让整个架构具备了滚动升级的能力。比如你想升级Nginx版本，可以直接在备用节点上先升级、测试、然后主动触发切换，再把旧主节点升级。整个过程业务不中断，这就是高可用架构带来的额外红利。

明白了这些，我们下面直接进入实操。

2. 高可用集群的方案设计与环境准备

2.1 方案选型：Keepalived双机热备为什么是主流

Nginx高可用的实现方案有很多，常见的包括：

综合来看，Keepalived 双机热备是目前最主流的方案。为什么？因为它用最简单的机制解决了最核心的问题。

Keepalived基于VRRP（虚拟路由冗余协议）实现，多个节点在同一个虚拟组内竞选角色，Master节点持有VIP并对外提供服务，Backup节点持续监控Master的状态。一旦Master失联，Backup节点晋升为Master并绑定VIP。整个过程在秒级到毫秒级完成，配置也仅仅是几个文本文件。

我倾向使用Keepalived方案，还有一个原因是它的“无侵入性”——它不修改Nginx本身的任何行为，只是为Nginx加了一层“保护罩”。无论你用Nginx做反向代理、负载均衡还是静态服务器，Keepalived都能在旁边稳定地守护着。

2.2 环境规划与网络拓扑设计

在动手之前，先把环境规划好。以最常见的双节点主备架构为例：

在这个设计中，VIP不对应任何物理网卡，而是由Keepalived动态绑定在Master节点的网卡上。正常情况下，客户端访问192.168.1.100，实际请求被node1处理。当node1故障时，Keepalived在node2上自动绑定同一VIP，实现秒级切换。

网络层面的要求：

• 两节点之间需要能够互通，并且建议配置独立的心跳线路（比如单独的内网网卡或直连线），避免业务流量和心跳流量互相干扰。
• VIP需要和节点IP处于同一广播域内，这样Keepalived发送VRRP组播报文时才能被对端正常接收。
• 防火墙需要放行VRRP协议报文。Keepalived默认使用组播地址224.0.0.18，协议号为112。

操作系统方面，我建议使用同一版本的Linux发行版，避免底层网络栈行为不一致。如果在云环境下搭建，需要注意云厂商是否支持VRRP组播或需要改用单播模式，这也是后面要重点讲的内容。

2.3 核心原理解读：虚拟IP与健康检查

虚拟IP（VIP）的本质

虚拟IP的本质是：一个不属于物理网卡但被系统绑定到网卡上的IP地址。它和普通IP一样可以被路由、被访问，但绑定它的节点是可变的。

你可以把VIP理解成一个酒店的“前台电话号码”。客户只需要记住这一个号码，不管接待员今天是A还是B，只要电话能打通就行。Keepalived负责保证“电话永远有人接”——Master在，由Master接；Master不在，Backup自动接。

健康检查的两种层级

Keepalived对Nginx的健康检查分为两个层级：

• 进程级检查：Keepalived定期检查Nginx进程是否存在。如果进程不存在，就认为节点不健康。
• 服务级检查：通过自定义脚本主动访问Nginx的服务端口或健康检查URL，判断服务是否真正可用。

这两者的核心区别在于：nginx进程可能还活着，但工作进程已经死锁，端口已经不监听了。只靠进程检查发现不了这种问题。所以生产环境我强烈建议使用自定义脚本做服务级检查，后面会给出脚本模板。

掌握了这些原理，下面就是纯实操环节了。

3. 从零搭建Nginx高可用集群（完整实操）

3.1 基础准备：关闭防火墙干扰并统一环境

在开始安装之前，先把两个节点的系统基础环境统一起来。以下操作需要在两台机器上都执行。

配置主机名映射

# node1 上执行 hostnamectl set-hostname nginx-node1 # node2 上执行 hostnamectl set-hostname nginx-node2

然后在两台机器的/etc/hosts中添加：

192.168.1.10 nginx-node1 192.168.1.11 nginx-node2

主机名映射的作用是方便Keepalived配置中对端地址的解析，也方便后续排查问题时快速区分节点身份。

防火墙规则

如果开启了防火墙，需要放行Keepalived所需的VRRP协议和安全组端口。以firewalld为例：

# 放行VRRP协议（组播或单播） firewall-cmd --add-rich-rule='rule protocol value=112 accept' --permanent firewall-cmd --reload

也要确保Nginx的监听端口在防火墙规则中放行。如果用的是云主机，还要在安全组中确认同样的规则。

注意：防火墙配置是网络层面切换失败的最常见原因。如果你发现两台机器互相ping不通VIP、Keepalived收不到对方的VRRP报文，第一时间检查防火墙。

同步系统时间

使用chrony或ntpd同步两台机器的时间。VRRP报文带有时间戳信息，时间偏差过大会导致Keepalived认为对端状态异常。我在实际运维中遇到过因为系统时间差了5分钟，导致主备节点频繁误判切换的案例。

3.2 安装并标准配置Nginx

在node1和node2上分别安装Nginx。不同Linux发行版的安装命令不同，这里以常用的CentOS/RHEL系列为例：

# 安装Nginx（以EPEL源为例） yum install -y nginx # 或者使用官方源 rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.rpm yum install -y nginx

安装完成后，先做一份标准的反向代理配置，让两台Nginx都能正常代理后端的应用服务。以代理到本机的8080端口应用为例：

# /etc/nginx/conf.d/proxy.conf upstream backend_app { server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; # 如果有多个后端节点，在这里添加 # server 192.168.1.20:8080 max_fails=3 fail_timeout=30s; # server 192.168.1.21:8080 max_fails=3 fail_timeout=30s; } server { listen 80; server_name _; location / { proxy_pass http://backend_app; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } # 健康检查端点 location = /healthcheck { access_log off; return 200 "OK\n"; } }

这里留了一个重要的伏笔：我添加了一个/healthcheck端点。这个端点的作用是给Keepalived的健康检查脚本用的——它不依赖任何后端应用，如果Nginx本身正常，它就能返回200。这样我们就把“Nginx是否正常”和“后端应用是否正常”解耦了，避免后端应用偶发故障导致Nginx被误判为宕机。

验证Nginx配置并启动：

nginx -t systemctl start nginx systemctl enable nginx

启动后访问http://本机IP/healthcheck，如果看到OK，说明Nginx正常。

3.3 安装Keepalived

在node1和node2上分别安装Keepalived：

yum install -y keepalived

安装完成后，Keepalived的默认配置文件在/etc/keepalived/keepalived.conf，vrrp脚本目录在/etc/keepalived/下。我们先备份默认配置，再按下面的配置进行修改。

注意：Keepalived的配置语法很苛刻，变量名拼写错误、括号层级不对、行尾多了空格都可能导致服务启动失败。每次修改配置后，务必执行keepalived -t检查语法。

3.4 配置主节点（Master）

先来看node1的完整配置：

global_defs { router_id NGINX_HA_1 enable_script_security } vrrp_script check_nginx { script "/etc/keepalived/check_nginx.sh" interval 2 timeout 2 rise 2 fall 2 } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 nopreempt authentication { auth_type PASS auth_pass 1234 } unicast_src_ip 192.168.1.10 unicast_peer { 192.168.1.11 } virtual_ipaddress { 192.168.1.100/24 dev eth0 label eth0:0 } track_script { check_nginx } notify_master "/etc/keepalived/notify.sh MASTER" notify_backup "/etc/keepalived/notify.sh BACKUP" notify_fault "/etc/keepalived/notify.sh FAULT" }

这段配置的核心要点我来逐项拆解：

• vrrp_script段落定义了健康检查脚本，interval 2表示每2秒执行一次脚本，rise 2表示连续2次成功后节点才判定为健康，fall 2表示连续2次失败后判定为不健康。这个参数组合可以有效避免网络抖动带来的误判。
• state MASTER表示节点启动时以Master角色参与竞选。但注意，这个值只是初始状态。真正决定谁是Master的是priority值，值越大越优先。
• priority 100是主节点的优先级。备用节点需要设置一个更低的数值，比如90。
• virtual_ipaddress定义了VIP地址，label eth0:0表示将VIP绑定在网卡eth0的别名接口上。这样通过ip addr show能清晰地看到VIP是绑定在哪个物理网卡上的。
• nopreempt是一个容易被忽略但很重要的参数：它表示当Master从故障中恢复后，不主动抢占VIP。也就是说，只要备用节点还活着，VIP就继续留在备用节点上。这可以避免频繁的主备切换导致连接抖动。这个策略叫“非抢占模式”。

3.5 配置备用节点（Backup）

node2的配置和主节点几乎一致，只是改了三个关键值：

global_defs { router_id NGINX_HA_2 enable_script_security } vrrp_script check_nginx { script "/etc/keepalived/check_nginx.sh" interval 2 timeout 2 rise 2 fall 2 } vrrp_instance VI_1 { state BACKUP interface eth0 virtual_router_id 51 priority 90 advert_int 1 nopreempt authentication { auth_type PASS auth_pass 1234 } unicast_src_ip 192.168.1.11 unicast_peer { 192.168.1.10 } virtual_ipaddress { 192.168.1.100/24 dev eth0 label eth0:0 } track_script { check_nginx } notify_master "/etc/keepalived/notify.sh MASTER" notify_backup "/etc/keepalived/notify.sh BACKUP" notify_fault "/etc/keepalived/notify.sh FAULT" }

三个关键差异是：router_id、state BACKUP、priority 90。

需要强调一点：两个节点的virtual_router_id必须一致，这里都是51。这个ID是VRRP组播报文中的身份标识，两边的ID不一致，它们就不会认为彼此属于同一个虚拟路由器组，VIP就无法实现漂移。

3.6 编写健康检查与状态通知脚本

Keepalived之所以能实现“服务级健康检查”，靠的是它调用的外部脚本。现在我们来编写最关键的检查脚本。

在两台机器的/etc/keepalived/check_nginx.sh中写入：

#!/bin/bash # 定义检测URL，Nginx的本地健康检查端点 CHECK_URL="http://127.0.0.1/healthcheck" CHECK_PORT="80" # 检测Nginx端口是否存在 if ! /usr/sbin/ss -tln | grep -q ":$CHECK_PORT"; then exit 1 fi # 用curl获取HTTP状态码，判断服务是否可用 HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 2 --max-time 3 "$CHECK_URL" 2>/dev/null) if [ "$HTTP_CODE" = "200" ]; then exit 0 else exit 1 fi

赋予执行权限：

chmod +x /etc/keepalived/check_nginx.sh

脚本逻辑很简单：先检查端口是否在监听，再用curl请求健康检查端点。只有两个条件都满足，脚本才返回0，Keepalived才认为节点健康。

使用curl而不是直接检查进程，关键原因在于：网络协议栈可能已经异常，端口虽然listen但无法正常响应请求。直接检查进程发现不了这类半死不活的状态。

再编写通知脚本/etc/keepalived/notify.sh：

#!/bin/bash STATE=$1 case $STATE in MASTER) echo "$(date '+%Y-%m-%d %H:%M:%S') [notify] switch to MASTER, start logging..." >> /var/log/keepalived-notify.log # 这里可以扩展：告警通知、动态更新DNS、预热缓存等 ;; BACKUP) echo "$(date '+%Y-%m-%d %H:%M:%S') [notify] switch to BACKUP" >> /var/log/keepalived-notify.log ;; FAULT) echo "$(date '+%Y-%m-%d %H:%M:%S') [notify] enter FAULT state" >> /var/log/keepalived-notify.log ;; esac

赋予执行权限。这个脚本的价值在于：它把主备切换的瞬间记录下来，成为日后排查故障时最重要的时间线索。你可以在MASTER分支里追加企业微信/钉钉/邮件告警逻辑，让每次切换都能实时通知到人。

3.7 启动并验证集群

先在node1上启动Keepalived：

systemctl start keepalived systemctl enable keepalived sleep 5 ip addr show eth0

此时应该能看到eth0上多了一个eth0:0别名接口，IP为192.168.1.100。说明node1成功绑定了VIP。

然后在node2上执行同样操作，并用ip addr show eth0检查，正常情况下node2上是不会有VIP的。

验证VIP漂移的过程如下：

在node1上执行：

# 强制关闭Keepalived，模拟节点故障 systemctl stop keepalived

等待3-5秒，然后在node2上执行：

ip addr show eth0

如果配置正确，此时node2的eth0上已经出现了192.168.1.100的绑定信息。此时再用同一台客户端机器访问http://192.168.1.100/healthcheck，应该依然返回OK。

再启动node1的Keepalived，因为配置了nopreempt，VIP不会自动漂回node1，而是继续留在node2上。这个行为是符合预期的——非抢占模式就是为了避免切换抖动。

3.8 将Keepalived配置为开机自启

systemctl enable keepalived

同时我们需要确认一个细节：Keepalived和Nginx的启动顺序。如果服务器重启，理论上应该先启动Nginx，再启动Keepalived，因为Keepalived的健康检查脚本在Nginx不可用时会返回失败，节点无法绑定VIP。

但如果Nginx挂了而Keepalived还活着，健康检查脚本会连续失败，导致Keepalived降级为FAULT状态，VIP会漂移到备用节点。这个行为是我们需要的。问题在于：如果Nginx还没起来，Keepalived就起来了，节点无法立即接管VIP，会导致服务短暂不可用。

解决办法是在Keepalived的systemd服务中添加依赖关系：

# 编辑 /etc/systemd/system/keepalived.service.d/dependency.conf [Unit] After=nginx.service Requires=nginx.service

然后执行：

systemctl daemon-reload

4. 生产环境的高可用进阶与避坑指南

4.1 脑裂问题：最隐蔽的高可用杀手

脑裂（Split-Brain）是高可用集群中绕不开的话题。简单来说，当主备节点之间的心跳通信中断，但两个节点都认为对方已经死了，于是同时绑定VIP对外提供服务，造成IP冲突和流量分配混乱。

脑裂的产生条件非常苛刻：主节点本身是健康的，只是它发送的VRRP报文无法到达备用节点。常见诱因包括：

• 心跳线路物理断开或网络拥塞
• 交换机端口配置错误导致组播报文被丢弃
• 云环境中底层网络策略限制了组播
• 防火墙规则意外拦截VRRP

预防脑裂的手段主要有三层：

• 使用独立心跳线路：不要让心跳流量和业务流量共享同一链路。条件允许时用直连线或独立交换机连接两个节点。
• 配置单播而非组播：云环境特别推荐使用unicast_peer方式发送VRRP报文，绕开组播依赖。前文中已经配置了unicast_src_ip和unicast_peer，这正是针对云环境的适配。
• 引入仲裁机制（Fencing）：这是更高级的手段。当节点无法确认对端状态时，主动找第三方仲裁节点（如数据库或单独的探测机）确认对端状态，再决定是否接管VIP。Keepalived本身没有内置仲裁，可以通过notify_fault脚本结合外部探测来实现。

在实际生产环境中，我最常推荐的方案是：单播 + 独立心跳 + 仲裁探测脚本。三者配合可以把脑裂概率降到极低。

4.2 健康检查参数调优：避免切换过度敏感

很多人在配置健康检查时喜欢把interval设得很小，比如0.5秒，以为这样切换更快。但实际上，过于激进的检查策略会带来严重问题。

举个真实例子：某后端数据库因为GC停顿了2秒，导致后端应用接口响应超时，结果Nginx的健康检查脚本也超时了。生产上有两个节点都健康，但因为健康检查脚本短暂超时，Keepalived误判Master故障，触发了VIP切换。切换过程中，部分TCP连接被中断，反而影响了业务。

调优的核心原则是：健康检查的灵敏度要匹配后端服务的抖动容忍度。

对于严格依赖单点状态的服务，可以把fall设小一点；对于允许短暂抖动的服务，建议fall设2-3次，interval设2秒，这样整体故障切换时间在4-6秒左右，对大部分业务是完全可以接受的。

4.3 会话保持与数据一致性的补充说明

Nginx + Keepalived高可用集群解决了“入口可用性”的问题，但有一个很容易被忽略的坑：如果后端只有一台应用服务器，Nginx高可用只是把“入口挂了”变成了“入口没挂”，当实际调后端时还是只有一个后端节点。

你在做Nginx高可用架构时，必须明确两个层面的高可用是独立的：

• 入口层高可用由Keepalived保障
• 业务层高可用由应用集群 + 数据库主从等保障

另外，如果业务有会话保持需求，Nginx配置了ip_hash或sticky会话模块，那么在主备Nginx切换时，会话信息并不会自动同步到备用节点。这意味着用户可能被重新分配到新的后端节点，如果后端没有做Session共享，用户会突然掉线。

解决方案有两种：

• 后端应用做Session外置，存储到Redis或数据库中
• 使用Nginx的sticky模块，将用户会话绑定到同一后端节点，并配合后端Session复制

我在实际项目中倾向于前者，因为Session外置的扩展性更好，与高可用架构的配合也更自然。

4.4 高频故障速查表

这张速查表是我在多次排障中沉淀下来的高频项。实际线上故障大多数不会超出这个范围。

5. 个人实操体会与扩展建议

5.1 我踩过的最深的坑

如果只能分享一条经验，我想说：不要在主备节点上手工修改Nginx配置文件，一定要引入配置同步机制。

我遇到过这样一次事故。某天晚上需要临时加一个API的反向代理规则，我直接在当时的Master节点上改了配置并reload，当时一切正常。第二天早高峰时Master机器因硬件告警重启，VIP漂移到Backup节点上——结果Backup节点上根本没有我昨晚新加的规则，映射到新API的流量全部502。用户端表现为部分接口不可用，排查了接近二十分钟才发现是配置不一致的问题。

从那之后，我就建立了三个习惯：

• 所有Nginx配置纳入版本管理，通过配置同步脚本（如rsync或ansible）在两个节点间自动同步。
• 每次配置变更后，在两台机器上都执行nginx -t验证语法。
• 每隔一段时间主动做一次主备切换演练，确保备用节点真的能扛起流量。

主备切换演练尤其重要。很多高可用集群看着配置完美，但从未实际切换过。等到真正需要切换时，才发现备用节点连VIP都抢不过来。我建议至少每季度做一次主动切换演练。

5.2 后续扩展方向

搭建完这套Nginx高可用集群之后，你的架构已经具备了一定的容灾能力。但如果流量继续增长，可以考虑以下几个扩展方向：

• 多节点集群：Keepalived天然支持一主多备模式，你可以在配置文件中添加多个BACKUP节点，进一步提高可用性。需要注意的是，Keepalived的VRRP组播模式下多节点要合理规划优先级。
• 混合云架构：不同云厂商或自建机房之间，VIP方案可能受制于网络环境。可以考虑把Keepalived与全局负载均衡（如DNS GSLB）结合，实现跨机房的高可用。
• Nginx配置自动化：当Nginx实例越来越多时，手工维护配置文件会变得非常痛苦。可以引入Ansible、SaltStack等自动化工具管理Nginx和Keepalived的部署与配置。
• 可观测性建设：给Keepalived的切换事件增加告警、日志采集、甚至自动化工单创建。高可用不只是“能切换”，还要“知道什么时候切换了、为什么切换”。

最后分享一个我自己非常受用的习惯：每次搭建完高可用集群，我都会在手机备忘录里记一笔“切换演练操作清单”，内容包括停哪个服务、观察什么指标、如何回滚。这个清单在真正出故障时，能帮你省下最宝贵的十分钟。

高可用架构的核心从来不是“配置一套看起来很完美的集群”，而是“在出问题时能冷静、快速、正确地处理”。希望这篇实操笔记能帮你在搭建Nginx高可用集群的路上少踩一些坑。