Linux nftables 规则怎么定位：从计数器到链路命中确认丢包位置

端口突然不通时，最容易误判的是“规则看起来没问题”。nftables 的规则顺序、链类型和实际流量方向只要有一个没对上，配置文本就不能证明数据包走过了这条链。更稳的排查顺序是先看计数器，再用 trace 沿着真实路径定位，最后只改已经确认的那条规则。

先把“端口不通”拆成三个可验证的问题

以一台同时承载 Web 和内网转发的 Linux 主机为例，现象可能是客户端连接超时，也可能是服务已经收到连接但回包没有出去。对应的观察点并不一样：

这一步的目的不是马上修，而是把“防火墙问题”缩小为一个链路断点。这样即使现场规则很多，也不会靠猜测连续改配置。

用计数器判断流量有没有到达目标规则

先保存当前规则集，再查看带有 counter 的规则。下面的示例只读状态，不会改变现有配置：

sudo nft list ruleset > /tmp/nft-ruleset.before
sudo nft -a list chain inet edge input
sudo nft list counters table inet edge

重点看 packet 和 byte 是否在测试连接后增加。比如针对 TCP 8443 的规则一直是 0，而客户端确实在访问 8443，常见原因是流量走的是 forward 而不是 input，或匹配条件写成了错误的入接口。

计数器只能回答“这条规则有没有被经过”，不能单独说明最终结果。若计数器增长后连接仍失败，继续向后查，尤其注意同一链中后续的 drop、reject 或策略设置。

用 nft monitor trace 找到真正改变结果的位置

计数器能缩小范围，trace 才能把数据包在链中的路径串起来。排查时选择一个足够具体的临时规则，例如只追踪来自测试地址、目标端口为 8443 的 TCP 流量，避免让监控输出淹没现场。

sudo nft add rule inet edge input ip saddr 192.0.2.44 tcp dport 8443 meta nftrace set 1
sudo nft monitor trace

另开一个终端从测试主机发起一次连接，回到监控窗口观察 trace id、链名、规则句柄和最终 verdict。看到 packet 进入 input 后又在另一条规则上出现 drop，才可以把修复目标锁定到那条规则，而不是凭配置排列猜测。

转发场景要把观察点放到 forward 链；本机主动访问失败则优先检查 output。链名对不上时，trace 输出本身就是“排错方向错了”的证据。

改规则前先确认这四个边界

• 入口方向：本机服务通常走 input，路由转发走 forward，本机发起连接走 output。
• 地址族：同时存在 IPv4 和 IPv6 时，检查规则所在的 ip、ip6 或 inet 表。
• 策略与终止动作：前面有 accept 不代表后续路径不会改变结果，实际 trace 里的 verdict 更可靠。
• 临时标记：定位结束后删除带 meta nftrace set 1 的临时规则，避免持续产生诊断事件。

sudo nft -a list chain inet edge input
sudo nft delete rule inet edge input handle 
sudo nft list ruleset > /tmp/nft-ruleset.after

删除前记下句柄并再次列出规则，别用模糊的整链替换覆盖生产配置。需要长期保留的改动，应回写到发行版实际加载的配置文件，并在维护窗口做一次重载与回滚演练。

上线后的验收不能只看 nc 返回成功

修复后从同一测试地址再次发起连接，至少核对三件事：客户端是否完成握手；目标规则 packet/byte 是否按预期增长；trace 或日志是否显示放行路径。如果是转发流量，还要同时确认两侧接口的路径和回程路由。

如果客户端成功但计数器没有变化，说明测试流量可能命中了另一条更宽的规则；如果计数器增长但服务端没有监听，问题已经离开 nftables 范围。这个结果先别下结论，按证据把排查边界收窄。

常见问题

计数器一直是 0，是规则没有生效吗？

不一定。先核对链方向、入接口、地址族和端口，再确认测试流量是否真的经过这台主机。0 更像“没有命中这条规则”的信号。

为什么有 accept 记录，连接还是超时？

可能在后续链、另一地址族、回程路径或服务监听处失败。用 trace 查看最终 verdict，并检查 forward 与 output 的对应路径。

nft monitor trace 可以一直开着吗？

不建议。它适合短时诊断，规则上的 nftrace 标记与监控窗口都应在定位后关闭，避免持续产生日志噪声。

把排查顺序固定成一张小清单

遇到 Linux 端口异常时，可以按“保存规则集 → 看计数器 → 选准确链 → 短时 trace → 核对最终 verdict → 删除临时标记 → 三项验收”的顺序处理。这个顺序的价值在于每一步都能留下证据，也给错误修复保留了回退点。