协议与内核技术参考

A协议演进脉络:三代设计思路

六种协议不是同一时期的产物,各自针对当时最突出的问题做设计。按核心思路可以划成三代,理解这个顺序之后,后面所有的对比都不需要死记——每一代的优点和短板都是设计目标的直接结果。

第一代:极简封装

以 Shadowsocks 为代表。设计目标是"轻":用对称加密直接封装 TCP 流,协议头压到最短,没有握手协商、没有会话管理、没有额外元数据。服务端与客户端只需要约定四个参数(地址、端口、加密方式、密码)就能通信。代价是协议本身不携带身份体系,也没有传输层伪装能力——所有后续需求都要靠外部手段补齐。

第二代:协议内元数据

以 Vmess 为代表。它在协议内部引入了用户 ID(UUID)、时间戳校验、指令字段等结构化元数据,并把"承载方式"抽象成可替换的传输层:同一个 Vmess 节点可以跑在裸 TCP、WebSocket、HTTP/2 或 gRPC 之上,再按需叠加 TLS。灵活性大幅提升,配置项也随之膨胀——一个 Vmess 节点的可配参数是 Shadowsocks 的数倍,排错难度同步上升。

第三代:借壳与换底

第三代分成两条路线。一条是"借壳":Trojan 与 VLESS 不再自己发明加密封装,而是直接把数据放进标准 TLS 会话里,让代理流量在外观上与普通 HTTPS 访问一致,同时省掉一层冗余加密。另一条是"换底":Hysteria2 与 TUIC 放弃 TCP,基于 QUIC(UDP)重建传输层,主攻高延迟、高丢包链路上的吞吐与握手速度。两条路线解决的问题不同,不存在替代关系。

一句话总结:没有全能协议,只有目标不同的取舍。第一代赢在简单省资源,第二代赢在灵活,第三代借壳路线赢在流量特征干净,换底路线赢在弱网表现。选型就是把你的使用场景对准其中一个目标。

B六种协议逐项拆解

本章按协议逐个说明设计要点、关键参数与适用边界。所有参数名以 Clash 系配置文件(YAML)中的字段为准,示例值均为占位,不可直接连接。

Shadowsocks(SS)

最精简的一种。现行实现统一使用 AEAD 加密套件(常见为 aes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305),同时保证机密性与完整性校验。参数只有服务器地址、端口、加密方式、密码四项,几乎不存在配置出错的空间。CPU 与内存开销在六种协议中最低,老旧设备与嵌入式环境友好。短板同样明确:流量虽然加密,但不做任何协议伪装;协议本身也不含多路复用,每个连接独立建立。配置片段如下:

proxies:
  - name: "ss-example"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"

Vmess

V2Ray 生态的核心协议。身份认证基于 UUID,早期版本还要求客户端与服务端时间偏差不超过约 90 秒,时间不同步是 Vmess 节点连不上的经典原因之一;alterId 是旧版遗留字段,现行 AEAD 认证方式下应设为 0。Vmess 的真正价值在传输层组合:network 字段可选 tcp / ws / h2 / grpc,再通过 tls: true 叠加外层加密。其中 WebSocket + TLS 是使用最广的组合,因为它可以挂在标准 Web 服务器后面复用 443 端口。参数多意味着排错点多:路径(ws-opts.path)、Host 头、SNI 任何一项与服务端不一致都会导致握手失败。

Trojan

"借壳"路线的直接体现。Trojan 不发明自己的加密,整个会话就是一条真实的 TLS 连接,服务端持有有效证书,认证只靠一个密码哈希。未通过认证的访问会被回落(fallback)到一个真实网站,因此从外部观测,Trojan 服务端与普通 HTTPS 站点行为一致。客户端参数极少:地址、端口、密码、SNI。需要注意 skip-cert-verify 字段——它会跳过证书校验,仅用于自签证书的测试环境。

VLESS

可以理解为"去掉内层加密的 Vmess":既然外层已经有 TLS,协议内部就不再重复加密,只保留 UUID 认证与极简协议头,省掉一轮加解密的 CPU 开销。VLESS 必须与 TLS 类传输配合使用,不能裸跑。其 flow 字段(如 xtls-rprx-vision)进一步优化了 TLS 套 TLS 场景下的冗余加密问题,是目前低开销方向上的主流方案之一。关键限制:VLESS 不在原版 Clash 内核的支持范围内,只有 mihomo(Clash Meta)系内核可以解析,详见 E 章。

Hysteria2

