Nginx双机主备高可用：Keepalived+VIP漂移实战与避坑指南-北京尧图网络

1. 为什么单台Nginx扛不住双机主备到底在解决什么问题很多团队在项目初期都习惯把Nginx往一台机器上一装配好反向代理和负载均衡就完事了。流量小的时候确实没问题单机跑个几千QPS跟玩似的。但一旦业务上了规模或者对可用性有硬性要求单机Nginx就成了整个链路里最要命的单点。它一挂后面所有后端服务全部失联用户看到的就是502或者连接超时这种事故的杀伤力比数据库宕机还大因为它是整个流量的入口。我经历过一次线上事故凌晨两点一台跑了两年多的Nginx服务器磁盘突然写满日志把分区撑爆了Nginx进程直接僵死。后端十几台应用服务器全都健康但外面一个请求都进不来。那次之后我就下定决心所有生产环境的Nginx必须做高可用没有商量余地。双机主备的核心思路其实很朴素准备两台配置完全一致的Nginx服务器一台作为主节点Master对外提供服务另一台作为备节点Backup随时待命。主节点正常工作时备节点什么都不干就在那儿盯着。一旦主节点出问题——不管是Nginx进程挂了、服务器宕机了、还是网络不通了——备节点要在秒级时间内接管主节点对外提供服务的IP地址继续为用户的请求服务。整个过程对用户来说基本无感知最多就是几秒钟的抖动。这里的关键在于“对外提供服务的IP地址”这个说法。在双机主备架构里我们不会让用户直接访问某台服务器的真实IP而是使用一个虚拟IPVIPVirtual IP。这个VIP平时绑定在主节点上主节点通过它来接收和转发请求。当主节点故障时备节点通过某种机制把VIP抢过来绑到自己身上然后开始接管流量。这个“某种机制”就是Keepalived。Keepalived这个工具说白了就是干两件事第一通过VRRP协议Virtual Router Redundancy Protocol虚拟路由冗余协议在多个节点之间选举出一个主节点并让VIP漂移到主节点上第二通过健康检查脚本监控Nginx的运行状态一旦发现异常就触发VIP漂移。它本身非常轻量配置也不复杂但效果极其可靠是业界做Nginx高可用最主流的方案之一。这套方案适合哪些人参考如果你手里有至少两台服务器业务对可用性有要求又不想引入太重的负载均衡硬件或者云厂商的LB服务那KeepalivedNginx双机主备就是性价比最高的选择。它不需要额外购买商业软件配置维护成本低原理也足够透明出了问题你能自己排查。下面我就把这套方案的完整落地过程拆开来讲包括我踩过的坑和总结出来的经验。2. 整体架构设计与核心组件选型思路2.1 双机主备的拓扑结构长什么样先把这个架构的物理拓扑说清楚。假设你有两台服务器我们叫它们Node-A和Node-B。两台机器上都要安装Nginx和KeepalivedNginx的配置文件保持完全一致包括反向代理规则、负载均衡策略、日志格式等等。这一点非常重要因为备节点接管之后它要能无缝地按照同样的规则处理请求如果配置不一致接管后就会出现各种诡异问题。两台服务器各有一个真实IP比如Node-A是192.168.1.10Node-B是192.168.1.11。然后我们申请一个虚拟IP比如192.168.1.100这个VIP就是对外服务的地址。用户、DNS解析、上游系统全部指向这个VIP它们根本不知道背后有几台机器也不需要知道。正常状态下Keepalived通过VRRP协议选举Node-A为MasterVIP绑定在Node-A的网卡上。Node-A上的Nginx接收所有请求按照配置转发给后端应用服务器。Node-B作为Backup处于待命状态它的Keepalived进程持续接收Node-A发来的VRRP心跳包。如果Node-B在连续几个心跳周期内没有收到Node-A的消息就认为Node-A挂了于是自己升级为Master把VIP绑到自己的网卡上同时启动或继续运行Nginx开始接管流量。这里有一个细节值得展开说备节点上的Nginx是提前启动好还是故障时才启动两种做法都有。提前启动的话备节点的Nginx一直在跑只是没有VIP所以收不到外部请求相当于热备。故障切换时只需要漂移VIPNginx不用重新启动切换速度更快。另一种做法是备节点Nginx不启动Keepalived检测到故障后先启动Nginx再漂移VIP。我推荐第一种因为Nginx启动虽然快但在高并发场景下冷启动的那几秒可能会丢请求热备更稳妥。2.2 为什么选Keepalived而不是其他方案做Nginx高可用的方案不止一种常见的有Keepalived、Heartbeat、CorosyncPacemaker还有云厂商提供的负载均衡服务。我选Keepalived的理由很直接轻量、简单、可靠。Heartbeat和CorosyncPacemaker功能更强大支持多节点集群、资源组管理、复杂的依赖关系但它们的配置复杂度也高出一个量级。对于双机主备这种场景你根本用不到那么重的功能引入它们反而增加了维护成本和出错概率。Keepalived专注做一件事——VRRP选举和VIP漂移——而且做得非常好配置文件几十行就能搞定排查问题也直观。另一个考虑是Keepalived对Nginx的健康检查支持很灵活。它可以通过vrrp_script定义自定义检查脚本你可以在脚本里用curl检查Nginx是否正常响应也可以用killall -0检查进程是否存在甚至可以根据业务需求写更复杂的逻辑。这种灵活性是很多商业方案不具备的。至于云厂商的LB服务如果你的服务器都在同一家云上用他们的LB确实省事。但很多公司的服务器是混合云或者自建机房跨环境的情况下自建Keepalived方案更可控。而且从成本角度算一台最低配的云服务器跑KeepalivedNginx一年也就几百块比LB实例便宜不少。2.3 VRRP协议的工作原理与关键参数VRRP协议是Keepalived的底层机制理解它的工作方式对排查问题很有帮助。VRRP把多台服务器组成一个虚拟路由器组组内有一个Master和若干Backup。Master定期向组内广播VRRP通告包告诉其他成员“我还活着”。Backup收到通告包后重置自己的计时器继续等待。如果Backup的计时器超时了还没收到通告包就认为Master挂了触发选举。选举的依据是优先级priority。优先级高的节点成为Master优先级范围是0到255数值越大优先级越高。默认情况下如果两台机器优先级相同真实IP地址大的那个会成为Master。实际配置中我们通常给主节点设100备节点设90留出足够的差值避免网络抖动导致频繁切换。通告间隔advert_int默认是1秒意味着Master每秒发一次心跳。备节点的超时时间大约是3倍通告间隔也就是3秒左右。也就是说从主节点故障到备节点接管最快也要3秒左右。这个切换速度对于大多数业务来说是可以接受的但如果你的业务对延迟极其敏感可以适当调小通告间隔比如设成0.5秒但也不能太小否则网络稍微抖动就会误判。还有一个重要参数是nopreempt非抢占模式。默认情况下Keepalived是抢占模式如果原来的Master恢复了它会重新抢回VIP。这在某些场景下会导致问题——比如主节点因为短暂网络抖动被备节点接管网络恢复后主节点又抢回来这一来一回就是两次切换对业务有影响。非抢占模式下备节点接管后就不会主动归还VIP除非备节点也出问题。我一般建议在配置中加上nopreempt减少不必要的切换。3. 环境准备与基础配置实操3.1 服务器初始化与依赖安装假设你已经有两台干净的服务器操作系统是主流的Linux发行版。第一步是做一些基础的系统配置。关闭SELinux和防火墙或者至少放行VRRP协议所需的IP协议号112。VRRP不是基于TCP或UDP的它直接使用IP协议号112所以普通的端口放行规则对它无效。如果你用firewalld需要执行firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 --protocol vrrp -j ACCEPT firewall-cmd --reload如果用iptables对应的规则是iptables -A INPUT -p vrrp -j ACCEPT这一步很多人会忽略结果配置看起来都对但VIP就是漂移不了排查半天才发现是防火墙把VRRP包拦了。接下来安装Nginx和Keepalived。不同发行版的包管理命令不一样以常见的两种为例# Debian/Ubuntu系 apt update apt install -y nginx keepalived # RHEL/CentOS系 yum install -y epel-release yum install -y nginx keepalived安装完成后先别急着配Keepalived把Nginx的基础配置调通。两台机器的Nginx配置要完全一致你可以先在一台上配好然后scp到另一台。配置内容根据你的实际业务来核心是upstream和server块。这里不展开Nginx的具体业务配置重点放在高可用部分。3.2 网络参数调整与内核优化在配置Keepalived之前有几个系统参数需要调整。首先是IP转发和ARP相关的内核参数。因为VIP漂移涉及到ARP广播如果ARP缓存更新不及时可能会导致部分客户端仍然把请求发到旧的主节点上。我们需要调整ARP相关的参数来加快收敛# 编辑 /etc/sysctl.conf加入以下内容 net.ipv4.conf.all.arp_ignore 1 net.ipv4.conf.all.arp_announce 2 net.ipv4.conf.default.arp_ignore 1 net.ipv4.conf.default.arp_announce 2 net.ipv4.conf.lo.arp_ignore 1 net.ipv4.conf.lo.arp_announce 2这几个参数的含义简单解释一下。arp_ignore设为1表示只回答目标IP是本机IP的ARP请求不回答其他IP的。arp_announce设为2表示发送ARP请求时使用最合适的本地地址而不是随便用一个。这样配置的目的是确保VIP漂移后新的主节点能正确地对外宣告VIP同时旧的主节点不会继续响应VIP的ARP请求。改完之后执行sysctl -p让配置生效。这一步做完基础环境就准备好了。3.3 Nginx健康检查脚本的编写要点Keepalived本身只能检测自己的进程状态它不知道Nginx是否正常工作。所以我们需要写一个健康检查脚本让Keepalived定期执行根据脚本的返回值来判断Nginx是否健康。脚本的逻辑很简单用curl访问Nginx的一个本地健康检查接口如果返回200就认为正常否则认为异常。Nginx配置里可以加一个location专门用于健康检查location /health { access_log off; return 200 OK; }然后写检查脚本放到/etc/keepalived/check_nginx.sh#!/bin/bash # 检查Nginx进程是否存在 if ! killall -0 nginx 2/dev/null; then exit 1 fi # 检查Nginx是否能正常响应 if ! curl -s -o /dev/null -w %{http_code} http://127.0.0.1/health | grep -q 200; then exit 1 fi exit 0这个脚本先检查进程再检查响应。为什么要两步因为有时候Nginx进程还在但已经僵死了不响应请求。只检查进程会漏掉这种情况。脚本要加执行权限chmod x /etc/keepalived/check_nginx.sh注意脚本里的curl命令一定要加超时参数比如--connect-timeout 2 --max-time 3否则Nginx卡死时curl会一直等导致Keepalived误判。这个坑我踩过当时Nginx响应极慢但没有完全挂curl等了30秒才返回Keepalived以为脚本还在执行迟迟不触发切换。4. Keepalived核心配置与VIP漂移实现4.1 主节点配置文件逐行拆解Keepalived的主配置文件是/etc/keepalived/keepalived.conf。主节点Node-A的配置大概长这样global_defs { router_id nginx_master script_user root enable_script_security } vrrp_script check_nginx { script /etc/keepalived/check_nginx.sh interval 2 weight -20 fall 2 rise 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 MySecurePass123 } virtual_ipaddress { 192.168.1.100/24 dev eth0 } track_script { check_nginx } }逐段解释一下。global_defs里的router_id是一个标识主备节点要设成不同的值方便日志里区分。script_user指定执行脚本的用户enable_script_security是一个安全选项确保脚本以指定用户运行。vrrp_script定义了一个健康检查脚本。interval 2表示每2秒执行一次。weight -20是关键当脚本返回失败时当前节点的优先级会减去20。主节点优先级是100减去20变成80低于备节点的90于是触发切换。fall 2表示连续失败2次才认为真的故障rise 2表示连续成功2次才认为恢复。这两个参数是为了防止网络抖动导致的误判。vrrp_instance是核心配置。state MASTER表示初始状态是主节点但注意这只是初始状态实际角色由选举决定。interface指定VIP绑定在哪块网卡上这个要根据你的实际网卡名来填用ip addr命令可以查看。virtual_router_id是一个0到255之间的数字同一个VRRP组内的所有节点必须一致。priority是优先级主节点设100备节点设90。advert_int是心跳间隔1秒。nopreempt表示非抢占模式。authentication是认证配置主备节点必须一致。auth_pass是密码最多8个字符。虽然VRRP认证安全性有限但至少能防止配置错误的节点加入组。virtual_ipaddress定义VIP格式是IP/掩码 dev 网卡名。track_script引用前面定义的健康检查脚本。4.2 备节点配置的差异点与注意事项备节点的配置和主节点几乎一样只有几个地方不同global_defs { router_id nginx_backup script_user root enable_script_security } vrrp_instance VI_1 { state BACKUP priority 90 # 其他配置与主节点一致 }router_id改成不同的值state改成BACKUPpriority改成90。其他所有配置——virtual_router_id、auth_pass、virtual_ipaddress、track_script——必须和主节点完全一致。任何一处不一致都可能导致VRRP组无法正常建立VIP漂移失败。注意备节点的Nginx也要提前启动好并且配置和主节点完全一致。我见过有人备节点Nginx没启动Keepalived切换后VIP漂移过去了但Nginx没跑请求全部拒绝。所以部署时一定要确认两台机器的Nginx都在运行状态。配置完成后在两台机器上分别启动Keepalivedsystemctl start keepalived systemctl enable keepalived然后在主节点上执行ip addr应该能看到VIP绑定在eth0上。在备节点上执行同样的命令看不到VIP。这时候用另一台机器ping VIP应该能通。整个双机主备的基础架构就搭起来了。4.3 验证VIP漂移的完整测试流程配置写完不代表就完事了必须做完整的切换测试。我一般按以下步骤来验证第一步确认初始状态。在主节点执行ip addr看到VIP在备节点看不到VIP。用curl访问VIP能正常拿到后端响应。第二步模拟Nginx故障。在主节点上执行systemctl stop nginx然后观察备节点。大约2到4秒后备节点应该能看到VIP同时curl访问VIP仍然能拿到响应。这一步验证的是健康检查脚本和VIP漂移是否正常工作。第三步恢复主节点Nginx。执行systemctl start nginx由于配置了nopreemptVIP不会漂移回主节点仍然在备节点上。这是预期行为。第四步模拟整机故障。在主节点上执行systemctl stop keepalived或者直接关机备节点应该在3秒左右接管VIP。第五步恢复主节点。启动Keepalived后由于nopreemptVIP仍然在备节点上。如果你希望主节点恢复后能抢回VIP就去掉nopreempt但我不推荐这么做。每次测试都要用curl或者浏览器实际访问VIP确认业务没有中断。光看VIP漂移了还不够要确认Nginx真的在服务。5. 常见故障排查与实战避坑经验5.1 VIP漂移失败的高频原因排查表VIP漂移失败是最常见的问题原因可能有很多。我整理了一个排查表按可能性从高到低排列现象可能原因排查方法解决方案备节点始终看不到VIPVRRP组未建立查看/var/log/messages中Keepalived日志检查virtual_router_id和auth_pass是否一致主节点故障后备节点不接管健康检查脚本未生效手动执行脚本看返回值检查脚本权限和路径确认track_script引用正确VIP漂移后无法访问ARP缓存未更新在客户端arp -a查看VIP对应的MAC调整arp_ignore和arp_announce参数频繁切换网络抖动或脚本误判查看Keepalived日志中的切换记录增大fall和rise值调整advert_int双主同时存在防火墙拦截VRRP包检查IP协议112是否放行添加防火墙规则放行VRRP备节点接管后请求502备节点Nginx配置不一致对比两台机器的Nginx配置确保配置完全一致并提前启动Nginx这张表基本覆盖了我遇到过的所有情况。其中最常见的是防火墙拦截VRRP包和健康检查脚本权限问题。前者表现为两台机器都认为自己是MasterVIP同时绑在两边这时候访问VIP会时通时不通。后者表现为脚本手动执行正常但Keepalived执行就失败通常是脚本没有执行权限或者路径写错了。5.2 脑裂问题的成因与预防措施脑裂是双机主备架构里最危险的情况主备节点都认为自己是MasterVIP同时绑定在两台机器上。这会导致请求被随机分发到两台Nginx上如果后端会话没有共享用户就会遇到登录状态丢失、购物车清空等问题。脑裂的成因通常是主备之间的心跳网络断了但两台机器本身都正常运行。备节点收不到主节点的心跳以为主节点挂了就自己升级为Master。而主节点那边觉得自己好好的继续持有VIP。结果就是双主。预防脑裂有几个手段。第一确保心跳网络可靠最好用独立的网线或者VLAN走心跳流量不要和业务流量混在一起。第二配置双路心跳Keepalived支持多个通信通道一路断了还有另一路。第三在健康检查脚本里加入对端检测比如ping一下对端的真实IP如果对端可达但VRRP心跳不通就说明是心跳网络问题这时候不应该贸然接管。Keepalived本身也提供了一些防脑裂的机制比如unicast_peer配置可以指定单播心跳的对端地址避免组播被网络设备拦截。在跨网段或者云环境中组播经常被限制这时候就必须用单播模式unicast_src_ip 192.168.1.10 unicast_peer { 192.168.1.11 }主节点和备节点都要配src_ip是自己的真实IPpeer是对端的真实IP。5.3 日志分析与问题定位技巧Keepalived的日志默认输出到/var/log/messages或者/var/log/syslog具体取决于系统配置。我习惯把Keepalived的日志单独拆出来方便排查。在/etc/sysconfig/keepalived里可以配置日志参数或者在rsyslog里加一条规则# 在/etc/rsyslog.conf中加入 local0.* /var/log/keepalived.log然后在Keepalived配置的global_defs里加global_defs { log_facility local0 }这样Keepalived的日志就单独写到/var/log/keepalived.log了。日志里会记录VRRP状态变化、脚本执行结果、VIP漂移等关键事件。比如看到“Entering BACKUP STATE”就知道节点进入了备状态“VRRP_ISUP”表示VRRP组建立成功。切换时会有“Master down”或者“Backup transition”之类的记录结合时间戳可以精确判断切换耗时。我排查问题时习惯先看日志时间线确认切换是几点几分发生的然后对照业务监控看那个时间点有没有异常。如果日志显示切换了但业务没恢复问题就在Nginx或者后端不在Keepalived。5.4 性能调优与长期运行建议双机主备跑起来之后还有一些调优和运维的细节值得注意。首先是健康检查脚本的执行频率。interval设成2秒是比较平衡的值太频繁会增加系统负载太慢会延长故障发现时间。如果你的业务对切换时间极其敏感可以设成1秒但要确保脚本本身执行够快不要超过1秒。其次是Nginx的keepalive连接。VIP漂移后原来的TCP连接会断开客户端需要重新建立连接。如果Nginx配置了较长的keepalive_timeout客户端可能会在旧连接上等待超时。建议把keepalive_timeout设成比较短的值比如15秒让客户端尽快感知到连接断开并重连。还有一点是监控。双机主备本身是高可用方案但你不能等它出问题了才发现。要对VIP的可达性、Nginx的健康状态、Keepalived的进程状态都做监控。我一般用简单的shell脚本配合cron每分钟检查一次VIP是否可达不可达就告警。更完善的方案是接入现有的监控系统把Keepalived的状态作为自定义指标上报。最后说一个我踩过的坑证书和密钥的同步。如果Nginx配置了HTTPS主备节点的证书文件必须完全一致。我遇到过备节点证书过期了但主节点没过期的情况切换后HTTPS全部报错。后来我把证书更新加入了部署流程每次更新证书两台机器一起更新并且用md5校验确保一致。这个细节看起来小但真出问题的时候很致命。6. 进阶扩展与生产环境加固思路6.1 从双机主备到多机集群的演进路径双机主备解决了单点问题但备节点平时是闲置的资源利用率不高。如果业务继续增长可以考虑演进到更复杂的架构。一种常见的做法是双主互备两台机器同时持有不同的VIP互为备份。比如Node-A持有VIP1作为主同时作为VIP2的备Node-B持有VIP2作为主同时作为VIP1的备。这样两台机器的资源都得到了利用任何一台挂了另一台都能接管它的VIP。再进一步就是多机集群用LVS或者HAProxy做四层负载均衡后面挂多台Nginx。Keepalived仍然负责VIP的高可用但VIP后面是一个负载均衡器集群。这种架构的复杂度和维护成本都高不少适合流量规模很大的场景。对于大多数中小型项目双机主备已经足够没必要过度设计。6.2 配置版本管理与自动化部署双机主备的配置一致性是个持续性的挑战。今天你改了一台机器的Nginx配置忘了同步到另一台下次切换就出问题。解决办法是把配置纳入版本管理用Git或者SVN管理Nginx和Keepalived的配置文件。每次修改都走提交、审核、发布的流程发布时用Ansible或者简单的shell脚本批量推送到两台机器。我自己的做法是在Git仓库里维护一份配置模板用变量区分主备节点的差异部分比如router_id和priority部署时用脚本渲染模板并分发。这样既保证了配置的一致性又保留了必要的差异。部署脚本还会自动执行nginx -t检查配置语法语法不通过就不发布避免把错误配置推上去。6.3 安全加固与访问控制要点Keepalived的VRRP认证密码是明文传输的安全性有限。在生产环境中除了设置auth_pass还应该限制VRRP通信的网络范围确保只有主备节点之间能交换VRRP包。如果条件允许把心跳网络隔离到独立的VLAN或者专用网卡上减少被干扰的风险。Nginx本身的安全配置也很重要。VIP是对外暴露的Nginx上要配置好访问控制、限流、防DDoS等策略。Keepalived的健康检查接口/health不要暴露到公网只允许本地访问。可以在Nginx配置里加allow 127.0.0.1; deny all;来限制。另外Keepalived的配置文件权限要控制好auth_pass不要泄露。建议把配置文件权限设为600只有root可读。脚本文件也一样避免被其他用户篡改。这套双机主备方案我从几年前开始用中间经历过几次真实的故障切换每次都能在几秒内完成业务基本无感知。最惊险的一次是主节点服务器电源故障直接断电备节点在3秒内接管用户端只感受到了一次短暂的请求重试。如果没有这套机制那次事故至少是半小时以上的服务中断。所以说对于任何对可用性有要求的业务Nginx双机主备都是值得投入时间搭建的基础设施。配置本身不复杂关键是理解原理、做好测试、持续维护。

Nginx双机主备高可用：Keepalived+VIP漂移实战与避坑指南

相关推荐

跨时钟域亚稳态详解：从D触发器原理到同步器设计与MTBF量化

CAN与CAN-FD总线深度解析：从物理层到工程实战的硬实时通信之道

ARM Cortex-A9体系结构深度解析：工作状态、运行模式与存储格式

更多资讯

Agent外挂记忆系统实战：从原理到接入Mem0的完整指南

Matpower 8.0安装与工程级潮流计算实战指南

Cursor 搭配 Graphify 实属强强联合了：把 Base URL 改到 TaoToken 的完整配置

Agent落地实践：上下文窗口、记忆分层与MCP协议全解析

工作流进化论：从静态DAG到AI语义路由编排

技术方案权衡章节写作指南：如何通过竞品替代分析证明当前架构选型的必然性

今日更新

Susi AI API实战指南：susi_alexa_skill如何用Node.js调用chat.json获取智能回答

换新电脑了？KeyStats 恢复码数据找回完全指南，端到端加密统计一键重建

重建二叉树：由前序与中序遍历序列还原二叉树的原理与 Java 实现（YCBlogs 剑指 Offer 精讲）

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？