Clash 代理协议与内核技术参考

一、协议选型先看哪几层

客户端、内核与节点，各管一段

客户端是操作入口，负责订阅管理、系统代理开关、配置编辑和日志展示；内核负责解析配置、匹配规则并建立实际连接；节点是服务端提供的连接入口。界面里出现某个协议名称，不代表当前设备一定具备完整支持，还要看内核实现、构建选项和平台网络权限。反过来，内核已经支持的字段，也可能尚未出现在客户端的图形编辑器里。

选型应从现有订阅出发，而不是先挑一个听起来更新的名字。先确认服务端提供什么协议、是否允许转发 UDP、是否要求证书域名，再检查客户端能否原样导入。一个节点的协议类型通常不能在本地随意改写：把配置中的 SS 改成 Trojan，并不会让服务器改变监听方式，只会使双方在连接开始时无法理解彼此的数据。

协议、传输与安全层不要混成一项

代理协议规定如何表达目标地址、身份信息和数据；底层传输决定数据走 TCP 还是 UDP，以及是否使用 WebSocket、gRPC 等封装；TLS 处理安全连接中的身份验证与加密。同一个 VLESS 名称下面，可能是不同的传输与安全组合，实际握手次数、可用网络环境和参数要求都会变化。因此比较时，至少要记录完整组合，而不只是列表中的类型标签。

还要分清节点协议和本地接管方式。系统代理、TUN、混合端口属于设备把流量交给客户端的路径；规则、全局、直连属于流量如何选出口的策略。开启 TUN 不会自动把 SS 变成 QUIC 协议，选择全局也不会让一个原本不支持 UDP 的服务端突然支持游戏数据。遇到应用不联网，应该先判断流量是否进入内核，再判断出口是否可用。

比较结果需要控制变量

连接速度至少包含三段：找到服务器地址、建立代理连接、从服务器访问目标服务。一次节点探测往往只反映其中一部分，还会受到探测网址、缓存和连接复用影响。列表里更小的数字，不等于网页每个资源都更快，也不等于视频更少缓冲。服务端负载、出口线路与目标网站距离，常常比协议封装多出的几个字段更重要。

实际比较可以固定设备、接入网络、目标网站和大致时段，每种组合重复数次，分别记录首次打开、连续浏览、文件传输和待机后的恢复。不要把无线信号变化或服务器繁忙误算成协议差距。尤其在手机上，刚切回前台的首次请求可能包含无线链路唤醒，这与持续下载时的表现不是同一个指标，应当分开观察。

下面的对比以这一框架展开。目的不是给所有协议排一个固定名次，而是找到当前设备上可维护、参数完整、表现稳定的组合。能够解释失败发生在哪一层，比记住“某协议更快”更有用；换网络或换客户端以后，这套判断仍然适用。

二、SS 与 VMess：简洁数据流和结构化认证

SS 的背景与实现边界

Shadowsocks，通常简称 SS，采用客户端与服务端共享密钥的方式转发连接，设计重点是相对简洁的加密代理数据流。它不是一种单独固定的加密算法：配置里的加密方法决定具体如何处理密钥、随机数和数据记录。讨论 SS 时必须同时看加密方法，不能把不同方法、不同实现和不同硬件上的资源消耗直接混在一起比较。

常见 AEAD 方法将加密与完整性保护结合，适合用来理解现代 SS 的基本工作方式；较新的方法家族又有自己的密钥格式和实现要求。订阅里看见 SS 类型，并不能据此推定所有 SS 方法都受支持。导入后提示加密方法不识别，优先核对内核能力与密钥格式，不要靠随便换一个方法名称解决，因为服务端也必须使用匹配配置。

在没有额外插件的常见组合中，SS 的连接结构比较直接，不额外依赖一套外层 TLS 握手。这可以减少部分连接准备工作，但不能据此承诺固定的速度优势。若配置要求插件，还需要客户端与内核对该插件形式有对应支持。手机端与桌面端可能提供不同的插件集，复制了服务器、端口和密码，却遗漏插件选项，也会出现认证之前就断开的情况。

VMess 为什么有更多字段

