Clash 协议与内核技术参考

Clash 系客户端本身不发明协议,它是一个"多协议出站框架":配置文件里每个节点声明自己的 type,内核按类型调用对应的协议实现。因此选协议的第一步,不是纠结哪个"最快",而是搞清楚每种协议在设计上牺牲了什么、换来了什么。六种主流协议可以按两个维度粗分:传输层走 TCP 还是 UDP(QUIC),以及协议自身是否依赖 TLS 提供加密。

Shadowsocks:极简加密转发

Shadowsocks 是六者中最早的一代,设计目标只有一个:用尽可能少的代码,在客户端与服务端之间建立一条加密的 SOCKS 转发通道。协议头极短,没有握手协商阶段,连接建立后直接传输密文。早期的流加密方案已被淘汰,现行实现统一使用 AEAD 加密套件(如 aes-128-gcm、chacha20-ietf-poly1305),同时提供机密性与完整性校验。它的取舍很清楚:牺牲了协议层的可扩展性(没有多路复用、没有内建 UDP over TCP),换来了最低的实现复杂度与最小的每包开销。至今仍是低配设备与老旧路由器上的首选,也是很多订阅里的"保底节点"类型。SS2022 系列套件在密钥管理与抗重放上做了加固,内核层面视为同一 ss 类型的不同 cipher。

VMess:V2Ray 时代的多功能协议

VMess 随 V2Ray 项目诞生,定位与 SS 相反:宁可复杂,也要功能全。它在协议头里携带用户 ID、加密方式、时间戳等元数据,支持动态端口等特性,并且天然与 V2Ray 的传输层插件体系(WebSocket、gRPC、HTTP/2)组合使用。代价是协议头开销大于 SS,且早期依赖客户端与服务端时间同步——本机时间偏差过大时会握手失败,这是排查 VMess 节点连不上时的经典检查项。VMess 的价值在生态:大量面板、订阅转换工具围绕它构建,兼容性覆盖面广。作为纯协议看,它的加密与封装设计已显厚重,这直接催生了后面的 VLESS。

Trojan:把自己藏进 HTTPS 的形态里

Trojan 的思路是做减法:既然 TLS 已经提供了完善的加密,协议层就不再重复加密,只在 TLS 隧道内传一个简单的认证头加原始流量。对外观察,一条 Trojan 连接与普通 HTTPS 访问在传输形态上高度相似;认证失败的连接会被服务端回落到一个真实网站。它的取舍是:强依赖一套可用的域名与证书,部署门槛高于 SS,但客户端实现极薄、运行开销低。对使用者而言,Trojan 节点的连接行为稳定可预期,TCP + TLS 的组合在各种网络环境下兼容性最好,几乎不存在"运营商把这类流量单独限速"的问题。

VLESS:去掉冗余的下一代框架

VLESS 是 Xray 生态对 VMess 的重构:去掉协议自带加密(交给 TLS),去掉时间戳依赖,协议头压缩到最小,只保留 UUID 认证与必要的路由信息。这让它成为一个"薄壳",真正的差异化能力来自搭配的传输方案——XTLS Vision 通过流控减少 TLS in TLS 的双重加密开销,REALITY 则免去了自持证书的要求。选型时要注意:VLESS 本身几乎没有开销,性能表现取决于服务端配的是哪套组合,订阅里同样写着 vless 的两个节点,实际行为可能差别很大。客户端侧需要内核支持对应的传输特性,这也是后文内核章节强调 mihomo 的原因之一。

Hysteria2:为丢包环境而生的 QUIC 协议

Hysteria2 构建在 QUIC 之上,核心卖点是自定义拥塞控制:传统 TCP 的拥塞算法在高丢包链路上会大幅退让,跨洋链路实际吞吐经常只有带宽的零头;Hysteria2 采用更激进的发送策略,允许用户直接声明上下行带宽,在丢包 5% 以上的链路上仍能维持接近标称的速度。取舍同样明显:激进发包在拥塞网络中会挤占他人带宽,部分运营商对持续大流量 UDP 会话有 QoS 降速策略,遇到这种网络时 QUIC 系协议反而不如 TCP 系稳定。它适合"链路质量差但没有 UDP 限制"的场景,不适合当成无脑默认项。

TUIC:面向低延迟的另一条 QUIC 路线

