Clash 协议与内核技术参考

建立选型坐标：协议不是整条链路

客户端里显示的一行协议名称，只描述连接方案的一部分。一次访问通常先经过应用、系统代理或虚拟网卡，再进入本地内核，完成域名处理与规则匹配，最后由选中的出站协议送往远端服务。任何一段出问题，都可能表现为网页打不开、连接建立慢或下载中断。把这些现象一概归咎于协议，很容易换了一圈类型，真正松动的接头却还在原处。

区分客户端、内核、协议与传输

客户端负责界面、配置管理和系统集成；内核负责解析配置、分流与收发数据；协议规定客户端和服务端如何认证、封装及转发流量；传输方式则决定这些数据通过 TCP、WebSocket、HTTP/2 或 QUIC 等机制承载。TLS 负责特定连接层的身份认证与加密。它们并非同一层，因此“支持 VLESS”不等于“支持所有 VLESS 传输组合”，界面出现某个开关也不等于当前内核已经具备对应能力。

节点还包含地址、端口、认证材料、服务端名称和传输参数。同名协议可以部署在完全不同的机器、线路与负载条件上。两条记录分别写着 SS 和 Hysteria2，不能仅凭名称判定后者更快；服务端所在位置、可用带宽以及客户端到服务端的路径，可能比封装开销更影响体验。选型先确认环境边界，再比较实现方式，而不是给协议贴永久的快慢标签。

先说明目标，再谈性能

打开短网页更关注首次解析、握手与首个响应；连续下载关注长期吞吐和拥塞控制；语音、会议与游戏更在意抖动、丢包和 UDP 转发；手机待机则关注连接维持与唤醒次数。这些目标可能冲突：积极探测和频繁重连有助于更快发现失效连接，却可能增加无线模块活动。所谓“最佳协议”，应当补上“在什么网络、什么设备、什么负载下”这一串条件。

安全比较也要具体到层次。认证方式、加密算法、证书验证、凭据保管和服务端维护共同构成安全边界。新协议名称并不自动代表更安全，旧协议名称也不能替代对具体配置的检查。使用 TLS 的方案应检查证书链、名称匹配与设备时间；依赖共享密钥的方案应避免把订阅地址和认证信息传播出去。加密传输保护的是相应链路，不代表远端服务获得了端到端内容保护。

后续章节按这三层逐步收紧范围：先确认内核能读懂什么，再理解协议的设计取舍，最后用真实任务验证。记录结论时至少写下网络类型、客户端与内核信息、所用传输方式和故障现象。这样下次网络变化时可以重新判断，而不是把一次偶然结果当作永久经验。需要安装对应客户端时，从客户端下载页按系统与架构选择即可。

内核家族：原版 Clash、Meta 与 mihomo

Clash 生态不是一个客户端包打天下。原版 Clash 建立了配置、代理组、规则和本地控制接口等常用结构，后续分支继续扩展协议与网络能力。Clash.Meta 是这一演进中的项目名称，mihomo 则是该分支后续使用的名称。资料里看到 Meta 和 mihomo 时，通常是在讨论同一条技术演进线，但不能据此认为任何带 Meta 字样的历史安装包都具备今天文档里的全部功能。

家族关系不等于功能完全相同

原版 Clash 的公开开源实现与曾经的 Premium 实现也不能混为一谈。部分历史文章把规则提供器、虚拟网卡或脚本等能力笼统归到“原版支持”，实际可能依赖特定实现。原版上游已停止维护，旧配置仍可能被新内核兼容，但新功能通常无法倒灌给旧内核。阅读教程时应寻找具体字段和实现说明，而不是只看文章标题中的 Clash 一词。

mihomo 延续了常见的 YAML 配置框架，并增加或完善了 VLESS、Hysteria2、TUIC、DNS、嗅探和 TUN 等相关能力。这里的“支持”仍受所用构建与版本影响：同一协议的某种传输、认证或扩展字段可能晚于基础支持出现。第三方客户端还可能固定内核、允许替换内核，或为配置增加自己的生成层，因此网站文档、内核文档和客户端界面三者需要对齐查看。

