Clash 协议与 mihomo 内核参考

内核家族与客户端职责

Clash 是一个生态名称，不等于某一个安装包。图形客户端负责窗口、订阅管理、系统代理开关和权限申请；内核负责读取配置、解析域名、匹配规则及建立出站连接。两者可能由不同项目维护。判断功能时，应查看客户端实际使用的内核与发布说明，而不能只看应用名称中是否带有 Clash。界面存在某个选项，也不代表当前内核已经支持对应字段。

原版 Clash、Meta 与 mihomo 的关系

原版 Clash 建立了 YAML 配置、策略组与规则分流的基础模型。历史上还存在功能不同的开源版本与 Premium 内核，因此“原版支持什么”需要区分具体分支。Clash.Meta 在这一生态基础上继续扩展协议与网络能力，后来以 mihomo 名称发展。旧教程中的 Meta 内核、部分客户端中的 Meta 标签，通常指向这条延续路线，但名称相近并不能替代实际能力检查。

mihomo 保留了许多熟悉的配置结构，例如 proxies、proxy-groups、rules 和 dns，同时扩展了 VLESS、Hysteria2、TUIC 等协议及相关参数。兼容性主要是基础结构的延续，不是所有分支之间的双向兼容。一个能被 mihomo 读取的配置，交给较早内核时，可能因为未知协议、规则类型或 DNS 字段而无法启动，也可能只在使用相关功能时失败。

协议、传输与流量入口分开判断

节点的 type 描述代理协议；TCP、WebSocket、gRPC 或 QUIC 描述其使用的传输方式或传输基础；TLS 提供连接身份验证与加密保护。系统代理和 TUN 则是应用流量进入内核的路径。打开 TUN 不会把 SS 节点变成 QUIC 节点，换成 Hysteria2 也不会自动让所有应用遵循系统代理。它们位于不同层次，排错时需要分别观察。

客户端选择可从下载中心开始，优先查看 Clash Plus 的对应平台入口，再按桌面集成或管理习惯考虑 Clash Verge Rev、FlClash 等选项。不要因为同属 Clash 生态，就假定每个客户端都能直接导入相同文件；有的会转换订阅，有的会将配置交给不同内核，平台自身也可能限制后台网络行为。

迁移旧配置时，应保留一份原始文件，并先用最小功能集验证连接。确认基础节点可用后，再启用规则提供者、TUN 和高级 DNS。这样可以区分协议兼容问题与系统集成问题。完整的启动操作见mihomo 使用说明，本页后续章节着重解释这些设置为什么会产生差异。

SS、VMess 与 Trojan 的设计取舍

这三类协议经常同时出现在订阅中，但不能互相替换类型。服务端采用什么协议，客户端就必须使用与之匹配的实现和认证参数。修改节点名称不会改变协议；把 type 从一个名称改成另一个名称，也不能完成转换。它们的差别主要体现在加密与认证组织方式、传输组合、部署要求及历史兼容负担，而不是一个固定的速度排序。

Shadowsocks：较直接的加密代理模型

SS 是 Shadowsocks 的常用缩写。其设计重点是以相对精简的协议结构承载代理连接，常见配置由服务器、端口、加密方法和密码组成。现代使用中应区分传统 AEAD 方法与 Shadowsocks 2022 系列：两者的密钥要求、握手设计与实现支持并不完全相同。服务端给出哪种方法，客户端就应原样匹配，不能仅因为列表里都有 SS 就认为可通用。

SS 的基础结构比较紧凑，但“结构简单”不代表所有设备上的计算开销都更低。AES 系列在有硬件加速的平台上可能表现良好，ChaCha20 系列则可能适合缺少相关加速的设备，最终仍取决于实现、处理器和流量形态。带有插件的 SS 节点还多了一层传输要求；只复制密码而遗漏插件模式、主机名或路径，经常会出现认证信息看似正确却无法连接的情况。

VMess：历史生态与传输组合

VMess 来自 V2Ray 生态，围绕用户标识、认证与数据传输形成了较完整的协议设计。它可以搭配不同传输方案，因此订阅中同为 VMess 的两个节点，实际握手路径与连接开销可能不同。排查时需要同时核对 UUID、加密选项、传输类型、TLS 与路径参数。系统时钟明显偏差也可能影响认证，应先启用正常的系统时间同步，而不是反复更换策略组。

