nftables规则集需结构化管理与版本控制，通过表隔离（inet filter/forward/nat）、链分层（priority 0/10/20）、集合复用（blacklist/temp_allow）及文件化git部署实现可维护、可审计、可回滚。
nftables 规则集的结构化管理与版本控制，核心在于把防火墙配置从“命令行拼凑”升级为“可维护、可审计、可回滚”的基础设施代码。它不是写一堆 nft add rule 就完事，而是通过表隔离、链分层、集合复用和文件化部署，让万级规则依然清晰可控。
按场景建表，物理隔离策略域
表不是语法容器，而是逻辑边界。混用协议或用途会导致策略冲突、排查困难：
- 统一用
inet表族：同时覆盖 IPv4/IPv6，避免双栈重复定义 -
inet filter专用于主机防护：只放行 loopback、established、必要服务，其余默认 drop -
inet forward或inet docker单独建表：转发流量与主机策略完全解耦，Docker 启动时不会意外覆盖 input 链 -
inet nat集中管理地址转换：DNAT/SNAT/端口映射全在此表，便于审计和迁移，不和过滤规则搅在一起
链按 priority 分层，明确执行顺序
链的 priority 决定规则何时介入数据流，数字越小越早执行。这不是随意编号，而是策略分层设计：
- priority 0：用于黑名单拦截（如
ip saddr @badnets drop），第一时间阻断已知恶意源 - priority 10：做连接状态检查（
ct state established,related accept），保障已有会话不被前面的黑名单误杀 - priority 20：白名单放行（SSH/HTTP/HTTPS），兜底允许合法服务，避免策略收紧后连不上
- 自定义链（如
logging）用于复用逻辑：集中定义日志动作，各主链用jump logging调用，修改一处即全局生效
规则靠集合驱动，不堆单条语句
面对成千上万 IP 或端口，写一万条规则是反模式。高效做法是用集合承载数据，规则只写一次匹配逻辑：
- 创建带 interval 的集合支持 CIDR：
nft add set inet filter blacklist { type ipv4_addr\; flags interval\; } - 批量导入网段：
nft add element inet filter blacklist { 192.0.2.0/24, 203.0.113.10-203.0.113.20 } - 规则仅一行：
nft add rule inet filter input ip saddr @blacklist drop，匹配性能不受集合大小影响 - 启用 timeout 可自动清理过期条目：
nft add element inet filter temp_allow { 203.0.113.5 timeout 5m }
文件化 + Git 版本控制，实现原子部署与可追溯
所有规则必须保存为纯文本文件（如 /etc/nftables.conf），禁用逐条命令操作：
- 用
nft -f /etc/nftables.conf一次性加载，失败则整个回滚，无中间态风险 - 将配置文件纳入 Git 仓库：master 分支对应生产环境，dev 分支测试新策略，hotfix 分支处理紧急封禁
- 配合 pre-commit 钩子校验语法：
nft -c -f nftables.conf，防止非法配置提交 - 每次提交附带变更说明，自动记录 SHA-256 哈希值与时间戳，支持秒级比对差异（新增/删除哪些 IP 或端口）
