服务器 conntrack 表耗尽 conntrack table full

原因 ID so-conntrack · 主责 运维团队·系统运维 · 配合研发团队·服务器开发, 研发团队·客户端开发

Linux 防火墙会把所有连接记在连接跟踪（conntrack）表里，这张表达到上限后，新的数据包会被丢弃。

起因连接激增、反复建立短连接，使连接记录增多 → 结果表满后丢弃新连接和部分数据包 → 画面表现 连不上，莫名丢包导致瞬移

症状: 连不上/无限加载, 瞬移
因素: 丢包
谁会遇到: 全服
何时出现: 刚登录/维护结束后, 人多的时候
负责方: 主责 运维团队·系统运维 · 配合研发团队·服务器开发, 研发团队·客户端开发
研发团队要做的事: 服务器：减少短连接（服务器间调用复用连接）。客户端：连接失败或断开后，逐步拉长重试间隔并随机打散。
运维团队要做的事: 调大表的大小（nf_conntrack_max）；游戏端口不做跟踪（raw 表的 NOTRACK）；设置用量告警。
数值参考: 默认上限视服务器内存而定，约为 6 万~26 万条。溢出时内核日志会打出“nf_conntrack: table full, dropping packet”。
监控图上: 触顶后走平 · conntrack 条目数（nf_conntrack_count）
查看位置: 把 sysctl 的 net.netfilter.nf_conntrack_count（当前条目数）和 nf_conntrack_max 画在同一张图上，在 dmesg 中找“nf_conntrack: table full, dropping packet”
确认依据: nf_conntrack_count 在 max 处走平，从那一刻起内核日志出现 table full
排除依据: 条目数离 max 还很远则不是这个原因。AWS 实例本身的连接跟踪上限，看“超出云 PPS 上限”中的 conntrack_allowance_exceeded
确认手段: 运维工具即可确认（无需游戏代码）

出处

Netfilter Conntrack Sysfs variables Linux kernel
nf_conntrack_max 默认值等于哈希桶数（nf_conntrack_buckets），桶数由内存大小决定
net/netfilter/nf_conntrack_core.c (Linux v6.12) Linux kernel
默认大小：内存超过 1 GB 为 65,536，超过 4 GB（64 位）为 262,144；表满时记录“nf_conntrack: table full, dropping packet”并丢弃
iptables-extensions(8) — Linux manual page netfilter
用 raw 表的 CT --notrack 排除连接跟踪