Leaf 代理框架是什么？面向开发者的多协议框架

Leaf 代理框架的身份

Leaf 是开发者 eycorsican 维护的开源项目，官方仓库的描述是「一个通用而高效的代理框架」。注意这里用的词是框架，而不是客户端。它提供的是一套可以处理多种代理协议、多种传输方式与透明代理机制的底层能力，既可以编译成命令行程序直接运行，也可以作为库嵌入到其他应用里。

这和站内大多数客户端页面介绍的对象不太一样。像 Clash Verge Rev、v2rayN 这类软件，是给最终用户点按钮用的；而 Leaf 更接近 sing-box、Xray-core、mihomo 这一层，属于「内核」或「引擎」。区别在于，Leaf 的知名度和第三方图形外壳的数量都比那几个内核小得多，资料也相对少。

核对信息表

下表内容来自官方仓库 README、Releases 页面与 GitHub API。没有在官方渠道看到的字段写「未能核实」。

字段	核对结果	来源
官方仓库	eycorsican/leaf	https://github.com/eycorsican/leaf
最新版本	v0.14.2	GitHub API /releases/latest
发布日期	2026-02-25（UTC）	GitHub API published_at
最近推送	2026-09-30	GitHub API pushed_at
平台（发布资产）	macOS（aarch64、x86_64）、Linux musl（aarch64、x86_64）、Windows x86_64，另有 Android 库压缩包与苹果平台的 xcframework	Releases 资产列表
实现语言	Rust（README 的构建说明使用 cargo）	README Building
内核	自身即为代理框架，不依赖 Xray、sing-box 等其他内核	README
界面	命令行程序与开发库，无官方图形界面	README 与发布资产
许可证	Apache-2.0	README License 与 GitHub API
是否归档	否（archived 为 false）	GitHub API
订阅导入	未能核实	—
配置文件格式细节	未能核实（本页未在 README 首页看到完整说明）	—
价格	未能核实（官方页面没有标注）	—

表中的平台一栏，只根据最新发布附带的文件名整理。文件名里出现某个平台，说明作者为它提供了预编译文件；没有出现的平台，不代表一定不能编译运行，只是官方没有提供现成文件。

README 列出的 Leaf 框架能力

Leaf 的 README 用了几张表格来说明它支持什么，信息相当集中，这里按类别转述。

代理协议方面，表格列出了六种：HTTP 只有入站；SOCKS5、Shadowsocks、Trojan 入站和出站都支持；VMess 与 VLESS 只支持出站。也就是说，如果你想用 Leaf 搭一个 VMess 服务端，README 的表格并不支持这种用法。

传输与安全层方面，列有 WebSocket、TLS、QUIC，以及一个名为 AMux 的多路复用方案，README 注明它是 Leaf 自有的设计。另外还有只支持出站的简单混淆 Obfs、只支持出站的 REALITY，以及一个叫 MPTP 的多路径传输协议，用于链路聚合，仓库里另有架构和用法文档。

流量控制方面，支持代理链，也支持带健康检查的故障转移，后者只在出站一侧。

透明代理方面，TUN 入站被标为支持 Linux、macOS、Windows、iOS、Android 五个平台；Windows 上另有一种基于 NetFilter SDK 的方式；Linux 上的 TPROXY 则被标为「即将推出」，目前不可用。

这些表格本身就说明了 Leaf 的定位：它关心的是协议组合、传输方式和流量调度这些底层问题，而不是订阅管理或界面交互。

为什么普通用户不该直接拿 Leaf 框架当客户端

第一个原因是没有图形界面。发布资产里的命令行程序需要配合配置文件运行，启动、停止、切换节点都要靠命令或者自己写脚本。对只想「导入订阅、点连接」的用户来说，这条路太绕。

第二个原因是订阅处理未能核实。本页没有在官方 README 中找到订阅导入的说明。机场下发的订阅通常需要客户端定期拉取、解析、更新节点，这些工作在 Leaf 这一层是否提供、以什么方式提供，需要你自己阅读仓库文档后判断。

第三个原因是协议覆盖有边界。README 的表格里没有 Hysteria、TUIC 等协议。如果你的服务商主要提供这些协议，Leaf 并不合适。协议之间的区别可以参考 协议总览。

第四个原因是资料相对少。遇到问题时，你很难像使用主流内核那样，在大量中文教程里找到答案，更多时候要靠阅读源码、文档和议题。