"换底"路线代表。基于 QUIC 构建,认证只需一个密码,配置复杂度接近 Shadowsocks。它的核心差异在拥塞控制:不依赖传统 TCP 的丢包退让策略,而是按照配置或探测得到的带宽持续发送,在高丢包、高延迟链路上能维持远高于 TCP 系协议的实际吞吐。代价是对链路带宽的占用较为激进,且部分网络环境对 UDP 流量有限速或丢弃策略,遇到这类网络时表现会明显劣化。配置片段:

proxies:
  - name: "hy2-example"
    type: hysteria2
    server: node.example.com
    port: 443
    password: "your-password"
    sni: node.example.com

TUIC

同样基于 QUIC,但设计目标偏向"低延迟"而不是"高吞吐"。TUIC 利用 QUIC 的 0-RTT 能力,重复连接可以在首个数据包就携带请求,握手延迟接近零;对 UDP 流量提供原生转发模式(udp-relay-mode: native),适合游戏、实时语音这类对时延抖动敏感的应用。与 Hysteria2 一样依赖 UDP 通路,在限制 UDP 的网络里同样受影响。支持范围也限于 mihomo 系内核。

快速识别订阅里的协议

拿到一份 YAML 订阅后,用文本编辑器搜索 type: 字段就能清点其中包含的协议类型:ss、vmess、trojan、vless、hysteria2、tuic 分别对应本章的六种协议。分享链接形态的订阅则看 URI 前缀,例如 ss:// 开头是 Shadowsocks,vmess:// 开头是 Vmess。清点结果直接决定客户端内核的最低要求:只要出现后三种中的任意一种,就必须使用 mihomo 系客户端加载。这个两分钟的检查动作,可以在导入之前就避开绝大多数"节点消失""解析失败"类问题,也能帮你判断服务商提供的入口类型是否覆盖了你的使用场景。

C连接速度与吞吐对比

"哪个协议快"要拆成三个独立指标看:握手延迟(新建连接要几个来回)、稳定吞吐(带宽能跑多满)、弱网退化(丢包时掉多少)。三个指标的排名并不一致。

握手延迟

TCP 系协议(SS、Vmess、Trojan、VLESS)新建一条连接至少需要一次 TCP 握手;叠加 TLS 1.3 后再加一个往返,合计约 2 个 RTT。QUIC 系协议(Hysteria2、TUIC)把传输握手与加密握手合并,首次连接约 1 个 RTT,复用会话时 TUIC 可做到 0-RTT。对网页浏览这种"大量短连接"的负载,握手差异直接体现在页面首字节时间上。

稳定吞吐

链路质量良好时,六种协议的吞吐差距很小,瓶颈通常在节点带宽而非协议本身。协议侧的可感差异有两处:一是加密开销——支持硬件 AES 指令的设备上 aes-*-gcm 几乎免费,VLESS 的 vision 流控还能省掉冗余加密;二是队头阻塞——在 TCP 上做多路复用时,一个丢包会阻塞同连接内的全部流,QUIC 的流之间相互独立,不存在这个问题。

弱网退化

高丢包环境是 QUIC 系协议的主场。TCP 的拥塞控制把丢包解释为拥塞并大幅降速,跨洋高延迟链路上尤其明显;Hysteria2 的带宽驱动策略在同等丢包率下能维持成倍的有效吞吐。反过来,在 UDP 被限速的网络里,TCP 系协议反而更稳。

补充一点:客户端节点列表里的"延迟"数字是对测速地址发起一次 HTTP 请求的总耗时,反映的是当前链路状态,不是协议优劣。同一节点不同时段测出的延迟波动,与协议类型基本无关。延迟数字异常时的排查思路见博客《Clash 节点超时无法连接的排查顺序》。

自行验证的简单方法

对比协议表现不必依赖他人的评测结论,自己动手更可靠:在同一个落地节点、同一时段分别切换不同协议入口,先用客户端自带的延迟测试记录握手耗时,再打开同一个测速网站记录下行带宽,最后在晚高峰时段重复一轮,把三组数据放在一起,就能看出你所在链路上各协议的真实差距。测试时注意每次只改变"协议"这一个变量,不要同时更换节点、运行模式或分流规则,否则结果之间没有可比性;每组至少测三次取中位数,排除偶发抖动的干扰。

D资源占用与移动端电量表现

桌面设备上六种协议的资源差异几乎无感,但在手机上,协议与运行模式的选择会直接反映在电量统计里。影响电量的因素按权重排序:运行模式 > 保活策略 > 加密开销。

