核心结论：在从 iptables 向 nftables 迁移时，若自定义 NAT Chain 的 Hook 优先级配置不当（如 PREROUTING 优先级设为低于 -200），会导致数据包在进入 nf_conntrack 跟踪逻辑前触发 NAT 动作。由于 Netfilter 底层 NAT 强依赖连接跟踪上下文，过早执行将引发状态机丢失，导致 DNAT/SNAT 静默失效。解决方案是严格对齐 Netfilter 规范：PREROUTING 必须使用 -100，POSTROUTING 必须使用 100。
排查网络问题，最怕的不是报错，而是没有报错但流量神秘消失。习惯了 iptables 的老兵在初次接触 nftables 时，往往会被其极度灵活的框架反噬。近期在某次基础架构系统大版本升级（CentOS 7 迁移至 Rocky Linux 9.2，Kernel 5.14.0，nftables v1.0.4）过程中，遇到了一个经典的 NAT 击穿现场。
案发现场：诡异的 SNAT 穿透现象
某次集群割接后，业务反馈部分跨网段的出口流量间歇性超时。在网关节点（充当 SNAT 出口）上抓包，看到了令人脑溢血的一幕：
# tcpdump -i eth0 -nn host 10.200.1.50
14:22:31.102311 IP 10.0.5.10.43521 > 10.200.1.50.80: Flags [S], seq 123456789, win 64240, options [mss 1460]
14:22:32.105432 IP 10.0.5.10.43521 > 10.200.1.50.80: Flags [S], seq 123456789, win 64240, options [mss 1460]
10.0.5.10 是内网 Pod IP，10.200.1.50 是外部系统 IP。按理说，经过网关节点时，流量应该被 SNAT 成网关的物理网卡 IP，但抓包显示内网 IP 直接裸奔到了公网。由于上级路由没有该内网网段的路由表，数据包被丢弃，业务端表现为 TCP 握手超时。
检查 nftables 规则集，运维同学写的配置看起来“非常完美”：
table ip custom_nat {
chain postrouting {
type nat hook postrouting priority -250; policy accept;
ip saddr 10.0.0.0/16 oif "eth0" masquerade
}
}
触发匹配的网段、出接口、动作都没错，而且没有任何报错信息。
为什么自定义优先级的 NAT 链会静默失效？
要搞清楚这个问题，必须剥开 Netfilter 的内核源码。
在原生的 iptables 时代，nat 表的 Hook 优先级是内核硬编码固定的。你在 POSTROUTING 链写规则，它必然在 priority 100 执行。但 nftables 把定义权完全交给了用户，允许你在创建 Base Chain 时随意指定 priority 整数值。
上述配置中，SRE 为了让 SNAT “尽可能早地执行以减少延迟”，将 postrouting 链的 priority 设置为了 -250。这就是灾难的根源。
Netfilter 的核心数据包流转链路有着严格的优先级排序（定义在 include/uapi/linux/netfilter_ipv4.h）：
-
NF_IP_PRI_RAW= -300 -
NF_IP_PRI_CONNTRACK= -200 (关键点) -
NF_IP_PRI_MANGLE= -150 -
NF_IP_PRI_NAT_DST= -100 -
NF_IP_PRI_FILTER= 0 -
NF_IP_PRI_NAT_SRC= 100
NAT 的本质依赖于 nf_conntrack（连接跟踪模块）。只有在 Conntrack 建立起一条连接（状态为 NEW）时，NAT 引擎才会去计算并绑定转换地址。后续属于同一条连接的数据包，直接复用 Conntrack 表里的 NAT 绑定信息，根本不会再去遍历 NAT 规则链。
我们来看内核源码 net/netfilter/nf_nat_core.c 中的 nf_nat_inet_fn 函数（处理 NAT Hook 的核心逻辑）：
unsigned int
nf_nat_inet_fn(void *priv, struct sk_buff *skb,
const struct nf_hook_state *state)
{
struct nf_conn *ct;
enum ip_conntrack_info ctinfo;
/* 获取当前数据包的连接跟踪信息 */
ct = nf_ct_get(skb, &ctinfo);
if (!ct) {
/* 如果拿不到 ct 上下文，直接 ACCEPT 放行，跳过后续所有 NAT 处理！ */
return NF_ACCEPT;
}
// ... 后续计算和应用 NAT 转换的逻辑
}
当 priority 设置为 -250 时，这个自定义的 NAT Chain 会在 Conntrack Hook (-200) 之前执行。此时数据包刚进入协议栈，nf_ct_get(skb, &ctinfo) 返回 NULL。内核一看没有连接跟踪上下文，直接返回 NF_ACCEPT 放行数据包，完全跳过了你辛辛苦苦写的 masquerade 规则。这就是内网 IP 发生“裸奔逃逸”的根本原因。
排查实录：nftrace 链路追踪
为了验证推论并在现场拿到铁证，我们使用 nftables 自带的神器 nftrace 进行包流向追踪。
首先，在 raw 链层面给测试包打上 trace 标记：
nft add table ip debug_trace
nft add chain ip debug_trace preraw { type filter hook prerouting priority -350\; }
nft add rule ip debug_trace preraw ip daddr 10.200.1.50 meta nftrace set 1
随后，另开一个终端监听 trace 日志：
nft monitor trace
发起一次请求，观察 trace 输出（精简版）：
trace id e4b2c1 ip debug_trace preraw packet: iif "eth0" src 10.0.5.10 dst 10.200.1.50 ...
trace id e4b2c1 ip debug_trace preraw rule ip daddr 10.200.1.50 meta nftrace set 1 (verdict continue)
trace id e4b2c1 ip custom_nat postrouting packet: oif "eth0" src 10.0.5.10 dst 10.200.1.50 ...
trace id e4b2c1 ip custom_nat postrouting policy accept (verdict accept)
注意看输出，数据包流经了 custom_nat postrouting，但是没有触发任何 rule 匹配，直接命中了 policy accept退出。因为内核底层 nf_nat_inet_fn 直接 bypass 了规则引擎。
修复方案极其简单，遵守内核规范即可：
修改 Base Chain 的优先级至 srcnat 的标准位置（100）：
nft add chain ip custom_nat postrouting '{ type nat hook postrouting priority 100; policy accept; }'
重载规则后，抓包瞬间恢复正常，NAT 转换成功。
扩展防御：iptables-nft 混用下的优先级重叠踩坑
在 K8S 等容器环境中，还存在另一个隐蔽的黑洞：iptables-legacy 与 nftables (或 iptables-nft) 混用。
许多 OS 发行版默认采用 iptables-nft（用 iptables 的命令行包装 nftables 底层），Kube-proxy 也因此创建了大量 priority = -100 的 nftables nat 规则。
如果你使用原生 nftables 语法另外创建了一个 table，且优先级也设为 -100，会发生什么？
根据 Netfilter 设计，相同优先级 Hook 的执行顺序是不确定的（通常取决于内核模块加载顺序或 Table 名称字母序）。如果你的原生 nftables 规则先执行并且返回了 ACCEPT（没有做 NAT），那么 kube-proxy 的 KUBE-SERVICES NAT 规则即便随后执行，也可能因为连接状态的改变而无法生效，导致 NodePort 流量随机超时。
最佳实践：在任何生产服务器上，绝对不要混用多种防火墙工具。要么全盘接管使用纯正的 nftables，要么彻底清理原生 nft 规则，交由 iptables-nft 代理。使用 lsmod | grep _tables 检查，坚决剔除 ip_tables 和 x_tables 内核模块。
常见问题 (FAQ)
Q1: 修复了 nftables 的 NAT 规则并 reload 后，为什么已有的长连接依然是断网状态？
因为 NAT 操作只在连接建立（ct state NEW）的首包触发。对于已经建立的存量连接，它们在 Conntrack 表里的记录依然是未 NAT（或者错误 NAT）的状态，后续包直接复用该错误记录。排查时必须用 conntrack -D -p tcp --dport <端口> 清除脏连接，强制触发重连与重新 NAT 计算。
Q2: 怎么快速确认当前系统里挂载了哪些 Netfilter Hook 及其对应的真实优先级？
如果是较新版本的 nftables (>= 1.0.0)，可以直接使用命令：
nft list hooks
如果是老版本或者想看底层全貌，可以通过 BPF 工具或检查 /proc/net/netfilter/nf_log 间接推断，或者通过 nft list ruleset 提取所有 Base Chain 的 priority 声明逐一盘点。
Q3: 为什么有时候 SNAT 成功了，抓包看到了网卡公网 IP，但回程包依然被内核无情 DROP？
除了 NAT，最容易忽视的是 rp_filter（反向路由校验）。如果数据包的入口网卡和内核路由表中回程目标不一致（非对称路由），哪怕 NAT 配置完美，数据包也会在 IP 层被直接丢弃。排查时重点检查 sysctl -a | grep rp_filter，在复杂网络拓扑下通常需要设为 2 (松散模式) 或 0。
Q4: 刚从 iptables 迁移到 nftables，发现 CPU softirq/usr 飙升，QPS 下跌怎么查？
极大概率是直接用工具（如 iptables-restore-translate）做了 1:1 的线性转换。iptables 的线性链匹配时间复杂度是 O(N)，而 nftables 最大的性能优势是支持匿名集合 (Sets) 和映射字典 (Maps) (O(1) 复杂度)。千万不要在 nftables 里写一万行 ip saddr X.X.X.X accept，应当合并为 ip saddr { 1.1.1.1, 2.2.2.2 } accept。