Clash 协议与内核技术参考

一、建立协议选型框架

先区分协议、传输层与客户端

Clash 客户端是配置和流量调度入口，协议则规定客户端如何与远端服务通信。两者处于不同层次。配置文件中的 type 决定代理节点类型，例如 ss、vmess、trojan、vless、hysteria2 或 tuic；内核读取这一字段，再调用对应实现建立连接。图形客户端负责订阅导入、代理组选择、规则管理、系统代理和 TUN 开关，但真正执行协议握手、加密、复用与数据转发的是内核。

同一种协议还可能组合不同传输方式。VMess 与 VLESS 常见 TCP、WebSocket、gRPC 等承载方式，TLS 又是其中独立的一层。Trojan 通常直接建立在 TLS 之上。Hysteria2 与 TUIC 则以 QUIC 和 UDP 为基础。看到“VLESS + WebSocket + TLS”时，应将其拆成三部分理解：VLESS 负责认证与协议语义，WebSocket 负责数据封装，TLS 负责加密和服务端身份验证。任何一层参数不一致，都可能表现为连接失败。

客户端名称同样不能代替内核名称。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等属于用户直接操作的图形客户端，它们可能集成 mihomo，也可能因平台和发行方式而使用不同构建。选择客户端时需要确认其内核类型、更新机制和目标平台；选择协议时则应确认当前内核是否实现该协议及其扩展字段。只看界面相似度，无法判断底层兼容范围。

四个优先判断条件

第一项是配置来源。若服务提供方已经给出可用订阅，应优先使用订阅声明的协议与参数，不要在客户端里把 SS 节点手工改成 Trojan，也不要只替换 type 字段。不同协议的认证材料、传输参数和握手过程并不相通，名称修改不会完成协议转换。第二项是内核支持。较新的 Hysteria2、TUIC 和部分 VLESS 扩展通常需要 mihomo 或兼容实现，旧版原版 Clash 无法完整读取这些字段。

第三项是网络条件。稳定、低丢包的固定网络通常能让 TCP 类协议保持平稳表现；波动较大、存在一定丢包的移动网络，可能更适合具备现代拥塞控制与快速恢复能力的 QUIC 类方案。但 UDP 可达性、运营网络策略和路由设备实现会影响 QUIC 表现，不能仅凭协议标签预设结果。第四项是设备限制。移动设备更关注持续唤醒、后台保活、握手频率和无线模块活动时间；服务器或路由器更关注并发连接、内存上限和转发效率。

为什么测速不能直接给出结论

一次下载测试通常只覆盖单个时段、单条路径和有限连接数。TCP 慢启动、QUIC 拥塞窗口、DNS 解析、目标站点连接复用、服务器当前负载都会改变测试结果。短测试更偏向握手与首包表现，长测试更容易反映持续吞吐和拥塞恢复。网页浏览关注的是 DNS、握手、首字节与小对象并发；大文件传输更关注稳定吞吐；实时音视频更关注抖动、丢包恢复和 UDP 转发。不同任务不能只用同一个峰值数字概括。

更可靠的方法是在相同设备、相同规则、相同目标和接近的时间段内进行多轮对比，同时观察连接成功率、首次打开时间、长连接稳定性和设备温升。若某协议只有个别时段明显异常，应继续检查路径与服务端状态，而不是立即判定协议本身存在缺陷。协议选型最终应以持续可用、配置易维护和设备负担可接受为准。

二、SS、VMess、Trojan 与 VLESS 的设计取舍

Shadowsocks：结构简洁的加密代理协议

Shadowsocks 通常简称 SS，其核心目标是以相对简洁的方式完成加密转发。客户端根据密码和加密方法派生会话所需材料，再通过 TCP 或 UDP 与服务端通信。由于协议结构较轻，成熟实现通常具有较低的处理开销，配置项也容易理解。常见节点至少包含服务器地址、端口、密码和加密方法；现代配置应选择由服务端明确提供、且当前内核支持的 AEAD 或 2022 系列方法，客户端与服务端的加密方法必须完全一致。

SS 的优势是实现广泛、资源需求相对可控、跨平台兼容基础较好。它适合希望减少配置层次、关注稳定转发和设备资源的场景。限制在于，SS 本身并不等于 TLS，也不包含 VLESS、VMess 那套传输扩展语义。部分订阅会额外声明插件参数，插件必须由客户端和服务端共同支持；如果订阅包含插件而内核不识别，节点即使显示在列表里也可能无法建立连接。

排查 SS 时应首先核对加密方法拼写、密码、服务器端口和 UDP 开关。若 TCP 页面可访问而 UDP 应用异常，应确认节点、代理组和客户端内核是否同时允许 UDP。若配置由订阅生成，不建议手工替换加密方法，因为服务端不会随客户端设置自动变化。SS 的简洁性来自较少的协议层，而不是可以省略参数一致性检查。

VMess：带时间校验与用户标识的完整协议

