iptables -t nat PREROUTING不生效主因是数据包未到达该链，如ip_forward未开启、匹配条件错误、规则被提前终止或容器规则抢占；POSTROUTING SNAT仅作用于离机包，本地出包走OUTPUT链；验证需结合LOG日志、tcpdump抓包及conntrack状态分析。
iptables -t nat PREROUTING 不生效的常见原因
PREROUTING 链在数据包刚进入网络栈时就处理，但很多情况下规则看似写了却没触发，核心问题往往不是规则语法错，而是数据包根本没走到这条链。
典型场景包括：
- 目标 IP 不是本机（比如转发到其他机器），但
net.ipv4.ip_forward未开启，内核直接丢包，不进 PREROUTING 的 DNAT 分支 - 规则匹配条件太宽或太窄：比如用
-d 192.168.1.100却实际收到的是192.168.1.100:8080，而没加--dport导致不匹配 - 规则插入位置错误：后加的
ACCEPT或RETURN规则提前终止了链遍历，DNAT 规则被跳过 - 容器或虚拟化环境（如 Docker、Podman）自带的 iptables 规则抢占了优先级，
iptables -t nat -L -n -v能看到计数器为 0 就很说明问题
POSTROUTING 在 SNAT 场景下“不生效”的真实路径
POSTROUTING 的 SNAT 规则只对**离开本机的数据包**生效，也就是说：它不处理本地进程发出的包（除非该包被路由出去），也不处理已由 PREROUTING DNAT 过、正发往本机上层协议栈的包。
常见误判点：
- 想用 POSTROUTING 改本地 curl 发出的包源地址？不行——这类包走的是 OUTPUT 链，得查
iptables -t nat -L OUTPUT - 做了 SNAT 但目标机器收不到：检查是否在正确的出口网卡上匹配（
-o eth0），而不是用-i或漏写接口限定 - SNAT 后连接仍失败：可能是目标服务没响应、防火墙拦截回程包，或 SNAT 地址不可路由（比如用了 127.0.0.1 或内网地址对外发包）
如何验证 nat 表链是否真的命中
光看 iptables -t nat -L 没用，关键看计数器和实际路径。最直接的方式是加日志 + 抓包双印证。
- 给规则加
-j LOG --log-prefix "PREROUTING-DNAT: "，再dmesg -w实时观察是否打日志 - 用
tcpdump -i any port 80在不同接口（如lo、eth0、docker0）抓包，确认数据包在哪个环节被改写或丢弃 - 检查 conntrack 状态：
conntrack -L | grep :80，DNAT/SNAT 成功后能看到原始和转换后的五元组 - 注意：某些发行版（如 RHEL/CentOS 8+）默认启用 nftables 后端，
iptables命令只是兼容层，真实规则可能在 nft 中，需运行nft list table ip nat核对
nat 表链顺序与内核处理流程强绑定
iptables 的“链顺序”不是用户定义的执行顺序，而是内核网络栈中固定的位置节点。PREROUTING 一定在路由决策前，POSTROUTING 一定在路由决策后、离开网卡前——这个顺序无法靠 -I/-A 改变，只能靠规则条件筛选。
真正影响行为的是：
- 同一链内规则顺序：靠
-I插入位置决定，匹配即停，后续规则不执行 - 不同表之间的协作：raw/mangle/nat/filter 各自独立，但 mangle 的 TPROXY 或 CONNMARK 可能影响后续 nat 判断
- 模块加载顺序：比如
nf_nat_ftp必须在nf_conntrack_ftp之后加载，否则 FTP 主动模式的 PORT 命令解析失败，导致 DNAT 失效
链本身不会“失效”，但如果你在错误的链、错误的时机、错误的上下文中试图修改地址，那它就是不会按你预期工作。
