Clash 协议与内核参考

内核家族与客户端边界

界面、内核、配置分别负责什么

Clash 既是历史项目名称，也常被用来泛指一类兼容其配置习惯的代理工具。实际运行时，图形客户端负责订阅管理、系统代理开关、权限申请和界面交互；内核负责建立连接、匹配规则、处理 DNS 与转发数据。两者可能独立更新，所以界面外观相似，不代表支持的协议、字段和网络能力完全相同。

配置则把节点、策略组、规则和 DNS 设置连接起来。选择一个节点，只决定某个出口的连接参数；选择一个策略组，还可能触发自动测试或故障切换；切换规则模式，则影响哪些连接使用这个出口。遇到异常时必须先定位层次：配置未加载、策略组选错和协议握手失败，是三种不同问题，不能靠反复更换客户端一起处理。

原版、Meta 与 mihomo 的关系

原版 Clash 奠定了常见 YAML 配置结构、规则匹配方式与代理组概念，原项目已经停止维护。Clash Premium 是历史上的另一条分发线，其中部分能力与开源原版不同，不能把两者的功能表混为一谈。阅读旧教程时，应特别留意教程所说的 Clash 究竟指哪一种内核，而不是只看文章标题中的产品名称。

Clash Meta 从兼容 Clash 配置生态的方向扩展协议和功能，后续以 mihomo 名称延续维护。因此，旧资料里的 Meta 与当前讨论的 mihomo 存在直接的项目沿革关系，并非两套毫不相关的协议标准。但历史名称关联不等于所有时期的构建都拥有相同能力，尤其是较新的协议参数、DNS 行为和 TUN 选项，需要按实际运行内核确认。

客户端也可能保留旧名称，却已接入后续内核；反过来，新界面也可能附带较旧构建。确认方法是打开关于、设置或诊断页面查看内核名称，再查看启动日志中的配置解析结果。不要只依据安装包文件名判断。若客户端支持替换内核，应使用其明确支持的替换流程，避免把接口不兼容的可执行文件直接覆盖进去。

选择客户端时先看可操作性

普通用户可以先从下载中心的首推客户端 Clash Plus 开始，确认系统支持和订阅适配，再根据桌面操作习惯考虑 Clash Verge Rev 或 FlClash。需要注意，图形界面的功能范围由客户端自身实现决定，不能从使用某个内核直接推导出界面一定提供所有高级开关。缺少界面入口时，还要核对是否允许通过配置启用。

归档客户端适合复现已有环境或读取旧配置，不宜作为新协议选型的默认基线。Clash for Windows 与 ClashX Meta 已停止维护，遇到不认识的节点类型时，首先检查内核能力，而不是删掉所有报错字段。直接使用 Mihomo 内核则需要自行管理配置、进程与权限，更适合服务器、路由器或具备命令行维护经验的用户。

SS 与 VMess 的设计取舍

SS：相对精简的加密代理链路

Shadowsocks 通常缩写为 SS，最初围绕 SOCKS 代理的使用习惯构建，目标是在客户端与服务器之间提供相对精简的加密转发。它不要求每条连接都额外叠加 HTTP 传输层，因此常见配置的层次比较直接。客户端中的服务器地址、端口、加密方法和密码共同决定连接，任何一项不匹配都可能表现为连接建立后立即断开。

选择 SS 时，应核对具体加密方法，而不是只确认节点类型写着 SS。现代部署常用带认证的加密方案，部分部署使用 Shadowsocks 2022 系列；后者对密钥材料和实现支持有额外要求，不能随意把普通口令当作兼容密钥。相同协议标签下，不同加密方法也不应被视为可以相互替换的选项，必须与服务端保持一致。

SS 的资源表现往往比较容易预测，但也受处理器指令集、加密实现、并发连接和服务端性能影响。桌面处理器与低功耗路由器对同一种算法的处理能力可能明显不同。如果配置还启用了插件或额外传输封装，原先精简的链路就发生了变化，插件名称、参数和本地支持情况都要加入兼容性检查，不能仍按基础 SS 的开销判断。

VMess：认证与传输组合更多

