Clash 协议与内核参考

连接模型：协议、传输与系统接入

一次访问经过哪些环节

应用发起访问后，连接首先通过系统代理、应用内代理设置或 TUN 虚拟网卡进入本地客户端。内核识别目标地址，依据规则选择直连或某个代理策略，再与远端服务建立连接。远端服务负责连接最终目标，并把响应沿原路径返回。这里至少存在应用到本地、客户端到远端、远端到目标三个环节。任何一段的解析、握手、转发或出口拥塞，都可能表现为页面迟迟打不开。

节点里的协议类型描述客户端与远端之间如何认证、封装和传输；系统代理与 TUN 描述本地如何接收应用连接；规则描述连接应去哪里。它们是不同层次的设置。开启 TUN 不会把 SS 节点改成 Hysteria2，选择规则模式也不会改变服务端协议。排查时把这三层分别记录，才能避免在系统接入故障发生时反复切换节点，或者把配置语法不兼容误认为线路性能差。

协议名称之外的连接参数

协议通常还依赖底层传输与安全封装。例如 VLESS 可以配合 TCP、WebSocket 或其他受支持的传输形式，安全层又可能采用 TLS 或 REALITY。订阅中的端口、服务器名称、路径和传输类型共同决定握手是否成立。两条节点都标记 VLESS，不代表配置可以互换；同一服务器上的不同端口也可能运行不同服务。客户端的类型下拉框只是入口，完整参数才是连接约定。

TCP 提供可靠的有序字节流，出现丢包时通过重传恢复；UDP 提供数据报，本身不负责确认与重传。QUIC 基于 UDP，在协议内部实现加密、可靠流和拥塞控制，所以“基于 UDP”不等于“丢失数据也不处理”。还要区分外层连接和内层业务：代理可以通过 UDP 承载网页使用的 TCP，也可以在某些条件下转发应用的 UDP。看到 UDP 字样不能直接推断游戏或视频一定适合。

先明确需求，再比较节点

选型前先确认任务是网页访问、大文件传输、实时通信，还是手机后台保持连接。网页更在意首次连接和短请求响应，大文件更在意持续吞吐，实时通信更在意抖动与丢包，手机则还要考虑空闲唤醒。测试时应固定设备、接入网络、目标站点与时间段，并查看客户端日志确认请求确实经过所选节点。单独更换协议却同时更换服务器地区，得到的结果无法归因于协议。

SS 与 VMess：加密封装与配置取舍

Shadowsocks 的轻量转发思路

Shadowsocks，常写作 SS，采用相对直接的代理转发模型：客户端把目标地址与业务数据按约定加密，服务端解密后连接目标。它的设计重点是控制封装复杂度，而不是内置庞大的传输组合。常见 AEAD 加密方式同时提供保密性与完整性认证，接收端能够识别被修改的数据。实际连接仍依赖服务器地址、端口、密码与加密方式一致；任何一个字段错配都可能导致认证或解密失败。

加密方式不能单凭名称挑选“最强”或“最快”。带硬件 AES 加速的设备与主要依赖软件计算的设备，对不同算法的成本可能不同。SS 2022 是另一个需要明确兼容能力的协议系列，密钥格式和实现要求与常见传统 SS 配置有差异。订阅标记支持 SS，不意味着它必然支持所有 SS 2022 方法；服务端发来的密钥也不能随意换成普通短密码，否则双方无法按相同方式认证。

一些 SS 节点附带插件，插件提供额外传输或封装。此时兼容性取决于内核是否实现该插件及其选项，不只是能否解析 type: ss。移动端图形客户端可能隐藏部分插件字段，导入成功后仍要观察实际连接日志。SS 的 UDP 转发同样需要客户端和服务端共同支持；若网页正常、实时通信失败，应单独检查 UDP 支持、端口策略和应用接入方式，而不是立即修改加密算法。

VMess 的会话认证与传输组合