旧教程可能包含为历史兼容保留的参数，不能直接当作当前通用建议。尤其不要把旧配置中的认证参数机械复制到新服务端。VMess 的价值之一是已有部署与工具链较多；若现有服务稳定、客户端支持完整，保留它往往比仅为更换协议而迁移更合理。是否需要升级，应结合内核支持、安全维护与连接表现判断，而不是依据节点列表中名称的新旧。

Trojan：以 TLS 连接为基础

Trojan 通常利用 TLS 连接承载认证与代理数据。客户端需要正确的密码、服务器地址和证书验证信息。连接地址、SNI 与证书覆盖的域名可以存在合理差异，但必须由服务端部署方式决定。证书过期、信任链不完整、主机名不匹配，都会使握手失败。直接关闭证书验证只会掩盖问题，不应当作为常规连接方案。

Trojan 的连接成本受 TLS 握手、会话恢复与网络往返影响，不能简单理解为“套了 TLS 就一定慢”。长连接下载与频繁打开短连接的网页，感受到的成本不同。若还叠加 WebSocket 等传输，路径、Host 与服务端转发规则也要一致。基础 Trojan 和附加传输的 Trojan，应当作为不同组合来验证，而不是混在同一轮比较中得出结论。

三者都可以服务于日常浏览，但是否支持并实际启用了 UDP，需要同时检查协议实现、服务端配置与客户端路径。应用能够打开网页，只证明部分 TCP 请求成功，不能证明语音、游戏或其他 UDP 业务已经被同样处理。这也是后续比较 QUIC 类协议时必须保留的测试边界。

VLESS、Hysteria2 与 TUIC 的适用边界

新协议往往针对既有连接模型的某些问题作出调整，但不会消除网络路径本身的约束。VLESS 侧重精简认证与承载层设计；Hysteria2 和 TUIC 则建立在 QUIC 之上。它们常被放在一起讨论，是因为较新的内核普遍将其纳入支持范围，而不是因为它们拥有相同的传输行为。导入前必须核对协议代际与具体参数。

VLESS：认证层与安全传输分离

VLESS 来自 V2Ray 相关生态，相比 VMess 采用更精简的协议思路。需要特别明确：VLESS 本身不提供与名称相对应的一套独立数据加密层，通常依赖 TLS、REALITY 等外部安全机制保护连接。节点能够使用 UUID 完成认证，不等于链路已经具有充分的机密性保护。应根据服务端提供的完整传输方案配置，而不是只填写服务器和 UUID。

VLESS 的实际表现受传输组合影响很大。直接的 TCP 承载、WebSocket 或 gRPC，在连接建立、代理链路与中间服务支持方面各有要求。部分部署还使用特定的 flow；这不是通用加速开关，必须与服务端和底层传输相匹配。REALITY 相关的公钥、短标识和服务器名称也有各自含义，遗漏任意一项都可能使握手无法完成。

Hysteria2：QUIC 与带宽利用

Hysteria2 基于 QUIC，面向包括高时延、丢包等条件在内的网络环境设计。它依赖可达的 UDP 路径，并将可靠传输、加密握手及拥塞控制等机制组合起来。与初代 Hysteria 的参数和协议并不通用，订阅类型必须明确。节点列表上写着 Hysteria，不能替代对 hysteria2 类型与服务端支持的核对。

它的带宽配置需要按实际链路与服务端策略理解。某些模式下，带宽估计会影响发送行为，填写远高于真实链路的值可能带来排队、丢包或影响其他业务，而不是免费增加吞吐。若服务端存在速率限制，客户端一味提高参数也不会突破限制。应先按提供者说明使用默认值或合理估计，再通过持续传输和并行浏览观察稳定性。

TUIC：QUIC 连接与多路复用

TUIC 同样利用 QUIC，通过连接复用等设计承载代理业务。其身份认证字段、协议代际、拥塞控制和 UDP 转发模式必须匹配服务端。不同代际之间不能只凭一个 TUIC 名称认定兼容。若导入器转换了旧分享链接，应检查实际生成的节点类型和认证字段，而不是等到连接失败后反复切换 DNS。