TUIC 与 Hysteria2 同属 QUIC 系,但侧重点不同:它不做激进带宽争抢,而是充分利用 QUIC 的原生能力——0-RTT 握手让重连几乎无感,连接内多路复用避免队头阻塞,UDP 流量原生中继(native 模式)对游戏、实时语音这类小包高频的应用尤其友好。拥塞控制可在 cubic、new_reno、bbr 之间选择,行为比 Hysteria2 温和。它的短板是生态较小,提供 TUIC 节点的服务商少于其他协议,客户端支持要求内核为 Meta 血统。延迟敏感、丢包不严重的场景下,TUIC 的手感通常是六者中最好的。

把六种协议按传输层切开,会发现性能讨论里的大部分现象都能归因到这一层。SS、VMess、Trojan、VLESS 的主流形态走 TCP,Hysteria2 与 TUIC 走 UDP 上的 QUIC。两条路线的差异体现在四个方面。

握手成本

TCP + TLS 1.3 建立一条新连接需要一次 TCP 三次握手加一次 TLS 握手,首字节延迟约为两个 RTT;QUIC 把传输握手与加密握手合并,首连接一个 RTT,复用会话时 0-RTT 直接发数据。物理延迟 200ms 的跨洋链路上,这个差距在频繁建连的场景(网页打开瞬间的数十个并发请求)里可以被明显感知。TCP 系协议通过连接复用(mux)缓解,但 mux 引入了下一个问题。

队头阻塞

TCP 是单一有序字节流:一个丢包会卡住这条连接上所有后续数据,即使后续数据属于不相关的请求。在 TCP 连接上做多路复用,等于把多个请求绑上同一条容易被单点卡死的流,丢包环境下体感反而变差——这是"mux 不要随便开"的原理。QUIC 在协议内以独立流(stream)传输,单流丢包不影响其他流,多路复用是零负担的原生能力。

中间设备友好度

TCP 443 端口的 TLS 流量是互联网上最普遍的形态,任何网络环境都必须放行;UDP 长会话在部分运营商与企业网络中会被 QoS 限速、缩短 NAT 超时甚至丢弃。这是 QUIC 系协议"有时飞快有时不可用"的根源。选型结论:环境未知时 TCP 系是安全牌,QUIC 系需要实测验证。

伪装传输的位置

WebSocket、gRPC 这类传输插件属于 TCP 系协议的可选外壳,常用于套 CDN 中转的场景;代价是每层封装都增加延迟与开销,CDN 回源本身也引入额外一跳。QUIC 系协议不走这套体系。订阅里同名协议的不同节点若传输外壳不同,延迟表现可能差出一倍,测速时应分开对待。

协议本身的加解密开销在现代硬件上都很小,真正拉开差距的是握手模型、拥塞控制与封装层数。下表是同等链路条件下的定性对比,方向可靠,倍数因环境而异。

两点解释。其一,QUIC 系协议 CPU 占用偏高不是加密的锅,而是 QUIC 协议栈运行在用户态,收发包路径比内核态 TCP 长;桌面平台无感,低功耗设备上可测出差异。其二,"高丢包链路吞吐"一行的差距远大于表格能表达的程度:同一条丢包 10% 的链路,TCP 系协议可能只跑出带宽的十分之一,Hysteria2 能维持一半以上。链路质量决定了这张表哪一行对你重要。

测速方法建议:在客户端里对同一服务商的不同协议节点做延迟测试只反映握手 RTT,不反映吞吐;吞吐要用实际下载或流媒体加载来验证,并且分早晚高峰各测一次。下载页提供的各客户端均内建延迟测试,Clash Plus 的分组测速可以一次性比完同组全部节点。

手机上代理客户端的耗电由三部分构成:VPN 服务常驻的基础开销、协议栈处理流量的 CPU 开销、以及最关键的——网络行为触发的蜂窝/Wi-Fi 无线电唤醒。第三项占大头。协议对耗电的影响,主要通过心跳与重连行为传导。

心跳与保活

