协议与内核技术参考

一、协议选型的四个坐标

协议、传输、内核与界面不是同一层

客户端里的节点名称通常由提供方自行命名，名称中的“高速”“专线”不能代替技术信息。实际连接至少涉及四层：协议规定客户端与服务器如何认证和转发；传输决定数据通过 TCP、UDP 或其他承载方式发送；内核负责实现协议、解析配置并执行规则；图形界面提供订阅管理、系统代理和日志入口。同一个界面换用不同内核后，能识别的节点类型可能改变；同一种协议换了服务器和线路，使用体验也可能完全不同。

因此，选型首先是确认两端能否正确对话，而不是比较协议名称的新旧。服务端使用什么协议、认证参数、传输方式和安全设置，客户端都必须对应。节点类型支持 VLESS，并不自动意味着所有 VLESS 组合都受支持；界面能显示某个名称，也不代表运行中的内核理解其中全部字段。查看客户端的内核信息与实际配置，比仅凭应用名称判断更可靠。

把连接时间与持续吞吐分开观察

打开网页涉及域名解析、连接服务器、认证、连接目标站点以及等待首字节。第一次访问慢，可能发生在其中任意一步。大文件下载则更依赖持续传输能力、拥塞控制、服务器出口与目标站点限速。一个节点可能首字节较快，却无法长时间维持吞吐；另一个节点连接准备稍长，但持续下载更稳定。这两种表现并不矛盾，也不能用同一个延迟数值概括。

移动网络还增加了网络切换与无线休眠因素。终端从无线局域网切换到蜂窝网络后，本地地址、出口地址甚至路径质量都可能变化。某些连接需要重建，某些传输实现能够尝试迁移，但最终仍取决于内核、服务器和中间网络的共同支持。协议具备某项机制，只说明设计上存在这个能力，不等于所有部署都已启用，也不等于应用层会话必然连续。

先消除不满足条件的选项

实际选择可以采用排除法。网络不允许稳定的 UDP 出站时，先不把基于 QUIC 的协议作为唯一入口；终端内核不支持某个安全组合时，不要靠删除陌生字段强行导入；服务端只提供一种协议时，客户端也不能把它自行改造成另一种。筛出可用组合之后，再比较同一时段、同一设备和相同目标下的体验。这样得到的是当前环境中的结论，而不是脱离条件的协议排行榜。

二、SS 与 VMess 的设计取舍

SS：较小的协议范围与明确的加密参数

Shadowsocks，通常缩写为 SS，最初围绕轻量的加密代理转发构建。它的配置核心比较直接：服务器地址、端口、加密方法和密码。客户端将本地应用请求转成协议数据，服务器再建立到目标的连接。传统常见的 AEAD 方法把加密和消息认证结合起来，能够检测数据被篡改。这里的“方法”不是一个可随意替换的速度选项；两端方法不同，认证材料不匹配，连接就不能正确建立。

SS 后续出现了不同的协议规范与扩展，其中包括采用不同密钥要求的现代方案。不能因为都写着 SS，就把旧配置的密码文本直接搬到另一种方法中。有的方法接受常规密码，有的要求特定长度与编码的密钥。客户端还可能支持插件扩展，而另一款客户端并不具备同一个插件实现。遇到导入成功但持续握手失败，应先对照方法、密钥形式与插件参数，而不是反复修改本地混合端口。

在资源方面，SS 的基础结构相对集中，但真实成本取决于所选加密方法、处理器指令支持、实现质量及流量规模。TCP 和 UDP 转发也需要分别得到两端支持。节点具备 UDP 能力，不代表所有应用的 UDP 请求都会进入它：系统代理通常只影响遵循代理设置的程序，其他流量可能需要 TUN 或应用自己的 SOCKS 配置。排查语音或游戏连接时，应同时检查流量入口与节点出口。

VMess：带认证结构的代理协议

VMess 来自 V2Ray 生态，设计包含用户身份验证与请求封装，并可以结合不同传输方式使用。常见配置会出现 UUID、加密选项、传输类型和 TLS 设置。这些字段分别属于不同层：UUID 用于身份，传输字段描述连接如何承载，TLS 则负责相应链路的安全封装。把这些层次分开，才能理解为什么同为 VMess，一个节点可以直接使用 TCP，另一个却还需要 WebSocket 路径和请求主机信息。

