LVS负载均衡原理与实战：DR/NAT模式及Keepalived高可用配置

1. 为什么今天还在学 LVS——从一个最实际的性能问题说起

之前有位同事把公司的网关服务从单机换成了一台高配服务器，觉得 CPU 64 核、内存 256G，怎么都能扛住促销峰值了。结果第一波压测流量刚上来，单机网卡就跑满了，连接数冲到几十万，CPU 反而没怎么动。问题很明显：一台机器的处理能力是有上限的，而且瓶颈往往不在 CPU，而在内核协议栈和网卡中断处理的吞吐能力上。

这时候大家首先想到的是 Nginx。但 Nginx 是七层（HTTP 层）负载均衡，它要终结 TCP 连接，要解析、转发 HTTP 请求，这本身就消耗大量 CPU。后来我们把流量模型拆开来看，发现一个更有意思的对比：

当时我们最核心的需求是：上亿级别的短连接转发、每秒钟几十万新建连接、不能让负载均衡器本身成为瓶颈。LVS 天然契合这个场景，它工作在 Linux 内核的 netfilter 框架上，本质上是一段挂接在协议栈里的转发逻辑，不走用户态拷贝，响应能力远超 Nginx 这类基于用户态事件循环的软件。所以即便很多人一开始觉得 LVS 是老古董，我仍然认为它是大规模流量入口不可替代的基础设施。

这篇文章就围绕 LVS 的原理和配置展开，适合正在做网关选型、遇到单机瓶颈、想理解四层负载均衡原理的读者。我会把三种链路模式讲透，再给出可以直接抄的 Keepalived + LVS 配置，最后附上我在实际部署中踩过的坑。核心关键词始终是：LVS 原理、ipvsadm 配置、DR 模式、NAT 模式、Keepalived 高可用。

2. 三种数据链路模式：NAT、DR、Tunnel，一次讲透

LVS 的转发逻辑看似复杂，其实就围绕一个问题：数据包到达负载均衡器之后，怎么把它送进后端的真实服务器，同时还能保证回包正确地回到客户端手里。三种模式对应三种不同的答案，理解它们各自的取舍是配置前最重要的事。

2.1 NAT 模式——改目标地址的传统方案

NAT 模式（全称 Virtual Server via Network Address Translation）是最符合直觉的一种做法。客户端把请求发给 VIP（虚拟 IP），负载均衡器拿到包后，把报文的目标 IP 从 VIP 改成某台后端服务器（RealServer）的真实 IP，然后转发到内网。后端处理完请求后，回包要先回到负载均衡器，由负载均衡器再把源 IP 改回 VIP，才能送回客户端。

这个过程的本质和家里路由器做端口映射很像，只是维度更多。NAT 模式最大的问题是回程流量必须经过负载均衡器，等于所有进出流量都要走同一个设备。请求量上来之后，负载均衡器的网卡和 NAT 处理逻辑会先扛不住。但它的好处也很明显：后端服务器只需要一个普通内网 IP，不需要额外配置 VIP，也不要求操作系统做特殊 ARP 设置，后端的网络环境最简单。

配置 NAT 模式时有一个必须注意的点：后端的默认网关必须指向负载均衡器的内网 IP。否则后端回包会按照自身的路由表直接发给客户端网关，客户端拿到源 IP 是后端真实 IP 而不是 VIP 的包，连接直接就断了。这个坑我见过不止一次，很多人 NAT 模式调不通，八成就是网关没指对。

NAT 模式下可以做端口映射，VIP 的端口和后端服务器的端口可以不一致。比如入口是 80 端口，后端实际监听 8080，NAT 模式能在转发时做目标端口改写，这是 DR 模式做不到的。所以某些特殊场景下，NAT 模式仍然有它的存在价值。

2.2 DR 模式——性能神话背后的修改 MAC 地址思路

DR 模式（Direct Routing，直接路由）是生产环境中最常用的模式，也是理解门槛最高的一个。它之所以性能高，核心思路是：负载均衡器只修改数据链路层的目标 MAC 地址，不碰 IP 层。