CPU 与加密开销

现代手机 SoC 普遍带 AES 硬件指令,aes-128-gcm / aes-256-gcm 的加解密成本极低;chacha20-ietf-poly1305 面向无 AES 指令的老设备设计,新设备上反而略慢。VLESS 因为去掉了内层加密,单位流量的 CPU 消耗是六者中最低的。QUIC 系协议的协议栈运行在用户态,大流量场景(长时间高清视频、大文件传输)下 CPU 占用会明显高于 TCP 系,这部分开销在手机上会转化为发热与耗电。

连接保活与后台行为

移动网络下,长连接需要周期性心跳维持 NAT 映射,每次心跳都会短暂唤醒基带。TCP 系协议依赖系统协议栈保活,行为较为节制;QUIC 连接的保活由应用层负责,不同实现的心跳间隔差异较大。日常挂后台、流量以即时消息为主的场景,SS / Trojan 这类"安静"的协议电量表现通常更好;Hysteria2 / TUIC 更适合前台重度使用时段。

运行模式的影响

比协议选择影响更大的是运行模式:系统代理模式只处理走代理设置的应用流量;TUN 模式接管全部系统流量,所有数据包都经过客户端进程,常驻 CPU 占用与内存占用都更高。iOS 平台还有额外约束——网络扩展进程有严格的内存上限,规则集与订阅体积过大时可能触发扩展进程重启。移动端如果不需要接管特定应用,优先使用系统代理模式即可。

E内核家族:原版、Premium 与 mihomo

"Clash"这个词实际指向一个内核家族,不同客户端内置的内核不同,直接决定了它能识别哪些协议。选客户端之前先分清内核,能避开大量"订阅导入后节点消失"的问题。

三条分支的关系

原版 Clash 内核是这一切的起点:Go 语言编写、开源,确立了 YAML 配置格式、策略组与规则分流的基本模型,支持 SS、Vmess、Trojan 等当时的主流协议,目前仓库已经归档,不再更新。Premium 是原作者在原版基础上发布的闭源构建,主要补充了 TUN 模式与更强的规则能力,同样已停止演进。Clash Meta 是社区在原版归档前后接续维护的分支,后更名为 mihomo——它是当前唯一持续活跃的分支,新增协议支持全部发生在这条线上。

功能差异对照

客户端与内核的对应

客户端是内核外面的图形界面壳,内核决定协议能力,壳决定操作体验。当前活跃的客户端——Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android——均基于 mihomo 内核,六种协议全部可用;而 Clash for Windows、ClashX Meta 等已停止维护的客户端停留在旧内核或旧版本上,不建议用于包含新协议的订阅。各客户端的详细取舍见横向评测,安装包统一从客户端下载页获取。mihomo 与原版内核的完整差异分析,可读博客《mihomo 内核与原版 Clash 内核区别详解》。

F配置与订阅格式兼容性

协议与内核的选择最终都落到一个问题上:手里这份订阅,在这个客户端里能不能完整加载。本章说明订阅的常见形态与跨内核迁移时的兼容要点。

订阅的三种形态

一是 Clash YAML 订阅:一份完整配置文件,包含 proxies、proxy-groups、rules 三大段,Clash 系客户端可直接导入,这是最推荐的形态。二是分享链接集合:以 ss://、vmess:// 等 URI 组成的 Base64 文本,面向多种客户端通用,Clash 系客户端导入时由客户端或转换服务翻译成 YAML。三是多格式端点:同一订阅地址根据请求方的 User-Agent 返回不同格式,服务商侧较常见。无论哪种形态,导入步骤见教程页第一步。

跨内核迁移要点

从旧内核迁到 mihomo,绝大多数字段原样兼容,YAML 不需要重写。反方向则不成立:配置里只要包含旧内核不认识的 type(如 vless、hysteria2、tuic),旧内核会在解析阶段报错,整份配置加载失败,表现为"订阅更新后所有节点消失"。这也是从 Clash for Windows 迁移到现役客户端的最常见动因之一。若订阅通过 proxy-providers 引用外部节点列表,同样遵循这个规则:

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

常见加载失败原因

订阅拉取正常但节点异常时,按顺序检查三点:第一,客户端内核是否支持订阅内全部协议类型(用文本编辑器打开订阅,搜索 type: 字段核对);第二,YAML 缩进是否被二次编辑破坏——YAML 对缩进敏感,多一个空格即解析失败;第三,proxy-groups 引用的节点名是否与 proxies 内的 name 完全一致,包含空格与表情符号在内。订阅本身拉取失败(超时、403 等)的处理见常见问题的故障排查分类。