在客户端里确认实际执行者

先打开客户端的关于、内核管理或运行日志页面，找到实际运行的内核名称及构建信息。随后检查配置是直接加载，还是经过订阅转换、覆写和合并后才交给内核。界面导入成功，只能说明管理层接收了文件；启动日志中没有解析错误，才说明生成配置至少通过了基础读取。最后还要发起真实连接，确认所选出站能够完成认证与数据传输。

升级时先保留可工作的配置副本，并记录系统代理、TUN、DNS 与监听端口状态。一次同时替换客户端、内核和订阅模板，会让回归问题难以定位。更稳妥的顺序是先保持原有连接方案，仅升级一个层次，验证完成后再引入新字段。若客户端会在启动时重新生成配置，应修改它提供的覆写入口，而不是直接编辑稍后就会被覆盖的运行文件。

选择图形客户端时，本站首推 Clash Plus；同时可根据平台与操作习惯比较 Clash Verge Rev、FlClash 等下载页列出的选项。推荐顺序不改变核对功能的必要性，尤其不能仅因应用名称中含 Clash 就推断它使用 mihomo。归档的 Clash for Windows 与 ClashX Meta 适合了解旧环境，不宜作为新协议兼容性的依据。具体界面差异见选型指南，能力判断则始终落回当前实际运行的内核。

SS 与 VMess：轻量封装与结构化认证

Shadowsocks，常缩写为 SS，围绕相对简洁的加密代理模型发展：客户端提供目标地址，将应用数据交给约定的加密与转发流程。它的设计重点不是复杂的配置编排，而是在有限的协议结构中完成可靠转发。VMess 来自 V2Ray 生态，包含自己的认证与数据封装机制，并常与不同传输方式组合使用。两者都积累了广泛实现，但成熟度不能替代参数一致性检查。

SS：算法与实现比简称更重要

SS 的节点至少需要服务端地址、端口、密码和加密方法。早期流加密方案、后来常用的 AEAD 方法以及 Shadowsocks 2022 系列不是可以任意混用的同一套参数。AEAD 在加密之外提供完整性保护；不同方法对密钥派生、报文结构和实现要求存在差异。客户端与服务端必须采用共同支持的方法，不能为了“试试能不能连”随意修改算法名称。

在支持硬件加速的设备上，某些 AES 实现可能有较好的效率；在另一些处理器上，ChaCha20 系列可能更合适。但操作系统、加密库与处理器特性都会影响结果，不能把算法名单直接排成性能榜。配置出现不支持加密方法的错误时，应先核对内核能力与订阅内容，而不是调整系统代理。后者只决定应用如何进入本地代理，并不会补齐缺失的算法实现。

SS 可以承载 TCP 和 UDP，但客户端配置、服务端实现及网络路径都必须允许相应转发。某些扩展借助插件增加传输层，插件名称、选项和服务端配置同样需要匹配。一个 SS 链接能够被导入，不代表导入工具完整保留了插件字段；若基础 SS 可用而插件组合失败，应检查转换过程与插件支持边界，避免把全部故障都归到加密本身。

VMess：认证、时间与外层传输

VMess 通常使用 UUID 形式的用户标识，并区分历史认证方式与较新的 AEAD 认证机制。旧教程中的兼容参数可能只适用于旧实现；不应把历史配置机械搬进当前节点，更不应凭经验修改认证相关数值。设备时间明显偏差可能影响认证判断，因此跨设备只有一台失败时，可以先检查自动校时，再核对用户标识、传输方式与 TLS 相关参数。

当 VMess 使用 WebSocket 或其他外层传输时，路径、请求主机名、TLS 服务端名称等字段各有作用。WebSocket 路径影响服务端路由，HTTP 主机名影响应用层请求，TLS 名称用于连接中的身份匹配，它们不必总是相同。订阅转换丢失其中一个字段，可能导致握手失败或收到普通网站响应。处理这类错误，应对照服务端提供的完整连接信息逐层检查。

