从零搭建LVS负载均衡集群：DR模式原理与keepalived高可用实战-代码聚汇网

1. LVS的整体设计思路：从“单机扛不住”到“负载均衡集群”

做后端或者运维的朋友，肯定都经历过这种场景：业务上了线，用户量一上来，服务器CPU飙到90%，数据库连接打满，应用频繁超时。一开始加带宽、升配置，后来发现单机再怎么折腾也有天花板，于是开始上集群。集群之后面临的第一个问题就是：请求进来，到底分给哪台机器？

这时候就需要一个前置的“调度员”，把所有流量接住，再按照规则分发到后端的服务器集群。LVS（Linux Virtual Server）就是干这件事的，而且是从上世纪90年代末一直干到今天，依然是很多互联网公司负载均衡体系的核心基石，内核态的ipvs模块直到现在都在Linux主线上维护，这也说明它的生命力有多强。

LVS能解决的问题很明确：四层负载均衡，也就是基于IP和端口的流量分发。它比nginx这种七层负载均衡性能要高一个量级，因为数据转发工作发生在内核态，不需要频繁切换上下文，也不会因为用户态逻辑处理产生额外开销。你可能用nginx做过反向代理，把请求按域名或URL分发到后端，而LVS更底一层——它不关心HTTP协议内容，只负责决定“这个TCP/UDP包应该给谁”。

什么样的人最适合学LVS？一类是运维工程师，尤其是要维护高可用集群、线上流量入口的；另一类是后端开发，理解LVS能帮你搞明白请求从客户端进来之后到底经历了什么，排障时不会两眼一抹黑；还有就是对网络和系统底层感兴趣的读者，LVS是一个学习Linux内核网络栈、netfilter框架、ARP协议、路由转发的绝佳实战样本。

1.1 虚拟服务器的三层逻辑结构

LVS的架构核心是三段式的：负载均衡器（也叫Director，调度器）、服务器池（Real Server Pool）、共享存储（可选）。

负载均衡器：整个集群的唯一入口，对外暴露一个虚拟IP（VIP），客户端只跟VIP通信。用户请求到达VIP后，由均衡器根据预设的调度算法决定转发给哪台真实服务器。
服务器池：一组真正提供业务的服务器，每台都有一个真实IP（RIP），运行相同的业务应用。服务器池里的节点可以水平扩展，加机器就是加容量。
共享存储：如果业务是无状态的，其实不需要共享存储；但如果各RS需要提供完全一致的内容（比如静态文件、会话数据），通常会用NFS、分布式存储之类的方案把数据统一起来。

理解这个结构，关键要抓住两个词：虚拟和真实。对外只有一个VIP，客户端感受不到后端的多台机器；对内是RIP列表，负载均衡器负责把流量映射到具体的RIP上。

LVS内部还有一个概念叫“虚拟服务器”（Virtual Server），也就是一个由“VIP+端口+协议”定义的逻辑服务。比如你定义了一个TCP VIP 192.168.1.100:80，那么所有到192.168.1.100的80端口TCP请求，都会被LVS接管并分发。这个概念很重要，因为后面配置ipvsadm时，先加虚拟服务器，再往这个虚拟服务器里加真实服务器，顺序和逻辑都是围绕这个展开的。

1.2 为什么LVS性能能打：内核态转发的秘密

从高中物理的角度来类比一下用户态和内核态的区别：用户态相当于在办公室里处理文件，每份文件都要审批、签字、走流程，灵活但是慢；内核态相当于在流水线上直接操作，规则一旦定好，每个包裹进来直接分拣，不需要层层审批，快得离谱。

LVS的实现就是把“负载均衡”这活儿搬到了内核态。它的核心模块叫ipvs（IP Virtual Server），基于Linux内核的netfilter框架，挂载在LOCAL_IN的hook点上，也就是请求进入本机协议栈之后、交给上层应用程序之前的一个检查点。ipvs在这个位置直接改写数据包的目标地址/目标MAC，然后把数据包重新送回协议栈进行转发。因为整个过程都在内核里完成，不需要把数据包拷贝到用户态，也不会有用户态进程的调度开销，所以它才能一台机器扛住几十万甚至上百万的并发连接。