QUIC 在一条连接内提供多个流，单个流的数据丢失不必像同一 TCP 字节流那样阻塞所有后续流数据，但这些流仍共享连接的拥塞控制与路径条件。因此，多路复用不是完全隔离，更不是所有并发都能获得独立带宽。移动设备切换网络时，也不能只根据 QUIC 支持迁移就认定业务必然不断线；代理实现、服务端策略和操作系统仍会影响结果。

如果当前网络对 UDP 支持不佳，QUIC 类节点可能表现为握手超时或连接间歇中断。这时应先用已知可用的 TCP 类方案作对照，而不是认定设备性能不足。相反，在确有丢包且 UDP 路径稳定的环境里，可以把 Hysteria2 或 TUIC 纳入测试，但结论仍要来自实际业务，不应只看一次探测结果。

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

“哪个协议更快”需要拆成几个问题：首次连接多久完成、网页何时开始显示、持续下载能达到什么吞吐，以及后台保持连接消耗多少资源。这些指标可能互相矛盾。某个节点持续下载较快，却可能因为握手路径较长而让短请求显得迟缓；另一个节点测速普通，但日常网页稳定。协议只是变量之一，服务器负载与网络路径通常同样重要。

把握手、吞吐与业务体验分开

首次请求可能包含域名解析、到服务器的连接、TLS 或 QUIC 握手、代理认证和目标站点连接。连接复用与会话恢复可以减少后续成本，因此冷启动和已建立连接的测试不能混用。若一个客户端在后台预先建立了连接，而另一个刚刚启动，直接比较首次打开网页并不公平。测试前应明确是否清空连接、是否使用缓存以及是否同时运行其他流量。

延迟探测通常只说明一个指定 URL 经由当前策略完成请求的表现。它不能完整代表视频、代码仓库、大文件和交互应用。持续吞吐则受服务器出口、目标站点限制、拥塞控制和本地带宽共同影响。只比较不同协议但不同地区、不同运营网络的节点，得到的往往是路径差异，而不是协议本身的差异。

处理器与内存成本来自哪里

加密算法、用户态网络栈、数据复制与连接数量都会占用处理器。QUIC 的加密与传输处理通常由用户态实现，其资源表现与 TCP 类方案不同，但不能据此断言一定更耗电。实现优化、硬件能力、数据量和丢包重传都可能改变结果。若系统已经接近带宽上限，处理器占用升高也可能只是传输了更多数据。

内存占用不只由协议决定。较大的规则集合、DNS 缓存、连接跟踪、日志缓冲和图形界面都可能参与其中。比较两个客户端时，应尽量使用同一配置、同一规则集和相近连接数量。空闲时看到较低占用，不能证明在大量并发连接下也更省资源。排查增长时，先区分界面进程、内核进程与系统网络服务，而不是把总量都归到协议。

移动端电量与后台唤醒

移动网络的无线电工作状态对电量有明显影响。频繁心跳、断线重连、后台探测与短间隔订阅更新，可能让无线模块持续活跃。即使每次只传少量数据，也不一定节能。持续稳定的连接有时比反复重建更合适，但保活过密又会增加唤醒。应先采用客户端和服务端推荐的默认设置，再根据系统电量记录观察，而不是照抄某份激进参数表。

休眠、低电量模式与后台权限还会影响测量。屏幕熄灭后，系统可能限制后台调度；恢复前台时出现短暂重连，不一定是协议错误。iOS 的网络扩展与 Android 的 VPN 服务也有不同生命周期。判断耗电时，应记录使用的是无线局域网还是移动网络、屏幕状态、业务时长与数据量，尽量保持这些条件一致后再更换协议。

桌面端可同时观察内核日志与系统资源监视器，移动端则结合系统电池统计判断。若切换协议后吞吐增加，应比较完成同一任务的总耗电，而不只比较运行时的瞬时占用。首次连接验证的具体操作见选节点、测延迟与确认代理生效，其中的验证顺序也适合用于协议对照。

DNS、Fake-IP 与规则匹配关系

