协议手册:代理协议与内核选型技术参考

CL-01手册定位与阅读方法

先交代这份手册在站内的位置。Clash资源站 的内容按馆藏方式组织:下载中心负责按平台上架客户端安装包,教程页负责"导入订阅、选择模式、连接验证"的上手主线,选型指南负责客户端软件之间的横向对比,而本页处理的是更底一层的问题——客户端里跑的协议与内核该怎么选。多数用户被节点列表里的 ss、vmess、trojan、vless、hysteria2、tuic 这些类型标签困扰过:它们看起来只是名字不同,实际却决定了连接建立的快慢、弱网下的表现、手机的耗电水平,以及某些节点在旧内核上根本无法加载的兼容性问题。

阅读方法上,本页不要求从头读到尾。八个章节各自独立成篇:CL-02 是六种协议的"档案卡",逐一交代出身与取舍;CL-03 与 CL-04 是性能维度的横向对比,前者看速度,后者看资源与电量;CL-05 讲内核家族——原版 Clash、Clash Premium、Clash Meta 与 mihomo 之间的继承关系,这是理解"为什么有的配置在有的客户端里报错"的关键;CL-06 讲订阅格式与配置字段兼容性;CL-07 把前面所有结论收拢成按场景的选型表;CL-08 收录选型时最常见的几个误区。每章开头有一段导语,先读导语再决定是否深入。

两点写作约定需要说明。第一,本页只做技术科普与选型参考,不讨论任何网络管制相关话题,协议的对比维度限定在工程层面:握手开销、加密成本、传输层特性、生态成熟度。第二,本页不贴大段配置代码——协议参数动辄几十个字段,照抄意义不大;只在必要处给出最小示例帮助辨认字段结构,完整的配置操作请回到教程页按步骤执行。文中出现的服务器地址、密码一律为示意用的假值,不可直接使用。若某个名词在阅读中仍然陌生,可先在技术笔记里检索对应专题文章,再回到本页继续。

CL-02协议总览:六种协议的诞生背景与设计取舍

协议是客户端与服务器之间约定的"说话方式"。六种主流协议出现的年代不同、要解决的问题不同,因此没有绝对的优劣,只有取舍的差异。先用一张总表建立坐标,再逐一展开。

Shadowsocks:极简主义的起点

Shadowsocks 是六者中资历最老的一个,设计哲学是"把事情做少":客户端与服务器共享一个密码,流量用对称加密封装后直接转发,没有握手协商、没有证书体系。现代实现统一采用 AEAD 加密套件(如 aes-128-gcm、chacha20-ietf-poly1305),兼顾完整性校验与性能。极简带来两个直接好处——CPU 开销最低、实现最容易,几乎所有内核与客户端都支持;代价是协议特征长期被充分研究,单独使用时的对抗能力有限,实践中常配合 obfs、v2ray-plugin 等插件扩展传输层。作为选型基线,SS 至今仍是"老设备、低配路由器、追求省电"场景的第一候选。

VMess:传输层组合的开创者

VMess 出自 V2Ray 项目,核心贡献是把"协议本体"与"传输层"解耦:同一个 VMess 会话可以跑在裸 TCP、WebSocket、HTTP/2 等多种传输之上,再按需套一层 TLS。这种模块化设计让它在很长一段时间里是灵活性的代名词。取舍在于:协议头包含用户 ID、加密方式声明、时间戳校验等字段,每个数据包的固定开销明显高于 SS;时间戳校验还要求客户端与服务器时钟偏差在约九十秒以内,手机时间不准会直接导致握手失败——这是排查 VMess 节点"莫名超时"时第一个该检查的点。今天的 VMess 通常以 WebSocket + TLS 的组合出现,兼容性极好,但性能上限不如后来者。

Trojan:把自己藏进 HTTPS 里

