Nginx+Keepalived高可用负载均衡集群搭建实战

1. 方案设计与核心原理

先聊点实在的。最近一两年，我在帮几个业务方做服务架构梳理时，频繁遇到同一个诉求：Nginx 作为入口负责负载均衡，但 Nginx 自身挂了怎么办？单点故障不解决，后端服务做得再稳，入口一断全部白搭。

所以就有了这篇东西的主角组合：Nginx 负责流量分发，Keepalived 负责探活和虚拟 IP 漂移。两者配合，构成一套经典的主备高可用负载均衡集群。下面详细拆解我实际搭建这套集群的完整过程，以及过程中踩过的坑、做过的取舍。

1.1 核心需求解析：为什么是 Nginx + Keepalived

先定义清楚目标。我们要解决的，是两个完全不同层面的问题：

• 负载均衡（Load Balancing）：多台后端 Web 服务器分摊请求压力，避免单台机器过载，同时隐藏后端真实 IP。
• 高可用（High Availability）：当某台负载均衡器自身宕机或 Nginx 进程异常退出时，集群能在秒级内自动切换，让业务不中断。

Nginx 解决第一个问题，Keepalived 解决第二个问题。两者是通过虚拟 IP（VIP）机制结合在一起的——两台 Nginx 服务器组成一个主备对，共享一个 VIP；正常情况下 VIP 绑定在主节点上，客户端请求走主节点；主节点异常后，Keepalived 通过 VRRP 协议把 VIP 自动漂移到备用节点，备用节点的 Nginx 无缝接管流量。

为什么不直接用 DNS 轮询或者硬件负载均衡？DNS 轮询的问题在于生效时间不可控，客户端 DNS 缓存可能把请求继续打到已宕机的 IP；硬件负载均衡（比如 F5）效果好，但价格不是所有团队都能接受。Nginx 加 Keepalived 这套组合，用两台普通服务器就能实现 99.9% 级别的入口可用性，性价比极高，这也是它至今仍是中小团队主流方案的根本原因。

1.2 高可用集群的角色分配与架构规划

在动手安装前，先把集群拓扑和信息规划列清楚。我这次实际搭建的环境是三台机器：

之所以强调先把 IP 规划写清楚，是因为我在早期部署时吃过亏——当时随手选了个网段内已被 DHCP 分配的地址当 VIP，配置完成后死活漂移不过去，排查了半天才发现是 IP 冲突。所以这里先提醒一句：VIP 必须使用网段内空闲且不会被 DHCP 自动分配的地址，最好在路由器或 DHCP 服务器上做静态保留。

后端 Web 服务器我建议至少准备两台，这样才能验证负载均衡的真实效果。如果一时只有一台后端，也能完成 LB 层面的大部分验证，但建议尽快补足两台。

Keepalived 的配置核心是 VRRP（虚拟路由冗余协议）实例，通过优先级（priority）决定谁当主、谁当备。priority 数值越大，成为主节点的可能性越高。这里我用的是最基础的一主一备模式，不启用 nopreempt，也就是说主节点恢复后，VIP 会重新漂移回来。这个行为在某些场景下可能不是理想的，后面我会单独讲。

2. 基础环境准备：Ubuntu 24.04 系统配置与网络调优

系统层面如果一开始不弄干净，后面配置 Nginx 和 Keepalived 时容易出现各种莫名其妙的问题。这一节讲的都是我在多次部署中总结出的“最小必要操作”，不搞花活，但每一条都有明确目的。

2.1 系统更新与主机名规划

拿到一台全新的 Ubuntu 24.04 服务器，第一件事是更新软件源和系统包。这一步不是为了“赶时髦装新版”，而是确保后续 apt 安装时能拉到最新版本的安全补丁和依赖库：

bash复制sudo apt update && sudo apt upgrade -y