这一点也是LVS和nginx、haproxy的根本差异：后两者是用户态进程，处理的是已经“送达应用层”的请求，灵活，可以解析HTTP头做精细化路由，但性能天花板低；LVS只做四层转发，不关心上层协议，但性能天花板极高。在企业里，常见的组合是LVS做入口的四层分发，nginx再在每台后端上做七层反向代理，角色分工明确，各干各擅长的。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 三种工作模式的原理拆解与选型分析

LVS的协议和算法属于负载均衡的通用知识，真正能体现功力的是工作模式的理解。LVS有三种经典工作模式：NAT、DR、TUN。实际生产环境中90%以上的场景都用DR模式，但NAT适合入门理解，TUN用于特殊场景。把它们都搞明白，你才算真正理解了LVS。

2.1 NAT模式：原理最简单，瓶颈也最明显

NAT模式全称是Virtual Server via Network Address Translation，也就是通过网络地址转换来实现负载均衡。它的数据流向是这样的：

客户端请求到达LVS的VIP，源IP是客户端IP，目标IP是VIP。
LVS根据调度算法，把目标IP改写成某台RS的RIP。
RS处理完请求后，把响应直接回给LVS（因为RS的默认网关指向LVS）。
LVS再把源IP改回VIP，响应返回给客户端。

说白了，LVS在这里扮演了一个“双向中转站”的角色，请求和响应都要经过它。这带来两个直接后果：第一，后端RS可以只有内网IP，不需要外网IP，安全性和灵活性好，适合后端和前端网络隔离的场景；第二，LVS的出网流量和入网流量一样大，请求量大时它自己就容易成为瓶颈，扩展能力受限于单机网卡带宽。

给一个具体的数字感受：假如每个请求响应的平均大小是50KB，后端整体吞吐量到2Gbps时，LVS的出入流量合计就要跑4Gbps，千兆网卡直接打满，万兆网卡也开始吃力。所以NAT模式适合流量不太大、以功能验证和入门学习为目的的场景，不太适合大型线上业务。

配置NAT模式有几点容易踩坑的地方：后端RS的默认网关必须指向LVS的内网IP，否则响应包找不到回来的路；要知道内核的IP转发功能必须开启，net.ipv4.ip_forward = 1；还有，如果你在某台机器上直接测试VIP，回包路由可能不对称，导致连接异常，这是个经典坑，后面排障章节细说。

2.2 DR模式：生产环境的首选，响应不经过LVS

DR模式全称是Virtual Server via Direct Routing，直连路由模式。这是LVS三种模式里最受生产环境青睐的，也是理解难度最高的一个。

DR模式的核心思想是：请求进LVS，LVS通过改写数据链路层的MAC地址，把数据帧直接送给某台RS；RS处理完响应后，直接把包回给客户端，不回给LVS。

这里的重点在于“改写MAC”这四个字。LVS不会改动IP包里的源IP和目标IP，VIP还是那个VIP，RIP还是那个RIP，它只把以太网帧的目标MAC换成所选RS的MAC。RS收到这个帧之后，发现目标IP是VIP，而自己本机正好也配置了这个VIP（绑定在loopback接口上），于是认为这个包就是给自己的，正常收下并处理。

响应时，源IP就是VIP，目标IP就是客户端，直接走RS自己的网关发出去。这样，LVS只负责入站流量的调度，响应流量完全不经过它，性能瓶颈瞬间小了一大截，单台LVS能支撑的吞吐量远高于NAT模式。这也是DR模式能扛大流量的根本原因。

但DR模式也有代价：所有RS和LVS必须在同一个二层网络（同一个VLAN/物理网段），因为MAC地址只能在二层直接通信；RS的loopback接口上必须配置VIP，并且必须抑制ARP响应，否则客户端直接ARP请求VIP时，多台RS都会抢答，整个网络就乱了。

这里我会在第四章给出完整的配置步骤和参数，先记住这三个关键点：LVS和RS二层互通、lo绑定VIP、ARP抑制。

2.3 TUN模式与FULLNAT：特殊场景的补充方案

TUN模式，全称是Virtual Server via IP Tunneling，它把客户端请求包再封装一层新的IP包，外层目标IP是RS的RIP，内层目标IP还是VIP。RS收到之后解封装，发现内层目标IP是VIP，而自己也配了VIP在tunl接口上，于是接收处理，响应直接回给客户端。

TUN模式最大的价值在于：它不要求LVS和RS在同一二层网络，可以跨网段部署，适合异地多活的场景。但代价也很明显：所有RS必须支持IP隧道协议（ipip），配置复杂度提升，而且隧道封装本身带来额外开销，性能会比DR模式略差。所以TUN模式实际使用的频率并不高。

