Clash 协议与内核参考

第一章 · 先看这一节:本页怎么用,与教程页如何分工

站内两条主线先分清。教程页是上手主线:装好客户端、导入订阅、选好模式、验证分流,跟着做完就能用,全程不要求理解协议细节。本页是另一条线——系统查阅手册,回答的是"为什么"和"选哪个":订阅节点列表里那一串协议类型各自是什么来路,连接速度差在哪一步,手机上谁更省电,几个内核之间到底是什么亲缘关系。两页互为补充:第一次配置,请先去教程页把主线走通;配置能跑了、想把节点列表里的选项看明白,再回到这里逐章查。

本页的组织方式按"选型决策"排布,不按字母表。第二、三章讲协议本身:先是经典三件套 Shadowsocks、VMess、Trojan 的诞生背景与设计取舍,再是新一代的 VLESS、Hysteria2、TUIC 各自解决了什么老问题。第四、五章做横向对比:连接建立速度、吞吐瓶颈、CPU 与内存占用,以及移动端最关心的电量表现。第六、七章转向承载协议的软件层:内核家族关系与配置兼容性,订阅格式为什么会"在这个客户端能用、换一个就报错"。第八章把前面所有结论收束成一张按场景查的选型清单。

阅读路径按人分三种。刚接触 Clash 的读者,建议按章节顺序通读第二到第四章,建立"协议是传输方案、内核是执行引擎、客户端是操作界面"这个三层认知,后面所有结论都挂在这个框架上。已经在用、但遇到"某类节点连不上""某个协议特别耗电"这类具体问题的读者,直接跳第五章和第七章,再配合疑难解答里对应的分类条目。替家人朋友选客户端、自己不打算深究的读者,第六章的内核对照表和第八章的场景清单看完即可离开,十分钟够用。

名词约定说在前面。本页说"协议"专指节点的传输协议类型,即配置文件 proxies 段里 type 字段的取值;说"内核"指真正处理流量的核心程序;说"客户端"指带图形界面的软件外壳。单个名词的完整解释集中在概念速查,具体故障的处理步骤集中在疑难解答,本页不重复展开,遇到生词随手去查即可。

还有一条边界先划清:本页只讨论工程取舍——握手轮次、加密开销、电量、兼容性,不评价任何服务商,也不涉及节点来源。节点用什么协议是订阅提供方决定的,读者真正能做的选择有两个:一是挑一个内核能力覆盖自己订阅的客户端组合,二是当订阅同时给出多种协议的节点时,知道在什么场景下把策略组切到哪一类。本页所有建议都从这两个决策点出发。

第二章 · 经典三件套:Shadowsocks、VMess、Trojan 的来路与取舍

先看三个"老资历"。它们出现得早、部署面广,几乎所有内核都支持,是订阅里最常见的类型。理解它们各自的设计出发点,后面看新协议时才知道"新"在哪里。

Shadowsocks:把事情做少的典范

Shadowsocks(配置里写作 ss)是三者中最早成型的方案,设计哲学是"做少":客户端与服务端约定一个预共享密钥,流量用对称加密算法直接封装转发,没有额外的会话协商,没有复杂的元数据结构。现行实现普遍采用 AEAD 类加密套件(如 aes-128-gcm、chacha20-ietf-poly1305),兼顾加密与完整性校验。少,带来的直接好处是快和省:建连几乎没有协议层面的额外往返,加解密开销在现代 CPU 上可以忽略,连树莓派级别的路由器都跑得动。代价同样明确:协议本身不携带传输层多路复用,每条连接各自独立;功能扩展空间小,想加能力只能在外层叠插件。给它的定位一句话:轻、快、对老设备最友好,是"能用就行"场景的保底选择。

VMess:生态换来的字段,字段带来的负担

VMess 出自 V2Ray 生态,思路与 Shadowsocks 相反——做全。它自带用户 ID 体系、内建加密、可自由组合的传输层(裸 TCP、WebSocket、HTTP/2 等都能挂),字段丰富意味着服务端可以做精细的用户与路由管理。但字段多也意味着负担:VMess 的认证机制依赖客户端与服务端的时间戳校验,两端系统时间偏差过大会直接握手失败——"所有 VMess 节点集体超时,其他协议正常"这个经典故障,十有八九是本地时间不准,排查思路在节点超时排查顺序一文里有完整流程。另外,VMess 常见搭配是 WebSocket + TLS,封装层数多,建连轮次和 CPU 开销都比 Shadowsocks 高一截。定位:生态成熟、配置灵活,但属于"重"方案,新部署已逐渐被 VLESS 取代。