接着设置主机名。为什么主机名重要？Keepalived 在日志和状态切换记录中会输出主机名，如果两台 LB 主机名一样，排查故障时你会怀疑人生：

bash复制sudo hostnamectl set-hostname lb01
# 备节点执行：sudo hostnamectl set-hostname lb02

然后编辑 /etc/hosts，把集群内所有节点的解析关系写进去。这一步虽然不是必须的，但强烈建议做——后面配置 Nginx upstream 时，直接用主机名代替 IP，配置可读性和可维护性会好很多：

bash复制192.168.1.10 lb01
192.168.1.11 lb02
192.168.1.20 web01
192.168.1.21 web02

2.2 网络参数基础配置

Ubuntu 24.04 默认使用 Netplan 管理网络。你需要注意一个细节：如果服务器上有多个网卡，要确认 Keepalived 的 VRRP 通告走的是哪个网卡，VIP 绑定在哪个网卡上。我一般会提前给网卡设置静态 IP，避免 DHCP 分配导致 IP 变化。

我的 /etc/netplan/01-netcfg.yaml 配置大致如下：

yaml复制network:
  version: 2
  ethernets:
    ens18:
      addresses:
        - 192.168.1.10/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 192.168.1.1

应用配置：

bash复制sudo netplan apply

注意，修改网卡配置如果格式写错，会直接导致网络中断，所以建议通过本机或带外管理方式操作，避免把自己锁在门外。

另外，如果你用的是云服务器，还需要在安全组和防火墙中放行 VRRP 协议。VRRP 的协议号是 112，不是 TCP/UDP 端口。很多云平台默认不允许 VRRP 报文通过，这会导致 Keepalived 主备之间无法通信，VIP 永远漂移不过去。遇到这种环境，要么改用云平台自带的 HA 能力，要么找客服确认是否支持 VRRP。

2.3 防火墙与 SELinux 注意事项

Ubuntu 默认的防火墙是 ufw。为了减少干扰因素，我在内网测试环境直接禁用了 ufw：

bash复制sudo ufw disable

但在生产环境，我一般会精确放行必要端口，而不是全关。至少需要放行的规则包括：

如果开启 ufw，用类似下面的命令放行：

bash复制sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow proto 112 from 192.168.1.0/24

SELinux 在 Ubuntu 上不是默认启用的，但如果你用了 AppArmor 且对 Nginx 有特殊限制，需要检查一下是否拦截了 Nginx 的绑定、监听等操作。大部分场景下无需额外调整，但如果 Nginx 启动报权限错误，值得往这个方向查一查。

3. Nginx 安装与负载均衡配置实操

Nginx 是整个方案的流量入口，配置的好坏直接决定后端服务能否稳定承接请求。这一节我会给出完整可复现的安装和配置过程，并解释每一个关键参数的含义。

3.1 两种安装方式：apt 与源码编译怎么选

在 Ubuntu 24.04 上装 Nginx，有两条主流路径：apt 直接安装，或者源码编译安装。

apt 安装最大的优势是省心：

bash复制sudo apt install nginx -y

装完后版本可能不是最新的，但都是经过了发行版测试的稳定版本，安全更新也能通过 apt 自动拉取。对绝大多数业务场景，apt 安装完全够用，这也是我推荐的第一选择。

源码编译的优势是能自定义模块和编译参数，比如加装 echo 模块、http_realip_module 等。但劣势同样明显：升级麻烦、依赖需要自己解决、编译参数一旦有遗漏后续补模块要重新编译。坦白说，除非你的业务有特殊模块需求，否则在 Ubuntu 24.04 上使用 apt 安装是投入产出比最高的方案。

安装完成后，先确认 Nginx 能正常启动：

bash复制sudo systemctl start nginx
sudo systemctl enable nginx
systemctl status nginx

访问 http://192.168.1.10/ 看到 Welcome to nginx! 的页面，基础环境就通了。

3.2 负载均衡策略选择：轮询、权重、IP Hash 怎么选