VMess 源自 V2Ray 生态，使用用户标识和协议握手组织连接，通常还会与 TCP、WebSocket、HTTP/2 或 gRPC 等传输方式组合。它的配置比 SS 更具层次：除服务器、端口和用户标识外，还可能包含安全选项、网络类型、路径、主机名、TLS 开关和服务器名称。VMess 曾广泛用于需要多种传输组合的部署，因此许多通用订阅和旧配置仍包含大量 VMess 节点。

VMess 对系统时间偏差较敏感。设备时间明显不准确时，认证阶段可能失败，而界面只显示超时或握手错误。排查时应确保操作系统启用自动时间同步，并检查时区与时间是否正常。另一个高频问题是把 WebSocket 路径、Host 请求头和 TLS 服务器名称混为一项：路径是 WebSocket 请求位置，Host 是 HTTP 层字段，服务器名称用于 TLS 证书验证，它们可能相同，也可能由服务端分别指定。

VMess 的功能较完整，但协议处理和配置复杂度通常高于纯 SS。对于已有且运行稳定的 VMess 订阅，没有仅因协议较早就必须迁移的理由；新配置则应根据服务端支持、内核兼容和维护方案决定。实际表现主要取决于承载方式与网络路径。例如 VMess over WebSocket 会增加封装和握手层次，而直接 TCP 的路径更短，但两者适用的服务端架构不同，不能只以协议名比较。

Trojan：以标准 TLS 连接为基础

Trojan 将认证与数据转发放在 TLS 连接中，客户端需要服务器地址、端口、密码，并通常需要正确的服务器名称。TLS 握手会验证证书与目标名称是否匹配，因此系统时间、证书链、SNI 和服务端配置都会影响连接结果。Trojan 的配置概念相对直观，但“使用 TLS”并不意味着可以忽略证书检查。关闭证书验证会削弱服务端身份确认，只适合受控测试，不应作为长期解决超时或名称错误的默认办法。

Trojan 常见问题集中在服务器名称与地址的关系。节点地址可以是域名或 IP，而 sni 通常应填写证书覆盖的域名。若订阅已经给出 sni，应保留该值。ALPN 等高级参数也必须与服务端协商范围一致。对于普通用户，优先使用订阅下发的完整参数，比在图形界面中逐项猜测更可靠。

从性能角度看，Trojan 需要完成 TLS 握手，但现代实现可通过连接复用、会话恢复和长连接降低重复成本。在稳定网络中，握手开销通常集中在连接建立阶段；频繁创建短连接、移动网络反复切换或后台连接被系统回收时，重连成本更明显。因此评估 Trojan 时应同时观察首次连接与持续使用，而不是只看已建立长连接后的吞吐。

VLESS：精简认证层与可组合传输

VLESS 同样来自 V2Ray 生态，设计上减少协议自身承担的加密职责，通常依赖 TLS 或其他受支持的安全层提供机密性与服务端验证。配置常包含用户标识、传输方式、TLS 设置、服务器名称，以及由具体内核支持的扩展字段。VLESS 本身不是某一种固定传输，它可以组合 TCP、WebSocket、gRPC 等方式，因此讨论“VLESS 是否更快”时必须说明承载形式和安全层。

VLESS 配置的兼容难点在于扩展能力。不同内核对 Reality、流控标记、客户端指纹、传输细节等字段的支持范围可能不同。原版 Clash 无法覆盖许多现代 VLESS 配置，而 mihomo 对相关协议与扩展提供了更完整的适配。订阅可成功导入并不代表所有字段都被执行；某些转换服务可能保留基础字段却丢失扩展参数，最终表现为节点存在但连接失败。

SS、VMess、Trojan 与 VLESS 都可能使用 TCP 作为底层承载，但它们的认证、加密责任和扩展方式并不相同。SS 侧重轻量加密转发，VMess 提供完整协议握手与多种承载组合，Trojan 以 TLS 为基础组织认证，VLESS 则将更多安全责任交给外层并保留组合能力。选择时应服从服务端配置和内核支持，而不是将某个协议视为其他协议的直接替代品。

三、Hysteria2 与 TUIC：基于 QUIC 的连接模型

QUIC 改变了哪些传输行为

Hysteria2 与 TUIC 都建立在 UDP 和 QUIC 能力之上。QUIC 在用户态组织可靠传输、加密握手与多路流，能够避免传统 TCP 连接中不同逻辑流完全共享同一队头阻塞状态。某一条流发生丢包时，其他流不必总是等待同一序列中的缺失数据，这对并发请求和存在抖动的网络有实际价值。QUIC 还将 TLS 语义纳入连接建立过程，减少协议层之间重复协商的空间。

这种模型不代表 UDP 天然比 TCP 快。UDP 只提供数据报传送，可靠性、拥塞控制、重传和流管理由 QUIC 实现承担。性能取决于具体实现、拥塞控制参数、路径 MTU、服务端带宽和网络对 UDP 的支持。若本地网络阻断或严格限制 UDP，Hysteria2 与 TUIC 可能直接无法连接；若 UDP 路径质量良好且存在一定丢包，它们则可能比反复触发 TCP 拥塞恢复的方案更平稳。