对于已有稳定 SS 或 VMess 服务的用户，优先目标是保持兼容、确认 UDP 需求与减少转换损失，而不是只为协议名称更新就迁移。SS 的简洁往往方便定位基础连接问题，VMess 的多种传输组合则要求更完整的参数记录。两者的最终表现仍取决于服务端部署与线路，选型时应使用相同应用任务，分别观察冷启动、持续传输及网络切换后的恢复，再决定是否更换。

Trojan 与 VLESS：TLS 与分层设计

Trojan 与 VLESS 经常出现在支持现代 TLS 连接方案的客户端中，但两者并不是同一个协议换个名字。Trojan 围绕 TLS 连接中的认证与代理转发构建，常以密码作为认证材料；VLESS 来自 V2Ray 相关生态，以较轻的协议结构与外部分层能力为设计方向，通常使用 UUID 标识用户。理解它们时，关键是拆开“协议自身做什么”和“外层连接提供什么”。

Trojan：先确认 TLS，再确认转发

常见 Trojan 连接先建立 TLS 通道，再在其中完成认证并转发目标流量。证书验证、服务端名称与系统时间因此直接影响连接能否建立。地址字段可以是域名，也可能是 IP；但使用 IP 连接不代表证书必须按该 IP 验证，客户端通常可以显式设置预期的服务端名称。这个名称必须与实际部署匹配，不能随意填一个看起来正常的站点域名。

客户端报 TLS 握手错误时，应先区分证书过期、名称不匹配、证书链缺失、设备时间错误与端口上根本没有运行 TLS 服务。认证失败则发生在另一层：证书验证通过，也可能因为密码不一致而无法代理。把全部异常都当作“节点失效”会丢失诊断信息。日志若已经说明握手阶段，先修该阶段，不要同时改 DNS、代理组和规则顺序。

Trojan 本身可以涉及 UDP 转发，但 UDP 如何封装、服务端是否启用及客户端是否实现对应行为仍需核对。外层可靠连接也不意味着实时应用一定表现更好：当底层 TCP 遇到丢包，后续数据可能等待重传。对于普通网页与多数常见应用，现有部署的兼容性和连接稳定性往往比封装层数更值得优先考虑；对于实时通信，则应额外验证抖动和恢复过程。

VLESS：轻协议不是省略安全配置

VLESS 的基础协议本身不提供传统意义上的独立内容加密，实际使用应依靠 TLS、REALITY 等与部署相匹配的安全机制。它可以与不同传输组合，协议名称只说明认证和转发框架的一部分。不能看到配置中没有传统加密方法字段，就认为整条链路没有加密；同样不能只看到 VLESS 名称，就默认外层已经受到正确保护。必须检查完整组合。

REALITY 是特定连接安全方案，不是可随手替换的通用 TLS 开关。公钥、短标识、服务端名称和相关行为需要与服务端配置一致。Vision 则属于特定流控组合，存在适用协议、传输与实现条件，不能复制到任意 WebSocket 连接中期待提速。若订阅中包含这些扩展，必须确认客户端实际内核以及转换工具都支持，而不是只确认能够识别 VLESS 这几个字母。

选型上，已有正确维护证书的 Trojan 服务可以继续作为稳定候选；需要特定 VLESS 组合时，应先确认服务端信息完整，再选择支持该组合的内核。两者都不适合靠随机勾选高级选项来排错。每次只修改一个与错误相关的字段，保留原始订阅副本，并记录变化前后的日志阶段。这样才能分清是协议选择不合适，还是配置在导入与转换中丢了零件。

Hysteria2 与 TUIC：QUIC 的收益与代价

Hysteria2 与 TUIC 都利用 QUIC 组织代理连接，但它们是不同协议，服务端与客户端不能互相替代。QUIC 通常运行在 UDP 之上，结合加密握手、可靠流和连接管理能力；这不意味着经过它的所有应用都变成不可靠 UDP。应用的 TCP 数据可以映射到可靠流，应用的 UDP 数据则可能使用数据报或协议规定的其他承载方式，具体行为由实现与配置决定。

为什么选择 QUIC 作为底座