VMess 来自 V2Ray 生态，在代理数据中引入身份验证等结构，并能与多种传输方式搭配。常见字段包括用户标识、加密选项，以及传输所需的路径或主机信息。这种结构允许更丰富的组合，也意味着排错时不能只检查一个密码框。对于采用现代认证方式的服务端，沿用旧教程中的历史参数，可能造成导入成功但实际无法建立连接。

VMess 的认证涉及时间因素。设备系统时间偏差明显时，即使地址和用户标识正确，也可能认证失败。遇到多个 VMess 节点同时异常、其他协议却正常，可以先检查系统自动校时，再查看内核日志中的认证相关信息。不要一开始就重装整个客户端。旧配置里出现的额外标识参数，应按服务提供方当前说明处理，不宜根据过时截图自行增加。

TCP、UDP 与外层封装的差别

SS 与 VMess 都不能仅凭协议名称判断 UDP 一定可用。还需要服务端启用相应转发、客户端将应用数据交给内核，以及中间网络允许这条路径。某个网页访问正常，只证明对应的网页连接成功，并不证明语音、游戏或实时会议的数据也能走通。测试时应使用真正依赖相关传输的应用，并结合日志确认，而不是只看一个网页探测。

当 VMess 外面再套 WebSocket 或其他传输时，会增加对应封装的处理与连接准备。若内层数据依靠一条可靠的 TCP 连接承载，丢包时后续数据可能需要等待前面的字节恢复。是否能通过复用改善小连接开销，要看服务端与实现；复用还可能让多条业务共享拥塞与故障影响，因此不能把打开复用当成所有场景下的默认优化。

日常网页、文档同步和中等规模传输，可以把参数清晰的 SS 作为简洁基线；已有完整 VMess 服务时，则重点确认认证与外层传输兼容。两者的选择更多取决于服务质量和配置可靠性，而不是某一类协议在所有设备上都天然省内存或更省电。

三、Trojan 与 VLESS：理解 TLS 和传输组合

Trojan 将认证放在安全连接之内

Trojan 的常见工作方式是先建立 TLS 安全连接，再在其中完成代理认证与数据转发。它利用成熟的安全传输机制处理加密与服务端身份验证，代理协议本身保持相对直接。客户端配置除了服务器、端口和密码，还需要关注证书验证所使用的名称。连接地址可以是一个 IP，但证书通常签发给域名，这两者并不总是同一个字段。

SNI 用于在 TLS 握手中告知服务端期望访问的名称；客户端也需要按实现与配置检查证书身份。填写错误可能选中不匹配的站点或触发证书错误。若服务方给出了独立的服务器名称，应完整保留，不能认为服务器地址已经有域名就删除。证书过期、设备时间错误或信任链缺失，也会在代理认证之前终止连接，需要分别排查。

VLESS 的轻量不等于独立提供加密

VLESS 同样来自 V2Ray 生态，重点是较精简的代理协议结构，常见使用方式依靠外层安全机制保护传输。用户标识负责协议所需的身份信息，但用户标识不是万能的加密开关。看到配置里某个加密字段为空或写着特定的禁用值，不应脱离外层 TLS 等配置就断言连接整体没有加密，也不能反过来认为 VLESS 名称本身已经保证了安全性。

VLESS 的实际组合可能涉及 TCP、WebSocket、gRPC，以及 TLS 或 REALITY 等安全配置。这里每个名字解决的问题不同，支持 VLESS 不等于支持全部组合。REALITY 还涉及公钥、短标识和服务器名称等参数，流控选项也有对应的组合约束。字段可以被界面保存，并不代表该平台内核能够执行，最好以实际日志和维护方的功能说明确认。

为什么相同协议会有不同连接开销

普通 TCP 加 TLS 的组合，连接准备涉及底层连接和安全握手；再加入 WebSocket，通常还要完成对应的升级过程。gRPC 依赖 HTTP/2 等机制，具有自己的流管理与实现特征。连接复用、会话恢复和已有连接是否仍有效，都会改变后续请求的成本。因此首次访问慢、连续访问正常，可能是连接准备较重，而不是持续传输带宽不足。