Trojan 的思路与前两者相反:不发明新的加密封装,直接复用标准 TLS。客户端与服务器完成一次货真价实的 TLS 握手,流量行为与普通 HTTPS 访问几乎一致;验证失败的连接会被服务端转交给一个真实的 Web 站点,进一步降低可辨识度。这个设计让 Trojan 的实现非常薄——协议本体只有一个密码哈希加目标地址,几乎零额外开销,性能贴近裸 TLS 的理论上限。门槛在服务端:必须持有域名与有效证书,部署比 SS 复杂;客户端一侧则需要注意 sni 字段必须与服务端证书匹配,配错会报 TLS 握手错误。对客户端用户而言,Trojan 是"稳定、低开销、行为端正"的可靠选项。

VLESS:做减法的下一代框架

VLESS 是 VMess 的精简继任者,出自同一生态。它把 VMess 里被认为冗余的部分全部删掉:不再自带加密(交给外层 TLS)、不再做时间戳校验、协议头压缩到最小。本体变轻之后,安全性完全取决于搭配的传输层——常见组合是 VLESS + TLS + Vision 流控,或 VLESS + REALITY(一种无需自有证书、借用真实站点 TLS 指纹的握手方案)。设计取舍非常清晰:用"本体零加密"换取最低的封装开销,再用现代传输层补足安全。需要注意的是 VLESS 的各种流控与传输组合迭代较快,老内核往往不认识新字段,这也是它对内核版本最敏感的原因,详见 CL-05 与 CL-06 两章。

Hysteria2:为烂网络而生

Hysteria2 构建在 QUIC 之上,整个协议跑在 UDP 上,加密由 TLS 1.3 完成。它的独特之处是自带一套激进的拥塞控制:传统 TCP 遇到丢包会大幅退让,导致高丢包链路上的实际吞吐远低于带宽;Hysteria2 允许按配置的带宽持续发送,通过冗余与快速重传对抗丢包。工程结论很直接——在跨境长链路、晚高峰拥塞、无线信号差这类"高延迟高丢包"环境下,Hysteria2 的吞吐往往显著领先 TCP 系协议;而在本身通畅的网络里优势不明显,激进发包反而可能挤占同网段其他设备。它的硬性前提是 UDP 通道可用:部分运营商与公共 Wi-Fi 会对 UDP 限速或拦截,此时 Hysteria2 会整体失效,选型时必须准备一个 TCP 系协议兜底。

TUIC:QUIC 生态的轻量路线

TUIC 同样基于 QUIC,但走的是"标准化、轻量化"路线:直接复用 QUIC 的多路复用与 0-RTT 握手能力,不像 Hysteria2 那样重写拥塞控制,而是提供 BBR、Cubic 等标准算法供选择。0-RTT 意味着与曾经连接过的服务器重新建连几乎不消耗往返时间,对"频繁切换网络的手机端"格外友好;QUIC 原生的 UDP 转发能力也让它处理游戏、语音这类 UDP 流量更自然。短板在生态:TUIC 相对年轻,服务端部署面与机场支持度都不如前五者,且同样依赖 UDP 通道可用。可以把它理解为"温和版的 QUIC 方案"——想要 QUIC 的低延迟收益、又不想要 Hysteria2 的激进风格时,TUIC 是对应答案。

CL-03连接速度与吞吐:三个决定体验的环节

用户口中的"这个节点快",实际由三个环节分别决定:连接建立速度(点开一个新网站要等多久)、稳态吞吐(下载与视频能跑多满)、并发表现(网页几十个请求同时发出时是否互相阻塞)。三个环节的主导因素完全不同,分开看才能得出可靠结论。

连接建立:握手往返次数是硬账

