跟踪表满引发的丢包
连接跟踪模块会为每条经过的连接维护一条状态记录，记录条数的上限由内核参数控制。当记录数触顶时，新连接无法建立跟踪条目而被直接丢弃，同时在统计与内核日志里留下痕迹。这类故障的症状很有辨识度：既有连接一切正常，新建连接却偶发失败，而且失败在流量高峰更集中。高并发的短连接场景，比如代理节点与网关节点，最容易触顶。
基本信息
| 适用平台 | Linux netfilter 连接跟踪 |
|---|---|
| 查看命令 | conntrack -C、conntrack -S、sysctl 查看当前值与上限 |
| 日志线索 | 内核日志中出现跟踪表已满的提示 |
| 高发场景 | 高并发短连接的代理与网关节点 |
典型使用场景
- 新连接偶发失败而旧连接正常，确认是否为跟踪表容量问题
- 压测中定位失败集中在高峰时段的原因
- 扩容或调整上限前评估当前用量与增长趋势
- 排查是否存在连接泄漏导致记录数持续不降
- 为超时参数调整提供依据
- 为网关类节点的容量规划提供实测数据
核对步骤
核对步骤
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
conntrack -C # 当前跟踪记录数
conntrack -S | grep drop # 丢弃计数
dmesg | grep -i 'nf_conntrack: table full' # 内核日志中的触顶提示
# 触及上限且高峰时段丢弃增长 → 容量瓶颈已成立观察项逐项读法
| 观察项 | 含义 | 判读方向 |
|---|---|---|
| 当前记录数 | 已占用的跟踪条目 | 接近上限即为容量风险 |
| 记录上限 | 可容纳的最大条目数 | 需与内存预算一起评估 |
| 丢弃计数 | 因表满被丢的连接 | 持续增长说明容量不足 |
| 内核日志提示 | 表满的直接证据 | 出现即可确认为该类问题 |
扩容前先查是否存在连接泄漏：长时间不释放的连接会让记录数居高不下，只调大上限只是延后复发。
上限抬高会增加内存占用，需要与连接超时参数一并评估，避免为了容量付出过高的内存代价。