PREROUTING链中-i仅匹配入站接口，DNAT必须置于nat表PREROUTING开头、确保ip_forward=1且规则命中，本地回环流量不经过PREROUTING。
PREROUTING 链里 -i 参数只匹配入站接口，不能写成出站接口
很多用户在配置 DNAT 时，误以为 -i 是“流量要从哪个接口出去”，结果填了实际的外网出口（比如 eth1），但 PREROUTING 发生在路由决策前，此时内核还不知道该走哪条路由，-i 只能匹配数据包**真正进入系统的那个物理/虚拟接口**（如 eth0、br-lan、docker0）。如果填错，规则根本不会触发。
实操建议：
- 用
tcpdump -i eth0 port 80确认目标端口流量是否真从该接口进来 - 查接口名：运行
ip link show或cat /proc/net/dev，避免混淆ens33和enp0s3这类命名差异 - 容器或 K8s 场景下，宿主机 PREROUTING 规则通常需绑定
-i docker0或-i cni0，而非-i eth0
DNAT 必须放在 PREROUTING 链最前面，否则可能被早期规则跳过
iptables 规则按顺序执行，一旦某条规则带 -j ACCEPT、-j DROP 或 -j RETURN，后续规则就不再检查。如果前面有 ACCEPT 已放行原始目的 IP 的包，后面再写 -j DNAT 就完全无效。
常见错误场景：
- 防火墙脚本中先加载了通用白名单规则（如
-A PREROUTING -s 192.168.1.0/24 -j ACCEPT），而你的 DNAT 目标 IP 正好来自这个网段 - 使用了某些发行版预装的防火墙工具（如 ufw、firewalld），它们会在 PREROUTING 插入默认策略，把你的自定义规则压到下面
- 没加
-t nat表名，误把 DNAT 规则加到了 Filter 表的 PREROUTING（该表不支持 DNAT）
验证方法：iptables -t nat -L PREROUTING -n -v，看对应规则的 pkts 列是否为 0；若为 0，说明没命中，优先排查位置和匹配条件。
本地进程发往本机 IP 的包不经过 PREROUTING
这是最容易被忽略的底层行为：当源和目的都是本机（比如 curl http://192.168.1.100:8080），内核会走「本地回环路径」，直接进入 input 链，跳过 PREROUTING 和路由决策。所以你在 PREROUTING 写的 DNAT 对这类请求完全无效。
解决路径取决于你要做什么：
- 测试 DNAT 是否生效？必须从**另一台机器**发起请求，不能用
localhost或本机 IP - 确实需要本机访问也走 DNAT？改用 OUTPUT 链 + DNAT（仅适用于 IPv4，且需配合
route_localnet=1），例如：iptables -t nat -A OUTPUT -d 192.168.1.100 -p tcp --dport 8080 -j DNAT --to-destination 127.0.0.1:3000 - 更稳妥的做法是让应用直连目标服务，或用 hosts 绑定 + 反向代理，避免强依赖 iptables 回环 DNAT
开启 ip_forward 且确认 sysctl 值未被覆盖
DNAT 后若目标主机不是当前机器，内核必须转发包，否则会被静默丢弃。但仅仅 echo 1 > /proc/sys/net/ipv4/ip_forward 不够——某些系统（如 systemd-networkd、cloud-init、kubernetes kube-proxy）会在启动后期重置该值。
关键检查点：
- 运行
sysctl net.ipv4.ip_forward，输出必须是net.ipv4.ip_forward = 1 - 确认
/etc/sysctl.conf或/etc/sysctl.d/*.conf中有net.ipv4.ip_forward = 1，并执行sysctl --system重载 - 云服务器注意：部分厂商（如 AWS EC2）默认关闭转发，且控制台无法直接修改，必须在实例内正确配置并持久化
即使所有规则都对，只要 ip_forward 是 0，DNAT 后的包就会在路由阶段被丢弃，且不会报错，抓包只能看到 SYN 发出、无响应。