建立一条代理连接的耗时基本等于"握手往返次数 × 链路延迟"。SS 没有握手,发出第一个数据包即完成建连,是理论最快;Trojan、VLESS + TLS、VMess + TLS 都需要一次完整 TLS 握手,TLS 1.3 下为一个往返;VMess 若再叠加 WebSocket,还要多一次 HTTP Upgrade 往返,是 TCP 系里建连最慢的组合。QUIC 阵营的 Hysteria2 与 TUIC 把传输握手与 TLS 握手合并进同一个往返,重复建连时更可借助 0-RTT 做到"首包即数据"。链路延迟越高,这笔账越显著:同样的握手差距,在延迟很低的近距离链路上几乎无感,在延迟明显的远距离链路上则会被放大数倍,表现为"点开新页面前的白屏时间"差异。

稳态吞吐:拥塞控制与加密成本

连接建立之后,长时间大流量传输(下载、高清视频)的瓶颈转移到拥塞控制与加密开销。通畅链路上,六种协议的稳态吞吐差距不大,都能接近链路带宽,此时反而是加密成本决定上限——SS 与 Trojan 封装最薄,VMess 的逐包头部开销让它在小包密集的场景(如大量图片的页面)略吃亏。一旦链路出现持续丢包,格局立刻改变:TCP 系协议(SS/VMess/Trojan/VLESS over TCP)受制于内核 TCP 的退让策略,吞吐随丢包率上升而陡降;Hysteria2 凭自定义拥塞控制在同等丢包下仍能维持接近配置带宽的吞吐,TUIC 选用 BBR 时也明显好于传统 TCP。这就是"晚高峰 QUIC 系协议体感更好"的技术根源。

并发与队头阻塞

现代网页动辄同时发起数十个请求。跑在单条 TCP 连接上的多路复用(如 VMess 的 mux)存在队头阻塞问题:一个丢包会卡住整条连接上所有请求。QUIC 在传输层原生解决了这一点,每个流独立重传,互不拖累——Hysteria2 与 TUIC 因此在"网页大量小请求并发"的场景下体感更流畅。TCP 系协议的应对方式是干脆不用多路复用,让内核为每个请求单独建连,配合连接复用池也能获得不错的并发表现,代价是建连开销更频繁。实际测试时建议区分场景:用大文件下载测吞吐,用图片墙类网页测并发,用新域名首次访问测建连,单一的延迟数字(ping 值)只能反映链路距离,与三者都不等价——这个误区在 CL-08 还会展开。

CL-04资源占用与移动端电量表现

桌面端用户很少关心代理内核吃多少 CPU,手机用户则每天都在为电量精打细算。这一章把"资源占用"拆成加密计算、协议栈位置、无线电唤醒三个因素,并给出移动端的实操建议。

加密计算:硬件加速是分水岭

对称加密是代理流量的固定成本。近十年的手机与电脑 CPU 普遍内置 AES 指令集,aes-128-gcm 这类套件的加解密几乎不占用可感知的 CPU;没有硬件加速的老设备(部分低端路由器、老款电视盒子)则应选 chacha20-ietf-poly1305,它为纯软件实现优化,同等安全强度下速度可达软件 AES 的数倍。协议层面,SS 与 Trojan 只有一层加密,计算成本最低;VMess 自带加密再叠加外层 TLS 时存在双重加密,是六者中单位流量 CPU 成本最高的组合;VLESS 本体不加密的设计正是为了消掉这层冗余。在路由器上跑 mihomo 内核时,这笔账直接决定设备能不能跑满带宽。

QUIC 的用户态成本

TCP 协议栈在操作系统内核里运行,经过几十年优化;QUIC 目前主要在用户态实现,同等流量下 CPU 占用普遍高于 TCP 系协议,内存占用也略高。桌面端这点差异无关痛痒,但在手机上,持续大流量走 Hysteria2/TUIC 时的发热与耗电会比 SS/Trojan 明显一档。结论不是"手机别用 QUIC",而是"QUIC 的收益要花在刀刃上":网络差的时候它带来的体验提升远超电量代价,网络好的时候则不必为用不上的抗丢包能力付电费——支持自动切换策略组的客户端里,可以把 QUIC 节点与 TCP 节点混编,让规则按需选择。