传统多路复用若共用一条 TCP 连接，底层丢包可能使多个逻辑流一起等待。QUIC 把可靠传输的状态组织到流级别，能够减少这种跨流的队头阻塞影响，并提供连接标识等机制帮助管理路径变化。不过同一连接仍共享网络容量与拥塞状态，丢包并不会凭空消失。服务端负载、接入网络策略和实现质量，也都可能抵消协议结构带来的收益。

UDP 可达性是使用这类协议的前提之一。某些网络允许 DNS 等少量 UDP，却限制其他端口或长时间 UDP 会话；某些设备的 NAT 映射保持时间较短，后台静置后更容易失去路径。遇到连接超时，应先确认服务端监听、防火墙、UDP 转发和端口策略，而不是反复换 TLS 名称。若同一设备切到另一网络就恢复，这通常是路径线索，不是凭据突然变对了。

Hysteria2：带宽参数不是加速咒语

Hysteria2 的设计强调在高延迟、存在丢包的路径上进行数据传输，并提供与带宽估计和拥塞控制相关的机制。客户端中的上传、下载带宽设置会影响相应发送行为及协商，具体含义需按当前实现文档理解。把估计值写得远超真实接入能力，可能造成排队、丢包和其他应用受影响。参数应来自实际可持续能力，而不是宽带套餐上的理想峰值。

Hysteria 第一代与 Hysteria2 也不是只改名称就能兼容。认证结构、配置字段和协议行为存在差异，订阅工具必须明确支持对应类型。如果服务端要求额外混淆参数，客户端必须采用匹配的机制和材料；没有要求时，不应凭空添加。某些网络对报文大小敏感，持续传输中断还可能与路径 MTU 有关，应结合日志与网络测试判断，而不是直接认定拥塞控制失效。

TUIC：把连接管理与应用需求一起考虑

TUIC 同样围绕 QUIC 构建代理与转发机制，常见配置涉及用户标识、密码、拥塞控制及 UDP 转发方式。不同协议代际及实现支持范围需要对齐，不能只检查类型写着 TUIC。连接复用可能减少重复建立通道的开销，但会把多个应用集中到同一连接状态中；服务端重启或路径失效时，也可能一起受到影响。应同时观察启动体验与长时间运行表现。

QUIC 具备路径迁移相关机制，并不保证任何客户端在 Wi-Fi 与移动数据之间切换都能保持现有会话。操作系统的网络权限、虚拟网卡行为、客户端处理方式与服务端设置都会参与。不要把“移动网络友好”读成“切网永不断线”。需要检查的实际结果是应用能否及时恢复、是否出现反复重连，以及后台恢复后是否仍然沿用已失效的连接状态。

两者适合进入候选名单的理由，是当前路径和业务确实可能受益于其传输机制，而不是“更新的协议一定更快”。在同一网络中分别检查短网页、持续下载、实时应用和静置恢复；若只有下载表现改善，却增加手机后台重连，就应按主要用途取舍。保留测试条件比保留一个脱离上下文的速度结论更有价值。

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

协议性能至少包含连接建立、首个响应、持续吞吐和异常恢复四个维度。客户端的连接测试通常只测其中一小段：向某个目标发出请求，得到一个耗时结果。它可能受到 DNS 缓存、连接复用、测试地址和服务端响应影响，不能直接代表视频、会议或下载表现。比较时先弄清测试做了什么，再判断这个结果是否与实际任务相关。

把握手与持续传输拆开

新连接可能经历域名解析、底层连接、TLS 或 QUIC 握手、协议认证以及目标连接建立。复用已有连接会跳过其中一部分，因此连续点测试得到的较好结果，不一定代表应用冷启动也一样。TLS 会话恢复和 QUIC 的早期数据机制也有使用条件及安全边界，不应为追求更短建立时间随意开启所有选项。先保留默认可靠组合，再针对明确瓶颈调整。

持续吞吐则取决于拥塞控制、接收窗口、路径容量和两端处理能力。加密消耗 CPU，但并非所有慢速都由加密造成；如果设备处理器负载不高而应用等待明显，可能是远端带宽、排队或目标站点响应。反过来，低功耗路由器满载时，算法实现与并发数量确实可能成为限制。检查资源应覆盖客户端整组进程，避免只看界面进程而漏掉实际收发数据的内核。

