Clash 协议、内核与订阅兼容技术参考

01 · Decision Model

先确定约束，再比较协议名称

协议、传输与客户端是三个层次

在 Clash 配置中，“节点类型”通常对应代理协议，例如 ss、vmess、trojan、vless、hysteria2 或 tuic。协议负责规定客户端与服务端如何建立会话、验证身份、封装目标地址以及传递应用数据。它并不等同于底层传输：VMess、VLESS 等协议可以组合 TCP、WebSocket、gRPC 或其他传输方式；Trojan 通常与 TLS 一起出现；Hysteria2 和 TUIC 则以 QUIC 及 UDP 传输能力为重要基础。订阅中看似相同的协议节点，只要传输方式、TLS 参数或服务端实现不同，实际行为就可能明显不同。

客户端是更外层的操作界面。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等 GUI 客户端负责导入配置、切换策略组、管理系统代理与展示连接信息，真正解析节点字段并建立连接的是其内置或调用的内核。选择客户端时，需要同时确认平台支持和内核能力；选择节点时，则要确认协议字段是否被当前内核识别。GUI 能显示节点名称，不代表底层一定能完整处理该节点的全部选项，尤其是较新的协议扩展或传输参数。

用四个问题缩小范围

第一项约束是服务端已经提供什么。客户端不能把一个 Shadowsocks 节点直接改成 VLESS，也不能仅通过修改 type 字段完成协议转换。协议两端必须采用一致的认证和封装规则，因此节点类型首先由服务端配置决定。如果订阅只提供一种协议，合理做法是检查当前内核是否支持，并优化节点、策略和 DNS，而不是在客户端里随意改写协议名称。

第二项约束是网络路径是否可靠支持 UDP。Hysteria2 与 TUIC 的主要传输建立在 UDP 和 QUIC 之上；如果本地网络、路由设备或服务端入口对 UDP 支持不稳定，它们可能出现握手超时、速度波动或频繁重连。此时 TCP 类方案即使峰值吞吐不突出，持续可用性也可能更好。判断 UDP 能力不能只看网页是否打开，应观察一段时间内的连接建立、休眠恢复、大文件传输和网络切换表现。

第三项约束是设备资源。桌面设备通常更关心并发连接、下载吞吐和长期运行稳定性；手机与平板还要考虑无线模块唤醒、后台存活、网络切换和电量消耗；路由器或小型服务器则可能受 CPU 指令集、内存和文件描述符数量限制。加密算法、用户态拥塞控制、连接复用和日志级别都会改变资源占用，协议名只能提供方向，不能替代实测。

第四项约束是配置可迁移性。长期使用的订阅可能包含规则集、策略组、DNS、脚本或特定内核扩展。迁移到另一个客户端时，最容易出问题的往往不是基础节点，而是规则提供器、TUN 参数、嗅探设置与较新的协议字段。若需要在多台设备间共享配置，应优先选择共同支持的字段子集，并把平台专属设置放在客户端本地，而不是全部写入一份通用订阅。

选型时建议先保留一个稳定基线，再比较候选协议。基线可以是当前能够持续连接、配置字段较少的节点。随后只改变一个变量，例如保持同一服务端区域与相近线路，分别测试 TCP 类和 QUIC 类节点。若同时更换服务端、协议、端口和策略组，结果无法归因，也就很难判断后续应调整哪一项。

02 · Established Protocols

Shadowsocks 与 VMess：成熟基础和组合能力

Shadowsocks 的简洁设计

Shadowsocks 常缩写为 SS，其核心思路是使用预共享密码和选定的 AEAD 加密方法保护客户端与服务端之间的数据，并用较轻的协议封装转发 TCP 或 UDP 流量。它的配置项相对集中，典型节点只需要服务器地址、端口、密码和加密方法。较少的协商步骤与清晰的实现边界，使它容易被不同内核和客户端支持，也适合作为检查订阅、DNS 与策略组是否正常工作的基线协议。

“配置简单”不代表所有 Shadowsocks 节点都相同。加密方法必须与服务端一致，名称拼写也要符合内核支持列表。现代配置通常采用 AEAD 方法；旧式流加密方法可能因实现策略或安全属性而不再被部分客户端接受。订阅若包含插件字段，还要确认当前内核是否支持相应插件及其参数。一个基础 SS 节点能够导入，并不能推导出带插件的另一节点也一定兼容。

