Linux nftables 规则命中怎么核对：counter、链优先级与回滚边界

线上主机明明已经写好 nftables 规则，业务端口却总出现时通时不通的状况，最容易误判的误区是“规则文件里存在这一行”，完全不等于“数据包真的命中处理了这一行”。排查时要把配置文本、当前内核运行的规则集、数据包实际转发路径分开校验，再通过 counter 的计数变化拿到明确的事实依据。

先确认当前正在生效的 ruleset，再观察目标规则的 counter 是否发生增长，最后检查 base chain 的 priority 配置和前置 verdict 动作；只有这三层都核对匹配，放行或拒绝的结果才有明确溯源依据。

触发信号：端口状态和规则判断对不上

典型现场是：应用监听在 0.0.0.0:8443，本机访问正常，外部请求却超时；或者同一条规则在测试机上命中，在生产机上 counter 一直是零。这里先别急着把策略改成全放行，先确认问题属于“包没到主机”“包到了但没进目标链”，还是“进链后被更早的 verdict 结束”。

操作前先记录服务监听状态和当前全量规则集快照：

ss -lnt '( sport = :8443 )'
nft -a list ruleset > /var/tmp/nftables-before.nft

第一条输出只能确认对应服务有没有正常监听端口，第二条才是防火墙当前的运行状态快照。保存快照时要注意输出内容里可能带有内部地址和端口信息，需要发给其他人协助分析前要先做好脱敏处理。

快速判断：用 counter 证明包到底走了哪条规则

把待观测的目标规则放在独立的明确链里，给它配置对应的计数器。举个场景，只想统计所有进入8443端口的TCP流量，可以在维护窗口临时加载一条针对性的短规则：

add rule inet filter input tcp dport 8443 counter comment "observe-8443"

实际部署不要盲目追加同类型规则，先用带句柄的列表查询确认当前链里是否已经存在同名或同匹配条件的规则：

nft -a list chain inet filter input
nft list chain inet filter input

随后从一台明确的客户端发起一次连接，再重复查看该规则的 packets 和 bytes。计数不增长时，结论不是“nftables 失效”，而是这条匹配条件没有接到目标流量，或者包在更早的链上已经结束。

处理步骤：沿着 hook、链优先级和 verdict 往前查

nftables 的 base chain 会挂到诸如 input、forward、output 的 hook 上。包进入主机时，先确认它经过的是哪个 hook；把只处理转发流量的规则放进 input，或者把容器流量当成主机本地流量，都会让 counter 长时间不动。

接下来核对 base chain 的优先级配置和默认策略：

nft -a list chain inet filter input
nft list table inet filter

同一个 hook 下，数值更小的 priority 会更早运行。若前面的链已经执行了 drop，后面的放行规则没有机会；若前面执行了 accept，后续链也不会再改变这个包的最终判断。规则顺序和链优先级要一起看，不能只截取命中的那一行。

需要追踪单个测试包的完整流向时，可以短时打开trace功能：

nft monitor trace

这个命令会持续输出数据包全链路处理日志，验证完成后要及时停止监视。生产环境不要长时间开启trace作为常驻日志方案，它会产生大量额外输出，还可能暴露不该对外公开的内部地址信息。

把修改做成可回滚的小步

规则变更前先留存一份带句柄的现场快照，提前准备好仅包含最小变更内容的规则片段。验证规则效果时一次只调整一个条件：先改匹配范围，确认counter计数变化正常之后，再调整priority或者前置verdict动作。这样验证出问题的时候，可以明确知道是哪一步操作改变了规则的实际运行行为。

nft -a list ruleset > /var/tmp/nftables-before.nft
# 维护窗口内加载经过审阅的最小片段
nft -f /var/tmp/nftables-change.nft
nft -a list ruleset > /var/tmp/nftables-after.nft

如果外部探测仍然超时，或者counter已经增长但上层应用没有收到连接请求，立刻恢复提前校验过的旧规则快照，重新确认端口监听状态。不要直接执行一串按句柄删除的命令：句柄编号会随着规则的增删动态变化，直接复制旧快照里的编号很容易删错其他正常规则。

告警确认：不要把“计数增长”当成业务成功

counter出现增长只能说明数据包匹配到了这条规则，不代表后续的TLS握手、应用层鉴权或者后端回包流程已经成功完成。规则效果验收至少要覆盖三层校验：本机确认服务监听端口正常，防火墙侧确认目标规则的包数计数正常增长，客户端侧确认连接能正常建立或者明确收到对应的拒绝响应。

• 预期放行却看不到counter增长：优先排查hook类型、地址族、端口方向和更早的前置规则。
• counter正常增长但客户端始终超时：继续排查服务进程状态、回程路由和上游负载均衡配置。
• 规则命中后流量仍然被拒绝：检查是否存在优先级更早的其他链、不同hook节点或者状态匹配拦截条件。

复盘项：把规则验证写进发布清单

每次规则变更至少要留存规则快照、变更目的说明、测试源地址、目标端口、预期verdict动作和预定义回滚文件。针对远程主机的规则操作，回滚动作的设计必须不依赖当前SSH连接可以继续存活，不然防火墙配置一改就可能直接断连失去远程恢复通道。

还要注意一个很容易被忽略的细节：不同发行版的持久化服务和配置加载逻辑都不一样。这里只讨论运行态的nftables规则集；主机重启后规则能不能自动恢复，要针对目标系统的服务配置单独做验证，不要把“当前运行规则正确”直接等同于“重启后规则也一定正确”。

常见问题

counter 一直是零，是规则没有加载吗？

不一定。先用 nft list ruleset 确认规则确实在当前规则集里，再检查 hook、地址族、端口方向和前置 verdict。规则存在但没有匹配到目标流量时，counter 同样会是零。

priority 数字越大越先执行吗？

不是。同一个hook节点下，数值更小的priority通常会更早参与流量处理。最终还是要结合当前base chain的列表输出和trace结果做实际核对，不要只靠配置文件里的排列顺序直接判断执行优先级。

能不能看到规则命中后具体做了什么？

可以在短时验证窗口使用 nft monitor trace 观察包经过的链和规则。用完及时停止，并对输出中的地址、端口和内部命名做必要脱敏。

为什么删规则时不建议直接照抄 handle？

handle编号会随着规则增删动态变化，旧快照里记录的编号可能已经对应了完全不同的规则对象。更稳妥的操作是重新拉取当前链的全量规则列表，通过唯一comment标注、匹配条件和现场状态核对完之后，再执行最小范围的变更操作。

nftables问题排查的核心不是把规则写得多么复杂，而是让每一步判断都有可溯源的依据：当前ruleset输出证明配置确实已经加载进内核，counter计数证明数据包确实到达了目标规则，链优先级和verdict动作能解释后续其他规则有没有机会参与处理，最后提前留好的快照能保证改错了随时可以回退到正常状态。