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

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

Clash 生态里常见的六种协议,可以按诞生顺序排成一条演化线:Shadowsocks 最早,VMess 与 Trojan 属于中间一代,VLESS、Hysteria2 与 TUIC 是较新的方向。每一代都在回应上一代暴露出的问题,因此没有"全面胜出"的协议,只有取舍不同的协议。

Shadowsocks:极简对称加密

Shadowsocks(常缩写为 SS)的设计目标是最小化:客户端与服务端约定同一套密码与加密方法,数据经 AEAD 对称加密后直接传输,没有握手协商,没有额外的认证往返。这带来两个直接好处——实现简单、连接建立快;代价是协议本身不提供伪装层,扩展能力依赖 SIP003 插件体系(如 obfs、v2ray-plugin)来补齐。加密方法上,aes-128-gcm 与 chacha20-ietf-poly1305 是目前的主流选择,前者在带硬件加速的 x86 设备上更快,后者在多数手机的 ARM 芯片上表现更好。

VMess 与 Trojan:两条相反的路线

VMess 来自 V2Ray 项目,走"功能全"路线:基于用户 UUID 做动态认证,支持多种传输层(TCP、WebSocket、gRPC 等)自由组合,元数据里携带较多控制信息。取舍是协议头开销偏大,且认证依赖客户端与服务端的系统时间大致同步——时间偏差过大时会直接连接失败,这也是排查 VMess 节点异常时首先要检查的一点。Trojan 走的是相反路线:不自造加密,直接复用标准 TLS,让流量在外观上与访问普通 HTTPS 网站一致。代价由服务端承担——部署需要域名与有效证书,对使用者而言几乎无感,配置字段也最少。

VLESS、Hysteria2 与 TUIC:新一代的减法与换道

VLESS 是对 VMess 的减法:去掉协议自身的加密与时间认证,把安全性完全交给外层 TLS(以及 REALITY 等扩展),协议头压到最薄,转发开销显著低于 VMess。Hysteria2 与 TUIC 则是换道:放弃 TCP,改用基于 UDP 的 QUIC 作为底座。Hysteria2 的特色是自带激进的拥塞控制策略,在高丢包、高延迟的弱网线路上仍能维持吞吐;TUIC 的重点是握手效率,利用 QUIC 的 0-RTT 特性把连接建立压到极短,并对 UDP 转发提供原生支持。这三者在 Clash 生态中都只有 mihomo 系内核支持,这一点在第 E 章展开。

B传输层差异:TCP 系与 QUIC 系的分水岭

六种协议真正的分水岭不在加密方式,而在传输层:SS、VMess、Trojan、VLESS 属于 TCP 系,Hysteria2 与 TUIC 属于 QUIC 系。理解这条分界,比记住每个协议的字段更有用,因为它直接决定了协议在不同网络环境下的行为差异。

TCP 系:成熟、保守、路径友好

TCP 系协议的最大优势是"路径友好":TCP 是互联网上最成熟的传输协议,途经的路由器、防火墙、运营商 QoS 设备都对它有完善的处理逻辑,极少出现整类流量被限速或丢弃的情况。Trojan 与 VLESS 叠加 TLS 之后,流量特征与普通网页访问一致,兼容性最好。代价有两个:一是握手轮次多——TCP 三次握手叠加 TLS 握手,连接建立至少需要两到三个往返,物理距离越远的节点首包等待越明显;二是队头阻塞——TCP 保证字节流严格有序,一个数据包丢失会阻塞其后所有数据,即使后面的数据属于不相关的请求。在丢包率高的线路上,这会把偶发丢包放大成整体卡顿。

QUIC 系:少握手、抗丢包、但依赖 UDP 待遇

QUIC 在 UDP 之上重新实现了可靠传输,并把 TLS 1.3 握手合并进连接建立过程,新连接通常一个往返即可完成,重连场景下 0-RTT 甚至可以随首包携带数据。QUIC 的流(stream)之间相互独立,单个包丢失只影响所属的流,不会阻塞其他请求,这是它在弱网下体验更好的结构性原因。QUIC 还支持连接迁移:设备从 Wi-Fi 切换到蜂窝网络时,连接可以延续而不必重建,对移动设备价值明显。它的软肋同样来自 UDP:部分运营商与企业网络会对 UDP 流量做限速或低优先级处理,遇到这种线路时,QUIC 系协议的表现可能反而不如一条普通的 TLS-over-TCP 连接。因此"Hysteria2 一定比 Trojan 快"这类结论不成立——快不快取决于这条路径如何对待 UDP。

