Clash 协议与内核技术参考

一、协议、传输与客户端的选型基础

先区分四层能力

客户端界面、代理内核、代理协议和底层传输不是同一层。客户端负责配置管理、订阅更新、系统代理与权限交互；内核读取配置，执行 DNS、规则匹配和出站连接；协议定义客户端与服务端如何认证及转发数据；传输决定数据通过 TCP、UDP 或其上的封装到达对端。界面里显示同一个节点名称，不代表实际采用相同的内核参数。判断兼容性时，应先看协议类型，再看传输方式，最后检查客户端是否把相关字段完整交给内核。

选型的第一项约束是服务端支持什么，而不是哪种协议更新。服务端只提供 Trojan 时，把本地类型改成 VLESS 不会得到另一种连接方式，只会导致认证或握手失败。订阅提供的地址、端口、凭据、TLS 名称和传输路径应作为一组参数理解。能够编辑字段不等于可以任意替换字段。需要试用另一协议时，应使用服务端明确提供的另一组配置，并保留原来的可用配置作为对照。

连接速度不是单一指标

用户感知的“快”至少包含首次打开的等待、持续传输的吞吐和长时间运行的稳定性。首次请求可能依次经历域名解析、到服务端的握手、认证以及服务端到目标站点的连接；持续下载又受到带宽、拥塞控制、丢包和服务器负载影响。一个节点的小请求响应较快，不代表它适合大文件；一次下载跑满带宽，也不能证明视频会议中的抖动较小。因此本页不提供脱离环境的协议速度排名，也不把客户端测试栏中的单次结果当成完整性能结论。

安全边界与比较顺序

代理连接的加密主要保护客户端到代理服务端这一段，不会自动改变目标网站自身的安全属性。访问 HTTPS 网站时，浏览器仍需验证网站证书；代理协议使用 TLS 时，内核还要验证代理服务端的证书，两者不能互相替代。服务端运营方、订阅来源和目标应用的权限同样属于信任边界。协议名称本身不能证明服务可信，也不能作为关闭证书验证、公开订阅地址或扩大局域网监听范围的理由。

推荐按“能够连接、功能满足、资源可接受、维护可持续”的顺序筛选。先确认系统与架构适配，再确认内核支持订阅中的协议和传输，随后用自己的工作负载比较稳定性与电量。规则分流、TUN 和域名嗅探属于流量接管与识别能力，不是某个节点协议独占的加速功能。只需要浏览器访问时，系统代理可能已经足够；需要处理不遵循系统代理的应用时，才进一步评估 TUN 与路由设置。

二、Shadowsocks 与 VMess 的设计取舍

Shadowsocks：轻量转发与加密方法

Shadowsocks，常写作 SS，围绕加密代理转发构建，配置通常包含服务端地址、端口、加密方法与密码。它的设计重点是保持转发链路相对简洁，而不是把证书管理、复杂传输协商和控制面板都纳入协议。客户端界面里的 SS 只表示协议家族，实际兼容性还取决于加密方法和扩展。看到相同的类型名称时，仍需逐项核对配置；尤其不能把旧客户端支持过 SS，理解为它支持后续所有加密方案。

现代配置常使用带认证的加密方法，AEAD 能在加密之外验证数据完整性。SS 的不同方法在密钥派生、密码格式和实现要求上存在差异，不能只改一个方法名称沿用全部参数。采用较新方案时，应先确认客户端所带内核与服务端实现均支持。对于明显依赖处理器加速的算法，桌面与低功耗设备上的资源表现也可能不同。没有必要仅凭算法名称判断谁更省电，实际负载和实现质量往往更关键。

SS 的 TCP 与 UDP 转发需要分别理解。服务端允许 TCP 连接，不代表对应 UDP 路径、端口和防火墙策略已经配置完成；网页可用而语音或游戏异常时，应单独检查 UDP。部分 SS 配置还依赖插件，插件不是密码的附属文本，而是另一套传输条件。客户端能识别 SS 基本字段，但无法实现某个插件或其选项时，导入成功也不代表能够连接。迁移配置前应确认插件名称、模式和服务端设置一致。

VMess：认证、时间与传输组合

