Linux conntrack 表满怎么排查？连接跟踪、丢包与容量治理

conntrack 表满会让需要连接跟踪的新流量无法建立，但直接提高 nf_conntrack_max 只会推迟问题。应先确认内核日志与计数，再按协议、状态、源目标和 NAT 路径定位连接为什么长期占用。

先给结论

conntrack 表满会让需要连接跟踪的新流量无法建立，但直接提高 nf_conntrack_max 只会推迟问题。应先确认内核日志与计数，再按协议、状态、源目标和 NAT 路径定位连接为什么长期占用。

先确认是否真的达到上限

检查内核日志是否出现 nf_conntrack: table full, dropping packet，读取 net.netfilter.nf_conntrack_count 与 nf_conntrack_max。count 接近上限但没有业务异常时仍需观察趋势，不能用单一时刻判断。

同时记录新建连接失败、SYN 重传、负载均衡健康检查和应用错误率。连接跟踪耗尽主要影响需要新建或跟踪的流量，已经建立的连接可能暂时正常，因此用户表现可能不一致。

理解哪些流量会进入 conntrack

状态防火墙、NAT、容器网络和 Kubernetes Service 等场景依赖连接跟踪。每个连接会按协议和状态保留一段时间，突发短连接、扫描、异常重试或过长超时都可能快速占用表项。

双向数据包属于同一跟踪项，但 NAT 和多网络命名空间会让观察位置不同。必须在实际承担防火墙/NAT 的节点检查，不能只在后端应用服务器读取 count。

用 conntrack 工具定位占用

conntrack -S 可查看统计，conntrack -L 能列出现有条目。生产环境全量列举可能耗费 CPU 和输出大量敏感地址，应先在低峰、限制时间，并优先用统计或采样。

按协议、连接状态、源地址、目标地址和目标端口聚合，寻找单一来源扫描、大量未完成握手、短连接风暴或异常长寿命条目。定位业务来源后再调整客户端连接池、重试和超时。

容量与超时应该怎样调整

提高 nf_conntrack_max 会增加可容纳连接数，也会消耗更多内存和查找成本。调整前要根据峰值并发、连接建立速率、保留时间和节点内存评估，不应复制其他服务器的固定数值。

降低 TCP established 或其他超时可能更快回收表项，但会误伤低频长连接。先按真实协议和状态找出主要占用，再小步调整并监控重传、断连和表项回收速度。

架构层面的长期治理

反向代理和应用应使用合理连接池与 keepalive，避免每个请求建立新连接；对扫描和恶意流量在更靠前的位置限速或拦截。NAT 网关、容器节点和边缘入口要按峰值连接数规划，而不只按带宽。

高可用环境应避免所有连接集中到单节点，并为 count/max 比例、insert_failed、drop 和新建连接失败建立告警。告警阈值要留出排障时间，不能等达到 100% 才通知。

修复后的验证

在相同流量条件下观察 count 峰值是否回落、insert_failed 是否停止增长、新连接成功率和应用尾延迟是否恢复。变更超时后还要覆盖长连接、WebSocket、数据库连接池和后台任务。

如果只清空 conntrack 表，现有连接会被破坏且根因仍存在。除非明确接受影响并有回退方案，不应把批量删除连接作为常规修复。

排查与验收表

操作边界

所有示例都需要按实际账户、区域、接口和业务时间窗口替换。生产变更前记录影响范围和回退位置；日志可能包含账户、资源与网络信息，不应公开粘贴完整事件或连接清单。

安全读取 conntrack 状态

使用 sysctl net.netfilter.nf_conntrack_count、sysctl net.netfilter.nf_conntrack_max 和 conntrack -S 确认计数、上限与失败统计，再从内核日志查找 table full。上述操作只读取状态，不会主动删除连接。

生产执行 conntrack -L 前应评估表规模；大表全量输出可能增加 CPU 并暴露网络信息。count/max 只能说明容量比例，不能说明来源；应继续按协议、状态、源目标和端口做受控采样。

参数调整与持久化边界

临时修改上限前应计算内存余量并记录原值，验证通过后才考虑写入受版本管理的 sysctl 配置。不同内核、节点角色和流量模型不能复制同一数值。调整超时还要覆盖 SSH、WebSocket、数据库池和后台长任务，防止回收过快造成隐性断连。

官方资料

• Linux Kernel：Netfilter conntrack sysctl
• Netfilter：conntrack-tools manual
• conntrack(8) manual