Clash 协议与内核技术参考 代理协议选型对照

这六类协议不是六个平行的选项，而是同一个问题在不同阶段给出的不同答案。它们要完成的事情一致：把本地流量加密后送到远端服务端，再由服务端发出请求。差别出在实现路径上——传输层选 TCP 还是 UDP、身份认证放在握手前还是握手后、连接是有状态还是无状态。这三条轴决定了协议的性能特征、兼容范围与适合的部署环境。

第一条轴：传输层

Shadowsocks、Vmess、Trojan、VLESS 都属于 TCP 优先的一类。在 QUIC 成熟之前，TCP 是几乎所有网络环境都能承载的传输层，代价是握手需要往返、丢包恢复由内核负责。Hysteria2 与 TUIC 选择 UDP 上的 QUIC，把加密、拥塞控制与多路复用全部放进用户态实现，好处是握手更快、丢包恢复更灵活，代价是 CPU 占用更高。

传输层选择直接决定端口要求。TCP 类协议只需要放行一个 TCP 端口，服务端防火墙、云厂商安全组、容器端口映射三处保持一致即可。QUIC 系协议必须放行 UDP 端口，而且部分云厂商的安全组默认不放行 UDP，配置时容易漏掉这一步，表现是「客户端连不上、服务端日志里什么都没有」。

第二条轴：身份认证与特征

Shadowsocks 没有握手协商，客户端与服务端共享密钥，对上即可开始发数据，协议层不做身份声明。Vmess 引入 UUID 身份，把认证做成协议的一部分，服务端可以按 UUID 区分用户、统计流量、单独限速。Trojan 与 VLESS 换了一条路：把流量放进标准 TLS，认证信息藏在 TLS 之后，服务端在证书与 SNI 层面与一个普通 HTTPS 站点没有区别。

认证方式越复杂，握手开销越大，换来的可管理性也不同。共享密码最简单，缺点是换密码要通知所有人；UUID 便于按用户管理，代价是配置项更多；TLS 承载类的可管理性最好，但对证书与域名有硬性要求。选型时把「谁维护服务端」这件事一起考虑进去，比单纯比较协议性能更有意义。

第三条轴：状态与开销

有状态协议需要维护会话表，无状态协议每个请求独立处理。VLESS 是无状态设计的代表，服务端不需要为每个连接保存会话，重启与迁移的成本更低。Vmess 早期依赖时间窗口校验，后来移除了这套机制，说明「状态」在工程上始终是负担。对客户端来说，有状态协议可以做连接复用（多路复用），减少重复握手，但对单个大流量连接没有帮助，反而可能让所有连接共享同一条链路的抖动。

把三条轴放在一起看，六类协议的定位就清楚了：Shadowsocks 与 Vmess 是通用型，兼容面最广；Trojan 与 VLESS 是 TLS 承载型，适合需要标准 HTTPS 特征的部署；Hysteria2 与 TUIC 是 UDP 优先型，在丢包与高延迟链路上有优势。后面三章分别展开这三组。

Shadowsocks：把加密转发做薄

Shadowsocks 的设计目标只有一个：把本地流量加密后原样转发出去，不在协议里加入任何额外协商。客户端与服务端共享一个密码，密码经密钥派生函数生成会话密钥，AEAD 加密（AES-256-GCM 或 ChaCha20-Poly1305）直接作用在数据流上。第一个数据包就是密文，没有握手往返，因此建立连接的延迟几乎等于一次 TCP 握手。

代价是协议本身没有身份声明，服务端无法知道「谁」在连接，只能按密码区分。Shadowsocks 2022 规范（SIP022）在这一点上做了改进：引入会话 ID 与重放保护，把密钥派生拆成主密钥与会话密钥两层，同时改善了 UDP 的处理方式。新旧版本的服务端与客户端之间存在兼容性差异，部署前需要确认服务端实现是否支持 2022 规范，否则会出现「密码正确但连不上」的情况。

加密套件的选择也有讲究。AES-256-GCM 在有硬件加速指令的设备上更快，路由器与低功耗设备上 ChaCha20-Poly1305 表现更稳。两者安全性同级，差别只在实现效率，客户端与服务端必须使用同一套加密方式。

Vmess：把传输层做成可选项