无线电唤醒与心跳:移动端耗电的大头

手机耗电的真正大头往往不是计算,而是蜂窝/Wi-Fi 模块被反复从休眠中唤醒。长连接协议若维持频繁心跳,哪怕每次只发几十字节,也会阻止无线电进入深度休眠。这方面 QUIC 系有一个常被忽略的优势:连接迁移。手机在 Wi-Fi 与蜂窝之间切换时,TCP 连接必须断开重建(触发一轮完整握手与流量重传),QUIC 连接可以原地迁移到新网络继续使用——通勤场景下频繁的重连正是耗电与卡顿的来源之一。实操建议:移动端优先选择 Android 平台的 Clash Plus 或 FlClash 这类基于 mihomo 内核的客户端,按需开关 TUN 模式(虚拟网卡全程接管会带来额外的常驻开销,原理见技术笔记中的 TUN 模式详解);策略组的自动测速间隔不要设得过密,几百毫秒一轮的健康检查在手机上就是标准的电量杀手。

CL-05内核家族:原版 Clash、Meta 与 mihomo 的关系

"内核"是客户端界面之下真正处理流量的引擎。市面上所有 Clash 系客户端共享同一套配置语法,但引擎有代际之分——不理解这层关系,就无法解释"同一份订阅在 A 客户端能用、在 B 客户端报错"的现象。

三代内核的继承链

原版 Clash 内核确立了这套生态的全部基础:YAML 配置、代理组(策略组)、基于规则的分流。它支持的协议以 SS、VMess、Trojan、Socks5、HTTP 为主。原作者随后维护过闭源的 Premium 版本,补充了 TUN 模式与规则集(rule providers)等进阶能力。在原版仓库停止更新后,社区分支 Clash Meta 接过主线,大幅扩展协议支持并保持活跃开发;此后 Meta 项目更名为 mihomo——今天说 Clash Meta 内核与 mihomo,指的是同一个项目的同一条主线。理解这条继承链后,选型规则可以浓缩成一句话:配置语法向前兼容,协议支持只增不减,新协议一律认准 mihomo。

功能差异对照

客户端与内核的对应关系

客户端只是内核的图形外壳,选客户端本质上是在选内核。本站下载中心上架的活跃客户端——Clash Plus(全平台首推)、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android——均基于 mihomo 内核,六种协议全部可用;归档区的 Clash for Windows 与 ClashX Meta 已停止维护,前者搭载的原版/Premium 内核无法加载 VLESS、Hysteria2、TUIC 节点,订阅里含这些协议时会直接报"unsupported proxy type"或整份配置加载失败。这正是"寻找 Clash for Windows 替代"成为高频检索词的原因:不是旧软件坏了,是协议生态往前走了。各客户端的界面与功能差异,另见选型指南的逐项对比;服务器与路由器用户可直接在下载中心获取 mihomo 内核裸二进制,不经图形界面运行。

CL-06订阅格式与配置文件兼容性

协议与内核之外,第三个常见的翻车点是订阅格式。同一批节点可以被打包成多种格式分发,客户端能不能吃下这份订阅、吃下之后字段会不会丢,都有明确的规律可循。

三类主流分发格式

目前流通的订阅大体分三类。第一类是 Clash YAML 完整配置:一份包含 proxies、proxy-groups、rules 的完整 YAML 文件,Clash 系客户端可直接导入,信息保留最完整,是本站教程默认采用的格式。第二类是 Base64 分享链接合集:把 ss://、vmess://、trojan:// 等单节点 URI 编码后按行拼接,通用性最好,但只携带节点连接参数,不含任何分流规则与策略组,导入 Clash 系客户端前需要经过转换。第三类是 sing-box JSON 等其他生态的格式,Clash 系客户端不直接兼容,需要转换服务翻译。判断手里订阅属于哪一类,把订阅链接在浏览器里打开看返回内容即可:YAML 有清晰的缩进结构,Base64 是一大段无空格的字母数字。

