连接跟踪表满为什么难查
启用地址转换或状态防火墙的主机，内核会为每条连接维护一条跟踪表项。表满时新连接不会被正常建立，而是被静默丢弃：客户端看到的是超时重试，服务端日志里什么都没有，因此极易被误判为链路问题或对端故障。确诊依赖内核侧的证据：当前条目数与上限的比较，以及内核日志里关于连接跟踪表已满的告警。
基本信息
| 适用平台 | Linux 内核的 netfilter 连接跟踪模块 |
|---|---|
| 查看计数 | net.netfilter.nf_conntrack_count 与 nf_conntrack_max |
| 统计工具 | conntrack 命令行，查看总数、分类统计与条目列表 |
| 确诊证据 | 内核日志中出现连接跟踪表满、丢弃报文的告警 |
| 代价 | 调大上限会同步增加内核内存占用，需要评估内存 |
典型使用场景
- 大量地址转换的主机上出现随机超时：优先怀疑连接跟踪表满
- 新连接成功率下降：对比条目数与上限的接近程度
- 排查丢弃原因：查看分类统计中的插入失败与丢弃计数
- 应急恢复：清理陈旧条目争取时间，同时制定扩容方案
- 容量规划：按峰值并发连接数设定上限与老化时间
检查与确诊
检查与确诊
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
conntrack -C # 当前条目数
conntrack -S # 分类统计：插入失败、丢弃等
dmesg | grep -i conntrack | tail -5
conntrack -L -p tcp --dport 443 | head -20 # 查看某类连接条目缓解参数（评估内存后调整）
缓解参数（评估内存后调整）
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
# 写入 /etc/sysctl.d/ 下的文件后执行 sysctl --system 生效
# 应急清理陈旧条目（会短暂影响对应连接）：
# conntrack -D -p tcp --state TIME_WAIT指标与处置
| 观察 | 含义 | 处置 |
|---|---|---|
| 条目数接近上限 | 表将满，新连接开始被丢 | 评估内存后调大上限 |
| 分类统计有丢弃计数 | 已发生静默丢包 | 调参并排查异常连接来源 |
| 短连接数量极高 | 老化时间与业务模型不匹配 | 调整老化时间，优化连接复用 |
| 内存吃紧 | 跟踪表占用过大 | 降低上限并排查连接泄漏 |
| 日志仅有内核告警 | 应用日志完全干净 | 以内核证据为准，别只看应用 |
表满的表现是丢包而不是报错，极易误判为链路问题；调大上限会同步增加内核内存占用，需结合内存评估，应急时可先清理陈旧条目。