Vmess 是 V2Ray 项目的原生协议，核心变化是把传输层抽象出来。同一个 Vmess 身份可以跑在裸 TCP、mKCP、WebSocket、gRPC、HTTP/2 之上，也可以叠加 TLS。身份用 UUID 表示，服务端可以按 UUID 区分用户、做统计与限速。这种设计让 Vmess 的部署形态非常灵活：需要走标准 WebSocket 端口的场景、需要 gRPC 多路复用的场景，都可以复用同一套身份配置。

灵活性带来的是配置复杂度。Vmess 的分享链接是 base64 编码的 JSON，字段命名在不同实现之间并不统一（ps、add、port、id、aid、net、type、host、path、tls、sni 各代表一段信息），转换工具处理不当时会丢字段。另外，Vmess 自带的加密层在已经叠加 TLS 的情况下属于重复加密，计算开销高于 VLESS——这也是 VLESS 出现的原因之一。

两者的取舍

如果只看兼容性，Shadowsocks 与 Vmess 是覆盖最广的两个协议：原版 Clash、mihomo、Surfboard 以及各类移动端客户端都能识别。差别在于资源占用与配置成本——Shadowsocks 更省 CPU，Vmess 更灵活。UDP 转发方面，Shadowsocks 需要服务端实现显式开启，Vmess 原生支持 UDP over TCP 的转发方式，在只放行 TCP 的环境里更省事。

一个常见误解是「协议越新越快」。在同一台服务端、同一条链路上，Shadowsocks 与 Vmess 的实测吞吐差异通常小于链路本身的波动；真正拉开差距的是握手次数与是否叠加 TLS。选型时优先考虑客户端支持范围与服务端实现，而不是协议出现的时间顺序。

Trojan：把认证放进 TLS 之后

Trojan 的做法很直接：服务端监听 443，先完成标准 TLS 握手，客户端在握手完成后提交密码，服务端校验通过才开始转发。对中间的转发设备而言，这个端口的流量与一个普通 HTTPS 站点没有区别；服务端甚至可以在同一端口上用一个真实网站做回落（fallback），未通过认证的请求交给网站处理，因此一个域名可以同时承载网站与代理服务。

这种设计的依赖项很明确：一个有效的证书、一个与证书匹配的域名、正确的 SNI。三项里任何一项错位，客户端都会在握手阶段失败，日志里通常只留下「连接被重置」或「TLS 握手失败」这类笼统提示。Trojan 的 UDP 支持在不同实现之间有差异，原生实现提供 UDP associate，部分实现依赖扩展版本。配置上 Trojan 是六类协议里最简单的一类——地址、端口、密码、SNI，四项就能跑起来。

VLESS：去掉重复加密

VLESS 的设计前提是：既然外层已经有 TLS，协议内部就不需要再做一次加密。于是 VLESS 本身不加密，只负责携带身份（UUID）与目标地址，安全性完全交给底层传输。这一刀砍掉了 Vmess 里最重的计算开销，也让服务端变成无状态——不需要维护会话，不需要校验时间戳，重启不影响后续连接的建立。

VLESS 的另一个变化是流控。Vision 流控（flow 字段取 xtls-rprx-vision）会在 TLS 层内做填充与分片，减少嵌套 TLS 场景下的额外开销。需要注意的是，flow 参数是客户端与服务端之间的约定，订阅转换工具如果丢弃了这个字段，连接会退化成普通 TLS 模式——功能上仍然可用，但性能特征与预期不同。判断方法是打开连接日志，确认实际使用的流控方式。

证书与时间：两个最常见的问题

TLS 承载类协议的故障大多不在协议本身，而在证书链。自签证书需要客户端显式跳过校验，长期使用并不合适；证书链不完整时，桌面浏览器可能因为缓存了中间证书而显示正常，客户端却直接报错。另一类问题是系统时间——时间偏差超过证书有效期容差后校验会失败，表现却像是「节点不可用」，很容易被误判成服务端故障。

排查顺序建议固定下来：先看客户端日志里的错误类型（握手失败、证书校验失败、连接超时），再按系统时间、证书链、SNI 三项逐一排除。证书报错的完整排查路径见技术笔记《Clash 环境下的 HTTPS 证书报错：常见成因与排查顺序》。

