▶协议详解:六种协议与三代内核的选型参考

协议全景:六种主流协议从哪来、解决什么问题

先记住一条主线:代理协议的演进史,就是一部"在加密、伪装、速度三者之间反复找平衡"的历史。客户端订阅里常见的六种协议——Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC——分属三个世代,每一代都是对上一代短板的直接回应。搞清楚各自的出发点,后面所有对比表都能读得顺。

Shadowsocks:轻量加密的起点

Shadowsocks(常缩写为 SS)是六者中资历最老的一个。设计目标只有一句话:用尽量少的开销给 TCP 流量套一层对称加密。它没有握手协商、没有会话概念,客户端和服务端事先约定同一个密码与加密方法,连接建立后直接传密文。好处立竿见影:实现极简、CPU 占用低、几乎所有平台都有成熟实现;代价同样明显——流量特征相对固定,缺乏元数据层面的伪装能力。后续社区给它补上了 AEAD 加密套件(如 aes-128-gcm、chacha20-ietf-poly1305),把早期流加密的完整性缺陷修掉了,这也是今天配置里推荐只用 AEAD 方法的原因。

VMess 与 VLESS:带会话层的两代协议

VMess 出自 V2Ray 项目,思路比 SS 更进一步:引入用户 ID(UUID)、时间戳校验与动态元数据,每条连接的头部都不一样,并支持挂载 WebSocket、gRPC 等多种传输层。灵活是它的最大卖点,复杂也是它的最大负担——协议头计算量偏大,时间戳机制还要求客户端与服务端时钟偏差不能太大,手机时间不准就连不上是 VMess 的经典故障。VLESS 是同一个社区对 VMess 的"减负版":砍掉内置加密与时间戳校验,把加密职责整体外包给底层 TLS,协议本体只保留身份标识与路由信息。结果是头部更小、转发更快,但它必须搭配 TLS(或 REALITY 这类衍生方案)使用,裸奔的 VLESS 没有任何保密性。

Trojan:把自己藏进 HTTPS 的人流里

Trojan 换了个思考方向:与其发明新的加密格式,不如让代理流量在外观上与普通 HTTPS 完全一致。它直接复用标准 TLS 握手,服务端配真实证书,验证失败的访问会被回落到一个普通网站。对观察者而言,一条 Trojan 连接和一次正常的网页浏览没有可辨识的差别。设计取舍也随之而来:必须有域名和有效证书,部署门槛比 SS 高;所有流量都过一层完整 TLS,单核加解密吞吐会略低于轻量协议,但换来了最稳的"融入背景"能力。

Hysteria2 与 TUIC:QUIC 世代的提速派

前四种协议都跑在 TCP 上,受制于 TCP 的拥塞控制与队头阻塞:丢一个包,整条连接都要等重传。Hysteria2 与 TUIC 把底座换成了基于 UDP 的 QUIC。Hysteria2 的核心是自带激进的拥塞控制策略,专门面向高丢包、高延迟的长距离链路,弱网环境下的吞吐提升非常直观;TUIC 则更"标准派",尽量贴着 QUIC 规范做多路复用与 0-RTT 快速握手,追求低延迟的同时保持协议行为温和。两者共同的软肋:部分网络对 UDP 有限速或拦截策略,遇到这种环境,QUIC 系协议反而不如老实的 TCP 系稳定,所以它们是"备选加速档"而不是无脑默认项。

传输层设计取舍:TCP、TLS 与 QUIC 三条路线

协议对比经常被简化成"哪个快",但决定体验的第一变量其实是传输层路线。把六种协议按底座分成三派,很多现象会瞬间说得通。

TCP 直连派:SS 与轻装 VMess

SS 与不挂 TLS 的 VMess 直接在 TCP 上传输自定义密文。优点:兼容性最好,任何允许 TCP 的网络都能跑;实现轻,老设备、路由器都带得动。缺点:自定义密文本身就是一种特征,且 TCP 队头阻塞在丢包链路上会显著拖慢体感速度——延迟数字可能不难看,但网页加载会一顿一顿,这正是延迟测试数字怎么看一文里拆解过的"数字好看体验差"的典型来源之一。

TLS 封装派:Trojan、VLESS 与挂 WS 的 VMess