VMess 来自 V2Ray 生态，围绕用户身份认证和代理数据传输设计，常见配置使用 UUID 标识用户。VMess 可以与不同传输组合，因此“VMess 节点”仍不足以描述完整连接。直连 TCP、WebSocket 等组合的握手过程和配置字段不同，不能把一种传输的路径、请求头直接复制给另一种。客户端需要同时支持 VMess 实现与指定的传输层，服务端入口也必须接受相同组合，否则连接可能在认证之前就被终止。

VMess 对系统时间准确性有要求。设备时钟明显偏移时，即使地址与 UUID 正确，也可能出现认证失败。排查这类问题应检查系统自动校时和时区显示，而不是不断更换端口。旧资料里出现的 alterId 与早期认证机制有关，不能把历史示例当成所有服务端的通用写法。现代配置应以服务端说明和当前内核文档为准，不为兼容一份旧教程而随意启用旧选项。更新后出现问题时，也要区分认证变化与传输变化。

如何沿用已有服务

已有 SS 或 VMess 服务运行稳定时，不必仅因为存在新协议就迁移。先明确现有问题：是服务端带宽不足、UDP 不通，还是旧客户端无法加载配置。带宽不足通常不会靠更换本地协议标签解决；缺少传输支持则可能需要更换内核。比较过程中保留原节点，使用独立名称导入新配置，并分别验证网页、持续传输与所需的 UDP 应用。这样才能判断迁移收益来自协议、服务端资源，还是客户端配置修正。

三、Trojan 与 VLESS 的 TLS 配置边界

Trojan：依赖 TLS 的认证转发

Trojan 将代理认证和转发放在 TLS 连接中，常见部署以密码认证用户，由 TLS 提供传输加密。它的配置表面上较短，但服务端地址、端口、密码、证书名称和 TLS 行为必须对应。连接 IP 地址时，证书往往仍签发给域名，因此拨号目标与证书验证名称不一定相同。应使用服务端提供的名称参数，而不是为了消除报错关闭验证。证书有效期、设备时间和信任链缺失，都可能让正确的密码无法进入认证阶段。

SNI 是 TLS 握手中用于表达目标服务器名称的信息，证书验证则检查对端身份是否与预期名称匹配，两者有关联但不是一个概念。某些客户端会用同一输入项推导相关参数，另一些把它们分开显示。复制配置时需要看内核字段映射，不能只根据界面标签猜测。ALPN 用于协商应用层协议，也应遵循服务端要求；随意填写看似常见的值，可能导致入口选择错误或握手完成后立即断开。

VLESS：协议本体与安全层分离

VLESS 同样来自 V2Ray 相关生态，设计上减少协议自身的部分负担，并把加密交给外部安全层处理。UUID 是认证参数，不是给业务内容提供加密的密码替代品。实际使用中必须把 VLESS 与 TLS、REALITY 或明确的受保护部署环境一起理解，不能因为名称里带有某种“轻量”印象就忽略安全层。客户端支持 VLESS，也不自动代表它支持每一种传输、安全层和流控组合。

REALITY 涉及特定握手机制及公钥等参数，不是把普通 TLS 的证书名称换一个字段。配置中可能需要公钥、短标识、服务器名称和客户端指纹等条件，各字段必须来自相匹配的服务端配置。flow 则属于另一项协议行为选择，不能因启用了 REALITY 就自行填入。某种组合是否可用，要同时核对当前 mihomo 实现与服务端实现的支持情况，不能把其他内核的完整示例直接视为可移植配置。

WebSocket、gRPC 等传输也不能被理解为通用加速开关。它们可能用于配合既有入口和中间层部署，但会引入额外的路径、服务名称、请求头或协商要求。服务端使用 WebSocket 时，路径写错可能得到普通 HTTP 错误；使用 gRPC 时，服务名称不一致也会造成失败。出现问题应先确认传输类型，再检查相应字段，不要同时切换协议、安全层和路径。一次只调整一个条件，才能知道修正发生在哪一层。

两类协议如何选择

在服务端同时提供 Trojan 与 VLESS 时，优先考虑配置完整性和实现兼容，而不是仅比较认证字段多少。需要简单的 TLS 部署且现有服务可靠，可以保留 Trojan；需要服务端明确支持的 VLESS 特定组合，则选择兼容该组合的客户端。二者都可能获得稳定表现，也都可能被 DNS、证书和服务端负载拖慢。首次连接失败时应区分解析、TCP 建连、TLS 握手和用户认证四个阶段，再针对相应参数处理。

