Keepalived的lvs_method应优先选DR模式，因其性能最优；次选NAT（需优化conntrack）；TUN仅作兜底。三者分别对应IPVS的DR、NAT、TUN模型，差异在于转发路径、网络约束与开销。
Keepalived 本身不直接处理四层流量转发，真正执行 LVS 转发的是 Linux 内核的 IPVS 模块；lvs_method 是 Keepalived 配置中用于指定 IPVS 工作模式的关键参数，它的选择直接影响转发路径长度、连接保持能力、NAT 开销和后端服务器网络拓扑适配性。调优它不是“改个值就变快”，而是根据实际网络结构和业务特征匹配最轻量、最直接的转发路径。
明确 lvs_method 的三种取值与核心差异
Keepalived 的 lvs_method 实际对应 IPVS 的三种工作模型：DR（Direct Routing）、NAT（Network Address Translation）、TUN（IP Tunneling）。它们在数据包处理层面有本质区别：
- DR 模式：负载均衡器仅修改请求报文的目标 MAC 地址为真实服务器的 MAC，IP 不变；响应由真实服务器直接返回客户端（绕过负载均衡器）。性能最高，但要求所有节点在同一物理网段，且真实服务器需配置 VIP 的 lo 接口并禁用 ARP 响应。
- NAT 模式：负载均衡器同时修改请求报文的目标 IP 和端口（DNAT），并将响应报文的源 IP 和端口做反向转换（SNAT）。所有流量双向经过负载均衡器，适合跨网段部署，但会成为带宽和连接跟踪（conntrack）瓶颈。
- TUN 模式：负载均衡器将原始 IP 包封装进新的 IP 包（隧道），发往真实服务器；服务器解封装后响应直回客户端。无需同网段，但增加封装/解封装开销，且需内核支持 IPIP 模块，运维复杂度高。
优先选用 DR 模式提升吞吐与并发
在满足前提条件下，DR 是四层转发性能最优解。它避免了 NAT 的地址转换和连接状态维护，内核路径最短，单机可轻松支撑 10 万+ 并发连接。启用前必须确认：
- 所有 LVS 节点（Master/Backup）与 RealServer 在同一二层广播域（如 VLAN 或物理交换机直连）；
- RealServer 上已配置 VIP 到 loopback 接口（如
ip addr add 192.168.199.119/32 dev lo）； - RealServer 禁用对 VIP 的 ARP 响应（
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore和echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce）； - Keepalived 配置中明确指定
lvs_method DR，并在 virtual_server 块中正确设置 real_server 的 IP 和端口。
慎用 NAT 模式，规避 conntrack 性能陷阱
若网络结构强制使用 NAT（如 RealServer 分布在不同子网），需重点优化内核 conntrack 行为，否则高并发下易出现丢包或新建连接延迟：
- 增大连接跟踪表上限：
net.netfilter.nf_conntrack_max = 655360； - 缩短超时时间以快速释放空闲连接：
net.netfilter.nf_conntrack_tcp_timeout_established = 300； - 关闭对非 SYN 包的连接跟踪（适用于纯转发场景）：
net.netfilter.nf_conntrack_tcp_be_liberal = 1； - 确保负载均衡器 CPU 核心数充足，conntrack 是强 CPU 密集型操作。
避免无谓封装，TUN 模式仅作兜底方案
TUN 模式因额外 IP 封装带来约 20–30μs 延迟，且隧道 MTU 易引发分片，实际生产中极少作为首选。仅在以下情况考虑：
- RealServer 完全无法调整网络配置（如云厂商托管实例，不允许配置 lo:VIP 或禁用 ARP）；
- DR 和 NAT 均不可行，且对延迟不敏感（如后台批处理接口）；
- 已启用内核
ipip模块并验证隧道连通性（modprobe ipip+ip tunnel add tunl0 mode ipip remote）。local
选对 lvs_method 是四层性能调优的第一步，它决定了流量是否绕过内核协议栈冗余处理。DR 最快但约束多，NAT 最通用但需防 conntrack 瓶颈，TUN 最灵活但代价明确。没有“万能模式”，只有“最适合当前网络拓扑的模式”。