TCP 系协议依赖 NAT 映射存活,客户端或服务端通常以数十秒级的 keepalive 维持;每次心跳都可能把已休眠的蜂窝模块唤醒到高功耗状态并维持数秒。QUIC 系协议同样需要保活,但 QUIC 的连接迁移(connection migration)允许网络切换(Wi-Fi 与蜂窝之间)后沿用原连接,省去一轮完整重连;TCP 系协议在每次网络切换后必须全部重建连接,伴随一波集中的握手流量与无线电活跃。频繁在 Wi-Fi 与蜂窝间切换的使用模式下,QUIC 系协议的电量表现通常更好。

加密与协议栈开销

AEAD 加解密有硬件指令加速,各协议差距可忽略。QUIC 用户态协议栈在移动芯片上的额外 CPU 消耗可测但不显著,持续大流量传输(长时间视频)时才会体现;轻量浏览场景下可以不计。

比协议影响更大的因素

实测中,客户端配置对耗电的影响远大于协议选择:规则集自动更新间隔过短、日志级别开在 debug、DNS 并发解析策略激进、节点自动测速间隔过密,任何一项的耗电都可能超过协议差异一个量级。逐项排查方法见博客文章手机上 Clash 耗电严重怎么排查,Android 电池优化白名单与 iOS 按需连接的具体设置也在该文中。

"Clash"这个名字在今天至少指三样东西:一个已停止开发的原版内核项目、它的社区增强分支 Clash.Meta、以及 Meta 更名延续至今的 mihomo。GUI 客户端(Clash Plus、Clash Verge Rev、FlClash 等)都是套在内核外面的图形界面,内核决定了协议支持范围与配置语法上限。三者的谱系与差异如下。

三代内核谱系

原版 Clash 确立了 YAML 配置格式、规则分流模型与 RESTful 控制接口,支持 SS、VMess、Trojan 等当时的主流协议;项目停止开发并删除仓库后,原版内核不再获得任何更新,新协议一概不支持。Clash.Meta 是社区在原版基础上的增强分支,补齐了 VLESS、Hysteria 系、TUIC 等新协议与大量分流能力;后因避免名称纠纷更名为 mihomo,项目本体、配置格式与开发团队均未中断——mihomo 就是 Meta,只是换了名字。当前生态里活跃维护的 Clash 系内核只有 mihomo 一个,主流 GUI 客户端也已全部迁移到它。三代内核的完整来龙去脉见博客文章Clash 原版、Meta 与 mihomo 内核区别对照。

功能差异对照

配置兼容性

mihomo 对原版配置基本向下兼容:一份能在原版内核运行的 YAML,通常可以直接被 mihomo 加载。反向不成立——配置里只要出现 mihomo 扩展字段(如 hysteria2 节点类型、TUN 段、增强 DNS 字段),原版内核会直接报错退出。判断一份配置是否依赖 mihomo,可检索这类字段:

proxies:
  - name: hy2-node
    type: hysteria2      # 原版内核不识别该类型
    server: example.com
    port: 443
    password: your-password

tun:                     # 原版开源内核无此段
  enable: true
  stack: system
  auto-route: true

选型结论直接给出:今天没有理由新装原版内核。协议覆盖、TUN 模式、维护状态三项都指向 mihomo;本站下载页提供的 GUI 客户端均基于 mihomo 或其衍生,内核区也提供 mihomo 各平台裸内核,供服务器与路由器用户使用。

订阅是服务商向客户端分发节点的载体,格式不匹配是导入失败的头号原因。当前流通的订阅主要有三类。

三类订阅格式

第一类是 Clash YAML 订阅:一份完整或部分的 Clash 配置文件,包含 proxies、proxy-groups、rules 等段,Clash 系客户端原生支持,信息最完整,分组与分流规则可由服务商预置。第二类是 Base64 通用订阅:把 ss://、vmess:// 等节点分享链接逐行拼接后整体编码,只含节点不含规则,历史最悠久、兼容面最广;现代 Clash 客户端多能自动识别并转换,但转换后需要客户端自行补分组与规则。第三类是其他生态的专有格式(如 sing-box 的 JSON),Clash 系客户端不直接支持,需经订阅转换服务翻译。

协议支持对订阅的影响

格式正确不代表全部节点可用:YAML 订阅里若包含 hysteria2、tuic、vless 类型节点,而客户端内核是旧版或原版,轻则这些节点被静默丢弃,重则整份配置加载失败。表现为"订阅导入成功但节点列表比别人少"或"更新订阅后客户端报错"。处理顺序:先确认客户端内核为 mihomo 血统,再检查订阅链接是否带了服务商提供的 Clash 专用参数(很多机场同一订阅地址通过 URL 参数输出不同格式)。