多路复用的位置差异

TCP 系协议可以通过 mux 配置把多个请求复用进一条连接,减少握手次数,但复用会把队头阻塞的影响面同步放大,通常只建议在高延迟线路上按需开启。QUIC 系协议的多路复用是原生的,不需要额外配置,也不引入跨请求的阻塞,这一点是传输层设计带来的天然差异,不是参数调优能抹平的。

C连接速度与资源占用:定性对比

协议性能没有普适的数字可引用——同一协议在不同线路、不同设备上的表现差距远大于协议之间的差距。因此本章只做定性对比,给出"其他条件相同"前提下的相对排序,以及资源占用的结构性差异。

连接建立速度

影响"点开一个新网站要等多久"的核心变量是建连往返次数。按握手轮次从少到多排列:TUIC 与 Hysteria2(QUIC,一个往返,重连可 0-RTT)最快;SS 次之(无协议握手,只有 TCP 三次握手);Trojan 与 VLESS 需要 TCP 加 TLS 两层握手;VMess 因协议头与认证开销,通常在同类里建连最慢。注意这个排序只影响新连接的首包时间,连接建立之后的持续传输速度与它无关。浏览网页这类频繁建立短连接的场景对建连速度最敏感,看视频、下载大文件这类长连接场景则几乎无感。

吞吐与 CPU 开销

持续吞吐的瓶颈通常在线路本身,协议差异主要体现在 CPU 占用上。加密运算是大头:x86 设备普遍带 AES 硬件加速指令,跑 aes-128-gcm 几乎不占 CPU;多数 ARM 移动芯片上 chacha20-ietf-poly1305 反而更高效。VLESS 因为协议自身不做加密(只有外层 TLS 一层),在同等吞吐下 CPU 占用最低,这也是它被用于高流量转发场景的原因。QUIC 系协议的加密收发目前多在用户态完成,缺少操作系统对 TCP 的成熟优化,在跑满带宽的极限场景下 CPU 占用会明显高于 TCP 系——桌面设备无感,低功耗设备需要留意。

内存与低配设备

内存占用主要由内核与规则数据决定,协议本身的差异很小。真正吃内存的是 GEO 数据库与大体积规则集,在软路由、旧手机这类内存有限的设备上,精简规则文件比更换协议更能降低占用。如果设备是只有少量内存的路由器,建议优先选 SS 或 Trojan 这类实现简单的协议,并使用Mihomo 内核的精简配置,而不是在低配设备上追求 QUIC 系协议的新特性。并发连接数多的场景(如网页多开、P2P)下,每条 TCP 连接都有独立的系统开销,开启 mux 或改用原生多路复用的 QUIC 系协议可以减少连接总数,这是资源层面选择协议的另一个考虑点。

D移动端电量表现:协议之外还有客户端行为

手机上的耗电问题经常被归咎于协议,实际上电量消耗由三层因素叠加:协议的保活行为、客户端的后台策略、系统对 VPN 服务的调度。只换协议不调整客户端行为,省电效果通常有限。

无线电唤醒:移动端耗电的真正大头

蜂窝网络下,手机的基带芯片在无数据传输时会进入低功耗状态,任何一个数据包都会把它唤醒并维持一段高功耗窗口。因此耗电的关键不是传输了多少数据,而是唤醒了多少次。协议层面的保活心跳、客户端的定时延迟测试、策略组的自动测速,每一项都在制造周期性唤醒。QUIC 系协议的连接迁移特性在这里有实际价值:Wi-Fi 与蜂窝切换时连接直接延续,省掉了重建连接的握手与随之而来的一串唤醒;TCP 系协议在网络切换时所有连接作废重建,切换频繁的通勤场景下差距会累积。

客户端侧的可调项

比协议选择影响更大的是客户端设置。第一,策略组的自动测速间隔:url-test 类型的组默认会周期性地对组内所有节点发起测试,间隔设得太短等于让手机每隔几分钟唤醒一次并批量建连,移动设备上建议把 interval 放宽,或对不常用的组改用手动选择。第二,TUN 模式与系统代理的差异:TUN 模式接管全部流量,处理路径更长,待机功耗略高于仅代理浏览器流量的系统代理模式;不需要接管全局流量时,移动端用系统代理模式更省电。第三,规则数量:每个新连接都要过一遍规则匹配,规则集越大匹配开销越高,移动端配置应避免堆叠大量用不到的规则集。