FULLNAT不是LVS原生协议，而是阿里等大厂在LVS基础上做的增强改进版本。它的特点是：LVS不仅改写目标IP，还改写源IP，也就是说客户端看到的源IP是LVS的内网IP，而不是真实客户端IP。这样做的好处是回包可以强制走LVS，解决了LVS和RS跨网段的问题；代价是客户端真实IP会被隐藏，如果后端需要记录来源IP，必须通过TCP option等方式传递，做起来比较麻烦。

了解了这些模式，选型思路其实很清晰：

模式	回包路径	网络要求	性能	配置复杂度	适用场景
NAT	请求响应都过LVS	LVS与RS可跨网段	中低	低	小流量、学习入门
DR	仅请求过LVS	LVS与RS同二层网络	高	中	生产环境首选
TUN	仅请求过LVS	可跨网段，要求RS支持隧道	中高	高	异地多活
FULLNAT	请求响应都过LVS	LVS与RS可跨网段	高	高	大规模集群、云环境

3. 调度算法：LVS分流的“大脑”

工作模式决定数据包怎么走，调度算法决定数据包给谁。LVS官方提供了十种左右的调度算法，分静态和动态两大类。静态算法不看后端实际负载，单纯按规则来；动态算法会结合后端的当前连接数等实时指标做决策。理解“为什么选这个算法”比记住算法名字重要得多，因为选错算法，轻则负载不均，重则服务雪崩。

3.1 静态调度算法：RR、WRR、SH、DH

RR（Round Robin），轮询，最简单。请求一个接一个轮流分配给各RS，做到完全平均，但忽略了一个事实：不同RS的硬件配置可能不一样，老机器和新机器扛的并发能力完全不同。所以实际中RR更多作为学习示例，或者后端机器配置完全一致时使用。

WRR（Weighted Round Robin），加权轮询，是RR的升级版。给每台RS设一个权重值，比如新机器权重4，老机器权重1，那么每5个新请求中，4个分给新机器，1个分给老机器。权重值通常根据机器CPU核数、内存大小、网络带宽等综合评估。这个算法在生产中的使用频率很高，因为它简单又可控。

SH（Source Hashing），源地址哈希。对客户端IP做哈希计算，同一个IP的请求总是分给同一台RS。这解决了会话保持的需求：用户登录状态存在本机内存里，如果第二次请求被分到别的机器，会话就丢了。有状态服务、依赖本地Session的应用，可以用SH来兜底，但它的代价是负载可能不均衡——某个热门网段的IP可能把一台机器打满，其他机器闲着。

DH（Destination Hashing），目标地址哈希。按请求的目标IP做哈希，主要用在多级缓存架构中：同一个目标IP的请求总是被分发到同一台缓存服务器，提高缓存命中率。这个算法用得少，但在特定架构中价值很大。

3.2 动态调度算法：LC、WLC、SED、NQ等

动态算法的核心是“结合后端RS的当前连接数来做决策”。

LC（Least Connections），最少连接数。哪台RS当前活跃连接最少，就把新请求分给谁。这个算法比RR智能，但有个缺陷：如果所有RS权重一样，它是有效的；如果权重不同，可能出现权重高的机器连接数多、权重低的机器连接数少，但新请求依然被分到权重高的机器的情况。

WLC（Weighted Least Connections），加权最少连接，是LC的升级版、也是LVS默认算法。它的计算公式是：(当前连接数 / 权重) 最小者优先。比如RS1权重2，当前连接数10，比值5；RS2权重1，当前连接数4，比值4，那么新请求会分给RS2。这个公式把机器的处理能力权重和实时负载结合起来了，实用性和公平性都不错，所以成为默认算法。

SED（Shortest Expected Delay），最短期望延迟，是WLC的一个变种。它计算的是(当前连接数 + 1) / 权重，额外考虑了一个“新连接到来后的预期负载”，避免某些RS在权重被压满的前一刻仍然接收新请求。当各RS权重差异较大时，SED比WLC更均衡。

NQ（Never Queue），永不排队，是SED的改进版：如果所有RS的连接数都没有超过某个阈值，新请求直接分配给空闲的RS；如果没有完全空闲的，才用SED的逻辑。它的好处是减少请求在调度器端的排队等待。