从资源角度看，Shadowsocks 的协议处理通常较直接。实际 CPU 消耗取决于加密方法、设备硬件加速能力、并发数量和吞吐规模。在普通桌面设备上，协议本身很少成为日常浏览的主要瓶颈；在低功耗路由器、高速下载或大量并发连接场景中，算法实现和单核性能才会逐渐显现差异。若测速时 CPU 已接近持续满载，继续切换策略组通常无法提升吞吐，应先降低变量并检查设备处理能力。

VMess 的身份与传输组合

VMess 源自 V2Ray 生态，节点通常使用 UUID 作为用户标识，并允许与多种底层传输组合。它在订阅中经常同时带有 network、TLS、主机名、路径或服务名等字段。对用户而言，VMess 的主要特点不是某个单一速度结论，而是配置组合较丰富：同为 VMess，TCP、WebSocket 和 gRPC 方案的握手过程、连接复用方式及额外头部成本都不同。

VMess 节点排错时，需要从外到内核对。先确认服务器、端口与 UUID，再确认加密或安全字段，随后检查传输类型。如果使用 WebSocket，应核对路径和 Host；如果配合 TLS，应核对服务器名称、证书验证和 ALPN 等信息；如果使用 gRPC，则需关注服务名及多路复用行为。订阅转换工具若遗漏其中任意一项，节点仍可能显示在客户端中，但连接会在握手阶段失败。

VMess 对系统时间较敏感。设备时间存在明显偏差时，身份验证可能无法正常完成，因此“同一订阅在一台设备可用、另一台设备全部超时”时，系统时间与时区是成本很低但值得优先检查的项目。自动时间同步恢复后，应重新加载配置或重启相关连接，避免旧连接状态继续干扰判断。

两者如何选择

如果服务端同时提供 SS 与 VMess，并且两者线路条件相近，SS 更适合作为低复杂度基线：字段少，迁移到不同内核时更容易识别问题。VMess 则适合已有成熟部署、需要特定传输组合，或订阅生态已经围绕其参数组织的情况。选择不应基于“字段多所以更高级”或“字段少所以一定更快”，而应看额外传输层是否解决了明确需求，以及当前内核是否能正确表达这些配置。

在移动端，连接数量和重连频率通常比单次加密计算更影响体感。WebSocket 或 gRPC 组合可能引入额外握手与连接管理，但合理的连接复用也可能减少重复建连。应用流量若以短请求为主，应观察首次请求和休眠恢复；若以持续音视频或下载为主，应观察十分钟以上的稳定吞吐。单次延迟数字只能反映探测目标的某一时刻，不足以覆盖上述差异。

迁移配置时，SS 基础字段在 Clash 系内核之间通常具有较好的可移植性；VMess 的基础字段也较成熟，但传输扩展的命名和嵌套结构更值得检查。若订阅来自转换服务，建议保留原始订阅地址，并在转换前后对比一个节点的服务器、端口、UUID、网络类型、TLS、路径与主机名，避免只根据节点显示名称判断转换是否完整。

proxies:
  - name: "SS 基线节点"
    type: ss
    server: server.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

上例展示的是 mihomo 配置中基础 Shadowsocks 节点的字段关系。示例域名与密码需要替换为服务端提供的真实信息；udp: true 仅表示允许内核处理该节点的 UDP 流量，服务端和网络路径也必须具备对应能力。不要从其他节点复制密码、端口或加密方法后仅修改名称，这种配置虽然能通过 YAML 语法解析，却无法完成协议认证。

03 · TLS-Oriented Choices

Trojan 与 VLESS：认证层和传输层的取舍

Trojan 的连接结构

Trojan 通常把密码认证与 TLS 连接结合起来。客户端首先需要完成 TLS 握手，再在加密连接中提交协议认证信息和目标地址。配置中除服务器、端口与密码外，经常还会出现 sni、证书验证、ALPN 和 UDP 支持等字段。它的节点结构不算复杂，但 TLS 相关参数必须与服务端证书和入口配置一致，任何一处名称不匹配都可能表现为握手失败。

SNI 用于在 TLS 握手中指明目标服务器名称。订阅提供域名作为服务器地址时，内核通常可以据此处理；若服务器字段是 IP 地址，而证书签发给某个域名，则往往需要单独填写服务器名称。关闭证书验证虽然可能暂时绕过名称或证书链问题，却会改变连接的身份验证属性，不应作为长期排错方法。更稳妥的做法是确认服务端证书、系统时间、SNI 和订阅字段是否一致。