VMess 来自 V2Ray 生态，在认证、数据保护和传输组合上具有自己的设计。常见分享链接除了服务器地址和用户标识，还可能携带传输类型、TLS、路径和请求主机等字段。客户端必须把这些字段一起解释；只保留地址、端口与用户标识，往往不足以重建原连接。它的使用门槛主要来自组合较多，而不是某一个设置特别复杂。

VMess 的认证与系统时间有关，设备时间明显偏差可能导致认证失败。排错前先开启系统自动校时，比更改加密字段更合理。旧资料还可能出现历史认证方式和额外标识参数，不能直接照搬到当前部署。应以服务端给出的完整配置和内核当前支持范围为准，避免在不知道原意的情况下，把旧字段机械填入新客户端。

同为 VMess，原生 TCP 与 WebSocket 上承载的连接在路径、握手和中间服务要求上并不相同。使用 WebSocket 时，路径与请求头必须匹配入口服务；启用 TLS 后，还要检查证书和服务器名称。连接失败不一定意味着 VMess 本身不可用，也可能是传输路径被改写、入口配置失配，或订阅转换时丢失了某个附加字段。

两者怎么比较才有意义

若已经有稳定的 SS 节点，日常网页和普通下载通常不需要仅为协议名称而迁移。若服务提供方给出的是完整 VMess 配置，应优先保留其传输组合，再做实际测试。两种协议都不能仅凭名称保证 UDP 应用可用：还需要客户端、内核、服务端以及流量接管方式共同支持；配置中的 UDP 开关也不能凭空补齐服务端能力。

比较时先固定线路和测试任务，分别观察首次连接、重复访问和持续传输。若一个节点走 WebSocket 加 TLS，另一个走直接加密传输，结果体现的是整套部署差异，不是孤立的协议优劣。保留可读日志，记录失败发生在解析、连接、认证还是应用响应阶段，比把全部异常统称为节点超时更有助于下一步处理。

Trojan 与 VLESS 的安全边界

Trojan：把 TLS 放在连接基础层

Trojan 采用基于 TLS 的连接设计，在建立受保护的通道后完成认证并承载代理请求。它的常见配置看起来较短，但证书链、服务器名称和密码缺一不可。客户端填写的连接地址可以是域名或地址，TLS 验证所用的服务器名称则必须与服务端证书及入口配置相符；这两个值有关联，却并不总是同一字段。

TLS 提供加密与服务器身份验证，因此不应把关闭证书验证当成连接失败后的常规修复。证书过期、系统时间错误、名称不匹配和系统缺少信任链，可能产生相似的握手报错。正确顺序是先读日志定位原因，再修复证书或名称设置。如果服务端使用自建信任体系，应通过客户端支持的证书信任方式处理，而不是长期忽略验证。

Trojan 的日常表现与 TLS 实现、连接复用和线路条件有关。首次连接通常涉及底层传输连接与 TLS 握手，后续请求能否复用已有通道则取决于具体实现及配置。不能从使用 TLS 推导出所有小请求都很慢，也不能从某次热连接测试很快，推导出网络切换后的冷启动同样迅速。测试时需要区分这些状态。

VLESS：协议层与安全层分开理解

VLESS 在设计上精简了代理协议本身的处理，将数据保护交给所选安全层或传输方案。它通常使用用户标识认证，但用户标识并不等同于传输加密。查看配置时，不能只看到类型为 VLESS 就认为连接已经具备完整的机密性和身份验证；还必须查看 TLS、REALITY 或其他受支持组合的实际设置，以及服务端是否与之对应。

在支持的部署中，REALITY 采用与普通证书配置不同的身份验证参数。公钥、短标识和服务器名称等字段具有明确含义，不能把它们当作可任意改写的备注。相关参数是否可用，还受客户端集成方式和内核实现限制。分享链接可以携带这些信息，但导入后的配置仍应复核，尤其要防止转换工具把不认识的参数直接丢弃。