LBLC、LBLCR这两个算法都是基于“目标地址的局部性”做调度的，用在Web Cache集群场景中，生产环境普通后端服务用得少，这里不展开细说。

3.3 实际选型建议：不同业务选什么算法

我给一个简单可执行的选型逻辑：

后端无状态、各机器配置一致，且没有会话要求的简单场景：直接用RR，简单清晰，排查问题也方便。
后端机器配置参差不齐：选WRR或WLC，并在配置里把权重按机器性能设好。
后端是有状态服务，依赖本地Session：选SH（源地址哈希），把“同一个用户”钉在同一台机器。
高并发短连接场景（比如API网关、消息推送入口）：推荐WLC，动态负载更均衡。
涉及缓存集群、希望提高命中率：考虑DH或LBLC，把同一目标IP的请求固定到同一缓存节点。

要特别强调一点：调度算法不是“一配永逸”的。业务流量模型变化时，算法需要跟着调整。我见过不止一次，线上从RR换到WLC之后，某几台机器负载立刻降下来，整体吞吐反而涨了。关键是观察数据、权衡取舍，不要迷信某一个算法。你可以在LVS上用ipvsadm -E动态修改调度算法，不影响现有连接，这个操作在生产环境是可以直接执行的。

4. 从零配置一套LVS负载均衡集群（DR模式）

原理说完了，下面进入实际操作环节。我用最常见的DR模式，配一套“LVS调度器 + 两台真实服务器”的最小高可用集群，然后把keepalived也带上，这样调度器挂掉一台后vip会自动漂移，整个集群才算完整。拓扑如下：

LVS主：192.168.1.10
LVS备：192.168.1.13
VIP：192.168.1.100
RS1：192.168.1.11，运行Nginx
RS2：192.168.1.12，运行Nginx

所有机器都是CentOS 7.x/8.x环境，如果你用的是Ubuntu，命令稍有差异，但原理完全一样。

4.1 调度器（LVS节点）的配置步骤

第一步，安装ipvsadm管理工具。LVS的内核功能ipvs在主流Linux发行版中默认已经编译为模块或内置，不需要额外装内核组件，但管理工具必须装：

bash复制yum install -y ipvsadm   # CentOS/RHEL
apt install -y ipvsadm   # Ubuntu/Debian

装完后可以用ipvsadm -L查看当前规则，初始应该什么都没有。

第二步，开启IP转发。虽然DR模式LVS不修改IP地址，但LVS本身要把收到的数据帧转发给后端RS，所以内核必须支持转发：

bash复制echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf
sysctl -p

第三步，配置VIP。把VIP绑定在LVS的网卡上，比如eth0的别名eth0:0：

bash复制ifconfig eth0:0 192.168.1.100 netmask 255.255.255.255 up

注意这里子网掩码填的是255.255.255.255，不是常见的255.255.255.0。原因是VIP不应该响应ARP广播，避免多台设备对一个VIP进行ARP竞争。如果你填成24位掩码，可能引发ARP冲突问题。为了让配置重启后依然生效，需要把这个IP写入网络配置文件，CentOS下可以新建/etc/sysconfig/network-scripts/ifcfg-eth0:0，内容为：

code复制DEVICE=eth0:0
BOOTPROTO=static
IPADDR=192.168.1.100
NETMASK=255.255.255.255
ONBOOT=yes

第四步，添加LVS转发规则。用ipvsadm定义一个虚拟服务器，然后添加两台RS：

bash复制# 添加虚拟服务器，-A表示add，-t表示TCP协议，-s指定调度算法为wlc
ipvsadm -A -t 192.168.1.100:80 -s wlc

# 添加真实服务器，-a表示add，-r表示real server，-g表示DR模式（gatewaying）
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11 -g -w 1
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.12 -g -w 1

保存规则，防止重启丢失：

bash复制ipvsadm-save > /etc/sysconfig/ipvsadm
systemctl enable ipvsadm

我遇到过一个细节：如果在第3步先把VIP配好，再执行ipvsadm添加规则，是正常的；但如果VIP还没配置就添加规则，ipvsadm命令本身不会报错，但规则不会生效，因为内核找不到对应的本地地址。所以顺序很重要：VIP绑定优先。

4.2 RS节点配置：ARP抑制和VIP绑定

RS节点的配置是DR模式最容易出错的地方。它有两个核心动作：把VIP绑到lo接口上，并抑制ARP响应。

