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网关端口耗尽排查。
应急处理优先级
先限流或隔离异常来源，停止失控重试，必要时把流量切到有容量的节点。盲目清空conntrack会中断现有NAT和状态连接。调整上限或超时要记录原值、内存影响与回滚方法。
长期治理
- 监控使用率、创建速率、失败计数和协议分布；
- 优化连接池、Keep-Alive、健康检查和重试退避；
- 对扫描与攻击实施边界限速和清洗；
- 按节点角色与内存规划conntrack容量；
- 进行峰值、上游故障和滚动升级演练；
- 把表满告警与具体业务连接失败关联。
如何定位是哪类工作负载占满表
先按协议、状态、源网段、目标地址和端口做聚合，不必立即导出每一条连接。若大量SYN_SENT集中到一个失效上游，重点处理健康检查和重试；若短生命周期UDP来自少数Pod，检查DNS或日志配置；若外部NEW状态遍布端口，则结合边界设备判断扫描或攻击。
调整参数后怎样验收
记录调整前后的最大值、内存占用、插入失败、查找性能和业务新建连接成功率，在逐级压力下验证。还要模拟节点滚动升级和上游不可达，确认重试不会再次把表打满。告警阈值应留出人工或自动扩容时间，而不是等使用率达到百分之百才通知。
结论
conntrack表满是状态容量耗尽，不等同于带宽跑满。先通过失败计数和流量分布确认根因，控制异常连接，再按内存与峰值合理扩容，才能避免简单调大参数后重复发生。