Nginx 的 upstream 模块支持多种负载均衡策略，我把常用的几种整理成一张表：

我在实际部署中最常用的组合是：默认轮询打底，如果后端有性能差异就加权重；如果业务有 Session 粘滞需求，先考虑把 Session 放到 Redis 里，而不是依赖 ip_hash。为什么？ip_hash 虽然能保持会话，但一旦某台后端宕机，这部分用户的会话就无法转移到其他节点，反而影响可用性。把 Session 外置到 Redis，让所有后端无状态化，才是更健康的架构。

3.3 完整 Nginx 配置：upstream 与 proxy 参数详解

我下面给出一个实际可用的 Nginx 核心配置。主配置文件是 /etc/nginx/nginx.conf，但我们一般不改这个文件，而是在 /etc/nginx/conf.d/ 下新建一个站点配置，通过 include 机制加载，方便维护和回滚。

nginx复制upstream web_backend {
    # 默认轮询策略
    # 如果后端有性能差异，可以加权重：
    # server 192.168.1.20 weight=3;
    # server 192.168.1.21 weight=1;
    server web01 max_fails=2 fail_timeout=30s;
    server web02 max_fails=2 fail_timeout=30s;

    # 如果后端请求有长连接需求，可以开启 keepalive 连接池
    keepalive 32;
}

server {
    listen 80;
    server_name example.com;

    access_log /var/log/nginx/example_access.log;
    error_log /var/log/nginx/example_error.log;

    location / {
        proxy_pass http://web_backend;
        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;

        # 超时配置：后端处理请求的合理时间阈值
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;

        # 开启代理缓冲，避免后端响应慢导致前端阻塞
        proxy_buffering on;
        proxy_buffer_size 4k;
        proxy_buffers 8 4k;

        # 与后端 keepalive 配合的 HTTP 版本设置
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }

    # 健康检查辅助：当所有后端都不可用时，返回 503
    location = /health {
        access_log off;
        return 200 "ok";
    }
}

挑几个关键参数重点说明：

• max_fails 和 fail_timeout：这两个参数决定 Nginx 在多久时间内失败多少次会将后端标记为不可用。我设置的是 30 秒内失败 2 次就摘除节点，避免请求持续打到已经故障的服务器上。
• proxy_set_header X-Forwarded-For：如果后端 Web 应用需要记录客户端真实 IP，这个头是必须的，否则拿到的全是 Nginx 内网 IP。
• keepalive 32：这是 upstream 与后端之间的长连接池配置，能显著减少 Nginx 与后端之间的 TCP 握手次数。但对 HTTP/1.0 的后端，需要配合 proxy_http_version 1.1 和 Connection "" 才能生效。

配置完成后，测试语法并重载：

bash复制sudo nginx -t
sudo systemctl reload nginx

3.4 验证负载均衡是否生效

配置完成后，最简单的验证方式是用 curl 多次请求，观察后端日志或者请求响应：

bash复制for i in {1..10}; do curl -s http://192.168.1.10/; echo; done

我在测试环境中的两个后端页面分别返回了 Web-1 和 Web-2 标识。如果多次请求能看到两个后端的响应交替出现，说明轮询策略已经生效。

如果你和我一样不放心，可以在 web01 和 web02 上分别查看 Nginx 访问日志，确认请求确实被分发到了不同的后端：

bash复制tail -f /var/log/nginx/access.log

从日志里能看到来自 192.168.1.10 的请求在持续进入，这就说明 LB 层的转发链路已经通了。

4. Keepalived 安装与高可用配置实战

Nginx 层的负载均衡已经通了，接下来是重头戏——用 Keepalived 给这层负载均衡加上高可用能力。这一步是整个方案的核心，也是坑最多的地方，我会把配置和原理讲透。

4.1 Keepalived 在 Ubuntu 24.04 上的安装