QUIC 运行在用户态，带来快速迭代和灵活控制，也意味着加密、数据包调度和重传处理会占用 CPU。桌面设备通常更容易消化这部分成本，移动设备和低功耗路由器则需要关注持续高吞吐时的温升与电量。协议的网络效率和设备能效不是同一个指标：更快完成传输可能让无线模块更早休眠，但较高的持续 CPU 负载也可能抵消这部分收益。

Hysteria2 的带宽与拥塞控制思路

Hysteria2 面向高延迟、存在丢包或带宽波动的路径，配置通常包含服务器地址、认证信息、TLS 服务器名称，以及可选的上传和下载带宽提示。带宽值不是客户端测速结果，也不是强制保证，它用于帮助拥塞控制建立合适的发送行为。填写远高于实际链路能力的值，可能造成队列积压和丢包；填写过低则会主动限制可用吞吐。没有明确依据时，应优先使用服务端或订阅提供的配置。

Hysteria2 的认证字段可能以字符串形式出现，TLS 相关字段仍要求服务器名称与证书配置一致。部分配置会包含混淆或端口跳跃等扩展，但这些能力需要服务端、客户端内核和配置格式三方同时支持。通用订阅转换器若不认识扩展字段，可能只输出一个基础节点，导致导入后无法连接。此时应检查原始 YAML，而不是在图形界面里连续切换代理模式。

路径 MTU 是 QUIC 类连接中容易忽略的因素。若链路中某一段无法承载较大的 UDP 数据报，而分片或路径发现又工作异常，连接可能表现为握手成功但大流量停滞、部分站点打开而下载中断。排查时可先关闭额外传输层、恢复订阅原始参数，再换到另一网络对比。若只有某个局域网或路由器下异常，应继续检查路由器 UDP 会话、MTU 与防火墙策略。

TUIC 的多路复用与移动切换

TUIC 同样基于 QUIC，强调低延迟连接、多路流和高效转发。配置常见服务器地址、端口、用户标识、密码、TLS 服务器名称、拥塞控制算法和 UDP 中继模式。不同 TUIC 协议代际的字段可能不同，客户端与服务端必须使用兼容实现。若订阅只写“TUIC”而未保留所需认证字段，内核无法通过猜测补全。

QUIC 具有连接迁移相关能力，但客户端、操作系统和具体协议实现是否利用该能力，需要结合实际版本和平台判断。手机从无线局域网切换到蜂窝网络时，本地地址会变化；理想情况下连接可以更快恢复，但系统后台限制、VPN 接口重建、DNS 更新和客户端生命周期仍可能触发完整重连。因此不能把 QUIC 的连接迁移等同于所有移动端应用都能保持会话。

TUIC 的拥塞控制选项不应随意照抄其他人的配置。算法需要与网络路径和服务端能力匹配，某些实现会提供默认值，订阅也可能明确指定。对普通使用者而言，先保留订阅值，再通过长期稳定性观察是否需要调整，比只追求测速峰值更可靠。若发生高负载时延迟突然增加，应检查上行是否被占满、路由器是否出现 UDP 队列堆积，以及带宽管理是否与 QUIC 流量发生冲突。

何时不必优先选择 QUIC 类协议

固定网络稳定、TCP 节点已持续可靠、设备算力有限，或所在环境的 UDP 行为不可预测时，没有必要仅因协议较新就强制切换。路由器上的低功耗处理器需要同时承担 NAT、DNS、规则匹配和加密转发，QUIC 用户态处理可能更早触及 CPU 上限。移动设备若主要进行轻量网页访问，QUIC 的吞吐优势也未必能抵消后台连接和加密处理成本。

反过来，当网络存在明显抖动、长距离链路偶发丢包、应用包含较多并发流，并且 UDP 路径稳定时，可以将 Hysteria2 或 TUIC 纳入候选。正确方法是保留一个工作稳定的 TCP 类节点作为对照，在相同规则和相近时段下观察数日，而不是用一次短测速决定长期默认节点。

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

把速度拆成四个阶段

用户感知的“速度”至少包含名称解析、连接建立、首字节到达和持续传输四个阶段。DNS 决定目标地址如何获得；客户端与代理服务端完成协议和安全握手；服务端再与目标建立连接；最后进入稳定数据传输。网页打开慢而下载正常，问题可能在 DNS、握手或小对象并发。下载开始快但随后波动，则更可能涉及拥塞控制、丢包、服务端限速或本地无线质量。

SS 的协议处理相对直接，在 CPU 较弱的设备上容易保持可预测开销。Trojan 需要 TLS 处理，但成熟 TLS 库通常具有良好优化。VMess 和组合式 VLESS 配置的开销受传输层影响显著，WebSocket、gRPC 与额外 TLS 会增加封装和内存缓冲。Hysteria2 与 TUIC 需要在用户态维护 QUIC 状态、流和重传，CPU 使用可能更高，但在特定丢包路径上也可能更快完成任务。

