### [Linux conntrack表满了为什么断网？NAT连接跟踪与容量排查](https://www.jiyueip.com/article/8200)

**Published:** 2026-07-22T19:56:16

**Author:** 斑斓助理

**Excerpt:** Linux网关或容器节点的conntrack表满后，新连接可能被丢弃。本文说明状态项、超时、NAT、哈希桶、连接风暴和安全扩容。

Linux网关日志出现“nf\_conntrack: table full, dropping packet”，新开的网页、DNS或容器连接大面积超时，已有SSH却暂时还能用。这符合连接跟踪表无法为新流创建状态的典型表现，但调大上限前还要找出谁在制造状态。

## conntrack记录什么

Netfilter连接跟踪根据协议和地址端口识别流，维护NEW、ESTABLISHED、RELATED等状态，并为NAT保存转换关系。它不仅服务于传统路由器，容器节点、状态防火墙和负载均衡规则也可能大量使用。

## 表满时会发生什么

当现有条目达到上限，新流无法分配状态，相关报文可能被丢弃。已有条目在未过期时仍能匹配，所以用户常描述为“老连接还在，新连接打不开”。若系统同时内存紧张或CPU过载，影响会更广。

## 先看哪些指标

| 指标  | 用途  |
| --- | --- |
| 当前条目数与最大值 | 确认是否逼近容量 |
| insert\_failed、drop等计数 | 证明新状态创建失败 |
| 按协议和状态分布 | 识别TCP、UDP或未确认流 |
| 按源目标聚合 | 定位扫描、重试或热门服务 |

收集统计时避免导出包含大量用户地址的完整表到公开渠道。

## 什么流量会快速填满

-   应用短连接、连接池失效和同步重试；
-   外部扫描、SYN Flood或内部端口探测；
-   DNS、日志等大量UDP流及过长超时；
-   容器健康检查频率过高；
-   上游不可达导致大量SYN重试；
-   规则或服务异常让本应绕过的流量全部进入跟踪。

## 超时为什么不能随便缩短

每种协议和状态有不同超时。缩短可更快释放陈旧条目，但过短会让合法空闲连接失去状态、NAT回包被丢弃或应用频繁重连。应按实际连接生命周期和官方文档调整，并先在测试或灰度节点验证。

## 调大上限的代价

更高`nf_conntrack_max`需要更多内存和合适哈希桶配置，查询与清理也会占CPU。容量应根据节点内存、峰值流量和故障余量规划。若应用每秒创建不必要的连接，扩容只会延后下一次故障。

## 容器与Kubernetes为何常见

节点同时承载Pod出站、Service转发、健康检查和东西向通信，连接集中度高。故障可能只在某些节点发生。按节点检查Pod分布、conntrack使用和异常工作负载，必要时排空节点，而不是重启整个集群。

## 与SNAT端口耗尽的区别

两者都可能让新连接失败，也可能同时发生。conntrack关注网关状态表容量，SNAT端口关注公网地址端口映射组合。SNAT侧的目标集中和扩容方法可参考[NAT网关端口耗尽排查](https://www.jiyueip.com/article/8188)。

## 应急处理优先级

先限流或隔离异常来源，停止失控重试，必要时把流量切到有容量的节点。盲目清空conntrack会中断现有NAT和状态连接。调整上限或超时要记录原值、内存影响与回滚方法。

## 长期治理

1.  监控使用率、创建速率、失败计数和协议分布；
2.  优化连接池、Keep-Alive、健康检查和重试退避；
3.  对扫描与攻击实施边界限速和清洗；
4.  按节点角色与内存规划conntrack容量；
5.  进行峰值、上游故障和滚动升级演练；
6.  把表满告警与具体业务连接失败关联。

## 如何定位是哪类工作负载占满表

先按协议、状态、源网段、目标地址和端口做聚合，不必立即导出每一条连接。若大量SYN\_SENT集中到一个失效上游，重点处理健康检查和重试；若短生命周期UDP来自少数Pod，检查DNS或日志配置；若外部NEW状态遍布端口，则结合边界设备判断扫描或攻击。

## 调整参数后怎样验收

记录调整前后的最大值、内存占用、插入失败、查找性能和业务新建连接成功率，在逐级压力下验证。还要模拟节点滚动升级和上游不可达，确认重试不会再次把表打满。告警阈值应留出人工或自动扩容时间，而不是等使用率达到百分之百才通知。

## 结论

conntrack表满是状态容量耗尽，不等同于带宽跑满。先通过失败计数和流量分布确认根因，控制异常连接，再按内存与峰值合理扩容，才能避免简单调大参数后重复发生。

**Tags:** 企业网络合规, 服务器运维, 网络故障排查, 隐私与合规

**Categories:** 行业洞察

---