Clash 协议详解:六类代理协议与 mihomo 内核的选型参考

R-01客户端、内核、协议:先分清三层

客户端只是外壳

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu——这些名字指的都是图形界面客户端。客户端负责呈现节点列表、切换代理模式、管理系统代理开关,本身不建立任何代理连接。界面差异只影响操作体验,不影响链路的实际行为。同一份订阅在两个客户端里导入,节点列表、延迟测速、分流结果应当一致;如果不一致,问题多半出在设置,而不是客户端之间的差别。

内核是引擎

真正与远端服务器通信的是内核:一个随客户端启动的后台进程。目前下载页列出的在维护客户端几乎全部内置 mihomo 内核(原名 Clash Meta)。同一套节点配置在不同客户端里,只要内核版本接近,连接行为、协议支持范围、规则执行结果都基本一致。因此「选协议」本质上是「在内核支持的协议列表里选」,而不是在客户端界面里选。想确认手头客户端的内核,打开设置或关于页,内核名称与版本号都会标注——看到 mihomo 或 Clash Meta 字样,即说明协议支持范围以本页 R-08 章为准。

协议是封装约定

节点信息里标注的 SS、VMess、Trojan、VLESS、Hysteria2、TUIC,就是协议类型。协议规定三件事:数据如何封装、用什么方式加密、走 TCP 还是 UDP。订阅导入后,客户端把每个节点解析成内核配置里的一项 proxy,内核按协议字段与服务器握手并转发流量。协议选择只影响「客户端到节点」这一段;节点到目标网站的最后一段由服务器侧决定,客户端无从干预。

本页与教程页的分工至此明确:quickstart.html 是「跟着做就能连上」的主线流程,本页是「查得到、看得懂」的参考手册。遇到不认识的配置字段,先查术语表,再回本页对应章节细看。

R-02代理协议的演进脉络

通用代理:SOCKS5 与 HTTP

最早的代理协议是通用的。SOCKS5 只负责转发,不加密、不校验内容,常用于本机或局域网环境;HTTP 代理同理,主要服务浏览器。两者至今保留在 Clash 系配置里,但角色是入站——本机应用连到客户端监听的端口——而不是出站连远端服务器。配置里的 mixed-port 就是同时提供 SOCKS5 与 HTTP 两种入站的混合端口,allow-lan 控制是否允许局域网设备接入。

# 本机入站设置(应用连客户端用,不是节点配置)
mixed-port: 7890
allow-lan: false
mode: rule

专用协议的三次转向

面向远端服务器的专用代理协议,大致经历三次设计转向。第一次,Shadowsocks 确立「轻量加密流」思路:只加密负载,不加多余结构,四项参数即可运行。第二次,VMess 走「功能优先」:时间戳校验、多传输层、协议内加密全部纳入,能力变强,结构也变重。第三次,路线一分为二:Trojan 与 VLESS 把加密交给 TLS,让流量在外形上接近普通 HTTPS;Hysteria2 与 TUIC 改用 UDP 之上的 QUIC,换取弱网吞吐与切换网络时的连接保持。

六种并存的现状

今天订阅里最常见的仍是六类:SS、VMess、Trojan、VLESS、Hysteria2、TUIC。没有哪一种在所有维度上领先:开销小的特征相对明显,仿真强的依赖域名与证书,速度激进的依赖 UDP 环境。协议之间是取舍关系,不是替代关系——这正是需要一份选型参考的原因。

R-03Shadowsocks(SS):轻量加密流

诞生背景与设计目标

SS 于 2012 年前后发布,设计目标极其克制:在 SOCKS5 的转发框架上加一层流加密,让传输中的数据不可读,除此之外不加任何结构。一个 SS 节点只需要四项信息:服务器地址、端口、密码、加密方式。实现一个可用的 SS 客户端只需几百行代码,这是它迅速普及、并被几乎所有内核与客户端支持的直接原因。

AEAD 加密与现行用法