连接复用会改变短连接成本。若多个请求共享一条已建立连接，可以减少重复握手和系统调用；但过度复用也可能让大量逻辑流集中在单一连接中，当该连接异常时影响范围更大。不同内核对复用的实现和默认值不完全相同，不应从其他工具复制参数后直接套入 mihomo。只有在确认服务端支持、问题可复现且有明确测量方法时，才适合调整复用选项。

CPU、内存与并发连接

协议资源占用不能只看空闲时的任务管理器数字。实际负载与吞吐、连接数、规则数量、DNS 模式、日志级别和 TUN 转发共同相关。高吞吐会增加加密和数据复制工作；大量短连接会增加握手与连接表维护；复杂规则集会增加匹配过程；详细日志持续写入也会带来额外 I/O。比较协议时必须保持其他配置一致，否则测到的是整个客户端配置差异。

桌面系统通常拥有更宽松的内存与调度空间，Clash Plus、Clash Verge Rev、FlClash 或 Clash Nyanpasu 的界面进程还会带来各自的图形运行时开销。评估内核时应区分界面进程和内核进程。Linux 服务器直接运行 mihomo 内核时，资源构成更单纯；路由器则需预留系统服务、连接跟踪表和 DNS 缓存所需内存。内存接近上限时，任何协议都可能因系统回收或进程终止而不稳定。

并发连接数量与单连接吞吐不是同一指标。网页、软件更新和同步工具可能建立许多连接，即使总流量不高，也会增加文件描述符、连接状态和 DNS 查询。QUIC 多路流可以把多个逻辑流放入较少的底层连接，但内核仍需维护每条流的状态。SS、Trojan 等方案也可以借助内核级复用降低连接数量，不过服务端和客户端设置必须一致。

移动端耗电由哪些因素组成

移动端电量主要受无线模块活跃时间、CPU 唤醒、后台保活、数据传输量、VPN 接口处理和网络切换影响。协议加密算法只是其中一部分。持续低速传输可能让无线模块长时间保持高功耗状态；较高吞吐若能快速完成任务，反而可能更早进入休眠。与此同时，复杂握手、频繁重连和高强度用户态加密也会增加处理器工作，因此不能简单地将“更快”直接换算为“更省电”。

Android 上使用 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard 时，系统通常通过 VPN 服务接管流量。省电策略可能限制后台进程，导致锁屏后连接被回收；恢复屏幕后客户端需要重新建立代理连接。iOS 客户端受 Network Extension 生命周期管理，后台行为与桌面系统不同。移动端比较协议时应在相同系统设置、相同信号条件和相似使用强度下观察，而不是同时更换客户端与协议。

TCP 类长连接在稳定网络中通常具有成熟的系统级优化。QUIC 类连接可能在网络抖动与切换时减少部分恢复等待，但用户态数据处理也可能增加 CPU 活动。轻量浏览、消息同步和长时间待机更应关注后台稳定与唤醒次数；视频、大文件和云同步则更关注单位任务完成时间与温升。若设备持续发热，应先检查是否有异常重试、DNS 循环、日志高频写入或 TUN 路由冲突，不要只替换协议。

一套可重复的比较方法

先选择两个服务端位置和线路条件接近的节点，确保仅协议或传输方式不同。固定客户端、内核、规则模式、DNS 配置和网络环境，关闭会干扰结果的后台下载。第一轮测试冷连接，记录首次打开与连接失败情况；第二轮测试持续传输，观察吞吐稳定性；第三轮测试多应用并发；移动端再增加锁屏恢复和无线网络切换。每轮在不同时段重复，避免单次服务端负载造成误判。

结果应以“是否满足任务”记录，而不是只排列峰值。例如网页首开稳定、视频不中断、锁屏恢复正常、设备温升可接受，通常比某次吞吐高出少量更重要。若两个协议都能满足使用需求，应优先选择配置更简单、客户端支持更完整、服务端维护更明确的一项。稳定和可解释性本身就是重要性能指标。

五、原版 Clash、Clash.Meta 与 mihomo 的内核关系

原版 Clash 的定位与边界

原版 Clash 奠定了配置文件、代理组、规则匹配、DNS 与控制接口等核心使用方式。大量 YAML 字段和客户端交互模型都由这一生态普及。它能够处理 SS、VMess、Trojan 等常见类型，并通过规则决定请求走代理、直连或拒绝。许多教程中的 proxies、proxy-groups、rules 结构至今仍然适用。

原版项目停止持续演进后，其协议支持和平台适配停留在既有范围。较新的 VLESS 扩展、Hysteria2、TUIC、规则提供器增强、TUN 与 DNS 新能力通常不应假设原版内核可用。旧客户端即使可以导入一份现代订阅，也可能忽略未知字段、跳过节点或在启动时报告配置错误。保留旧版客户端只适合维护已有环境，不适合作为现代协议选型的默认基线。