请求流程是这样的：客户端发一个目标 IP 为 VIP 的包到达负载均衡器，负载均衡器把这个包的二层帧头里目标 MAC 地址改成后端服务器的 MAC 地址，再扔进二层网络。后端服务器收到包后发现 IP 层目标地址确实是自己绑定的 VIP，于是正常处理。回包时，后端服务器直接以自己的真实 IP 作为源 IP、客户端 IP 作为目标 IP 发出，完全不需要经过负载均衡器。

这就解释了为什么 DR 模式的瓶颈远低于 NAT：负载均衡器只处理入站流量的一半，出站流量全部旁路了。但也正因为回包路径变了，引出了一系列配置前提，缺一不可：

1. 负载均衡器和所有后端服务器必须处于同一物理二层网络（同一交换机域），因为要直接改 MAC 地址转发。
2. 后端服务器的回环接口 （lo） 上必须绑定一个 VIP 的别名地址，否则内核收到目标 MAC 是自己的报包后，一看目标 IP 不是本机 IP，会直接丢掉。
3. 后端服务器必须抑制对 VIP 的 ARP 响应。如果不抑制，交换机会学到多条 VIP 对应的 MAC，流量分发给后端服务器后，四层负载均衡的入口就名存实亡了。

我见过很多初次配置 DR 模式的人，一路配置下来都很顺利，唯独忘记抑制 ARP，结果流量浪涌式随机打到后端某台机器上，连接时好时坏。这个细节我在后面的踩坑部分会展开讲。

DR 模式还有一个限制：后端服务器和负载均衡器的 VIP 端口必须一致。因为负载均衡器只改 MAC，不改 IP 层和传输层头部，所以没法做端口映射。如果你需要 80 端口进、8080 端口出，DR 模式直接做不到，必须换 NAT 或者在后端前面再挂一层转发。

2.3 Tunnel 模式——跨机房流量调度的可能性

Tunnel 模式（IP Tunneling，也叫 IPIP 隧道）的原理是：负载均衡器把进入的请求包用一个新的 IP 头封装起来，新的源 IP 是负载均衡器自身、目标 IP 是后端服务器的真实 IP，然后像普通 IP 包一样发出去。后端服务器支持 IPIP 解封装的话，会去掉外层 IP 头，露出内层的 VIP 目标地址，然后正常处理请求。回包同样直接发给客户端，不回负载均衡器。

这种模式最大的价值是解除了 DR 模式对二层网络的限制。后端服务器可以分布在不同的机房、不同的网段，只要它们支持隧道协议并且网络能通就行。对于需要跨地域做流量调度的场景，Tunnel 模式几乎是唯一选择。代价是每一份流量都要额外增加一层 IP 头，大约 20 字节的封装开销，同时要求后端的操作系统内核启用 IPIP 模块。大多数情况下，Tunnel 模式用得没有 DR 多，但在多云、多机房架构里，它是不可替代的。

2.4 三种模式对照与选型决策

我在实际选型时遵循的决策顺序很简单：

网上很多教程一上来就让新手配 DR 模式，理由是性能最好。但如果你的后端只有三五台机器，对性能没有那么极致的需求，NAT 模式反而更省心，因为它不需要任何 ARP 抑制相关的额外配置，出问题概率低。选型的第一原则不是追求最强参数，而是考虑你的团队能不能在未来一年内持续运维这套架构。

3. 调度算法不是越多越好，掌握取舍才是关键

LVS 的转发规则决定了它能做到什么程度，但流量进来之后给谁，是调度算法（Scheduling Algorithm）负责的事。LVS 的调度算法分为静态算法和动态算法两大类，静态算法不关心后端当前的负载情况，纯粹按规则分发；动态算法会查询后端当前的连接数和权重，再决定下一跳。

3.1 静态算法：轮询、加权轮询、源地址哈希