VLESS 的传输方式和流控选项也需要分别确认。某个节点在其他生态客户端中可用，不代表任意 Clash 类客户端都能原样运行；协议类型相同而传输扩展不同，仍可能不兼容。不要把未知的流控值换成一个看起来接近的值尝试修复，因为这可能改变通信语义。更稳妥的方法是获取明确面向当前内核的配置。

认证、加密与接管方式不能混为一谈

密码或用户标识用于认证，TLS 等安全层用于保护连接，TUN 和系统代理负责把应用流量送进内核。这三类设置位于不同层。开启 TUN 不会补上缺失的 TLS 参数，切换规则模式也不会解决证书名称错误。相反，先用系统代理验证基本连接，再逐步扩大接管范围，能让问题更容易定位，避免同时改变多个条件。

在实际选型中，Trojan 常适合已有规范 TLS 部署、希望参数较集中管理的场景；VLESS 更适合需要明确传输组合、且服务端与内核能力已经核对的场景。两者都不具有脱离线路质量的速度保证。对客户端使用者而言，完整、可维护且能够保留验证的配置，通常比选中一个听起来更新的协议名称更重要。

Hysteria2 与 TUIC 的 QUIC 路径

QUIC 解决什么，又依赖什么

QUIC 基于 UDP 构建可靠传输，并整合现代 TLS 握手机制。它可以在同一连接中承载多个流，一个流的数据丢失通常不必像单一 TCP 字节流那样阻塞其他流的交付。这为多请求并发和部分丢包环境提供了设计空间，但 QUIC 仍然需要重传、拥塞控制和加密处理，不是绕过带宽、时延与服务器负载限制的捷径。

使用 QUIC 类代理前，先确认所在网络允许稳定的 UDP 通信。有些网络能够正常浏览网页，却对 UDP 设置较短的会话存活时间、限速或直接丢弃。此时 TCP 类节点可用，而 Hysteria2 或 TUIC 超时，并不矛盾。开启客户端中的 UDP 转发选项，也无法改变接入网络对 UDP 的处理方式，必须换网络或使用合适的备用出口。

Hysteria2：带宽配置影响发送行为

Hysteria2 面向基于 QUIC 的代理传输，其协议代际与早期 Hysteria 不兼容，不能只改节点类型名称完成迁移。认证、TLS 和其他协议参数需要服务端与客户端一致。若订阅只写了模糊的 Hysteria 标签，应先向配置提供方确认代际和目标格式，避免把协议握手不匹配误判为服务器临时负载较高。

Hysteria2 的拥塞控制和带宽协商会影响连接表现。在实际启用 Brutal 相关路径时，上下行带宽配置尤其重要，数值并非越大越好。明显超过真实链路能力的设置可能增加丢包、排队和其他应用的等待时间。应根据可持续获得的带宽保守填写，并注意单位；服务端策略及客户端具体实现也会影响最终采用的行为。

如果部署使用其他拥塞控制路径，不应把另一份配置中的带宽参数强行套入。先确认当前内核如何解释这些字段，再调整一个变量并重复测试。可选混淆参数同样必须与服务端一致，不能认为填写后一定改善连接。对普通用户，保留经过提供方确认的完整配置，通常比频繁尝试未经解释的高级选项更稳定。

TUIC：多流连接与 UDP 转发

TUIC 也利用 QUIC 承载代理连接，围绕多流通信和 UDP 转发设计了相应机制。不同协议代际的认证字段和行为可能不同，当前常见配置会涉及用户标识、密码、TLS 和拥塞控制等信息。导入时应按服务端明确支持的代际处理，而不是认为所有 TUIC 分享链接都能被同一个旧内核识别。

TUIC 的 UDP 转发方式、保活与拥塞控制选项会改变不同任务下的表现。高并发请求、实时数据报和长时间下载对连接的要求并不一致，某种设置对下载有效，不代表对语音交互同样合适。涉及零往返握手的选项还要考虑重放风险和实现默认策略，不应仅为缩短测速结果而开启；优先使用客户端与服务端建议的组合。

保留 TCP 备用路径

