Clash 协议与内核参考

先分清协议、传输与客户端

协议决定客户端与代理服务端如何表达目标地址、认证身份和传递数据；传输层决定这些数据通过 TCP、UDP 或基于它们构建的通道移动；客户端则提供配置导入、策略选择、日志和系统接管界面。这三层彼此相关，却不是同一件事。看到 Clash Plus、Clash Verge Rev 或 FlClash 的名称，不能直接推断其中某个节点使用何种协议，也不能仅凭软件外观判断某个扩展字段是否得到支持。

把一条连接拆成可检查的环节

一次网页访问通常涉及本地 DNS、规则匹配、代理连接建立、远端目标连接和应用层协商。用户感知到的等待时间，是这些环节共同产生的结果。节点测试通过，只能说明测试目标在当时可达；某个网页仍可能因为自己的 DNS、证书、区域服务或站点故障而失败。比较协议时应先确认流量确实走了目标策略，否则所谓的协议差异，可能只是两次测试命中了不同出口。

TCP 提供可靠、有序的字节流，丢失的数据需要重传，后续字节交付可能等待缺失部分补齐。UDP 提供数据报服务，本身不保证可靠与顺序；基于 UDP 的 QUIC 则在用户态实现可靠流、拥塞控制与加密握手。因而“基于 UDP”并不等于“不重传”，也不等于任何 UDP 应用都能直接通过代理。协议实现还需要明确支持数据报转发，客户端接管方式也必须能把流量送到内核。

兼容性比参数微调更靠前

实际选择可以按四层收窄：先确认服务端提供什么协议，再确认当前内核能解析什么字段，然后确认所在网络允许什么传输，最后才比较速度、电量和功能。一个字段不受支持的配置，即使成功保存到客户端，也不意味着对应功能已经启用。尤其要区分协议名称与传输扩展：同样叫 VLESS，使用不同传输、安全层和流控设置时，要求可能完全不同。

还要区分代理模式与协议。规则模式、全局模式、直连模式决定连接交给哪个策略，不会把 SS 转换成 Trojan，也不会自动给节点增加 UDP 能力。TUN 模式负责在系统网络层接管流量，同样不是新协议。打开 TUN 后游戏可以连接，常见原因是流量终于被接管，而不是节点的传输性能突然改变。关于流量走向，可接着阅读规则、全局与直连模式区别。

本手册默认读者拥有合法可用的服务端配置，不提供服务端凭据，也不建议凭协议名称改写订阅内容。客户端只能按服务端已经支持的方式建立连接；把配置中的类型名称替换成另一个协议，不会完成协议转换。需要换协议时，应取得服务端对应入口的完整参数，并把旧入口保留为回退，避免同时修改多个变量后失去比较基准。

SS 与 VMess：基础协议的取舍

Shadowsocks，通常简写为 SS，围绕轻量的加密代理设计，核心目标是把目标地址和应用数据传给服务端，避免把大量路由与管理功能塞入协议本身。VMess 来自 V2Ray 生态，把用户标识、请求认证和数据传递组织成自己的协议结构。两者都在客户端生态中积累了广泛支持，但“存在多年”只说明应用历史，不代表所有旧配置、加密方法或扩展插件仍适合今天的实现。

SS 的简洁建立在方法匹配上

对 SS 而言，服务端地址、端口、密码和加密方法必须成套匹配。AEAD 方法会对数据进行认证，常见方法的可用性仍应以双方实现为准。较新的协议变体可能使用不同的密钥约束，不能把普通密码随意填到需要特定编码密钥的位置。遇到认证失败，应优先核对方法名称、密码是否完整和订阅是否过期，而不是先尝试关闭本地 DNS 或改变规则。

SS 的基础结构相对直接，往往有利于减少协议层处理，但实际 CPU 占用还受加密算法、处理器指令支持和实现优化影响。某台设备对 AES 有硬件加速，另一台设备可能更适合其他方法，因此不存在跨设备成立的“某算法永远更省电”。若配置附带插件，还要把插件本身的握手、进程和兼容性计入成本；只比较基础 SS 的描述，会低估实际连接路径。