对于频繁创建短连接的业务，握手、解析和调度的占比通常更高；持续下载则更容易体现链路容量与拥塞控制的差别。服务端提供多种组合时，可以先选参数更少、客户端明确支持的一种建立基线，再比较外层封装带来的收益。不要因为某个传输名称更熟悉，就删除服务方指定的路径、服务名或主机字段；这些可能参与服务端路由。

排错时，证书错误应修正名称、时间或服务端证书，而不是长期关闭验证。关闭验证会削弱对服务端身份的确认，也会把配置错误掩盖成暂时可用。对于新手，完整订阅通常比手工录入复杂组合更可靠；需要理解订阅究竟保留哪些字段，可继续阅读本页的订阅兼容章节。

四、Hysteria2 与 TUIC：基于 QUIC 的取舍

QUIC 改变的是承载连接的方式

QUIC 在 UDP 之上实现安全连接、可靠流和拥塞控制等能力。它不是简单地把可靠性丢给应用，也不是因为使用 UDP 就天然快于 TCP。它能让不同数据流在部分丢包情况下减少相互等待，但同一数据流仍要处理有序交付，所有流也仍受到共享链路容量的限制。无线信号差、出口拥塞或服务器负载高，不会因为换成 QUIC 就消失。

Hysteria2 与 TUIC 都建立在 QUIC 相关能力之上，但它们不是可互换的协议。二者的认证、转发方式、参数和拥塞控制选择存在差异，服务端类型必须和客户端配置匹配。旧的 Hysteria 配置也不能只改类型名称就当作 Hysteria2 使用。导入遇到不支持的类型时，先确认协议代际和内核支持范围，再处理字段映射。

Hysteria2 的带宽参数不是测速结果

Hysteria2 在高时延或存在丢包的链路上提供另一种传输选择，常见实现可按配置使用带宽预期参与发送控制，也有不同的拥塞控制行为。订阅中的上行、下行参数通常是配置目标或提示，不是客户端已经测得的可用速度。服务端还可能对行为施加约束，因此不能把界面中的带宽数字直接理解为实际保障。

将预期带宽写得远高于接入能力，可能增加排队和丢包，影响同时进行的通话与网页访问。家庭共享网络上尤其要留意：单个下载看似跑得更满，不代表整体体验更好。若客户端提供相关设置，先保留服务方给定值；需要调整时，结合接入带宽、上行瓶颈与其他设备占用，逐步试验，并记录高负载时网页能否及时响应。

TUIC 也需要核对实现与认证

TUIC 将代理转发建立在 QUIC 连接上，可用于承载不同业务流，并提供 UDP 转发相关机制。不同协议代际和实现的认证形式、配置字段可能不同，不能用一份旧链接推定新内核都能导入。即使客户端都显示 TUIC，仍需核对服务端要求的认证信息、服务器名称和拥塞控制选项，避免只填地址后凭默认值碰运气。

拥塞控制决定连接如何根据反馈增减发送量，不是越激进越好。不同算法在丢包、队列和公平性方面有不同取舍，实现也会随维护演进。没有受控测试时，不宜宣称其中一种算法总能提升固定比例。优先使用服务端与客户端都明确支持的选项，比较持续传输之外，也观察同一网络中的其他应用是否受到挤压。

UDP 可达性是使用前提

部分访客网络、企业网络或移动接入对 UDP 有限制，也可能对长时间流量采用不同处理。此时基于 TCP 的节点能用，而 QUIC 类节点超时，并不能直接证明认证信息错误。可以在同一设备换一个接入网络复测，并检查日志是在解析、握手还是认证阶段停止。若服务端和配置没有变化，网络切换后的差异就是重要线索。

QUIC 还可能支持连接迁移，但手机从无线网络切到蜂窝后能否顺畅恢复，要同时看客户端、系统、网络地址映射与服务端实现，不能保证完全不中断。对于游戏，还要确认游戏流量已被接管、节点允许相关 UDP 转发；能够承载游戏数据，与一定降低游戏往返时延，是两件不同的事。

五、连接速度、资源占用与手机电量

先把性能拆成四种体验

首开速度受域名解析、握手和目标站点响应影响；持续吞吐更依赖线路容量、丢包和服务端出口；交互流畅度关注请求能否及时完成；恢复能力则看熄屏、切网或闲置之后多久可以重新使用。四者可能给出不同结论。一个持续下载很快的节点，未必适合频繁唤醒的小请求；一次首开较慢，也未必影响后续长时间传输。