iOS 的特殊约束

iOS 上代理客户端运行在 Network Extension 框架内,系统对这个扩展进程的内存限制相当严格,超限会被直接终止——表现为代理无故断开。因此 iOS 客户端要格外控制规则与 GEO 数据的体积,协议上也宜选择实现较轻的类型。Clash Plus 在 iOS 上通过 App Store 分发,针对这一约束做了内存控制,是 iOS 平台的首选项;安装入口见下载页 iOS 分区。安卓平台则要留意系统的电池优化白名单:客户端被系统冻结后,VPN 服务重启同样会带来一轮重连耗电,加入白名单比调整协议更能改善续航。

E内核家族:原版、Premium、Meta 与 mihomo 的关系

"Clash"这个词在不同语境下指代不同的东西:有时指内核(在后台处理流量的命令行程序),有时指客户端(带图形界面的应用)。客户端只是内核的外壳,协议支持、规则能力、TUN 实现全部由内核决定。弄清内核家族关系,是理解"为什么这个节点在 A 客户端能用、在 B 客户端报错"的前提。

三代内核的演化线

原版 Clash 内核是这一切的起点,确立了 proxies、proxy-groups、rules 三段式配置结构,支持 SS、VMess、Trojan 等基础协议;其上游仓库已经归档,不再更新。Premium 是原版作者维护的闭源增强版,补充了 TUN 模式与规则提供者(rule providers)等能力,同样已随原版一起停止演进。Clash Meta 是社区在原版基础上的延续分支,后更名为 mihomo——两个名字指同一条演化线,现在的正式名称是 mihomo。它在保持配置结构兼容的同时,补齐了 VLESS、Hysteria2、TUIC 等新协议,扩展了规则集(rule-set)、域名嗅探(sniffer)、更完善的 GEO 数据管理等能力,是目前唯一活跃维护的主线内核。

客户端与内核的对应关系

选客户端本质上是在选内核。下载页收录的客户端里:Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android、ClashX Meta 均基于 mihomo 系内核,可以完整使用六种协议;Clash for Windows 基于原版 / Premium 内核且已停止维护,遇到 VLESS、Hysteria2、TUIC 节点会直接报不支持,仅建议有历史配置包袱的用户继续使用。如果订阅里已经出现 QUIC 系协议的节点,客户端必须选 mihomo 系,没有别的路径。各客户端在界面、平台覆盖、更新节奏上的详细差异,见客户端对比页;结论先行:全平台场景下 Clash Plus 是首选,桌面端次选 Clash Verge Rev。

F配置与订阅格式兼容性

订阅是"由服务器下发的一份配置文件",格式兼容性问题因此分两层:配置文件本身的字段是否被内核识别,以及订阅链接下发的格式是否被客户端识别。两层各有各的坑,混在一起排查只会绕远路。

配置字段层:同一结构,两套字段集

所有 Clash 系内核共享同一份 YAML 结构:proxies 定义节点,proxy-groups 定义策略组,rules 定义分流规则。差异在字段集:原版内核只认识基础协议的字段,mihomo 在同一结构里扩展了新协议类型与附加参数。下面的片段展示了同一份配置里新旧两类节点的形态差异:

proxies:
  - name: "节点-SS"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
  - name: "节点-HY2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com

把这份配置交给原版内核,解析到 type: hysteria2 时会以"unsupported proxy type"类错误整体拒绝加载——不是跳过这个节点,而是整份配置失败。这解释了一个高频现象:订阅在新客户端里正常,在旧客户端里"一个节点都没有"。反过来,纯基础协议的配置在 mihomo 上可以原样运行,兼容是单向的:新内核认旧配置,旧内核不认新字段。

订阅下发层:格式与 User-Agent