Trojan:直接借用 HTTPS 的成熟路径

Trojan 的取舍又是另一个方向:不自己发明加密,直接把流量放进标准 TLS 连接,服务端行为与一台普通 HTTPS 网站服务器一致。工程收益很实在——TLS 是互联网上验证最充分的加密通道,握手路径成熟,各类网络中间设备兼容性好,客户端实现也简单。代价是部署门槛转移到了服务端:需要一张有效的域名证书,证书过期或域名解析异常都会让节点整体不可用,这类故障客户端侧无解,只能等订阅提供方处理。对使用者而言,Trojan 节点的日常表现通常稳定、延迟可预期,是网页浏览与视频场景的稳妥选项。

第三章 · 新一代协议:VLESS、Hysteria2 与 TUIC 各自解决了什么

三个新方案不是凭空出现的,每一个都针对上一章某个具体痛点。看它们时抓住一个问题:它把哪部分工作从协议层挪走了,又把哪部分做重了。

VLESS:给 VMess 减重

VLESS 可以理解成 VMess 的减法版本:去掉内建加密与时间戳校验,把机密性完全交给外层 TLS,协议本身只保留最小的用户标识与路由信息。少了一层加密封装,CPU 开销显著下降,也不再有时间偏差导致的握手失败——VMess 用户最头疼的两件事一次解决。它常与新式传输层组合出现,例如基于 TLS 会话特征优化的传输方案,这些组合的可用性取决于内核版本,这一点第七章讲订阅兼容时会展开。选型时记一条:同一订阅里若同时有 VMess 与 VLESS 节点,且客户端内核支持,优先 VLESS,几乎是纯收益。

Hysteria2:为糟糕链路设计的 QUIC 方案

Hysteria2(配置里写作 hysteria2)换了地基:不再基于 TCP,而是构建在 QUIC(UDP 之上的现代传输协议)上,并配套了激进的自定义拥塞控制策略。这套组合针对的是一个具体场景——高丢包、高抖动的链路,比如移动网络、跨运营商的长距离连接。传统 TCP 在丢包时会大幅退让,速度断崖式下跌;Hysteria2 的策略是按预设带宽持续推进,丢了就补,弱网环境下的吞吐表现常明显好于 TCP 系协议。代价有两个:一是持续的带宽估计与重传逻辑让它在"好链路"上没有优势,还多耗资源;二是基于 UDP,少数网络环境对 UDP 流量限速或干扰,遇到时表现反而不如 TCP 系。定位:弱网利器,好网平平。

TUIC:把 QUIC 的多路复用用满

TUIC 同样构建在 QUIC 上,但侧重点不同:它充分利用 QUIC 的原生多路复用与 0-RTT 会话恢复——多条代理请求跑在同一条 QUIC 连接里,不互相阻塞;曾经连过的服务端可以近乎零往返地恢复会话,第二次建连几乎是瞬时的。对高频、小请求的场景(网页浏览、即时通讯)体感提升明显。与 Hysteria2 相比,TUIC 的拥塞控制更接近常规实现,不做激进带宽抢占,持续开销更温和。同样因为走 UDP,它继承了与 Hysteria2 相同的环境依赖:所处网络对 UDP 不友好时,表现打折。

第四章 · 连接速度与资源占用:第一口数据由握手轮次决定

"哪个协议快"是被问得最多、也最容易答错的问题。先把"快"拆成两半:建连速度(点开链接到内容开始加载的那一小段)和持续吞吐(下载大文件、看高码率视频时的稳定速率)。两者的决定因素完全不同,选型时要分开看。

建连速度:数一数往返轮次

建连快慢基本由"客户端与服务端之间要打几个来回"决定,每个来回消耗一个 RTT(往返时延)。粗略地数:Shadowsocks 走 TCP,一次 TCP 握手后即可发数据;Trojan 与 VLESS 在 TCP 之上还要完成一次 TLS 握手,多一轮;VMess 若配 WebSocket+TLS,再叠一层升级握手,轮次最多。QUIC 系的 Hysteria2 与 TUIC 把传输握手与加密握手合并进一次交互,首连一个往返内完成;TUIC 的 0-RTT 恢复更进一步,回访曾连过的服务端时几乎不花轮次。当物理延迟本身较高时(例如跨洲链路 RTT 200ms 以上),轮次差异会被放大成体感差异——同一订阅里 QUIC 系节点"点开就有"、TCP 系节点"顿一下才动",多半就是这个原因。

持续吞吐:瓶颈通常不在加密