协议只能影响其中一部分。现代设备可能具有相应加密运算加速，具体加密方法和处理器实现会影响 CPU 成本；封装层数、数据包频率和复用策略也会改变调度开销。不能把桌面电脑上的占用结论直接搬到低功耗手机，更不能用不同服务器的两次下载，推导出协议本身的资源排名。内存占用还包含连接数、规则与缓存。

手机电量通常不是一个加密选项决定的

手机使用蜂窝网络时，无线链路从低功耗状态唤醒以及保持活跃，都可能消耗电量。频繁心跳、小包传输、失败重试和后台应用访问，会让通信模块持续工作。某个协议单次处理更轻，并不代表整机耗电一定更低；若配置让连接反复断开重建，握手和无线唤醒的总成本反而可能更高，需要从整段使用过程观察。

TUN 接管范围更广，可能让原本没有进入代理的后台连接也被处理，因此开启前后耗电不同，不一定是出口协议变重。规则规模、日志级别、连接嗅探、DNS 请求和自动探测也会产生额外工作。排查电量时应固定接管模式，先关闭不必要的高频探测与长期开启的详细日志，再比较节点协议，否则多个变量会混在一起。

保活、复用与空闲超时要一起看

较频繁的保活有时能维持中间网络的地址映射，降低闲置后重连概率，但也可能增加后台唤醒。过长的间隔则可能让映射先失效，下一次请求需要重新建立连接。合适的值取决于网络设备、运营环境与服务端超时，不能给所有手机套一个固定间隔。若服务方已给出配置，先记录现象，再一次只调整一个相关设置。

复用能减少部分连接准备，但也可能让业务共享同一连接的拥塞、故障和空闲处理。持续传输时节省的握手，不一定能抵消所有场景的共享影响。尤其是交互业务和大下载混用时，应关注网页是否被明显拖慢。对于不熟悉服务端能力的用户，不建议随意叠加多种复用扩展；先使用订阅默认行为，得到稳定基线后再做比较。

电量比较至少应覆盖相近的使用时长和屏幕亮度，观察系统电池统计时还要留意它如何归属网络服务的消耗。设备发热、系统更新和后台同步都可能干扰结果。出现异常时先找持续重试、后台高流量或连接循环，而不是直接更换全部协议。记录配置与现象后，可结合常见问题逐项缩小范围。

六、原版、Meta 与 mihomo 的内核关系

“Clash”既可能指生态，也可能指具体内核

原版 Clash 建立了广为使用的规则、策略组和 YAML 配置习惯。后来出现了不同分支、衍生实现与图形客户端，名称中带有 Clash 的软件，未必运行同一份内核。原版项目已停止维护，旧客户端中附带的内核能力也不会因为订阅更新而自动增加。理解这一点，才能解释为什么同一个文件在一台设备正常，另一台却提示未知协议或字段。

Clash Meta 是在这一生态中扩展功能的分支名称，mihomo 则承接其内核项目的后续命名。它们在用户讨论中经常交替出现，但不应把名称相同或相近理解为所有历史构建完全一致。较新的协议、安全组合和网络栈功能，仍应根据当前客户端实际使用的内核确认；历史教程中的 Meta 专用选项，也需要核对当前文档是否继续适用。

配置兼容有三个不同层次

第一层是语法能否读取，例如缩进、列表和字段类型是否符合 YAML 解析要求；第二层是内核是否认识字段，例如某种协议类型或 DNS 选项；第三层是运行环境能否完成动作，例如创建虚拟网卡、监听端口和加载证书。导入成功通常只能说明前面的部分检查通过，不能证明网络权限齐全，也不能证明全部节点已完成连通性测试。

较新的内核往往保留大量常见配置习惯，但兼容并不意味着任何旧文件都能原封不动运行。废弃字段、默认行为变化、规则资源格式和实验选项，都可能造成差异。相反，把新配置交给旧内核，通常也不能指望未知功能自动降级。遇到报错应保留具体字段路径，而不是只记住“配置错误”四个字，这样才能定位是语法还是能力问题。

图形界面可能覆盖原始配置