电量往往耗在无线活动与后台策略

手机耗电不仅来自加密计算。无线模块保持活跃、频繁心跳、连接探测、DNS 请求、重试和后台日志写入都会消耗资源。TUN 或系统 VPN 接管更多应用后，统计到的流量与耗电也可能集中显示在客户端名下，不代表这些流量全部由客户端主动生成。应结合系统电池统计、前后台活动和应用实际使用情况分析，而不是仅凭电量列表的排名判断协议优劣。

缩短心跳周期可以更快发现连接失效，也可能导致更多唤醒；延长周期可能降低后台活动，却增加恢复等待。合适值取决于 NAT、服务端和系统后台管理，不能跨网络照抄。代理组的自动健康检查、订阅更新与规则数据库更新也会触发网络活动。若目标是延长待机，应先清理没有实际用途的高频任务，避免同时开启多个客户端争用系统代理或虚拟网卡。

做可重复的对比，而不是跑一次排行

固定设备、网络、目标站点与应用操作，避免边下载边比较交互响应。先分别观察冷启动，再进行持续使用，最后测试静置与切网恢复。每轮只更换一个变量；若同时变更服务端地区、协议和客户端，就无法把差异归因到协议。重复观察不同时间段，并写明异常是否稳定出现。没有控制服务端和线路条件时，应把结果表述为这两条连接的比较，而不是两种协议的普遍结论。

如果需要进一步理解客户端的测试入口，可以从使用教程确认操作，再根据日志核对实际选中的出站。不要给协议编造固定内存、耗电或速度数字：实现、硬件和负载变化足以改变结果。真正能指导选择的记录，是在当前设备上哪种组合稳定完成任务、哪些操作会触发故障，以及为获得收益付出了哪些资源代价。

订阅格式：能导入与能运行是两回事

订阅不是一种固定文件格式，而是一种交付与更新配置的方式。同一个地址可能返回完整 Clash YAML、单独的代理提供器内容、编码后的分享链接列表，或其他生态使用的 JSON。扩展名和链接外观都不能保证返回格式，服务端还可能依据请求信息选择不同内容。导入前应确认提供方说明的目标客户端与格式，再选择对应入口。

完整配置、节点集合与分享链接

完整 Clash YAML 通常包含监听、DNS、代理、代理组和规则等内容；代理提供器文件则通常只交付节点集合，由主配置通过提供器引用。后者不能因为同样使用 YAML，就当作完整配置直接运行。分享链接记录单个连接的参数，Base64 列表则常把多条链接编码打包；Base64 是表示方式，不是加密，也不是把任意协议自动转换为 Clash 配置的工具。

因此，导入失败先判断处于哪一步：地址获取失败、返回内容不是预期格式、文件结构解析失败，还是具体节点不被内核支持。若地址返回登录页面、错误页面或空内容，调整 YAML 缩进没有作用。若能够读取 YAML 但提示未知代理类型，应检查内核能力。若运行成功却只有某条连接失败，再检查该连接的认证、传输与服务端状态，别把整个订阅一并推倒重来。

转换工具可能只保留“认得的零件”

转换工具需要把源格式字段映射到目标格式。较新的协议扩展、插件选项、REALITY 参数、流控、UDP 承载方式和特定 TLS 设置，都可能在旧工具中缺少对应项。输出文件语法合法，并不意味着语义完整。出现原客户端可用、转换后不可用的情况时，应对照连接的关键字段，而不是只比较节点名称或服务器地址。名称相同，只说明标签没丢。

订阅地址往往本身就具备访问权限，交给第三方转换服务相当于把获取配置的能力交给对方。优先使用提供方明确支持的目标格式或本地处理方式，不要把真实订阅粘贴进公开问题区、截图和日志。需要求助时，应移除完整地址、用户标识、密码及其他认证材料，同时保留错误类别、字段名称和不含敏感信息的结构，既保护访问权限，也不妨碍定位。

更新与覆写要分工清楚