最基本的轮询算法（rr）就是把请求轮流发给每一台后端服务器，适合后端性能差异不大的情况。加权轮询（wrr）在此基础上加入了权重，权重高的后端分到的请求更多，适合后端服务器配置高低不一的集群。

源地址哈希（sh）根据客户端 IP 做哈希运算，同一个源 IP 的请求永远发给同一台后端服务器。这种算法天然适合需要会话保持的场景，比如部分老旧系统的登录态只存在单机内存里、没做统一 Session 存储，这时候靠 sh 能规避一部分问题。但它的缺点也很明显：一旦后端服务器数量变化，哈希映射会重新洗牌，大量客户的会话会瞬间失效。所以使用 sh 算法时，后端节点的扩缩容要格外谨慎，尽量在低峰期操作。

3.2 动态算法：最小连接及其变种

最小连接算法（lc）会把新请求发给当前连接数最少的后端。加权最小连接（wlc）则是在连接数最少的基础上叠加权重考量，优先发给“连接数除以权重”最小的后端。LVS 官方给出的默认推荐算法基本就是 wlc，因为它兼顾了后端实时负载和个体差异，在绝大多数 HTTP 长连接场景下表现都不错。

但动态算法也有误判的时候。它统计的是连接数，不是 CPU 使用率或响应延迟。假设后端某台机器出现死锁、线程池耗尽，每个请求都卡住不释放连接，连接数一直很高，动态算法反而会精确地把新请求都避开这台机器。这在某些场景下成了“故障自动隔离”，算是歪打正着。反过来，如果后端是纯 CPU 密集型任务，连接数很低但 CPU 已经打满，动态算法依然会把流量源源不断送进去，这时候 wlc 就不够用了，需要配合更上层的健康检查和配额控制。

3.3 实际业务中的算法选择顺序

我个人的经验是，不要一上来就追求复杂算法，按照下面的优先级去试：

1. 后端配置基本一致、无会话要求，直接 rr，简单直观。
2. 后端配置差异较大，用 wrr，把权重调成和机器 CPU 核数近似成正比。
3. 需要会话保持且后端没有共享 Session，用 sh。
4. 后端请求处理时间相对均匀，用 wlc 做默认兜底。
5. 特殊场景（如长期连接、大量新建短连接混存）再逐个测评 lc、lblc、dh。

另外提醒一句，算法是在virtual_server配置段里通过lb_algo指定的，改算法不影响已有连接，只影响新连接的调度。所以线上环境可以放心改，不需要停机。但改了之后要持续观察一段时间，重点看有没有出现连接倾斜。

4. Keepalived + LVS：从单机转发到高可用集群

LVS 本身解决的是流量分发问题，但它没有自带故障转移机制。如果部署 LVS 的这台机器宕机了，整个入口就断了。所以生产环境里几乎不会单独使用 LVS，而是配套 Keepalived 实现高可用。Keepalived 的核心是 VRRP 协议（虚拟路由冗余协议），通过多台机器竞争同一个 VIP 来实现故障切换。只要 VIP 在，服务对外就是连续的。

4.1 整体架构设计

先看典型的两节点高可用架构：

• 两台 LVS 节点，一主一备，共享一个 VIP。
• 正常情况下，主节点持有 VIP，将流量分发到后端的 RealServer 集群。
• 主节点宕机或 Keepalived 进程退出后，备节点通过 VRRP 通告超时机制接管 VIP。
• 后端 RealServer 上分别部署 Nginx 或应用服务，监听一个统一端口。

这里需要特别强调一下，Keepalived 不仅要管 VIP 漂移，还要负责后端服务器健康检查。它通过 TCP 探活或 HTTP 探活定期检查每个 RealServer 的存活状态，发现某台后端挂掉后，自动从 LVS 转发列表里摘除该节点，恢复后再重新加回来。没有健康检查的 LVS 就只是机械转发，后端挂了你都不知道，用户照样打到故障机上。所以 Keepalived 的配置里，健康检查段一定不能省。

4.2 部署配置拆解

