Clash 协议与内核技术参考

一、先分清协议、传输与客户端

三个名称回答三个问题

选择配置时，先把一条连接拆成三层看。Shadowsocks、VMess、Trojan、VLESS、Hysteria 2 和 TUIC 是协议名称，决定客户端与服务端如何认证、封装请求，以及需要哪些参数。TCP、UDP、TLS、WebSocket、HTTP/2、gRPC 和 QUIC 则描述连接所依赖的传输或封装方式。同一个协议可以有不同传输组合，但不是每一种组合都能被每个内核识别。Clash Plus 之类的客户端提供导入、连接开关和系统界面；真正解析配置并建立连接的是它使用的内核或实现。只看应用名称，无法推断某个协议一定可用。

例如，看到一条写着 VLESS 的分享链接，还要继续确认它使用 TCP 还是 WebSocket、是否启用 TLS、有没有额外的安全层，以及所需字段是否被目标内核支持。看到 Hysteria 2 或 TUIC 时，则要先确认当前网络能否稳定使用 UDP，因为它们建立在 QUIC 之上。协议名相同而传输参数不同，得到的兼容结果可能完全不同。这也是“链接能导入”与“连接能建立”必须分开判断的原因：导入器负责把文本变成配置项，内核负责解释配置项并尝试连接。

参数由连接提供方确定

服务端地址、端口、密码或用户标识、TLS 服务器名称、证书验证要求，都应与连接提供方给出的资料对应。地址和端口用于找到服务端；密码或用户标识用于完成协议认证；TLS 服务器名称通常用于服务端证书匹配。把这些字段从不同配置里拼在一起，通常不会得到一个可用连接。尤其不要把“某协议支持 TLS”误读成“勾选 TLS 就能修复连接”：服务端必须以相同方式提供服务，客户端的传输层设置也必须一致。

一份 Clash 配置还包含协议之外的部分。proxies 定义可选出站，proxy-groups 组织选择关系，rules 决定请求进入哪个出站；DNS 设置影响域名如何解析。协议正确但代理组没引用对应出站，或者规则最终指向直连，界面里仍可能看不到预期效果。反过来，修改出站模式也不会改变节点本身使用的协议。需要核对这些层次时，按“配置能解析 → 出站可选择 → 连接可建立 → 规则命中预期出站”的顺序检查，比反复切换开关更容易定位问题。

协议支持是“客户端版本、所用内核、具体传输组合”共同决定的能力，不是协议名称旁的一个永久勾选项。导入失败先看格式；导入成功但连接失败，再核对字段和网络条件。

比较前固定测试条件

所谓某协议“更快”，只有在服务端位置、线路、设备、网络和测试时间相近时才有比较意义。蜂窝网络与家庭 Wi-Fi 的丢包、UDP 可达性和休眠策略都不同；同一配置换个接入环境，排序也可能变化。判断日常是否适用，建议先明确自己的任务：网页短连接、持续下载、视频播放还是长时间后台待机。再看连接能否稳定恢复、首个页面是否及时打开、持续传输是否波动，最后才比较协议名称。后文的资源与电量讨论都是工作机制的定性分析，不是某台 iPhone 上的固定耗电结论。

二、Shadowsocks：较少字段的加密代理

从轻量转发到多种加密方法

Shadowsocks 最初以轻量代理的思路发展：客户端与服务端约定加密方法和密码，代理在两端之间转发流量。它不是一个只有单一参数组合的协议。不同实现支持的密码方法、认证方式及扩展能力可能不同，因此配置中的 cipher 不能省略，也不能随意替换。常见的 AEAD 方法会同时提供加密与消息完整性保护；更新的 Shadowsocks 2022 方法又有自己的密钥格式和实现要求。内核能识别一种 Shadowsocks 配置，不代表它自动支持所有方法。