Trojan 的性能包含两部分：初次 TLS 握手成本与连接建立后的数据传输成本。短连接很多时，重复握手对首包时间更明显；保持连接或合理复用时，这部分成本会被摊薄。TLS 实现通常经过广泛优化，在现代桌面与手机处理器上具有较成熟的硬件和软件支持，因此不能仅凭“多一层 TLS”判断它一定更慢。线路时延、服务端负载和应用建连模式往往更关键。

VLESS 把扩展交给外层

VLESS 同样来自 V2Ray 相关生态，但其协议层设计更轻，通常使用 UUID 标识用户，并把加密与安全能力交给 TLS、REALITY 或其他外层机制。对 Clash 用户而言，VLESS 的关键不只是 type: vless，还包括网络传输、TLS 开关、服务器名称、流控字段以及可能出现的客户端指纹等扩展。不同组合之间的兼容边界比协议名称本身更值得关注。

VLESS over TCP、VLESS over WebSocket 与 VLESS over gRPC 的连接行为并不相同。TCP 组合层次较少，排错链路相对短；WebSocket 增加 HTTP 升级、路径和主机字段；gRPC 依赖 HTTP/2 语义与服务名。若再叠加 TLS 或其他安全层，配置字段会继续增加。订阅转换时必须保持这些字段之间的对应关系，不能把传输类型改为 TCP 后仍保留只属于 WebSocket 的路径并期待内核自动推断。

VLESS 的一些扩展由不同项目逐步实现。mihomo 对常见 VLESS 组合提供支持，但旧版 Clash 原始内核不具备同等能力，部分较早 GUI 即使可以读取 YAML，也可能在启动内核时报告未知代理类型或未知字段。因此，包含 VLESS 的订阅更适合使用持续维护并明确采用 mihomo 的客户端。本站下载页中，Clash Plus 与 Clash Verge Rev 都可作为桌面端优先考察对象，具体平台入口可在下载页选择。

认证成功不等于全部流量正常

Trojan 或 VLESS 节点显示为可连接，只说明基础探测可能完成，不代表 TCP、UDP、IPv6 和所有应用协议都已经验证。测试时应至少覆盖普通网页、长连接应用、域名解析以及需要 UDP 的应用场景。若只有部分应用失败，应检查规则匹配、DNS、TUN 和 UDP 能力，而不是立即认定协议本身不可用。

连接建立后马上断开，常见检查顺序是：系统时间、服务器地址与端口、身份凭据、TLS 开关、SNI、证书验证、传输类型、路径或服务名。VLESS 还需要核对 flow 等扩展字段是否由服务端要求并被内核支持。日志中的“TLS handshake”“authentication”“unknown field”对应不同层次，排错时应根据关键词定位，而不是反复切换节点掩盖原始错误。

从选择角度看，Trojan 适合服务端已经围绕标准 TLS 入口组织、参数相对固定的情况；VLESS 适合需要利用其传输与安全层组合、并且客户端内核明确支持相关扩展的情况。如果多设备共享订阅，应先列出所有设备的内核能力，再选择共同支持的组合。桌面端能使用的较新扩展，不一定能被旧移动客户端或路由器插件完整识别。

04 · QUIC Transport

Hysteria2 与 TUIC：面向变化链路的 UDP 方案

为什么选择 QUIC 与 UDP

Hysteria2 和 TUIC 都把 QUIC 作为重要基础。QUIC 运行在 UDP 之上，在用户态完成加密连接、可靠传输、多路流与拥塞控制。与传统 TCP 连接相比，它可以减少部分传输层与安全层往返，并避免多个逻辑流完全共享同一个 TCP 队头阻塞状态。对于时延变化明显、存在一定丢包或需要较高吞吐的链路，这类设计提供了更多调节空间。

但 UDP 不是自动获得高性能的开关。QUIC 仍然受到物理带宽、往返时延、丢包、服务端出口和终端处理能力限制。部分路由器对长时间 UDP 会话的状态保持较短，某些网络会限制 UDP 包大小或速率，企业网络也可能只允许特定类型的 UDP 流量。出现周期性断流时，应检查 NAT 会话、MTU、路径质量和网络切换，而不是只调整客户端测速目标。

Hysteria2 的带宽与拥塞控制