Clash for Windows 属于已停止维护的图形客户端，历史上与原版 Clash 生态关系紧密。它仍可能出现在旧配置说明中，但面对新订阅和新协议时兼容范围有限。需要下载当前维护的客户端时，应优先从客户端列表选择 Clash Plus，或按平台考虑 Clash Verge Rev、FlClash、Clash Nyanpasu 等方案。

Clash.Meta 扩展了什么

Clash.Meta 在兼容 Clash 配置结构的基础上扩充协议、规则、DNS、TUN 和平台网络能力。它让用户继续使用熟悉的代理组与规则语法，同时支持更多节点类型和现代传输。许多标注“Meta 内核”的客户端由此获得 VLESS、Hysteria、TUIC 等扩展能力。配置层面仍以 YAML 为主，但新增字段只有 Meta 系列实现能够识别。

“兼容 Clash 配置”不等于所有方向都完全可逆。原版 Clash 配置通常较容易由 Meta 系列读取；包含 Meta 扩展的配置则不能保证回到原版内核后继续工作。具体风险包括未知节点类型、额外 DNS 字段、TUN 参数、规则提供器行为和代理组扩展。迁移时应把兼容理解为“基础结构延续”，而不是“任何字段都能跨内核互换”。

一些订阅转换工具会提供 Clash 与 Clash.Meta 两种输出目标。若订阅包含 VLESS、Hysteria2 或 TUIC，应选择面向 Meta 或 mihomo 的格式；选择旧 Clash 模板可能导致这些节点被删除或降级。若订阅只包含 SS、VMess 和 Trojan，两个输出目标在基础节点上可能都能读取，但 DNS 与规则部分仍需核对。

mihomo 是当前延续的内核名称

mihomo 是 Clash.Meta 后续使用的内核名称，延续其配置体系和扩展能力。实际客户端界面可能仍显示“Meta”字样，配置文档也常将二者并列提及。判断时应查看客户端的内核信息或项目说明，不要只根据界面品牌猜测。对于新安装和现代协议，mihomo 通常是更合适的兼容基线。

mihomo 负责协议连接、DNS、规则匹配、代理组、TUN 和控制接口。图形客户端在其外层提供配置管理、系统托盘、订阅更新和平台权限处理。客户端更新与内核更新可能采用不同节奏：界面版本变化不一定意味着内核功能变化，内核更新也可能由客户端静默集成。因此遇到新协议无法识别时，应同时确认客户端发行状态和实际内核信息。

服务器或路由器用户也可以直接部署 mihomo 内核，不使用桌面图形界面。这种方式便于通过配置文件和系统服务管理，但要求用户自行处理权限、日志、启动顺序、DNS 端口和防火墙。普通桌面或移动端用户更适合使用完整客户端，因为系统代理、TUN 权限和订阅管理已经由界面封装。

配置迁移的安全顺序

从旧客户端迁移到 mihomo 客户端时，先保留原配置副本，再导入订阅或 YAML，不要立即覆盖旧文件。启动后检查配置解析日志，确认代理节点数量、代理组名称和规则提供器均已载入。然后测试一个基础 TCP 节点，再测试 Hysteria2 或 TUIC 等扩展节点。最后开启系统代理或 TUN，避免在配置尚未通过时同时引入系统路由变量。

若配置解析失败，应从日志指出的字段或行号着手。YAML 对缩进敏感，Tab、重复键、引号和冒号位置都可能导致错误。若配置可加载但个别节点缺失，应检查节点类型与字段是否属于当前内核支持范围。若所有节点正常但规则行为变化，再核对规则顺序、规则集格式和 DNS 模式。将迁移过程拆成解析、节点、代理组、规则、系统接管五个阶段，可以明显缩小问题范围。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "Example-SS"
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "Example-SS"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,节点选择
  - MATCH,节点选择

以上片段用于说明基础结构，示例地址属于文档用途。真实节点参数应由服务端或订阅提供。配置可以被 mihomo 读取，不代表示例节点能够连接；实际部署时还需根据平台补充 DNS、TUN 或控制接口设置。

六、订阅格式、YAML 字段与转换兼容性

订阅链接返回的内容并不只有一种

用户在客户端中粘贴的“订阅链接”只是获取配置的入口，返回内容可能是完整 Clash YAML、Base64 编码的通用节点列表、单个分享链接集合，或由服务端根据客户端标识动态生成的格式。客户端能否导入，取决于其订阅解析器是否认识返回内容。链接能在浏览器中打开，不代表内容就是 Clash 配置；链接显示一段难以阅读的字符，也不代表数据损坏。

