当前位置：首页 > 文章列表 > 文章 > linux > nftables reset counters 怎样做规则变更前后对比

nftables reset counters 怎样做规则变更前后对比

来源：17golang原创 2026-11-14 06:42:43 0浏览收藏

在 nftables 里，规则变更前后要比较命中情况，最稳妥的做法是把观察对象放进 named counter，先记录基线，再用 nft reset 把计数窗口归零，最后在相同时间窗口内读取 packets 和 bytes。reset 只处理计数状态，不会替你改写匹配条件、动作或链结构。

官方地址：https://www.netfilter.org/projects/nftables/manpage.html

如果只想看“这次规则变更之后有没有命中”，优先使用 named counter，并把“读取基线—重置—变更—同窗口读取”固定成一组操作。不要直接 reset 整个规则集，除非你确实要放弃其它表的统计窗口。

先分清 nftables 里要重置的对象

nftables 的计数器可以附在规则上，也可以声明为 named counter 后被规则引用。前者是匿名计数器，后者有稳定名称，适合做变更前后的观测。命令里的 reset counters 是复数形式，表示按范围处理多个计数器；reset counter

 则更精确。
这个区别很重要：规则变更通常只需要观察一个表或几条关键规则，如果直接执行全局 reset，可能把无关业务的计数窗口也清掉。下面的图是静态关系说明图，不是终端截图或运行证据。
图1：静态结构图展示规则、named counter、表范围和 packets/bytes 状态的关系；它是说明图，不是运行截图。
变更前先保存一份可解释的基线
基线不必复制整套规则文件，但至少要保留计数器所在的 family、table、counter 名称，以及当前的 packets 和 bytes。先查看规则和 named counter，确认名称没有拼错：
# 查看指定表里的规则与计数器，先确认观察对象的名称和位置
nft list table inet edge_filter

# 只列出指定表的 named counters，便于记录 packets 与 bytes 基线
nft list counters table inet edge_filter
如果规则使用了 named counter，输出中会出现类似 counter web_ingress 的对象。记录基线时不要只记“有命中”，要把两个数值都记下来：packets 更适合看请求次数，bytes 更适合发现大包、上传或响应体积变化。
建议用固定的记录格式，方便变更单或值班记录复用：

字段	示例	用途
family/table	`inet edge_filter`	限定 reset 的作用范围
counter	`web_ingress`	稳定定位观察对象
packets	`12480`	比较请求命中增量
bytes	`9823410`	比较流量增量
记录时间	`变更前`	对齐后续观察窗口

`按范围选择 reset 命令`


nftables 官方语法把 reset 设计成“列出并重置”有状态对象。针对 named counter，可以按三个范围选择命令：
# 只重置一个 named counter，适合单条规则或单个业务入口
nft reset counter inet edge_filter web_ingress

# 重置一张表里的所有 named counters，适合一次观察一组规则
nft reset counters table inet edge_filter

# 重置当前规则集可见范围内的 counters，影响最大，谨慎使用
nft reset counters
第一个命令最适合规则变更前后的单点对比；第二个命令适合把一张表视为一个统计窗口；第三个命令会扩大影响面，必须在记录中写清原因。reset 返回的内容可以作为“重置前最后一份快照”，因此不要把它的输出丢掉。
这里的关键是范围，而不是命令长短：单个 counter 的 reset 不会清空规则，表级 reset 也不改变表内的 chain、set 或 rule。它们改变的是计数状态。

规则变更后用同一个窗口比较命中增量
完成 reset 后再做规则变更，并等待一个预先约定的观察窗口。变更后不要拿历史日志里的累计值直接与当前值比较，而是重新读取同一批 named counters：
# 读取变更后的同一张表，保持 family、table 与基线一致
nft list counters table inet edge_filter

# 也可以连同规则一起查看，确认 counter 仍挂在预期规则上
nft list table inet edge_filter
比较时使用简单的增量：
# 变更后值减去变更前值，得到本次观察窗口的命中增量
delta_packets = after_packets - before_packets
delta_bytes = after_bytes - before_bytes
上面的片段是伪代码，变量名只表达计算关系。实际记录可以按下面的逻辑解释：
delta_packets = 0 且 delta_bytes = 0：观察窗口内没有命中，或流量没有经过这条规则。
  delta_packets > 0：规则至少匹配到了流量，接下来结合 chain 顺序和 verdict 判断最终动作。
  delta_bytes 增长明显但包数少：可能是少量大包或上传流量，不能只按请求数判断影响。
下面的第二张图把“基线、重置后的零点、同窗口结果”与规则对象分开表示，帮助区分统计口径和规则结构；它同样是静态说明图，不代表某台机器的实际输出。
图2：静态关系图强调基线值、重置后的统计零点和同窗口增量之间的关系，不是性能数据或运行截图。
匿名 counter 为什么不能按同样方式管理
匿名 counter 绑定在单条规则内部，没有可供命令直接定位的稳定名称。nftables 官方 Counters 说明中也指出，reset named counters 不会重置匿名 counters。不要因为看到规则里有 counter 就默认 nft reset counter ... 能找到它。
如果业务确实需要可重复的变更前后对比，应把关键观察点改为 named counter，并在规则评审中固定命名。为了清空匿名计数器而重载整套无状态规则可能产生更大副作用，例如其它有状态信息也会被丢弃；这不应当作为普通变更的默认动作。

一份可复用的变更记录模板
可以把下面的内容放进变更单，重点是让下一位值班同事知道 reset 的范围和比较窗口：
# 记录这次观察的对象、窗口和变更目标
对象：inet edge_filter / web_ingress
变更前基线：packets=12480，bytes=9823410
重置范围：仅 named counter web_ingress
观察窗口：规则变更完成后 10 分钟
变更后读取：记录 after_packets 与 after_bytes
比较方式：after - before（以 reset 后零点为本次窗口起点）
回退依据：若命中增量异常，恢复原规则并保留本次快照
如果已经执行了 reset，最直接的补救不是再次 reset，而是保留当前读数、写清新的窗口起点，并在后续比较中只使用这一次 reset 之后的数据。

常见问题
reset counters 会删除 nftables 规则吗？
不会。它重置的是 counter 的状态值，不会删除 table、chain 或 rule。
应该使用 table 级 reset 还是单个 counter？
只观察一条规则时用单个 counter；需要把一张表作为整体统计窗口时用 table 级 reset。范围越大，越要提前记录影响对象。
为什么 reset 后看不到匿名 counter 归零？
匿名 counter 没有稳定名称，named counter 的 reset 不负责清理它。要获得可管理的窗口，优先改用 named counter。
比较 packets 还是 bytes？
请求数量优先看 packets，流量规模优先看 bytes。排障时同时记录两者，避免少量大包造成误判。

小结：用 named counter 固定观察对象，先记录基线，再选择最小必要范围执行 reset，规则变更后用相同窗口读取 packets 和 bytes。这样得到的是可解释的命中增量，而不是被历史累计值污染的模糊判断。