Hysteria2 是 Hysteria 系列后续协议，配置通常包含服务器、端口、密码、TLS 服务器名称，以及可选的带宽或混淆相关参数。它强调在复杂链路上利用 QUIC 与拥塞控制维持传输效率。客户端中的上行、下行带宽设置不是运营商套餐数字的展示项，而是拥塞控制算法的重要输入；填写远高于真实可用能力的数值，可能导致发送过快、排队和丢包增加，最终反而降低稳定性。

带宽参数应根据长期可用水平而非瞬时峰值设置。可以先不写可选值，使用服务端建议或内核默认行为；确需手动设置时，先用稳定时段的多次结果确定保守区间，再分别观察上行和下行。移动网络的上行能力通常波动更大，过高的上行估计会影响确认包和交互流量。修改后至少测试网页首包、持续下载、视频拖动与设备休眠恢复，不能只看短时速度。

Hysteria2 使用 TLS 相关机制验证服务端，系统时间和服务器名称仍然重要。如果订阅提供了 SNI，应保持原值；如果节点使用 IP 地址连接，也不要因此删除证书对应的域名。遇到证书错误时，应回到订阅来源核对字段。混淆密码等扩展同样需要与服务端一致，客户端单方面开启不会产生可用连接。

TUIC 的会话与并发特点

TUIC 同样基于 QUIC，节点常见字段包括服务器、端口、UUID、密码、服务器名称、拥塞控制算法和 UDP 转发模式。其设计关注低延迟连接建立、多路复用和 UDP 流量承载。不同 TUIC 协议代际的字段并不完全相同，订阅来源、服务端实现和客户端内核需要采用兼容的格式。看到 tuic 类型后，仍应核对认证字段与版本语义，而不能只复制另一节点的 UUID。

拥塞控制算法决定发送端如何根据确认、时延和丢包调整速率。算法名称本身没有脱离环境的优胜顺序：较积极的策略可能在带宽充足时快速提升吞吐，也可能在共享网络或缓冲较深的链路上造成排队；较保守的策略可能更平稳，但达到峰值需要更长时间。订阅若已经给出服务端建议，通常先保持原值。只有在重复测试确认问题可复现时，再单独修改该字段。

TUIC 与 Hysteria2 都可能让手机的无线模块维持更活跃的收发状态，尤其是在大量并发、持续传输或频繁保活时。另一方面，若协议能更快完成传输并及时进入空闲，整体能耗也可能下降。因此，不能仅按“基于 UDP”判断耗电高低。应在相同亮度、相同应用任务、相近信号强度下比较一段完整使用周期，并同时观察后台重连次数。

建立可靠的失败回退

若订阅同时提供 QUIC 类和 TCP 类节点，可在策略组中保留两类候选。网络环境支持 UDP 时优先实测 Hysteria2 或 TUIC；出现握手超时、切换网络后无法恢复、路由设备负载过高时，回退到 SS、Trojan 或其他 TCP 传输节点。回退不是协议降级评价，而是让连接方式适配当前路径。

排查 QUIC 类节点时，建议先关闭客户端内不必要的并发测速，避免测试本身占满带宽。随后确认系统时间、UDP 可用性、服务端地址与端口、认证信息、SNI 和证书，再查看 MTU 或包大小相关现象。若小流量正常而大流量停顿，路径 MTU、拥塞控制和路由设备 UDP 状态表值得重点检查；若从一开始就无法握手，则更可能是 UDP 路径、端口、认证或 TLS 参数问题。

05 · Performance

连接速度、资源占用与移动端电量

把“速度”拆成四项指标

协议比较中的速度至少包含连接建立时间、首包时间、稳定吞吐和故障恢复时间。连接建立时间受 DNS、TCP 或 QUIC 握手、TLS 和认证步骤影响；首包时间还包含服务端访问目标的耗时；稳定吞吐取决于带宽、拥塞控制、丢包恢复和终端处理能力；故障恢复时间则体现网络切换或路径变化后能否快速重新建立会话。只记录一个延迟数字，会把这些差异压缩成无法解释的结果。

Clash 客户端中的延迟测试通常向指定 URL 发起探测，它适合排除完全不可达节点和发现明显异常，但不等同于应用真实访问。探测目标所在位置、连接是否复用、DNS 结果和缓存都会影响数字。选节点时可以先用延迟测试缩小范围，再用实际应用完成持续验证。若两个节点的探测结果接近，不必反复追求很小的数值差，应更重视长连接稳定性和失败率。

