搞负载均衡的兄弟们应该都听过LVS这三个字母，Linux Virtual Server，从当年章文嵩博士的开源项目一直活到今天，内核里自带IPVS模块，稳得一批。这么多年过去了，Nginx、HAProxy轮番上场，但LVS依然在不少核心链路里稳如磐石，尤其是NAT、DR、TUN这三种模式，面试是高频考点，实战中更是绕不开的硬骨头。这篇文章基于我自己在虚拟机环境里反复折腾三轮实验的完整记录，把三种模式的原理差异、配置步骤、踩坑实录一次性讲清楚，给你一份能直接抄作业的实践笔记。
我第一次正经用LVS是好几年前在一套电商系统的压测环境里，当时老架构师坚持用DR模式扛流量，确实把后端压得很稳。后来我自己从零搭过NAT、DR、TUN三套集群，从ipvsadm命令一路敲到keepalived做高可用，把每个细节都摸了一遍，才敢说真正理解这三种模式。这篇文章适合两类人：一是刚接触LVS、不知道三种模式怎么选的新手；二是用过LVS但说不清数据包走向、遇到问题只会重启的同行。看完之后，你至少能搞清楚三种模式的核心差异，以及生产环境里到底该选哪一种。
1. 选型逻辑：NAT、DR、TUN到底该怎么挑
1.1 先搞清楚LVS在内核里的角色定位
LVS全称Linux Virtual Server，工作在TCP/IP协议栈的四层，也就是传输层。它的核心组件是内核里的IPVS模块，可以用ipvsadm这个用户态工具去管理。它做的事情用一句话总结：把一组后端真实服务器（RealServer，简称RS）伪装成一个虚拟IP（Virtual IP，简称VIP）对外提供服务，外部客户端访问的是VIP，实际干活的是后面一堆RS。
我习惯把LVS叫“调度器”而不是“负载均衡器”，因为它在四层做的是转发调度的活儿——只看IP和端口，不关心请求里的URL、Header、Cookie这些七层的东西。这和Nginx有本质区别：Nginx是七层反向代理，能根据路径、域名做高级路由；LVS转发速度更快，内核态处理，基本不产生用户态拷贝，而且不挑协议，TCP、UDP都能转发。
在动手配置之前，必须先和自己确认一个问题：你的业务场景到底需要哪种模式？这个问题想不清楚，后面全是白忙。很多新手上来就抄一段DR模式的配置，结果后端服务器在另一个网段，流量根本过不去，最后只能一头雾水地到处查日志。
对于不同基础的人来说，我的建议是：如果是第一次接触LVS，先把三种模式的数据包流向图画明白，再动手敲命令；如果已经有一定经验，直接跳到配置部分对比细节差异就行。
1.2 三种模式的适用场景和性能差异
先给一张我自己归纳的对比表，后面再逐个展开原理和实操。
| 模式 | 核心机制 | 请求路径 | 响应路径 | 后端要求 | 适用场景 |
|---|---|---|---|---|---|
| NAT | 网络地址转换 | 客户端 → LB → RS | RS → LB → 客户端 | 后端可用私有IP，网关指向LB | 后端数量少、无独立公网IP、安全隔离要求高 |
| DR | MAC地址改写 | 客户端 → LB → RS | RS → 客户端 | 与LB同二层网络，需抑制ARP | 大流量集群、吞吐量优先 |
| TUN | IP隧道封装 | 客户端 → LB → RS | RS → 客户端 | 可跨网段，需支持IPIP隧道 | 跨机房调度、后端分散部署 |
选型逻辑我总结成一句话：能选DR就选DR，二层不通才考虑NAT或者TUN。DR模式响应不走LB，吞吐量最高，但要求调度器和后端在同一个二层网络里，而且要对后端做ARP抑制配置，这个细节是很多初次上手的人踩坑的地方。NAT模式适合后端服务器没有公网地址的场景，调度器作为唯一的入口和出口，安全隔离效果好，但代价是所有流量都压在LB上，到达一定量级后会成为瓶颈。TUN模式适合后端分散在不同机房、不同网段的场景，通过IP隧道把请求封装转发过去，配置复杂度最高，还需要额外考虑MTU问题。
2. 数据包流向拆解：理解模式的关键一关
2.1 NAT模式：负载均衡器是唯一入口和出口
NAT模式的全称是Virtual Server via Network Address Translation，可以理解为调度器做了四层的“地址转换”。客户端请求到达LB的VIP之后，LB通过IPVS规则把数据包的目标IP从VIP改成后端RS的IP，然后再转发出去。RS处理完请求后，把响应包发回给LB，LB再把源IP从RS的IP改回VIP，最后回给客户端。
这个过程里有一个关键点：客户端从头到尾只认识VIP，它根本不知道后面有RS的存在。RS也以为自己在和LB通信，它不回包给客户端，而是回给LB。所以RS的默认网关必须指向LB的内网IP，否则响应包就不知道往哪儿送了。这个配置看起来简单，却是NAT模式最常用的故障点。
我之前实验的时候遇到过一种情况：RS上面能收到请求，curl后端本机地址也正常，但从外网访问就是不通。后来抓包一看，RS把响应包发到了自己的默认网关——公网路由器上，路由器收到一个源IP是私网地址的包，直接扔了。把RS的默认路由改成走LB内网后，问题立刻消失。
NAT模式的另一个细节是要开启内核的IP转发功能：
echo 1 > /proc/sys/net/ipv4/ip_forward这个参数告诉Linux内核：允许把从一个网卡收到的包转发到另一个网卡去。如果不开，LB收到包后直接丢弃，整个集群就瘫痪了。
对于NAT模式，我还想多说一句客户端的连接状态问题。因为LB要维护NAT会话表，所以连接跟踪（conntrack）模块会记录每一条连接的状态。在高并发场景下，如果LB的内存不够大，或者conntrack表项超时时间设置不合理，可能因为表项爆满导致新连接被丢弃。生产环境里建议调一下net.netfilter.nf_conntrack_max参数。
2.2 DR模式：只改MAC地址的“暗送”
DR模式全称Direct Routing，是三种模式里性能最好、应用最广的一种。它的核心思想是：LB收到客户端请求后，并不修改IP层的信息，只把数据链路层的目标MAC地址改成后端RS的MAC地址，然后直接在这个二层网络里把包送过去。因为目标IP仍然是VIP，而后端RS提前在lo接口上绑定了VIP，所以RS能正常收下这个包并处理请求。
这里有两个非常关键的前置条件。第一，RS上必须绑定VIP，通常是绑在lo回环接口上，不能用物理网卡。第二，RS必须配置ARP抑制，不能对外响应关于VIP的ARP请求。如果不抑制ARRP，后端服务器会把VIP的MAC地址广播出去，路由器可能会把原本应该发给LB的请求直接转到RS上，导致调度逻辑完全失控。
我总结的DR模式标准RS配置脚本如下：
# RS上执行 ifconfig lo:0 192.168.100.100 netmask 255.255.255.255 up sysctl -w net.ipv4.conf.all.arp_ignore=1 sysctl -w net.ipv4.conf.all.arp_announce=2 sysctl -w net.ipv4.conf.lo.arp_ignore=1 sysctl -w net.ipv4.conf.lo.arp_announce=2这里有个很多人不理解的地方：为什么VIP的掩码要配成255.255.255.255？原因是如果配成常规的24位掩码，那么lo接口上绑定的VIP会与本地物理网卡产生路由冲突，系统会认为这个IP属于本地网段，从而触发不必要的ARP广播。配成全1掩码，就是明确告诉内核：这个IP是本机的，但不要对它做任何网段相关的ARP通告。
DR模式下响应包直接由RS发给客户端，数据包源IP就是VIP，客户端自然认为这就是服务器本人回的包。这样就完全绕开了LB，LB只处理入站流量，单台LB能扛的吞吐量被大大释放。当然啦，代价是RS必须和LB在同一二层网络，这是很多人一开始容易忽略的硬性约束。
2.3 TUN模式：IP隧道里的接力赛
TUN模式全称IP Tunneling，它解决的是DR模式没法跨网段的痛点。原理可以这么理解：LB收到客户端请求后，把原始数据包整个封装进一个新的IP包里，外层源IP是LB的IP，外层目标IP是RS的IP，然后通过IP隧道发出去。RS收到外层包后拆包，看到里面的目标IP是VIP，而自己恰好又在lo接口上绑了VIP，于是正常处理请求，响应直接回给客户端。
用生活化的类比来说，TUN模式就像一个快递中转站。客户端把包裹寄到中转站（VIP），中转站拆开看了下发现收件人其实在另一个城市，于是重新贴了一张新面单，把包裹送到那台RS手上。RS拆开新面单，发现实际收件人地址就是VIP，自己正好负责这个地址，就签收处理了。
配置TUN模式需要内核支持IPIP协议，并且可能需要加载相应模块：
# LB和RS都要执行 modprobe ipip在RS上需要建立一个叫tunl0的隧道接口，并在这个接口上绑定VIP：
# RS上执行 ip tunnel add tunl0 mode ipip remote 0.0.0.0 local 0.0.0.0 ifconfig tunl0 192.168.100.100 netmask 255.255.255.255 up然后是LB上的调度规则，调度算法我后面细说，TUN模式的-t参数指定的是VIP，-r指定的是RS的真实IP。
TUN模式最大的坑是MTU问题。因为每个包都被额外套了一层IP头，原始包大小如果太大，隧道封装后可能超过链路的MTU，导致分片或者直接丢包。经验做法是调整后端服务的TCP MSS，或者把隧道接口的MTU调小，再配合客户端和服务端的MSS协商。这个坑我在跨机房压测时踩得很惨，大包传输一多就丢，调低MTU之后才稳定下来。
3. 亲手搭建三套集群：完整操作记录
3.1 实验环境规划与主机基础设置
我在实验环境里用了四台虚拟机，一台当客户端做压力测试，三台当服务器。操作系统是CentOS 7.9，内核版本3.10。生产环境用什么系统无所谓，关键是内核自带IPVS和必要的隧道协议。
| 主机名 | 角色 | IP地址 | 网卡 | 说明 |
|---|---|---|---|---|
| client | 压测客户端 | 192.168.122.50 | ens3 | 用来发起HTTP请求 |
| lb01 | 调度器 | 192.168.122.10 | ens3 | 承载VIP |
| rs01 | 后端1 | 192.168.122.11 | ens3 | 运行nginx |
| rs02 | 后端2 | 192.168.122.12 | ens3 | 运行nginx |
这个环境的巧妙之处在于四台机器都在同一个网段，方便同时演示三种模式。如果要做跨网段实验，只需要给rs01和rs02再加一个网段，TUN实验就能展示出优势。
开始之前要把一些基础问题处理干净，不然配置完各种奇怪问题。首先确认内核模块：
modprobe ip_vs lsmod | grep ip_vs如果输出里有ip_vs字样，说明内核已经支持。其次把SELinux关掉或者设置为宽松模式，防火墙直接停掉或者只在必要端口放行。我在实验中直接停掉防火墙，因为要排除干扰因素：
systemctl stop firewalld systemctl disable firewalld setenforce 0后端RS上需要安装并启动一个简单的HTTP服务。我用的是nginx，主要图省事：
yum install -y nginx echo "<h1>Server 192.168.122.11</h1>" > /usr/share/nginx/html/index.html systemctl start nginx后端每台的index.html内容不同，方便测试时确认请求到底分发到了哪台机器上。
3.2 NAT模式配置全过程
NAT模式要规划两个IP：一个VIP，一个后端RIP。我的实验里VIP用192.168.122.100，后端直接用现有的192.168.122.11和192.168.122.12。NAT模式对VIP位置没有特殊要求，LB上哪块网卡绑VIP都行，后端只要能路由到LB即可。
第一步，在LB上开启转发并把VIP绑定到物理网卡：
echo 1 > /proc/sys/net/ipv4/ip_forward ifconfig ens3:0 192.168.122.100 netmask 255.255.255.255 up第二步，配置IPVS调度规则，用轮询算法：
ipvsadm -C ipvsadm -A -t 192.168.122.100:80 -s rr ipvsadm -a -t 192.168.122.100:80 -r 192.168.122.11:80 -m ipvsadm -a -t 192.168.122.100:80 -r 192.168.122.12:80 -m ipvsadm -L -n这里的参数要看清：-A是新增一条虚拟服务规则，-a是添加后端真实服务器节点，-t指定协议类型为TCP，-s rr使用轮询算法，-r指定后端RS，-m表示NAT模式。
第三步，把RS的默认网关指向LB的内网IP。这一步是关键，一定要做：
# 在rs01和rs02上执行 route add default gw 192.168.122.10我为什么要把这一步单独拎出来强调？因为默认网关这个东西，如果你用正常上网的IP规划，很可能已经是路由器地址了。如果RS的网关还是公网路由器，它回包会直接发给路由器，这包就彻底丢了。NAT模式下，RS永远别把网关指向别处，只能指向LB。
配置完就可以在客户端测试访问了：
curl http://192.168.122.100/多执行几次，应该能看到轮询返回不同RS的内容。如果curl不动，大概率是RS网关问题，先ping一下VIP确认LB上没有丢包，再到RS上看默认路由。我在实验中还特意用tcpdump抓过包：SYN包到达LB后，LB把目标IP改路由RS；RS回包源IP是RS自己的地址，到了LB又被改回VIP地址。整个过程非常清晰，建议你自己也抓一遍，比看十篇文章都管用。
3.3 DR模式配置全过程
DR模式的环境要求和NAT完全不同，它要求LB和RS必须在同一个二层网络，并且RS不能用默认网关指向LB那一套，因为响应包要直接回客户端。这就意味着，如果客户端在另一个网段，RS的默认网关必须指向实际的路由器，保证回包能正常出去。
LB部分，先把VIP绑定在网卡的别名接口上：
ifconfig ens3:0 192.168.100.100 netmask 255.255.255.255 up然后配置IPVS规则，注意最后面的参数从-m变成了-g：
ipvsadm -C ipvsadm -A -t 192.168.100.100:80 -s rr ipvsadm -a -t 192.168.100.100:80 -r 192.168.122.11:80 -g ipvsadm -a -t 192.168.100.100:80 -r 192.168.122.12:80 -gRS部分，需要把VIP绑定到lo接口的别名上，同时配置ARP抑制参数：
ifconfig lo:0 192.168.100.100 netmask 255.255.255.255 up sysctl -w net.ipv4.conf.all.arp_ignore=1 sysctl -w net.ipv4.conf.all.arp_announce=2 sysctl -w net.ipv4.conf.lo.arp_ignore=1 sysctl -w net.ipv4.conf.lo.arp_announce=2ARP抑制是DR模式的核心，一旦配置有误，可能会有两类问题。一类是RS对外宣告了VIP，导致客户端请求被中途截胡；另一类是RS不接收VIP包，导致LB转发过去后无人应答。前者表现为请求到达RS后本机nginx报错，后者表现为TCP连接建立不了。
配置完在客户端同样执行curl，多请求几次就能看到轮询效果。想确认数据包路径的话，可以在RS上用tcpdump监听任意流量，你会发现RS确实收到了目标IP是192.168.100.100的包，而物理网卡上并没有这个IP。这正好证明DR模式通过MAC改写和VIP环回绑定实现了转发。
注意，DR模式下RS的VIP掩码一定也要配置成255.255.255.255，不能配成255.255.255.0，这是个容易犯又很隐蔽的错误。我刚开始配过一次网段掩码，结果RS的路由表直接乱了，物理网卡的默认路由被覆盖，流量全部异常。
3.4 TUN模式配置全过程
TUN模式是在DR模式基础上做跨网段扩展的，所以RS侧仍然要在lo上绑定VIP，并且配置ARP抑制。区别在于LB和RS之间要建立一条IPIP隧道。
先看LB配置。假设VIP还是192.168.100.100，后端RS1在192.168.122.11，RS2在192.168.122.12，这两台RS和LB不在同一个二层网络里，这时候用DR模式没法做，改TUN模式就有戏。
LB上，把VIP绑到物理网卡，并配置IPVS规则，注意最后参数变成-i：
ifconfig ens3:0 192.168.100.100 netmask 255.255.255.255 up ipvsadm -C ipvsadm -A -t 192.168.100.100:80 -s wrr ipvsadm -a -t 192.168.100.100:80 -r 192.168.122.11:80 -i ipvsadm -a -t 192.168.100.100:80 -r 192.168.122.12:80 -iRS上，加载IPIP模块并建立tunl0接口，在tunl0上绑定VIP：
modprobe ipip ip tunnel add tunl0 mode ipip remote 0.0.0.0 local 0.0.0.0 ifconfig tunl0 192.168.100.100 netmask 255.255.255.255 up如果内核不支持modprobe ipip，可能是内核配置里没编译这个模块，需要重新编译内核或者换用包含该模块的系统。我的CentOS 7.9内核自带这个模块，没有额外麻烦。
TUN模式里RS的默认网关不需要指向LB，响应包由RS自己发回客户端，这一点和DR一致。但要注意，跨网段时RS得保证客户端能路由回来。比如客户端在192.168.50.0网段，RS自己在192.168.122.0网段，那么RS的默认网关必须能路由到192.168.50.0网段，否则响应包发不出去。
我在实验里用wrw加权轮询算法，目的是模拟生产环境后端性能不均的场景。如果你希望接下来重点看某个权重高的RS，运行ipvsadm -L -n --rate能看到每个RS的连接数和权重比例。
配置完成后，从客户端访问VIP，再用ipvsadm -L -n查看连接分布，你会看到流量经过LB后，被封装成隧道包发给RS。理论上跨机房、跨网段的场景都可以这么实现，唯一要重点关注的就是MTU值。
4. 高可用、压测对比与排坑经验
4.1 keepalived实现VIP自动漂移
单台LVS跑生产，调度器挂了整个集群就废了，这肯定不行。业界标准做法是keepalived做VIP漂移。keepalived通过VRRP协议让两台LB组成一个高可用集群，正常情况下VIP在备用LB身上，一旦主LB故障，VIP自动漂移到备用LB，客户端无感知。
keepalived.conf的核心配置其实不复杂，下面是我实验用的主LB配置：
global_defs { router_id LVS_MASTER } vrrp_instance VI_1 { state MASTER interface ens3 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.122.100/24 dev ens3 } } virtual_server 192.168.122.100 80 { delay_loop 6 lb_algo rr lb_kind DR protocol TCP real_server 192.168.122.11 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 192.168.122.12 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }备LB的state改成BACKUP，priority改成90，其余保持一致。注意keepalived配置里的lb_kind要和实际用的LVS模式对应。如果写错，会出现VIP正常，但流量不打到RS的情况。
keepalived自带的健康检查会定期探测后端RS的TCP端口。如果RS的nginx挂了，keepalived会自动把这条real_server从规则里摘掉，请求就不会打到故障机器上。这个功能实际上是生产环境最刚需的部分，比手工执行ipvsadm命令靠谱得多。
我在实验中专门测试过一次：手动停掉rs01的nginx，然后观察ipvsadm输出。大约几秒后，rs01就从规则列表里消失了，所有流量都到了rs02。重启rs01的nginx后，它又自动加回来。这个恢复过程完全不需要人工干预。
4.2 常见故障排查速查表
搞LVS最烦的就是现象看起来一模一样，原因却五花八门。我把实验中遇到的典型问题整理成一张速查表，遇到问题直接对号入座。
| 故障现象 | 可能原因 | 解决办法 |
|---|---|---|
| curl VIP超时，ping VIP通 | NAT模式下RS默认网关没指向LB | 在RS上执行route add default gw LB内网IP |
| 请求偶尔通偶尔不通 | 轮询到某一台RS时报错，RS的nginx挂了 | 检查每台RS服务状态，用ipvsadm -L -n看节点状态 |
| 客户端能连上但页面白屏 | RS响应包过大，超过链路MTU | 检查RS到客户端的链路MTU，调整nginx的sendfile或调低MTU |
| 只有一台RS在接收流量 | 调度算法问题，权重配置异常 | 查看ipvsadm -L -n --rate，确认lb_algo和weight |
| 后续请求全部集中到同一条连接 | 客户端开启HTTP keep-alive | LVS四层模式天然支持连接保持，客户端连接不关闭就一直在同一RS |
| DR模式下VIP地址冲突 | RS的ARP抑制配置没生效 | 检查sysctl参数，尤其是conf.lo.arp_ignore是否配置 |
| TUN模式大包丢失 | 隧道封装导致MTU超限 | 在RS上把tunl0的MTU调小，或调整TCP MSS |
| NAT模式下RS收到包但回不了 | RS的默认路由指向公网网关 | 在RS上把默认路由指向LB |
| keepalived启动但VIP不漂移 | virtual_router_id冲突或者认证不一致 | 检查两台LB的router_id和auth_pass是否匹配 |
| ipvsadm提示无权限 | 内核模块没加载 | modprobe ip_vs后再执行ipvsadm |
这张表背后每个问题我都实际踩过。尤其是TUN模式MTU问题，当时压测脚本一跑就丢包，排查了很久才发现是隧道封装把包撑爆了。后来直接在内核参数里调整TCP MSS编辑，问题才彻底解决：
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu这个命令告诉防火墙自动调整TCP的MSS值，让它和链路MTU匹配，避免分片。
4.3 实测数据与我的最终选型建议
我在实验环境里用ab做了简单的HTTP压测，单台LB、两台RS，并发100，总请求数10000。结果很直观：DR模式吞吐量最高，NAT模式大概是DR的六成，TUN模式因为封装开销比DR稍低一些。这个比例在生产环境会受CPU性能、内核版本、网络拓扑影响，仅供参考，但趋势是一致的：NAT模式天然要承担双倍流量，性能上限最低。
如果让我给一个最终选型建议，我会这样说：
- 后端和LB在同一个机房同一个二层网络，果断选DR，这是吞吐量和配置复杂度之间最平衡的选择。
- 后端没有独立公网IP，或者你希望屏蔽后端的真实地址，选NAT，但一定要给LB足够的CPU和带宽，并且规划好连接跟踪表的容量。
- 后端分散在多个机房，或者需要做跨地域容灾调度，选TUN，但提前把MTU调通，不要等上线了再改。
- 如果只是想做简单的四层负载均衡，不想维护这么复杂的配置，可以考虑直接用HAProxy或者Nginx的stream模块，但LVS在性能上仍然有优势，尤其在高并发TCP场景下。
我个人在项目里用得最多的是DR模式加keepalived这套组合。配置成熟、坑都被人踩过了，文档也全，出问题翻社区经验很快就能定位。TUN模式我用的最少，只有在跨机房容灾的场景下才动用，因为每次调MTU和路由都够喝一壶的。
最后分享一个实验里的小技巧：在配置完LVS之后，不要急着上压测工具，先用ipvsadm -L -n --stats看一下每个RS的活跃连接数，再用tcpdump抓VIP上的包对比实际转发路径。我见过太多同行把规则配好了，curl通了，就以为万事大吉，结果压测一出并发就暴露问题。每次抓包对比一下数据包流经的接口和IP变化，能让你对三种模式的理解深入一大截。这些实验做完之后，我最大的感受是：LVS这东西，原理不下功夫，配置抄再熟也只是个工具人；把数据包走向吃透，三种模式在你眼里就是一层窗户纸。