迁移时尤其要避免订阅转换工具丢失安全层字段。转换后的节点仍可能保留名称、地址和 UUID，却遗漏公钥或流控选项，导致界面看起来完整而实际无法使用。建议保存转换前后两份文件，逐项对照，不在公开讨论中粘贴真实凭据。缺少某字段的说明时，回到服务端文档确认，不通过随机枚举参数寻找偶然可用的组合。

四、Hysteria2 与 TUIC 的 QUIC 连接机制

共同基础：UDP 上的可靠传输

Hysteria2 与 TUIC 都使用 QUIC 相关能力，但不是同一个协议，也不互相兼容。QUIC 通常运行在 UDP 之上，把加密握手、流管理和丢失恢复等能力整合到传输实现中。它并不意味着业务数据可以随意丢失：可靠流仍会处理丢包和重传。相比单条 TCP 字节流，多条 QUIC 流可以减少某一流丢包对其他流的顺序阻塞，但它们仍共享路径带宽、拥塞状态和设备资源，不会突破网络本身的容量。

外层使用 UDP 是实际部署条件。当前接入网络、路由设备和服务端防火墙必须允许相应路径；如果 UDP 被丢弃，浏览器正常访问 HTTPS 并不能证明 QUIC 代理也能连接。某些网络还会缩短 UDP 映射的空闲保留时间，造成连接在静置后失效。排查应关注从客户端到代理服务端的 UDP，而不是仅查看业务应用是否使用 UDP。外层协议与内层业务类型是两件事，TCP 应用同样可以经过 QUIC 代理转发。

Hysteria2：带宽参数与拥塞控制

Hysteria2 在 Hysteria 方案基础上重新设计协议，常见配置使用密码认证并依赖 TLS 验证服务端。它与第一代 Hysteria 的类型和参数不能混用。其拥塞控制行为与带宽设置有关，具体模式还受客户端和服务端协商影响。上行、下行参数不是购买的服务器标称带宽，也不是希望达到的数字，而应结合当前接入网络和实际路径理解。照抄他人的高带宽值，可能增加排队、丢包和与其他应用争用的程度。

如果服务端启用了混淆，需要核对类型与密码；混淆配置不替代 TLS，也不负责修正证书名称错误。先保证基础 QUIC 连接可建立，再验证认证和混淆要求。配置迁移时注意订阅中的带宽单位以及客户端是否识别对应字段，避免把字符串与数值混写。下载速度下降也未必是参数太小，可能来自接入网络变化、服务端出口或持续拥塞。修改带宽前应保留原值，并记录修改后的网页响应与其他应用表现。

TUIC：连接复用与 UDP 转发方式

TUIC 通过 QUIC 承载代理会话，强调连接复用以及 TCP、UDP 业务的组织方式。常见配置同时包含 UUID 与密码，但具体格式必须遵循服务端协议代际与当前内核实现。旧版 TUIC 与新版并不能仅靠补齐一个字段保证兼容。客户端支持表中出现 TUIC 时，应继续检查它支持哪一代配置、哪些拥塞控制选项，以及服务端使用的 UDP 转发模式，而不是只确认节点列表里有这一类型。

UDP 转发可能采用不同封装路径，其可靠性与开销存在取舍。基于数据报的方式通常更贴近实时业务对时效性的要求，基于可靠流的方式则可能让旧数据重传影响后续数据的及时性，实际行为应按实现文档确认。不要把界面里出现的“可靠”一词直接等同于更适合游戏。游戏、语音与文件传输对重传和等待的容忍度不同，需要通过目标应用验证，而不是只看网页是否打开。

两者都值得在合适路径上评估，但不能当成所有网络的默认最优解。建议同时保留一个已验证的 TCP 类节点作为诊断参照。QUIC 节点失败而 TCP 节点正常时，优先检查 UDP 路径与对应服务端设置，而不是先重装客户端。

五、连接开销、资源占用与移动端电量

握手、吞吐和复用分别测量