公平比较要求控制变量。尽量选择同一服务商、同一区域、相近时间和相同目标，关闭后台更新与云同步，并让每个候选完成一次预热。每项测试重复多次，记录中位表现和最差情况，而不是只保留最快结果。协议节点位于不同服务端时，测到的主要差异可能来自线路与负载，不能归因于协议设计。

CPU、内存和并发连接

Shadowsocks 的基础封装较轻，VMess、Trojan 和 VLESS 的具体成本取决于外层传输与 TLS，Hysteria2 和 TUIC 则需要在用户态处理 QUIC、加密、丢包恢复和拥塞控制。这个顺序只能描述处理结构，不能直接转化为固定资源排名。成熟实现、硬件加速、数据包大小和连接数量都会改变结果。某个协议在低速网页浏览中差异很小，在高速转发或数千连接下却可能暴露单核瓶颈。

内存占用通常随连接表、DNS 缓存、规则集、日志和 TUN 状态增长。大型规则集与复杂 DNS 配置可能比节点协议本身占用更多内存。若客户端运行一段时间后资源持续上升，应区分是活动连接没有释放、日志级别过高、规则提供器更新，还是内核异常。只切换协议节点无法解决规则和日志造成的资源问题。

路由器与小型服务器更需要关注并发和架构。Mihomo 内核本身需要与设备 CPU 架构匹配；高吞吐 QUIC 在较弱 CPU 上可能更早到达处理上限。此时可降低并发测试数量、选择处理成本较低的节点、缩减日志，并确认系统软中断和 NAT 处理没有成为瓶颈。本站下载页的 Linux 与内核区用于区分桌面 GUI 和面向服务器、路由器的内核文件，普通桌面用户通常不需要手动管理独立内核。

移动端电量由工作周期决定

手机耗电不能只看客户端进程的瞬时 CPU。代理连接会影响无线模块唤醒、后台保活、DNS 请求、连接重试和系统 VPN 接口。信号较弱时，设备发射功率和重传成本都会上升；协议如果频繁重连，即使每次计算很少，也可能增加整段时间的能耗。反过来，能够稳定保持会话并快速完成数据传输的方案，可能更早进入空闲状态。

比较移动端电量时，应固定屏幕亮度、网络类型、应用任务和测试时长。可以分别执行三类任务：持续半小时的网页与消息混合使用、固定大小文件传输、锁屏后的后台通知与恢复。记录系统电量变化、设备温度和断连次数。一次短测速无法体现后台行为，整天混合使用又容易受到相机、定位和屏幕活动干扰，分阶段测试更容易定位原因。

TUN 模式通常覆盖更多应用流量，也会让内核持续参与路由和 DNS 处理；系统代理只影响遵循代理设置的应用，资源范围相对有限。比较协议时应保持代理模式一致，否则得到的是 TUN 与系统代理差异，而非协议差异。Android 和 iOS 的后台管理机制不同，同一客户端在两个平台上的结果也不应直接横向套用。

最终选择应以稳定区间为依据。某个节点偶尔达到很高峰值，但经常出现停顿，未必适合会议、同步和长连接应用；另一个节点峰值稍低却能保持连续传输，通常更适合作为默认策略。可以把前者放入下载或大流量策略组，把后者用于日常默认组，通过规则分流让协议特征服务于具体任务。

06 · Kernel Family

原版 Clash、Meta 与 mihomo 的家族关系

原版 Clash 奠定配置模型

原版 Clash 建立了后来广泛使用的配置模型：代理节点放在 proxies，策略组放在 proxy-groups，规则按顺序放在 rules，并通过系统代理、透明代理或其他入口接收流量。规则命中后把连接交给策略组或指定出口。许多订阅和教程至今仍沿用这套基本术语，因此理解原版配置结构仍然有价值。

原版项目的维护状态已经发生变化，其协议集合和扩展能力不能代表当前 mihomo 生态。它适合用于理解基础兼容层，但不应被当作较新节点类型的能力基准。包含 Hysteria2、TUIC、VLESS 扩展、复杂 DNS 或规则提供器选项的配置，通常需要 mihomo 系内核。旧客户端若固定捆绑原版内核，可能无法识别这些字段。

Clash.Meta 扩展协议与网络能力