VMess 要关注认证与传输组合

VMess 以 UUID 等参数识别用户，历史上存在不同认证方式。维护中的实现通常采用更新的认证机制，旧教程中的兼容字段不应机械照搬。部分认证检查与系统时间有关，设备时钟明显偏差可能导致请求被拒绝。排查时应先恢复系统自动校时，再核对用户标识和服务端要求；反复重装图形客户端，通常无法修复时间或认证参数不一致。

VMess 还经常与 WebSocket、TLS 等组合使用。此时目标端口能建立 TCP 连接，不代表完整代理链路成立：TLS 的服务器名称、WebSocket 路径、请求头与服务端路由仍需一致。若连接刚建立就关闭，应把这些层次逐一核对。不能因界面里都显示 VMess，就认为两个入口的配置能够互换；同一个协议名称之下，传输封装可能已经改变了主要的连接成本。

如果现有 SS 或 VMess 入口在日常网络中稳定，且能满足应用所需的 TCP、UDP 与平台兼容要求，没有必要仅为协议名称而迁移。反过来，旧入口依赖客户端不再支持的插件或认证方式时，应向配置提供方获取受支持的入口，而不是长期冻结整套软件。评价基础协议的合理尺度，是它是否满足实际路径和维护需求，不是把功能少直接等同于落后。

Trojan 与 VLESS：安全层要分开看

Trojan 的设计把代理认证和转发放在 TLS 连接之内，借助成熟的 TLS 机制保护传输。VLESS 来自 Xray 等生态，采取更轻的协议头和身份标识设计，把传输安全交给外部安全层。二者都可能出现在现代订阅中，但它们不是同义词：Trojan 的常见部署直接围绕 TLS 展开，VLESS 则更依赖配置中的安全层与传输组合来确定实际行为。

Trojan 的证书不是附属装饰

常见 Trojan 配置包含服务端地址、端口、密码以及用于 TLS 的服务器名称。地址负责把连接送到服务器，服务器名称参与身份验证；当地址是 IP 时，名称与证书仍可能需要单独设置。证书链、有效期、系统信任库和设备时间都会影响握手。遇到名称不匹配，首先核对入口说明，而不是把跳过证书验证当作默认步骤，否则连接可能失去对服务端身份的可靠判断。

也要区分代理通道的 TLS 错误与浏览器访问目标站点时的证书错误。普通代理转发并不需要替浏览器解密 HTTPS；浏览器报错可能来自系统时间、目标网站证书、系统中安装的检查代理，或异常出口路径。若只有一个站点失败，应先检查站点本身；若所有 HTTPS 都失败，再检查系统代理链和证书环境。相关分支见开启代理后的证书错误排查。

VLESS 的轻量不代表可以省略安全设置

VLESS 本身不提供与独立加密通道等价的数据保护，使用时必须理解实际部署采用的 TLS、REALITY 或其他受支持安全机制。订阅中的 UUID、服务器名称、公钥、短标识及流控字段，各自有明确职责，不能互相代替。某些设置只适用于特定传输与内核能力；界面提供了一个输入框，并不意味着任意字段组合都会产生有效连接。

REALITY 是安全层相关机制，不是另一个可以单独选择的代理协议。类似地，Vision 属于需要双方匹配的流控设置，不是所有 VLESS 节点都应填写的加速开关。手动补上这些字段可能让原本正常的入口失败。正确顺序是先保留配置提供方给出的完整组合，再核对当前内核支持范围；只有确认服务端启用了对应能力，才谈调整参数或迁移传输。

从连接体验看，Trojan 和 VLESS 都可能运行在高质量 TCP 路径上，也都可能因复杂封装、服务端拥塞或错误路由而变慢。外层 TLS 可能受连接复用、会话恢复和实现方式影响，不能简单用“多一层加密”推算耗时。比较时应保持同一目标和相近线路条件，观察首次连接与已建立连接两种情况；浏览器重复刷新常会复用现有连接，无法单独代表协议的冷启动成本。