持续传输阶段,现代 CPU 做 AEAD 加解密的速度远超家用带宽,加密本身很少成为瓶颈。真正拉开差距的是传输层对丢包的反应:TCP 系协议(SS、VMess、Trojan、VLESS)受操作系统 TCP 栈的拥塞控制支配,丢包即降速;Hysteria2 用自定义策略硬顶,弱网吞吐领先;TUIC 介于两者之间。所以结论反直觉:链路质量好时,六个协议的吞吐差异很小;链路质量差时,差异主要来自传输层而非协议本身。

内存与 CPU:数量级参考

资源占用方面给定性排序即可。CPU 开销从低到高大致是:SS ≈ VLESS < Trojan < TUIC < VMess ≈ Hysteria2——VMess 输在多层封装,Hysteria2 输在持续的带宽探测。内存差异主要来自连接数而非协议:QUIC 系协议单连接承载多路请求,连接总数少,内存反而占优;在路由器这类内存以 MB 计的设备上,SS 的极简实现仍是唯一稳妥项。

第五章 · 移动端电量:耗电的三个来源,协议只是其一

"开了 Clash 手机掉电快"是移动端最高频的抱怨。先把责任拆清楚:耗电来自三层——协议本身的保活行为、客户端的健康检查策略、系统层面的常驻方式。三层各自独立,逐层排查才不会冤枉协议。

协议层:UDP 保活是隐形电老虎

QUIC 系协议(Hysteria2、TUIC)为了维持 UDP 会话,需要周期性发送保活包;Hysteria2 的带宽探测逻辑在连接活跃时还会持续工作。每一次发包都会短暂唤醒移动设备的射频模块,而射频唤醒正是移动端耗电大头。TCP 系协议(SS、Trojan、VLESS)在无流量时可以长时间静默,系统能进入更深的节能状态。所以在电量优先的场景下,结论与第四章正好互补:插电或 Wi-Fi 场景放心用 QUIC 系,纯电池的移动网络场景优先 TCP 系轻协议。

客户端层:健康检查间隔是最值得动手的一项

url-test 类策略组会按 interval 周期对组内所有节点发起测速,间隔设得太密(比如 60 秒),等于让手机每分钟把几十个节点挨个唤醒测一遍。移动端把间隔放宽到 600 秒以上,体感延迟几乎无差,电量收益立竿见影:

proxy-groups:
  - name: 自动选择
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 600        # 移动端建议 ≥600 秒
    tolerance: 80        # 新旧节点延迟差小于 80ms 时不切换
    proxies: [节点A, 节点B]

tolerance 也值得一并设置:没有它,两个延迟接近的节点会被反复切换,每次切换都伴随一轮新建连。订阅由提供方托管、改不了配置的,可以在客户端界面里把自动测速组手动切成 select 型固定节点,效果等价。

系统层:TUN 常驻与厂商后台策略

TUN 模式建立虚拟网卡全量接管流量,进程必须常驻,安卓各厂商的后台限制策略又会反复尝试杀掉再拉起它,一杀一拉比安静常驻更耗电。TUN 与系统代理的机制差异在TUN 模式与系统代理的区别一文有逐层拆解;安卓端从电池统计定位耗电来源、逐项关停的完整清单,见安卓耗电排查。一个够用的原则:手机上没有全局接管需求就用系统代理模式,把 TUN 留给桌面端。

第六章 · 内核家族:原版、Meta 与 mihomo 到底什么关系

很多兼容性问题的根源是把"Clash"当成一个软件。实际上它是一个家族:内核负责按配置处理流量,客户端只是套在内核外面的操作界面。搞清家谱,第七章的兼容性问题就一目了然。

家谱:一次分叉,两个名字

最初的开源项目是原版 Clash 内核,配套还有闭源的 Premium 构建(多出 TUN 等能力)。原版仓库停止维护后,社区维护的 Clash.Meta 分支接过了演进主线,持续加入新协议与新规则类型,后来改名为 mihomo——所以"Clash.Meta"与"mihomo"是同一条血脉的先后两个名字,日常说的"Meta 系内核"指的就是它。今天还在活跃维护、支持全部六类协议的,只有 mihomo 这一支。选择客户端时,第一个要确认的就是它内置哪个内核。

能力差异:一张表看全

规则层面补一句:mihomo 对原版的常用字段(port、mode、DOMAIN-SUFFIX、GEOIP、MATCH 等)保持向下兼容,老配置直接喂给 mihomo 通常照常工作;反方向则不行——配置里只要出现一条 mihomo 专属语法,原版内核就会报错拒载:

rules:
  - GEOSITE,category-ads-all,REJECT   # 仅 mihomo 识别,原版内核报错
  - GEOIP,CN,DIRECT                   # 两系内核通用
  - MATCH,手动选择                     # 两系内核通用

客户端与内核的对应关系

落到客户端下载页的货架上:Clash Plus(全平台首推)、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android 都基于 Meta 系能力,六类协议全部可用;ClashX Meta 同属 Meta 系但已停止维护;Clash for Windows 基于原版内核且已停止维护,是目前"订阅里有新协议节点却加载失败"最常见的病灶——还在用它的读者,迁移到 Clash Verge Rev 的完整流程见Windows 安装 Clash Verge Rev 全流程。选型逻辑一句话收尾:订阅里只要出现过 VLESS、Hysteria2、TUIC 任意一种,客户端必须是 Meta 系,没有第二个答案。

第七章 · 订阅格式与字段兼容:为什么换个客户端就报错

协议与内核之间还隔着一层:订阅。同一条订阅链接,在 A 客户端节点齐全、在 B 客户端一片空白,问题几乎都出在这一层。这一章把订阅的形态与失败模式讲清。

订阅的两种形态

订阅链接返回的内容分两类。第一类是完整的 Clash 配置(整份 YAML,含 proxies、proxy-groups、rules),客户端拿来即用,分流策略由订阅提供方写好;第二类是通用节点列表(常见为 Base64 编码的分享链接集合),Clash 系客户端不能直接使用,需要经过订阅转换服务翻译成 Clash 格式。转换环节是个隐形变量:转换模板决定了输出配置用哪一系内核的语法,模板陈旧就可能把 Hysteria2 节点悄悄丢弃,或输出原版内核不认识的字段。节点数量对不上时,先确认订阅形态、再检查转换配置,顺序不要反。

字段兼容:一个字段掀翻整份配置

YAML 配置是整体载入的,内核遇到不认识的节点 type 或字段,不同实现的处理方式不同:宽松的跳过该节点(表现为节点变少),严格的直接拒载(表现为订阅导入失败、节点列表全空)。以一个 Hysteria2 节点为例,它的专属字段原版内核一个都不认识:

proxies:
  - name: 示例-HY2
    type: hysteria2          # 原版内核不识别此类型
    server: example.com
    port: 443
    password: your-password
    sni: example.com

反过来也有坑:个别客户端会在导入时"帮忙"改写配置、补默认字段,改写逻辑不同,同一订阅在不同客户端的最终行为就可能有细微差异。遇到"只有某个客户端异常"的情况,把订阅链接在浏览器里直接打开、核对原始内容,是最快的定位手段。

导入失败的排查顺序

固定四步,按序执行:①确认订阅未过期——多数失效订阅返回空内容或错误页,而不是报错;②确认客户端是 Meta 系(对照第六章表格);③检查是否经过订阅转换、转换模板是否支持订阅里的全部协议;④查看客户端日志里的 YAML 报错行号,定位具体字段。前两步能解决大半问题;"节点列表是空的""全部节点超时"这两类高频症状,在疑难解答和节点超时排查一文里各有独立的完整流程,照着走即可。

第八章 · 按场景选型:一张速查清单

前七章的结论,收成一张按场景查的表。用法:先在左列找到自己的主场景,按"优先—次选"顺序在策略组里固定或分组;订阅里没有优先项时,退到次选即可,不必强求。

表之外,三条通用原则值得写在页边。其一,协议选型永远排在节点选择之后:同协议不同节点的质量差异,通常大于同节点不同协议的差异,先用延迟测试和实际下载把节点池筛一遍,再谈协议偏好。其二,用策略组固化决策,而不是每天手选:把弱网优先的 QUIC 系节点编成一组、省电优先的 TCP 系编成另一组,场景切换时切组,而不是在几十个节点里翻找——策略组的编写方法在教程页的进阶小节有分步说明。其三,定期回看:订阅提供方会调整节点协议构成,内核也在持续演进,本页的定性结论稳定,但你手里那份订阅的最优解每隔几个月值得重验一次。

选型想好了,落地只剩两步:去客户端下载页按平台取一个 Meta 系客户端——全平台首推 Clash Plus,Windows/macOS/Linux 亦可选 Clash Verge Rev 或 FlClash;然后回教程页把订阅导入与分流验证走完。配置过程中卡在任何一步,疑难解答按分类索引,生词随手查概念速查。这份参考写到这里,该圈的重点都圈完了。