Clash.Meta 在原有配置模型上增加协议、传输、DNS、TUN、嗅探和规则相关能力。它尽量保持常用 Clash 配置的迁移路径，同时引入新的节点类型与字段。对用户最直接的变化是，同一份订阅可以包含更丰富的协议组合，客户端也能提供更完整的透明代理与 DNS 控制。

扩展兼容并不意味着所有原版配置都会产生完全相同的运行结果。DNS 默认值、规则集行为、TUN 栈、嗅探和连接处理可能因配置与实现更新而变化。迁移时应先保留原配置副本，使用内核的配置检查功能确认语法，再依次验证节点、策略组、规则、DNS 和 TUN。一次性开启所有扩展会让问题来源难以判断。

mihomo 是当前延续名称

mihomo 是 Clash.Meta 后续使用的项目名称。实际资料中仍可能同时出现 “Meta core”“Clash.Meta” 与 “mihomo”，它们反映项目历史与客户端界面中的不同命名，不应简单理解为三个互不相关的内核。当前客户端如果标注使用 mihomo，通常意味着延续 Meta 系列的协议与配置能力，但具体支持范围仍需以客户端捆绑的内核和配置说明为准。

GUI 客户端与内核的更新节奏可能不同。客户端界面新增某个设置项，需要底层内核提供对应参数；内核支持的新字段，也可能尚未被 GUI 做成可视控件。多数情况下，订阅节点由内核直接读取，因此重要的是确认客户端实际调用哪个内核，而不是只看产品名称中是否含有 Clash。Clash Plus、Clash Verge Rev、FlClash 和 Clash Nyanpasu 等客户端的定位与平台覆盖可在客户端对比页继续查看。

配置兼容要分层判断

第一层是 YAML 语法兼容。缩进、列表和键值结构正确，配置才可能被解析。第二层是字段识别，内核需要知道 type、传输和扩展字段的含义。第三层是语义兼容，即字段虽然存在，但默认值或组合约束是否相同。第四层是运行环境兼容，例如 TUN 权限、系统代理接口、网络扩展和防火墙规则。只通过语法检查，不能证明后面三层都正常。

基础 SS、VMess、Trojan 节点和常规策略组通常具有较好的迁移基础；VLESS、Hysteria2、TUIC、REALITY、复杂 DNS 与 TUN 选项更依赖 mihomo 能力。若配置需要同时服务多个客户端，可以维护一个公共基础层，只放共同支持的节点、策略组和规则，再为桌面、移动端与路由设备分别添加本地覆盖。这样比把所有平台选项塞入单一 YAML 更容易维护。

从 Clash for Windows 迁移时，还要区分 GUI 设置与配置文件内容。窗口行为、开机启动、系统代理端口和更新设置可能存放在应用本地，不会随订阅迁移；节点、策略组和规则通常来自配置。可参考Clash for Windows 停更后的迁移方案逐项整理，而不是只复制应用目录。

mihomo -t -f config.yaml

上面的命令用于让独立 mihomo 内核检查配置文件。不同客户端可能把内核封装在应用内部，不需要用户直接执行命令；如果使用下载页提供的独立内核，应在终端进入文件所在目录，并将 config.yaml 替换为实际配置路径。检查通过表示语法和已知字段可被读取，仍需启动后测试端口、DNS、规则与节点连接。

07 · Subscription

订阅格式、字段转换与兼容边界

订阅链接不等于统一文件格式

用户通常把一条远程地址统称为“订阅”，但地址返回的内容可能是 Clash YAML、URI 列表、Base64 包装文本，或面向特定客户端的 JSON。客户端能否直接导入，取决于它是否识别返回格式，或是否内置了转换过程。HTTP 请求成功只说明文件已下载，不代表节点字段已经被正确解析。

Clash YAML 通常可以同时描述端口、DNS、节点、策略组、规则和规则提供器，适合完整配置分发。URI 列表则更侧重逐个节点，每种协议使用自己的链接结构，复杂传输字段可能通过查询参数表达。客户端把 URI 列表转换为 Clash 配置时，需要生成节点对象，并把它们放入策略组；若转换器不了解较新的字段，可能出现节点缺失、参数丢失或类型降级。

导入后检查四个层次