Keepalived 同样可以直接用 apt 安装：

bash复制sudo apt install keepalived -y

安装后先看版本：

bash复制keepalived --version

我这边装的是 2.x 版本。这里多说一句，Ubuntu 24.04 的软件源中的 Keepalived 版本会比较新，但配置语法和旧版基本兼容。

安装完成后，先不要急着启动服务。Keepalived 启动后如果发现配置有问题，不会立刻报错，而是会在日志中狂刷错误——最典型的是一开始没配置配置文件就直接启动，服务会反复重启。我们要先把配置写好再启动。

4.2 VRRP 协议原理与 Keepalived 的工作机制

在不引入复杂概念的前提下，可以这样理解 VRRP：两台（或多台）服务器组成一个虚拟路由器组，对外通告一个虚拟 IP。主服务器周期性发送 VRRP 通告报文，宣告自己活着；备服务器如果在设定时间内收不到通告，就认为主服务器挂了，立刻接管虚拟 IP，并开始发送自己的通告，宣告自己成为新的主。

Keepalived 的工作机制分为两层：

• VRRP 层：负责主备节点的心跳检测和 VIP 漂移。
• 健康检查层：通过自定义脚本检查 Nginx 进程状态。如果 Nginx 挂了但服务器还活着，Keepalived 会主动降低自己的优先级，触发 VIP 漂移。

这一层的设计非常关键。只依赖 VRRP 的物理心跳是不够的——如果只是 Nginx 进程崩溃，机器没宕机，Keepalived 不会自动切换，VIP 不会漂移，客户端依然会把请求打到 Nginx 已经挂掉的机器上。所以必须在 Keepalived 里集成 Nginx 进程健康检查。

4.3 编写 Nginx 监控脚本：进程与端口双重检测

监控脚本的思路很简单：检查 Nginx 进程是否存在，同时检查 80 端口是否能正常访问。两者都正常，返回 0，Keepalived 认为服务健康；任一不正常，返回非 0，Keepalived 根据配置降低优先级或直接触发切换。

我的脚本放在 /etc/keepalived/check_nginx.sh：

bash复制#!/bin/bash

# 检查 Nginx 进程是否存在
if ! pgrep -x nginx > /dev/null; then
    exit 1
fi

# 检查 80 端口是否能正常建立连接
if ! curl -s --connect-timeout 3 http://127.0.0.1/ > /dev/null; then
    exit 1
fi

# 检查后端服务器是否至少有一台存活
if ! curl -s --connect-timeout 3 http://127.0.0.1/health > /dev/null; then
    exit 1
fi

exit 0

脚本加执行权限：

bash复制sudo chmod +x /etc/keepalived/check_nginx.sh

为什么要把健康检查脚本独立出来，而不是用 Keepalived 内置的简单 TCP 检测？因为 TCP 检测只能确认端口还在监听，但 Nginx 可能已经处于僵死状态，端口虽然开着却无法正常处理请求。用 curl 做 HTTP 层探测，能更真实地反映服务可用性。第三个检查点（/health）是为了避免后端全部宕机时 LB 还在硬扛——只有当后端全部不可用时才应该让 VIP 漂移吗？这里有个取舍，我后文会讲。

4.4 主备节点配置详解：priority、unicast 与 vrrp_script

先看主节点 lb01 的 /etc/keepalived/keepalived.conf：

nginx复制global_defs {
    router_id lb01
    script_user root
    enable_script_security
}

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    timeout 2
    fall 2
    rise 2
    weight -20
}

vrrp_instance VI_1 {
    state MASTER
    interface ens18
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 12345678
    }
    unicast_src_ip 192.168.1.10
    unicast_peer {
        192.168.1.11
    }
    virtual_ipaddress {
        192.168.1.100/24 dev ens18
    }
    track_script {
        check_nginx
    }
}

备用节点 lb02 的配置基本一致，需要改的地方很少：

