Linux 服务器日志里出现 nf_conntrack: table full, dropping packet，说明内核用于记录网络连接状态的 conntrack 表已经达到上限，新连接可能被丢弃。网站会因此偶发超时，反向代理可能报 502/504，容器访问外网、DNS 查询或 NAT 转发也可能出现间歇性失败。
这个问题不能只靠调大 nf_conntrack_max 解决。正确顺序是先确认表是否真的满了，再找出连接由谁产生，最后根据内存和业务特征决定扩容、调整超时还是限制异常流量。
一、先确认是不是连接跟踪表已满
先查看内核日志。不同发行版可任选一种命令：
sudo dmesg -T | grep -i conntrack
sudo journalctl -k --since "30 minutes ago" | grep -i conntrack
如果反复看到类似信息，就继续检查当前条目数和上限：
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
也可以直接读取 /proc。其中 nf_conntrack_count 是当前条目数，nf_conntrack_max 是最大条目数：
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
watch -n 2 'printf "count="; cat /proc/sys/net/netfilter/nf_conntrack_count; printf "max="; cat /proc/sys/net/netfilter/nf_conntrack_max'
如果 count 长时间贴近 max，并且同一时段出现丢包日志，基本可以确认 conntrack 容量不足。若只偶发出现一次，也要结合业务峰值、容器发布、扫描攻击或上游重试情况判断。
二、判断连接是正常增长还是异常堆积
Debian、Ubuntu 可安装 conntrack，RHEL、Rocky Linux、AlmaLinux 可安装 conntrack-tools：
sudo apt update && sudo apt install conntrack
# 或
sudo dnf install conntrack-tools
先查看统计，不要一上来打印全部连接：
sudo conntrack -S
sudo conntrack -C
条目很多时，conntrack -L 会产生大量输出。需要进一步分析，可先写入临时文件，再观察源地址和目标地址分布：
sudo conntrack -L -o extended > /tmp/conntrack-list.txt
sudo conntrack -L -o extended 2>/dev/null \
| grep -oE 'src=[^ ]+' | sort | uniq -c | sort -nr | head -20
sudo conntrack -L -o extended 2>/dev/null \
| grep -oE 'dst=[^ ]+' | sort | uniq -c | sort -nr | head -20
同时查看主机连接状态：
ss -s
ss -ant | awk 'NR>1 {count[$1]++} END {for (s in count) print s, count[s]}' | sort
重点检查以下情况：
- 某个公网 IP 在短时间内建立大量连接，可能是扫描、爬虫、攻击或失控客户端。
- 某个本地服务不断访问同一目标，可能是程序重试、连接池失效或健康检查过密。
- Docker、Kubernetes、网关或 NAT 服务器承担大量转发，conntrack 压力通常高于普通 Web 主机。
TIME_WAIT很多不等于 conntrack 一定满，但短连接高峰会同时推高两类状态数量。- UDP、DNS 或无响应连接长期存在时，应检查业务行为和对应超时，而不是直接删除全部记录。
三、先做低风险止损
如果连接表已满并影响线上业务，可以在确认可用内存后临时提高上限，为排查争取时间。例如把当前值提高到原来的两倍：
current=$(sysctl -n net.netfilter.nf_conntrack_max)
sudo sysctl -w net.netfilter.nf_conntrack_max=$((current * 2))
这是临时调整，重启后通常会恢复。执行后立即检查：
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
sudo dmesg -T | tail -n 50
不要在不了解内存余量和流量来源时连续翻倍。每个 conntrack 条目都会占用内核内存，实际占用与内核版本、协议、扩展信息和系统架构有关，不能用一个固定字节数套用所有服务器。
如果是明显的单一来源异常，应优先在云防火墙、安全组、负载均衡或主机防火墙上限速、封禁或收敛入口。只扩表不处理异常流量，往往只是延后再次被填满的时间。
四、确认后再持久化参数
观察一个真实业务周期，确认新上限能够覆盖正常峰值且系统内存稳定后，再写入独立的 sysctl.d 配置文件：
sudo tee /etc/sysctl.d/90-nf-conntrack.conf >/dev/null <<'EOF'
net.netfilter.nf_conntrack_max = 262144
EOF
sudo sysctl --system
这里的 262144 只是配置示例，不是所有服务器的推荐值。正式设置时应根据正常峰值、增长速度、内存余量和故障缓冲空间确定。
sysctl net.netfilter.nf_conntrack_max
grep -R "nf_conntrack_max" /etc/sysctl.conf /etc/sysctl.d 2>/dev/null
如果多个文件重复设置同一参数，应只保留明确的一处，避免重启或执行 sysctl --system 后出现与预期不一致的值。
五、不要随意清空连接跟踪表
conntrack -F 会清空当前网络命名空间中的连接跟踪条目，可能中断现有 NAT、状态防火墙和业务连接，不应作为常规清理命令。
只有在明确知道影响范围、已有维护窗口并准备好回滚方案时，才考虑删除特定条目。例如按源地址删除：
sudo conntrack -D -s 198.51.100.10
示例地址必须替换为实际确认的异常来源。生产环境应先使用 conntrack -L 验证匹配范围，避免误删正常连接。
六、超时参数要按协议和状态调整
conntrack 为不同协议和 TCP 状态设置了不同超时。可以先查看当前配置：
sysctl -a 2>/dev/null | grep '^net.netfilter.nf_conntrack_.*timeout'
不建议把所有超时统一调小。超时过短可能让仍在使用的连接提前失去状态，影响 NAT、防火墙判断和长连接业务。只有连接样本显示某类无效状态大量堆积且业务允许时，才针对具体协议或状态小幅调整，并记录修改前的值：
sysctl -a 2>/dev/null | grep '^net.netfilter.nf_conntrack_.*timeout' \
| sudo tee /root/nf-conntrack-timeout-before.txt >/dev/null
调整后至少观察连接数、丢包日志、业务成功率以及 NAT/防火墙行为，不要只以 count 下降作为成功标准。
七、容器和 NAT 主机要额外检查什么
Docker、Kubernetes 节点、软路由和网关往往会为转发连接维护 conntrack 状态。排查时还应检查：
sudo nft list ruleset
sudo iptables-save
docker stats --no-stream
如果主机上存在多个网络命名空间，要确认故障发生在哪个命名空间，以及规则是否由 Docker、Kubernetes、firewalld 或其他组件管理，不要直接覆盖自动生成的防火墙规则。
还应检查 HTTP keep-alive 是否合理复用、连接池是否失效、健康检查是否过密、失败重试是否缺少退避，以及 NAT 出口是否过度集中在单台小规格服务器上。
八、修复后怎样验证
完成流量治理或参数调整后，建议连续观察至少一个真实业务高峰：
watch -n 5 'cat /proc/sys/net/netfilter/nf_conntrack_count; cat /proc/sys/net/netfilter/nf_conntrack_max'
sudo journalctl -k --since "10 minutes ago" | grep -i conntrack
还要从业务侧验证网站访问、API 成功率、DNS、容器出网和 NAT 转发。连接表不再满，只能证明容量告警缓解；程序仍超时时，还需要继续检查应用、网络、上游服务和防火墙规则。
长期监控建议包含 conntrack 占用比例、连接增长速度、内核告警、内存与网络错误，以及主要来源、目标和协议分布。
结语
遇到 nf_conntrack: table full，先确认连接表占用，再定位连接来源。线上已经受影响时，可以在确认内存余量后临时扩容，但持久化前必须经过峰值观察；异常流量、短连接设计和重试风暴则要从源头处理。
最稳妥的路径是：确认告警与占用率、分析连接构成、低风险止损、治理异常来源、持久化合理上限，最后通过内核日志和真实业务共同验证。
参考资料
- Linux Kernel Documentation：Netfilter conntrack sysctl variables
- Netfilter Project：conntrack-tools manual
- Red Hat Enterprise Linux Documentation：持久化内核参数
资料核验日期：2026年8月28日