客户端经常通过覆写、补丁或合并配置来管理端口、系统代理、DNS 与 TUN。用户编辑的订阅文件不一定就是最终交给内核的内容。比如在文件中修改混合端口后，重新启动又恢复原值，可能是图形设置在启动时覆盖了该字段。需要查看客户端提供的运行配置或合并预览，而不是反复修改将被订阅更新替换的缓存文件。

迁移时建议先导出原配置并记录本地覆写，再在新客户端导入一份副本。先关闭 TUN，用规则模式和一个已知可用节点验证基础连接，随后逐项恢复 DNS、规则资源与虚拟网卡。这样出现问题时容易判断是哪一步引入差异。一次同时替换客户端、内核、订阅和接管方式，虽然操作更快，却会显著增加回退和排查的难度。

平台与权限仍然构成边界

Windows 的服务权限、macOS 的网络授权、Linux 的网络管理与防火墙，以及 Android 的 VPN 服务接口，都可能影响实际接管效果。iOS 客户端还要遵循自身系统接口与功能实现，不能看到同名软件就认定它与桌面端共享完全一致的内核功能。选客户端时应同时查看平台说明和导入能力，不要把桌面截图当作手机端承诺。

如果旧客户端启动就退出，不要立即认定是订阅协议太新。端口占用、权限、配置语法与运行环境也会导致启动失败，可以先参照启动崩溃排查清单获取日志，再决定更新内核、迁移配置还是调整系统设置。

七、YAML、Base64 与 SIP008 的兼容边界

订阅是配置交付形式，不是连接协议

订阅地址负责交付配置内容，里面可以包含节点，也可以包含策略组、规则和远程资源。它通过什么方式下载，与节点使用 SS、Trojan 还是 TUIC 没有直接对应关系。同一个服务方可能提供多种订阅输出，名称相似但面向不同客户端。优先选择明确标注适用于当前客户端或 mihomo 配置体系的入口，通常比事后转换更容易保留原始含义。

Clash 风格 YAML 既可能是一份完整配置，也可能只是节点资源。完整配置常见顶层字段包括代理列表、代理组和规则；节点资源则可能只有提供节点所需的部分结构，需要由主配置引用。把资源地址当成完整配置导入，可能缺少客户端所需的策略组；反过来，把完整配置交给只读取节点资源的入口，也可能提示结构不符合要求。

Base64 只说明编码，不能说明全部内容

很多订阅把多条分享链接组成的文本做 Base64 编码。Base64 本身只是编码方式，不负责加密，也不规定节点协议。解码后可能是 SS、VMess、Trojan 等链接混排，客户端还需要逐项解析其语法。它通常不具备完整规则配置那样的表达能力，因此导入后出现节点却没有原来的分组与分流规则，并不一定是下载出错。

SIP008 则是面向 Shadowsocks 服务信息的 JSON 格式，可表达一组 SS 服务器与相关字段，并不是六种协议通用的订阅容器。不能因为它也是 JSON，就把 VMess 分享链接中常见的 JSON 结构当成同一种格式。判断应看文件的实际结构与用途，而不是扩展名或是否能在浏览器中显示；订阅地址的末尾也未必能反映返回格式。

转换容易丢失的是语义，不只是字段

转换器可以把一组分享链接整理成目标客户端能读取的节点列表，但它无法从缺失的数据中恢复原本不存在的规则、策略组和健康检查。复杂传输字段如果目标格式不支持，可能被忽略、降级或直接报错。名称相似的字段也未必具有完全相同的取值范围，因此转换后的文件能解析，不等于实际连接行为与原配置一致。

订阅内容可能包含连接认证信息，订阅地址本身也可能带有访问凭据。不要把真实地址提交给来源不明的转换服务，公开求助前也应移除密码、用户标识和地址中的敏感参数。优先使用服务方原生输出或可信的本地处理方式。需要更详细的结构对比，可阅读订阅格式与互转说明。

让本地规则与订阅更新分开维护

在订阅下载得到的文件中直接追加本地规则，下次更新可能被覆盖。更稳妥的做法是使用客户端明确提供的覆写或合并功能，并理解它是替换字段还是追加列表。规则通常按顺序匹配，追加在末尾不一定生效：如果前面已经存在兜底规则，新规则可能没有机会执行。代理组中的名称引用也要与实际节点或组名保持一致。