nginx复制global_defs {
    router_id lb02
    script_user root
    enable_script_security
}

vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    timeout 2
    fall 2
    rise 2
    weight -20
}

vrrp_instance VI_1 {
    state BACKUP
    interface ens18
    virtual_router_id 51
    priority 90          # 必须小于主节点的 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 12345678
    }
    unicast_src_ip 192.168.1.11
    unicast_peer {
        192.168.1.10
    }
    virtual_ipaddress {
        192.168.1.100/24 dev ens18
    }
    track_script {
        check_nginx
    }
}

几个关键参数的详细说明：

关于 weight 参数，这里有个容易被忽略的细节：当 check_nginx 脚本检测失败时，Keepalived 会把当前节点的 priority 减去 weight 值（我配置的是 -20）。这意味着主节点如果 Nginx 挂了，优先级会从 100 降到 80，低于备节点的 90，触发 VIP 漂移。当主节点恢复后，脚本检测通过，优先级恢复为 100，VIP 又会漂移回来。这样的设计比直接用 fall 计数触发切换更平滑，但代价是主备之间会有短暂的重复抢占——如果你不希望主节点恢复后 VIP 再漂回来，可以配置 nopreempt。

unicast_src_ip 和 unicast_peer 这两个参数是我特意加的。默认情况下 Keepalived 使用组播地址 224.0.0.18 发送 VRRP 报文，但部分交换机或云平台对组播报文做了隔离，导致主备之间收不到彼此的通告。使用 unicast 单播模式，可靠性更高，也能规避大多数网络环境限制。

4.5 启动服务与验证 VIP 漂移

配置完成后，启动两台机器的 Keepalived 服务：

bash复制sudo systemctl start keepalived
sudo systemctl enable keepalived

先看主节点 lb01 上的 VIP 是否已经绑定成功：

bash复制ip addr show ens18

正常情况下，ens18 上除了原有的 192.168.1.10，还会多出一个 192.168.1.100，并且显示为 secondary 地址。这就说明 VIP 已经在主节点上生效了。

然后验证对外访问路径：

bash复制curl -s http://192.168.1.100/

如果 Nginx 配置正确，这个请求会经过主节点 Nginx 转发到后端 Web 服务器。多刷几次，能看到两个后端交替响应。

为了确认 Keepalived 是否工作正常，查看日志：

bash复制sudo journalctl -u keepalived -f

正常情况下，主节点日志会周期性显示发送 VRRP 通告，备节点日志显示收到来自主节点的通告。看到这些日志，说明主备之间的心跳已经建立。

5. 故障切换测试与常见问题排查

高可用方案做完了，不等于万事大吉。真正考验方案质量的是故障切换测试——只有在演练中验证过的方案，才敢放到生产环境。

5.1 手动制造故障：停掉 Nginx 与宕机模拟

第一个测试场景：Nginx 进程异常退出。

在主节点 lb01 上执行：

bash复制sudo systemctl stop nginx

正常情况下，check_nginx 脚本在两次检测（间隔 2 秒，fall 2 次，大约 4-8 秒）后会发现 Nginx 不可用，触发优先级降低。20 秒内，VIP 应该漂移到 lb02。观察备节点日志：

bash复制sudo journalctl -u keepalived -f

可以看到类似 "Entering MASTER state" 的日志输出，说明 lb02 已经接管了 VIP。

此时再次验证访问：

bash复制curl -s http://192.168.1.100/

请求依然正常返回，但实际处理的 LB 节点已经变成了 lb02。业务无感知，切换成功。

第二个测试场景：整机宕机。

模拟方式可以是直接关机，或者拔掉网线。这里我一般用 sudo poweroff 来模拟最真实的宕机场景。主节点宕机后，lb02 在 3 个 advert_int 周期（约 3 秒）内收不到通告，就会触发抢占，VIP 漂移到 lb02。整个过程比 Nginx 进程级故障的切换更快，因为 VRRP 的心跳检测比脚本检测更直接。