Hysteria2 与 TUIC 都值得在高时延或存在丢包的网络中进行实际比较，但结果必须包含连接成功率，而不只是成功样本的速度。无线网络切换、设备休眠和运营网络的 UDP 策略都会影响长期可用性。建议保留经过验证的 TCP 类节点作为备用，并确认自动策略组的测试能够反映目标应用需求，避免网页探测成功而实时应用持续失败。

连接速度与资源占用的比较方法

把连接过程拆成几个阶段

一次网页请求至少可能经历域名解析、到代理服务器的传输连接、协议认证、远端目标连接和应用响应。面板中的延迟测试通常测的是某个探测地址的请求耗时，并非纯粹的物理往返时间，也不是下载带宽。不同客户端的测试地址、超时和是否复用连接不同，显示值不宜直接跨软件排名，更不能用一次测试替代长期判断。

冷连接需要建立新的传输与安全上下文，热连接则可能复用已有会话。短网页、频繁打开小接口和持续下载对这两种状态的敏感程度不同。若想比较首次打开速度，应在测试条件一致时重新建立连接；若想比较日常浏览，应连续访问并观察复用表现。不要一边使用已有长连接，一边让另一协议每次重新握手。

用相同任务观察完整链路

尽量选择相同地区、相近服务器条件和相同目标资源，固定设备与接入网络，暂停其他大流量任务。先记录连接是否成功，再记录首次响应和持续传输表现。至少分开测试普通网页、较大文件和实际使用的实时应用。每轮只改变一个条件，重复几轮后观察波动范围，不需要为了得到单一漂亮数字反复挑选最优样本。

资源占用要与任务量一起看。相同时间内传输了更多数据，CPU 使用率更高并不一定意味着实现效率更低；大量空闲连接、规则集、DNS 缓存和图形界面也会占用内存。若需要比较内核本身，尽量固定客户端界面状态和规则配置，并区分客户端进程与内核进程，避免把界面渲染开销归因于代理协议。

复用、并发与线路瓶颈

连接复用可以减少重复握手，但不应默认越多越好。多个应用共享某条底层连接时，拥塞、重传和服务端实现会影响它们之间的干扰。基于 TCP 的复用与 QUIC 多流也不是同一种机制。出现单连接下载正常、多应用同时使用却卡顿时，应检查共享连接和并发限制，而不是立即把规则模式改成全局模式。

低功耗设备上，加密算法实现和数据复制可能先于线路带宽成为瓶颈；高速桌面上，服务器限速或目标站响应反而更常见。持续传输时若 CPU 已长时间占满、设备发热并降频，换更复杂的协议未必改善体验。先减少不必要的封装、日志输出和并发测试，再考虑设备能力，能避免用网络设置处理硬件瓶颈。

自动策略组也会改变测试结论。url-test 根据探测结果选择出口，fallback 更强调按顺序使用可用出口，load-balance 则按其策略分摊连接，并不是把所有线路带宽简单相加。需要理解切换条件时，可查阅三种自动策略组的切换逻辑。比较协议阶段建议先固定手动出口，排除策略组切换造成的混淆。

移动端电量与网络切换

耗电来自整条工作链

移动端代理耗电不能只按 SS、Trojan 或 QUIC 排出固定榜单。无线模块活跃时间、蜂窝信号强弱、后台唤醒、加密处理、日志记录和应用流量都会共同影响结果。即使两次使用同一节点，屏幕亮度、定位任务和网络覆盖不同，也可能产生明显差异。先确认测试期间的实际任务相近，再讨论协议本身的增量开销。

保活报文可以帮助维持会话，却也可能让无线模块频繁离开低功耗状态。QUIC 或 UDP 会话在某些网络中需要更积极地维持映射，但过短的保活周期会增加唤醒；周期过长又可能造成恢复后的重新连接。应优先保留经过验证的默认值，只有日志或可重复现象表明会话经常过期时，才考虑有针对性地调整。

后台测试和日志是可控制的变量

自动策略组若频繁探测大量节点，会产生与前台应用无关的连接。多个组各自测试、客户端同时显示实时统计时，额外工作可能叠加。移动端通常更适合减少不必要的测试范围，按使用频率设置合理间隔，而不是持续刷新全部节点。具体间隔要兼顾故障发现速度，不能为了省电把必要的可用性检查完全取消。

