conntrack 表耗尽：连接正常建立前为何就被丢弃

内核日志出现 nf_conntrack: table full, dropping packet 时，新连接可能在到达应用前就被丢弃。Kubernetes 节点、NAT 网关和高短连接服务尤其常见。

确认容量与趋势

sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
journalctl -k | grep -i conntrack
conntrack -S

不要只看某一时刻的 count。结合新建连接速率、超时和失败率判断是正常峰值、扫描流量还是连接未及时回收。

分析状态分布

conntrack -L -o extended 2>/dev/null | awk '{print $4}' | sort | uniq -c | sort -nr
ss -s
sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait

完整导出大表会消耗 CPU，生产环境应限时执行或使用统计接口。大量 UNREPLIED 可能意味着单向流量、扫描或回程路由异常。

治理策略

• 先限流异常来源并减少无意义短连接
• 按内存预算调整 nf_conntrack_max，同步评估哈希桶
• 谨慎缩短超时，避免破坏长连接和慢请求
• Kubernetes 中分散热点 Service 或扩展节点容量

收尾清单

修复后观察表使用率、新连接失败和丢包计数至少一个峰值周期，并为使用率和插入失败建立告警。