5.2 恢复场景测试：主节点回归行为

主节点恢复后会发生什么？这取决于你是否配置了 nopreempt。

默认行为是：lb01 恢复后，priority 恢复为 100，高于 lb02 的 90，所以 VIP 会重新漂移回 lb01。这看起来是合理的，但在真实生产场景中，有个隐患：如果主节点恢复时状态并不稳定（例如刚启动但 Nginx 还在预热），VIP 漂移回来后可能导致短暂的服务异常。

我实际遇到的一个具体场景是：主节点机器被强制关机后重启，Keepalived 服务启动了，但 Nginx 因为磁盘检查耗时还没起来。此时 check_nginx 脚本检测失败，priority 被降低到 80，VIP 不会漂移回去。直到 Nginx 完全就绪，脚本检测通过，VIP 才切回主节点——所以脚本的 fall 和 rise 参数在这种场景下真的是护身符。

如果你希望主节点恢复后不抢占 VIP，只在备节点也故障时才接管，可以在配置中加上：

nginx复制vrrp_instance VI_1 {
    nopreempt
    ...
}

但要注意，nopreempt 配置只有在 state BACKUP 的节点上才生效。也就是说，如果你希望主节点恢复后不立刻抢占，主节点的 state 也要改成 BACKUP，并配合 priority 控制初始选举。

5.3 常见问题速查表与排查思路

我把实际部署中遇到的高频问题整理成了一张速查表，每一个都是我亲手踩过的：

5.4 抓包验证与脑裂问题的处理经验

在高可用集群中，还有一个比较隐蔽的问题值得单独拿出来讲——脑裂（Split-Brain）。简单说，就是主备节点都认为自己是主节点，都绑定了 VIP，导致流量走到两个不同的入口。

脑裂最常见的原因是主备之间的 VRRP 通信中断。比如网线松动、交换机端口 STP 阻塞、防火墙误拦，导致备节点收不到主的通告，从而触发抢占。此时主节点还活着，VIP 没有被释放，备节点又把 VIP 绑上了，两个节点同时响应，客户端请求被随机分发到两台机器上，表现就是服务不稳定、后端日志错乱。

检查脑裂最直接的方法是查看两台机器的 VIP 绑定情况：

bash复制ip addr show ens18 | grep 192.168.1.100

如果两台机器上都出现了这个 IP，说明脑裂已经发生。排查思路按顺序：

1. 先检查网络连通性：两台 LB 之间能否互相 ping 通。
2. 再用 tcpdump 抓 VRRP 报文确认通告是否在传输：

bash复制sudo tcpdump -i ens18 vrrp

如果抓不到对端发送的 VRRP 报文，说明问题出在网络链路或防火墙。

3. 如果是云环境，确认安全组是否放行了 112 协议。如果是物理交换机环境，检查端口是否启用了组播过滤。

针对脑裂，我能给出的最实用建议是：在脚本健康检查中增加“对端存活”的判断。比如主节点在抢占 VIP 前，先试着 ping 一下对端 IP，如果能 ping 通则说明对方还活着，不抢 VIP；只有 ping 不通（说明对端彻底宕机）才接管。这样能大幅降低脑裂造成的影响。

这个方案的后续扩展方向也很明确：如果想进一步提升运维效率，可以加 Prometheus + Grafana 对 LB 集群做监控告警；如果想支持更多后端节点和更复杂的路由策略，可以在 Nginx 层接入 Lua 或 OpenResty；如果业务规模再上一个台阶，就需要考虑 LVS + Keepalived 的四层 LB 架构，或者直接上 Kubernetes 的 Ingress Controller。我个人的建议是，先把这套经典的二三层方案跑熟，理解 VIP 漂移和健康检查的本质，再去接触更复杂的技术栈，会轻松很多。