首次请求耗时由多段过程相加，协议仅影响其中一部分。DNS 缓存是否命中、代理服务端是否已建立会话、目标站点是否允许连接复用，都会影响结果。带 TLS 的协议可能增加首次握手工作，但后续复用连接时不必重复相同成本；QUIC 的会话恢复也有条件，不能把理想恢复路径当成每次请求都能获得的表现。评估日常浏览时，应同时观察冷启动和连续访问，不要只重复刷新一个已缓存页面。

持续吞吐更依赖拥塞控制、可用带宽和接收端处理能力。外层 TCP 丢包会触发重传及速率调整，多种封装还会增加包头与缓冲开销；QUIC 则在用户态处理较多传输逻辑，其 CPU 成本受实现、系统接口和硬件影响。两种路径都可能在某些设备上成为瓶颈。若下载时 CPU 持续繁忙而链路尚未满载，需要考虑设备处理能力；若 CPU 较低但吞吐波动明显，应进一步观察网络与服务端出口。

移动端耗电来自持续工作

手机电量不能按协议名称给出固定排名。加密计算、用户态数据处理、无线电唤醒、后台保活、日志写入和 DNS 查询都参与耗电。蜂窝网络中的小包可能让无线模块维持活跃，持续下载又会同时增加射频与处理器负载。连接复用有时能减少重复握手，但激进保活也可能增加空闲耗电。需要依据实际使用时段观察，不能用几分钟亮屏操作后的电量变化推断全天后台表现。

比较时先固定亮度、网络类型、后台应用和任务内容，分别观察空闲与负载。空闲测试用于发现异常重连、频繁探测或后台日志；负载测试用于比较相同下载、通话或浏览任务的资源成本。系统电池统计通常按应用归集，但网络扩展或系统服务的部分开销可能分散显示，应结合总耗电和温度理解。设备已经发热降频时，后续结果也不再与冷机条件直接可比，最好等待状态恢复后再测试。

TUN、MTU 与保活的调整边界

TUN 扩大流量接管范围，也会增加路由、DNS 与网络栈处理环节。启用后耗电增加，不应立即认定节点协议低效，可能是此前未接管的后台应用现在也经过代理。先查看连接列表确认业务来源，再判断是否需要调整分流。MTU 不匹配可能造成某些请求停顿，特别是路径无法正确反馈报文大小时；但过度降低 MTU 又会增加分包和处理次数。只有在确认相关症状后，才应按客户端与内核文档做受控调整。

保活用于维持会话或网络映射，不是越频繁越稳定。设置过密会产生额外包量，设置过疏则可能让某些网络的空闲连接失效；具体间隔需要由协议实现、接入网络和使用方式共同决定。初次使用优先保留客户端默认值，出现可复现的空闲断线再逐项调整。需要记录的不是一个“最佳参数”，而是网络条件、任务、改动值和结果，这份记录比跨设备复制参数更有参考价值。

六、原版 Clash、Meta 与 mihomo 的家族关系

名称沿革不等于能力完全相同

原版 Clash 建立了以 YAML 描述代理、策略组和规则的常见使用方式；Clash Meta 是在相关基础上扩展功能的分支，mihomo 延续这一分支的发展。很多资料仍使用 Meta 这个称呼，客户端名称中也可能保留历史用词。理解关系时应看实际运行的内核，而不是仅凭软件图标或标题。某个客户端名称带 Clash，不意味着它使用原版内核；界面写 Meta，也可能需要通过运行信息确认具体实现与功能范围。

原版、历史 Premium 分支与 mihomo 不能简单画成逐项完全包含的关系。历史分支在规则集、TUN 和其他能力上各有实现差异，迁移时需要对照字段语义，而不是只判断新内核能否读入文件。mihomo 扩展了协议、DNS、嗅探和规则能力，但新增字段也可能随着实现演进调整。本文不绑定具体版本的支持矩阵；遇到边缘选项时，以当前内核文档、启动输出和配置检查结果共同确认。

配置兼容有三个层次

第一层是语法兼容，即文件能否被解析。缩进、冒号和列表结构错误会使 YAML 本身不合法。第二层是字段兼容，即内核是否识别某个键和值。第三层是行为兼容，即同一配置在默认值、匹配顺序或网络栈实现变化后，是否仍产生预期结果。启动成功只说明通过了部分检查，不代表每项行为都经过验证。未知字段在不同实现中可能被拒绝或忽略，因此不能只用“没有报错”证明配置完全迁移。