DNS 决定域名如何得到地址，规则决定请求交给哪个策略，两者会互相影响。某个节点握手正常，但网页仍然失败，原因可能在目标域名解析、规则命中或应用缓存，而不在节点协议。先分清“解析代理服务器地址”和“解析业务目标域名”：前者影响能否到达节点，后者影响业务连接与分流判断，使用的解析路径未必相同。

Fake-IP 保存域名与连接的关联

Fake-IP 模式向应用返回一个用于映射的虚拟地址，内核保存该地址与域名的对应关系，收到后续连接时再依据映射执行处理。这样有助于保留域名信息，减少仅靠目标 IP 猜测业务身份的情况。它不会修改远端网站的真实地址，也不会把目标网站搬进本地；虚拟地址只是内核识别连接的中间标识。

常见的 Fake-IP 地址池取自专用测试地址空间，而不是普通公网服务地址。应用若把解析结果写入长期缓存，或切换网络后继续使用旧映射，可能出现连接异常。排查时可先重启相关应用、清理其 DNS 缓存并重新建立连接。不能只清空浏览器页面缓存，因为系统和应用可能各自保留地址记录。

兼容例外与解析路径

少数局域网发现、需要真实地址的应用或特定网络设备，可能不适合直接接收虚拟地址。此时可使用 fake-ip-filter 为明确的域名设置例外，但过滤列表不是越长越好。把大量域名全部排除，会改变原先依赖映射的分流路径，还可能让问题变得难以复现。应只添加经过验证的例外，并记录它解决了哪种具体异常。

下面展示的是结构示意，不能替代完整配置。其 DNS 服务只监听本机回环地址，解析器使用明确的加密 DNS 地址；若要让应用实际走到这里，还需要客户端接管系统 DNS，或通过 TUN 的 DNS 劫持等机制引导查询。只写 enable: true，不会自动改变所有应用的解析路径。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query

规则顺序与 TUN 的边界

规则通常从上到下执行，首次匹配后采用相应策略。域名规则、规则集、GEOIP 与最终 MATCH 的先后，会影响请求结果。若提前命中一条宽泛规则，后面的细分规则就没有机会执行。部分规则需要解析得到真实 IP，另一些可依据域名直接判断；因此更改规则顺序，有时会改变解析次数与出站路径，而不仅是改变策略名称。

TUN 通过虚拟网卡处理匹配的流量，扩大了应用流量进入内核的覆盖范围，但不能自动保证所有 DNS 请求都按照预期执行。浏览器内置的加密 DNS、应用自己的解析器、网络中的其他接口，都需要单独核对。协议加密保护的是相应连接，不能据此推断整个系统的解析路径已经一致。检测时应观察实际查询与连接记录，而不是仅看开关状态。

从 Fake-IP 切换到返回真实地址的模式后，应重新测试受影响应用，并注意旧缓存。需要排查解析路径时，阅读DNS 检测与 Fake-IP 配置；需要调整匹配顺序时，转到自定义规则说明。把 DNS 与规则分开验证，可以避免将分流异常误判为某种协议不稳定。

订阅格式与配置兼容边界

订阅链接只是配置获取入口，不代表它返回的内容拥有统一格式。有的返回完整 Clash YAML，有的只返回节点列表，有的由多行分享链接编码组成，也有的面向其他内核输出 JSON。客户端能够保存一个 URL，不等于它能正确解释返回内容。导入失败时，应先确定内容类型与目标内核，再讨论节点是否过期或网络是否异常。

完整配置、节点订阅与分享链接

完整配置通常包含端口、DNS、节点、策略组与规则，导入后可以构成独立运行方案。节点订阅主要提供连接信息，需要已有配置来组织策略组与规则。单条分享链接则一般描述一个节点，不负责定义完整分流逻辑。把节点列表当作完整配置启动，可能缺少策略组；把整份配置当成代理提供者读取，则可能出现格式错误。

在 mihomo 中，proxy-providers 用于组织代理来源，rule-providers 用于组织规则来源，两者不能混用。策略组需要显式引用代理来源，规则也需要引用对应规则集。下载成功只说明远端文件拿到了，不说明其内容已经被正确引用。若更新后界面里没有节点，应检查提供者是否成功解析、策略组是否引用，以及名称是否完全一致。

转换不是完整的语义迁移