如果读者需要较直观的证书与密码配置，已有服务端提供的 Trojan 入口通常更容易逐项核对；如果服务端围绕 VLESS 的特定安全层部署，则应选择明确支持该组合的维护中客户端。这里的优先级始终是参数完整和双方一致，而不是某个名称更现代。对现有稳定入口，先建立可重复的对照结果，再决定是否迁移。

Hysteria2 与 TUIC：先检查 UDP 路径

Hysteria2 与 TUIC 都利用 QUIC 构建代理通道，但并不是同一协议的不同名称。QUIC 通常运行在 UDP 之上，整合加密握手、多流传输与拥塞控制，能够避免不同流之间完全共享 TCP 有序交付造成的部分阻塞。它仍需要确认接收、重传丢失数据并遵守发送约束，因此不能把它理解为绕过网络容量限制的通道。服务端带宽不足时，换成 QUIC 也不会凭空增加出口容量。

Hysteria2 的带宽设置需要真实依据

Hysteria2 的设计重点之一是高吞吐与复杂链路适应。其可选的带宽估计、拥塞控制相关机制，需要结合双方实现和实际配置理解。客户端中的上下行带宽字段不是套餐宣传数字，也不是越大越好的性能档位。填入明显超过可用链路的值，可能增加排队和丢包，让同一网络中的语音或网页体验变差；不确定时应遵循服务端建议与当前内核文档，而不是套用别人网络中的数值。

Hysteria 与 Hysteria2 也不能只靠修改类型名称互换。两者协议与参数存在差异，认证和混淆等设置必须对应服务端。拿旧教程补充一个当前入口不需要的字段，可能导致连接在认证前就中断。遇到失败时，先确认订阅标明的协议代际、端口和认证参数，再检查 TLS 名称与 UDP 可达性，最后才分析拥塞控制；后者通常不是握手完全失败的首要原因。

TUIC 要区分传输能力与配置代际

TUIC 同样在 QUIC 连接中承载代理流量，并考虑 TCP 与 UDP 转发。其身份认证、UDP 转发模式和拥塞控制选项，需要由服务端、订阅格式和内核共同支持。不同代际的 TUIC 配置可能使用不同认证字段，看到同一个协议缩写并不足以判断兼容。应检查入口要求的是哪种字段组合，避免让转换工具把无法表达的选项静默删除，再把连接失败误认为线路不稳定。

某些配置提供零往返握手或相关恢复选项，它们只在满足会话恢复等前提时才可能减少等待，也存在重放语义等需要实现方处理的边界。不要把这些选项当作全局加速按钮。客户端首次启动、网络切换、服务端重启和会话票据失效时，连接过程可能不同。日常选型更应观察持续传输、恢复能力和应用兼容性，而不是单次短测试中少了一次握手。

酒店、办公访客网络或某些移动网络可能对 UDP 有限制，也可能对持续 UDP 流量采用不同管理策略。QUIC 入口在一个网络正常、换网后失败，不一定是订阅过期。应保留一个受支持的 TCP 类入口作对照，并在相同设备上复测。对于移动设备，网络切换后的恢复还取决于客户端、内核和服务端实现，不能仅因 QUIC 具有连接迁移机制，就承诺所有代理会话都能跨网络保持不断。

因此，选择 Hysteria2 或 TUIC 的前提是路径可用和双方配置明确。它们值得纳入高往返时延、波动链路的候选，但结果应来自本地测试。若主要使用场景是轻量网页与后台待机，是否更省电、更快建立连接，需要与现有入口实测，而不是从大文件吞吐表现直接外推。

速度、资源与移动端电量怎么比

协议比较最容易把不同指标混成一个“速度”。建立连接的等待、页面首字节时间、持续下载吞吐、交互抖动和连接成功率，回答的是不同问题。大文件传输快的入口，可能在短连接和弱信号环境中体验一般；一次延迟测试较低的入口，也可能在晚间负载上升后频繁超时。先确定应用需要什么，再决定测什么，否则测试数字越多，结论反而越容易偏离实际需求。