策略组和规则中的名称引用尤其容易遗漏。节点被转换工具重命名后，策略组仍引用旧名称，或者规则指向不存在的策略，都可能导致加载失败或选择错误。rule-providers 与 proxy-providers 分别管理规则来源与代理来源，不能互换。服务端提供的新协议也需要相应内核实现支持，更新 GUI 而继续使用旧的自定义内核，并不会自然获得该协议。应检查客户端实际启动的可执行文件与运行信息。

# 保存为 core-check.yaml；仅用于验证基础字段与规则结构
mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

这段最小配置只验证监听端口与直连规则，不包含代理节点，也不会验证任何代理协议。安装了独立 mihomo 命令行程序的环境，可使用 mihomo -t -f core-check.yaml 检查配置；命令名称和路径以本机安装方式为准。检查完整配置前，应在副本上操作并保留原文件。完整文件若依赖外部规则、代理提供器或数据文件，还需要确认网络访问、文件路径及相应资源可用，静态检查不能替代运行测试。

客户端负责的设置也要保留

Clash Verge Rev、FlClash、Clash Nyanpasu 等客户端可能使用覆写、合并或界面设置生成最终配置。订阅原文件与内核运行文件因此可能不同，直接修改临时文件会在更新或重启后丢失。应使用客户端提供的持久化覆写入口，并检查最终配置的相关部分。服务模式、系统代理和开机启动也属于客户端与系统集成范围，复制 YAML 不会自动迁移这些状态。迁移后应重新确认权限、监听端口与网络接管方式。

需要进一步理解配置差异，可阅读Clash 原版、Meta 与 mihomo 版本差异对照；规则集与嗅探的独立说明见mihomo 内核特性笔记。这两类内容用于补充字段背景，实际迁移仍应逐项验证当前配置。

七、订阅格式、字段映射与更新兼容

订阅地址是入口，不是格式名称

订阅通常通过一个 URL 获取配置，但 URL 本身不能说明返回什么内容。服务端可能返回完整 Clash YAML、仅包含节点的 YAML、经过编码的分享链接集合，或者其他客户端使用的配置。某些入口还会根据请求参数或客户端标识返回不同内容。因此“浏览器能打开订阅”只能证明取回了响应，不代表它适合当前客户端。导入前应确认服务提供方标注的格式，并使用客户端明确支持的入口，不靠文件后缀推断。

完整 Clash 配置可能包含 proxies、proxy-groups、rules 和 DNS 设置；代理提供器文件则通常只承担节点列表等有限职责，不能直接替代完整配置。反过来，把一份完整配置当作代理提供器载入，也可能因为结构不匹配失败。导入界面如果分别提供“配置订阅”和“代理提供器”，应按内容选择。更新成功后还要查看策略组是否有可用节点、规则引用是否存在，而不只是确认文件大小变化。

分享链接转换可能丢失语义

SS、VMess、Trojan、VLESS 等分享链接有各自的编码与参数约定，不同工具对扩展参数的支持并不完全一致。转换器可能正确提取地址与认证信息，却遗漏传输路径、SNI、ALPN、流控、插件参数或 QUIC 相关设置。有些字段名虽然相似，取值格式却不同。转换完成后应对照原始服务端说明逐项检查，不把节点出现在列表中当成转换正确的证明。复杂协议组合优先使用服务方提供的目标客户端格式。

协议类型的大小写、连字符和别名也需要按目标内核规范处理。不能把其他生态中的类型名直接替换到 YAML 中，更不能通过删除无法识别的字段让文件勉强加载，因为被删除的字段可能正是连接必要条件。若某字段在当前客户端没有对应入口，应先查内核支持情况，再决定使用自定义配置还是选择兼容的服务配置。网页上的转换结果可能包含敏感凭据，保存和分享时都要按订阅本身的权限级别处理。

更新后验证最终配置

