Conntrack table（连接跟踪表） dmesg 里出现 nf_conntrack: table full, dropping packet。

在 Linux 系统里，“查看 Conntrack table 状态”通常指两件事：

1. 当前表里存了多少条目、上限是多少、是否已溢出（即 /proc/sys/net/netfilter/ 中的一组计数器）。
2. 每个具体连接条目长什么样（五元组、协议、状态、超时等）。

下面给出最常用的几条命令，普通用户即可执行，无需改代码。

---

一、只看“表用量”——最快

bash

复制

cat /proc/sys/net/netfilter/nf_conntrack_count   # 当前条目数
cat /proc/sys/net/netfilter/nf_conntrack_max   # 内核允许的最大条目数

 

示例输出

复制

20035
262144

 

表示已用 20 035 条，上限 262 144 条，占用率 ≈ 7.6 %。

---

二、同时看“溢出/丢弃”统计

bash

复制

cat /proc/net/stat/nf_conntrack

 

每列含义（内核 2.6.35+ 通用）

entries searched found new invalid ignore delete delete_list insert insert_failed drop early_drop icmp_error expect_new expect_create expect_delete search_restart

 

重点列

• entries —— 当前表内条目数（同 nf_conntrack_count）
• new —— 自开机以来新建过多少条目
• drop —— 因表满而被丢弃的新连接包数（>0 说明曾被打爆）
• early_drop —— 内核主动“踢掉”快过期条目给新连接腾位置的次数

---

三、看每个连接详情

bash

复制

sudo conntrack -L          # 列出所有条目（五元组、状态、超时）
sudo conntrack -L | wc -l  # 快速统计条目数（与 /proc 值一致）

 

常用过滤示例

复制

# 只看 TCP 且状态为 ESTABLISHED
sudo conntrack -L -p tcp --state ESTABLISHED

# 只看某源 IP
sudo conntrack -L -s 192.168.1.100

 

若系统提示 conntrack: command not found，安装包
apt install conntrack 或 yum install conntrack-tools

---

四、一行脚本：实时占用率

bash

复制

while :; do
  printf "\rConntrack 使用率: %3d%%  (%d/%d)" \
    $(($(cat /proc/sys/net/netfilter/nf_conntrack_count)*100/
       $(cat /proc/sys/net/netfilter/nf_conntrack_max))) \
    $(cat /proc/sys/net/netfilter/nf_conntrack_count) \
    $(cat /proc/sys/net/netfilter/nf_conntrack_max)
  sleep 1
done

 

---

五、图形/监控对接

• Prometheus：node_exporter 的 nf_conntrack_* 系列指标
• Grafana：直接画 nf_conntrack_count / nf_conntrack_max 曲线
• Zabbix/AliyunCloudMonitor：自定义键值读取 /proc 即可

---

常见疑问

1. 权限：读 /proc 不需要 root；conntrack -L 需要 CAP_NET_ADMIN，普通用户加 sudo。
2. 表满会怎样：新连接包会被直接丢弃，业务表现为“建连超时/丢包”，dmesg 里出现
   nf_conntrack: table full, dropping packet。
3. 如何扩容：
   复制

   # 临时生效
   sudo sysctl -w net.netfilter.nf_conntrack_max=524288
   # 永久生效
   echo "net.netfilter.nf_conntrack_max = 524288" >> /etc/sysctl.conf
   sysctl -p

    
   同时建议同步放大哈希桶 nf_conntrack_buckets，否则查找性能下降。

---

一句话总结
想最快速知道 Conntrack table 状态，就执行

bash

复制

cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

 

前面是已用，后面是上限；两条命令即可判断“快满没”。

 

 

在 Linux 系统里，只要数据包经过 netfilter 钩子且内核配置开启了 nf_conntrack，就会为这条流建表项。
因此“会用到 conntrack 表”的并不是某个用户态服务，而是内核提供的三大功能——防火墙、NAT、负载均衡——以及依赖它们的用户态守护进程。
下面把日常最可能把表吃满的“常见服务/组件”按场景列出来，方便你对号入座。

 

 

CentOS 7.9 默认有没有开 conntrack

 

Kubernetes 是否“必须”开启 conntrack

 kube-proxy（iptables/ipvs 模式）需要为 Service 做 SNAT/DNAT、为 Pod 出站做源地址伪装——底层就是写 iptables 规则，内核必须跟踪连接才能正确回包

 

什么时候“可以”关闭？

1. 纯路由器/核心交换角色，不做 NAT、不跑状态防火墙、不依赖 LVS，且所有过滤用无状态 ACL（ip rule + tc flower、BPF、交换机芯片 ACL）。
2. 自定义快路径（DPDK、XDP、智能网卡）把包全部旁路，内核根本看不到流。
3. 嵌入式设备内存极小，用静态包过滤就能满足需求。

 

为什么不需要开启iptables服务，直接使用iptables命令也能生效？
因为iptables规则是直接在内核的netfilter框架中操作的，而iptables命令就是用来操作这些规则的工具。内核中的netfilter规则表是独立于用户空间服务的，只要规则被正确插入，就会生效。

具体来说：

1. iptables规则是立即生效的，每一条iptables命令都会直接修改内核中的规则集。

2. 传统的iptables服务（比如iptables-persistent或firewalld）的作用是在系统启动时恢复规则，或者在系统关闭时保存规则。如果你没有这样的服务，那么规则在重启后就会丢失。

但是，在Kubernetes节点上，我们通常不需要持久化iptables规则，因为：

• kube-proxy会持续监控API Server，并动态更新规则，所以即使重启，kube-proxy也会重新配置规则。

• 如果节点重启，kube-proxy会重新启动，并根据从API Server获取的信息重新设置规则。