Hysteria2：按配置带宽发送

Hysteria2 把传输层换成 QUIC（HTTP/3 的底层协议），TLS 1.3 内置，不需要额外配置加密套件。它最有辨识度的部分是拥塞控制：默认使用 Brutal，按客户端配置的上下行带宽固定速率发送，链路出现丢包时不主动降速。这个策略在丢包率较高的链路上能维持吞吐，前提是带宽参数填得接近真实值——填得过大，会挤占同一链路上的其他流量；填得过小，则发挥不出协议本身的优势。

Hysteria2 还提供 UDP 层的混淆选项（salamander），把 QUIC 数据包做一层轻量包装。服务端只需要一个 UDP 端口，不需要为每个用户分配端口，部署与扩容都比 TCP 类协议简单。配置项比 Trojan 多一些：地址、端口、密码、SNI、带宽上下限，以及是否跳过证书校验。

TUIC：0-RTT 与原生 UDP 转发

TUIC 同样基于 QUIC，设计上更贴近「把 QUIC 的能力直接用满」：v5 版本支持 0-RTT 握手，复用会话时可以省去一次往返；UDP 转发有两种模式（native 与 quic），前者把 UDP 数据包直接封装，后者走 QUIC 流，按链路特征选择。拥塞控制算法可以在 bbr、cubic、new_reno 之间切换，与 Hysteria2 的固定速率策略形成对比。

TUIC 的身份用 UUID 与密码共同表示，配置项数量与 Vmess 接近。它对客户端的要求更高——需要内核完整实现 QUIC 栈，因此目前只有 mihomo 系内核支持。服务端同样只需要一个 UDP 端口，且多个用户共享同一端口不会互相干扰。

QUIC 系的共同代价

QUIC 在用户态实现，这是它最大的工程代价。加密、拥塞控制、重传都在应用程序里完成，CPU 占用高于内核态 TCP；移动端持续传输时，电量消耗的差异会比 TCP 类协议更明显；内存占用也因为 QUIC 的缓冲区而更高。在桌面端与服务器上这些开销通常可以接受，在路由器、低配设备或长时间移动使用场景里则需要权衡。

另一个现实约束是 UDP 端口本身。部分企业网络与公共 Wi-Fi 会对 UDP 做限制或降级处理，此时 QUIC 系协议的表现会明显下降，需要回退到 TCP 类协议。这也是为什么 Hysteria2 与 TUIC 更适合作为备选节点而不是唯一节点存在——订阅里同时保留一个 TCP 类节点，切换成本最低。

三者关系

原版 Clash 内核定义了 config.yaml 的基本骨架：proxies、proxy-groups、rules、proxy-providers、rule-providers、dns、tun 等段落，以及 mode、log-level、mixed-port、external-controller 这些顶层字段。这份骨架后来成为整个生态的事实标准，几乎所有客户端都按它组织配置。原版内核已经停止维护，但它的字段命名方式一直沿用至今。

Clash.Meta 是在原版基础上做的扩展分支，增加了新协议、新规则类型与更完整的 TUN 实现。分支后来更名为 mihomo，仓库与文档迁移到 MetaCubeX 组织下维护。目前仍在更新的图形客户端——Clash Verge Rev、Clash Meta for Android、FlClash、Clash Nyanpasu、ClashX Meta——使用的都是 mihomo 内核。Clash for Windows 使用原版内核，已归档停止维护，可以继续加载原版配置，但不认识后来新增的字段。

判断一个客户端用哪个内核，最直接的方法是看日志里的版本行与配置解析结果：加载配置时提示未知字段，说明内核的字段集合较小；能识别 sniffer、listeners、rule-set 这些段落，说明是 mihomo 系。开源生态中各项目的关系见技术笔记《Clash 开源生态梳理：内核、客户端与规则集的关系》。

功能差异对照

配置兼容性与迁移

从原版内核迁到 mihomo 基本是无痛过程：原版配置里的段落与字段在 mihomo 中全部保留，直接加载即可。反向迁移则需要注意——mihomo 的扩展字段在原版内核里会触发解析错误，需要逐项删除。常见需要删除的段落包括 sniffer、listeners、sub-rules，以及 rule-providers 中的 mrs 格式声明。