不同格式可以表达的字段不一样。转换器可能保留基础服务器与认证参数，却丢失传输选项、REALITY 参数、UDP 模式或特定协议字段。即使转换结果能通过语法检查，也不一定与原节点行为相同。对较新的协议尤其应逐项比对原始信息，确认类型、证书参数、路径与认证方式没有被默认值覆盖。

订阅服务也可能根据请求特征返回不同格式，因此在浏览器看到的内容与客户端获取的内容未必一致。遇到此类情况，应使用提供者明确给出的 Clash 或 mihomo 格式入口，而不是随意拼接 URL 参数。若远端返回登录页、错误页或其他 HTML，客户端可能报告 YAML 解析失败；这时问题在获取结果，不应通过修改本地缩进来处理。

覆盖设置与自动更新

客户端可能在订阅原文之外叠加本地覆盖、合并脚本或全局设置。原文件写的是一个 DNS 值，实际运行配置可能已被界面改写。定位问题时要区分订阅原文、客户端生成的运行配置与内核日志。直接编辑自动下载的文件，还可能在下一次更新时被覆盖。需要长期保留的规则，应放在客户端明确支持的覆盖或自定义入口中。

自动更新间隔应考虑内容变化频率和移动端后台行为。频繁更新不一定更可靠，远端异常时反而增加请求与日志。更新失败时应先保留最近一次可用配置，并检查错误原因，而不是立刻删除全部文件。订阅地址常带有账户识别信息，分享截图或求助日志时要遮盖完整 URL、认证字段及个人节点信息，避免把访问权限交给其他人。

首次导入与更新操作见订阅链接导入。如果使用旧配置迁移到 mihomo，建议先建立新的配置条目，保留原条目用于对照，再逐步恢复覆盖规则。这样既能避免自动更新覆盖手工修改，也能更快发现是哪一层引入了不兼容字段。

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

选型应先回答“需要接管什么流量”，再回答“用哪种协议连接服务端”。客户端平台、权限、服务端部署和网络路径都是前置条件。若服务端只提供某一种协议，客户端就应优先确认对该方案的完整支持，而不是在界面里尝试其他类型。真正有选择空间时，才比较连接建立、丢包表现、耗电和管理复杂度。

桌面浏览与开发工具

普通网页与文档访问可先使用配置完整、证书正确的 TCP 类方案，SS、VMess、Trojan 或 VLESS 都可能适合。重点是路径稳定和规则清楚。开发工具、包管理器与终端程序不一定遵循桌面系统代理，有的需要单独设置 HTTP/SOCKS 代理或环境变量。浏览器可用而命令行失败时，应先核对流量入口，不要立即更换节点协议。

Windows 与 macOS 可优先从 Clash Plus 开始，根据操作习惯再比较 Clash Verge Rev 或 FlClash；Windows 还可考虑 Clash Nyanpasu。归档客户端 Clash for Windows、ClashX Meta 已停止维护，应将其作为历史兼容资料看待，不宜只因为旧教程截图熟悉就作为新安装的默认选择。实际平台入口与安装说明以客户端下载列表为准。

移动端日常使用

移动端要同时考虑后台持续性、网络切换与电量。Android 可查看 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard 的配置支持；iOS 优先查看 Clash Plus，并通过其官网 clashplus.io了解产品信息。不同应用对订阅的解释方式可能不同，迁移时应重新核对策略组与规则，不要只确认节点数量相同。

如果每天频繁在移动网络与无线局域网之间切换，测试重点应包含熄屏恢复、网络切换和后台待机，而不只是前台测速。QUIC 类方案值得在 UDP 路径稳定时测试，但不应被视为默认省电选项。稳定的 TCP 类连接也可能更适合某些设备。应关闭没有实际需要的高频探测，并观察系统电池记录，而不是仅凭协议名称作判断。

高丢包、实时业务与受限资源设备

在明显丢包的链路上，可对比 Hysteria2 或 TUIC 与现有 TCP 类方案。保持服务器位置和业务目标尽量一致，观察网页响应、持续传输与其他并行任务。如果增加传输吞吐后语音变差，可能是本地排队与带宽竞争，应先检查拥塞与速率设置。游戏、语音等 UDP 业务还需确认服务端支持转发、规则命中正确以及目标路径可达。