完整 Clash YAML 通常包含 proxies、proxy-groups 和 rules，有时还包含 DNS、规则提供器与端口设置。通用订阅可能只有节点，没有代理组和规则，客户端导入后需要自行生成默认组。分享链接则以协议方案开头，例如 ss://、vmess://、trojan:// 或 vless://。Hysteria2 与 TUIC 也有各自表达方式，但不同客户端对单链接与批量订阅的支持范围不完全一致。

更完整的说明可参考订阅链接格式与导入方法。本页重点是兼容性判断：若订阅服务能够直接输出 mihomo 或 Clash.Meta YAML，应优先选择该格式，因为它能保留代理组、规则和现代协议字段；若只能获取通用节点列表，则需要客户端或转换器补充组与规则。

YAML 中决定节点可用性的字段

所有节点都需要名称、类型、服务器和端口，但不同协议还要求各自的认证字段。SS 使用密码与加密方法；VMess 通常使用用户标识，并可能声明 alterId、安全选项和传输网络；Trojan 使用密码及 TLS 服务器名称；VLESS 使用用户标识、安全层和传输扩展；Hysteria2 使用认证、SNI 及可选带宽参数；TUIC 常包含用户标识、密码、SNI、拥塞控制和 UDP 中继设置。

字段名称必须符合目标内核语法。某个应用导出的 JSON 配置不能直接复制进 Clash YAML，因为层级和命名规则不同。即使两个工具都支持 VLESS，它们也可能分别使用不同字段表达传输、安全层与指纹。可靠做法是使用目标内核认可的订阅模板，或根据 mihomo 文档逐项转换，并在启动日志中确认配置解析结果。

YAML 字符串包含冒号、井号、花括号或特殊前缀时，使用引号可以降低解析歧义。缩进应使用空格并保持层级一致。节点名称如果被代理组引用，文字必须完全相同，包括空格和大小写。订阅更新后节点名称发生变化，手写代理组可能引用旧名称，表现为代理组为空或回退到其他项。规则目标也必须对应现有代理组名称。

订阅转换会丢失什么

转换过程通常需要把来源字段映射到目标字段。基础 SS、VMess、Trojan 节点较容易映射，但现代 VLESS 扩展、Hysteria2 带宽选项、TUIC 中继模式、客户端指纹和特定传输参数可能因模板能力不足而丢失。转换结果能通过 YAML 语法检查，只说明文本结构有效，并不说明协议语义完整。

判断转换是否完整，可以对照原始节点和输出 YAML：节点类型是否保留，服务器与端口是否一致，认证字段是否存在，TLS 是否开启，SNI、路径、Host、ALPN、指纹和协议扩展是否仍在。对于 Hysteria2 和 TUIC，还应检查 UDP、拥塞控制及认证字段。若转换后某一整类节点消失，通常是输出目标选择了旧 Clash 格式，或转换器不支持该协议。

避免多次串联转换。每增加一次转换，都可能重新命名节点、重建代理组或删除未知字段。最理想的路径是订阅源直接输出 mihomo 配置；其次是从原始通用订阅转换一次；不建议先转换成旧 Clash，再转换成 Meta。若必须维护自定义规则，可将节点订阅与本地规则通过客户端支持的覆写或规则提供器机制组合，减少每次更新后手工修改整份文件。

订阅更新与本地修改的关系

大多数客户端在更新订阅时会重新下载远端内容。本地直接编辑订阅生成的配置，可能在下一次更新时被覆盖。需要长期保留的规则、DNS 或代理组调整，应使用客户端提供的覆写、合并配置或脚本机制；如果客户端没有此能力，则复制为本地配置并自行管理更新，但节点变更也需要手工同步。

订阅更新失败时，先区分下载失败与解析失败。下载失败通常与链接有效性、系统时间、DNS 或当前网络有关；解析失败则会在日志中出现 YAML 行号、未知类型或字段错误。若旧配置仍能连接而更新失败，不要立即删除旧文件。保留上一份可用配置，可以在排查期间继续对照节点字段和代理组结构。

客户端之间迁移订阅时，不要只复制缓存文件路径。不同客户端对配置目录、覆写规则和内核参数的组织不同。更稳定的方式是重新导入原订阅链接，再迁移必要的本地规则。若使用本地 YAML，应确认路径权限、文件编码和换行符正常。Windows 上的路径反斜线若出现在 YAML 字符串中，应通过引号和正确转义避免被错误解释。

七、客户端、操作系统与协议支持选择

图形客户端首先看内核与平台集成

协议支持由内核决定，但日常可用性也取决于客户端如何管理内核。Windows 和 macOS 客户端需要处理系统代理、服务模式、TUN 权限、开机启动和托盘状态；Android 与 iOS 依赖系统 VPN 接口；Linux 桌面还涉及桌面环境、系统代理变量和权限。一个协议在命令行内核中可用，不代表图形客户端已经为它提供完整的导入、编辑与错误提示。