这一派把流量放进标准 TLS 会话。外观与普通 HTTPS 一致,穿透各类中间设备的成功率最高;配合 CDN 中转(常见于 VMess/VLESS + WebSocket 组合)还能隐藏服务器真实地址。代价是握手轮次多:TCP 三次握手加 TLS 握手,首包延迟天然比直连派高一截;每字节都要过一次 TLS 加解密,吞吐上限受 CPU 单核性能影响明显。

QUIC 派:Hysteria2 与 TUIC

QUIC 把加密握手与传输握手合并,理想情况下一个往返即可建联,支持 0-RTT 时甚至更快;流级多路复用彻底绕开队头阻塞,单条丢包只影响单条流。移动网络切换(Wi-Fi 换 5G)时,QUIC 的连接迁移能力也让重连更平滑。短板前文说过:UDP 在部分网络里是"二等公民",被限速时表现会断崖式下滑。

连接速度与资源占用:数字背后的规律

先给结论:同一台服务器、同一条线路下,六种协议的"极限带宽"差距通常小于线路本身波动;真正拉开体感差距的是首包延迟、丢包恢复与 CPU 瓶颈三件事。逐项看。

首包延迟:握手轮次决定下限

打开一个新网站,客户端要先与代理服务器建联。SS 只需 TCP 三次握手即可发数据,轮次最少;Trojan/VLESS 要在 TCP 之上再完成 TLS 握手,多出一至两个往返;Hysteria2/TUIC 靠 QUIC 把两步合一,长距离链路上优势明显,TUIC 的 0-RTT 在重复访问同一服务器时可以做到"发出即带数据"。链路延迟 50ms 时这些差距感知不强;延迟 200ms 以上时,每省一个往返都是肉眼可见的提速。

吞吐与 CPU:加密路径的账

满速下载时,瓶颈常常不是线路而是加解密。SS 配 AEAD 套件的单位字节开销最低,老旧路由器也能接近线速;Trojan/VLESS 的 TLS 路径在支持 AES-NI 指令集的现代 CPU 上开销可控,但在低端 ARM 设备上会先于带宽到顶;QUIC 系协议目前多在用户态实现,同吞吐下 CPU 占用普遍高于内核态优化成熟的 TCP 栈,这是"Hysteria2 跑分快但风扇也快"的原因。桌面平台一般无感,软路由和电视盒子上要认真对待。

丢包恢复:弱网下的分水岭

丢包率超过 1% 的链路上,TCP 系协议的吞吐会被拥塞算法压得很低,而且所有复用同一条连接的请求一起卡;Hysteria2 的激进补偿策略在这种环境下常能把可用带宽拉回数倍,TUIC 的流隔离也能保证"一个请求卡住不连累其他"。反过来,在低丢包的优质链路上,三派的实际速度差可以忽略,此时选协议应该看伪装与兼容性而非跑分。

移动端电量表现:协议如何影响续航

手机上挂客户端整夜掉电,协议选择是变量之一,但通常不是最大的那一个。这一章把"协议相关"的耗电因素单独拎出来讲清楚,系统层面的排查(省电白名单、后台策略、探测间隔)参见博客的Android 耗电排查清单。

无线电唤醒:小包频率是隐形大户

移动芯片的基带有"睡眠—唤醒"状态机,每次收发数据都可能把基带从低功耗态拉起来,拉起来之后还要保持一段高功耗驻留。因此耗电与流量总量关系不大,与"多久来一个包"关系极大。协议或其上层实现的心跳、保活、探测越频繁,基带越难睡,整夜待机掉电就越多。

三派协议的耗电画像

TCP 系协议自身没有强制心跳,连接静默时几乎不产生额外唤醒,待机友好;需要注意的是挂 WebSocket 的 VMess/VLESS,部分服务端会配置周期性 ping 帧,间隔过短就是标准的"电量刺客"。QUIC 系协议为了维持 NAT 映射与连接迁移能力,通常带有内建的保活探测,静默状态下的唤醒次数天然多于 TCP 系;换来的好处是网络切换时不必推倒重连——频繁在 Wi-Fi 与蜂窝之间切换的通勤场景里,一次完整重连(重新握手、重新探测节点)的耗电可能比多几次保活更高。所以结论不是一边倒:重度移动切换用户选 QUIC 系反而可能更省,长时间驻留单一网络的用户选 TCP 系更稳。