在 Clash 风格的配置里，一条基础 Shadowsocks 出站通常写成 type: ss，并配合 server、port、cipher 和 password。如果提供方要求额外插件或传输包装，还需要对应的插件字段；缺少插件时，基础出站即使字段齐全也未必能与服务端一致。导入之前应看清提供的是标准出站字段、ss:// 分享链接，还是带有平台专用扩展的订阅。不同导入器对链接参数和插件字段的转换范围并不相同。

适用条件与排查顺序

Shadowsocks 的字段相对容易核对，通常适合作为理解代理配置结构的起点。基础连接的处理路径也比较直接，但实际延迟主要由网络往返、服务端负载、DNS 和传输状态决定，不能把“配置项少”等同于“任何环境下都最快”。如果密码方法与服务端不一致，连接一般不会靠切换规则模式恢复；如果是插件不匹配，则需要确认双方插件类型和参数，而不是只改密码。对 iPhone 来说，还要确认所选客户端的内核是否实现了该加密方法，以及订阅转换过程有没有丢掉插件信息。

一个实用的核对方法是先在配置详情中逐项查看地址、端口、方法与密码来源，再查看是否存在插件相关字段。接下来确认代理组确实列出了这条出站，选中它后重新建立连接。如果“连接开关已开启，但请求仍按直连路径走”，重点应转向出站模式和规则，不必继续改动加密方法。若只有某一条 Shadowsocks 出站不可用，而同一配置里的其他出站正常，则应优先比较它与提供方原始参数的差异，避免把局部配置问题误判为系统网络权限问题。

需要特别区分“协议类型”与“服务提供方的订阅类型”。一个以 YAML 提供的订阅可能同时包含多种协议出站；一个以 ss:// 开头的链接则通常只描述单条 Shadowsocks 连接。前者还可能附带规则、代理组和 DNS，后者一般需要客户端自行放入代理组。想让多条连接按规则工作，应确认导入的是完整配置还是单个分享链接，而不是仅凭文件名推测内容。

三、VMess：身份字段与传输组合

协议身份不等于传输方式

VMess 来自 V2Ray 生态，使用用户标识等信息区分连接，并能配合不同底层传输。配置里通常会看到 UUID 形式的 uuid，有时也会看到 alterId。在采用较新设置的连接中，alterId 通常为 0；但应以服务端实际参数为准，不能把旧订阅里的值机械改成零。VMess 的身份字段解决的是双方如何识别连接，TCP、WebSocket 或其他网络类型则决定数据如何承载。排查时必须同时读这两组信息。

分享链接中常见的 vmess:// 内容，可能是经过编码的一组连接参数，而不是直接可读的 YAML。客户端能显示出站名称，只能说明它完成了某种程度的解析；还要确认地址、端口、UUID、传输类型、TLS 开关、路径和主机名是否完整落到内核配置中。特别是 WebSocket 的路径与请求主机名，常与服务器设置成对出现，少一个字符都可能导致握手失败。TLS 的服务器名称也应按提供方要求填写，不宜直接拿出站显示名称代替。

比较性能时看完整连接链

与字段较少的基础 Shadowsocks 连接相比，VMess 可能叠加 TLS 和 WebSocket 等封装，因此建立连接涉及更多步骤。但这些步骤是否成为明显等待，要看连接是否复用、网络往返时间及服务器实现。如果把一条启用 WebSocket 与 TLS 的 VMess 连接，同一条未启用这些层的连接相比，再把差异全部归因于“VMess 协议慢”，结论并不成立。更合适的方式是比较同一设备上的真实任务：首次打开页面、连续加载资源，以及网络从 Wi-Fi 切到蜂窝后能否恢复。

资源占用也不能只按协议名排序。加密处理、TLS、系统网络扩展、日志记录和活跃连接数都会影响 CPU 唤醒及内存使用。短时测试时，界面刷新或系统后台任务还可能掩盖差异。对 iPhone 用户而言，优先选择参数完整、传输组合被当前内核支持且连接稳定的配置，比根据协议标签预判电量更可靠。若某条配置在导入后缺少传输字段，应回到原始订阅检查转换结果，而不是自行猜一个常见的 WebSocket 路径。