字段兼容:同一份 YAML 的代际差异

Clash YAML 语法整体向前兼容,但 mihomo 扩展的字段在原版内核上会被拒绝或忽略,典型的有:新协议的 type 值(vless、hysteria2、tuic)、rule-providers 规则集、sniffer 嗅探段、GEOSITE 类规则,以及 VLESS 相关的 flow、reality-opts 等传输字段。反方向没有问题——为原版内核写的老配置,mihomo 可以原样加载。识别一个节点条目的协议类型,看 type 字段即可,以下是一个最小示意(参数均为假值,仅用于辨认结构):

proxies:
  - name: "示例-Hysteria2"
    type: hysteria2
    server: hy2.example.com
    port: 443
    password: "your-password"
    sni: hy2.example.com

  - name: "示例-Shadowsocks"
    type: ss
    server: ss.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

订阅转换与多配置管理

当格式与客户端不匹配时,就轮到"Clash 订阅转换"登场:转换服务读取原始订阅,输出目标格式,并可在转换时套用远程模板补全策略组与分流规则。使用转换服务要注意两点——订阅链接会经手第三方服务,对隐私敏感的用户应优先要求订阅提供方直接给出 Clash YAML 格式;转换模板决定了最终的策略组结构,模板过于复杂会拖慢配置加载,选简洁模板为宜。多份订阅并存时的命名、更新与切换策略,技术笔记的 Profile 基础概念一文有专门整理;具体到某个客户端的导入按钮在哪、更新间隔怎么设,回教程页按平台小节操作即可,此处不重复展开。

CL-07按使用场景的选型建议

前六章的结论在这里收拢。选型的正确顺序是:先确认内核(mihomo 系客户端,协议全兼容),再按自己的主场景挑协议,最后留一个不同传输层的协议兜底。以下按五个典型场景给出参考结论。

桌面日常办公与网页浏览

链路质量通常稳定,建连速度与并发体验比极限吞吐更重要。首选 Trojan 或 VLESS + TLS:一层加密、开销薄、行为稳定,TLS 1.3 单往返握手让新页面打开干脆利落。SS 同样完全够用,且在任何客户端上零门槛。策略组建议把同协议的多个节点编入 url-test 自动选择组,健康检查间隔设在几分钟一档即可——桌面端不心疼这点后台流量,但过密的检查同样会给节点侧带来无谓压力。客户端按下载中心 Windows 区的顺序选择,首推 Clash Plus。

移动端通勤与省电优先

手机场景的两个关键词是网络切换与电量。协议上建议 TUIC 或 Trojan 二选一:TUIC 的 0-RTT 与连接迁移特性专治"出电梯瞬间的断流重连",Trojan 则胜在单位流量能耗最低。VMess 在手机上是相对最不划算的选择——双重加密费电,时间戳校验又容易被手机的时钟漂移触发握手失败。配合 CL-04 的省电检查单调整客户端设置,Android 用户从下载中心 Android 区获取 Clash Plus 或 FlClash,iOS 用户按下载页 iOS 区指引经 App Store 安装 Clash Plus。

弱网、高丢包与晚高峰

判断标准:延迟波动大、下载速率远低于带宽、视频反复缓冲。这是 Hysteria2 的主场——自定义拥塞控制在高丢包链路上的吞吐优势在 CL-03 已经解释过,体感差距通常是"能不能流畅看高清"级别的。两个前提务必确认:所在网络的 UDP 通道未被限速(公共 Wi-Fi 与部分移动网络常见此问题),以及节点侧配置的带宽参数与实际线路相符——带宽值虚高会导致大量无效重传,反而更慢。兜底方案必备:同一策略组里放一个 Trojan 或 SS 节点,UDP 不通时手动或按规则切换。

游戏、实时语音与低延迟需求