VMess 的认证与时间相关，系统时钟偏差明显时可能导致连接异常。检查时应确认设备启用了正常的时间同步，同时核对服务端日志。历史配置中还可能出现 alterId 等字段；现代常见部署与旧式部署存在差异，不应通过随意增减数值来猜测兼容性。优先使用提供方针对当前内核给出的完整配置，迁移旧订阅时再单独确认认证模式，而不是把旧字段当成通用优化参数。

旧节点不等于失去使用价值

SS 与 VMess 的部署积累较多，兼容范围往往是现有设备继续使用它们的原因。选择时应关注服务端是否维护、加密配置是否合理、线路是否稳定，而不是只按诞生时间判断。如果已有节点满足需求，迁移到另一协议应有明确目的，例如解决特定传输兼容问题或统一配置。单纯替换类型名称不会提升线路容量，错误转换反而容易丢失插件与传输细节。

两种协议的速度没有固定先后。比较时要尽量让服务器位置、出口和目标保持一致；跨提供方测试，实际上往往是在比较服务器与网络。出现所有协议都慢的情况，可继续阅读网速慢的分层排查，先把本地入口、节点负载与线路质量分开，避免把共同故障误判成某个协议的固有缺点。

三、Trojan 与 VLESS 的安全层

Trojan：依赖正确的 TLS 链路

Trojan 的设计把代理转发放在 TLS 连接之内，使用密码进行认证。它希望复用成熟的 TLS 安全机制，因此客户端配置不仅要有服务器地址、端口和密码，还要正确处理服务器身份。证书是否在有效期内、域名是否匹配、证书链是否完整，都可能影响连接。密码正确并不能补救证书问题；反过来，TLS 握手成功也不代表代理认证已经通过，需要结合日志区分失败阶段。

这里有两个容易混淆的名称：连接地址决定网络请求发往哪里，SNI 则在适用的 TLS 握手中向服务端指明期望的主机名。二者可以相同，也可能由部署方式决定而不同。使用 IP 地址连接时，不能随意把证书验证目标也改成该 IP；应使用服务端明确提供的域名参数。客户端中的 sni 或对应界面项，是身份与路由配置的一部分，不是随便填一个热门网站域名就能改善连接的选项。

证书验证失败时，先检查设备时间、证书域名与服务端证书链。长期启用跳过验证会削弱客户端确认服务器身份的能力，不应当作常规兼容设置。若服务端采用私有证书体系，应按照客户端支持的方式建立明确的信任关系，而不是把所有验证错误都忽略。排查中即便暂时改变验证选项，也需要理解其影响，并在确认原因后恢复符合部署要求的安全设置。

VLESS：精简认证，不等于独立加密

VLESS 同样来自 V2Ray 相关生态，侧重精简的身份认证与代理请求表达。与带自身加密机制的协议不同，VLESS 本身不提供完整的传输保密，需要结合合适的安全层。客户端看到 type: vless 只是第一步，还应继续核对 TLS 或 REALITY 等安全设置、承载方式，以及服务端要求的 flow。把安全字段删掉，可能使配置无法使用，也可能偏离原本的安全前提。

REALITY 是可与相关代理组合使用的安全机制，不是把任何节点都变成 VLESS 的转换开关。涉及公钥、短标识和服务器名称等参数时，必须与服务端部署一致。公钥不是客户端自行生成后随便填入的值，短标识也不是节点名称。对于 flow，只有两端与相应传输组合支持时才能使用；某个配置示例出现该字段，不意味着其他 VLESS 节点也应该照抄。

把额外传输层的收益与代价一起考虑

WebSocket、HTTP 类传输或其他封装常用于适应既有部署架构，它们不是免费的加速层。增加封装可能带来额外请求头、握手和中间代理约束，也可能利用已有基础设施改善可达性。选型时要问它解决了什么实际问题。如果直连传输已经稳定，额外包装未必有收益；如果服务端只通过特定入口提供服务，则必须完整保留路径、主机名及相关参数，不能为了减少层数自行删减。