建立一个能复测的对照流程

先固定设备、网络、客户端、目标资源和代理模式，确认没有后台下载或系统更新占用带宽。依次测试候选入口，而不是同时开启多个下载互相争抢。记录测试时段、是否首次连接以及是否发生网络切换，观察多轮结果的分布。若不同协议入口位于不同机房或使用不同出口，只能得出“这两个入口谁更适合当前环境”，不能把差异全部归因于协议机制。

短连接测试可以观察首次打开页面和连续打开页面的差别，但要留意浏览器缓存、连接池和 HTTP 协议复用。持续传输则应同时观察网页、语音或远程终端是否受到挤压。下载速度上升而交互明显卡顿，可能提示排队积累，而不是全面优化。节点面板中的测试结果通常只覆盖指定测试地址，不能替代目标应用验证，也不应该被当成服务端资源占用的间接测量。

CPU 与内存应放回运行环境

客户端总资源包含图形界面、内核、规则集、DNS 缓存、连接追踪与日志，协议只是其中一部分。大量规则和连接可能推高内存；详细日志、频繁刷新连接列表和图形渲染也会增加负载。比较时应使用相同日志级别与近似规则规模，同时区分空闲占用和传输中的增量。桌面任务管理器看到的整个应用占用，不能直接拿来证明某协议头部更复杂。

加密算法是否获得硬件支持、设备是否处于节能模式、系统是否正在限频，都会改变 CPU 结果。低端路由器和现代笔记本的排序可能相反。服务端 CPU 满载也会表现为客户端速度不稳定，但仅靠本地观察无法确认，应结合服务端监控或配置提供方说明。测试过程中的设备发热与频率下降，也值得记录，避免把热限制后的结果当作协议固有上限。

耗电主要看活动模式，不只看协议名

移动端电量与无线电唤醒、弱信号重传、连接保活、后台限制和屏幕亮度共同相关。长时间吞吐测试适合比较传输效率，却不代表整天待机表现。频繁的小流量保活可能延长无线电活跃时间；过于激进地清理连接，又可能增加重复握手。QUIC、TCP、系统代理或 TUN 都不能单凭名称判定更省电，实际流量和后台策略往往更重要。

调优时一次只改一个变量，并保留原配置。先关闭不必要的高频日志和界面刷新，再判断保活、并发或协议参数是否需要调整。若更换入口后耗电下降，同时出口线路和信号环境也改变了，只能记录组合结果。对普通读者而言，连接可靠、待机可接受、恢复容易的入口，通常比吞吐峰值略高但需要持续照看的入口更有使用价值。

原版 Clash、Meta 与 mihomo 的关系

原版 Clash 建立了配置、代理组和规则分流的使用体系，其后出现了围绕兼容性和能力扩展发展的不同分支。Clash Meta 后续以 mihomo 名称继续发展，因此今天讨论 Meta 与 mihomo 时，很多内容指向同一条演进路径，而不是两个需要同时安装的独立内核。旧文章保留 Meta 名称很常见，判断资料是否适用，应查看字段和实现能力，而不是只看标题用词。

图形客户端不等于网络内核

Clash Plus、Clash Verge Rev、FlClash 等客户端负责配置管理与系统集成，底层网络行为还取决于其实际内核及构建方式。图形客户端更新与内核更新可能采用不同节奏；客户端设置中出现某个选项，也可能受平台权限或当前构建限制。核对能力时应查看关于页面、内核信息与启动日志，不要仅根据安装包名称，假定它支持全部 mihomo 功能或所有平台具有相同行为。

mihomo 相比原版 Clash 的常见能力扩展，涉及更多协议、规则类型、DNS 功能和接管能力，但具体支持范围仍以实际构建文档为准。原版配置中的许多基础字段可以继续使用，不代表新增配置能够反向交给旧内核。迁移最常见的问题，是订阅已经包含新协议或新字段，用户却仍在使用不识别这些内容的旧实现。更多差异可见mihomo 与原版 Clash 内核对照。

