卸载 conntrack 模块导致 NAT 静默失效，根本原因是 nf_conntrack 未加载；nf_conntrack 是 NAT 依赖的底层连接跟踪框架，新内核中 nf_conntrack_ipv4 已合并入主模块，加载失败属正常设计变更。
卸载 conntrack 模块后 NAT 不工作，modprobe nf_conntrack_ipv4 报错
直接原因是 nf_conntrack_ipv4 在较新内核（5.4+）中已被合并进主模块，不再作为独立可加载模块存在。强行 modprobe nf_conntrack_ipv4 会返回 Module nf_conntrack_ipv4 not found in directory /lib/modules/...，但真正影响 NAT 的是 nf_conntrack 本身未加载或被意外卸载。
nf_conntrack 是 NAT 正常工作的底层依赖
NAT 规则（如 iptables -t nat -A POSTROUTING）必须依赖连接跟踪子系统记录双向流量状态；没有 nf_conntrack，nf_nat 就无法构造、匹配和转换连接元数据。
-
nf_conntrack是核心模块，提供通用连接跟踪框架 -
nf_nat依赖它完成地址/端口映射逻辑 -
nf_conntrack_ipv4和nf_conntrack_ipv6在旧内核中负责协议层解析，新内核中功能已内置到nf_conntrack - 卸载
nf_conntrack后，iptables -t nat表仍可配置，但规则完全不生效——没有错误提示，只有“静默失效”
检查和恢复 conntrack 状态的实操步骤
别急着重装内核或重启，先确认当前模块加载状态和依赖关系：
- 运行
lsmod | grep nf_conntrack：应看到nf_conntrack（必有），nf_nat（NAT 必需），nf_conntrack_netlink（可选，用于用户态交互） - 若
nf_conntrack缺失，执行modprobe nf_conntrack；它会自动拉起nf_nat等依赖 - 验证是否生效：
cat /proc/sys/net/netfilter/nf_conntrack_count应为非零值（哪怕刚启动时很小） - 如果之前手动
rmmod nf_conntrack导致其他模块（如xt_conntrack）残留，需按依赖顺序重新加载，否则iptables -m conntrack会报错
为什么 nf_conntrack_ipv4 加载失败却不是问题根源
这个模块名在内核文档和旧脚本中广泛存在，容易让人误以为它是关键组件。实际上：
- 从 Linux 4.19 开始，IPv4 连接跟踪逻辑已编译进
nf_conntrack，不再分离为独立模块 -
modinfo nf_conntrack_ipv4在新版系统中通常返回“file not found”，不是 bug，是设计变更 - 某些发行版（如 RHEL 8/CentOS 8+）甚至彻底移除了该模块符号，但
iptables -t nat依然正常——只要nf_conntrack和nf_nat在位 - 真正要警惕的是：卸载
nf_conntrack时，内核不会阻止你，但所有基于 conntrack 的功能（NAT、state 匹配、bridge-nf-call-iptables）瞬间退化为“仅路由”模式
最易被忽略的一点：conntrack 模块一旦被卸载，iptables 规则不会自动刷新或报错，你会花很长时间排查网络策略本身，而不是底层模块缺失。