主节点和备节点的 Keepalived 配置只有小部分不同，核心是state、priority和unicast_peer（如果使用单播 VRRP）。为了方便大家直接抄作业，我把最小可用的配置贴出来并逐段解释。

主节点 Keepalived 配置（/etc/keepalived/keepalived.conf）：

global_defs { router_id LVS_MASTER } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 123456 } virtual_ipaddress { 192.168.200.100 } } virtual_server 192.168.200.100 80 { delay_loop 6 lb_algo wlc lb_kind DR protocol TCP real_server 192.168.200.11 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } real_server 192.168.200.12 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 connect_port 80 } } }

备节点配置只需把state改为BACKUP，priority改为 90 或更小，其他内容保持一致。这里有几个关键参数必须理解，而不是照抄：

• virtual_router_id：同一组高可用节点必须保持一致，否则 VRRP 报文无法互相识别。
• priority：主备竞争 VIP 的依据，越大越优先。备机不能超过主机的值，否则会发生 VIP 抢占。
• advert_int：VRRP 通告间隔，默认 1 秒。也就是说主节点 1 秒发一次心跳，备节点超过 3 个通告周期没收到，才开始抢占 VIP。这个值决定故障切换的时间上限。
• lb_algo wlc：调度算法，按上一章的思路来选择。
• lb_kind DR：链路模式，本章配置针对 DR 模式展开。

virtual_server块中的real_server是必须显式列出的，Keepalived 不是自动发现后端，它把我们写好的节点列表下发到内核 ipvs 表里。所以每次后端扩容，都要记得同步修改 Keepalived 配置并重启服务，这一点很容易漏。

健康检查参数也需要细心调。connect_timeout太短容易误判，太长会导致故障节点隔了很久才被摘除。我的经验是内网环境下 2 到 3 秒比较合适。如果后端是 HTTPS 端口，可以把TCP_CHECK替换为HTTP_GET，指定url路径做应用层探活，能更真实地反映服务可用性。

4.3 验证高可用切换是否真的生效

配置完成并启动 Keepalived 后，不能只看 VIP 在不在，要做故障演练。我这里提供一个标准验证流程：

1. 在主节点上执行ip addr show eth0，确认 VIP 已经绑定在当前机器。
2. 执行ipvsadm -L -n，确认内核转发规则里有后端节点列表。
3. 从客户端访问 VIP 的服务，确认请求能正常返回。
4. 直接停掉主节点上的 Keepalived 服务（systemctl stop keepalived），模拟进程故障。
5. 在客户端持续发起请求，观察连接是否中断，稍等片刻后 VIP 是否出现在备节点上。
6. 把主节点重新启动，观察 VIP 是否被抢占回去（取决于nopreempt状态，默认会抢占）。

这个过程我建议大家写进上线检查清单。只部署不演练的高可用等于没有高可用，真正故障来临时你根本不知道备机能不能接得住流量。我见过太多案例，备机配置错了网关，主节点一挂服务就全挂，因为没人演练过。

5. 真实踩坑清单：这些问题文档里一般不写

配置 LVS 和 Keepalived 最折磨人的往往不是看不懂原理，而是某些隐含约束没满足，表现出的故障千奇百怪。我把这些年实际踩过的坑按排查思路整理成清单，每一个都是真实发生过的。

5.1 DR 模式下回环接口的网关卡点

DR 模式要求后端服务器在 lo 接口（回环接口）上绑定 VIP，这是很多人知道的。但很少有人注意，绑定 VIP 时不能带广播地址和全零子网掩码，而且不能把这条配置写到主接口 eth0 上，否则系统会对 VIP 发 ARP 响应，破坏整个转发链路。

我的后端配置习惯是：把 VIP 绑定和 ARP 抑制写进/etc/rc.local，确保重启后自动生效。具体命令如下（以实际环境 IP 为例）：

ip addr add 192.168.200.100/32 dev lo sysctl -w net.ipv4.conf.all.arp_ignore=1 sysctl -w net.ipv4.conf.lo.arp_ignore=1 sysctl -w net.ipv4.conf.all.arp_announce=2 sysctl -w net.ipv4.conf.lo.arp_announce=2

