nftables 仅支持匹配内核已解析的协议头部字段，不处理应用层载荷。它可高效过滤链路层（vlan/arp）、网络层（ipv4/v6）、传输层（tcp/udp/icmp）及部分扩展头字段，支持位运算与多层组合，但无法匹配http、tls、dns等应用层内容。
nftables 本身不解析应用层载荷，但能直接访问并匹配网络协议栈已解析的各层头部字段——从链路层（如 VLAN、ARP）、网络层（IPv4/IPv6）、传输层（TCP/UDP/ICMP）到部分扩展头（如 ICMPv6 类型、IPv6 扩展头）。这种“协议头过滤”是 nftables 的核心能力，无需用户态介入，全部在内核 netfilter hook 点完成，高效且低延迟。
支持的协议头字段类型明确、结构固定
nftables 表达式系统只处理内核网络栈已解码的字段。例如：
- IPv4 头：
ip version、ip ihl、ip tos、ip ttl、ip protocol、ip saddr、ip daddr、ip frag-off - IPv6 头：
ip6 version、ip6 hoplimit、ip6 saddr、ip6 daddr、ip6 nexthdr - TCP 头：
tcp sport、tcp dport、tcp flags（支持位运算如& (syn | ack) == syn）、tcp window、tcp option（有限支持 MSS、WS、SACK 等标准选项） - UDP 头：
udp sport、udp dport - ICMP/ICMPv6：
icmp type、icmp code、icmpv6 type（如nd-router-advert、nd-neighbor-solicit） - VLAN/802.1ad：
vlan id、vlan proto、vlan priority；嵌套 VLAN 支持vlan id和vlan id . vlan id
这些字段在规则中可直接使用，例如：
nft add rule ip filter input ip protocol tcp tcp dport 22 ct state new counter accept nft add rule ip6 filter input ip6 nexthdr icmpv6 icmpv6 type nd-neighbor-solicit ip6 saddr fe80::/10 counter accept
用好 flags 和 option 实现精细控制
TCP 标志位是常见审计点。tcp flags 是一个 8 位字段，nftables 支持按位与（&）和比较（==），可用于识别握手、异常包或协议行为：
- SYN 扫描检测：
tcp flags & (fin | syn | rst | ack) == syn - FIN+ACK 异常连接关闭：
tcp flags & (fin | ack) == (fin | ack) - 拒绝无标志位的“空包”：
tcp flags == 0
TCP 选项也部分可用，如：
- 提取 MSS 值：
tcp option maxseg size 1460（匹配 MSS ≤ 1460 的 SYN 包） - 检查窗口缩放是否启用：
tcp option wscale
注意：并非所有 TCP option 都被内核解析并暴露给 nftables；仅标准、常用且由 nf_conntrack 或 tcp_parse_options() 提前提取的字段才可用。
一款AI开发辅助工具，主要用于通过后台进程将编码任务委托给 Codex、Claude Code 或 Pi 智能体。适用场景：（1）构建或创建新功能/应用，（2）审查 PR，适合需要提升相关任务效率的用户。
组合多层头部字段提升策略精度
nftables 支持跨层拼接（concat）或链式条件，避免规则爆炸。例如：
- 同时约束 IP 协议类型和 TCP 端口：
ip protocol tcp tcp dport 8080 - 匹配带特定 DSCP 的 VoIP 流量：
ip tos 0xb8（EF 值） - 过滤双 VLAN 封装流量：
vlan id 10 vlan id 100（外层 VID=10，内层 VID=100）
这类组合仍属 L3/L4 层原生字段，全部在内核一次遍历中完成判断，性能远高于用户态抓包。
不能依赖的“伪头部字段”需警惕
以下内容 nftables 无法直接匹配，常见误区包括：
- HTTP URL、User-Agent、Host 头等应用层内容
- TLS SNI、ALPN、证书信息
- DNS 查询域名（QNAME）或响应码
- 自定义私有协议头中的 magic 字段、版本号、校验和
- TCP payload 任意偏移字节（如“第 12 字节是否为 0x47”）
这些必须通过 eBPF、nfqueue 或 conntrack helper 协同实现，nftables 只负责前置分流或结果标记。
实用建议：先做头部硬过滤，再交由上层决策
- 对已知高危特征（如非法端口、异常 flag 组合、非业务 DSCP）直接
drop，不进用户态 - 对需深度识别的流量（如 HTTPS、gRPC），用
queue或ct mark引导至用户态或 eBPF 程序 - 利用
socketmeta（如meta skuid）或cgroupv2辅助区分进程归属，弥补头部信息不足
不复杂但容易忽略。