早期 SS 使用流密码(如 aes-256-cfb),后被证实存在可主动探测的弱点,社区遂引入 AEAD(带关联数据的认证加密)。目前常见的三种算法:aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305。桌面 CPU 大多带 AES 硬件指令集,两种 AES-GCM 几乎零成本;多数手机 SoC 没有对应指令集,chacha20-ietf-poly1305 在移动端更快也更省电。SS 还支持 UDP 转发(配置里的 udp 字段),但依赖服务端同步开启。

proxies:
  - name: "示例节点-SS"
    type: ss
    server: example.com
    port: 8388
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

适用与局限

SS 的优点集中在工程层面:协议开销在六类中最小,实现成熟,全内核支持,移动端电量表现最好。局限同样明确:协议没有内置伪装层,流量特征相对固定;它只定义加密,不处理身份与证书,服务端真实性依赖部署者。作为日常通用协议,SS 至今仍是稳妥的默认选项,也是旧设备与路由器上的首选。

插件与混淆的可选扩展

SS 本身不带伪装,但社区为它设计了插件机制,在加密流之外再套一层外形。最典型的是 obfs(简单混淆)与 v2ray-plugin(WebSocket 伪装):前者把流量整形为无特征随机字节,后者把 SS 负载装进 WebSocket 帧,可配合 CDN 中转。配置里通过 plugin 与 plugin-opts 字段启用。需要理解的是,插件是 SS 的可选外挂,不是协议本体——同一节点带不带插件,对客户端是两种不同配置;订阅里若标注了插件,客户端必须支持对应插件才能连接。mihomo 对主流 SS 插件支持完整,但插件会增加一层封装开销,移动端电量表现会略逊于裸 SS。日常使用中,若网络环境对 SS 没有针对性限制,裸 SS 加 AEAD 加密已足够,不必为「看起来更隐蔽」而叠加插件。

R-04VMess:功能优先的一体化设计

设计背景

VMess 是 V2Ray 项目的原生协议,设计思路与 SS 相反:把身份验证、时间校验、加密与传输伪装全部纳入协议本身。每个请求携带时间戳,与服务器时间偏差过大的请求直接拒绝,从协议层面防重放;UUID 作为用户标识,一个服务端可承载多个独立用户并分别统计。

传输层与结构开销

VMess 支持 TCP、WebSocket、gRPC 等多种传输层。WebSocket 形态可以把代理流量套在普通 Web 服务的结构里,配合 CDN 中转是常见用法;gRPC 形态则借用 HTTP/2 的多路复用。功能完整的代价是结构复杂:握手流程长,首部开销在六类协议中最大,实现难度高。另外 VMess 自带加密,若再叠加 TLS 会形成双重加密,CPU 占用明显上升而安全收益有限。

现状

VMess 在存量订阅中仍然常见,mihomo 完整支持其各传输层形态。新部署的服务端更多转向结构更轻的 VLESS,VMess 逐步退居旧配置。客户端侧无需刻意回避:节点能连、测速达标即可,协议新旧不构成更换理由。手动维护配置时留意 alterId 字段——新版服务端与内核已将其固定为 0,旧教程里的非零写法不再适用。

proxies:
  - name: "示例节点-VMess"
    type: vmess
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    network: ws
    ws-opts:
      path: /ray

R-05Trojan 与 VLESS:TLS 仿真路线

共同思路:不再自己设计加密

Trojan 与 VLESS 属于同一条路线:协议层不实现加密,直接借用 TLS——即 HTTPS 使用的安全层。服务器持有真实域名与有效证书,客户端与服务器建立的是一条标准 TLS 连接,握手、加密、证书校验全部沿用成熟实现,从外部观察与访问一个 HTTPS 站点基本一致。mihomo 还支持 client-fingerprint 字段(如 chrome),用 uTLS 模拟指定浏览器的 TLS 指纹,让握手特征与真实浏览器更接近。

Trojan:极简结构

Trojan 的设计近乎「没有协议」:TLS 握手完成后,客户端在会话内发送密码的散列值完成身份校验,之后的数据原样转发。协议自身结构越少,行为越接近正常 HTTPS,开销也越小。配置只需要域名、端口、密码三项,sni 字段通常与域名一致。

