conntrack模块卸载后NAT不工作，需按nf_defrag_ipv4→nf_conntrack→nf_conntrack_ipv4顺序加载并验证；rmmod nf_conntrack会级联卸载依赖模块；可用modprobe配置禁止误卸载。
conntrack 模块卸载后 NAT 不工作，modprobe nf_conntrack 不够用
单纯执行 modprobe nf_conntrack 很可能无法恢复 NAT 功能——因为 NAT 依赖一整套连接跟踪模块链，而不仅仅是顶层模块。常见现象是：执行后 iptables -t nat -L 看规则还在，但 DNAT/SNAT 完全不生效，新连接无状态记录，conntrack -L 输出为空。
-
nf_conntrack是核心模块，但必须配合协议子模块（如nf_conntrack_ipv4或nf_conntrack_ipv6）才能解析具体报文 - 若系统启用了 conntrack helper（如 FTP、SIP），还需加载对应
nf_conntrack_ftp等模块，否则相关协议连接会失败 - 部分内核版本中，
nf_defrag_ipv4（或nf_defrag_ipv6）必须先加载，否则nf_conntrack_ipv4初始化失败并静默退出
一次到位的 modprobe 恢复命令顺序
模块加载有依赖顺序，错序会导致后续模块加载失败且无明确报错。推荐按以下顺序执行（以 IPv4 NAT 为主场景）：
modprobe nf_defrag_ipv4modprobe nf_conntrackmodprobe nf_conntrack_ipv4- 如有需要，再加
modprobe nf_conntrack_ftp或modprobe nf_nat_ftp
验证是否全部就位：lsmod | grep -E 'nf_(conntrack|defrag|nat)' 应输出至少 3 行以上；conntrack -L | head -n1 能打印出连接条目才算真正生效。
为什么 rmmod nf_conntrack 会连带卸载其他模块？
Linux 内核模块引用计数机制决定了：当某个模块被显式卸载时，内核会递归检查其所有依赖者。如果 nf_conntrack_ipv4 正在使用 nf_conntrack，而你强制 rmmod nf_conntrack，内核会自动先卸载 nf_conntrack_ipv4 和 nf_defrag_ipv4（只要它们没有被其他模块引用）。这不是 bug，是设计行为，但容易让人误以为“只卸了一个模块”。
- 卸载前可用
lsmod | grep nf_conntrack查看当前加载的 conntrack 相关模块及其 size/use 字段 - use 列为 0 表示未被引用，可安全卸载；大于 0 表示被其他模块或 netfilter 规则持有，强制卸载会触发级联卸载
-
iptables -t nat -L本身不会阻止模块卸载，但实际运行中的 NAT 流量会持续引用nf_nat和nf_conntrack模块
防止再次意外卸载的简单加固方式
模块被误卸载往往源于自动化脚本、容器 runtime 清理逻辑，或运维人员执行了未加判断的 rmmod -a 类命令。最轻量的防护是屏蔽卸载：
- 写入
/etc/modprobe.d/nf-conntrack.conf：install nf_conntrack /bin/true
install nf_conntrack_ipv4 /bin/true
install nf_defrag_ipv4 /bin/true - 该配置让系统在每次尝试加载这些模块时都返回成功（实际不加载），更重要的是：任何
rmmod尝试都会因“模块未加载”而失败，从而避免静默级联卸载 - 注意：此法不影响已加载模块的运行，也不影响重启后正常加载；若需临时调试，可注释该文件后重启网络服务
真正的难点不在加载命令本身，而在于模块间的隐式依赖和内核引用计数的不可见性——看到 modprobe nf_conntrack 成功返回，不等于 NAT 已恢复。
