不用管外面那些关于“LVS”的各种热搜词了芯片验证用的Calibre LVS和本文要讲的Linux Virtual Server完全是两码事。我这次要拆的就是Linux服务器负载均衡里最常见的LVS NAT模式从原理到部署再到那些文档里不会明说的坑一次讲透。如果你正在搭实验环境或者打算在生产环境里用LVS做四层负载均衡这篇应该能帮你省下不少排查时间。NAT模式最大的优点是好理解、好上手后端服务器不需要动任何网络配置也不用担心ARP问题比DR模式省心得多。但它又有一个非常关键的“门槛”——所有响应流量都要绕回Director这既是它简单的原因也是它最大的瓶颈所在。很多人一开始觉得很简单一部署就出问题归根到底就是没把数据链路想明白。所以这篇文章会先把原理说到骨头里再给一套可以直接抄的部署步骤最后把我在实际环境里踩过的坑原原本本列出来。1. LVS NAT模式到底在解决什么问题1.1 名字一样东西不一样的LVS先给搜错东西的朋友指个路。芯片设计领域的“Calibre LVS”是版图与原理图一致性检查工具主要做物理验证另外还有个“LVS soft connect”的概念也是EDA领域里关于软连接检查的术语。这些和Linux服务器负载均衡没有任何关系。我下面要讲的LVS全称是Linux Virtual Server是一个内核态的负载均衡框架。工作在Linux内核的网络协议栈里通过ip_vs模块实现数据包级别的转发主要用于四层TCP/UDP负载均衡常见于Web服务、数据库中间件、邮件服务等场景。它的作者是章文嵩博士在2000年前后开源后来合并进了Linux内核主线所以任何主流Linux发行版都自带这套能力。你不需要装业务软件只需要装一个管理工具ipvsadm就能操作。1.2 NAT模式一句话说清楚LVS有三种工作模式NAT模式、DR模式、Tunnel模式。从名字就能看出来NAT模式就是利用网络地址转换来完成流量分发。它的核心逻辑是客户端访问一个虚拟IPVIP这个VIP在Director调度器上。Director收到请求后根据负载均衡算法把数据包的目标地址改写成某台后端服务器RS的IP然后转发出去后端服务器处理完请求后把响应包交还给DirectorDirector再把响应包的源地址从RS的IP改回VIP送还给客户端。在整个过程中客户端始终只感知到VIP这一个地址后面有几台RS、RS的IP是什么客户端完全不知道。打个比方Director就像一个前台来访者只认前台的电话VIP前台接完电话后转给后台的某个同事RS同事办完事还要把结果交回前台由前台统一答复来访者。NAT模式就是“所有电话都从总机过一遍”的工作方式。1.3 什么场景适合用NAT模式NAT模式最适合的场景是后端服务器数量不多、响应流量不是特别夸张的中小型业务。比如一个日活几万的Web应用后端有三四台Nginx或Apache请求和响应都在几百Mbps以内这种规模下NAT模式完全能扛住。它还有一个天然优势后端RS可以和Director不在同一网段只要RS能通过路由访问到Director的转发地址DIP即可。这一点比DR模式灵活很多因为DR模式要求Director和RS必须在同一个二层网络中。另外NAT模式下RS不需要修改ARP配置不存在“VIP地址冲突”这类的坑新手部署起来心理压力小很多。但如果你做的是视频、文件下载、大图片这类“响应流量远大于请求流量”的业务建议直接放弃NAT模式改用DR模式。原因后面我会专门解释。2. NAT模式数据链路与关键参数拆解2.1 一次完整请求的“四段旅程”理解NAT模式必须先搞清楚一个数据包从头到尾经历了什么。我以最常见的HTTP请求为例假设客户端IP为CIPVIP为192.168.1.100Director的内网IPDIP为10.0.0.1后端RS1的IP为10.0.0.11。客户端发起TCP连接数据包的目标地址是VIP也就是192.168.1.100。这个VIP配置在Director的网卡上所以请求首先到达Director。Director的ip_vs模块接管这个包查一下自己的调度算法决定把请求交给哪台RS。假设选中了RS1Director会把数据包的目标地址从192.168.1.100改成10.0.0.11源地址保持不变仍然是CIP。这就是DNAT目的地址转换。改完后数据包从Director的内网网卡发出交给RS1。RS1收到这个包后发现自己就是目标地址10.0.0.11于是正常处理HTTP请求生成响应数据。响应包的目标地址是CIP源地址是RS1自己的IP。关键来了RS1的默认网关必须指向DIP10.0.0.1所以这个响应包会先发给Director而不是直接发给客户端。Director收到RS1的响应包反过来做一次SNAT源地址转换把源地址从10.0.0.11改回192.168.1.100再发回客户端。客户端看到的就是VIP在给自己回复整个过程没有任何破绽。2.2 IP转发NAT模式的命门从上面的流程能看出Director本身扮演了“路由器”的角色它必须把从一个网卡进来的包转到另一个网卡出去。Linux内核默认不开这个能力你必须显式开启IP转发。临时开启的方式echo 1 /proc/sys/net/ipv4/ip_forward永久生效修改/etc/sysctl.conf文件net.ipv4.ip_forward 1然后执行sysctl -p很多人部署完LVS发现流量不通第一反应就是防火墙、或者ipvsadm规则写错了其实最常被忽略的就是这个ip_forward。记住NAT模式下Director本质是一台NAT路由器不开转发一切都白搭。2.3 为什么RS网关必须指向Director这是NAT模式里最要害的地方。很多人配置RS时习惯性把网关指向机房的物理路由器结果就是客户端请求能到达RSRS也能正常处理但响应包直接被RS交给了物理路由器物理路由器一看目标地址是客户端IP就傻乎乎地直接把包发了出去根本没有经过Director。客户端收到一个源IP是RS地址的响应包——但它当初请求的是VIP——按照TCP/IP协议栈的规则这个包与既有的连接不匹配直接丢弃。表现就是LVS看起来配置了后端服务也没问题但客户端就是一直超时。所以NAT模式下RS的默认网关必须指向Director的DIP不能指向其他任何路由器。如果后端RS有多个网卡或者有策略路由也要确保访问客户端网段的流量优先走DIP不能有第二条路绕出去。检查RS上的路由这是最常用的命令ip route show正常情况默认路由应该长这样default via 10.0.0.1 dev eth0其中10.0.0.1就是Director的DIP。2.4 端口映射与连接表LVS NAT模式不仅能把流量转发给后端的IP还能顺便改端口这跟iptables的DNAT很像。比如你希望外面访问VIP的80端口但后端RS实际跑在8080端口完全可以在添加RS时指定端口映射。ipvsadm -A -t 192.168.1.100:80 -s rr ipvsadm -a -t 192.168.1.100:80 -r 10.0.0.11:8080 -m这里的-m参数就是开启NAT模式masquerading对应LVS的NAT转发方式。另外要特别注意的是LVS NAT模式不是“每次包都查一遍规则”那么简单它维护了一张连接跟踪表。第一个包到达时Director会把连接信息记录下来后续同一个TCP连接的所有数据包都直接按照连接表处理不需要重新调度。这就是为什么ipvsadm能看到当前活跃连接数的原因。你可以在Director上执行ipvsadm -L -n输出里会有一个“ActiveConn”列显示当前活跃的连接数这部分数据就来自连接表。3. 从零搭建一套LVS NAT3.1 拓扑与IP规划我建议第一次练手时用三台虚拟机搭建一个最经典的拓扑Director双网卡一张连“外网”一张连“内网”。如果你用的是VirtualBox或VMware可以创建两个虚拟网络一个叫外部网络一个叫内部网络。我来给一套可以直接照抄的IP规划角色网卡IP地址网关Directoreth0外部192.168.1.10/24192.168.1.1Directoreth1内部10.0.0.1/24无Directoreth0辅助IPVIP192.168.1.100/24无RS1eth0内部10.0.0.11/2410.0.0.1RS2eth0内部10.0.0.12/2410.0.0.1Clienteth0外部192.168.1.50/24192.168.1.1外部网络模拟公网环境客户端从这里的192.168.1.50访问VIP内部网络承载Director到RS之间的流量。注意RS不需要配置任何外部网络相关的IP更不需要配置VIP这是NAT模式比DR模式简单的一个重要原因。3.2 单网卡还是双网卡很多教程用单网卡也能搭建NAT模式Director只用一个网卡把VIP和DIP配在同一个网段比如Director的IP是192.168.1.10VIP是192.168.1.100RS也在192.168.1.x网段默认网关指向192.168.1.10。这种做法在小实验里能跑通但它有两个明显问题第一所有流量从同一张网卡进出Director的性能会大打折扣失去了NAT模式“内外网隔离”的意义第二内网RS和客户端在同一个二层网络很容易触发我后面要讲的“NAT回流”问题也就是内网客户端访问VIP不通的坑。所以我强烈建议正式学习和生产部署都采用双网卡方案让内网流量和外网流量物理分离。如果Director只有一张网卡确实没法加第二张那至少要用虚拟网卡VLAN子接口或者不同子网的方式把内外逻辑隔开。总之别嫌麻烦双网卡才是NAT模式的正确打开方式。3.3 Director上的配置命令在Director上安装ipvsadmCentOS/RHEL系用yumDebian/Ubuntu系用apt这里以CentOS为例yum install -y ipvsadm开启IP转发并设置为永久生效echo net.ipv4.ip_forward 1 /etc/sysctl.conf sysctl -p给eth0配置VIP用ip命令临时生效重启会丢失ip addr add 192.168.1.100/24 dev eth0配置LVS规则这里用加权轮询算法RS1权重1RS2权重2意思是后端的请求会按1比2的比例分发ipvsadm -A -t 192.168.1.100:80 -s wrr ipvsadm -a -t 192.168.1.100:80 -r 10.0.0.11:80 -m -w 1 ipvsadm -a -t 192.168.1.100:80 -r 10.0.0.12:80 -m -w 2启动并设置开机自启systemctl enable ipvsadm systemctl start ipvsadm查看当前LVS规则ipvsadm -L -n输出大概长这样IP Virtual Server version 1.2.1 (size4096) Prot LocalAddress:Port Scheduler Flags - RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.1.100:80 wrr - 10.0.0.11:80 Masq 1 0 0 - 10.0.0.12:80 Masq 2 0 0看到Forward列是Masq就说明已经是NAT模式了。有些教程会看到Route或者Tunnel那就是DR或隧道模式不是我们要的。3.4 后端RS的配置RS只需要四件事安装Web服务、监听正确的端口、保证默认网关指向DIP、确保防火墙放行相应端口。以RS1为例安装Nginxyum install -y nginx systemctl enable nginx systemctl start nginx然后确认网关是否指向DIP。如果之前网关配置不对立刻修正例如把RS1的网关设置成10.0.0.1ip route add default via 10.0.0.1 dev eth0RS上不需要装ipvsadm也不需要配置VIP更不需要任何ipvs规则。这是NAT模式最让人舒服的地方后端基本零改动。为了后续验证方便建议在两个RS上写不同的首页内容比如在/usr/share/nginx/html/index.html里分别写上RS1和RS2的标识这样从客户端访问时就能直观看出负载均衡是否生效。3.5 验证结果是否正常在客户端机器上不断访问VIPfor i in $(seq 1 10); do curl -s http://192.168.1.100/; done如果一切正常你会看到输出在RS1和RS2之间交替。因为是加权轮询RS2出现的次数大概会是RS1的两倍。再回到Director上看连接统计ipvsadm -L -n --stats输出里会有每个RS实际接收的包数和字节数通过这个能判断流量分发是否符合预期。我当年第一次验证的时候curl一直卡住不动排查了很久才发现是iptables的FORWARD链默认策略是DROP把转发流量全丢了。所以建议做实验前先在Director上临时放开FORWARD链iptables -P FORWARD ACCEPT或者写一条精确的放行规则iptables -I FORWARD -j ACCEPT等调试通过后再按生产需求收紧。这个细节能帮你省掉大量无效排查时间。4. 生产环境避坑会话保持、健康检查与调度算法4.1 会话保持同一个用户的两个请求打到两台RS怎么办负载均衡最基本的能力是“把请求分散到多台机器”但很多业务有状态典型的就是用户登录后的会话Session。用户第一次请求登录到了RS1Session存在RS1本地第二次请求被调度到RS2RS2上没有这个Session用户就直接掉线了。LVS提供了持久连接功能。配置时加上-p参数指定一个超时时间秒比如600秒内来自同一个源IP的所有请求都发给同一台RSipvsadm -A -t 192.168.1.100:80 -s rr -p 600也可以在添加虚拟服务后单独修改持久超时时间ipvsadm -E -t 192.168.1.100:80 -s wrr -p 1200注意持久连接是按源IP维度生效的不是按用户维度。如果很多人共享同一个出口IP比如公司NAT上网这些请求全被调度到同一台RS可能造成单机过载。所以最稳妥的做法是应用层做Session共享比如把Session存到Redis里这样无论请求去哪台RS都能读出登录态。4.2 健康检查LVS不健康检查后端挂了你可能不知道裸的ipvsadm不具备健康检查能力。RS网络不通了ipvsadm不会自动把它摘除请求照样往死路上一台发结果就是部分用户间歇性访问失败。这种问题在生产环境非常隐蔽尤其是流量分散到多台RS时只有一部分用户感觉到异常。最简单的方案是用keepalived来管理VIP和RS。keepalived不仅能提供VIP漂移还自带健康检查。下面是一段最简单的keepalived配置global_defs { router_id LVS_DEVEL } 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/24 } } virtual_server 192.168.1.100 80 { delay_loop 6 lb_algo wrr lb_kind NAT persistence_timeout 600 protocol TCP real_server 10.0.0.11 80 { weight 1 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } real_server 10.0.0.12 80 { weight 2 TCP_CHECK { connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } }这台机器就是主Director。如果Director本身挂了keepalived会把VIP漂移到备用Director上后端RS完全无感知。如果单纯是某一台RS的端口无法连接keepalived会把它从调度列表里摘除等恢复后再加回来整个过程自动完成。4.3 调度算法怎么选LVS支持的调度算法很多但我实际生产中用得最多的其实是这三个轮询rr和加权轮询wrr适合后端RS配置基本一致、请求处理时间差别不大的场景简单直接。加权轮询能让你按机器性能分配流量比例。最少连接lc和加权最少连接wlc适合请求处理时间差异较大的场景。比如有些请求要查数据库有些只是静态页面处理时间完全不一样单纯轮询会导致某台RS堆积大量慢请求。最少连接会动态地把新请求分给当前活跃连接最少的RS。源地址哈希sh本质上是按源IP做持久会话适合后端应用无法共享Session、必须把同一用户固定到同一台RS的场景但要注意前面说到的出口IP集中问题。我个人的习惯是后端差异不大就用wrr差异大就用wlc有会话黏滞需求就考虑sh或者persistence。没有银弹必须结合业务特点。4.4 连接表超时参数连接表有一个超时机制TCP连接如果超过一定时间没有活跃流量LVS会把它从连接表中清理掉。默认值是TCP 900秒TCP FIN状态120秒UDP 300秒。ipvsadm --set 900 120 300对于普通的HTTP请求900秒完全够用。但如果业务里有长时间保持连接的应用比如WebSocket、数据库连接池、长轮询建议把TCP超时调大一些ipvsadm --set 7200 120 300否则会出现一种诡异的现象LVS层的连接已被清理但应用层的TCP连接还活着后续数据包到达Director时查不到连接表被当成新连接重新调度导致同一连接的两端在不同RS之间跳来跳去应用直接报错。长连接场景务必要检查这个参数。5. NAT、DR、Tunnel三种模式怎么选5.1 一张表看懂三种模式很多新人选不了模式主要是对三种模式的区别没有整体认知。我把核心差异整理成了一张表对比项NAT模式DR模式Tunnel模式后端是否要改默认网关必须指向Director不需要不需要Director是否处理响应流量是否否后端是否能看到客户端真实IP能能能通过隧道头后端RS与Director二层要求无可跨网段必须在同一二层网络无可跨机房后端RS是否要配置VIP不需要需要在lo上配置并抑制ARP需要支持隧道协议性能瓶颈Director的进出双向流量Director仅处理入站流量Director仅处理入站流量后端封装隧道开销配置难度低中ARP问题麻烦高最佳场景中小规模、入门大流量、响应大的Web业务跨机房调度、大流量DR模式的响应流量不经过Director直接由RS回给客户端所以Director只承担入站流量性能远好于NAT模式这是它在大型业务中成为主流的根本原因。但DR模式要求RS和Director在同一个广播域内而且必须处理一个经典问题——VIP的ARP广播。简单说不能让RS上的VIP地址参与ARP响应否则客户端发往VIP的请求可能被其中一台RS抢答了。这需要额外配置sysctl参数比如arp_ignore和arp_announce对新手不太友好。Tunnel模式则是在IP报文外面再套一层IPIP隧道把请求封装后发给异地机房的RSRS解开隧道后直接处理并回复客户端。实现复杂还需要RS支持隧道一般业务用不到。5.2 NAT模式的最大瓶颈在响应流量NAT模式最容易被低估的地方就是“响应流量也要过Director”。很多初学者脑子里只想着“请求进来了Director转发给RS”却忘了RS的响应还要原路返回。这意味着什么意味着Director的带宽、CPU、内存必须能同时承载“下行到RS的请求流量 上行到客户端的响应流量”两条链路。举个例子假设你的服务器出口带宽是1Gbps请求流量平均200Mbps响应流量平均800Mbps看起来每个方向都没超1Gbps但注意Director是同一个出口请求和响应要复用同一张网卡200 800已经接近甚至超过1Gbps的物理上限。而且NAT模式的数据包是用户态和内核态都要进行地址转换处理包量特别大时CPU占用也会成为瓶颈。所以NAT模式特别不适合那种“响应大、请求小”的业务。如果是视频点播、大文件下载这种场景RS回给客户端的流量轻轻松松超过Director的网卡能力换DR模式才是正解。5.3 什么时候必须抛弃NAT模式我总结了几条判断标准只要命中其中一两条建议直接上DR模式响应流量远大于请求流量比如图片、视频、软件下载站。Director的网卡和CPU很容易被打满而RS到客户端之间的链路又明明很空闲。业务规模达到单机Director无法承受的包转发量。曾经有个朋友用NAT模式扛一个日UV在几十万的站点每到晚高峰Director的CPU就冲到90%以上换了DR模式后Director的CPU几乎可以忽略不计。后端RS跨网段但不想给RS配复杂路由。虽然NAT模式理论上能跨网段但跨网段后RS到DIP的路由一跳都不能少哪个环节配置错了都很难排查。跨网段场景直接使用Tunnel模式或者用云原生的负载均衡方案反而更省心。6. 常见问题与排查实录6.1 后端RS收不到任何请求如果客户端访问VIP时请求根本没有到达RS大概率问题出在Director上。按下面顺序排查先用ipvsadm -L -n确认规则存在而且Forward列是Masq如果规则不存在或者状态不对规则问题。确认Director本机是否能访问RS比如curl一下http://10.0.0.11/如果不通检查Director到RS的链路和RS防火墙。确认ip_forward已开启echo 1 /proc/sys/net/ipv4/ip_forward临时生效但要记住重启后丢失。检查iptables的FORWARD链特别是默认策略是否是DROP是的话需要放行。用tcpdump在Director的内网网卡上抓包看是否存在发往RS的数据包tcpdump -i eth1 host 10.0.0.11 -n如果Director上抓不到任何发往RS的包说明ip_vs模块没有接管流量如果抓到了但RS没反应问题就在RS那一侧。6.2 请求到了RS响应却丢了请求明明进了RS后端服务也正常处理了但客户端就是收不到响应。这时候十有八九是RS的回包路线不对。在RS上抓包tcpdump -i eth0 src host RS_IP -n或者直接看RS的路由表。如果发现默认网关不是DIP立刻改路由。注意有些系统你改了默认网关也没用因为还有一条更精确的静态路由指向物理路由器你需要一并清掉或覆盖。另外确认RS上有没有启用一些奇怪的防火墙策略比如firewalld的zone规则把源地址是客户端网段的响应包拦了。这种情况我碰到过不止一次经常是之前为了安全把某个网段给DROP了结果所有流量都正常唯独响应包被防火墙悄悄丢掉。6.3 局域网内访问VIP不通NAT回流问题这是一个非常经典的问题值得单独拿出来说。如果你的客户端、Director、RS都在同一个网段客户端访问VIP时请求经过Director的DNAT转发到RSRS处理完一看目标地址是客户端IP而客户端就在同一个二层网络里RS会直接把响应包二层发给客户端根本不经过Director。客户端收到这个响应包后发现源IP是RS的IP而不是当初访问的VIP按照TCP协议栈的规则这个包属于“不属于任何已知连接”的包直接被丢弃。表现就是外网访问VIP正常内网同一网段的机器访问VIP反而超时。解决办法有三种任选其一在RS上添加一条静态路由把客户端网段的流量强制指向DIPip route add 192.168.1.0/24 via 192.168.1.10 dev eth0如果VIP和DIP不在同一个网段把192.168.1.0/24替换成客户端所在的网段网关替换成Director的内网IP即可。这条路由让RS认为回给客户端的包必须经过Director于是响应就会先回到DirectorDirector再改源地址回VIP发给客户端。第二种方式是在Director上加SNAT规则iptables -t nat -A POSTROUTING -d 10.0.0.11 -p tcp --dport 80 -j SNAT --to-source 10.0.0.1把RS收到的请求源地址改成DIP这样RS响应时目标地址是DIP自然会把包交给网关Director。但副作用是RS上看到的客户端IP全是Director的内网IP真实IP丢失了。第三种方式最简单别在同一个二层网络里搭NAT模式实验把客户端放到独立的网络里从源头上避开这个问题。这也是我前面坚持推荐双网卡拓扑的原因。6.4 VirtualBox的NAT和NAT网络别搞混用虚拟机搭LVS实验环境的人十有八九会在VirtualBox的网络模式上翻车。VirtualBox有两种模式名字里都带NAT一个是“NAT”一个是“NAT网络”看着很像实际完全不同。“NAT”模式是给单台虚拟机用的虚拟机通过宿主机共享IP上网外部无法主动访问虚拟机内部的任何端口而且两台同时选“NAT”模式的虚拟机之间是隔离的互相根本ping不通。很多人把两台RS都设成“NAT”模式然后发现RS之间无法通信差点以为是LVS配置错了。“NAT网络”模式则不一样它是在VirtualBox里创建一个虚拟NAT网络多台虚拟机加入同一个NAT网络后它们处于同一个虚拟局域网内既能互相通信也能共享同一个NAT网关上网。所以搭LVS实验环境推荐这么设计VirtualBox里创建一个“NAT网络”用来承接Director的内网网卡和两台RS再创建一个“桥接网络”或“仅主机网络”模拟外部客户端。如果你实在不想折腾双网卡也可以把所有机器都放在同一个“NAT网络”里但要注意前面说的NAT回流问题。6.5 那些名字相似但完全无关的坑我在这行干了这么多年发现LVS相关的搜索里混着大量完全不相干的东西。这里简单提几个帮你少走弯路。Windows Server 2012 R2里的“NAT”功能是RRAS角色下的网络地址转换用于让内网机器共享一个公网IP上网跟LVS的NAT模式只是同名不是同一套体系。如果你在Windows上做实验别拿Windows的NAT配置思路去套LVS。WSL2里经常出现“检测到localhost代理配置但未镜像到WSL。NAT模式下的WSL不支持localhost代理”的提示。这是WSL2自身网络机制的问题WSL2默认运行在NAT模式它和Windows宿主之间的网络是经过转换的。如果你只是为了跑Linux命令这个提示可以忽略如果你需要从WSL里访问Windows上监听的端口需要额外配置。但这个问题跟LVS NAT模式没有关系不要混在一起排查。CentOS虚拟机选NAT模式后上不了网通常不是NAT本身的问题而是网卡没启用、DHCP没拿到IP、网关错误、DNS没配置这几类。特别是新装的CentOS很多网卡默认ONBOOTno开机时网卡根本没起来。至于“光猫路由NAT模式DNS延迟”那属于家庭网络环境的NAT转发延迟问题跟服务器端的LVS没有任何关系。如果你在本地实验时遇到DNS解析慢先换一下DNS服务器试试别一上来就怀疑LVS配置有问题。最后再分享一个小技巧如果你在实验环境里反复改来改去把规则弄乱了想全部清掉重来用这一条命令ipvsadm -C这条命令会清空所有LVS规则。如果你用keepalived管理的规则清掉后keepalived可能会立刻把规则重新加载回来这反而说明keepalived配置生效了可以放心。另外如果条件允许建议Director的操作系统不要开太新的内核尤其不要用那些带特殊安全模块的定制内核LVS在标准内核上表现最稳定。我自己踩过几次内核版本太新导致ip_vs模块加载异常、或者调度器行为不正常的坑。生产环境求稳用发行版自带的稳定内核别手痒随便换。LVS NAT模式性能上限虽然不如DR模式但作为入门、中小规模业务、以及理解Linux内核网络栈工作原理的切入点它依然是非常值得掌握的一环。把它吃透了再看DR模式和Tunnel模式的时候你会发现自己对数据包流转的敏感度完全不一样了。