VMess 排查顺序：先核对 UUID 与服务端地址，再核对网络类型；使用 TLS 时检查服务器名称，使用 WebSocket 时检查路径和请求主机名。最后再看代理组与规则。

如果同一份订阅在另一客户端可用、在当前客户端不可用，应记录两边识别出的设置项并逐项比较，而不只比较节点显示名称。有些订阅转换工具会给不同实现生成不同字段，导致显示相同而实际传输设置不同。协议字段解释可结合术语表阅读；若需要确认连接开关、配置导入与规则模式的先后顺序，则回到快速上手按步骤检查。

四、Trojan 与 VLESS：名称相近，依赖条件不同

Trojan 的 TLS 与密码

Trojan 把 TLS 放在连接设计的核心位置，配置通常包含服务端地址、端口、密码，以及 TLS 所需的服务器名称等信息。它使用密码识别客户端，但密码并不能代替 TLS 证书验证。正常情况下，客户端仍需按提供方信息检查证书与服务器名称是否匹配；把证书验证关闭作为通用修复办法，会失去本应具备的身份确认环节。遇到证书错误，应优先检查设备时间、填写的服务器名称、证书状态以及服务端配置。

Trojan 也可能与 WebSocket、gRPC 等传输组合。此时仅有“Trojan + 密码”不足以还原完整连接：路径、服务名称或请求主机名仍要与服务端一致。对于移动端，TLS 握手会带来初次建立连接的工作量，但持续连接期间的体验更取决于网络稳定性与连接复用情况。不能因为 TLS 存在，就断言 Trojan 一定比其他协议更费电；频繁断线并反复握手，往往比一条长期稳定的连接更值得排查。

VLESS 的认证与外部安全层

VLESS 同样来自 V2Ray 相关生态，但它与 VMess 不是简单的改名关系。VLESS 使用用户标识完成身份识别，本身不负责提供传输加密，实际安全属性取决于它搭配的 TLS 等外部层以及具体传输配置。因此看到 type: vless 时，不应只检查 UUID，还应确认传输类型、安全层及其参数。某些 VLESS 配置还使用特定的安全扩展；是否支持该扩展，必须以客户端所用内核的能力为准。

这一点在 Clash 内核家族里尤其重要。原版 Clash 的能力范围与 Meta、mihomo 并不相同，不能因为某个 YAML 文件可以被打开，就假定其中的 VLESS 出站已经得到执行。即使两个内核都认识 VLESS，也可能对特定传输方式或扩展字段的支持程度不同。导入前先查看客户端说明中的内核信息；导入后查看解析提示、出站列表和连接日志。出现“不支持的代理类型”或未知字段时，应先考虑配置与内核不匹配，而不是修改服务器凭据。

把安全层与连通性分开检查

Trojan 和 VLESS 都可能涉及 TLS，但排查路径不同。Trojan 要核对密码及 TLS 参数；VLESS 要核对用户标识、传输方式与外部安全层。两者都可能出现端口可达但握手失败的情况：前者可能是密码或证书名称不一致，后者可能是扩展参数不被支持，也可能是传输路径不一致。先确认订阅原始字段，再检查转换后的 Clash 配置，最后才修改客户端内的可编辑选项，能够避免把“导入器遗漏字段”当成“协议本身不可用”。

如果配置来源同时提供不同协议的连接，不必为了追求更新的名称而更换已经稳定工作的出站。实际选择应围绕服务端提供的完整参数、客户端支持范围、所在网络的稳定性和自己的使用任务。对于仅想完成日常连接的用户，先使用下载页推荐的Clash Plus iOS 入口查看客户端，再确认所导入配置支持哪些协议；协议名字的流行程度不是配置有效性的证据。

五、Hysteria 2 与 TUIC：先确认 UDP 条件

QUIC 改变了比较前提