调试日志适合短期定位问题，不适合长期记录所有细节。大量日志可能增加字符串处理、存储写入和界面刷新；连接面板持续打开也可能产生额外负载。完成排错后恢复日常日志级别，并关闭不需要的实时视图。这样得到的电量表现更接近正常使用，也能减少订阅地址、目标域名等敏感信息在本地日志中累积。

TUN、系统代理与平台能力

移动系统通常通过系统提供的 VPN 或网络扩展接口接管流量，桌面端的系统代理与 TUN 开关不能直接映射成完全相同的行为。Android 的按应用设置、后台限制与电池优化，iOS 的网络扩展生命周期和系统休眠，都可能影响连接保持。选择客户端时应以平台实际提供的功能为准，不要照搬另一系统的权限路径。

TUN 会扩大可处理的应用范围，但并不意味着接管的每条连接都会使用远端代理，最终仍由规则决定。错误 DNS 配置可能导致反复查询和重试，过宽的规则可能让本可直接访问的高流量任务绕远。优化电量之前，应先确认连接分流符合预期；单纯更换协议，而保留大量失败重试或错误出口，往往难以得到稳定改善。

切网恢复比单次测速更重要

从 Wi-Fi 切换到蜂窝网络后，源地址、路由和会话映射都可能变化。QUIC 具备支持连接迁移的设计，但代理实现、服务端配置和操作系统生命周期未必允许每次切换都保持原连接。TCP 连接也可能需要重建。因此应实际检查切网后的首个请求、休眠唤醒和弱信号恢复，而不是把协议具备某种设计能力等同于应用永远不断线。

实测时可分别记录待机、轻度浏览和持续传输三种状态，每次保持接近的信号与任务时长，并查看系统电池统计中的后台活动。若耗电主要出现在空闲阶段，优先检查保活、探测和后台重连；若集中在大流量阶段，再观察 CPU、发热及无线网络。两类问题处理方向不同，分开测试才能避免错误归因。

订阅格式与配置兼容性

链接集合不等于完整配置

常见订阅内容大致分为节点分享链接集合和完整 YAML 配置。链接集合主要描述如何连接服务器，完整配置还可以包含代理组、分流规则、DNS 和运行选项。Base64 是一种编码表示，不是独立代理协议，也不能仅凭内容经过编码就判断它兼容 Clash。解码后可能仍然是其他客户端格式，需要继续检查内部结构。

一个能够在浏览器打开的订阅地址，也未必返回可用配置。它可能返回登录页面、到期提示或其他格式的文本。更新失败时先区分网络请求失败与内容解析失败：前者检查地址可达性和授权状态，后者检查实际返回格式及内核报错。不要把包含私人授权信息的订阅地址提交到公开测试网站，也不要直接贴到公开问题记录。

转换可能丢失哪些信息

转换工具需要理解输入协议、附加传输参数与目标内核语法。若工具不认识某个字段，可能直接忽略，也可能生成一个能解析但无法连接的节点。VLESS 的安全层参数、WebSocket 请求头、TUIC 的代际信息和 SS 的特定加密方法，都是需要重点复核的项目。节点名称保留下来，不代表其通信参数也完整保留。

规则和策略组的丢失同样重要。只有节点的订阅无法自动恢复原来的分流逻辑；转换时重命名代理组，还可能让规则引用一个不存在的目标。相同名称的节点也可能在合并时被覆盖。导入后应先确认节点数量与类型是否合理，再检查策略组引用，最后检查规则末尾是否有符合预期的兜底，避免只看导入成功提示。

YAML 语法与内核语义分别检查

YAML 使用缩进表达层级，不同缩进可能让一个字段进入错误对象。语法检查通过只说明文本结构可读，不代表字段被当前内核支持。某些未知字段可能被忽略，某些不匹配类型则会直接使加载失败。处理错误时从日志指出的字段向上检查所在层级，优先修复单个明确问题，不要把整份配置替换成来源不明的长模板。