实时类应用的痛点是 UDP 流量转发与延迟抖动。优先 TUIC:QUIC 原生的 UDP 转发路径干净,标准拥塞控制不会像 Hysteria2 那样为吞吐牺牲平滑度,更适合稳定的小包流。次选 Hysteria2。TCP 系协议转发 UDP 需要额外封装,延迟与抖动都会增加一档,能避则避。此外注意分流规则:游戏流量建议按进程或目标网段直接指定固定节点,不要交给自动测速组——测速切换瞬间的连接迁移对下载无感,对正在进行的对局则是掉线。规则写法可在教程页的规则小节找到入口。

老设备、路由器与常驻服务

树莓派、软路由、NAS 这类设备的约束是 CPU 与内存。协议选 SS(无硬件 AES 时配 chacha20 套件)或 Trojan,避开 QUIC 系的用户态开销与 VMess 的双重加密;内核直接用 mihomo 裸二进制,按设备架构选择 AMD64/ARM64/ARMv7/MIPS 版本,不跑图形界面。常驻服务还要控制配置复杂度:上千条规则与几十个策略组会显著推高内存占用,路由器上建议用精简规则集,把复杂分流留给桌面端。

CL-08选型常见误区与检索入口

最后一章收录咨询频率最高的几个认知误区,并给出站内的后续检索路径。这些误区共同的特点是:结论听起来顺理成章,推导过程却缺了关键一环。

误区一:协议越新越好

协议的"新"解决的是特定场景的特定问题,不是全面升级。VLESS 相对 VMess 是明确的减法优化,但 Hysteria2 与 TUIC 相对 Trojan 并非代际碾压——通畅网络下三者体感几乎无差,QUIC 系反而多付出用户态 CPU 与 UDP 可用性两笔成本。正确做法是按 CL-07 的场景对号入座,而不是无条件追新。同理,"某协议已过时"的说法也要打折扣:SS 诞生最早,却仍是低配设备场景无可替代的最优解。

误区二:延迟数字等于体验

客户端里的延迟测试(如对测试 URL 的 HTTP 请求耗时)只反映"此刻到该节点走一趟有多快",与吞吐、丢包率、并发表现都不是一回事。一个延迟数字漂亮的节点可能带宽极小,高峰期丢包严重的节点在深夜测试时也可能数字很好看。选节点应结合时段多测几轮,大流量场景再补一次实际下载测试;节点全部超时时也别急着换订阅,按技术笔记的排查顺序从本机网络查起,多数问题出在离自己最近的一环。

误区三:加密层数越多越安全

VMess over TLS 的双重加密是历史包袱,不是安全增益——内层加密在外层 TLS 已经建立的前提下不提供额外的保密性,只消耗 CPU。VLESS 把本体加密删掉、完全信任 TLS 1.3,安全强度并无损失,这正是现代协议设计的共识:一层可靠的加密胜过多层重复的加密。评估安全性应看加密套件与实现质量,而不是数层数。

误区四:内核版本盲目追新或死守旧版

两个方向的极端都有代价。死守停更内核的问题在 CL-05 已经说透——新协议一概无法使用;而内核大版本更新偶尔伴随配置字段的调整,盲目第一时间升级可能遇到旧配置需要小改的情况。稳妥节奏是:保持客户端在活跃维护的版本线上(下载中心的推荐排序即以此为准),大版本更新后先在一份备份配置上验证,再切换日常使用。配置文件的备份与多 Profile 管理方法,见 CL-06 章末给出的笔记链接。

下一步去哪里

读完本手册,站内的后续路径按需取用:动手安装从下载中心按平台取件;第一次配置走教程页的三步主线;客户端软件之间犹豫不决,查选型指南的横向对比;TUN 模式、DNS 泄漏、macOS 权限这类专题问题,到技术笔记按标签检索。本页随协议生态演进不定期修订,编目信息以页首馆藏卡为准。