第一步检查配置是否成功更新，并记录更新时间和来源名称。更新失败时先查看 HTTP 状态、证书、网络和链接有效性，不要立即删除原配置。第二步检查节点数量与类型，确认 SS、VMess、Trojan、VLESS、Hysteria2 和 TUIC 等预期类型是否存在。第三步抽查字段完整性，尤其是服务器名称、TLS、传输路径、UUID、密码和 UDP 选项。第四步确认策略组引用的节点名称仍然存在，避免节点已导入但没有进入任何可选组。

节点显示名称不是可靠的唯一标识。订阅更新可能修改名称、添加地区前缀或调整排序，手写策略组若按旧名称引用，更新后就会出现找不到代理的错误。使用正则筛选或代理提供器时，也要确保表达式不会意外排除新节点。需要长期固定选择时，建议使用清晰的策略组和自动筛选条件，而不是依赖列表位置。

订阅转换最常遗漏的是嵌套传输参数。VMess 或 VLESS 的 WebSocket 路径、Host、gRPC 服务名，Trojan 的 SNI，Hysteria2 的认证和 TLS 参数，TUIC 的拥塞控制与认证字段都需要保留。转换后若基础节点可用而某一类全部失败，应优先对比该类节点的原始字段与生成 YAML，而不是修改全局 DNS。

配置合并需要明确覆盖规则

部分客户端支持在远程订阅上叠加本地覆写，例如加入自定义规则、修改 DNS 或创建策略组。合并机制可能采用键覆盖、列表追加、脚本处理或模板生成，不同客户端的顺序并不统一。覆写前应确认“远程值覆盖本地值”还是“本地值最后生效”，尤其要注意 rules 与 proxy-groups 这类列表。错误的追加顺序可能让兜底规则提前命中，后续规则完全没有机会执行。

规则自上而下匹配，命中后停止继续检查。如果本地配置把 MATCH 或等效兜底规则放在前面，远程规则即使成功合并也不会生效。策略组则需要确保名称唯一且引用关系完整，循环引用会导致配置失败。DNS 覆写还可能影响节点服务器域名的解析路径，因此修改 nameserver、fake-ip 或代理服务器解析设置后，应同时测试节点域名能否正常解析。

订阅安全与维护习惯

订阅地址通常包含用于识别账户或配置的随机路径，应视为敏感配置，不要发布在公开页面、截图或日志中。排错时可以展示节点类型和已脱敏字段，但应隐藏完整订阅地址、密码与 UUID。将配置发送给他人协助检查前，应先复制一份并替换认证信息，避免直接编辑正在使用的原文件。

更新订阅前保留最近可用配置，有助于区分“远程内容变化”和“本地客户端变化”。如果更新后全部节点消失，可以切回旧配置验证；如果旧配置也失败，再检查网络、系统时间和服务端状态。客户端升级与订阅更新尽量不要在同一时间进行，否则一旦出现问题，很难确认变化来自内核还是远程配置。

多设备使用同一订阅时，建议把节点信息与平台设置分离。订阅负责节点和通用策略，本地客户端负责系统代理、TUN 权限、启动行为和平台 DNS。iOS、Android、Windows、macOS 与 Linux 的系统接口不同，把某个平台的路径、网卡名称或权限字段写入公共配置会降低可移植性。需要选择平台客户端时，可从下载页进入对应标签，其中 Clash Plus 作为全平台优先选择，其他客户端按系统和配置需求补充。

如果导入、更新或策略组引用仍然异常，可以前往常见问题按安装配置和故障排查分类继续定位。配置结构需要逐段阅读时，可参考Clash 配置文件结构解析，先理解端口、节点、策略组与规则之间的引用，再处理客户端特有的覆写功能。

08 · Scenario Guide

按设备与使用场景完成协议选择

桌面日常使用：稳定基线优先

Windows 与 macOS 桌面设备适合先建立一个长期稳定的默认策略组。若服务端提供 Shadowsocks、Trojan 或成熟的 VMess 节点，可以从字段较完整、连接稳定的一类开始；VLESS、Hysteria2 与 TUIC 则作为明确支持后的候选。默认组不需要包含所有节点，数量过多会增加选择成本，也会让自动测试频繁建立连接。可以按协议或用途拆分策略组，再由上层组选择。

客户端方面，Clash Plus 可作为全平台首选，Clash Verge Rev 适合需要桌面端规则、订阅和 mihomo 设置界面的用户。迁移自旧客户端时，先导入订阅和基础规则，不要立刻复制全部应用设置。确认系统代理端口、DNS 和节点可用后，再根据需要开启 TUN。这样可以把系统权限问题与协议连接问题分开。