VMess 源于 V2Ray 生态，提供会话认证和数据保护，并常与 TCP、WebSocket 等传输组合使用。它的识别凭据通常是 UUID，而不是 SS 风格的共享密码。现代配置应按服务端要求使用 AEAD 机制；历史订阅中的 alterId 不应被当成随意优化的参数。旧式认证与新实现的支持范围可能不同，遇到旧配置时应确认提供方的实际部署方式，不能靠调整数字试出一个“通用值”。

VMess 的部分认证机制与时间有关，设备时钟偏差可能让握手失败。若同一订阅在另一台设备正常，先检查系统时间是否自动同步，再看 UUID、TLS 与传输字段。WebSocket 还需要路径和 Host 设置匹配，TLS 需要服务器名称和证书关系正确。这里额外的握手与封装可能影响首次访问，但是否明显取决于连接复用、链路往返和实现方式，不能把所有 VMess 节点归为同一种速度表现。

什么时候优先考虑这两类节点

设备性能有限、需求偏向常规网页与稳定转发时，可以先测试参数简单且维护正常的 SS 节点；已经有完整 VMess 配置和相应服务端时，则应优先保证现有传输组合准确。两者之间的实际差距往往小于服务器负载、出口和距离的差距。若客户端报未知加密方法或不支持传输，应先处理内核兼容；若连接已建立但吞吐不稳定，再比较线路，避免把语法问题与性能问题混在一起。

Trojan 与 VLESS：TLS、安全层与传输参数

Trojan 把安全传输交给 TLS

Trojan 的常见设计是在 TLS 通道内完成认证与代理转发，借助成熟的 TLS 实现保护连接。客户端首先建立安全通道，再按协议提交凭据与目标信息。因此证书验证、服务器名称和服务端监听方式是关键条件。节点密码正确并不代表 TLS 一定成功：连接到错误地址、服务器名称填写不匹配、证书过期或设备时间异常，都可能让认证之前的握手阶段就终止。

服务器地址用于找到远端主机，SNI 通常用于在 TLS 握手中声明服务器名称；两者可以不同，但必须符合服务部署。通过 IP 连接并使用域名进行证书验证是常见情况，不能把 SNI 自动替换为 IP。证书链还依赖系统或内核使用的信任来源。桌面能连接而手机失败时，应检查手机时间、信任存储和客户端 TLS 实现，而不是把证书错误理解成订阅密码一定失效。

VLESS 的精简认证与外置安全层

VLESS 同样来自 V2Ray 相关生态，精简了协议自身的认证与封装逻辑，但本身不承担通用的流量加密保护。常见安全部署依靠 TLS 或 REALITY 等机制，具体取决于服务端与客户端能力。不能因为 UUID 正确就忽略安全层设置，也不能把名称中的“轻量”理解为所有场景都占用更少资源。外层 TLS、所选传输与流控方式，仍会参与连接建立和数据处理。

REALITY 不是一张普通 TLS 证书的替代字段，而是需要两端按其机制配置的安全层。客户端常需要公钥、短标识和服务器名称等参数；这些值应来自服务提供方。Vision 是特定流控设置，必须与服务端及所用传输相适配，不是任意 VLESS 节点都应开启的加速按钮。公钥缺失、短标识错误与流控不匹配，通常需要修复配置，切换系统代理或 TUN 不会补齐这些字段。

传输叠层对短请求的影响

TCP、TLS、WebSocket 等层次各有用途，同时也可能增加握手或封装工作。网页包含多个资源时，连接复用能摊薄部分成本，但是否复用由客户端、协议与业务共同决定。HTTP/2 类传输和其他实现还存在不同的连接组织方式，不能仅凭“多路复用”四个字判断更快。某条连接上的资源竞争、服务端限制和中间网络策略，都可能影响多个业务流共同运行时的体验。