Clash Plus 是全平台优先选择，适合希望在 Windows、macOS、Android 与 iOS 间保持相近操作逻辑的用户。Windows 与 macOS 还可考虑 Clash Verge Rev、FlClash；Windows 可使用 Clash Nyanpasu；Android 可选择 Clash Meta for Android、FlClash 或 Surfboard；Linux 桌面常用 Clash Verge Rev 与 FlClash，也可以直接部署 mihomo。Clash for Windows 与 ClashX Meta 已停止维护，更适合处理历史配置，不应作为现代协议的首选环境。

选择客户端时应查看三个事实：集成的内核是否支持订阅中的节点类型，系统接管方式是否满足需求，订阅与配置管理是否清晰。界面主题、窗口布局和托盘样式属于使用偏好，不能替代协议兼容性判断。完整客户端列表及系统要求可在客户端对比和获取客户端页面查看。

Windows 与 macOS

Windows 上的系统代理主要影响遵循系统代理设置的应用，部分 UWP 应用、游戏或自带网络栈的软件可能需要 TUN 或额外系统设置。协议连接成功但特定应用不走代理时，应先判断流量是否进入内核，而不是更换节点协议。TUN 模式通过虚拟网络接口接管更广范围的流量，需要相应权限和正确路由。关于 Windows 安装、系统代理与常见错误，可阅读Windows 安装配置全流程。

macOS 同样区分系统代理与虚拟网络接管。Apple Silicon 与 Intel 安装包架构不同，但配置文件中的协议语义一致。若客户端可以启动而内核进程立即退出，应查看架构、执行权限和配置解析日志。Trojan、VLESS、Hysteria2 等涉及 TLS 的协议还依赖系统时间和服务器名称，时间异常会同时影响多个节点。

桌面端适合进行更完整的日志排查。先将日志级别设为 info，复现一次连接问题，记录是 DNS、协议握手、TLS、超时还是规则选择错误。不要长期使用过高日志级别，因为大量日志会增加磁盘写入并使关键信息更难识别。问题定位完成后恢复常规级别。

Android 与 iOS

Android 客户端通常创建本地 VPN 服务，将应用流量送入内核。系统省电策略、后台运行权限和常驻通知会影响持续连接。若锁屏一段时间后连接中断，而打开客户端后恢复，应检查系统是否限制后台活动。若只有个别应用不经过代理，检查分应用代理、绕过设置和规则命中情况。协议本身通常不是第一排查项。

iOS 上的客户端使用系统网络扩展，应用能够使用的内存和后台生命周期受系统管理。Clash Plus 通过 App Store 提供 iOS 版本，并在 clashplus.io 提供产品信息。移动端不适合导入体积过大的规则集合后持续开启详细日志，这会增加内存与处理压力。规则需求较复杂时，应优先使用经过整理的规则集，并减少重复条目。

移动网络切换会改变本地地址、DNS 与可用传输。TCP 节点可能需要重建连接，QUIC 类协议可能更快恢复，但仍受系统 VPN 接口和客户端生命周期影响。比较移动端协议时，至少测试无线局域网、蜂窝网络、锁屏恢复和网络切换四种状态。只在桌面测速正常，无法证明移动端配置同样稳定。

Linux、服务器与路由器

Linux 桌面可使用图形客户端，也可直接运行 mihomo。图形客户端适合订阅和桌面代理管理；直接运行内核适合服务器、容器和路由器。命令行部署需要明确配置目录、工作目录、日志输出和服务用户。配置文件应先在前台启动验证，再交给 systemd 等服务管理器，避免启动失败后只能看到重复重启。

路由器部署还涉及转发链、DNS 接管、局域网访问和连接跟踪。Hysteria2 与 TUIC 对 UDP 路径有要求，低功耗设备还需关注 CPU。若路由器内核运行正常但局域网设备无法访问，应检查监听地址、允许局域网连接、系统防火墙与客户端网关，而不是直接修改协议认证。部署思路可参考路由器与旁路由部署概览。

服务器环境应优先保证可恢复性。保留一份已验证配置，更新内核前记录当前启动参数，修改协议节点后先执行配置检查或前台启动。若新配置失败，可以快速回退。对于多设备共享的路由环境，稳定的 SS、Trojan 或既有 TCP 节点常比频繁调整协议更容易维护；只有在明确需要改善丢包路径或 UDP 应用时，再评估 QUIC 类方案。

八、按使用场景完成协议决策与故障定位

日常网页与办公应用

日常网页、文档协作和消息应用通常更重视连接成功率、首字节时间和长期稳定，而不是单连接峰值。已有 SS、Trojan 或 VMess 节点稳定运行时，可以继续使用，不必仅因出现较新协议而迁移。若需要新建配置，优先选择订阅原生提供、客户端完整支持且参数层次较少的节点。规则模式下还要确认目标请求命中了预期代理组。

浏览器正常而其他应用异常，首先检查系统代理覆盖范围。系统代理只影响遵循该设置的程序，TUN 才负责更广泛的流量接管。浏览器首开缓慢但后续正常，应分别检查 DNS 和握手；所有协议同时解析失败，更可能是 DNS 配置或系统网络问题。只有某一协议失败，则按该协议的认证、TLS 或 UDP 条件继续排查。

