Clash 协议手册

第一章 · 手册定位与查阅方式

本手册与站内其余页面的分工,先行说明如下。入门指南承担"从安装到连通"的主线操作:下载客户端、导入订阅、选择模式、验证连接,四步走完即可正常使用,全程不要求理解任何协议名词。本手册承担的是另一半工作——回答"节点列表里那些 ss、vmess、trojan、hysteria2 字样各是什么""为什么同一订阅里有的节点快有的慢""旧客户端为什么读不出某些节点"这类需要原理支撑的问题。二者的关系可以概括为:教程页保证能用,手册页保证会选。尚未完成安装的读者,建议先按教程页操作一遍,再回到本页按需查阅;客户端安装包统一由下载页提供,各平台首推 Clash Plus。

全书结构按查阅习惯组织。第二章至第四章按技术脉络分三组介绍六类协议:Shadowsocks 与 VMess 代表早期的自建加密路线,Trojan 与 VLESS 代表复用标准 TLS 的伪装路线,Hysteria2 与 TUIC 代表基于 QUIC 传输的新一代路线。第五章将六者放进同一张表做横向性能对比,并单独讨论移动端电量。第六章梳理原版 Clash、Clash.Meta 与 mihomo 三代内核的沿革与功能差异——这直接决定客户端能识别哪些协议。第七章说明 Clash 订阅与其他分享格式的兼容关系。第八章按使用场景收束成可执行的选型条款。

有两项术语约定需先行确认。其一,本手册所称"协议",对应 Clash 配置文件中 proxies 条目的 type 字段,即客户端与远端服务器之间的传输协议,与"规则""策略组"等概念属于不同层面。其二,绝大多数用户并不手写协议字段——节点参数由订阅下发,客户端解析后呈现为节点列表;因此"选协议"在实践中体现为两件事:在多协议混编的订阅里优先选用某类节点,以及在与服务提供方沟通时明确要求某类节点。理解这一点,后续各章的选型建议才有落脚处。

第二章 · Shadowsocks 与 VMess:两代经典协议的设计取舍

Shadowsocks:最小化的加密转发

Shadowsocks(下称 SS)是六类协议中结构最简单的一个,诞生年代最早,设计目标只有一条:在本地与远端之间建立一条加密的数据转发通道,除此之外不附加任何东西。其工作方式为:客户端在本地监听,收到应用流量后按预共享密码加密,发往远端服务器解密转发。协议本身没有握手阶段、没有会话状态、没有版本协商,首个数据包即携带业务数据。现行实现统一采用 AEAD 加密套件,常见取值为 aes-128-gcm、aes-256-gcm 与 chacha20-ietf-poly1305,其中 ChaCha20 系列在不带 AES 硬件指令的老旧手机与路由器上速度明显更优。

这种极简结构带来两面性。正面是开销全场最低:无握手意味着首连即刻建立,单层加密意味着 CPU 与内存占用可以忽略,因此 SS 至今仍是旧设备与嵌入式环境的首选。反面是协议行为特征长期被充分研究,现代部署中常需配合传输层插件补强,这属于服务端职责,客户端侧无须干预,仅需按订阅下发的 plugin 字段照常解析即可。

关于 SS 还有两处细节值得单独交代,因为它们直接影响可用性判断。第一是加密套件的选择逻辑:aes-128-gcm 与 aes-256-gcm 在具备 AES-NI 指令的现代处理器上由硬件加速,几乎不占 CPU;而在缺少该指令集的低端 ARM 芯片、老款手机与家用路由器上,AES 只能软件实现,吞吐会明显下滑,此时 chacha20-ietf-poly1305 往往能跑出成倍的速度差。若同一订阅对同一节点同时提供两种套件,旧设备优先选 ChaCha20 系,不是安全性考量,而是纯粹的算力适配。第二是 UDP 转发:SS 原生支持 UDP 中继,但是否真正可用取决于服务端有没有开启对应端口转发,而客户端配置里的 udp: true 只是声明意愿,并不能创造能力。这正是"网页正常但游戏语音不通"的常见成因之一——判断方法是在客户端连接详情里观察是否出现 UDP 类型的连接记录,而非反复改写配置文件。

VMess:结构化的会话协议

