nftables规则不生效的主因是链优先级冲突、钩子位置错误或被高优先级链提前处理；需用nft list ruleset确认链绑定与priority，并用nft trace实时追踪数据包路径。
加载 nftables 规则后不生效，常见原因不是规则写错了，而是**链的优先级（priority）冲突、钩子位置不对、或被更高优先级的链提前处理/终止了数据包**。调试核心是搞清“数据包实际经过了哪些链、在哪个环节被接受/丢弃/跳转”，而不是只看自己加的规则是否在列表里。
确认规则是否真被加载并处于活跃链中
执行 nft list ruleset 查看完整规则集，重点检查：
- 你的表（table）、链（chain）是否已创建，且链绑定了正确的 hook（如 input、forward、output）和 priority
- 链的
type Filter hook input priority 0;中的 priority 数值是否符合预期 —— 数值越小，越早被执行（例如 -300 是 earliest，100 是较晚） - 同一 hook 下多个链按 priority 升序执行，相同 priority 则按添加顺序（但不建议依赖此顺序）
用 trace 功能实时观察数据包路径
这是最直接的调试手段。启用 trace 后，内核会记录匹配到的每条规则（含跳转、返回、终止动作），帮你看到数据包到底走到了哪一步：
- 临时开启 trace：比如追踪进来的 TCP 包
nft add rule ip filter input tcp dport 22 trace - 抓取 trace 日志：
sudo cat /proc/net/nf_tables_trace或用sudo nft monitor trace - 发一个测试包（如
ssh -p 22 localhost），立即查看 trace 输出，你会看到它依次匹配了哪些链、哪条规则、是否被 accept/drop/jump，甚至是否进入自定义链
检查是否有更高优先级链提前终止了流程
例如，系统默认可能有 priority -300 的 raw 链调用 ct state invalid drop，或 priority -200 的 mangle 链做了 early-drop；如果你的 filter 链 priority 是 0，那它根本收不到已被前面链 drop 的包。
- 运行
nft list chains ip filter和nft list chains ip raw对比各链 priority - 特别注意 raw 表中的 prerouting 和 output 链（常用于 bypass conntrack），以及 filter 表中 priority 小于你链的其他链
- 如果发现某条高优先级规则意外 drop 了你的流量，要么调低它的 priority，要么在它之前插入 bypass 规则（如
ct state established,related accept）
验证 hook 类型与方向是否匹配
同一个表里可以有多个链绑定不同 hook，但数据包只会进入对应方向的 hook。容易出错的情况：
- 想限制本机出站连接，却把规则加在
input链（只管进来的包），应改用output链 - 转发流量（如网关场景）没加在
forward链，而误加在input或output - 本地生成的回应包走的是
output，不是input—— 所以仅放行 input 的 22 端口，不代表你能 ssh 出去
提示：不要假设“我加了规则就一定起作用”。nftables 是按 hook + priority + 规则顺序逐包匹配的流水线，任何一环的 accept/drop/jump 都会影响后续。trace 是唯一能看清真实路径的方法。