比较 Trojan 与 VLESS 时，先对齐服务器、TLS 条件与传输组合，再观察冷启动访问、连续浏览和大文件三个阶段。只测已经建立的长连接，会漏掉首次握手差异；只测首次访问，又可能夸大长期下载的影响。在同一线路上，两者性能差距未必足以抵消配置复杂度。参数准确、客户端支持完整、服务端持续维护的节点，通常比堆叠更多可选特性的节点更容易稳定使用。

导入后若界面只显示协议名，可在配置预览中核对传输与安全选项，但不要把含凭据的整份配置发到公开讨论区。需要解释字段时可查名词解释；需要选择图形客户端时可看横向评测。本站首推 Clash Plus，具体协议仍应以该平台实际集成的内核能力为准，客户端名称不能替代兼容性检查。

Hysteria2 与 TUIC：QUIC、丢包与链路条件

以 QUIC 组织代理连接

Hysteria2 与 TUIC 都采用基于 QUIC 的传输思路，目标包括利用现代加密传输与流管理能力处理代理业务。QUIC 在 UDP 上实现可靠流，某条流的数据丢失通常不要求其他独立流等待同一条字节序列补齐，但它们仍共享链路带宽与拥塞资源。所谓减少流间队头阻塞，并不意味着可以忽略丢包、无线信号和出口拥塞，更不意味着每个业务都会自动获得更低延迟。

QUIC 使用 TLS 相关的安全机制，连接建立和数据加密由实现共同处理。它还具有支持连接迁移的协议基础，但具体代理客户端是否完整启用相关能力，必须看实现与运行方式。手机从 Wi-Fi 切换到蜂窝网络时，地址变化、NAT 状态和系统后台限制都可能导致重建连接。不能仅因节点类型是 QUIC，就承诺应用会话始终连续，尤其是长时间后台之后重新打开应用的场景。

Hysteria2 的带宽设置不是测速成绩

Hysteria2 对高时延、丢包链路的吞吐有针对性的设计，其中拥塞控制与带宽相关设置需要结合实际部署理解。某些配置会提供上行与下行带宽估计，并影响发送策略；具体行为也受服务端限制和协商结果影响。把数值填得远高于可用链路能力，不会凭空增加带宽，反而可能造成排队、丢包和其他应用响应变慢。家庭共享网络尤其应考虑同时使用者。

Hysteria 与 Hysteria2 不能仅凭名称相近就互换配置。两者的协议和字段存在差异，客户端需要明确识别 hysteria2 类型。除服务器地址、端口、认证和 TLS 外，如果服务端启用了额外混淆，客户端对应参数也必须一致。遇到网页与下载都无法建立连接时，应先确认 UDP 路径、协议类型和认证信息；不要先将带宽估计不断调高，把连接故障误当作吞吐不足。

TUIC 的认证与拥塞控制边界

TUIC 的配置通常包含身份凭据、TLS 以及拥塞控制相关选项。不同协议代际和实现之间可能存在兼容边界，因此订阅里的 UUID、密码或其他认证形式必须按服务端要求处理。拥塞控制算法决定如何在容量变化和丢包时调整发送，而不是独立于线路的速度开关。某算法在固定宽带表现较好，换到抖动明显的无线网络未必同样合适，默认配置应先建立可复现的基线。

保留可回退的连接选择

受限访客网络、部分移动接入和某些路由器设置可能让 UDP 不稳定。在这些环境下，TCP 类节点正常而两个 QUIC 节点同时失败，值得优先检查接入网络而非重复导入订阅。可用手机热点或另一条网络进行对照，但一次只改变一个条件。日常配置中保留经过验证的 TCP 备选，有助于跨网络使用；是否选 QUIC，应看实际业务在同一链路上的表现，而不是把协议年代当成质量排序。

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

把速度拆成三个可观察阶段

“速度快”可能指首次打开页面快，也可能指下载快。首次访问涉及 DNS、连接建立、认证以及目标响应；持续传输更多受出口容量、拥塞控制、服务器负载和接入带宽影响；连接稳定性则表现为失败、重连与抖动。协议只影响其中一部分。比较时先记录具体症状：是点击后长时间空白、资源加载中途停顿，还是持续下载逐渐下降。清晰的症状比一个孤立测速数值更有诊断价值。

