卸载 conntrack 模块会直接破坏连接跟踪机制，导致 NAT、iptables 状态匹配、br_netfilter 转发及容器网络失效；需按序 modprobe nf_conntrack、nf_nat、nf_conntrack_ipv4 等恢复，并验证模块加载与流量通断。

卸载 conntrack 模块（如执行 rmmod nf_conntrack）会直接破坏连接跟踪机制，导致基于状态的 NAT（如 SNAT/DNAT）、iptables 状态匹配（-m state 或 -m conntrack）、网桥 br_netfilter 转发、甚至部分容器网络（如 Docker 的默认 bridge）瞬间失效——即使 iptables 规则仍在，数据包也会因无法建立/查找连接状态而被丢弃。

确认 conntrack 模块是否已卸载

运行以下命令检查：

• lsmod | grep nf_conntrack —— 若无输出，说明模块未加载
• cat /proc/sys/net/netfilter/nf_conntrack_count —— 若报错 No such file or directory，也表明连接跟踪子系统不可用
• iptables -t nat -L -n 规则存在但流量不通，是典型症状

使用 modprobe 快速恢复模块

多数现代内核中，nf_conntrack 及其依赖模块可直接通过 modprobe 重新加载：

Docker Encyclopedia

Docker 文档优先工作流：针对 Docker 特定问题、故障排除、命令规划、镜像/构建、容器/运行时操作及 Compose 等

下载

• 依次执行（顺序重要）：
  modprobe nf_conntrack
modprobe nf_nat（若用了 NAT）
  modprobe nf_conntrack_ipv4（IPv4 场景必需）
  modprobe nf_nat_ipv4（配合 IPv4 NAT）
• 若提示 Module nf_conntrack not found in directory，说明模块被编译进内核（built-in），此时无法用 rmmod 卸载，也不需 modprobe —— 应检查是否误操作了其他模块（如 xt_conntrack）或 sysctl 设置

验证恢复与防止再次卸载

加载后立即验证：

• lsmod | grep nf_conntrack 确认模块在列表中
• echo $(( $(cat /proc/sys/net/netfilter/nf_conntrack_count) >= 0 )) 返回 1 表示系统就绪
• 测试一条 DNAT 或 SNAT 流量（如 curl 外部服务 / 访问端口映射服务）
• 为防误操作，可将关键模块列入黑名单禁止卸载（不推荐生产环境随意 rmmod）：
  echo "install nf_conntrack /bin/true" > /etc/modprobe.d/protect-conntrack.conf

注意：Docker/K8s 环境的特殊性

Docker 默认依赖 nf_conntrack 和 br_netfilter。若同时卸载了 br_netfilter，仅恢复 conntrack 不足以恢复容器间通信：

• 补加：modprobe br_netfilter
• 并确保启用网桥流量转发到 iptables：
  sysctl -w net.bridge.bridge-nf-call-iptables=1
sysctl -w net.bridge.bridge-nf-call-ip6tables=1
• Docker 启动时若检测不到 conntrack，可能跳过 iptables 链设置，此时需重启 docker daemon：
  systemctl restart docker