为什么要绑定VIP？因为LVS在DR模式下把数据帧发过来，帧里的目标IP是VIP，RS收到之后发现本地没有这个IP，直接就把包丢了。必须让RS“认领”这个VIP，同时又不让它对外广播“我有这个IP”，否则客户端直接ARP询问VIP时，RS也会抢答，导致流量绕过LVS直接打到RS上，负载均衡就失效了。

第一步，绑定VIP到lo接口的别名lo:0：

bash复制ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up

第二步，配置ARP防火墙参数，写进/etc/sysctl.conf：

code复制net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2

然后执行sysctl -p生效。这两个参数的含义需要理解一下：

arp_ignore = 1：只回答目标IP是本机“接收地址”的ARP请求。因为VIP绑在lo上，而ARP请求VIP时，目标IP确实是本机地址，按理说会响应。但由于VIP配在lo接口上，而且设置了arp_ignore = 1，结合后面的arp_announce = 2，可以让内核不主动广播这个VIP的MAC信息。实际经验是，arp_ignore = 1, arp_announce = 2这套组合在绝大多数场景下都是有效的。
arp_announce = 2：对外发送ARP通告时，使用网卡上最合适的地址作为源IP，不使用VIP。这样RS在对外通信（比如回包给客户端）时，不会把VIP通告出去。

有人会问，为什么不在eth0上绑VIP？原因很简单：eth0和LVS在同一网段，如果eth0绑VIP并响应ARP，那VIP就变成全网可见了。绑在lo接口上，LVS通过二层MAC转发RS时，RS会认为VIP是本机地址从而接受数据帧，同时因为lo不参与外部网络通信，自然不会对外通告VIP，从而实现“对外隐藏、对内可见”的效果。

第三步，如果RS上默认路由的网关和LVS不在同一网段，还要确保回包路由能正常到达客户端。通常RS的默认网关指向自己所在网段的出口即可，不需要特意配置。

完成之后，可以用ip addr show确认VIP已在lo上，然后用ping -I lo 192.168.1.100测试本机能否走lo访问VIP。注意：在外面其他机器上ping VIP，正常情况下只有LVS会响应，RS不应响应，这是判断DR模式是否配置正确的关键点。

4.3 引入keepalived：主备双机高可用

上面的配置只有一台LVS，如果这台机器挂了，整个集群就瘫痪了。生产环境必须给LVS做高可用，最经典的做法就是配合keepalived。

keepalived的核心是VRRP协议，它让主备两台LVS共享一个VIP：正常情况下VIP绑在主LVS上，备机通过心跳检测到主挂了之后，自动接管VIP，流量切换到备机继续服务。整个切换过程对客户端是透明的。

在LVS主、备机上分别安装keepalived：

bash复制yum install -y keepalived

主LVS的keepalived.conf核心配置如下：

code复制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 1111
    }
    virtual_ipaddress {
        192.168.1.100/32 dev eth0
    }
}