# 以下段落仅 mihomo 系内核识别，原版内核会直接报未知字段
sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
      override-destination: true
    TLS:
      ports: [443, 8443]

两类内核的解析风格都是严格的：遇到不认识的字段会直接报错，而不是忽略。这个特性在迁移时是好事——配置有问题会立刻暴露，不会静默降级。看到 unknown field 这类日志时，先确认客户端的字段集合，再决定是删除字段还是换客户端。

另一个容易忽略的差异是 DNS 段落。mihomo 对 dns 的配置项做了扩展（nameserver-policy、fallback-filter 的匹配方式、是否让解析遵守规则等），原版内核的 dns 段落更简单。迁移时如果保留了旧字段，需要确认新内核是否仍然接受；反过来，把带扩展字段的 dns 段落拿到原版内核上，会直接解析失败。

四种订阅形态

第一种是完整 YAML 订阅：服务端直接返回一份 config.yaml，包含 proxies、proxy-groups、rules 以及端口设置，客户端加载后即可使用。这种形态对用户最省事，代价是订阅提供方决定了规则策略，用户自己的规则需要额外维护。第二种是分享链接列表：一份 base64 编码的多行文本，每行是一条 ss://、vmess://、trojan://、vless://、hysteria2:// 或 tuic:// 链接，客户端解析后得到节点列表，规则由客户端本地决定。

第三种是转换服务：把分享链接列表转换成 Clash YAML，中间可以套用规则模板。转换服务解决了客户端不认识分享链接的问题，同时引入了新的信息损耗。第四种是 proxy-providers：客户端定时从一个远程地址拉取节点列表，与本地规则解耦，适合多订阅合并。

proxy-providers：把节点与规则分开

proxy-providers 让客户端定时从远程拉取节点列表，与本地规则解耦。它适合多订阅合并与团队共享配置：规则写在本地，节点从远程更新。每个 provider 可以单独设置更新间隔、健康检查地址与过滤表达式。

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/subscribe/xxxx"
    interval: 3600
    path: ./providers/provider-a.yaml
    filter: "(?i)(hk|sg|jp)"
    health-check:
      enable: true
      url: https://example.com/generate_204
      interval: 300

过滤表达式是 provider 里最实用的两个字段：filter 与 exclude-filter，用正则匹配节点名。比如只保留名字里带某个地区标识的节点，或排除临时节点。需要注意的是，过滤发生在客户端：服务端返回的节点仍然会被下载到本地文件，只是不进入可用列表。排查「节点变少了」这类问题时，先看过滤表达式，再看服务端返回的内容。

转换与更新中的常见坑

分享链接转 YAML 的过程会丢失信息，这是最常见的问题来源。vless:// 的 flow 参数、hysteria2:// 的混淆与跳过校验选项、tuic:// 的拥塞控制与 UDP 转发模式，在部分转换工具里没有对应字段，转换后连接会退化成默认参数。判断方法是对比转换前后的节点参数，而不是只看「能不能连上」。

proxies:
  - name: "ss-a"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"
  - name: "vless-a"
    type: vless
    server: 203.0.113.11
    port: 443
    uuid: b831381d-6324-4d53-ad4f-8cda48b30811
    tls: true
    servername: example.com
    flow: xtls-rprx-vision
  - name: "hy2-a"
    type: hysteria2
    server: 203.0.113.12
    port: 443
    password: "your-password"
    sni: example.com
    up: "30 Mbps"
    down: "200 Mbps"

第二类问题是 YAML 语法本身。节点名里出现逗号、冒号、引号时，如果没有加引号包裹，整份配置会解析失败；这类错误通常表现为「订阅更新成功但节点列表为空」。第三类问题是订阅里的端口设置——部分订阅会带上 port、socks-port 字段，客户端一般会忽略它们并使用本地设置；如果发现本地端口被改，先检查客户端的端口覆盖选项。

订阅更新失败的排查顺序建议固定：先确认链接在浏览器里能直接访问（返回文本而不是登录页），再确认客户端日志里的 HTTP 状态码，最后检查订阅是否包含客户端不认识的协议——包含未知协议的节点会被跳过，其余节点正常加载。更多订阅相关的排查项整理在常见问题页。

客户端决定协议上限