arp_ignore=1的含义是只回答目标 IP 是本机网卡 IP 的 ARP 请求；arp_announce=2的含义是发送 ARP 时使用能访问目标的最佳本地地址，而不用 lo 上的 VIP。这两个参数配合，才能确保后端机器不会“抢答”VIP 的 ARP 请求。注意这些参数是内存态的，服务器重启后要重新设置，建议一并写入/etc/sysctl.conf或专门的 sysctl 配置文件。

很多人在这一步卡住后，会用tcpdump去抓包，结果发现客户端发给 VIP 的包络来到了后端，但后端的内核就是不处理。这时先看一眼ip addr show lo，再看一眼arp_ignore的值，大概率问题就出在这两处。

5.2 后端服务的监听地址陷阱

DR 模式下，后端服务器的应用服务（比如 Nginx）监听地址必须包含 VIP 或者监听 0.0.0.0。如果你偷懒只监听 eth0 的内网 IP，那么即使 lo 上绑了 VIP，内核也不会把目标为 VIP 的包交给应用进程处理，因为包被路由到 lo 之后，应用根本没绑定这个地址，会被拒绝。

这个问题在排查时最迷惑的地方在于：你在后端机器上本地访问 VIP 是通的，但外部客户端就是不成功。原因就是本地回环访问和外部转发走的路径不同。处理办法很简单：Nginx 的listen指令不要只写具体 IP，建议写成listen 80 default_server;，或者同时监听 VIP 地址。

5.3 Keepalived 探活导致的误摘除

健康检查探活参数如果设置得太激进，后端处理延迟稍微高一点，Keepalived 就认为服务挂了，把这个节点从 ipvs 表里摘掉。等请求压力降低，探活恢复后又加回来。一摘一加之间，如果摘除前已经建立的长连接还在被使用，连接里的流量就会被中断，尤其对长连接服务影响巨大。

我推荐的保守参数组合：

如果你后端的服务本身有健康检查接口（比如/healthz），建议优先用HTTP_GET而不是TCP_CHECK，因为后者只能证明端口通，不能证明应用可用。同时要让探活接口本身轻量、稳定，不要让它在高并发下也超时。

5.4 数据包入口的对称性问题

这里分享一个非常隐蔽的坑。某次我们在机房内用 DR 模式部署 LVS，转发规则、后端 ARP 配置、健康检查全部正常，但压测时发现丢包率随并发数上升而急速恶化。排查了很久，最后的根源竟然是机房的交换机开启了某个端口安全功能，对学习到的 MAC 地址有数量限制。LVS 转发大量数据包时，后端服务器的 MAC 地址频繁变动（因为不同后端 MAC 不同），交换机的 MAC 表被撑满后开始丢包。

这类问题不亲自踩过很难想到。它提醒我们，LVS 虽然是软件层面的负载均衡，真正上线时仍然极度依赖底层网络的稳定性。DR 模式对二层网络的基础设施要求比 NAT 高得多，如果物理网络质量没有保障，再正确的配置也扛不住流量冲击。遇到类似丢包问题时，不要光盯 LVS，先看看交换机端口统计，再下结论。

6. 线上参数调优与日常运维的几条经验

配置落地只是开始，真正让 LVS 稳定运行，还需要对其内核参数、连接追踪、日志处理做持续调优。这里的经验是我在长期运维中逐步积累的。

6.1 连接跟踪与超时控制

LVS 在内核中维护一张 IPVS 连接表，每条 TCP 连接都有状态和超时时间。短连接大量建连、断连时，连接表会残留 TIME_WAIT 或 FIN_WAIT 状态的条目。如果后端一直崩溃重连，表项堆积多了，内核查找效率会下降，极端情况下连接表会满，新连接被直接丢弃。

处理手段有几个层面。首先是检查当前连接表状态，用ipvsadm -L -n --stats看每条 RealServer 的活跃连接、非活跃连接计数。其次是调整系统级的连接超时参数：