测试顺序可以固定为冷启动访问、连续打开同站资源、持续下载和网络切换。冷启动前应结束相关连接，连续访问则保留正常复用条件。每轮使用相同目标与接入网络，重复几次并观察波动，不用最高的一次作为结论。客户端测试地址可能只覆盖很短的请求，与文件下载路径不同；同地区两个节点也未必共享出口。相关解释见节点测速与倍率解读。

资源开销来自整条处理链

CPU 开销包括加密、封装、协议状态维护、规则匹配和数据复制，内存则与连接数量、缓存和内核实现有关。TLS、QUIC 或多层传输会带来各自的处理工作，但硬件加速与连接复用可能改变相对成本。因此不能给六类协议列一个永久有效的内存或 CPU 排名。桌面低负载测试得到的差距，迁移到入门手机、路由器或多连接服务器时，也可能发生变化。

TUN 会增加虚拟网卡与系统网络栈之间的数据处理，DNS 接管、嗅探和频繁测试也会参与资源消耗。规则集很大并不必然导致明显卡顿，但重复导入、持续调试日志和高频更新可能增加不必要的工作。评估内核负载时应同时记录这些开关，不能把开启 TUN 的 QUIC 配置与仅开启系统代理的 SS 配置直接比较，再把差异全部归给协议。

手机耗电与后台唤醒

移动端电量除了取决于 CPU，还受到无线电状态影响。频繁保活、后台测速、订阅更新和重连可能让设备反复维持活跃通信；信号弱时传输与重试成本也会上升。持续下载中的能耗和整夜空闲待机的能耗是两种测试。某协议能更快传完文件，不代表它在后台一定更省电；某连接空闲时很安静，也不代表高吞吐下成本最低。

耗电排查应先看系统电池页面中的前台、后台运行时间，再检查客户端的测试间隔、自动更新和连接日志。关闭不需要的高频探测，保持同一订阅与屏幕状态进行对照，观察是否有循环断开和重新认证。手机系统把代理服务计入网络活动时，统计口径也可能影响显示。不要只根据应用列表中的百分比判定协议问题，应结合实际总耗电和使用时长。

选型时通常先排除频繁失败的节点，再比较业务响应，最后优化电量与参数。稳定的 TCP 节点可能更适合某条移动网络，也可能是 QUIC 在丢包环境中明显改善持续传输。保活和拥塞设置应从客户端默认值开始，确认问题后再按服务端文档调整。一次改变多个参数会失去基线，也容易把短暂的网络改善误认为某个选项有效。

原版 Clash、Meta 与 mihomo 的兼容关系

图形客户端与代理内核分开判断

图形客户端负责订阅管理、设置界面、系统接入和进程控制，代理内核负责解析配置、匹配规则并转发连接。一个客户端可以集成特定内核，也可能提供切换内核的功能；平台不同，集成方式还可能不同。判断协议支持时，必须查看正在运行的内核信息，而非只看应用名称或安装包名称。界面提供某个设置，不代表旧内核能够理解对应的配置字段。

原版 Clash 建立了广泛使用的 YAML 配置体系和规则模式。历史上的开源内核与 Premium 分支又存在能力差别，因此“原版支持”仍需要明确是哪种实现。Clash.Meta 在 Clash 生态中扩展了协议与功能，随后项目以 mihomo 名称继续发展。旧教程中的 Meta 通常指这一技术谱系，但客户端里的旧 Meta 二进制不会因为项目更名自动具备当前实现的全部能力。

共同结构不等于全部字段通用

这些内核共享许多配置概念，例如代理节点、策略组、规则和本地监听端口。但新协议、规则类型、DNS 选项和 TUN 行为并非天然向后兼容。用较新的 mihomo 配置启动旧内核，可能出现未知代理类型、未知规则或字段处理差异。反过来，基础配置被新内核接受，也不代表所有默认行为与旧环境完全相同。迁移时应关注实际日志和连接，而不是仅看“加载成功”。