下面是适用于已有完整配置的规则片段，用于说明策略引用与匹配顺序，不是包含服务器信息的独立订阅。第一条让示例域名直连，第二条让私有地址直连，其余流量进入名为“手动选择”的已有策略组。该组必须已经定义；实际域名与出口应按需求调整。规则顺序改变，结果也可能随之改变。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,手动选择

第三方客户端可能在加载前合并自身设置、覆写配置或补充规则，因此编辑磁盘上的订阅文件不一定是持久操作。下次更新可能覆盖修改，界面设置也可能优先于文件。需要长期保留的改动，应使用客户端支持的覆写、合并或独立规则机制，并查看最终生效配置。先备份，再更新，再验证，是比直接改缓存文件更可靠的维护方式。

数据文件与配置一起维护

GEOIP、GEOSITE 或规则集引用依赖对应数据来源，节点握手成功却分流异常时，还要检查数据是否加载和更新。不同数据格式不能只改后缀互换。可结合GeoIP 与 GeoSite 更新说明核对来源；需要比较订阅结构时，参考订阅格式与转换指南。更新内核或数据后，用同一批目标连接复查结果，确认变化来自预期设置。

场景选型与排错顺序

先排除不满足条件的组合

选型先看硬条件，再看速度。确认客户端运行的内核支持协议和传输组合，订阅包含完整参数，所在网络允许所需传输，设备能够承担长期负载。四项中任意一项不满足，都不应靠反复测速弥补。之后再比较实际任务的响应、稳定性与电量，最终保留一个日常出口和一个经过验证的备用路径，通常比维护大量未知组合更容易。

日常网页与办公场景，优先使用已经稳定运行、认证和安全参数完整的节点。SS、Trojan、VMess 或 VLESS 都可能满足需求，选择依据应是成功率、目标响应和维护成本。若工作环境经常切网，增加休眠恢复与网络切换测试；若需要局域网设备访问，还要单独检查路由、DNS 和直连规则，不要把所有连接统一送往远端。

持续下载或大文件同步，重点观察长时间吞吐、丢包后的恢复以及其他应用是否受到影响。Hysteria2 与 TUIC 可以作为比较对象，但应确保 UDP 通信可靠，并使用合理的拥塞控制设置。实时语音和交互应用则更重视抖动、短时丢包和连接恢复，下载很快的节点未必更合适，必须用实际应用测试双向通信。

路由器和低功耗主机应特别重视架构、内存及散热。普通桌面用户优先使用图形客户端；服务器维护者再考虑独立 Mihomo 内核。安装前到内核下载区确认目标平台与处理器，不能仅按操作系统名称选择。已有可用配置时先在新环境验证，确认正常后再切换主要流量，保留回退文件与原有配置。

按失败阶段缩小范围

第一步看配置是否加载：未知节点类型通常指向内核能力或转换格式，缩进报错指向文本结构。第二步看是否能连接服务器：超时可能来自地址、端口、路由或传输不可达，拒绝连接则更接近端口未监听或服务未启动。第三步再检查认证与 TLS，区分口令错误、系统时间和证书问题；不要在这些阶段同时修改 DNS 与规则。

第四步看目标连接和规则。若只有部分应用失败，确认应用是否进入系统代理或 TUN，再查看它命中的规则与实际出口；若域名失败而地址连接正常，重点检查 DNS，但不要用直接访问地址替代 HTTPS 的正确验证。若全部节点超时，可按节点超时排查顺序检查公共因素，避免把同一个本地问题重复归因到每个服务端。

连接恢复后，用出口信息和连接面板交叉确认，而不是只看开关处于开启状态。可以参考首次连接验证流程，记录应用、规则、出口和失败时间。准备排错记录时删除密码、用户标识、订阅授权与私人地址，保留协议类型、内核名称、网络环境和经过脱敏的错误信息即可。

选型常见问题

完成选择后，把稳定组合及其适用网络记录下来，后续更新一次只改变一个关键条件。更换内核、转换订阅或调整 DNS 后，重新运行基础验证；没有明确问题时，不需要持续追逐所有高级参数。本页用于解释取舍，具体安装和导入仍回到使用文档，术语含义可在术语表中按类别查阅。