订阅更新可能改变节点名称、分组和规则，也可能覆盖手工写入的参数。建议把个人规则和本地端口等设置放在客户端支持的持久化覆写层，并明确合并顺序。更新后若策略组突然回到其他节点，先确认原选择是否因名称变化失效；若只有特定网站行为变化，检查规则和 DNS 是否被替换。不要在未查看差异前反复点击更新，这会让原来可复现的状态更难保留，也不利于区分远端变更与本地设置问题。

订阅地址常包含访问凭据，应避免放进截图、公开日志或在线转换表单。需要他人协助时，先删除完整 URL、UUID、密码和其他认证字段，只保留类型、字段名称和错误阶段。客户端更新订阅失败时，按网络可达、HTTP 响应、内容格式、配置解析的顺序定位；连接超时与 YAML 解析失败不是同一问题。确认新配置可用后再移除旧副本，保留一个已知可工作的配置，便于在下一次更新异常时快速回退。

八、按场景选择协议与建立排查闭环

桌面、手机与路由设备分别取舍

桌面日常浏览与办公，优先考虑客户端管理能力、规则清晰度和现有服务稳定性。Clash Plus 可作为首选入口，再根据系统集成与配置需求比较 Clash Verge Rev、FlClash 或 Windows 上的 Clash Nyanpasu。已有 SS、VMess 或 Trojan 服务满足需求时，可以继续使用，不必为了协议名称升级而增加迁移成本。需要特定 VLESS 组合时，先确认客户端实际内核支持，再考虑界面操作是否方便，避免选了界面却无法运行目标配置。

Android 可从 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard 的实际配置需求中选择，但不能假设这些客户端具有相同内核和字段支持范围。iOS 优先查看 Clash Plus 的商店说明与配置能力，官网为 clashplus.io。手机经常切换 Wi-Fi 与蜂窝网络，应把切网恢复、后台稳定和电量纳入验证；QUIC 具有连接迁移相关机制，也不代表每种客户端、服务端和系统后台条件下都能保持业务不断线。

Linux 桌面可比较 Clash Verge Rev 与 FlClash；服务器或路由设备则需要单独评估 mihomo 内核、服务管理和网络路由。低功耗设备应关注处理器架构、加密成本、内存与持续吞吐，而不是只看协议支持列表。Clash for Windows 与 ClashX Meta 属于已停止维护的归档选择，已有环境可以作为迁移参照，新部署更应重视持续维护与兼容。具体安装包及平台要求见Clash 下载页，客户端侧重点见客户端对比。

实时业务与大文件使用不同标准

语音、游戏和交互式应用优先看抖动、丢包和短时停顿。先确认节点与服务端支持业务所需的 UDP，再比较实际体验；能够测速不代表业务端口和转发路径正常。大文件下载则关注稳定吞吐、设备温度和对其他应用的影响。Hysteria2 或 TUIC 可以作为 UDP 路径合适时的候选，但应与已知可用的 TCP 类配置对照。办公浏览更应重视失败率和首次响应，不需要为一次峰值速度牺牲日常稳定性。

从错误阶段定位，不从协议名称猜测

第一步确定故障范围：所有节点都失败时，检查订阅、系统网络、端口占用和接管状态；只有一种协议失败时，检查对应传输与认证；只有特定域名失败时，检查规则、DNS 与目标服务。第二步区分阶段：解析失败先看 DNS，建连超时先看地址与路径，TLS 错误先看时间、名称与证书，认证失败再核对凭据。日志阅读方法见Clash 常见日志报错定位，避免把不同阶段统一归为节点不可用。

第三步使用最小改动复测。临时选择明确的出站策略，确认目标请求确实经过预期节点，再分别测试网页和需要的实时应用。若改动涉及 DNS，可参考Fake-IP 映射与兼容说明；若涉及分流顺序，可参考域名与 GeoIP 规则实战。不要同时更改 DNS、TUN、MTU 和协议，否则即使恢复连接，也无法解释原因，更难形成长期可维护的配置。

最终选择应能解释三个问题：服务端是否支持，当前客户端是否完整实现，自己的业务是否得到稳定结果。协议没有脱离环境的统一优胜者，配置也没有适用于全部网络的固定参数。已经具备这三项证据时，就可以停止无目的调参；首次使用仍有操作疑问，可回到快速上手教程按导入、模式、连接和验证的顺序检查。