这两类协议适合有明确 TLS 部署条件、需要对应生态功能的场景。对于普通客户端用户，可靠的做法是导入提供方标明支持 mihomo 的配置，再检查内核日志是否接受全部字段。理解参数职责有助于定位问题，但不意味着必须手工重建节点；保留原始配置副本，通常比凭印象重新填写更稳妥。

四、Hysteria2 与 TUIC 的 UDP 条件

共同基础：QUIC 不等于普通 UDP 转发

Hysteria2 与 TUIC 都利用 QUIC 构建代理传输。QUIC 基于 UDP，并集成安全握手、可靠流与拥塞控制等机制。不能把它理解为“改用 UDP 就不再重传”；可靠数据仍需要确认与恢复，只是相关逻辑位于 QUIC 实现中。多个流之间可以减少传统单条 TCP 连接上的某些相互阻塞，但同一流内部的数据顺序、共同路径的拥塞及服务器处理能力仍会限制表现。

这类协议首先要求客户端到服务器的 UDP 路径可用。网络允许域名解析的 UDP 流量，并不证明允许任意目标端口的持续 QUIC 会话。访客网络、防火墙、运营网络以及服务器安全组都可能影响连接。若 TCP 节点可用而两类 QUIC 节点都超时，先检查出站 UDP、服务端监听与端口映射，不要立即修改认证密码。NAT 映射的存活时间也会影响长时间空闲后的恢复。

Hysteria2：以可控发送策略应对复杂链路

Hysteria2 面向高延迟、丢包等复杂网络条件设计，使用 QUIC 承载代理流量，并提供相应的拥塞控制与带宽设置机制。配置里常见认证信息、TLS 名称，以及根据部署需要出现的混淆或带宽字段。第一代 Hysteria 与 Hysteria2 不是仅改名称的同一种线协议，不能只把类型字段替换后期待互通。订阅转换器必须识别正确代际，并保留当前内核所需的参数。

带宽参数尤其容易被误用。它们可能参与发送行为的决策，不是显示给界面看的期望速度。把上行或下行写得远超可用链路，可能增加排队、丢包与其他应用的竞争；写得过低又可能限制吞吐。应按实际部署使用的拥塞控制模式理解字段，并以稳定链路测量作为依据。服务端也可以通过协商或策略约束实际行为，客户端填写更大的数字并不能增加服务器出口容量。

TUIC：多流与拥塞控制仍需端到端匹配

TUIC 同样在 QUIC 上实现代理连接，关注流复用及 UDP 转发等需求。常见配置包含 UUID、密码、服务器名称和拥塞控制相关选项。不同协议代际与实现之间存在兼容边界，不能只因为都写着 TUIC 就认定互通。客户端应使用服务端要求的协议代际与认证形式，拥塞控制名称也要由当前内核接受。未知选项被忽略和直接报错都可能发生，应查看实际加载日志。

部分实现支持早期数据或会话恢复，以减少再次建立连接时的等待。但首次连接、恢复连接与失效会话的路径不同，不能把恢复条件下的优势推广到每次请求。早期数据还涉及重放风险及服务端策略，是否启用应遵循实现文档。对普通用户而言，保持提供方给出的默认组合，再进行重复访问测试，通常比单独追求最短握手更有意义。

实际使用中，Hysteria2 或 TUIC 可以成为 UDP 路径良好时的候选，但不宜作为未经验证环境中的唯一入口。保留一个稳定的 TCP 类候选有利于区分协议问题与网络限制。它们也不能保证所有移动切网过程连续：连接标识、迁移机制、服务器策略以及客户端生命周期共同决定结果，应以切网后的实际恢复情况判断。

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

用分阶段测试代替单一测速数字

节点探测一般请求某个固定地址，并显示一次请求消耗的时间。不同客户端可能使用不同目标、连接复用策略和超时规则，所以两个界面的数值未必可以直接横比。探测请求成功，只能说明该路径在当时完成了特定测试，不能证明视频、代码仓库或实时通话都具有相同表现。目标站点的地理位置、解析结果与连接策略不同，实际业务路径也可能不同。