VLESS:把 VMess 减重

VLESS 是 VMess 的简化重写:去掉协议层加密与时间戳,只保留 UUID 身份标识,加密完全交给外层 TLS。结构比 VMess 轻得多,首部开销与 Trojan 同档;配合 XTLS 一类的传输优化时,数据在内核与 TLS 库之间少一次拷贝,高带宽场景吞吐更好。需要强调:VLESS 必须搭配 TLS 使用,明文形态的 VLESS 没有意义,也不应出现在正常订阅里。

共同前提:域名与证书

TLS 路线依赖真实域名与有效证书,这决定了它多由自建或管理较规范的服务端采用。客户端侧的注意点只有一个:节点里的 sni(或 servername)字段必须与证书域名一致,不一致握手即失败。通过订阅导入的节点这一字段已写好,手动添加或修改节点时才需要留意。

proxies:
  - name: "示例节点-Trojan"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    udp: true
  - name: "示例节点-VLESS"
    type: vless
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    tls: true
    servername: example.com
    client-fingerprint: chrome

R-06Hysteria2 与 TUIC:QUIC 上的 UDP 路线

QUIC 带来的变化

QUIC 是建立在 UDP 之上的现代传输协议,也是 HTTP/3 的底座。它把加密、拥塞控制、多路复用整合进传输层:握手通常一个往返完成,支持 0-RTT 会话恢复;连接以连接标识维系,而不是源地址四元组,因此 Wi-Fi 切到蜂窝网络时会话可以继续,不必重建。Hysteria2 与 TUIC 都以 QUIC 为底座,但取舍方向不同。

Hysteria2:主动占带宽的拥塞控制

Hysteria2 的核心是名为 Brutal 的自定义拥塞控制:不按传统方式探测可用带宽,而是按设定的目标带宽主动发包。在高丢包、高延迟线路上,这种策略能跑出明显高于任何 TCP 协议的吞吐——TCP 类协议遇到丢包会指数级退让,Brutal 不退让。代价同样清楚:发包激进,对服务端带宽有硬性要求;配置里的 up 与 down 值必须接近真实链路,虚高或虚低都会拉低实际速度。协议还支持端口跳跃(在端口区间内轮换),用于规避单端口限速,mihomo 以 ports 字段配置。

TUIC:多路复用与低延迟

TUIC 的设计目标是低延迟与低开销:把多条 TCP 连接复用在一条 QUIC 会话里,应用每开一个新连接不必重新握手;原生支持 UDP 中继,游戏、语音这类延迟敏感流量受益直接。拥塞控制沿用 QUIC 标准算法族,行为比 Hysteria2 温和,对线路的侵入性小,也更适合带宽不大的服务端。

UDP 路线的边界

两类协议都依赖 UDP 可达。部分网络环境对 UDP 限速甚至完全阻断,此时它们会直接不可用或速度骤降,客户端无法绕开这一限制,只能换回 TCP 类协议。另一点是资源:QUIC 的加密、重传、拥塞控制全部在用户态完成,CPU 占用高于纯 TCP 协议,长时间大流量下载时,移动端的发热与耗电差异可以感知。

如何判断所在网络是否适合 UDP 协议

最可靠的方法是实测而非猜测。先把节点切换到 Hysteria2 或 TUIC,打开一个视频或跑一次下载,观察速度是否达到预期、连接是否稳定;再换到 Trojan 或 SS 重复一次。若 UDP 协议明显更快且不掉线,说明所在网络对 UDP 宽松,可以把它设为默认;若 UDP 协议时快时慢、频繁中断,或干脆连不上,说明网络对 UDP 不友好,应回到 TCP 类协议。企业内网、校园网、部分公共 Wi-Fi 是 UDP 受限的高发场景;家庭宽带与主流蜂窝网络通常宽松。还有一点容易被忽略:某些网络对 UDP 的限速是分时段的——晚高峰收紧、凌晨放开,因此单次测速结论不必当成永久结论,发现默认协议突然变慢时,先怀疑网络策略变化,再怀疑节点本身。