VMess 是 V2Ray 项目的原生协议,设计年代晚于 SS,思路截然不同:与其做一条极简管道,不如做一个结构完整的会话协议。VMess 以用户 UUID 为身份凭据,请求头携带指令、加密方式等元数据,并内置时间校验机制——客户端与服务端的系统时间偏差超出容忍范围(约九十秒)即握手失败,这也是"节点全部超时,先检查手机时间"这条经典排查经验的出处。VMess 的另一特点是传输层高度可组合:可裸跑 TCP,也可套 WebSocket、gRPC 等传输并叠加 TLS,套 WebSocket 加 TLS 后对外呈现为一次普通的加密 Web 会话,是共享托管环境下的常见部署形态。

取舍同样清楚:结构化头部与多层传输带来了灵活性,也带来了高于 SS 的握手延迟与 CPU 开销;早期的 alterId 动态端口混淆机制已被 AEAD 头部取代,现代订阅中该字段应为 0,若拿到非零值的老式节点,兼容性与安全性都需存疑。两者的典型配置字段如下,仅供核对订阅解析结果,一般不建议手工改写:

proxies:
  - name: "示例-SS"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
  - name: "示例-VMess"
    type: vmess
    server: node.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws

第三章 · Trojan 与 VLESS:复用标准 TLS 的伪装路线

Trojan:把自己藏进 HTTPS

Trojan 的设计出发点与前两者相反:不发明任何新的加密结构,直接复用互联网上最普遍的 TLS。一次 Trojan 连接从外部观察就是一次标准的 HTTPS 访问——真实域名、有效证书、标准握手,全部齐备;只有持有正确密码的客户端,才会在 TLS 通道内被识别为代理请求,其余访问(包括浏览器直接打开该域名)会被回落到服务器上挂载的真实网站。这套机制要求服务端必须持有域名与证书,部署门槛落在服务方,客户端侧反而极其简单:核心字段只有 password 与 sni 两项。

性能层面,Trojan 的建连成本就是一次 TLS 握手,不多不少;数据面只有 TLS 单层加密,CPU 开销低于 VMess 套 WebSocket 加 TLS 的多层结构,吞吐上限也更高。选型时唯一需要留意的字段是 skip-cert-verify:该项为 true 意味着跳过证书校验,仅应在明确知晓原因的排查场景短暂使用,日常配置中出现此值应向服务方确认缘由。

VLESS:做减法的下一步

VLESS 可以理解为对 VMess 的一次系统性减法:既然外层已经有 TLS 负责机密性,协议内层的加密就是重复劳动——VLESS 因此去掉了内置加密,协议头压缩到最小,身份仍以 UUID 表达,机密性完全交给外层 TLS。在此基础上,VLESS 生态发展出两项重要扩展:XTLS 流控(常见取值 xtls-rprx-vision)通过减少内外两层加密的重复处理提升大流量吞吐;REALITY 则借用第三方真实网站的 TLS 指纹完成握手,使服务端不再需要自备域名与证书。

对客户端用户而言,VLESS 一系有两个实务要点。第一,协议支持完全依赖内核世代:mihomo 内核完整支持 VLESS、XTLS 与 REALITY,原版 Clash 内核一概不识别,拿到此类节点却报 unsupported proxy type,应先核对客户端内核(详见第六章)。第二,VLESS 的字段数量在六类协议中最多——flow、reality-opts、client-fingerprint 等任何一项与服务端不匹配都会导致连接失败,故此类节点务必依赖订阅自动下发,手工誊抄出错率很高。

第四章 · Hysteria2 与 TUIC:基于 QUIC 的新一代协议

共同底座:QUIC 带来了什么

前三章的四类协议全部构建在 TCP 之上,本章两位则构建在 QUIC 之上——QUIC 是运行于 UDP 的用户态传输协议,也是 HTTP/3 的底座。这一层的更换带来三项通用收益:其一,0-RTT 会话恢复,断线重连几乎不产生额外握手往返,首连体验显著优于"TCP 三次握手加 TLS 握手"的叠加;其二,连接迁移能力,手机在 Wi-Fi 与蜂窝网络之间切换时会话可以延续,不必重建连接;其三,拥塞控制在用户态实现,可以替换为更激进的算法,而不受操作系统内核 TCP 栈的约束。