测试应分成三类：短连接观察页面首字节与失败次数；持续下载观察吞吐能否维持；交互业务观察抖动、重连和后台恢复。每一类都需要重复，而不是只保留最好的结果。对比时尽量固定设备、网络、服务器地区与目标地址，暂停其他大流量任务，并记录测试是否使用连接复用。若无法固定服务端，就应明确结论是在比较节点整体，而不是纯粹比较协议实现。

处理器、内存与连接规模互相影响

加密、复制数据、协议封装和拥塞控制都会消耗处理器时间。硬件加速支持、内核编译方式以及系统网络栈会改变成本，同一协议在两台设备上的排序可能不同。内存占用还受规则集大小、DNS 缓存、连接数量与日志缓冲影响。看到客户端占用较高时，不能立即归因于节点协议；先观察是否加载了大量规则提供器，是否有很多并行下载，或者界面正在持续刷新连接列表。

复用可以减少部分重复连接，但也会形成共享资源与故障范围。多个请求共用一条承载连接时，一个拥塞事件可能同时影响多个业务；不复用则可能增加握手与连接数量。嵌套复用也未必更好，尤其是协议本身已经具有多流能力时。除非能够说明具体收益，并确认内核与服务端支持，否则应优先沿用默认配置，避免同时打开所有看起来能够减少延迟的选项。

电量主要看全天行为，而不是一次峰值

移动端耗电不仅来自加密计算，还来自无线模块被唤醒的次数与持续活跃时间。频繁健康检查、过短的保活间隔、反复失败重连、后台订阅刷新和详细日志，都可能增加耗电。某个协议下载时处理器占用更低，并不意味着待机也更省电；如果它所在网络的 UDP 映射很短，客户端不断维持或重建会话，全天成本可能反而增加。需要把活跃使用与待机分开观察。

TUN 通常会让更多符合路由条件的流量进入内核，因此启用前后的耗电差异也可能来自处理范围变大，而不是协议效率改变。系统代理只接管遵循系统设置的应用，两者的工作量并不天然相同。比较电量时应固定接管模式、规则与后台应用，至少覆盖相似的使用时段，同时留意系统是否限制了客户端后台运行。客户端被系统挂起导致“省电”，可能伴随连接中断，不能当作优化成功。

不建议给六类协议标注固定的“省电等级”或“速度星级”。这些标签会掩盖硬件、线路与设置差异。更有用的结论是带条件的：在当前手机、当前网络与固定接管模式下，哪个节点满足业务且后台更稳定。每次只改变一个变量，出现退化时即可回到上一个状态，不必同时替换内核、协议和 DNS 设置。

六、原版、Meta 与 mihomo 的关系

内核演进与配置谱系

原版 Clash 建立了规则分流、代理组、配置文件与控制接口等广泛使用的工作方式。Clash.Meta 在相关代码与配置体系上扩展协议和功能，后来以 mihomo 名称继续演进。阅读旧资料时，“Meta 内核”和“mihomo”常指向同一条后续演进脉络的不同阶段，但不代表任意时间点的功能完全相同。讨论兼容性应落实到运行中的实现与具体字段，而不是只看历史名称。

原版配置中的许多基础概念仍能在 mihomo 中看到，例如 proxies、proxy-groups 和 rules。这形成了较强的使用连续性，但不是双向兼容承诺。较新的配置若包含原版没有实现的协议、规则类型或 DNS 选项，原版不会因为文件仍是 YAML 就自动理解。迁移方向通常比名称更重要：基础配置向扩展实现迁移，与扩展配置退回旧实现，是两类不同任务。

客户端是管理层，不是内核的同义词

Clash Plus、Clash Verge Rev、FlClash 和 Clash Nyanpasu 等客户端提供不同的界面与集成方式。下载页优先列出 Clash Plus，适合先从图形界面完成订阅管理与常规设置；其他客户端按平台和功能需求选择。界面中的系统代理、服务模式、TUN 权限和配置覆写，往往由客户端与内核共同完成。某个界面没有显示高级字段，不代表内核不支持；界面提供按钮，也不代表系统权限已经满足。