迁移时检查生成后的有效配置

客户端往往会将订阅、全局设置与本地覆写合并，再生成交给内核的配置。订阅中的端口可能被客户端设置覆盖，DNS 或 TUN 也可能由界面统一管理。因此查错时应优先看有效配置及内核日志，而不是只看原始订阅。修改文件后，如果客户端下次刷新又重新生成配置，手写字段会丢失；需要持久保存的调整应放到客户端支持的覆写或合并入口。

迁移前保存本地规则、策略组选择和必要设置，先用基础连接验证新环境，再逐项启用 TUN、DNS 和规则集。内核控制接口与本地监听端口应保持在预期范围，不需要远程管理时不要随意扩大监听地址。检查日志只需保存相关错误与字段名，分享时删去订阅地址和认证数据。若配置测试通过但无法上网，应回到系统接入与节点握手层继续定位。

按平台选择维护中的客户端

本站首推 Clash Plus；Windows、macOS 也可比较 Clash Verge Rev 与 FlClash，Windows 另有 Clash Nyanpasu；Android 可比较 Clash Meta for Android、FlClash 与 Surfboard；Linux 可选 Clash Verge Rev 或 FlClash。Surfboard 使用的配置生态需要单独确认。Clash for Windows 与 ClashX Meta 属于已停止维护的归档选择，保留旧环境时尤其要留意新协议与系统兼容。

客户端安装入口见安装包页面。iOS 的 Clash Plus 信息以商店说明及官网 clashplus.io 为准。协议选型不应要求用户随意替换应用内部二进制，尤其是签名应用或移动系统环境；优先采用客户端提供的更新途径，再核对其内核说明与受支持的订阅格式。

订阅格式、字段转换与多设备兼容

订阅是配置分发方式

订阅链接是更新节点或配置的入口，不是一种代理协议。它可能返回完整 Clash YAML、仅节点集合、Base64 编码的分享链接，或者其他客户端使用的格式。扩展名和链接名称不一定能说明真实内容，服务端还可能根据客户端请求返回不同格式。导入失败时，应先区分下载失败与解析失败：前者涉及地址、认证和网络，后者涉及返回内容与客户端接受的结构。

完整配置可以包含节点、策略组、规则和 DNS 等设置；节点提供器通常只负责一组节点，还需要主配置引用它。将节点集合直接当作完整配置启用，可能缺少策略组和规则；把完整配置交给只接受节点列表的入口，也可能被拒绝。订阅导入位置应按客户端说明选择，不要把“新建配置”“添加节点”和“添加提供器”当成完全相同的操作。

分享链接转换会遇到信息边界

ss://、vmess://、trojan:// 与 vless:// 等链接用于携带节点参数，但不同工具对可选字段的约定和支持并不完全一致。转换器可能把地址和凭据正确转换，却遗漏传输路径、插件、REALITY 或 UDP 设置。转换后的 YAML 能被解析，只能说明语法有效，不能证明每个协议参数都等价。需要新协议时，优先请求目标内核原生支持的订阅格式。

转换过程中应逐项比较协议类型、端口、安全层、服务器名称和传输字段。不要在客户端已经覆写 DNS 的情况下，误以为转换器修改了节点；也不要把策略组里引用不到的名称视为协议失败。节点重命名会影响规则或组的引用，移除不支持的节点还可能让原有组变空。兼容检查既包括字段是否保留，也包括引用关系是否仍然成立。

更新失败与空列表分开排查

更新失败先观察网络错误、HTTP 状态或解析提示。下载到登录页面、错误提示页，甚至空响应，都可能让客户端显示格式错误。若旧配置仍可用，保留旧配置并检查订阅有效性，不要先删除唯一可用入口。若更新成功但节点为空，则检查分组过滤、关键字筛选和协议兼容；如果部分节点缺失，应比较被过滤的类型，判断是否发生了转换丢失。