可操作的省电原则

• 待机为主的设备:优先 SS 或 Trojan,避开心跳间隔激进的 WebSocket 配置。
• 通勤高频切网:可试 TUIC 或 Hysteria2,利用连接迁移减少重握手。
• 无论哪种协议:把策略组的自动测速间隔调大到十分钟以上,探测本身也是唤醒源。
• TUN 模式常驻会接管全局流量,耗电高于仅代理部分应用属正常现象,按需开启。

内核家族:原版、Meta 与 mihomo 是什么关系

先把一句话钉死:这三个名字不是三个竞争产品,而是同一条演进线上的三个阶段。理清家族关系,客户端选择与配置兼容性问题会少一大半。更完整的时间线梳理见博客的内核区别对照一文。

原版内核:规则分流范式的奠基者

最初的 Clash 内核确立了今天所有衍生品沿用的骨架:YAML 配置、proxies 节点列表、proxy-groups 策略组、rules 规则段,以及"按域名与 IP 规则决定流量去向"的分流范式。它原生支持 SS、VMess、Trojan 等当时的主流协议,但对后来出现的 VLESS、Hysteria2、TUIC 没有支持。原始仓库已经停止更新,原版内核如今属于"历史阶段",不建议新用户再围绕它搭建环境。

Meta 分支:社区接棒的功能扩展版

原版活跃期间,社区维护的 Clash.Meta 分支就在并行推进:补齐新协议支持(VLESS、Hysteria 系、TUIC)、增强 TUN 模式、扩展 DNS 与嗅探能力、引入 sub-rules 等更灵活的规则写法。它保持对原版配置的向下兼容——老配置文件基本可以直接喂给 Meta 内核运行,反过来则不行:用了 Meta 扩展字段的配置在原版内核上会报"unsupported"类错误。

mihomo:同一内核的现用名

原版仓库归档后,Meta 分支改名为 mihomo 并延续开发至今。**mihomo 就是 Clash.Meta 的现用名,二者是同一个项目**,配置格式、命令行行为、API 全部延续。今天主流客户端——下载页首推的 Clash Plus,以及 Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android 等——底层内核均为 mihomo 或其衍生。选客户端时看到"基于 mihomo/Meta 内核"字样,即代表六种协议与 TUN、嗅探等能力都在支持范围内。

配置字段与内核兼容性:哪些写法只有新内核认

拿到订阅或手写配置时,最常见的翻车点是"字段与内核不匹配"。这一章按字段层级过一遍兼容性边界,配置文件的整体结构逐段精读请移步配置文件结构解析。

全内核通用的骨架字段

port、socks-port、mixed-port、allow-lan、mode、log-level、external-controller 这些顶层字段从原版时代沿用至今,任何内核都认。proxies 里 SS、VMess、Trojan 三类节点的基础写法同样通用。只用这些字段的配置,拿到任何客户端都能跑。

仅 Meta/mihomo 支持的扩展字段

以下写法出现任意一个,配置就只能在 Meta/mihomo 系内核上运行:type 为 vless、hysteria2、tuic 的节点;tun 段的完整配置(含 stack、auto-route、dns-hijack);sniffer 嗅探段;GEOSITE 类规则与部分扩展规则类型;proxy-providers 与 rule-providers 的增强参数。一个最小的 Hysteria2 节点示例:

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

对照一个全内核通用的 Shadowsocks 节点,可以看到扩展协议只是多了几个字段,骨架完全一致:

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

兼容性排错的三步法

1. 确认内核:打开客户端设置页查看内核标识,写着 mihomo 或 Meta 即为新内核。会看到版本号旁通常带内核名。
2. 看报错关键词:日志里出现 unsupported type 或 unknown field,基本可以断定是老内核遇到了新字段。
3. 就高不就低:把客户端换成基于 mihomo 内核的版本(下载页所有在维护客户端均满足),而不是反过来删配置字段迁就老内核。

订阅格式兼容性:换客户端时会发生什么

订阅是"一条 URL 换回一整份节点配置"的机制,但不同生态的订阅格式并不通用。搞清楚三种常见形态,换客户端、换平台时就不会一脸问号。

