Linux Virtual Server（LVS）在四层负载均衡场景中承担着大量并发连接，其中NAT模式以及配合iptables策略使用时，内核连接跟踪表（nf_conntrack）的容量会直接影响转发能力。当连接跟踪表被占满，内核会丢弃新连接，表现为客户端偶发连接超时、已有连接正常但新建失败。解决这一问题的思路并不是简单把表调大，而是要结合内存开销、哈希效率、超时回收和LVS工作模式做整体优化。
一、先区分IPVS连接表与nf_conntrack
LVS核心模块IPVS维护着一套自己的连接表，记录客户端来源、目标VIP、后端真实服务器映射关系以及NAT转换信息。这套表由ip_vs_conn结构体管理，大小取决于连接数和内存，不直接受nf_conntrack_max控制。而nf_conntrack是Netfilter框架中的通用连接跟踪表，当报文经过带有状态跟踪的iptables规则时，内核会为每条流建立conntrack条目。
在很多LVS NAT部署中，管理员为了限制访问来源或做端口过滤，会添加iptables规则。一旦规则中使用了-m state或-m conntrack，或者默认的防火墙策略要求状态匹配，所有经过LVS的流量都会产生conntrack条目。此时nf_conntrack_max就成为瓶颈。如果LVS采用DR或TUN模式，返回流量直接回给客户端，通常不需要NAT转换，也很少依赖conntrack，因此这些模式下表满问题不常见。区分两者可以避免无意义地调大通用连接跟踪表。
二、连接跟踪表大小与哈希参数的计算
nf_conntrack_max决定连接跟踪表最多容纳多少条连接。该值默认由内核根据物理内存自动计算，通常是内存MB数乘以一定系数，例如64GB服务器默认可能只有几十万条。对于高并发LVS，默认值偏保守。调整前应先评估单条conntrack条目占用内存。一个IPv4 conntrack条目大约占用300字节到400字节，包括连接状态、两端地址端口、协议信息以及扩展字段。若将max设置为200万，内存占用约为600MB到800MB，需要确认服务器有足够空闲内存。
与max配套的是哈希桶数量nf_conntrack_buckets，通常通过模块参数hashsize指定。哈希桶数量影响查找效率：桶太少会导致每个桶上的链表过长，即使表未满，CPU在查找和插入时也会明显升高。一般建议hashsize为max的四分之一到二分之一。例如max为2097152时，hashsize可设为524288。内核在加载nf_conntrack模块时可通过参数设置：
# 编辑 /etc/modprobe.d/nf_conntrack.conf options nf_conntrack hashsize=524288
但hashsize必须是2的幂，也可以不手动指定，内核会根据max计算合适的hashsize。更常用的做法是通过sysctl调整max，同时让hashsize保持自动计算。若要持久化模块参数，需要重新加载模块后才能生效，因为hashsize在模块加载时确定。
调整max的持久化方法是在/etc/sysctl.conf或/etc/sysctl.d/99-lvs.conf中写入：
net.netfilter.nf_conntrack_max = 2097152
执行sysctl -p后立即生效。需要注意，如果当前加载时hashsize过小，仅调大max不会改变hashsize，极端情况下查找性能仍可能受限。可以在/proc/sys/net/netfilter/nf_conntrack_max和/sys/module/nf_conntrack/parameters/hashsize中确认两个值是否匹配。
三、超时参数与回收策略优化
连接跟踪表占满不一定是总容量不够，很可能是大量连接处于TIME_WAIT或ESTABLISHED僵尸状态没有被及时回收。内核为不同协议和状态定义了超时时间，例如TCP的nf_conntrack_tcp_timeout_established默认长达432000秒（5天），对于短连接密集的负载均衡场景明显过长。如果LVS主要转发HTTP短连接，可以将established超时缩短到1800秒甚至600秒，让完成数据交换但未正常关闭的连接更早释放。
需要关注的一组sysctl参数如下：
net.netfilter.nf_conntrack_tcp_timeout_established = 1800 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60 net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120 net.netfilter.nf_conntrack_udp_timeout = 30 net.netfilter.nf_conntrack_udp_timeout_stream = 120
这些值的单位是秒。缩短超时能降低表占用峰值，但要避免把正常长连接误杀。如果LVS后端有WebSocket、数据库长连接等长时间空闲的TCP会话，established超时不应低于业务最大空闲间隔。另一个易被忽略的是UDP流超时，DNS、视频流等场景下默认30秒可能太短，导致频繁新建；而QUIC等协议需要更长的stream超时。
此外还可以启用tcp_tw_reuse和调整tcp_tw_recycle，但注意tcp_tw_recycle在NAT环境下容易造成时间戳混乱，现代内核已经不建议开启。更安全的是缩小TIME_WAIT时长或让LVS自身工作在DR模式，绕开conntrack对TIME_WAIT的跟踪。
四、LVS不同模式下的优化取舍
DR模式是高性能LVS部署的首选，因为响应流量不经过负载均衡器，IPVS只需要维护连接表而无需修改报文地址。此时应该尽量减少iptables中依赖conntrack的规则，甚至关闭不必要的防火墙状态跟踪。可以让iptables仅处理管理接口的访问控制，转发路径保持纯净。对于必须使用NAT模式的场景，连接跟踪不可避免，但可以把nf_conntrack_max设置得足够高，并配合超时参数控制占用。
IPVS自身也有超时参数可以优化。ipvsadm -l --timeout可以查看TCP、TCP FIN、UDP超时。默认TCP超时为900秒，TCP FIN为120秒，UDP为300秒。可用ipvsadm --set tcp tcpfin udp调整，例如：
ipvsadm --set 600 60 120
这样可以让IPVS连接表更积极地回收，降低内存占用。在高并发短连接压力下，缩短IPVS超时和conntrack超时同样重要，两者分别作用于不同层次。
五、监控与自动化调整
调参后需要建立监控，而不是一次性设置。重点关注/proc/sys/net/netfilter/nf_conntrack_count当前条目数占max的比例，以及dmesg中是否出现nf_conntrack: table full。可以在LVS节点上定时采集：
# 查看当前连接跟踪计数 cat /proc/sys/net/netfilter/nf_conntrack_count # 查看最大容量 cat /proc/sys/net/netfilter/nf_conntrack_max # 查看哈希桶数 cat /sys/module/nf_conntrack/parameters/hashsize # 统计各状态分布 conntrack -S
conntrack工具来自conntrack-tools包，输出各类协议状态计数，能帮助识别是哪些状态占用了大量条目。如果TCP_SYN_SENT或TIME_WAIT占比异常高，说明客户端可能存在连接不完成或短连接过多，可以从业务侧做连接复用。
对于极端流量突增，还可以配置conntrackd做状态同步或配合fail2ban临时限制异常来源，但核心仍是容量与回收速度匹配。LVS节点内存充足时，将max调到数百万人级是可行的，但需确保hashsize足够大，否则CPU会在链表遍历上消耗过多。
总体来看，LVS连接跟踪优化不是单独增大一个参数那么简单。它涉及IPVS与Netfilter的关系、NAT模式的选择、超时策略以及业务连接特征。合理的顺序是先确认LVS工作模式是否真的需要conntrack，再根据内存和并发量计算max，然后调整超时参数加速回收，最后通过监控持续修正。这样可以在不牺牲转发性能的前提下，消除连接跟踪表满导致的新建连接失败问题。