多设备共用订阅时，每台设备仍可能拥有不同的本地端口、TUN 权限和覆写设置，因此共用节点不等于完整配置完全一致。手机宜保留适合后台运行的设置，电脑可保留更详细的规则，但两端需要各自支持节点协议。配置同步方案可参考电脑与手机配置同步；首次导入操作见订阅导入教程。

对比订阅格式时，建议保留一条已验证节点作为基线，先确认单节点连接，再恢复策略组和规则。这样能把转换兼容性与路由选择分开，避免一份复杂配置同时包含多个问题，最终只得到笼统的“订阅不能用”。

规则分流与使用场景的选型顺序

先确认规则实际选择了哪个出口

规则模式通常按顺序匹配连接，先命中的规则决定策略。策略可以是直连、拒绝，也可以是一个代理节点或策略组。节点切换后访问行为没有变化，可能是连接命中 DIRECT，也可能是已有连接尚未重建。选协议之前先在连接记录中检查目标、命中规则与实际策略，能避免对一个根本没有使用的节点做性能判断。

域名规则依赖内核能获得目标域名，IP 规则则依据目标地址匹配。系统代理、TUN、DNS 处理和嗅探方式不同，连接记录中可见的信息也可能不同。域名已经丢失时，修改 DOMAIN-SUFFIX 并不保证生效；先检查应用如何解析、内核是否掌握域名，再处理规则。DNS 决定目标解析，规则决定出口，两者相互影响，但不是同一个开关。

下面是基础路由片段，用于说明顺序与策略引用，不是包含远端节点的完整订阅。将其合并到实际配置时，需要让 PROXY 策略组引用真实节点。这里 DIRECT 是内置直连策略，REJECT 是内置拒绝策略；PROXY 则是示例定义的策略组名称，不是任意配置都会自动存在的关键字。

mode: rule
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-SUFFIX,example.org,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

该片段的 PROXY 只含 DIRECT，便于在没有远端凭据时检查语法与规则；它不会建立远端代理。实际使用应把可用节点加入组内，再选择相应节点。GEOIP 还依赖内核可用的地理数据，不能把数据库更新问题归因于节点协议。MATCH 位于末尾处理未命中的连接，放到前面会让后续规则失去匹配机会。

按业务场景确定第一轮候选

常规浏览和办公可以先选择参数完整、连接稳定的 SS、Trojan 或已验证的 VLESS 节点，不必为了协议名称迁移现有正常配置。大文件传输可在同一接入网络上加入 Hysteria2 或 TUIC 做持续测试，观察是否改善丢包条件下的吞吐。实时通信先确认应用 UDP 能进入客户端并被远端支持，再观察抖动；最低的测试延迟不一定代表实际通信最稳定。

多设备场景首先筛选共同支持的协议与订阅格式，再考虑单端优化。手机长期后台运行时，把频繁重连和自动探测作为电量排查重点；路由器或服务器场景则关注硬件加密能力、并发连接和内核资源。可在策略组中保留不同传输类型的可用节点，跨网络时手动切换验证，而不是让未经确认的自动选择不断改变测试条件。

故障出现时按层收敛

应用没有出现在连接记录里，优先检查系统代理、应用设置与 TUN；出现记录但命中错误策略，检查规则顺序和组引用；选中节点后握手失败，检查认证、TLS、传输与 UDP 路径；连接成功但业务慢，比较出口、目标和持续传输。Windows 商店应用还可能受回环限制影响，详见UWP 回环限制处理，这类问题不应通过更换协议解决。

最终选型应满足三个条件：当前内核能完整理解配置，接入网络允许该传输正常工作，实际业务与资源表现符合需求。具体设置步骤回到客户端设置教程，需要更新或更换客户端再查看安装包。协议标签提供机制线索，但稳定性仍应由真实连接、有效配置和业务测试共同确认。