nftables 不支持 ingress hook，也无硬件级丢包能力；其最早可干预点是 prerouting 链，延迟在微秒级，真正硬件加速需依赖网卡厂商 SDK 或 DPDK/AF_XDP 绕过内核。

不能在 ingress 链执行“秒级硬件级丢包”——nftables 本身不支持 ingress hook，也没有硬件级丢包能力。

ingress 链根本不存在于 nftables

nftables 的 hook 点由内核 netfilter 框架定义，标准 hook 包括：prerouting、input、forward、output、postrouting。所谓 “ingress” 是早期 tc（traffic control）中用于入口流量整形的术语，它运行在内核网络栈更早的位置（dev_queue_xmit 之前），但不是 netfilter 的处理阶段，也不属于 nftables 可挂载规则的范围。

你可能混淆了以下两个机制：

• tc + clsact + bpf：可在 ingress 方向用 eBPF 程序做极低延迟过滤（接近硬件级），但这是流量控制子系统，和防火墙无关；
• nftables 的 prerouting：是数据包进入路由决策前的第一个 netfilter hook，已是软件协议栈最早可干预点，延迟在微秒级，非“硬件级”。

真正能实现快速丢包的推荐方式

若目标是“尽早丢弃恶意或无效包以节省 CPU 和带宽”，应聚焦在 prerouting 链 + 精准匹配 + ct state invalid drop：

• 添加兜底规则：nft add rule inet filter prerouting ct state invalid drop，在路由前就终止非法连接状态包；
• 配合快速匹配项，如源 IP 黑名单：nft add rule inet filter prerouting ip saddr @blacklist drop（需先定义 ipset）；
• 避免在 input 链才丢包——那意味着已完成路由、本地送达判断、甚至部分协议栈处理，开销已产生。

硬件加速不是 nftables 负责的事

真正的“硬件级丢包”依赖网卡厂商支持（如 Intel Flow Director、NVIDIA ASAP2、Marvell DPU），需通过：

• DPDK 或 AF_XDP 应用绕过内核协议栈；
• 厂商 SDK 编程写入硬件流表（flow table）；
• nftables 完全不参与此类路径，也无对应接口。

别被“秒级”误导，实际延迟看位置

各环节典型处理延迟（参考主流 x86 服务器）：

• 网卡 DMA 收包 → 内核 softirq 处理：~5–20 μs；
• prerouting hook 规则匹配（简单匹配）：~0.1–1 μs；
• input hook 同样规则：+3–8 μs（因已做路由查表、本地交付判断等）；
• 用户态工具（如 tc + bpf）在 ingress 方向：可压到 ~0.5 μs，但仍属软件路径。

所谓“秒级”是数量级误用——真实优化目标是微秒（μs）级，而非秒（s）级。