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）级。