配置兼容要分三个层次判断

第一层是语法能否解析，例如 YAML 缩进、列表结构和字符串类型是否正确。第二层是字段是否被实现理解，例如代理协议、规则类型或 DNS 选项。第三层是运行条件能否满足，例如 TUN 权限、系统路由、端口占用和服务模式。第一层通过只说明文件能读，不能证明后两层成立；“导入成功但不能用”正需要沿着这三个层次继续定位。

TUN 模式尤其容易跨越职责边界。客户端需要创建或调用系统接管能力，内核负责处理进入的流量，操作系统则决定权限和路由是否允许。开启开关后没有效果，应检查服务是否运行、路由是否安装，以及其他 VPN 或网络工具是否冲突。直接换协议可能暂时改变现象，却不能修复接管层问题。涉及系统网络修改前，应保存已有设置，并准备关闭接管后的回退方式。

客户端选择上，本站首推 Clash Plus；仍应按平台和实际功能核对安装项。Linux 可优先比较 Clash Verge Rev 与 FlClash，其他平台的候选及架构入口见客户端下载页。Clash for Windows 与 ClashX Meta 属于已停止维护的归档选择，适合了解历史配置，不宜仅因旧教程截图熟悉就作为新安装的默认起点。迁移时先保留旧配置副本，再让新客户端完成最小连接验证，最后恢复规则、DNS 与接管设置。

订阅格式与配置字段的兼容边界

订阅是配置分发方式，不是一种代理协议。一个链接可能返回完整 YAML、单独的节点列表、编码后的分享链接集合，或面向其他内核的 JSON。客户端能下载到文本，不代表文本适合当前解析器。排查导入失败时，应先确认响应格式和目标客户端类型，再讨论节点参数；否则容易把返回的登录页面、错误页面或其他格式配置当作 YAML 反复修改。

完整配置与节点提供器不是同一种内容

完整配置通常包含代理、策略组、规则、DNS 与监听设置；节点提供器则主要提供可被主配置引用的代理条目。两者即使都使用 YAML，也不能随意互换导入位置。把完整配置放进只接受节点列表的位置，可能出现结构错误；只导入节点列表而没有策略组和规则，则可能无法得到预期分流。应先确认客户端的“导入配置”与“添加提供器”分别接受什么结构。

协议分享链接也不保证包含所有部署细节。有些字段可以通过链接参数表达，有些依赖额外约定；不同解析器对名称编码、特殊字符和扩展参数的处理还可能不同。节点名称显示乱码未必影响连接，但密码、路径或认证标识被错误解码就会造成失败。重新导入时应保留原始链接供本地比对，不要把含凭据的完整内容粘贴到公开讨论区。

转换只能重排信息，不能创造能力

订阅转换可以把已有节点信息整理成另一种结构，不能让旧内核突然支持 Hysteria2，也不能从缺失字段中推导出服务端公钥。转换工具还可能删除未知参数、替换规则或覆盖 DNS 设置。因此优先使用配置提供方明确支持当前内核的格式；必须转换时，比较转换前后的协议类型和关键字段，并确认处理过程是否会接触完整订阅链接及其中凭据。

下面是一个可独立解析的本地分流示例，没有远端节点，仅演示监听端口、模式和规则顺序。运行后，经过该监听端口的连接会直连，不会自动获得代理出口。它适合把“内核能否启动”和“远端节点能否连接”分开验证；正式使用时应恢复自己的受支持配置，而不是把这一段覆盖到订阅上，再期待原有节点仍然存在。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

YAML 依赖缩进层级，列表项与所属字段必须对齐，不能混用制表符和空格。端口字段需要合理的数值，包含特殊字符的字符串应按 YAML 语法引用。先修正解析错误，再处理协议字段；否则日志可能只报告最先遇到的语法问题，把后面的真实配置隐藏起来。规则则按顺序匹配，宽泛规则放在前面可能让后续精细规则失效，具体写法见自定义规则语法与优先级。