两条不同的实现路线

Hysteria2 走的是激进带宽利用路线。其标志性设计是允许用户声明链路带宽(配置中的 up/down 字段),内建的拥塞控制据此主动填充链路,在高丢包、高延迟的弱网环境下,吞吐表现常显著优于依赖标准拥塞控制的 TCP 系协议——后者遇到丢包会保守退避,而 Hysteria2 不会。其外观伪装基于 HTTP/3,与正常的三代 Web 流量同层。TUIC 则走"更标准的 QUIC"路线:不做激进填充,拥塞控制算法可在 bbr、cubic、new_reno 之间选择,并原生定义了两种 UDP 转发模式(over stream 与 native),对游戏、语音这类 UDP 业务的转发语义比 TCP 系协议干净得多。

必须写明的代价

两条路线的差异还体现在带宽声明这一处细节上,它是 Hysteria2 最容易被误用的字段。up/down 并非限速阀门,而是告知拥塞控制"链路大致有多宽",算法据此决定发包节奏。声明值远高于实际带宽,会让发送端持续超发,表现为丢包率飙升、延迟抖动加剧,实测速度反而低于不声明;声明值明显偏低,则算法主动收敛,链路利用不足。故此字段应由服务方按线路实况给定,用户不宜凭"我家宽带一千兆"随手填写。TUIC 一侧对应的调节位是拥塞控制算法:bbr 在高延迟长肥管道上通常最稳,cubic 在低延迟稳定链路上更平顺,new_reno 仅作兼容保留。两者共同的实务结论是:QUIC 系节点的表现对参数敏感度远高于 TCP 系,同一台服务器换个参数就可能换个量级,因此"这类协议不好用"的结论在核对参数来源之前不宜过早下定。

QUIC 一系的代价与收益同样明确。第一,链路依赖 UDP,而部分接入网络对 UDP 流量实施限速或低优先级调度,此时 QUIC 系协议的实测速度可能反而不如一条普通的 Trojan 连接——是否受限只能实测,无法预判。第二,用户态协议栈加上全程加密,CPU 占用高于 TCP 系协议,直接反映为移动端电量消耗上升(第五章展开)。第三,QUIC 依靠周期性探测维持连接活性,手机后台常驻时的唤醒次数多于安静的 TCP 长连接。综上,QUIC 系协议应当被理解为"特定场景的利器"而非默认之选。

第五章 · 连接速度、资源占用与移动端电量对比

比较口径

先申明口径:协议性能受服务器规格、线路质量、传输层组合影响极大,任何"某协议延迟多少毫秒"的绝对数值脱离环境都无意义。下表给出的是同等服务器与线路条件下的相对量级,只用于回答"同一订阅里几类节点相互比较孰优孰劣",不构成对任何具体节点的性能承诺。表中 VMess 按最常见的 WebSocket 加 TLS 组合计,VLESS 按 REALITY 组合计。

各列结论的成因

首连建立一列由握手层数决定:SS 无握手,首包即数据;Trojan 只有一次 TLS 握手;VMess 套 WebSocket 加 TLS 需要 TCP、TLS、WebSocket 三层依次建立,故最慢;QUIC 两家在会话恢复时可做到 0-RTT,重连场景优势尤其明显。弱网吞吐一列由拥塞控制决定:TCP 系协议受操作系统标准拥塞控制约束,遇丢包保守退避;Hysteria2 的主动填充策略在丢包环境下退让最少。CPU 一列由加密层数与协议栈位置决定:单层加密的 SS、Trojan、VLESS 最省;QUIC 系的用户态协议栈本身即是持续的计算负担。

移动端电量的单独说明

移动端电量值得单列一段,因为它的决定因素与桌面端不同。手机上 Clash 通过 VpnService 建立虚拟网卡常驻后台,耗电由三部分构成:内核处理流量的 CPU 时间、维持连接活性的心跳唤醒、以及无线基带被唤醒的次数。TCP 系协议在空闲期几乎静默,而 QUIC 的活性探测更频繁,蜂窝网络下每次探测都可能唤醒基带,长时间待机的累计差异可观。实测排查方法与后台策略优化,站内博客《Clash 手机耗电快怎么排查》有完整步骤;Android 端 VpnService 的授权与保活机制见《Clash Android 客户端使用要点》。