G按使用场景的协议选型建议

前面几章的结论在这里收拢成可直接执行的选型表。前提是订阅里同一落地提供多种协议入口——多数服务商如此;若订阅只有单一协议,本章可作为与服务商沟通或更换套餐的参考。

日常网页浏览与办公

负载特征是大量短连接、单连接数据量小。Trojan 或 VLESS 是均衡选择:握手开销可接受、流量特征干净、CPU 占用低。SS 同样完全够用,且参数最少、最不容易配错。这个场景下协议差异的体感接近于零,不必纠结。

高清流媒体与大文件

负载特征是长连接、高持续吞吐。链路质量好时任何协议都能跑满;跨洋高延迟或晚高峰丢包明显时,Hysteria2 的优势最大,同等链路下有效吞吐通常显著高于 TCP 系协议。注意确认所在网络未对 UDP 限速,否则退回 Trojan / VLESS。

移动网络通勤

蜂窝网络信号波动大、基站切换频繁,连接重建是常态。QUIC 系协议的连接迁移与低握手成本在这里价值最大:TUIC 的 0-RTT 让断网恢复几乎无感。若以省电为优先,参考 D 章的结论,待机时段用 SS / Trojan,重度使用时段再切换。

游戏与实时会议

核心指标是时延抖动而非带宽,且流量以 UDP 为主。TUIC 的原生 UDP 转发是首选;Hysteria2 次之。TCP 系协议转发 UDP 需要额外封装,抖动表现普遍更差。客户端侧建议配合 TUN 模式,确保游戏进程的 UDP 流量被接管。

服务器与路由器常驻

无界面环境直接运行 mihomo 内核,协议选择以稳定优先:SS 或 Trojan 的长期稳定性与低资源占用最适合 7×24 常驻;内核安装包见下载页的内核区。软路由等 ARM 设备注意选择对应架构的构建。

H常见误区与排错入口

误区一:协议越新越快

协议决定的是特定条件下的行为差异,不是绝对速度。链路质量好时六种协议吞吐几乎一致;Hysteria2 在优质链路上不会比 SS 快,在 UDP 受限的网络里反而更慢。先确认瓶颈在哪(节点带宽、本地网络、还是协议与网络的匹配度),再谈换协议。

误区二:延迟数字低等于体验好

节点列表的延迟测的是一次 HTTP 往返,与持续吞吐、丢包率没有直接关系。50ms 但晚高峰丢包严重的节点,实际体验可能远差于 180ms 但链路干净的节点。判断节点质量应结合实际使用中的加载速度与稳定性,而不是只看测速数字。

误区三:全局模式更稳

全局模式只是把所有流量都送进代理,不解决任何连接层问题,反而会让本应直连的流量绕路,放大节点故障的影响面。规则模式配合合理的分流规则才是常态用法,全局模式适合临时排查"是不是规则没命中"这一类问题:切到全局后现象消失,说明是分流规则漏配;现象依旧,则问题出在节点或链路本身,应回到连接层继续排查。

误区四:加密层数越多越安全

VLESS 去掉内层加密不是削弱安全性——外层 TLS 1.3 已经提供完整的机密性与完整性保障,叠加第二层对称加密只增加 CPU 开销,不增加防护。安全性的关键在证书校验是否开启、密码强度是否足够,而不在加密层数。

误区五:换协议能解决一切连接问题

协议只是链路中的一环。订阅过期、本地防火墙拦截、系统时间偏差、DNS 解析被污染、节点服务端故障,这些问题换任何协议都不会消失。正确的排查顺序是先确认订阅有效、再确认本地网络与系统设置正常、最后才考虑协议与网络环境的匹配问题。把"换协议"当成第一反应,往往只是把真正的故障原因往后拖。遇到连不上的情况,建议按固定顺序逐层排除:先看客户端日志有没有明确报错,再用浏览器直接访问测速地址验证直连是否正常,最后切换节点与协议做交叉对比,定位问题出在本地、链路还是服务端。

排错入口索引

• 订阅更新失败、开机自启、模式切换等高频问题:常见问题按分类整理了标准处理步骤。
• 节点全部超时或部分超时:按博客《节点超时无法连接的排查顺序》给出的固定顺序逐层检查。
• 看不懂客户端日志里的报错:参考《Clash 运行日志怎么看》逐条对照报错含义。
• 正文出现的名词(AEAD、SNI、RTT、TUN 等)释义:查术语手册对应分类。