不同客户端还可能生成自己的运行配置。用户导入的是订阅原文，客户端启动内核时使用的则可能是经过端口注入、规则合并与覆写后的文件。排查时必须知道查看的是哪一份。直接编辑生成文件，可能在下次切换配置或重启后被覆盖；修改订阅原文，也可能被随后的更新替换。应优先使用客户端提供的持久化覆写入口，并检查实际运行配置是否体现了修改。

迁移检查与权限检查分开进行

迁移前保留现有配置、代理组选择和覆写设置，再用新客户端导入副本。先关闭复杂覆写验证基础配置，检查协议是否识别、代理组引用是否存在、规则提供器是否能获取。确认基础连接后，再逐项恢复 DNS、TUN 与自定义规则。这样一旦失败，可以知道是哪一步引入问题，而不是在一份同时变化了多个层面的配置里寻找原因。

若基础代理可用而 TUN 不工作，应转向权限、驱动、路由与系统服务排查，不要立即换协议。若系统代理开启后只有终端无法访问，应确认终端是否读取系统代理，参见浏览器与终端分开排查。这些问题发生在入站或应用层，和服务器使用 SS 还是 Trojan 通常不是同一个故障点。

七、订阅格式与配置兼容性

同一个“订阅”入口可能接收不同内容

订阅是一种交付方式，不是单一文件规范。链接返回的内容可能是完整 Clash YAML、只有节点的集合、编码后的分享链接列表，或者网页错误信息。完整配置通常含代理组、规则和 DNS 等设置；节点集合只提供服务器条目，需要由客户端或模板补足其他部分。因此“链接能打开”不等于“返回了可运行配置”，导入失败时应先检查响应类型和结构，再判断客户端能力。

分享链接中的 SS、VMess、Trojan、VLESS 等形式有各自的参数表达，编码与转义方式也不完全一致。转换器把它们映射到 YAML 时，需要保留认证、传输、安全与扩展字段。某个转换器认识协议名称，却不认识较新的参数时，可能输出表面完整但实际缺项的节点。尤其是 REALITY、flow、插件和 QUIC 相关选项，不应因为转换成功就默认已经完整保留。

YAML 能解析，不代表语义正确

YAML 对缩进、列表和映射有明确规则。建议使用空格缩进，并让包含特殊字符的字符串使用合适的引号形式。解析阶段通过，只说明文件结构合法；代理组引用了不存在的节点、规则指向不存在的策略，仍然可能使运行失败。节点重名也会造成选择歧义。对复杂订阅，应分开看语法错误、字段错误、引用错误与运行时网络错误，不要用同一种“更新失败”概括所有情况。

下面的片段只展示 mihomo 中本地入站与规则的最小关系，不包含远程代理服务器。混合端口接受 HTTP 与 SOCKS 代理请求，局域网访问关闭，所有匹配流量走直连。它适合用于理解配置层级，不是用于替换现有订阅的远程节点配置。实际使用代理时，还需要添加真实节点与相应代理组，并把规则指向正确的组名。

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

本地端口与远程节点端口属于不同端点。修改 mixed-port 后，需要同步修改手工配置代理的应用；远程服务器端口则必须与服务端监听一致。订阅内容中的 allow-lan 也不是节点性能选项，它改变的是本机入站是否允许局域网访问。共享代理前应同时理解监听范围、防火墙与身份验证，不能只因为手机需要连接，就把所有网络接口向外开放。

远程提供器、覆写与更新的边界

proxy-providers 用于获取节点集合，rule-providers 用于获取规则集合。两者用途不同，不能把完整客户端订阅随意放进只接受特定节点结构的提供器。更新失败还可能来自 DNS、访问路径、服务端认证、响应内容或本地文件权限。查看日志时，应记录是下载阶段失败，还是下载成功后的解析失败；前者需要排查网络与响应，后者应核对格式和内核字段支持。

