nftables匿名集合支持单条规则匹配多个端口或ip，提升效率并减少规则数量；它直接在规则中用{}定义，不占命名空间，适合临时高频变更场景，且需搭配ct state new与established,related使用以保障安全。
用 nftables 的匿名集合，能一条规则匹配多个端口或 IP，避免重复写一堆相似 rule，既减少规则数量，又提升匹配效率。它不依赖命名、不占全局命名空间，适合临时、轻量、高频变更的业务端口放行场景。
匿名集合的基本写法
匿名集合直接写在规则里，用大括号 { } 包裹，支持端口、IP、协议等类型。例如：
-
放行多个 HTTP 类端口：
nft add rule ip filter input tcp dport { 80, 443, 8080, 8443 } ct state established,related accept -
限制特定源 IP 访问多个管理端口：
nft add rule ip filter input ip saddr { 203.0.113.10, 203.0.113.11 } tcp dport { 22, 9000, 9001 } accept -
混合协议和端口（需同类型）：只能同属
tcp dport或udp dport，不能混写 tcp/udp 在同一个 { } 里
为什么比多条独立规则更快
nftables 内核虚拟机对匿名集合做的是单次哈希查找或位图匹配，而不是逐条规则线性扫描。尤其当你要开放 10+ 个业务端口时：
- 写 1 条带 { 80, 443, 8080, 8443, 9000, 9001, 9002 } 的规则，内核只需一次集合查询
- 写 7 条单独
tcp dport 80 accept… 规则，内核要顺序比对 7 次，且每次都要解析完整条件 - 规则越靠前、匹配越频繁的位置，匿名集合带来的性能差异越明显
搭配连接状态使用更安全
只放端口不看连接状态容易被伪造包绕过。推荐组合写法：
- 先放已建立连接（保障返回流量）：
nft add rule ip filter input ct state established,related accept - 再用匿名集合放新连接入口：
nft add rule ip filter input tcp dport { 80, 443, 8080 } ct state new accept - 注意：
ct state new必须放在established,related之后，否则会拦截返回包
实际业务场景示例
假设你跑着 Web 前端（443）、API 服务（3000）、监控面板（9090）、日志接口（5044），可统一管控：
nft add rule inet filter input iifname "eth0" tcp dport { 443, 3000, 9090, 5044 } ct state new accept- 用 inet 地址簇自动兼容 IPv4/IPv6，不用分开写两套
- 加
iifname "eth0"明确限定公网网卡，避免内网规则误匹配