适合哪些人

Leaf 适合下面几类读者：

• 想在自己的应用里嵌入代理能力的开发者，尤其是需要同时面向 Android 和苹果平台的项目。发布资产中专门提供了 Android 库和 xcframework，这是 Leaf 很有特色的一点。
• 对 Rust 生态感兴趣、希望研究一套代理协议实现的人。
• 需要链路聚合、故障转移等较少见能力，并且愿意自己写配置的进阶用户。

如果你属于这几类，建议直接从官方仓库开始，先读 README 和仓库中的文档目录，再看近期的发布说明。从源码构建的命令 README 里已经给出，这里不再重复。

开发者接入前的检查清单

如果你打算把 Leaf 作为依赖引入自己的项目，下面几项值得在动手前逐一确认，而不是等到上线后才发现问题。

一是协议覆盖是否满足需求。把你需要支持的协议、传输方式逐项和 README 表格对照，特别留意哪些只支持入站、哪些只支持出站。表格中被标为「即将推出」的能力，不要提前写进产品规划。

二是目标平台是否有现成产物。最新发布里提供了 Android 库和苹果平台的 xcframework，这能省下不少交叉编译的工作；但如果你的目标是其他架构，例如某些路由器芯片，就需要自己尝试编译，并预留排障时间。

三是许可证义务。Apache-2.0 允许商业使用和修改，但要求保留版权声明与许可证文本，修改过的文件要有说明。发布产品前，请让熟悉开源许可的人再看一遍。

四是版本升级策略。框架升级可能带来配置结构或接口的变化。建议在项目中固定使用某个具体版本，升级前先阅读发布说明，并在测试环境里跑通再推送给用户。

五是上游活跃度。可以定期查看仓库的提交、发布与议题处理情况，评估它能否长期满足你的维护需要。

框架、内核与客户端的三层关系

很多人在选软件时容易把三个层次混在一起。最底层是协议实现，也就是把 Shadowsocks、Trojan、VLESS 这些协议写成代码；中间一层是把协议实现组织起来、加上路由和调度的框架或内核，Leaf、sing-box、Xray 都在这一层；最上层是图形客户端，负责订阅、界面和系统设置。Leaf 主要站在中间这一层，同时又以库的形式向上层应用开放。弄清这一点，你就不会拿它和手机上的成品应用直接比较了。

下载与来源安全

Leaf 的官方发布只在 GitHub 仓库的 Releases 页面。网络上也能看到一些以 Leaf 为底层的应用，或者名字相近的分支仓库，它们与原作者的关系需要你逐一确认。分支项目可能落后于上游，也可能做了未经说明的改动。下载时请认准官方仓库地址，核对版本号与文件名，具体方法可以参考 下载安全指南。

另外，Leaf 的命令行程序在 Windows 上使用 TUN 方式时，通常需要较高的系统权限来创建虚拟网卡。对任何需要这种权限的程序，来源可靠都应当是第一位的考虑。关于 TUN 模式的原理和风险，可以读站内的 TUN 模式说明。

普通用户可以看什么

如果你读到这里，发现 Leaf 并不是你要找的东西，可以按设备选择站内其他页面：

• Windows 用户可以先看 Windows 客户端指南，再根据订阅格式选择 Clash Verge Rev 或 v2rayN。
• 想了解主流内核的，可以看 sing-box、mihomo 与 Xray-core 三个页面。
• 想先弄清订阅是什么、能导入到哪里的，可以读 订阅链接说明。

完整的客户端列表见 客户端总览。

维护状态的判断

从官方数据看，Leaf 仍处在维护中：最新发布是 2026 年 2 月的 v0.14.2，此后仓库在 2026 年 9 月底仍有推送，仓库也没有归档。不过，发布间隔和提交频率都会变化，本页记录的只是 2026 年 10 月 22 日核对时的情况。准备在项目中长期依赖它之前，建议再看一眼仓库的最新动态和未关闭的议题。

小结

Leaf 是一个以 Rust 编写、以 Apache-2.0 许可发布的代理框架，核对时最新版本为 v0.14.2，发布于 2026-02-25，仓库未归档。它支持多种代理协议与传输方式，提供命令行程序和面向移动平台的开发库，但没有官方图形界面，订阅导入能力未能核实。它更适合开发者和进阶用户，普通用户建议选择站内的图形客户端。