订阅自动更新会重新取得上游内容，本地直接改写其中的规则往往不能持久保存。较稳妥的方式是把个人设置放在客户端支持的覆写或合并机制中，同时理解它的覆盖顺序。列表是整体替换还是追加、同名映射如何处理，各客户端可能不同。每次调整后查看运行配置，确认没有意外删除原有代理组或把分流规则全部覆盖为最后一条匹配。

初次导入与更新入口可参照订阅导入步骤。处理兼容问题时，优先向提供方索取明确面向 mihomo 的格式，再比较原始内容和运行配置之间的差异。只换订阅文件后缀、只改节点类型名称或反复编码解码，都不能补回已经丢失的协议参数。

八、按场景选型与验证

桌面、移动与服务器分别确定约束

桌面日常浏览优先考虑兼容性和可维护性。已有稳定 SS、VMess 或 Trojan 节点时，不必仅为更换协议而迁移；需要 VLESS 特定组合时，再确认 mihomo 与服务端参数一致。客户端可先选择下载页首推的 Clash Plus，也可以按平台考虑 Clash Verge Rev、FlClash 等选项。桌面环境通常有较充足的资源，但系统代理、浏览器扩展和终端环境变量仍可能互相独立，需要分别验证。

移动设备优先观察后台恢复与切网表现。先保持一个已验证稳定的节点，再比较 Hysteria2 或 TUIC 在当前蜂窝网络中的收益。不要同时改变协议、测速频率和 TUN 模式，否则难以解释电量变化。Android 可按设备架构从下载页选择对应客户端；iOS 的客户端入口与系统网络扩展机制不同，使用 Clash Plus 时应以其实际支持的导入格式与功能为准，不应把桌面 mihomo 的所有字段机械套用。

服务器和路由器更强调架构、常驻运行与暴露面。选择内核包前核对处理器架构、操作系统及运行环境，配置独立的运行目录与持久化策略。外部控制接口不要直接暴露到不可信网络；本地代理端口、控制接口和远程服务器监听端口要分开管理。无界面部署可阅读Linux 图形客户端与命令行服务部署，先建立可维护的服务，再讨论更复杂的分流。

沿请求路径建立故障分支

验证从本地开始：确认内核已运行、端口未被其他程序占用，再确认应用请求确实进入代理。连接列表里没有对应请求时，先查系统代理、应用设置或 TUN 路由；有请求但选错节点时，检查模式、规则与代理组；选对节点仍失败，才继续查看认证、TLS 与远端连接。这个顺序能够避免把入站故障当作协议不兼容，也避免在规则根本未命中的情况下反复测速。

DNS 也需要单独判断。服务器域名解析失败，会阻止代理连接建立；目标网站解析异常，则可能表现为部分站点打不开。使用假地址映射的 DNS 模式时，应用看到的地址还可能不是目标站点的真实地址，应结合内核日志理解，不能仅凭一次系统解析输出下结论。修改 DNS 后需要考虑缓存与旧连接，确认新请求确实使用了调整后的路径，再评价效果。

需要确认 HTTP 代理入口时，可以在本机使用下面的命令访问一个测试站点。它显式指定混合端口，适合区分终端没有读取系统代理与内核本身无法转发。该命令只验证一次 HTTP 请求，不验证 UDP、其他应用或全部分流规则。若端口已经修改，应同步替换命令中的端口；若测试目标本身不可达，也应使用另一个已知正常的目标交叉确认。

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

保留可回退的选择，而不是堆叠开关

最终配置应包含明确的主用节点、必要的备用节点，以及能够解释的分流规则。每次只改变一个关键设置，并保留修改前的配置副本。观察到收益后，再在相似使用时段复测；只有偶尔一次更快，不足以说明适合长期使用。对于频繁失败的候选，先定位网络条件或参数差异，再决定是否放弃，不必把它继续放在高频自动测试循环里增加资源消耗。

本页的选择原则可以压缩为一句技术判断：先满足端到端兼容，再按实际业务比较成本。完成选型后，使用连接验证步骤检查应用访问；需要接管不读取系统代理的程序，再查阅TUN 模式原理与权限要点。协议解决的是客户端到服务器的通信约定，不能代替正确的本地入口、DNS、规则与系统权限。