第六章 · 内核家族:原版 Clash、Meta 与 mihomo 的关系

三代沿革

"Clash"一词在今天的语境里至少指三样东西:一种 YAML 配置格式、一个内核家族、一批 GUI 客户端。厘清内核沿革是理解兼容性问题的前提。最初的原版 Clash 内核确立了这一生态的全部基础范式——YAML 配置、proxies/proxy-groups/rules 三段式结构、规则分流与策略组;其闭源的 Premium 构建额外提供 TUN 模式等增强能力。其后,社区分支 Clash.Meta 在保持配置兼容的前提下大幅扩展协议支持。原版仓库归档停止维护后,Meta 分支延续开发并更名为 mihomo,成为当前事实上的主力内核;本站首页认证编号行所载 KERNEL mihomo,指的即是这一内核。

功能差异对照

上表还有一层容易被忽略的含义:内核世代不仅决定"能不能连",也决定"连上之后的行为是否一致"。以 DNS 为例,原版内核的 fake-ip 实现较为朴素,遇到部分只认真实 IP 的应用容易出现解析异常,只能靠手工维护过滤名单规避;mihomo 增加了 fake-ip 过滤增强与域名嗅探能力,可在流量中还原真实域名再交给规则匹配,同样一份规则在两代内核上的命中结果因此可能不同。再以规则集为例,新式二进制规则集加载更快、体积更小,但旧内核完全无法解析,一旦订阅方切换到新格式,旧客户端会在启动阶段直接失败而非降级运行。这类差异无法通过"改配置"弥合,只能通过更换内核解决,这也是本站在各处一致推荐在维客户端的原因。

配置兼容与客户端对应

配置兼容性遵循单向原则:为原版内核书写的配置文件在 mihomo 上基本可以直接运行,mihomo 对旧字段保持了良好兼容;反向则不成立——包含 VLESS 节点、新式规则集或嗅探配置的文件交给原版内核,会在启动阶段直接报错。这条原则映射到客户端层面即为选型结论:本站下载页收录的在维客户端(各平台首推的 Clash Plus,以及 Clash Verge Rev、FlClash 等)均内置 mihomo 内核,六类协议全部可用;已停止维护的 Clash for Windows 与 ClashX Meta 归档条目,前者搭载原版内核,无法识别 QUIC 系与 VLESS 节点。若节点列表出现 unsupported proxy type 一类报错,应对照本表更换 mihomo 系客户端,而非修改订阅。各客户端的完整横向对比另见客户端对比页。

第七章 · 订阅格式与配置兼容性

三类常见格式

日常接触到的"订阅"实际存在三种形态,兼容范围各不相同。第一种是 Clash 专用订阅:一份完整的 YAML 文档,包含 proxies、proxy-groups、rules 全部三段,Clash 系客户端可直接消费,这是最理想的形态。第二种是单节点分享链接:ss://、vmess://、trojan:// 一类 URI,一条链接描述一个节点,不含任何分组与规则信息。第三种是通用聚合订阅:多行分享链接整体做 Base64 编码后经 HTTP 分发,是跨客户端生态的最大公约数格式。后两种并非 Clash 原生格式,需要经过转换才能使用——多数订阅服务会同时提供 Clash 专用地址,应优先取用;mihomo 系客户端普遍内置了对常见分享链接的解析能力,但转换结果只含节点,分组与规则仍需配置文件补齐。

节点与配置分离:proxy-providers

进阶用法中值得掌握的机制是 proxy-providers:把节点来源声明为外部资源,主配置只负责分组与规则,内核按周期自动拉取更新节点。其价值在于自定义规则与订阅更新互不干扰——直接改写订阅下发的完整配置,下次更新即被覆盖;providers 结构则可长期维护。典型声明如下:

proxy-providers:
  main:
    type: http
    url: "https://example.com/sub?token=xxxx"
    interval: 86400
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