规则配置需要遵循从具体到兜底的匹配顺序。域名后缀、规则集和地理规则命中后便停止继续匹配，最终由 MATCH 处理未命中流量。若节点连接测试正常但应用走错路径，应查看连接列表中的规则与代理组，而不是重复更新订阅。规则分流的完整写法可参考Clash 规则分流配置实战。

视频、大文件与高吞吐任务

持续传输应优先比较服务端可用带宽、线路稳定性和拥塞恢复。稳定低丢包网络中，SS、Trojan、VLESS 或 VMess 都可能获得良好吞吐，协议差异通常小于线路差异。存在明显丢包且 UDP 路径良好时，可以测试 Hysteria2 或 TUIC，但应观察长时间吞吐、缓冲中断和设备温升，而不是只看开始阶段。

高吞吐异常时，先确认本地无线信号和上行是否被其他任务占满，再比较直连网络与代理路径。若所有节点在同一速度附近触顶，可能是本地网络、服务端带宽或设备 CPU 限制。若只有 QUIC 类连接波动，应检查 UDP、MTU 与带宽参数；若只有 WebSocket 或 gRPC 节点异常，应核对路径、Host、TLS 名称和服务端承载配置。

路由器作为全局入口时，设备 CPU 很容易成为瓶颈。单台桌面客户端可以达到的吞吐，不代表低功耗路由器也能达到。测试时观察内核进程 CPU 是否接近单核上限，并关闭高频调试日志。若 CPU 已满，继续调整拥塞控制通常不会解决问题，应改用资源开销更合适的协议或将内核部署到性能更充足的设备。

移动设备与频繁网络切换

移动端应把后台恢复放在峰值吞吐之前。常在无线局域网和蜂窝网络之间切换时，可以比较 Trojan、VLESS 与 QUIC 类节点的恢复时间，但需要保持客户端、规则和 DNS 一致。若切换后所有节点都短暂失败，可能是 VPN 接口重建或 DNS 尚未更新；若只有 Hysteria2、TUIC 失败，则继续检查新网络的 UDP 可达性。

待机耗电异常时，查看是否存在持续重连。错误的服务器地址、失效订阅、TLS 名称不匹配或不可达 UDP 节点可能让客户端反复尝试连接。将默认代理组暂时切换到一个已确认稳定的节点，观察后台耗电是否恢复。减少不必要的健康检查频率、缩小规则规模和关闭调试日志，也能降低持续唤醒。

移动端无需长期保留大量功能重复的节点。代理组中过多节点会增加健康检查与订阅处理负担。更实用的结构是保留少量稳定 TCP 节点、一个经过验证的 QUIC 类节点和明确的故障回退项。自动选择组应使用合理的检查间隔，并避免多个代理组对同一批节点重复进行高频测试。

从错误现象反推问题层次

配置无法加载，先查 YAML 语法、未知字段和不支持的节点类型。配置加载成功但节点不出现，查订阅转换和内核兼容。节点出现但立即认证失败，查密码、用户标识、加密方法和协议代际。TLS 握手失败，查系统时间、SNI、证书名称与 ALPN。QUIC 节点超时，查 UDP 路径、端口、MTU 和服务端监听。节点测试正常但应用不可用，查规则、系统代理、TUN 和 DNS。

连接问题应一次只改一类变量。先保留原订阅，选择一个节点，使用规则最少的测试配置确认协议连接；再恢复代理组；然后恢复规则和 DNS；最后开启 TUN。若同时修改协议、DNS、规则和系统接管，任何结果都难以解释。常见错误的进一步处理可前往常见问题查询。

最终选择建议

如果现有 SS 节点稳定、设备资源有限且配置需求简单，继续使用 SS 是合理选择。已有 VMess 配置并能长期稳定运行时，无需仅因协议历史较长而立刻更换；新建组合式配置则应确认传输与 TLS 参数。重视标准 TLS 连接和清晰认证结构时，可选择服务端提供的 Trojan。需要现代扩展、且客户端使用 mihomo 时，可使用完整参数的 VLESS。

网络存在丢包或抖动、UDP 路径确认正常，并且设备资源足够时，可测试 Hysteria2 或 TUIC。两者都不应脱离服务端配置单独选择，也不应手工互换认证字段。移动端把后台恢复和电量作为主要指标，路由器把 CPU、内存与维护复杂度作为主要指标，桌面端则可以在兼容基础上更充分地比较传输体验。

无论最终选择哪一种协议，都应保留一个已验证的备用节点和一份可回退配置。订阅更新后先确认节点类型与代理组，再检查规则；客户端更新后确认实际内核；出现故障时按配置解析、协议握手、规则选择、系统接管的顺序定位。协议选型的目标不是追逐名称，而是建立一套可验证、可维护、适合当前设备与网络的连接方案。