优化 nftables 性能的核心是精简匹配路径：将 ESTABLISHED/RELATED 规则置顶、用 map 替代线性规则链、分层拆解 fastpath/policy/fallback 链、慎用 log 与 counter。

避免 nftables 规则集查找冗余，核心是让数据包“少走几步、少比几次”——不靠堆规则数量，而靠结构设计压缩匹配路径。重点不在删哪条规则，而在怎么组织规则、用什么结构、放在哪一层。

把高频流量提前放行，别让它跑完整条链
已建立的连接（ESTABLISHED/RELATED）占实际流量 70% 以上，这类包不该参与任何策略判断。必须把这条规则放在 input/forward 链最顶端：

• nft add rule inet filter input ct state established,related accept
• 后续所有规则都跳过它，CPU 不再做无谓匹配
• 若还混着 ct state invalid drop，建议紧随其后，快速过滤非法状态包

用 map 替代长链，把“遍历 N 条规则”变成“查一次哈希表”
万级 IP 黑名单、千级端口白名单，硬编码规则会触发线性扫描，延迟随条目数直线上升。换成 map 后，无论 100 还是 10 万条，匹配耗时基本恒定：

• 创建带 verdict 映射：nft add map inet filter ip2verdict { type ipv4_addr : verdict \; }
• 插入策略：nft add element inet filter ip2verdict { 192.0.2.10 : drop, 203.0.113.5 : accept }
• 链中调用：nft add rule inet filter input ip saddr @ip2verdict
• 注意：map 键值对需预先规划容量（加 size 65536），避免运行时扩容抖动

分层拆链，按处理意图隔离策略粒度
别把所有逻辑塞进一条 input 链。按流量生命周期分三层，每层只干一件事：

• fastpath 链：只做 conntrack 状态检查 + 本地回环 + 管理网段放行，80% 流量在此结束
• policy 链：挂载 map、concat、命名 set 等结构化策略，专注租户、服务、接口维度控制
• fallback 链：仅保留 drop 或限速规则，不掺杂具体策略，确保兜底干净且不拖慢主路径

慎用日志与计数器，它们不是监控工具而是性能拖累
log target 和 counter 在高并发下会频繁触发软中断、写内存、刷缓存：

• 临时调试才开 log，生产环境用 log prefix "DEBUG: " + 严格限制触发条件（如仅 tcp dport 22 ct state new）
• 计数器除非用于限速或告警，否则一律移除；nft list ruleset 查看时带 -a 才显示计数，不影响运行时
• 真要长期统计？改用 eBPF map 或 conntrack 统计接口，绕过 netfilter 规则路径

不复杂但容易忽略