Clash YAML 订阅:本生态的原生格式

订阅链接返回一份完整的 YAML 配置(或至少包含 proxies 段),客户端拉取后直接加载。这是 Clash 系客户端的原生格式,字段信息最完整:节点参数、策略组结构、规则段可以一并下发。注意点只有一个——返回的配置里若含 Meta 扩展字段,老内核客户端会加载失败,报错表现参见上一章。

分享链接与 Base64 聚合:跨生态的最大公约数

ss://、vmess://、trojan:// 开头的单节点分享链接,以及把一堆链接 Base64 打包的聚合订阅,是跨客户端生态的通用交换格式。它只描述节点本身,不含策略组与规则。mihomo 系客户端大多能直接识别这类订阅并自动套一份默认策略组;反向兼容则看目标客户端——部分协议(尤其 Hysteria2、TUIC)的分享链接格式各家实现细节不同,跨生态导入偶发参数丢失属常见现象。

订阅转换:方便,但要知道会丢什么

订阅转换服务能把一种格式翻译成另一种,常用于"机场只给通用订阅、客户端想要完整 YAML"的场景。三点务必清楚:一,转换按模板生成策略组与规则,原订阅里没有的分流逻辑是模板加的,不代表服务商意图;二,冷门协议参数(如 Hysteria2 的带宽提示字段)可能在转换中被静默丢弃,连不上时优先怀疑这里;三,订阅链接含身份凭据,提交给公共转换服务等于交出节点信息,自建或使用客户端内置的本地转换更稳妥。更多订阅相关问答见帮助中心。

按使用场景选型:直接抄答案

前面所有铺垫收束到这一章。找到自己的场景,按推荐顺序在客户端里试,第一个连通且稳定的就是当前环境的正确答案。

桌面日常:网页、办公、开发

做什么:优先 Trojan 或 VLESS + TLS,备选 SS。桌面 CPU 性能充裕,TLS 开销无感,伪装能力优先。会看到:延迟稳定、长时间挂机不掉线。搭配 Windows 或 macOS 平台的 Clash Plus,规则分流按入门指南的默认配置即可。

移动端:通勤与户外

做什么:频繁切网选 TUIC 或 Hysteria2,吃 QUIC 的连接迁移;驻留单一网络、重视续航选 SS 或 Trojan。会看到:切网后恢复更快,或整夜待机掉电收敛。配合上文电量章节的探测间隔设置一起调。

弱网与长距离链路:高丢包、高延迟

做什么:首选 Hysteria2,次选 TUIC。会看到:同一条烂线路上吞吐明显回升,视频拖动不再转圈。若所在网络对 UDP 限速(表现为 QUIC 节点全部超时或速度骤降),回退 Trojan。

路由器与常驻服务器

做什么:优先 SS(AEAD),CPU 开销最低;设备性能富余再考虑 Trojan。内核直接跑 mihomo 命令行版,下载页内核区提供各架构包。会看到:低端 ARM 设备也能贴近线速转发。QUIC 系协议在软路由上 CPU 占用偏高,谨慎常驻。

一套订阅多协议并存:推荐姿势

多数服务商同一节点会提供多种协议入口。推荐做法:在策略组里把不同协议的同地区节点放进同一组,手动切换对比几天;客户端选基于 mihomo 内核的版本,保证六种协议全部可用,不用迁就协议做客户端选择。

实测自查:用四组对照实验替代猜测

协议选型最忌讳的是凭感觉。前面所有表格给的是规律,而你手上的线路、运营商、设备性能是独一份的组合,结论必须靠自己跑一遍才算成立。好消息是不需要专业工具,客户端自带的面板加浏览器就够,下面四组对照实验各花五到十分钟,做完你会拿到一张属于自己网络环境的协议排序表。

实验一:同节点换协议,比首包响应

做什么:在同一服务商的同一地区里,挑出协议不同但落地相同的几个节点,依次设为当前出口,每次打开一个此前没访问过的网页,记录从回车到首屏出现文字的主观耗时,重复三轮取中间值。为什么这样测:首包体感由握手轮次决定,而握手轮次正是三派协议的结构性差异,单看客户端的延迟数字反映不出来。会看到:优质链路上几种协议差距在半秒以内,可视为等价;长距离链路上 QUIC 系通常明显领先,TLS 系落后半拍到一拍。如果结果与规律相反,大概率是所在网络对 UDP 做了限速,直接把 QUIC 系从候选里划掉。

