Linux nftables 规则顺序导致流量不通时怎么定位

nftables 遇到“规则明明写了 accept，流量还是不通”时，先别急着把允许规则往前插。最容易漏掉的是：同一个 hook 可以挂多个 base chain，priority 决定它们的先后；而 accept 只结束当前 base chain，后面的 base chain 仍可能继续处理，直到某条规则或策略执行 drop。

先把 nftables 的链与 priority 摊平

排查目标应先固定在一个方向，例如本机服务不通看 input，转发不通看 forward。表名只是组织规则的容器，真正决定数据包是否经过某组规则的是 base chain 的 hook。先把规则集完整列出，不要只盯着配置文件里最熟悉的那张表：

# 显示规则句柄，便于把命中计数与具体规则对应起来
sudo nft -a list ruleset

# 只展开目标表，减少排查时的无关信息
sudo nft list table inet filter

记录同一 hook 下每条 base chain 的 priority。数值越小越先评估，例如 -10 会先于 0；相同 priority 的链不保证固定顺序。若一条链的 policy 是 drop，它就是重要的兜底边界：前面的链即使 accept 了，数据包仍可能来到这里。

用 counter 区分规则没匹配与后续链丢包

看到“连接超时”只能说明最终结果，不说明哪条规则做了决定。可以在不改变判定的前提下，为可疑规则加上 counter；如果规则已经存在，优先用带句柄的完整列表确认位置，再选择插入或替换。临时观测点要尽量窄，避免把所有流量混在一个计数器里。

# 给来自测试网段、目标端口的允许规则增加计数器与句柄
sudo nft add rule inet filter input ip saddr 192.0.2.0/24 tcp dport 8443 counter accept

# 查看计数器是否随一次可控测试流量增长
sudo nft -a list chain inet filter input

计数为 0，通常先查流量是否真的进入这个 hook、地址族是否写对、接口方向是否判断反了；计数增长但仍不通，则继续查同一 hook 的后续链和它们的 policy。计数器只证明规则被命中，不代表包已经穿过整个规则集。

accept 为什么仍可能挡不住流量

这是 nftables 排错中最容易误判的一点。一个 base chain 内的 accept 会结束当前链的继续评估，但数据包仍可进入同一 hook 上 priority 更大的下一个 base chain。相反，drop 会立即结束整个规则集，后面没有“再 accept 一次”来挽回。

因此不要把“允许 SSH”放在 priority 0 的链里，就默认它能覆盖 priority 10 的默认丢弃链。更稳妥的做法是让职责清楚：一条链负责早期分类，另一条链负责最终策略，并为最终策略留下明确的允许条件。若多条链只是历史遗留，合并或重新分配 priority 往往比继续叠加规则更容易维护。

修改后怎样做反向核对

修复不要只看一次成功连接。先重新列出完整规则集，确认修改落在预期 chain 和 priority；再发送一条可区分的测试流量，同时观察允许规则和兜底规则的计数。最后检查其他端口或来源没有被一并放行，必要时把临时 counter 删除或重置，避免长期观测点干扰日常判断。

# 修改后重新查看完整结构，确认没有重复的同 priority base chain
sudo nft -a list ruleset

# 测试完成后按句柄删除临时观测规则，避免留下重复允许项
sudo nft delete rule inet filter input handle 42

如果规则在服务重载、容器启动或防火墙管理器刷新后又恢复，继续追查生成它的配置源；不要只在运行时规则集上反复手改。本文范围只覆盖链、priority、policy 和 counter，路由表、rp_filter、服务监听和安全组等问题应另开层次验证。

常见问题

同一个 hook 的 priority 越大越优先吗？

不是。nftables 按数值从小到大评估，较小的 priority 更早；相同 priority 的链顺序不应依赖。

accept 之后还能被 drop 吗？

可以，只要还有同一 hook 的后续 base chain，或者后续网络阶段存在会丢弃它的规则。

counter 一直是 0 就能证明 nftables 没收到包吗？

不能。它只能说明这条规则没有命中，还要核对 hook、地址族、匹配条件和流量方向。