virtual_server 192.168.1.100 80 {
    delay_loop 6
    lb_algo wlc
    lb_kind DR
    protocol TCP

    real_server 192.168.1.11 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
    real_server 192.168.1.12 80 {
        weight 1
        TCP_CHECK {
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

备机的配置只需把state改成BACKUP，priority改成90，其他保持一致。比较关键的是virtual_router_id必须一致，否则两台机器没法互相识别对方的VRRP消息；auth_pass也要一致。

TCP_CHECK的作用是健康检查：keepalived周期性探测后端RS的80端口，如果连续几次探测失败，就自动把该RS从转发列表中摘除。这个机制非常重要，因为LVS本身不感知后端RS是否存活，如果没有健康检查，一个后端挂了之后流量照样往它身上打，用户就会遇到打不开页面的情况。

配置完成后启动keepalived：

bash复制systemctl start keepalived
systemctl enable keepalived

启动之后，ip addr可以看到VIP已经自动绑定到主LVS的eth0上，ipvsadm -L可以看到keepalived自动把RS加进了转发规则。这样一套完整的DR模式LVS集群就成型了。

5. 高频报错与排障实录：从“different numbers of ports”说起

搜索结果里有个很典型的关键词：“LVS中报错different numbers of ports”。这是很多新手在配置LVS时会撞上的错误，背后隐藏着对LVS端口映射机制的理解误区。这一章就把这类高频问题集中整理一遍，每个都给出排查思路和解决方案。

5.1 报错“different numbers of ports”是什么原因

这个报错发生在执行ipvsadm添加真实服务器时。比如你执行了：

bash复制ipvsadm -A -t 192.168.1.100:80 -s wlc
ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.11:8080 -g

第二条命令会直接失败，报错信息是：different numbers of ports。

root cause很简单：LVS在同一个虚拟服务器定义中，默认要求后端真实服务器的端口和VIP端口保持一致。也就是说，如果你定义的是一个:80的虚拟服务，那么添加的RS端口也必须是:80，写成:8080就会报这个错。在很多其他负载均衡器（比如nginx upstream）里，前端端口和后端端口可以不一样，大家习惯了这种灵活性，到了LVS这里就容易踩坑。

但现实业务中经常有“前端80，后端8080”的需求，怎么办？有两个正规解法：

方法一：后端服务直接改成80端口，最简单粗暴，但是每次都要改应用配置。
方法二：使用防火墙标记（FWM，Firewall Mark）模式。先用iptables给匹配的流量打上标记，然后LVS基于这个标记做调度，标记模式下端口可以不一致。比如：

bash复制iptables -t mangle -A PREROUTING -d 192.168.1.100 -p tcp --dport 80 -j MARK --set-mark 100
ipvsadm -A -f 100 -s wlc
ipvsadm -a -f 100 -r 192.168.1.11:8080 -g
ipvsadm -a -f 100 -r 192.168.1.12:8080 -g

这里-f 100表示防火墙标记为100，相当于把“目标为VIP:80”的流量归为一个虚拟服务。后端RS的端口写成8080就不会报错了，因为LVS在FWM模式下不再校验端口一致性。

第二种方法虽然绕过了限制，但多了一层iptables逻辑，排障时链路更长。能统一端口就统一端口，这才是根治方案。

5.2 配置没问题但请求不通：重点检查ARP和路由

DR模式集群配完之后，最大的排查难点就是“配置看起来全都对，但访问VIP就是不通”。这种问题十有八九出在ARP抑制或路由上。

第一个高发点：RS的ARP参数没生效。有次我帮同事排查，发现/etc/sysctl.conf里明明写了arp_ignore = 1，但用sysctl -w手动改过之后重启机器，配置又还原了。后来发现问题是内核模块加载顺序，lo接口的配置在sysctl之前生效导致参数没匹配上。解决方法是同时设置net.ipv4.conf.all.arp_ignore和net.ipv4.conf.lo.arp_ignore，因为部分内核版本对all和具体接口的配置优先级处理并不一致。

第二个高发点：绑在lo上的VIP子网掩码写错。如果你写成ifconfig lo:0 192.168.1.100 netmask 255.255.255.0 up，RS会因为地址在同一个子网而对外产生ARP广播，广播自己的VIP地址，直接把整个二层的ARP表搞乱。正确写法必须是netmask 255.255.255.255，让内核认为VIP是一个独立的主机地址，不参与子网广播。

第三个高发点：在RS本机上curl VIP测试不通。这也是因为请求的源IP和目标IP都是VIP，LVS转发时不做源地址转换，RS收到请求回包时，目标IP是VIP，而VIP就在本机上，就导致丢包或者走错路由。这个场景建议用curl --interface eth0 http://192.168.1.100强制指定出口网卡，或者干脆用另一台机器测试。

5.3 后端RS挂了但流量还在转：健康检查与摘除机制

LVS本身只是转发引擎，不承载健康检查功能。如果你只用了ipvsadm手工添加RS，没有任何健康检查机制，那么RS挂掉之后，LVS依然会把请求分发给它，用户访问自然出错。

生产环境一定要用keepalived来管理LVS规则，用它的TCP_CHECK或HTTP_GET探测后端存活状态。keepalived探测到后端故障后，会自动把它从ipvsadm规则中摘除。有个容易被忽略的点是delay_loop参数，它控制健康检查的周期，默认单位是秒。如果后端服务启动比较慢，或者健康检查间隔设置得过短，可能出现“后端正在启动但已被摘除，然后又被加回来”的情况，导致请求时不时失败。我一般把delay_loop设为6秒，connect_timeout设为3秒，nb_get_retry设为3次，这样既能快速摘除故障节点，又不会误伤正在重启的节点。

另外，如果后端RS有多个端口需要同时检测（比如80是业务，443是另一个业务），一定要在同一个real_server块里配置多个健康检查端口或使用MISC_CHECK，不要漏掉，否则会出现“80端口正常但业务已经不可用”的隐蔽故障。

5.4 LVS软连接问题：连不上、闪断、TIME_WAIT堆积

还有一个热词是“lvs软连接softconnect”。LVS本身不叫“软连接”，但这组搜索词透露出一个常见场景：通过LVS建立的连接非常不稳定，表现为偶尔连不上、连接秒断、频繁TIME_WAIT堆积。这个现象跟LVS自身配置关系不大，更多是连接跟踪和TCP参数调优问题。

记住一个原则：高并发场景下，连接跟踪表（nf_conntrack）是最容易先爆的资源。如果访问LVS的并发连接数极大，而/proc/sys/net/netfilter/nf_conntrack_max设置得不够大，新连接会被直接丢弃，表现就是“间歇性连不上”。排查命令是：

bash复制cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

如果count接近或等于max，就该调大了，同时缩短连接跟踪的超时时间：

bash复制sysctl -w net.netfilter.nf_conntrack_max=2000000
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300

TIME_WAIT堆积的问题，多出现在后端RS本身没有开启net.ipv4.tcp_tw_reuse（注意新内核中tcp_tw_recycle已废弃，不要乱开）或大量短连接场景。正常的TCP四次挥手会产生TIME_WAIT，数量稍多不用怕，但如果端口耗尽、连接拒绝，就需要打开tcp_tw_reuse并设置合理的tcp_fin_timeout：

bash复制sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_fin_timeout=15

要注意，NAT模式下的LVS会改写IP，导致连接跟踪压力更大。DR模式因为只改MAC，连接跟踪的压力小很多，这也是DR模式在性能上的又一优势。

6. LVS与softconnect的取舍：我的一些扩展思考

从搜索热词里看到“lvs软连接softconnect”，这里单独提一下softconnect。它是腾讯开源的一个软件负载均衡器，基于DPDK实现，主打用户态高性能转发，单机性能指标非常激进。很多人会纠结：有softconnect这种新方案，LVS是不是过时了。

我的看法是：不要盲目追新，也不要固步自封。LVS和softconnect走的是两条完全不同的技术路线。

LVS跑在内核态，优点是稳定、通用、生态成熟，配合keepalived能快速搭建高可用架构，几乎所有的Linux发行版都内置支持，坑都被前人踩得差不多了。缺点是它受限于内核协议栈的性能边界，单机吞吐量有天花板，想要继续压榨性能，需要对内核网络参数做大量调优，而且有些优化手段（比如多队列网卡、CPU亲和性绑定）依赖硬件和驱动，不是所有环境都能用。

softconnect这类基于DPDK的方案，把网卡数据直接拉到用户态处理，绕过了内核协议栈，性能确实惊人，非常适合超大规模流量、超高并发连接数的场景。但代价也很直接：部署复杂度高、依赖特定网卡和驱动、需要专门的开发团队维护、排障工具链相对薄弱。在绝大多数中小型业务中，这套方案的投入产出比并不划算。

所以我的实际建议是：

如果你的业务QPS在几万到几十万这个量级，优先用LVS + keepalived，稳定性、性能、可维护性都足够好。
如果单机LVS扛不住、需要更高吞吐，先做LVS到应用层的优化，比如开启网卡多队列、设置CPU亲和性、优化sysctl网络参数。
只有当你确实到了“LVS调优之后依然成为瓶颈”的阶段，再考虑softconnect/DPDK这类用户态方案，并且一定要有专门的人力和预算支撑。

从职业发展的角度看，理解LVS仍然是一项很有性价比的投资。它涉及到负载均衡原理、Linux网络栈、ARP协议、VRRP协议、内核参数调优等核心知识，这些知识无论未来是去做云原生的网关、服务网格，还是维护高性能基础设施，都能复用。搞懂LVS，你就掌握了网络负载均衡领域的地基。

最后再分享一个小技巧：调LVS性能时，先看ipvsadm -L -n --stats输出，关注每秒转发包数和字节数，判断瓶颈在CPU、内存还是网卡。然后结合top看软中断（si）占比，如果软中断特别高，重点做网卡多队列和CPU亲和性绑定。操作系统调优是一条链路，不要死盯某一个参数，整体看、慢慢调，效果才稳定。

从零搭建LVS负载均衡集群：DR模式原理与keepalived高可用实战