更新订阅前保留本地修改

自动更新可能用远端内容替换本地配置，手工改过的规则或 DNS 因而消失。优先使用客户端明确提供的覆写、合并或独立规则管理能力，并理解其生效顺序。更新失败时，先看请求状态、响应格式与解析日志，再判断是否需要更换链接。连续重试无法修复过期授权；转换也不应成为掩盖服务端返回错误页面的办法。更多问题可在FAQ中按安装配置或故障排查分类查阅。

按场景选择，并保留排查回路

实用选型不是从六个协议中挑一个永久答案，而是建立一个主入口和一个条件不同的回退入口。主入口满足日常网络、应用和电量要求；回退入口用于判断是网络路径还是本地配置出现变化。两者最好具有可解释的区别，例如一个依赖 UDP，另一个使用受支持的 TCP 传输。不要为了凑齐协议名称保留大量来源不明的入口，管理成本也属于使用成本。

日常浏览与移动办公

网页、文档和即时通信通常更重视稳定建立连接与后台恢复。已有 SS、Trojan 或其他受支持入口表现可靠时，可先沿用，再观察休眠唤醒、换网和长时间待机后的行为。移动端还要检查系统是否限制后台运行，是否与另一项 VPN 冲突。iOS 可从下载页选择 Clash Plus，并核对官网 clashplus.io 的说明；Android 则应特别留意电池优化和应用接管范围。

大文件、弱网与实时应用

持续下载可以把 Hysteria2、TUIC 与现有 TCP 类入口一起纳入测试，但前提是当前网络的 UDP 路径稳定。弱网下先看成功率、恢复时间和交互抖动，再看峰值吞吐。游戏、语音和实时通信还需要确认应用流量确实被接管、节点支持所需数据报转发，且服务端出口适合目标服务。单纯打开全局模式并不保证未进入系统代理的应用会被接管，必要时应检查受支持的 TUN 方案。

实时应用出现问题时，把“能登录但不能进入会话”“语音单向”“持续卡顿”分别记录，它们可能涉及不同连接与端口。先查看连接列表是否出现目标流量，再检查规则命中的策略，最后才替换协议。若另一协议恢复正常，也应继续确认是 UDP 支持、服务端路径还是配置差异带来的变化，避免把一个偶然有效的切换当成普遍规律。

桌面、路由器与多人共享

桌面客户端适合通过界面管理订阅、日志和系统代理；服务器或路由器更需要理解监听地址、权限、进程管理与资源限制。允许局域网连接会扩大监听范围，应同时配置访问控制，不能把面向本机的默认假设直接带到共享网络。内核包不包含图形客户端的全部系统集成功能，普通用户应先选 GUI 客户端，不必为追求“更底层”而增加部署复杂度。

多人共享时，吞吐竞争、DNS 策略和规则维护往往比协议头部差异更重要。某台设备大量下载导致其他设备卡顿，应先检查带宽占用与排队，而不是在所有终端逐一更换协议。路由器出现高负载时，还应关注处理器能力、连接数量和规则规模。设备资源不足属于运行环境边界，不能指望通过添加更多复杂规则或开启更多接管功能来解决。

用最短路径定位故障

完全无法导入时看响应与语法；能导入但内核不能启动时看字段、端口和权限；能启动但节点不通时看认证、TLS 与传输路径；节点可用但单个应用失败时看接管、DNS、规则和应用自身。每次只改变一个条件，并记录改变前后的结果。客户端打开即退出，应先按启动崩溃的日志定位步骤处理，不要在内核尚未运行时讨论协议速度。

当主入口持续可靠、回退入口能够区分网络问题、配置更新不会覆盖重要设置时，这套方案就已经具备维护价值。协议手册的作用，是让下一次故障能沿着明确层次被解释，而不是让每个设置都保持最复杂状态。把少量经过验证的组合管理好，通常比追随协议名称变化更适合长期使用。