proxies:
  - name: "示例节点-Hysteria2"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    up: 50
    down: 200
  - name: "示例节点-TUIC"
    type: tuic
    server: example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    password: "your-password"
    alpn: [h3]

R-07横向对比:速度、资源与电量

连接建立

TCP 类协议(SS、VMess、Trojan、VLESS)先完成 TCP 握手,带 TLS 的再加一个 TLS 握手,首次建立通常一到三个往返。QUIC 类把传输与加密握手合并,通常一个往返,会话恢复可 0-RTT。日常浏览感知差别不大;短连接密集的场景——信息流刷新、API 请求频繁的应用——QUIC 类更占优。

吞吐与开销

协议首部开销从小到大大致为:SS < Trojan ≈ VLESS < VMess;QUIC 类首部不算小,但多路复用摊薄了握手成本,实际吞吐更多取决于拥塞控制策略。同一线路下:稳定低丢包时,SS、Trojan、VLESS 互差距不大;高丢包时 Hysteria2 吞吐最高,TUIC 次之,TCP 类协议整体退让明显。

CPU 与内存

桌面端(Windows、macOS、Linux)上,六类协议的 CPU 占用都在可忽略范围,选型不必以性能为依据。移动端不同:手机 SoC 的小核跑 AES 与 ChaCha20 的能效差异明显;QUIC 的用户态重传与拥塞控制会持续占用 CPU。内存方面各协议差异不大,内核整体占用主要取决于规则数量与活动连接数,与协议类型关系不大。

移动端电量

同等流量下的相对耗电,从省到费大致为:SS(chacha20-ietf-poly1305)< Trojan ≈ VLESS < VMess < TUIC < Hysteria2。以推送、即时通讯为主的挂后台用法,各类协议差异不大;持续视频播放或大文件下载时,差异开始可感知。iOS 的 Clash Plus 与 Android 各客户端使用同一 mihomo 内核,上述结论跨平台一致;iOS 端的获取与配置流程见技术笔记(iPhone 上怎么用 Clash)。

测速的正确姿势

选型前建议按统一口径测速:同一时段、同一目标、同一设备。客户端测速得到的是延迟,反映握手与往返成本;吞吐要用实际下载验证。单连接下载受协议开销影响大,多连接下载受拥塞控制影响大——两个数字都看一眼,比只看延迟可靠。

延迟低不等于速度快

这是选型时最容易混淆的一对指标。延迟(客户端测速显示的数字)衡量的是「一个数据包往返要多久」,主要决定网页打开、操作响应的快慢;吞吐衡量的是「单位时间能传多少数据」,主要决定下载、看高清视频的流畅度。一个节点可以延迟很低但吞吐有限——比如距离近但带宽小;也可以延迟偏高但吞吐充足——比如跨洲但线路质量好。日常刷网页、用社交应用,低延迟体验更好;看 4K 视频、下大文件,高吞吐更关键。因此选型时先想清楚自己的主要用途:以交互式操作为主,优先看延迟;以大流量传输为主,优先看吞吐。两者都要时,取延迟与吞吐都达标的节点,而不是某一项特别突出、另一项垫底的节点。客户端的测速功能只给延迟,吞吐需要实际下载或在线测速工具验证,这一步不要省。

R-08内核家族:Clash、Clash Meta 与 mihomo

原版 Clash 的历史位置

原版 Clash 内核于 2023 年停止维护,仓库归档。它支持 SS、VMess、Trojan 等早期协议,不认识 VLESS、Hysteria2、TUIC。原版还曾有一个闭源增强版 Clash Premium,提供 TUN 与脚本能力,同样已停止维护。仍在使用 Clash for Windows、ClashX Meta 等停更客户端的用户,实际运行的就是这个时代的内核或其早期分支——现有节点能连,但新协议、新功能不会再有,订阅里的新协议节点会被直接跳过。

Meta 到 mihomo:继承与扩展