远程订阅更新可能替换手工修改过的节点、规则或代理组。需要长期保留的设置应放在客户端支持的覆写、合并或独立主配置机制中；具体入口以客户端说明为准。先理解合并是替换列表还是追加内容，尤其是规则顺序与代理组引用。若追加规则落到 MATCH 之后，即使文件里看得见，也可能永远没有匹配机会。相关语法可查阅自定义规则与匹配顺序笔记。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

上面的 YAML 是可独立运行的基础示例，不包含远程代理，也不会把流量送往订阅节点。它适合帮助区分“内核无法启动”和“远程连接无法建立”，但仍需确认本地端口没有被占用。示例能启动，只说明基础配置与监听工作，不证明订阅格式、代理认证或远端服务可用。格式区别与导入过程另见订阅链接导入与格式说明。

按场景选型：从候选组合到验证工单

最终选择应写成一组条件，而不是一份永久排名：当前客户端和内核支持什么，服务端提供什么，所在网络允许什么，主要应用需要什么。先排除不支持的组合，再从可用候选中做对比，通常比反复更换所有高级参数更省时间。对普通用户而言，能稳定导入、正确验证并易于恢复的组合，往往比理论上更复杂的方案更合适。

桌面办公与普通网页

桌面主要处理网页、文档与代码仓库时，先使用已经确认稳定的 SS、VMess、Trojan 或受支持的 VLESS 组合，关注首次响应、长连接与休眠恢复。它们不是同一性能档次的承诺，而是常见可用候选。若网络对 UDP 有限制，优先保留 TCP 承载路径。下载量较大时也别只看峰值，检查下载进行中其他应用是否明显变慢，避免把排队问题误认为应用服务器异常。

新安装可从本站首推的 Clash Plus 开始，再按平台和管理习惯查看其他客户端。更换客户端之前，先导出必要的本地设置并保管好订阅，不要假定所有应用的 TUN、DNS 与合并机制完全一致。如果原有配置能用，迁移时优先保持出站协议和规则不变，只验证客户端集成差异。安装入口见下载页，首次系统代理与端口检查见初始设置检查清单。

移动办公、实时应用与波动网络

手机在不同接入网络间切换时，应把后台恢复、电量和权限稳定性放进检查范围。Hysteria2、TUIC 可以作为 UDP 可达网络上的候选，但必须实际验证切网与待机；TCP 方案也应保留可工作的备选。实时应用还需确认流量确实进入代理，系统代理并不覆盖所有 UDP 应用。TUN 只是接管手段，仍受系统权限、路由和 DNS 处理影响，不会自动修复协议认证。

路由器或服务器用户则应先确认架构、可用内存、服务管理与网络栈限制，使用下载页中的 mihomo 内核区域，而不是把桌面安装包搬到设备上。避免同时开启大量探测、高详细度日志与复杂匹配，再用由此产生的资源压力判断协议性能。家庭局域网还需要明确监听范围与访问控制；为了让一台设备接入就扩大所有接口暴露，属于另一个需要单独评估的配置决定。

故障按阶段收口，不靠随机换协议

第一步看启动：解析错误优先检查缩进、字段与内核支持。第二步看接管：确认应用使用了系统代理或 TUN，规则命中了预期代理组。第三步看连接：区分地址解析、端口连通、TLS、认证与目标转发。第四步看持续运行：观察断开是否由静置、切网、并发或下载触发。每一步都保留一条已经确认可用的对照路径，才能知道修改是否产生了真实改善。

mihomo -t -f config.yaml

该命令适用于已安装并能从终端调用 mihomo 的环境；文件名应对应本地实际配置。语法检查通过，不代表远端连接一定可用。图形客户端可能生成另一份运行配置，也可能要求从内置入口执行检查，应先确认检查的是同一文件。遇到 GeoIP 或 GeoSite 数据加载问题，可继续查阅数据库更新与规则调用说明；域名映射现象则参考Fake-IP 模式解析。

协议选择没有脱离环境的标准答案，但排查可以有稳定顺序。先对齐能力，再检查参数，最后验证实际任务；需要恢复时退回最近一组可工作的配置。把这套顺序用熟，后续无论更换服务端、客户端还是网络，都能知道该检查哪一个接头，而不是重新从协议名字开始猜。