Hysteria 2 与 TUIC 都利用基于 UDP 的 QUIC 连接，但它们是不同协议，认证字段和配置格式不能互换。QUIC 把连接建立、安全握手及多路复用等能力组合在一起；在合适的网络中，它可以减少某些连接建立等待，并避免多个传输流因单个丢包被一并阻塞。不过“基于 QUIC”并不保证在每个接入环境都更快。设备与服务端之间必须能够正常传递 UDP；某些公共 Wi-Fi、企业网络或特殊接入方式可能限制 UDP，表现为建立连接失败或反复重试。

Hysteria 2 延续了 Hysteria 项目的高效传输取向，配置中常见服务端地址、认证信息和 TLS 相关参数。它还有与带宽和传输行为有关的设置，不同客户端或内核版本对这些字段的接受方式可能不同。TUIC 也围绕 QUIC 建立代理连接，配置通常需要用户标识及认证凭据，并可能包含拥塞控制等选项。这些选项影响的是连接行为，不是“数值越大越快”的性能旋钮；没有服务端要求时，不应复制另一条连接的参数进行试错。

移动网络上的切换与重连

iPhone 在 Wi-Fi 和蜂窝网络之间切换时，网络地址、路由与系统网络扩展状态都可能变化。一条 QUIC 连接在某些条件下能较快恢复，但客户端实现、服务端设置及系统调度同样重要，不能把协议设计里的潜在优势当成必然结果。实际观察应包含切换后的首次请求是否成功、是否需要手动重连，以及长时间锁屏后连接是否恢复。若只在某一个 Wi-Fi 下失败、蜂窝网络却正常，可先判断该 Wi-Fi 的 UDP 可达性，不必立即更换整份订阅。

排查 UDP 时，应分清“服务端不可达”和“UDP 路径不稳定”。如果同一配置在多个网络都不能建立连接，先检查地址、端口、认证与 TLS 信息；如果仅在某个网络里失败，优先比较网络条件。反复降低证书检查要求或盲目更改认证字段，不会修复被限制的 UDP 路径。若配置同时提供 TCP 与 QUIC 类协议，可以在相同地点和时间分别试用，观察实际任务是否完成，而不是只看连接列表里是否显示为已选中。

在配置兼容性方面，Hysteria 2 不能按 Hysteria 早期格式直接理解，TUIC 的字段也不能因为同样使用 QUIC 就套用 Hysteria 2 的写法。订阅转换服务如果只输出一部分字段，导入后可能出现名称正常、连接失败的情况。对此应先确认订阅导出的目标格式确实面向所用内核，再查看是否存在协议类型、认证字段或 TLS 名称缺失。内核不支持时，改写 YAML 的缩进无法补出协议实现。

六、速度、资源占用与 iPhone 电量

把首包、吞吐和稳定性分开

“连接速度”至少有三个不同含义：建立连接需要多久，打开一个新页面的首次响应需要多久，持续传输时能保持怎样的吞吐。它们不一定同向变化。一个协议可能握手步骤较少，但服务端线路拥挤，页面依然打开得慢；另一个协议初次建立连接需要更多工作，却能在后续请求里复用连接，连续浏览时表现稳定。比较时应固定设备、接入网络和服务端条件，分别记录首次请求与连续请求的感受，避免把 DNS 等待或应用自身加载时间记到协议头上。

网络质量改变时，排序还可能反转。丢包会影响重传与拥塞控制；TCP 与 QUIC 对多个并行请求的处理方式不同，但都需要真实可用的底层路径。UDP 不稳定时，Hysteria 2 或 TUIC 未必比基于 TCP 的配置更顺畅。网页由很多短请求组成，视频播放则更看重持续传输和中断恢复。选择协议前先问自己最常遇到哪类问题：是首次打开慢、长连接容易断，还是只在某个网络里无法建立连接。不同问题需要不同的检查顺序。

电量不是协议名称的固定属性

iOS 客户端通常借助系统网络机制接管相应流量。设备电量受无线电状态、屏幕亮度、后台应用、DNS 查询、日志级别、连接重试和加密工作共同影响。协议字段多少不能直接换算成耗电量。稳定保持少量连接的配置，可能比频繁失败、不断重试的“轻量协议”更省资源；但长时间持续传输又会让无线网络与处理器保持活跃。比较电量时，应尽量保持屏幕与应用使用方式一致，观察一段正常使用过程，而不是根据几分钟的电池百分比变化下结论。