ipvsadm --set 120 20 60

这条命令分别设置了 TCP 空闲超时、TCP 关闭后的超时、UDP 超时（秒）。如果线上基本全走短连接，可以把 TCP 空闲超时从默认的 900 秒调低到 120 秒左右，加快表项回收。如果是长连接场景（WebSocket、消息推送），反而要调高，否则长连接会被 LVS 提前老化掉。这个参数非常依赖业务模型，没有一劳永逸的值，建议每次调整都配合抓包验证。

6.2 查看流量是否倾斜的日常手段

运维 LVS 集群时，我每次流量高峰期都会执行一条命令：

ipvsadm -L -n --stats

输出中每一行对应一条 RealServer，右边的ActiveConn（活跃连接数）和InActConn（非活跃连接数）可以直观地看出流量分配是否均匀。如果某个节点的连接数明显高于其他节点，先排查权重是不是写错了，再看这台机器是不是在处理响应更慢的请求（因为慢请求占用连接时间长，连接数自然堆起来）。

如果需要更精细的流量视角，可以在 LVS 节点上用tcpdump抓转发流量，确认入站流量和出站流量是否符合预期。DR 模式下，理论上 LVS 节点只应看到入站请求包和极少数异常回包，如果发现大量属于后端回包的流量也经过 LVS，说明后端默认网关配置错了，回程流量又绕回来了。

6.3 日志与监控的兜底建议

LVS 默认不记录每个转发的详细日志，因为转发量太大，打日志会拖垮性能。所以监控数据主要靠两个来源：一是ipvsadm自带统计接口，可以接入 Prometheus 等监控系统定期采集；二是 Keepalived 的 VRRP 状态切换日志。在监控系统里我会重点盯三个指标：

• VIP 漂移次数：频繁漂移说明某个节点不稳定，可能是网络抖动或心跳不健康。
• 后端 RealServer 的摘除次数：过多说明健康检查参数过严或后端服务确实有抖动。
• ipvs 连接表占用率：接近上限时，需要提前扩容或调参。

这些指标和业务响应时间结合起来，才能形成一套完整的网关健康度视图。没有监控的 LVS 集群就像没有仪表盘的飞机，飞得再高也让人不踏实。

6.4 扩容和缩容的操作纪律

LVS 集群扩缩容并不复杂，但操作顺序有讲究。先说扩容：先把新机器部署好应用，确认本地服务监听正常，再把新节点 IP 加进 Keepalived 配置，执行systemctl reload keepalived（如果支持）或重启 Keepalived。此时新节点会进入 ipvs 表并开始接收流量。

缩容正好相反：先从 Keepalived 配置里删掉目标节点，等待健康检查对它的摘除生效，确认ipvsadm -L -n里已经看不到它，再停掉目标机器上的应用服务，最后再关机器。按这个顺序操作，能最大程度避免在流量分发过程中出现“转发到不存在主机”的情况。

不管是扩还是缩，都要记得同步调整其他相关配置，比如后端服务自身接入的注册中心、配置中心里有没有本机 IP 的依赖。LVS 层面对后端节点是无状态的，但后端业务系统不一定无状态，这个边界要想清楚。

7. 写在最后的一点个人体会

LVS 不是新技术，它成名得早，但在当前的高并发架构里依然站得住脚。它的核心竞争力就是极简的转发模型和内核级的性能，这是 Nginx 等七层方案很难替代的。如果你团队的流量规模还没到需要单独维护一套 LVS 集群的地步，那用云厂商的负载均衡产品会更省心；如果有一天流量大到需要自建，希望这篇基于实际经验的梳理能让你少走一些弯路。

我在实际运维中最大的体会是：LVS 的原理本身不难，难的是它和底层网络、系统参数、业务模型之间的隐性耦合。与其在网上搜各种零散教程，不如自己搭一套最小环境，把 NAT、DR、Keepalived 切换、健康检查摘除这几条链路亲手跑通一遍。只有把正常流程和故障流程都摸熟了，真正出问题时才不会慌。