Linux 网关、NAT 节点、Kubernetes 节点或防火墙出现 nf_conntrack: table full, dropping packet 时，新连接可能被丢弃，表现为随机超时、DNS 异常、服务偶发不可达。增加表上限只是应急动作，还必须找到连接为什么增长。
一、确认内核是否报告表满
dmesg -T | grep -i 'nf_conntrack.*table full'
journalctl -k --since '-30 min' --no-pager | grep -i conntrack记录首次发生时间、节点、接口和业务影响。多节点集群要确认是单节点还是全部节点。
二、检查当前数量和上限
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_buckets计算使用率：
使用率 = nf_conntrack_count / nf_conntrack_max × 100%持续采样增长速度，不要只看一次结果。表满后 count 可能贴着 max 不再增长，但丢包仍在发生。
三、查看统计和协议分布
安装 conntrack-tools 后：
conntrack -S
conntrack -L -o extended | head
conntrack -L -p tcp | wc -l
conntrack -L -p udp | wc -lconntrack -L 在大表上可能消耗 CPU 并产生海量输出，生产高峰要限制输出或在低峰执行。
分析来源和目的地址时，可以导出受控样本：
conntrack -L -o extended 2>/dev/null | head -n 5000 > /tmp/conntrack.sample检查是否有单一源地址、目的端口、DNS 请求、短连接或扫描流量占比异常。
四、检查 TCP/UDP 状态与超时
sysctl -a 2>/dev/null | grep 'net.netfilter.nf_conntrack_.*timeout'
ss -s
ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c | sort -nrUDP 没有连接握手，DNS、监控或服务发现流量突增时，条目可能快速累积。TCP 则要关注 SYN、TIME-WAIT、长连接和重传。不要为了快速下降 count 就把超时统一调得极低，这会破坏正常 NAT 会话。
五、检查 NAT、Kubernetes 和异常流量
iptables -t nat -L -n -v
nft list ruleset
ip -s link
sar -n DEV 1 10Kubernetes 节点要结合 kube-proxy 模式、Service 数量、NodePort、Pod 出口和 DNS 流量分析。检查是否存在连接池失效、健康检查过频、客户端重试风暴或外部扫描攻击。
六、应急处理步骤
在入口限流或阻断明确的异常来源，先控制新增速度。
修复客户端无连接池、超时重试和 DNS 查询风暴。
在内存评估后临时提高
nf_conntrack_max，并同步规划 buckets。将高流量 NAT 分散到更多节点，或绕开不必要的连接跟踪路径。
持续观察 count、insert_failed、drop 和业务成功率。
示例仅用于说明，实际数值必须按内存和连接模型评估：
sysctl -w net.netfilter.nf_conntrack_max=524288不要在生产环境执行 conntrack -F 清空整张表。它会破坏现有连接和 NAT 状态，可能把局部故障扩大为全面中断。
七、容量与内存评估
每个 conntrack 条目都会消耗内核内存，具体大小随内核版本、协议和扩展功能变化。扩大上限前观察 slab：
slabtop -o
grep -i conntrack /proc/slabinfo
free -h如果节点本身内存紧张，盲目扩大上限可能触发 OOM。
八、长期治理
监控 count/max、insert_failed、drop、协议和状态分布。
网关容量规划包含连接建立速率、并发连接和超时。
应用统一使用连接池、指数退避和合理超时。
对 DNS、健康检查和服务发现设置查询预算。
高流量 NAT 节点做水平扩展和故障演练。
变更 conntrack 参数时纳入配置管理并验证重启后仍生效。
conntrack 表满的根因通常是连接模型或异常流量失控，调大参数只能争取排查时间。