在Deepin上部署Docker、KVM或Nginx时，偶尔会遇到新建连接失败但现有连接正常的情况，ping网关也可能突然不通。检查系统日志往往看不到明确报错，此时需要关注内核连接跟踪表是否已满。
conntrack在Deepin网络栈中的角色
conntrack是Linux内核netfilter框架提供的连接跟踪机制，它记录每一个经过主机的网络会话的五元组信息，包括源IP、目的IP、源端口、目的端口和协议类型。Deepin系统基于Debian内核，同样默认启用了这个模块。无论流量是转发还是发往本机，只要数据包命中了带状态检测的规则，内核就会在跟踪表中创建或更新一条记录。
连接跟踪表并不是无限大的，它受内核参数nf_conntrack_max限制。当活动连接数接近这个上限时，新的数据包无法插入跟踪表，内核会直接丢弃它们。此时已经建立的连接仍然可以继续传输，所以故障表现为老连接正常、新连接超时，而不是整机断网。这种半断网现象在桌面使用中不太明显，但在运行容器或虚拟化服务的Deepin主机上很容易触发。
查看当前限制和已使用数量的命令如下：
cat /proc/sys/net/netfilter/nf_conntrack_max cat /proc/sys/net/netfilter/nf_conntrack_count
如果nf_conntrack_count长期接近nf_conntrack_max，就说明连接跟踪表可能已经处于饱和状态。除了这两个参数，nf_conntrack_buckets也会影响查找效率，但它通常由内核根据内存大小自动计算，一般不需要手动修改。
查看和清理conntrack条目
Deepin默认没有安装conntrack用户态工具，需要先用包管理器安装。该工具可以细粒度地查看和删除跟踪表中的记录，比直接读取/proc/net/nf_conntrack更加友好。
sudo apt update sudo apt install conntrack
安装完成后，可以使用conntrack -S查看统计信息，包括当前条目数、新建速率、删除速率等。如果只想查看TCP连接中处于ESTABLISHED状态的条目，可以加上协议和状态过滤条件。
conntrack -S sudo conntrack -L -p tcp --state ESTABLISHED
当确认表中有大量过期或无效会话时，可以用-D参数删除符合条件的记录。例如删除所有目的端口为80的TCP跟踪条目，或者直接用-F清空整个跟踪表。清空操作会暂时中断所有经过本机的网络连接，执行前需要确认影响范围。
sudo conntrack -D -p tcp --dport 80 sudo conntrack -F
清理只能暂时缓解问题，如果业务本身连接数就很高，还是需要通过调整内核参数来扩大跟踪表容量。清理后可以观察conntrack -S中的当前条目数是否明显下降，以及新连接是否恢复正常。
调整内核参数并持久化配置
在Deepin系统中，修改连接跟踪上限最直接的方法是写入/proc/sys/net/netfilter/nf_conntrack_max，但这种方式重启后会丢失。更推荐使用sysctl配置文件进行持久化。常见的配置项包括最大跟踪数和TCP已建立连接的超时时间。
sudo sysctl -w net.netfilter.nf_conntrack_max=262144 sudo sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=7200
上述命令会立即生效，但如果希望开机自动应用，需要把参数写入/etc/sysctl.d/目录下的自定义配置文件。创建文件后执行sysctl -p或重启系统即可。
echo 'net.netfilter.nf_conntrack_max=262144' | sudo tee /etc/sysctl.d/99-conntrack.conf echo 'net.netfilter.nf_conntrack_tcp_timeout_established=7200' | sudo tee -a /etc/sysctl.d/99-conntrack.conf sudo sysctl -p /etc/sysctl.d/99-conntrack.conf
需要注意的是，nf_conntrack_max并不是越大越好。每条跟踪记录都会占用内核内存，过大的上限可能导致内存压力增大。对于普通的Deepin桌面环境，默认值通常足够；但如果用于Docker宿主机或网关，可以根据实际并发连接数适当放大。可以通过dmesg查看内核是否报告表满信息。
常见故障排查与优化建议
当怀疑连接跟踪表导致网络异常时，可以先查看内核日志。执行journalctl -k | grep conntrack或dmesg | grep conntrack，如果看到类似nf_conntrack: table full, dropping packet的输出，就可以确认是跟踪表溢出。此时应优先清理无用会话并提高上限。
journalctl -k | grep conntrack dmesg | grep conntrack
另一个容易忽略的问题是超时设置。对于短连接密集的场景，比如API服务或代理转发，如果TCP已建立连接的超时时间过长，会导致大量已经关闭的连接长期占用跟踪表。适当调低nf_conntrack_tcp_timeout_established可以加快条目回收，释放表空间。不过超时设置太短也可能切断空闲的长连接，需要结合业务模型调整。
在高并发环境中，还可以观察/proc/sys/net/netfilter/nf_conntrack_expect_max，它控制期望连接的数量，对FTP、SIP等协议有影响。Deepin作为客户端时一般不需要修改，但如果运行了基于这些协议的网关服务，也要避免期望连接条目耗尽。
cat /proc/sys/net/netfilter/nf_conntrack_expect_max
综合来看，Deepin系统下的conntrack排查重点是确认跟踪表是否饱和、及时清理无效条目、调整最大容量与超时时间，并让配置持久化。定位问题时先看内核日志，再观察计数变化，通常能快速找到原因。对于容器和虚拟化场景，建议将连接跟踪参数纳入初始部署检查项，避免在业务高峰期才发现网络异常。
Deepin系统conntrack连接跟踪netfilter修改时间：2026-10-04 16:47:38