iptables的-t nat PREROUTING规则不生效，主因是conntrack复用已建连接导致DNAT被跳过，需限定SNAT范围并清理conntrack状态。
iptables 的 -t nat PREROUTING 规则不生效，很多时候并不是规则写错了，而是被后续的 POSTROUTING 链中更早匹配的规则“覆盖”或“干扰”了——尤其是当做了 SNAT/DNAT 混用、多网卡转发、或启用了 conntrack 相关优化时，POSTROUTING 的执行顺序和连接跟踪状态会反向影响 PREROUTING 的行为。
PREROUTING 和 POSTROUTING 不是“前后独立”的两步
NAT 表中，PREROUTING 和 POSTROUTING 确实按包流向先后触发，但关键点在于：Linux 内核对已建立连接（conntrack entry）的包会跳过 PREROUTING 中的 DNAT 规则。一旦某个连接在 POSTROUTING 被 SNAT（比如 -j MASQUERADE 或 -j SNAT），该连接就进入 conntrack 表并打上 NAT 标记；之后同一连接的返回包、甚至新发起的同源目的五元组包，都可能复用该连接状态，导致后续 DNAT 规则完全不匹配。
- 典型表现：外网访问某端口，第一次能命中 PREROUTING DNAT，第二次开始就“失效”，日志里看不到匹配记录
- 根本原因：conntrack 认为这是“已有连接”，直接走连接跟踪重建路径，绕过 PREROUTING
- 验证方式：
conntrack -L | grep :你的端口，看是否已有 ESTABLISHED/RELATED 条目且 src/dst 与预期不符
常见踩坑场景：SNAT 在 POSTROUTING 太靠前
如果你在 POSTROUTING 链顶部写了类似 -o eth0 -j MASQUERADE，它会对所有从 eth0 出去的包做源地址伪装。而当这个包原本是经 PREROUTING DNAT 进来的（比如把 1.2.3.4:80 → 192.168.1.100:80），它的 reply 包返回时，内核会基于 conntrack 自动完成反向转换 —— 但如果原始请求包在 POSTROUTING 被 SNAT 过，整个连接的“原始五元组”就变了，DNAT 就无法正确关联。
- 后果：服务端看到的是伪装后的源 IP，但返回包的 dst 可能仍指向公网 IP，导致路由错乱或响应丢弃
- 解法：把
MASQUERADE/SNAT规则限定范围，例如只对! -s 192.168.0.0/16或-s 10.0.0.0/8 -d ! 10.0.0.0/8的流量做，避开内部转发流 - 更安全做法：用
-t nat -A POSTROUTING -s 192.168.1.0/24 -d ! 192.168.1.0/24 -j MASQUERADE明确指定需伪装的子网
检查和清理 conntrack 状态是调试关键
很多“规则不生效”其实是旧连接状态残留造成的假象。修改 iptables 后，必须同步清理 conntrack 表，否则新规则对已有连接完全无效。
- 清空所有 NAT 连接：
conntrack -F（生产环境慎用） - 只清特定协议/端口：
conntrack -D --dport 80 --proto tcp - 查看实时匹配情况：
iptables -t nat -vnL PREROUTING和iptables -t nat -vnL POSTROUTING，确认 pkts 计数是否增长 - 开启 trace 日志辅助定位：
echo 1 > /proc/sys/net/netfilter/nf_conntrack_log_invalid+ 使用iptables -t raw -A PREROUTING -j TRACE
替代方案：优先考虑使用 nftables
iptables 的链式匹配 + conntrack 交互逻辑复杂，尤其在混合 DNAT/SNAT 场景下容易隐性冲突。nftables 原生支持更清晰的 flowtable、更可控的 chain priority、以及 per-flow 的 nat 类型声明（如 dnat to vs snat to），大幅降低顺序依赖风险。
- nft 中可显式控制 chain hook priority：
type nat hook prerouting priority -100，避免被其他模块抢占 - 支持
ct status dnat等条件匹配，让规则真正按意图生效 - 若暂不能迁移到 nftables，至少避免在同一个 nat 表中混用无条件 MASQUERADE 和精细 DNAT