排查异常耗电可以从具体行为入手：先确认是否有出站反复重连，再看日志是否持续输出连接错误；接着检查订阅自动更新间隔、DNS 设置及后台网络活动。若问题只出现在某条配置，比较它与稳定配置的传输方式和错误信息。若所有配置都表现相同，关注系统网络扩展、其他应用的网络请求以及当前接入环境。不要为了省电随意删掉 TLS 验证或将规则全部改为直连，那会改变连接语义，却无法证明耗电原因。

用实际任务做小范围比较

一个可复现的试用流程是：在相同网络下分别选中两条已确认参数正确的出站，等待连接建立，依次打开平时使用的网页或应用，观察首次加载、连续加载和切换网络后的恢复情况。不要同时变更 DNS、规则、协议和服务端，否则无法知道是哪项变化带来差异。测试完成后，保留更稳定、符合使用需求的配置即可；无需追求单次测速结果里的最高值。若想理解 DNS 模式为何影响首次请求，可继续阅读Fake-IP 与 DNS 映射说明。

协议比较没有通用的“最快”或“最省电”名次。先确认连接成功，再在同一网络、相近任务和相同设置下比较；遇到持续重试，应先修复错误而不是做性能排名。

七、原版 Clash、Meta 与 mihomo 的关系

从原版配置到扩展内核

Clash 原版建立了广泛使用的 YAML 配置组织方式：出站、代理组、规则与 DNS 等顶层字段组成一份可由内核读取的配置。后来出现的 Clash.Meta 在这一体系上扩展了协议与网络功能；mihomo 是这一内核路线延续使用的名称。它们之间有配置继承关系，却不能简单理解为“任何原版配置都完全等价，任何扩展配置也能倒着打开”。读取一份文件所需的最低能力，取决于文件中实际使用的字段和出站类型。

例如，一份只使用基础 Shadowsocks 出站、常见代理组与规则的配置，往往比包含 VLESS、Hysteria 2 或特定 DNS 扩展的配置更容易跨内核迁移。但即使协议类型相同，扩展字段、规则类型和默认行为也可能不同。原版 Clash 不应被假定支持 Meta、mihomo 后续加入的所有协议。客户端界面里出现“Clash”字样，也不能代替查看其实际使用的内核或内置协议支持说明。

配置兼容是逐字段判断

核对 YAML 时，先看顶层结构，再看出站的 type，随后检查各类型独有字段。proxy-groups 引用的出站名称必须与 proxies 中定义的名称一致；rules 最终指向的代理组或出站也必须存在。内核若不认识某个代理类型，不能仅靠把字段名称改成另一种拼写来兼容。若只是个别设置项名称变化，则应参考目标内核的配置文档调整，并留意默认值是否也发生变化。做迁移时保留原始文件，再在副本上逐项修改，比直接覆盖正在使用的配置稳妥。

下面是一份用于阅读结构的简短 YAML 示例。它展示出站、代理组和规则之间的引用关系；示例域名与密码仅用于说明字段，实际连接必须替换为连接提供方给出的完整参数。这段结构不包含客户端的全部系统设置，也不代表所有内核都支持任意附加字段。

mode: rule
proxies:
  - name: Sample-SS
    type: ss
    server: proxy.example.net
    port: 443
    cipher: aes-128-gcm
    password: your-password

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - Sample-SS
      - DIRECT

rules:
  - MATCH,SELECT

示例中的 MATCH,SELECT 表示未被其他规则处理的请求交给 SELECT 代理组；SELECT 又允许选择示例出站或 DIRECT。它说明了引用链如何形成，并不是建议所有请求都采用同一规则。实际订阅常包含更细的域名与网络规则，也可能通过规则集更新。阅读配置时可从最后的匹配规则往回追踪：规则指向哪个组，组里有哪些出站，所选出站的协议字段是否完整。这样比单独盯着某一条节点名称更容易发现引用错误。