mihomo 系内核的客户端支持完整的协议集：Shadowsocks、Vmess、Trojan、VLESS、Hysteria2、TUIC 都能识别。使用原版内核的 Clash for Windows 已归档停止维护，只支持 Shadowsocks、Vmess、Trojan、Snell 与 HTTP / SOCKS5 这类第一代协议；Surfboard 的协议范围也以 Shadowsocks、Vmess、Trojan 为主。订阅里包含 VLESS 或 Hysteria2 节点时，在归档客户端上这些节点会被直接跳过，表现是「节点数比订阅里少」。

全平台首推的客户端是 Clash Plus：Windows、macOS、Android、iOS 都有对应版本，iOS 端通过 App Store 获取，官网域名为 clashplus.io，订阅导入与规则分流的方式与其他客户端一致。桌面端还可以选择 Clash Verge Rev（Windows / macOS / Linux）、FlClash（全平台）、Clash Nyanpasu（Windows）；Android 端常用 Clash Meta for Android 与 FlClash；macOS 上除 Clash Verge Rev 外还有已归档的 ClashX Meta。各平台的安装包入口集中在获取客户端页。

平台差异

桌面端资源充足，可以放心使用 QUIC 系协议，CPU 占用不是瓶颈。Android 端要留意系统的后台省电策略：省电模式会限制后台网络活动，QUIC 的长连接在后台可能被系统挂起，表现是「切回来需要重连」。这类场景下 TCP 类协议的表现更稳定，或者把客户端的保活设置调得更宽松。

iOS 端由系统统一管理网络扩展，客户端的选择以 App Store 上架的版本为准，配置导入流程与桌面端一致，同样是订阅链接导入。路由器与低配设备上，用户态实现的 QUIC 栈会明显吃紧，Shadowsocks 这类轻量协议更合适；同时要注意设备内存，规则集本身也会占用一部分。

场景选型表

除了协议本身，客户端的选择还受更新节奏影响。仍在维护的客户端会跟进内核的新协议与新字段，归档客户端只能维持存量能力。客户端之间的横向差异见技术笔记《主流 Clash 客户端横向对比：按平台与使用习惯选型》。

迁移前的准备

换客户端或换协议之前，先把现有配置导出备份：profile 文件、规则文件、订阅链接。归档客户端（Clash for Windows、ClashX Meta）的配置仍然可以继续使用，导出的 config.yaml 在 mihomo 系客户端上基本可以直接加载，需要删除的是内核不认识的新字段——方向与原版迁到 mihomo 相反。

换协议时确认三件事：服务端是否支持目标协议、端口是否放行（QUIC 系需要 UDP）、订阅里是否包含该协议的节点。三项里缺任何一项，客户端上都不会出现可用的连接。如果服务端只提供分享链接，先确认链接的协议前缀与客户端支持范围一致，再导入。

迁移后的验证

验证顺序建议从规则开始：打开客户端的连接日志，确认流量命中的是预期规则与策略组，而不是落到默认直连或默认代理。然后验证 DNS——解析结果是否符合配置里的 nameserver 与策略，是否出现意料之外的解析来源。最后验证 UDP 转发：需要 UDP 的应用能否正常工作，这一项在 QUIC 系协议上通常是原生支持的，在 Shadowsocks 上取决于服务端配置。

如果使用 proxy-providers，额外确认订阅定时更新是否成功：日志里会记录每次拉取的时间与结果，节点列表是否被过滤表达式清空也要一并检查。更新失败的常见原因是链接失效、返回内容不是 YAML，或过滤表达式把全部节点排除掉了。

常见回退场景

QUIC 系协议在限制 UDP 的网络里表现会下降，此时切回 TCP 类协议即可，不需要更换订阅。证书类问题优先检查系统时间与证书链，具体路径见技术笔记《Clash 环境下的 HTTPS 证书报错：常见成因与排查顺序》。订阅更新失败优先检查链接可访问性与客户端日志，常见原因整理在常见问题页。

如果迁移的目标是替换已停止维护的客户端，完整流程（配置导出、内核替换、替代方案对比）见技术笔记《客户端停更之后：配置导出、内核替换与替代方案》。迁移完成后，建议把新配置与旧配置各保留一份，观察一到两周再删除旧文件。