连接跟踪表上限是什么
net.netfilter.nf_conntrack_max 限制内核连接跟踪表能同时记录多少条连接。iptables 与 nftables 的状态匹配、NAT 转换都依赖这张表：每个被跟踪的连接占用一个表项，网关、负载均衡、VPN 与容器节点上的连接数越大，表越容易被打满。打满之后内核会丢弃新建连接的数据包并在日志里打印 table full，业务侧表现为随机建连失败，而 CPU 与带宽可能都还很空闲。
基本信息
| 参数 | net.netfilter.nf_conntrack_max |
|---|---|
| 默认值 | 内核按可用内存自动计算，必须以本机回读为准 |
| 当前占用 | /proc/sys/net/netfilter/nf_conntrack_count |
| 满表日志 | nf_conntrack: table full, dropping packet |
| 配套参数 | 哈希桶数 /sys/module/nf_conntrack/parameters/hashsize |
| 内存开销 | 每个表项占用数百字节量级，需按目标容量估算增量 |
典型使用场景
- NAT 网关与四层负载均衡：连接数天然是节点上最高的，最易触发满表
- 容器节点：Pod 间流量经主机网络栈时会产生大量被跟踪的连接
- 排查随机建连失败：服务日志零散出现超时，dmesg 里有 table full 记录
- 容量规划：按峰值并发连接数与超时时间估算所需表容量
- 调优前后对比：用 count 与 max 的比值观察表的使用水位
监控与调整
监控与调整
sysctl net.netfilter.nf_conntrack_max # 读上限
cat /proc/sys/net/netfilter/nf_conntrack_count # 读当前表项数
conntrack -C 2>/dev/null # 需要 conntrack 工具时用它统计
dmesg -T | grep -i conntrack | tail # 查满表日志
sysctl -w net.netfilter.nf_conntrack_max=1048576 # 临时上调
cat /sys/module/nf_conntrack/parameters/hashsize # 核对哈希桶数关键指标读法
| 指标 | 含义 | 正常与异常 |
|---|---|---|
| nf_conntrack_count | 当前表项数量 | 长期接近 max 说明容量即将成为瓶颈 |
| nf_conntrack_max | 表容量上限 | 需要与峰值并发连接数比对评估 |
| hashsize | 哈希桶数量 | 远小于表项数时冲突加剧，包处理开销上升 |
| table full 日志 | 满表丢弃记录 | 出现即说明已有业务受影响，不是预警而是故障 |
调大 max 的同时应当按比例提升 hashsize，通常让桶数与表容量同量级可降低链式查找开销。只加容量不加桶数，表虽然更大，但每包查找的耗时可能反而更差。
每个表项都要占用不可回收的内核内存，盲目把上限调到数百万会让内存持续增长。调整前按「目标连接数 × 单表项内存」估算增量，并在调整后观察可用内存的变化趋势。
连接跟踪表中的长连接会长期占用表项：一个 ESTABLISHED 表项的默认存活时间可达数天。因此网关类主机除了抬高上限，也应把跟踪超时与业务连接的实际情况对齐，减少无效占用。