实验二:大文件下载,比吞吐与 CPU

做什么:找一个稳定的大文件源,分别用不同协议下载同一份文件两分钟,记录客户端显示的平均速度,同时打开系统的任务管理器或活动监视器,盯住客户端进程的 CPU 占用峰值。为什么这样测:吞吐上限往往不由线路决定而由加解密路径决定,只看速度会漏掉"速度达标但设备发烫"的隐性代价。会看到:桌面机上几种协议速度接近而 QUIC 系 CPU 偏高;低端 ARM 设备(软路由、盒子)上则可能出现 SS 跑满带宽、其他协议先到 CPU 天花板的分化。这一组结果直接决定路由器该选什么协议常驻。

实验三:弱网复现,比丢包恢复

做什么:制造一个可控的差链路——用手机热点并把信号拉到只剩一两格,或选一个已知拥堵时段的远距离节点,然后播放一段在线视频并反复拖动进度条,观察卡顿与重新缓冲的频率。为什么这样测:丢包恢复能力是 Hysteria2 存在的理由,而它只在坏链路上才显现,好线路上做这项对比等于白做。会看到:TCP 系在拖动后要等更久才恢复流畅,Hysteria2 恢复最快,TUIC 居中且更平稳。若你的日常网络本来就干净稳定,这一组差异可以忽略,不必为它牺牲兼容性。

实验四:整夜待机,比电量与断连

做什么:手机充满电后开着客户端过夜,不主动使用,早上记录电量下降百分比与客户端连接是否还活着,换协议再来一晚,尽量保证两晚的网络环境一致。为什么这样测:耗电与保活策略、基带唤醒频率相关,短时间观察完全测不出来,只有跨夜数据有意义。会看到:静默的 TCP 系掉电最少;带保活的 QUIC 系与配了短心跳的 WebSocket 组合掉电更多。若两晚差距超过百分之十,说明协议或心跳配置确实是主因,再回到电量章节调整探测间隔;若差距在百分之三以内,问题不在协议,按系统层面的后台策略去查。

四组实验做完,把结果写成一句自己的结论,例如"我家宽带干净,四种 TCP 系协议等价,优先 Trojan;出门用手机切网多,改 TUIC"。这句话比任何通用推荐都准,因为它是在你的真实环境里量出来的。日后换了服务商、换了城市、换了主力设备,再花二十分钟重跑一遍即可,不必推翻整套认知。

常见误区与延伸阅读

最后清一遍高频误解,每条都对应真实的求助帖模式。

误区一:协议越新越好

不成立。Hysteria2、TUIC 是针对特定环境(弱网、切网)的特化方案,优质有线网络上相对 Trojan 没有体感优势,还要多付 CPU 与电量。协议选型看环境匹配度,不看发布年份。

误区二:延迟低等于协议快

不等于。客户端显示的延迟只是一次探测往返,不含吞吐、丢包恢复与握手开销信息。同一节点 SS 与 Trojan 的探测值几乎一样,弱网下实际体验却可能差数倍。详细机制见延迟数字解读。

误区三:Meta 和 mihomo 是两个内核,要二选一

是同一个项目的前后两个名字。客户端说明里出现任一名字,能力集合都一致,不存在选择问题。

误区四:订阅在 A 客户端能用,在 B 客户端就一定能用

取决于订阅格式与内核版本的交集。YAML 订阅含扩展字段时老内核会拒载;通用订阅跨生态导入可能丢参数。换客户端后连不上,先按配置兼容性一章的三步法排错,再去帮助中心的故障排查分类找对应条目。

误区五:分流不生效是协议的锅

大概率不是。分流由规则段与 DNS 行为决定,与节点协议无关;规则失效最常见的根因是 DNS 泄漏或 fake-ip 配置不当,排查路径见DNS 泄漏检测与修复。

读完本页,协议与内核的选型依据已经齐了。下一步:去安装包页按平台领取客户端,再按入门指南把订阅导入、模式选择与连接验证走完一遍主线。