Linux nftables 集合规则的批量维护

Linux nftables 的集合规则适合承载“经常变化、规则结构相对稳定”的清单，例如临时封禁地址、允许访问的网段或需要统一匹配的端口。批量维护的关键不是把几十条命令串起来，而是先创建一个命名集合，让规则只引用集合，再用一个 nft 脚本事务更新集合内容。这样新增、删除和替换清单时，不必反复改动 input 链中的规则。

先把变化清单从规则里拆出来

匿名集合直接嵌在规则中，规则删除后集合也随之释放，适合固定的小清单。批量维护应使用命名集合。下面的结构只让规则表达“命中集合就丢弃”，地址清单则放在 blocked_src 中：

table inet edge {
    chain input {
        type filter hook input priority filter; policy accept;
        # 规则只负责引用集合，不把变化的地址写死在链里
        ip saddr @blocked_src drop
    }

    set blocked_src {
        type ipv4_addr
        flags interval
        # interval 允许集合表达网段或地址范围
    }
}

这里的 type 必须和元素类型一致。单个 IPv4 地址可以不使用 interval，但网段、连续地址范围或需要自动合并相邻区间时，应在集合定义中声明它。不要把端口、IPv6 地址和 IPv4 地址混进同一个集合。

用一个脚本批量替换集合内容

临时操作可以直接执行 nft add element 或 nft delete element。需要把外部清单整体同步到防火墙时，建议把动作写入文件，一次交给 nft -f。下面的示例把集合清空，再装入一组新的地址；清空和添加属于同一份配置输入，避免维护脚本只执行了一半。

flush set inet edge blocked_src

add element inet edge blocked_src {
    198.51.100.10,
    198.51.100.0/24,
    203.0.113.0/25
}

# 先检查 nft 语法，再将同一份配置提交给 nft
# nft -c -f /etc/nftables.d/edge-set.nft
# nft -f /etc/nftables.d/edge-set.nft

批量脚本的边界也要写清：flush set 会删除集合当前元素，误把空文件提交到生产环境会让集合暂时失去保护内容。因此生成文件时要先校验输入非空、地址格式和网段范围；只想追加时不要使用 flush，改用一条或多条 add element。规则本身没有变化，引用集合的动作也不需要重复加载。

临时元素要分清 timeout 与 gc-interval

对自动过期的封禁项，可以在集合上声明超时能力，再给每个元素设置保留时间：

add set inet edge temp_block {
    type ipv4_addr;
    flags timeout;
    timeout 1h;
    gc-interval 5m;
}

# 只让这个地址保留十分钟，注释用于标记来源
add element inet edge temp_block {
    198.51.100.25 timeout 10m comment "rate-limit"
}

timeout 10m 是元素的存活时长；gc-interval 5m 不是把十分钟改成五分钟，而是影响过期元素何时被垃圾回收以及集合计数何时下降。短时高频更新的集合要关注容量上限，长期大集合则应根据回收压力调整间隔。需要从数据面动态更新集合时，还必须考虑 dynamic、size 和元素超时，不能只在规则中写 add 就认为容量会无限增长。

发布后用四个检查确认集合真的可用

不要只看命令退出码。先确认集合本身，再确认元素、规则引用和加载文件：

如果集合存在但规则没有引用它，问题在链配置；如果规则引用正常但元素查不到，问题在同步文件或集合类型；如果临时元素仍显示在列表中，也不能立即判定超时失效，还要结合 expires 和垃圾回收时机判断。

常见问题

为什么新增网段后规则仍然不命中？

先检查集合是否声明了适合区间的 flags interval，再用 nft list set 确认网段实际进入集合；同时确认规则匹配的是相同地址族和方向。

为什么删除元素后集合列表里还像是有记录？

带超时的元素可能等待垃圾回收才释放内部空间。看元素的过期状态，不要把 gc-interval 当成元素寿命。

批量同步前是否应该先改规则？

通常不需要。规则稳定、集合变化时，使用命名集合和单份 nft 脚本即可；只有集合类型、地址族或匹配语义发生变化时，才需要同步调整规则。