办公、会议与即时通信更重视连续性。应选择长连接稳定、网络恢复可靠的节点，而不是峰值最高的节点。大文件下载或同步可以放入单独策略组，允许选择吞吐更高但资源占用也可能更明显的 Hysteria2、TUIC 或其他节点。通过规则把不同应用分配到不同策略，比频繁手动切换全局节点更可控。

手机和平板：先看切网与后台恢复

移动端首要测试项目是 Wi-Fi 与蜂窝网络切换、锁屏后恢复、弱信号下重连和系统 VPN 稳定性。协议在固定 Wi-Fi 下速度很高，但切换网络后需要手动重连，就不适合作为默认移动节点。SS、Trojan 等成熟组合可以作为基线；Hysteria2 与 TUIC 若在实际移动网络中能保持稳定，则可用于对吞吐和恢复有要求的任务。

电量比较应至少覆盖一个完整工作周期，并保持代理模式一致。节点探测间隔过短、策略组自动测试过于频繁、日志持续写入和大量后台应用流量，都可能放大耗电。先减少自动测试频率并关闭不必要的调试日志，再比较协议。否则得到的结论主要反映客户端设置，而不是节点类型。

iOS 与 Android 的后台策略不同，客户端可用功能也不同。不要把桌面端 YAML 中的所有 TUN、网卡和脚本参数直接复制到移动端。订阅只保留节点和共同支持的策略，平台权限和 DNS 由移动客户端本地管理。iOS 用户可以在下载页选择 Clash Plus 的 App Store 入口；Android 还可根据界面偏好和配置兼容性比较 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard。

路由器与常驻设备：资源和可维护性优先

路由器、家庭服务器和小型 Linux 设备需要先确认 CPU 架构、内存、存储与系统服务管理方式。独立 mihomo 内核适合熟悉命令行、配置文件和服务日志的用户；普通桌面用户更适合 GUI 客户端。低功耗设备上，规则集规模、连接并发和 DNS 缓存可能比 GUI 有无更影响资源使用。

协议选择应以设备能够持续处理的吞吐为上限。Hysteria2 或 TUIC 在链路条件合适时可能提供良好传输表现，但用户态 QUIC 处理会占用 CPU；如果设备处理能力不足，SS 或其他较轻组合反而更稳定。可在传输过程中查看 CPU 单核占用、软中断和内存，确认瓶颈位于设备、线路还是服务端。

常驻设备更需要可回退配置。保留一份经过验证的基础 YAML，并将实验性协议放入单独策略组。更新内核前先执行配置检查，更新后依次验证 DNS、节点、规则和局域网访问。不要同时更新内核、订阅、规则集和系统网络组件。分批变化看似耗时，实际能显著减少故障定位时间。

一套可重复执行的决策流程

第一步，列出订阅真实提供的协议和当前客户端内核，不在客户端中自行猜测或转换节点。第二步，按网络路径分组：TCP 类节点作为基础候选，Hysteria2 与 TUIC 归入需要验证 UDP 的候选。第三步，检查协议所需字段是否完整，尤其是 TLS、SNI、UUID、密码、传输路径和服务名。第四步，用固定目标测试连接建立、持续吞吐、切网恢复和资源占用。

第五步，根据设备选择默认节点。桌面端优先稳定和持续运行；移动端优先后台恢复与电量；路由设备优先资源上限和服务管理。第六步，把有明显优势但适用范围较窄的节点放入专用策略组，例如下载、流媒体或大流量同步。第七步，记录当前可用配置与测试条件，以便订阅或内核变化后重新对照。

如果结果差异很小，应选择字段更清晰、多个设备都支持、维护成本更低的方案。协议选型的目标不是找到理论上最复杂的组合，而是在现有服务端、网络和设备条件下获得可解释、可恢复、可迁移的连接。一个能够稳定工作并且容易排错的配置，通常比依赖大量特定扩展的配置更适合作为长期基线。

完成选型后，可以返回Clash Verge Rev 教程按步骤导入订阅、选择规则模式并验证连接；需要进一步调整规则顺序时，可阅读Clash 流量分流配置与策略组实战。如果客户端仍报告配置错误，应保存原始日志中的第一条错误信息，再到常见问题页按配置解析、连接建立、DNS 和系统代理四个方向排查。