服务器、路由器与低功耗设备通常更关注处理器能力、内存和长期运行维护。可直接使用 mihomo 内核，但需要自行管理服务、权限、日志与配置更新。架构必须匹配，不能把桌面安装包作为路由器内核使用。Linux 桌面用户则可以考虑 Clash Verge Rev 或 FlClash，减少手工系统集成工作。具体架构入口见下载中心内核区。

系统代理与 TUN 的选择属于接管方式，不能用协议优劣替代。若应用没有把请求交给内核，再优秀的节点也不会参与连接。需要比较两种入口时，可阅读TUN 模式与系统代理区别。先保证流量进入正确路径，再以实际任务完成情况决定协议，通常比追求单一测速结果更可靠。

连接验证与分层排错流程

排错应沿连接链路逐层推进：配置能否读取、应用是否进入内核、规则选择了哪个策略、节点是否握手成功、目标请求是否完成。每次只改变一个变量，保留原始错误信息与可用配置。反复同时更换 DNS、协议、规则和 TUN，会让偶然恢复看起来像修复，却无法知道真正原因，也难以在下次发生时复现处理过程。

先检查配置与本地入口

若内核无法启动，先看首个解析错误及其字段位置。YAML 缩进、未知类型、引用不存在的策略组，都可能阻止启动。不要只看最后一条“启动失败”提示。使用独立 mihomo 内核时，可以通过下面的命令检查文件；图形客户端通常有配置检查或日志入口，具体运行配置可能位于客户端管理目录，不一定就是最初导入的文件。

mihomo -t -f config.yaml

语法检查通过后，确认应用使用的代理端口与内核实际监听一致。若配置中 mixed-port 是本机的 7890，可以用下列命令发起一个明确经过 HTTP 代理的请求。它只能验证这条指定路径，不能证明所有应用与所有业务都已接管。若本地端口不同，应按实际配置调整；命令行中不要填写控制接口或 DNS 端口。

curl --proxy http://127.0.0.1:7890 -I https://example.com

再检查规则与节点握手

如果日志里没有对应请求，优先检查应用代理设置、TUN 权限与路由；如果请求存在但命中了 DIRECT，则先检查规则顺序和策略组，而不是更改认证信息。若策略组使用自动选择，应记录当时实际选中的节点，避免测试过程中后台切换造成混淆。为了复现，可以临时选择一个已知节点，但测试结束后要恢复原有策略。

握手失败应按错误类别处理。认证错误检查密码、UUID 与协议类型；证书错误检查系统时间、服务器名称和信任链；连接超时检查服务器地址、端口与网络可达性；QUIC 类节点额外检查 UDP 路径。出现“连接被关闭”之类笼统信息时，还需结合服务端部署与传输参数，不应仅凭一句日志认定某个协议失效。

区分目标异常与网络栈异常

如果节点能完成探测，但只有某个网站失败，应比较该域名的 DNS 结果、规则命中与目标服务状态。若所有网页正常而实时应用失败，则检查 UDP 支持、应用自身连接方式和规则。若仅有大请求或持续传输异常，可进一步检查路径 MTU、丢包及并发限制；这些现象需要对照测试，不能看到超时就直接修改 MTU 或关闭证书验证。

启用 TUN 后异常，而显式 HTTP 代理请求正常，通常说明协议路径至少部分可用，应把注意力转向权限、路由、DNS 劫持和其他网络软件的冲突。Windows 的 UWP 应用还可能涉及回环访问限制，可查阅UWP 回环问题。不要同时运行多个接管相同流量的工具，否则入口竞争可能表现为间歇性失败。

修复后应回到实际业务验证，而不只确认错误日志消失。依次检查网页、原本失败的应用、后台恢复和网络切换，确认规则仍按预期工作。如果为了定位而临时放宽过滤、切换模式或关闭自动更新，应逐项恢复。长期保留临时设置会让下一次更新和排错更复杂，也可能改变原本需要的分流行为。

本页的最终判断标准是连接链路可解释、配置来源可追溯、功能边界清楚。首次连接主线仍以使用文档为准，集中问题可继续查阅FAQ。协议选型不是一次性的名称选择，而是在内核支持、服务端配置与实际网络条件之间找到可验证的组合。