订阅链接返回的内容常见三种形态:Clash YAML(直接可用)、Base64 编码的分享链接列表(需客户端转换)、以及 sing-box 等其他生态的 JSON(Clash 系客户端不直接支持)。很多订阅服务器会根据请求头里的 User-Agent 决定下发哪种格式——同一条链接,用 Clash 系客户端请求得到 YAML,用浏览器打开得到 Base64。这带来一个隐蔽问题:如果服务器不认识某个客户端的 UA,可能下发错误格式甚至拒绝响应,表现为"链接在别的客户端能用、在这个客户端导入失败"。遇到这种情况,可在客户端的订阅设置里自定义 UA 字符串,或联系订阅提供方确认支持的客户端列表。

订阅导入报错、更新后节点清零这类具体故障的逐项自查,已在技术笔记《Clash 订阅失效或解析失败的六种原因与自查步骤》里单独展开,本章不再重复。

G按使用场景的选型建议

前面各章的结论在这里收拢成可执行的建议。前提再强调一次:线路质量的影响大于协议差异,以下建议都假设"同一台节点服务器提供多种协议入口",在这个前提下按场景挑协议才有意义。

用策略组落实选型,而不是手动切换

选型的落地方式不是每次手动换节点,而是把判断写进策略组。常用做法:为不同用途建立独立的策略组——浏览走一个 url-test 组(自动选延迟最低的节点),下载走一个手动 select 组(固定到吞吐好的节点),再用规则把不同域名分派到对应的组。这样协议选型只需要做一次,之后由规则自动执行。组内混排协议是允许的,url-test 的自动测试会替你比较它们的实际表现;需要注意的是自动测试反映的主要是建连延迟,吞吐差异仍需手动体验确认。

两类不必纠结的情况

第一,订阅只提供一两种协议时,选型空间不存在,直接用即可——不必因为"手册说 QUIC 更快"去要求更换协议,收益不确定而沟通成本确定。第二,桌面有线网络、线路质量良好时,六种协议的体验差距会被压缩到难以感知,此时把精力放在规则与策略组的组织上(参考教程的分流章节),回报远高于反复切换协议。选型建议的价值在边界场景:弱网、移动、低配设备、UDP 受限,这四种环境下按上表调整,差异是可感知的。

H常见误区与排查线索

最后一章收录围绕协议与内核的高频误区,以及"表现—定位—去处"式的排查索引。这里只给判断线索,完整的排查步骤在对应的专项文章里。

三个流传最广的误区

误区一:"协议越新越快"。新协议解决的是特定场景的问题(弱网、握手延迟、UDP 转发),不是全场景提速。线路本身的带宽、拥塞程度、物理距离决定了体验上限,协议只影响逼近上限的效率。误区二:"加密越强越安全,应该选加密最复杂的协议"。六种协议在密码学层面都使用现代 AEAD 或 TLS 1.3,强度均已足够,复杂度差异体现在功能与开销上,不体现在"安全等级"上;为想象中的安全性选择开销更大的协议,是纯粹的损失。误区三:"延迟测试的数字代表使用体验"。客户端里的延迟测试通常是一次 HTTP 请求的耗时,反映建连与线路往返,不反映吞吐、丢包与 UDP 待遇;两个节点显示相同的延迟数字,实际体验可以差距很大。数字用于横向比较同协议节点是有效的,跨协议比较则要谨慎。

按故障表现定位

节点报"unsupported proxy type"或订阅加载后节点清零:优先怀疑内核不支持该协议类型,对照第 E 章确认客户端的内核家族,必要时更换 mihomo 系客户端(下载页各平台均有)。VMess 节点单独失效而其他协议正常:检查设备系统时间是否与标准时间偏差过大。QUIC 系节点(Hysteria2/TUIC)在特定网络下明显变慢或不通、切换网络后恢复:符合 UDP 被限速的特征,该网络下改用 TCP 系协议。所有节点全部超时:多数与本地网络、订阅服务器或客户端状态有关,与协议选型无关,按《Clash 节点全部超时无法连接?》的顺序从近到远排查。代理已连接但网页打不开:通常卡在系统代理、DNS 或规则命中环节,对照《Clash 已连接但打不开网页》的清单逐项确认。

延伸入口

名词层面的疑问(策略组、TUN、GEO 数据、REALITY 等)在术语表里按分类收录;安装、配置、使用中的零散问题在 FAQ 按"基础认知—安装配置—使用技巧—故障排查"四类组织;平台相关的安装细节(macOS 网络扩展授权、Windows TUN 模式)在技术笔记的平台指南系列里有逐屏说明。本页会随内核与协议生态的变化持续修订,以当前版本为准。