客户端选择先看系统与内核

下载页按 Windows、macOS、Android、iOS 和 Linux 列出客户端，Clash Plus 位于各适用平台的首推位置；其他客户端的支持范围应以其实际实现为准。桌面平台还能见到 Clash Verge Rev、FlClash 等选择，Android 也有 Clash Meta for Android 等客户端，但同一份订阅在不同客户端里的导入结果仍需分别确认。为 iPhone 选型时，先看 iOS 下载入口与客户端说明，再检查当前订阅所需协议是否被其内核支持，不应拿桌面客户端的能力直接推断手机端的能力。

如果要进一步阅读 port、dns、proxies 到 rules 的整份文件结构，可查看YAML 结构逐段解析。本章的核心判断只有一条：兼容性以“目标内核能否识别并正确执行配置中实际使用的每一项”为准，而不是以文件扩展名或客户端名称为准。

八、订阅格式兼容与按场景选择

区分完整配置和单条分享链接

“订阅”描述的是配置如何获取与更新，不是某一种代理协议。订阅 URL 可能返回完整的 Clash YAML，也可能返回多条分享链接组成的文本，或者返回面向其他客户端的格式。单条 ss://、vmess:// 等链接通常只承载某个出站的连接参数；完整 YAML 还可能包含代理组、规则、DNS 与更新所需的其他信息。客户端能够从 URL 下载内容，只说明取得了文件，并不表示内容格式可被当前导入器正确识别。

导入失败时，先确认 URL 返回的是文件内容而不是登录页或错误页，再确认提供方标明的导出格式是否适用于 Clash 风格配置。导入后出站数量异常、名称显示正常却缺少传输参数，则应查看订阅原文与客户端解析结果；必要时请求与当前内核匹配的导出格式。不要将一份为别的客户端生成的文件直接改名为 config.yaml：扩展名不会转换字段，也不会补齐代理组。有关 iPhone 上多份 Profile 的新增、更新和切换，可参阅配置文件管理说明。

用条件筛选，不用协议名排座次

如果刚开始使用，先选能被客户端完整导入、字段能与提供方资料逐项对应的配置。已有稳定工作的 Shadowsocks、VMess 或 Trojan 出站时，不必为了更换协议而重做整套规则。若提供方给出 VLESS 配置，重点确认传输与安全扩展是否受当前内核支持；若提供 Hysteria 2 或 TUIC，先在常用 Wi-Fi 和蜂窝网络下分别确认 UDP 连通性。频繁在不同网络间移动的用户，应把切换后的恢复表现放进选择标准，而不是只看静态的协议说明。

对于网页浏览，首次请求与 DNS 解析体验通常容易被感知；对于持续传输，连接的稳定性更重要；对于长时间待机，则要观察是否发生不必要的重试与后台唤醒。这些场景都不能单靠协议名称给出统一答案。一个实用的选择顺序是：确认内核支持、核对字段、在常用网络建立连接、执行真实任务、观察恢复与耗电。每一步只改变一个条件，留下可比较的结果。如果某一步失败，先解决这一层的问题，别继续做速度排序。

保留可回退的配置

调整配置之前，保留一份已经可以工作的 Profile。新订阅先作为另一份配置导入，确认出站、代理组和规则都正常后再切换日常使用项。若一次更新后连接失败，可以切回旧配置，对照更新前后的协议类型、服务器字段及代理组引用，快速判断是内容变化还是接入网络变化。订阅更新也不等于客户端内核同步更新：新配置引入未受支持的协议字段时，仍需要选择匹配的客户端实现，或使用提供方给出的兼容格式。

操作流程可回到快速上手，安装选项见获取客户端；遇到连接开关、导入或规则模式方面的具体疑问，可查帮助中心。本手册适合在这些操作之间反复查阅：先定位当前问题属于协议、传输、内核还是订阅格式，再进入相应章节核对，而不是一次改动所有设置。