eBPF 做透明代理，下一代 Clash 长这样？

dae 和 daed 的作者团队交出了一个新答案：honk，一个用 Rust 写的 Linux 透明代理引擎，实验性质，README 原话是「follows the design of dae's eBPF datapath and configuration syntax, and of sing-box's outbound groups and Clash API」。它继承 dae 的 eBPF 数据面和配置语法，借鉴 sing-box 的出站分组和 Clash API，独立实现而非两者移植。仓库 7 月 20 日创建，约三个半月，1,349 星、110 fork，GPL-3.0-only，当前版本 v0.1.0-beta.4。README 醒目位置写着：Early alpha, not recommended for production。

一、核心差异：direct 流量不进用户态

honk 的 eBPF 程序挂在 TC hook 上，在内核里完成流量分类与分流。direct 流量走「Real Direct」路径，永远不进用户态；只有需要代理的流量才上送到用户态进程。这是它和 Clash、mihomo 这类 TUN 方案的根本区别：TUN 把所有流量先收进用户态再转发，direct 流量也要付一次用户态的税；honk 里这笔税直接免了。eBPF 部分用 aya-rs 框架写成，整个项目贯彻 Rust。

二、协议面和分组面补齐了「Clash 习惯」

出站协议覆盖 SOCKS5、Shadowsocks 与 Shadowsocks 2022、Trojan、AnyTLS、Hysteria2、TUIC、Juicity、VMess、VLESS，外加 direct 和 block。分组支持 Selector、URLTest、LoadBalance、Fallback 和 Score。最后这个是新玩法：不只测延迟，而是结合业务观测加有界验证来做节点优选。DNS 支持 DoT、DoH、DoQ、DoH3；配置沿用 dae 语法、支持热重载，对外暴露 Clash 兼容的 REST API。一句话概括：honk 赌的是「内核分流的性能」和「Clash 生态的使用习惯」可以兼得。

三、冷水：五条都得泼

一，Early alpha 是认真的：没有 FakeIP 引擎、没有 inbound 支持、离 mihomo 的完整对等还远，别拿生产流量试。二，没有任何独立性能数据，「下一代 Clash」目前只是架构叙事，账面上的近零损耗要等实测说话。三，要求 Linux 6.12 以上内核，老机器、旧发行版和大部分路由器直接出局。四，和 dae 不能共存（同一个 dae0 接口），从 dae 迁移是二选一，不是平滑升级。五，Rust 重写不等于自动更好，dae 积累的面板、文档和社区踩坑经验，honk 都要重走一遍。

四、判断

正确的围观姿势是「关注、别换」：architecture 上它是透明代理的正确进化方向：分流下沉到内核，direct 流量近零损耗，这个思路对 TUN 方案是结构性优势；Score 分组用业务观测代替纯延迟测试也是节点优选的正确打开方式。但 alpha 就是 alpha，等它长出 FakeIP 和 inbound、等第一批独立实测，再决定要不要把 dae 换下来。

来源：github.com/daeuniverse/honk（第一手，2026-11-04 直读）；daeuniverse.org/honk 文档；TG 原帖 t.me/zhetengsha/7383。