用 proxy-providers 管理订阅

手动维护配置的用户,建议用 proxy-providers 把"节点来源"与"分组规则"解耦:节点由订阅地址定期拉取,分组与规则写在本地配置里,订阅更新不会冲掉个人定制。最小示例:

proxy-providers:
  main:
    type: http
    url: "订阅地址"
    interval: 86400        # 拉取间隔(秒),移动端不宜过短
    path: ./providers/main.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

综合前面各章,给出可直接执行的判断流程。前提:节点协议由服务商决定,以下建议用于"同一服务商提供多种协议节点时选哪个",以及"更换服务商时优先考察什么"。

桌面日常使用(办公 / 浏览 / 视频)

优先 Trojan 或 VLESS。TCP + TLS 组合在任何网络下兼容性最好,低开销、行为稳定,长时间挂机不出幺蛾子。链路丢包明显(晚高峰跨洋)且网络不限 UDP 时,把 Hysteria2 节点设为备选,高峰时段手动切换。客户端选 Clash Plus,分组测速与规则管理开箱可用;偏好开源桌面方案可选 Clash Verge Rev。

移动端(手机 / 平板)

信号稳定环境选 Trojan / VLESS,通勤等频繁切网场景优先 TUIC(连接迁移减少重连,0-RTT 降低切网后的恢复延迟)。避免长期使用 Hysteria2 挂后台——激进发包模型对电量不友好。客户端配置比协议更重要:更新间隔、日志级别按电量章节的建议收紧。iOS 用户通过 App Store 获取 Clash Plus,流程见教程页。

弱网与高丢包链路

Hysteria2 是为这个场景设计的,收益最大;带宽参数按真实链路填写,虚标上行只会加重丢包。若 UDP 被限速(表现为 QUIC 节点速度周期性跳水),退回 TCP 系协议,并优先选服务端有 BBR 拥塞控制的节点。

游戏与实时应用

关注 UDP 转发与延迟抖动:TUIC(native UDP 模式)与 Hysteria2 原生转发 UDP,是第一梯队;SS 需服务端开启 UDP 支持;VMess / Trojan 的 UDP 能力取决于服务端实现,普遍不如 QUIC 系。选型前先确认游戏用 UDP 还是 TCP,回合制与网页游戏走 TCP,协议差异不大。

服务器与路由器

裸跑 mihomo 内核,协议选 SS(资源占用最低)或 Trojan;MIPS / ARMv7 等低配设备避免 QUIC 系协议的用户态协议栈开销。内核各架构包在下载页内核区,以命令行方式运行:

mihomo -d /etc/mihomo    # 指定配置目录启动

决策速查

误区一:某某协议"最快",全场景通用。不存在。速度由链路质量、服务端负载、拥塞控制共同决定,协议只是其中一个变量。同一协议在不同链路上排名可以完全颠倒,结论只能来自自己链路的多次实测。

误区二:新协议一定比旧协议好。SS 诞生最早,但在低配设备与稳定链路上仍是开销最低的选择;VLESS + REALITY 组合很新,但要求内核与服务端版本匹配,出问题时排查难度也更高。协议是工具,匹配场景比追新重要。

误区三:客户端决定协议性能。GUI 客户端只是内核的外壳,同一 mihomo 内核下,不同客户端的协议吞吐没有本质差异。客户端之间的差别在交互、平台适配与配置管理能力,协议层面看内核版本即可。

误区四:延迟测试低等于体验好。客户端里的延迟数字通常是一次 HTTP 握手的 RTT,不反映吞吐、丢包与稳定性。一个延迟 80ms 但晚高峰丢包严重的节点,体验不如延迟 150ms 但全天稳定的节点。

误区五:配置报错先怪协议。加载失败的多数原因是 YAML 缩进错误、订阅格式不匹配或内核版本过旧,协议本身出问题的概率排在最后。按"格式 → 内核 → 节点 → 协议"的顺序排查,效率最高。

更多具体报错的处理路径,见帮助中心的故障排查分类;本页出现的全部术语在名词速查页可逐条对照。完成选型后,回到教程页按主线完成导入与验证,或直接前往下载页获取客户端。