与 proxy-providers 同源的机制还有 rule-providers,两者一并使用才构成一套可长期维护的配置骨架:节点来源交给前者按周期拉取,域名与 IP 规则集交给后者远程更新,主配置文件里只保留策略组结构与少量个人自定规则,体量通常不过百行。这样组织的好处在升级时体现得最明显——换订阅只需替换一个 URL,换规则源只需替换一个规则集地址,个人定制部分始终不受影响。需要留意的是三项参数:interval 决定拉取周期,过短会给上游造成无谓压力,一般取一天较为合适;path 指向本地缓存文件,同一份配置内不同 provider 的路径不得重名,否则后写入者会覆盖前者;health-check 的探测地址与间隔决定策略组自动切换的灵敏度,间隔过短会持续产生后台流量,在移动端亦会推高电量消耗,与第五章的结论相互呼应。

兼容性注意事项

三条实务经验值得记录。其一,同一订阅地址对不同客户端可能返回不同内容——服务端常依据请求的 User-Agent 判断客户端类型并下发相应格式,故"浏览器打开订阅地址看到的内容"与"客户端实际拿到的内容"未必一致,排查订阅问题时不应以浏览器所见为准。其二,新协议节点的可用性由订阅输出端与内核共同决定:即便客户端运行 mihomo,若订阅端仍按原版字段输出,Hysteria2、VLESS 等节点也不会出现在列表中,此时应向服务方索取 mihomo 格式的订阅地址。其三,订阅导入后应设置自动更新间隔,长期不更新的订阅是"节点全部超时"的高频原因之一。导入操作的完整步骤见入门指南,各格式差异的展开讨论见博客《Clash 订阅链接导入教程》。

第八章 · 按使用场景的协议选型建议

选型的前提认知

先厘清一个常见误解:Clash 客户端里并没有一个"协议选择开关"。所谓选型,是在订阅下发的节点列表中,依据节点类型有倾向地选用——多数订阅为多协议混编,同一地区往往同时提供数种类型的节点;策略组亦可将不同协议的节点编入同组,按延迟自动切换。因此下列建议的用法是:对照场景确定优先类型,在节点列表中优先选用该类型,并保留一类回退。

场景对照表

三条补充条款

其一,游戏与会议场景除协议外还涉及流量接管方式:此类程序常不遵循系统代理设置,需在客户端开启 TUN 模式方可完整接管,两种接管机制的差异见博客《Clash TUN 模式和系统代理有什么区别》。其二,移动端在电量与速度之间取舍时,建议以第五章电量列为主要依据,QUIC 系节点仅在确有弱网或大流量需求时启用。其三,任何建议都不能替代实测——同类型节点因服务器与线路不同,表现差异可能大于协议之间的差异,选定类型后仍应在实际使用时段做对比验证。

一份可复用的实测流程

既然实测不可替代,不妨把它固定成流程,避免每次都凭感觉切换节点。第一步,固定变量:选定同一地区的若干节点,类型各异,在同一时间段内测试;跨时段、跨地区的对比数据没有可比性,因为线路负载本身随时间波动。第二步,分别记录三项指标:客户端内置延迟测试给出的往返时间(反映建连质量)、一次固定大小文件的实际下载耗时(反映吞吐)、以及连续使用十分钟后是否出现断流或速度衰减(反映稳定性)。第三步,把结论落到策略组:把实测最优的两三个节点编入手动选择组置于首位,再把同地区其余节点编入自动选择组作为兜底,而不是把几十个节点一律丢进同一个自动组——后者在延迟接近时会频繁抖动切换,反而影响体验。第四步,每次订阅更新后抽查一次:节点背后的服务器与线路是会变的,三个月前的结论不必然仍然成立。整套流程一次约十五分钟,对长期使用者来说是回报最高的一次性投入。

选型三步收束

全书内容收束为三步操作。第一步,确认客户端内核:在维的 mihomo 系客户端(各平台首推 Clash Plus,安装包见下载页)可用全部六类协议,旧内核客户端先行更换。第二步,确认订阅供给:检查节点列表实际包含哪些类型,缺少所需类型时向服务方索取 mihomo 格式订阅。第三步,按上表场景排序并实测验证,保留一类 TCP 系节点作为回退。操作层面的疑问转入门指南逐步执行,异常报错转常见问题页对照排查。