Clash Meta 是社区在原版基础上的活跃分支,2023 年底更名为 mihomo。它完整继承原版的 YAML 配置格式,加入 VLESS、Hysteria2、TUIC 支持,并带来 TUN 模式增强、规则提供器(rule-providers)、外部控制器扩展等能力。TUN 模式通过虚拟网卡接管全局流量,原理与开启方法在技术笔记里有专文(Clash TUN 模式是什么)。下载页在维护的客户端——Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu——内置内核均为 mihomo。

配置兼容性

兼容方向是单向的:mihomo 能直接运行原版 Clash 的旧配置;反过来不成立——含新协议节点或新字段(如 rule-providers)的配置,原版内核解析失败。订阅转换工具通常提供「Clash」与「Clash Meta」两种输出:使用 mihomo 客户端时选 Meta 输出;选错为旧格式时,新协议节点会在转换阶段被丢弃,表现为「订阅里明明有的节点,导入后不见了」。

R-09订阅格式与按场景选型

订阅格式的三种形态

订阅链接返回的内容常见三种形态。一是 Base64 节点列表:每行一个 ss:// 或 vmess:// 分享链接,通用性最好,但不带 Clash 的策略组与规则结构,导入后由客户端自行组织。二是 Clash YAML:完整配置,包含 proxies、proxy-groups、rules 三段,导入即用,是 mihomo 客户端的首选形态。三是在线订阅转换的输出:把 Base64 列表转成 Clash YAML,旧订阅也能获得完整结构,但转换服务会接触节点明文,选择时留意其可信度。订阅的获取与导入细节,技术笔记有专文(Clash 订阅链接怎么导入)。

按使用场景选型

• 日常浏览与视频:SS 或 Trojan、VLESS。开销小、电量友好,桌面与手机都适用。
• 高丢包线路:Hysteria2。跨洲链路、晚高峰拥塞时吞吐优势最明显,前提是所在网络不限 UDP。
• 游戏与语音:TUIC 或 Hysteria2。UDP 中继延迟低,同时确认客户端已开启 UDP 转发。
• 频繁切换网络:QUIC 类协议。连接随网络切换保持,通勤场景掉线次数明显减少。
• 旧设备与路由器:SS。CPU 占用最低,实现最成熟,长期运行最稳。

三个常见误区

「协议越新越快」不成立:速度取决于线路质量与拥塞控制,不取决于发布时间,稳定线路上 SS 与最新协议的差距很小。「加密层数越多越安全」不成立:VMess 叠 TLS 这类双重加密只增加 CPU 开销,安全性由最外层决定。「换客户端协议表现就不同」也不成立:同一内核下协议行为一致,客户端只影响操作体验——客户端之间的差异对比见技术笔记的横向对比(主流客户端横向对比)。

多协议混用的实际策略

真实订阅往往同时提供多种协议的节点,这恰恰是优势而非负担。合理的用法是按用途分流,而不是死守单一协议:把延迟敏感、需要 UDP 中继的流量(游戏、语音通话)交给 TUIC 或 Hysteria2 节点;把日常浏览、视频这类以 TCP 为主的流量交给 SS 或 Trojan 节点;把协议最轻、最省电的 SS 留给挂后台的即时通讯与推送。mihomo 的策略组(proxy-groups)正是为此设计——可以建多个策略组,各指定不同协议节点,再用规则(rules)把不同域名或应用导向对应策略组。这样一次配置,各类流量各走最优链路,无需手动切换。对不愿深究规则的普通用户,更简单的等价做法是:日常固定用一个实测最快的协议节点,只在它明显变慢或连不上时,手动切到备选协议的节点。两种思路没有高下之分,取决于愿意在配置上投入多少时间。

收尾:四步选型流程

1. 确认客户端内核是 mihomo(下载页在维护客户端均满足)。
2. 导入订阅,按协议类型浏览节点列表。
3. 在常用网络里对候选协议各测一次速,延迟与吞吐都看。
4. 把实测最好的类型设为策略组默认,其余保留为备用。

协议部分到此为止。剩下的操作——导入订阅、选模式、开系统代理、验证连通——回到使用文档按步骤执行;需要下载客户端,前往下载页;遇到不认识的术语,查术语表。