nft describe 并非真实命令,官方工具链中不存在;可用 nft list ruleset -e 查看内核编译后的数值表达式结构,用 nft monitor trace 实时观察规则匹配路径,结合 counter 统计验证效率。

nft describe 并不是一个真实存在的 nftables 命令,nftables 官方工具链中没有 nft describe 指令。
你可能混淆了以下几种情况:
-
nft list ruleset -a:显示规则带自动生成的句柄(handle),用于精准定位和删除; -
nft list ruleset -n -e:以数字格式(如 IP 地址不解析为域名)+ 扩展语法输出,更贴近内核实际加载形式; -
nft list ruleset -j:输出 JSON 格式,便于程序解析,含完整表达式结构; -
nft monitor trace:实时捕获匹配过程,显示每条规则是否命中、跳转链、连接跟踪状态等——这是最接近“运行时字节码行为观察”的方式; - 内核级调试需配合
CONFIG_NF_TABLES_DEBUG=y编译选项 +perf或bpftrace跟踪nf_tables_do_chain等函数,但这已超出用户态命令范畴。
✅ 真正能帮你“深度核对底层字节码效率”的实用路径
1. 查看规则编译后的精简表达式结构
使用 -e(extended)参数暴露内核真正执行的表达式树:
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }
nft add rule inet filter input iifname "lo" counter accept
nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport {22, 80, 443} ct state established,related counter accept
然后执行:
nft list ruleset -e
你会看到类似:
ip saddr 0xc0a80100/0xffffff00 tcp dport ∈ { 0x0016, 0x0050, 0x01bb } ct state ∈ { 0x00000002, 0x00000004 }
→ 这里的 0x0016 就是端口 22 的十六进制,0x00000002 是 ESTABLISHED 状态值。说明规则已被编译为紧凑的数值匹配,集合 {22,80,443} 已转为高效哈希或位图查找,而非逐个比较。
2. 验证集合是否启用优化结构
nftables 对 type ipv4_addr . inet_service 类复合集合会自动选用 hash:ip,port 或 rbtree 后端。确认方式:
nft list sets
# 若看到 set myset { type ipv4_addr . inet_service\; flags interval\; }
# 则表示启用了区间压缩(如 192.168.1.0/24 → 自动展开为范围)
⚠️ 注意:普通
type ipv4_addr集合在元素 ≤ 64 时用 bitmap,更多时切到 hash —— 这些决策由libnftnl在加载时完成,无需手动干预。
3. 用 nft monitor trace 观察真实匹配路径
开启一个终端监听:
nft monitor trace
另一终端触发请求(如 curl -s http://localhost),你会看到逐跳日志,例如:
trace id 0123456789abcde0 ip protocol tcp sport 54321 dport 80 → verdict continue → chain input → rule #1 (iifname "lo") matched → accept
或:
→ rule #3 (tcp dport {22,80,443}) matched → accept
→ 这直接反映哪条规则被命中、是否发生集合查表、有无短路退出,是验证“效率”的第一手证据。
4. 对比不同写法的规则计数器增长
给关键规则加 counter,持续压测后对比 packets 字段:
nft add rule inet filter input tcp dport 22 ct state new limit rate 5/minute counter name ssh_limit_drop reject nft add rule inet filter input tcp dport 22 ct state new counter name ssh_all_drop reject
运行 nft list chain inet filter input -a,观察:
-
ssh_limit_drop的 packets 是否远少于ssh_all_drop?
→ 若是,说明limit表达式生效且未拖慢主路径;
→ 若两者增长一致,可能是limit未生效(如未加ct state new导致对每个包都检查)。
❌ 不推荐的操作(常见误区)
- 试图用
strace nft ...查看系统调用 → 只能看到 netlink 通信,看不到字节码; - 依赖
nft list ruleset -p(不存在该选项)→ 无此功能; - 以为
nft describe rule能输出汇编 → 实际无此设计,nftables 故意隐藏虚拟机细节,专注声明式语义。
nftables 的字节码优化是内核自动完成的,用户只需写清晰规则、善用集合与状态匹配,再通过 -e 和 monitor trace 验证效果即可。不需要、也无法手动“反编译”字节码。