mode: rule
mixed-port: 7890
allow-lan: false
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

上面是只做直连的最小设置示例，用来说明 YAML 缩进与规则顺序，不包含代理节点。混合端口供本机应用使用，关闭局域网访问；示例域名规则先匹配，最后一行处理其他连接。它不应直接覆盖正在使用的订阅。若要改成代理出口，需要先有真实可用的节点与策略组，再把规则目标改成确实存在的名称，不能只改一行文字。

更新订阅后节点消失时，先查看响应是否仍是预期格式，再检查导入入口、解析日志和本地筛选条件。有些客户端会按名称过滤节点，也可能保留上次选择的策略组引用。把“返回内容错误”“字段不兼容”“过滤后为空”分开排查，比反复点击更新更有效，也能避免误删仍可回退的配置副本。

八、按使用场景选择，再用日志验证

日常浏览、移动使用与持续传输

主要浏览网页、办公与同步文档时，先选订阅中参数完整、连接稳定的节点。已有可用 SS、Trojan 或 VMess，不必为了协议名字重新搭建整套配置。优先安装 Clash Plus 等适合当前平台的客户端，按快速上手教程完成导入，然后确认规则命中。规则把部分连接送到直连出口时，切换节点不会影响这些请求，这是预期行为。

手机经常熄屏、通勤切网或使用蜂窝数据时，应把恢复速度与后台重试纳入比较。可以在同一接入条件下比较一个 TCP 类节点和一个 QUIC 类节点，观察待机后是否频繁超时。不要为了保持连接而一开始就缩短所有保活间隔。若只在系统长时间后台后失效，还要检查省电策略与 VPN 服务状态，避免把系统暂停误当成协议掉线。

持续传输或远程交互对丢包比较敏感时，在网络允许 UDP 且服务端配置完整的前提下，可以试用 Hysteria2、TUIC。比较时保留 TCP 类节点作基线，并同时打开一个普通网页观察响应。大下载占满上行或下行导致其他任务卡顿，应先检查带宽目标与拥塞情况，而不是继续增加发送预期。服务器出口不足时，换本地协议也无法补足容量。

游戏、局域网共享与路由设备

游戏与实时音视频首先要确认 UDP 转发和接管范围。系统代理通常不能覆盖所有应用流量，必要时再评估 TUN。TUN 如何进入系统网络栈、DNS 如何处理，可参照系统代理与 TUN 机制对比及虚拟网卡接管说明。接管成功后仍要看服务端路径，不能承诺所有游戏都能改善时延。

手机或电视共享电脑代理时，应区分“设备到电脑的本地代理协议”和“电脑到节点的出口协议”。混合端口可以同时接收 HTTP 与 SOCKS5，但设备是否支持相应代理设置仍要确认。开启允许局域网连接后，要限制使用范围并检查防火墙；具体步骤见混合端口与局域网共享设置。路由设备则还需考虑处理器、内存、连接数与规则规模。

按连接发生的顺序排查

第一步看应用请求是否出现在连接或日志页面。完全没有记录，先检查应用代理设置、系统代理状态或 TUN 接管；有记录再看命中的规则与策略组，确认不是被送到意外出口。第二步看服务器域名是否解析成功，尤其注意 DNS 是否依赖一个尚未建立的代理路径。先解决基础解析，再讨论节点认证，否则后面的测试都没有实际发生。

第三步检查底层连接与安全握手。连接超时重点看地址、端口和网络可达性；证书错误重点看时间、名称与证书链；认证失败再核对密码、用户标识和协议代际。第四步才检查目标服务访问与 UDP 转发。不要把所有报错都归结成 DNS，也不要用关闭证书验证或全局直连把问题暂时盖住，这会丢失定位所需的线索。

最终选择不必永久固定。家庭网络、蜂窝网络和访客网络可以有不同的优先节点，但规则结构与回退方式应尽量清晰。稳定可复现的结果，比单次探测的最小数字更值得保留。需要更换客户端时回到下载页核对平台与维护状态；普通操作疑问交给常见问题，协议与内核差异则按本页目录继续查阅。