Clash 协议与内核技术参考

一、先建立协议选型方法

协议、传输层和客户端不是同一层

Clash 客户端的代理条目通常同时包含协议类型、服务器地址、端口、身份凭据、传输方式和若干扩展参数。界面里看到的“VLESS”“Trojan”或“hysteria2”只表示最外层的协议类型，并不能独立决定实际体验。相同协议若分别运行在稳定的有线网络和频繁切换基站的移动网络上，表现可能完全不同；同一台服务器若更换拥塞控制、TLS 配置或底层传输，连接时间和资源消耗也会变化。

客户端是配置和内核的外壳。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android 等图形客户端负责订阅管理、系统代理、TUN 开关和日志展示，真正解析协议并建立连接的是其内核。判断某种协议能否使用时，应依次确认客户端使用什么内核、该内核是否识别协议字段、订阅转换是否保留所需参数，以及运行平台是否允许相应网络能力。

不要只比较连接速度

选型至少应观察四项：首次握手所需的往返次数、连接建立后的吞吐稳定性、丢包时的恢复方式、设备持续运行时的资源代价。TCP 类协议通常容易理解，系统网络栈和家庭路由器对其支持成熟；基于 QUIC 或 UDP 的方案更擅长处理高延迟与一定程度的丢包，但会自行维护重传、拥塞控制和连接状态，因此参数组合与服务端实现更重要。

所谓“连接快”还需要区分三个阶段。第一阶段是 DNS 查询和寻找服务器地址，第二阶段是建立 TCP、TLS 或 QUIC 会话，第三阶段才是目标站点的数据交换。若域名解析缓慢，把问题归因于代理协议会得出错误结论；若服务器负载过高，更换客户端中的协议名称也不会改善吞吐。测试时应保持服务器、线路、时间段和目标资源一致，只改变一个变量。

先确认限制，再谈偏好

协议选择通常不是从六种方案中任意挑选，而是先排除当前服务端不提供、内核不支持或网络环境不适合的类型。订阅只给出 SS 节点时，客户端无法在本地把它直接变成 Hysteria2；VLESS 条目缺少服务端要求的 Reality 参数时，仅修改类型字段也不能完成连接。正确流程是先读取完整配置，再在可用集合中比较。

对大多数桌面用户，稳定性、配置透明度和故障可定位性比理论峰值更重要。对经常使用移动网络的用户，网络切换后的恢复速度和电量则应提高权重。需要先安装客户端时，可前往Clash 下载页选择对应平台；桌面与移动平台均优先查看 Clash Plus，其余客户端可按操作系统与界面习惯选择。

二、六类常用协议的设计取舍

Shadowsocks：结构精简，兼容范围广

Shadowsocks 通常缩写为 SS。它的配置核心是服务器、端口、密码与加密方法，协议本身相对精简，长期积累了广泛的客户端和服务端实现。对 Clash 用户而言，SS 的主要价值是配置字段少、迁移成本低、故障边界容易确认。只要双方使用相同的加密方法和凭据，基础连接通常不需要额外的传输层协商。

精简并不等于所有 SS 条目都完全兼容。部分服务端会附加插件或特定扩展，例如通过 plugin 与 plugin-opts 描述额外传输。内核若不支持对应插件，基础 SS 能力仍然存在，但该条目无法按预期建立连接。现代配置更常使用 AEAD 加密方法；遇到很早期的算法名称时，应先确认内核是否仍接受，而不是在 YAML 中反复修改大小写。

VMess：字段完整，历史配置较多

VMess 与 V2Ray 生态关系紧密，配置中常见 uuid、alterId、cipher、network、TLS 和 WebSocket 等字段。它曾被大量订阅格式采用，因此在旧配置和跨客户端转换结果中仍很常见。VMess 的优势是生态成熟、传输组合丰富，代价是配置层级较多，任何一项与服务端不一致都可能造成握手失败。

处理 VMess 时要特别区分协议身份信息和传输信息。uuid 属于身份凭据，network 决定底层传输，ws-opts 或 grpc-opts 描述具体路径与主机字段，tls 与 servername 则影响安全会话。订阅转换器若只保留 uuid 与地址，却丢失 WebSocket 路径，生成的条目看起来完整，实际仍然无法使用。alterId 多见于历史配置，新配置是否需要该字段应以服务端输出为准。

Trojan：基于 TLS 的清晰组合

Trojan 的典型条目由密码、TLS 服务器名称和可选传输参数组成。它依赖标准 TLS 能力建立安全会话，配置阅读上比多层 VMess 组合更直接。对于已经具备稳定 TLS 部署的服务端，Trojan 往往是容易维护的选择。客户端侧最常见的问题并非协议本身，而是 servername、证书名称、系统时间或传输路径不一致。

将 skip-cert-verify 设为 true 可能绕过证书验证错误，但不应把它当作常规修复手段。更合适的顺序是检查设备时间、服务器名称、证书链与订阅字段。若服务端使用 WebSocket 或 gRPC，Trojan 条目仍需携带对应参数；只看到 TLS 并不表示底层一定是普通 TCP。

VLESS：把身份与传输能力进一步拆分

VLESS 的设计强调较轻的协议层，并把加密与传输安全交给 TLS、Reality 等外部机制。配置中仍以 uuid 标识用户，但实际能否连接高度依赖 flow、network、servername、reality-opts 等组合。它适合需要明确控制传输结构的部署，也要求订阅和内核完整理解这些扩展字段。

Reality 是常见的 VLESS 配套能力，而不是一种可脱离 VLESS 单独填写的普通加密选项。客户端通常需要 public-key、short-id、servername 等信息。若订阅转换后字段名称改变或层级丢失，日志可能只表现为握手失败。排查时应将原始分享链接、转换后的 YAML 和内核日志三者对照，确认问题发生在来源、转换还是运行阶段。

Hysteria2：面向波动链路的 QUIC 方案

Hysteria2 基于 QUIC 与 UDP，重点是高延迟、存在丢包或带宽快速变化时的传输效率。它能减少传统 TCP 在部分弱网环境中的队头阻塞影响，并允许通过带宽、混淆和 TLS 相关参数调整行为。优势成立的前提是客户端到服务器之间的 UDP 通路稳定，服务端参数与证书配置正确。

Hysteria2 并不是把带宽数字填得越大越好。配置中的上行和下行带宽会参与拥塞控制判断，明显高于真实链路能力的值可能造成排队与丢包，明显偏低则限制可用吞吐。部分 mihomo 配置允许省略带宽并使用更通用的拥塞控制方式，应遵循服务端提供的条目，不要根据测速峰值随意放大。

TUIC：低延迟连接与移动性取向

TUIC 同样建立在 QUIC 之上，常见配置包括 uuid、password、拥塞控制算法、UDP 中继模式与 SNI。它重视连接建立、并发流和网络变化下的可用性，在支持良好的移动环境中有较自然的表现。与 Hysteria2 一样，TUIC 对 UDP 质量和实现版本配合更敏感。

TUIC 配置需要注意协议版本和字段语义。不同历史实现之间可能存在凭据格式或中继模式差异，不能只凭“TUIC”名称判断互通。订阅由服务端生成时应尽量原样导入；手动迁移则要参照当前 mihomo 配置语法逐项映射。若网络对 UDP 的处理不稳定，TUIC 的理论优势可能转化为频繁重连，此时成熟的 TCP 类协议反而更平稳。

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

握手次数决定首次连接的一部分成本

首次连接耗时由 DNS、传输层握手、安全握手和协议认证共同组成。SS 在普通 TCP 场景下结构较短，但目标连接仍需经过完整网络往返；Trojan、带 TLS 的 VMess 或 VLESS 需要完成 TLS 过程，启用会话恢复后，后续连接可能明显快于第一次。Hysteria2 与 TUIC 借助 QUIC 将安全与传输协商结合，并能在一个会话中承载多个流，适合大量短连接，但首次建立仍受 UDP 路径质量影响。

浏览器打开网页时常复用已有 HTTP/2 或 HTTP/3 连接，因此用户感知到的“秒开”不完全等于代理握手速度。对比时应先关闭旧连接或等待会话失效，再分别观察第一次与连续访问。Clash 日志能显示代理选择和错误阶段，但普通 info 级别不会给出每个协议内部步骤的精确计时。不要把策略组的延迟测试值直接解释为网页加载速度，它通常只代表指定测试地址的一次连接结果。

吞吐量取决于链路，而不只取决于加密

现代设备对常见 AEAD 与 TLS 加密具备较好的软件或硬件优化，单纯加密计算往往不是桌面端的首要瓶颈。服务器 CPU、单核性能、网络出口、丢包和路径 MTU 更容易限制吞吐。SS 的协议开销较容易预测；VMess、VLESS 与 Trojan 的额外消耗随传输层而变化；WebSocket 会增加封装，gRPC 依赖 HTTP/2，QUIC 类协议则在用户态处理更多传输逻辑。

资源较小的路由器需要更谨慎。QUIC 会维护加密、重传、拥塞窗口和多个流状态，在低性能处理器上可能比系统内核负责大部分 TCP 工作时占用更多 CPU。另一方面，链路丢包明显时，QUIC 避免跨流队头阻塞所节省的等待又可能抵消计算成本。因此不能只看空闲内存或某一秒的 CPU 峰值，应在真实传输持续数分钟后观察温度、负载和速率稳定性。

移动端耗电由唤醒频率和覆盖范围共同决定

手机上的电量差异通常来自无线模块唤醒、后台保活、网络切换重连和 TUN 处理范围，而不是协议名称本身。一个持续产生小数据包的连接会频繁唤醒基带；详细日志、短间隔健康检查和过密的自动测速也会增加后台活动。Hysteria2、TUIC 在弱网恢复方面可能减少等待，但若 UDP 路径不稳导致持续重试，同样会增加能耗。

系统代理只影响遵循代理设置的应用，覆盖面相对有限。TUN 模式需要接管更多流量，并处理 DNS、路由与不主动使用系统代理的应用，因此通常承担更多工作。Android 上还要考虑系统的后台限制和 VPN 服务生命周期；iOS 客户端受 Network Extension 运行方式影响。比较协议电量时，必须保持代理模式、规则集、健康检查周期和使用应用一致。

建立可重复的本地测试

有效测试应在同一设备、同一网络和相近时间完成。先关闭自动选择策略组，固定到一个条目；记录首次访问、连续访问、长传输和网络切换后的恢复情况；再更换同一服务器提供的另一协议。若服务器并非同一台，测试结果只能说明整条线路差异，不能证明某个协议更快。

四、传输层、TLS 与关键配置参数

network 字段改变的是承载方式

VMess、VLESS 与 Trojan 常通过 network 字段选择 tcp、ws、grpc 等承载方式。协议负责身份和数据格式，network 决定这些数据如何装入底层连接。WebSocket 配置通常需要路径与 Host；gRPC 通常需要 service-name；普通 TCP 可能还有额外头部选项。服务端使用何种方式，客户端必须逐项对应，不能仅凭端口是 443 就推断为某一种传输。

WebSocket 易于与常规 Web 服务部署方式组合，但每帧存在额外封装。gRPC 基于 HTTP/2，适合多路复用，不过中间网络设备和服务端反向代理必须正确支持。普通 TCP 路径直接，故障定位也较简单。选择时应以现有服务端输出为准；对普通订阅用户而言，手动更换 network 通常不会凭空获得性能提升，只会让客户端与服务器失配。

servername、Host 与服务器地址各有职责

server 字段决定客户端连接哪个主机或 IP，servername 常用于 TLS 的 SNI 与证书名称验证，WebSocket 的 Host 则属于 HTTP 请求头。三者有时相同，也可能不同。若订阅转换器把它们合并，常见结果是 TCP 已经连通但 TLS 或上层请求失败。排查时先看日志是否出现 DNS、connect、certificate、handshake 或 timeout，再定位对应层级。

设备时间也是 TLS 校验的一部分。系统时钟偏差较大时，Trojan、VLESS TLS、Hysteria2 和 TUIC 都可能报告证书有效期问题。此时更换协议或反复刷新订阅没有意义，应先恢复自动校时。对 Reality 配置，则要同时核对 public-key、short-id、servername 和 fingerprint；这些字段属于一组，缺少其中某项可能导致握手阶段终止。

UDP、MTU 与分片问题

Hysteria2 和 TUIC 依赖 UDP，其他协议也可能转发 UDP 应用流量。UDP 报文经过家庭路由器、移动网络和隧道时，可用 MTU 可能低于物理网卡标称值。过大的报文若不能正确分片，会表现为小请求正常、大数据卡住，或部分站点可用而部分连接超时。TUN 模式下还能通过客户端的 MTU 设置影响虚拟接口报文大小，但不应在没有现象依据时盲目调低。

合理的排查顺序是先保持订阅默认值，确认 TCP 类流量是否正常，再检查 UDP 协议条目。若 QUIC 连接持续超时，可切到同服务提供方的 TCP 类协议做对照；若 TCP 正常而所有 UDP 方案均失败，应优先检查本地网络、路由器与服务端 UDP 端口。只调整客户端的 skip-cert-verify 无法修复 UDP 通路问题。

一段可读的 mihomo 配置

下面示例展示字段层级，不代表可直接连接的服务。域名和凭据均为文档示例，实际使用时应采用服务端生成的完整配置。手写 YAML 时使用空格缩进，不使用制表符。

proxies:
  - name: "SS 示例"
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "Trojan 示例"
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: service.example.com
    udp: true

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - "SS 示例"
      - "Trojan 示例"

rules:
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

配置能被 YAML 解析，只表示语法成立，不表示服务端参数正确。导入后应查看客户端日志：若出现 unsupported proxy type，说明内核不识别类型；若出现字段解析错误，说明键名或层级不兼容；若条目成功加载但连接超时，则继续检查地址、端口、传输与网络路径。更多 YAML 基础词义可配合Clash 术语表阅读。

五、Clash 原版、Meta 与 mihomo 的内核关系

内核决定配置文件能否被执行

Clash 生态中的“客户端”和“内核”经常被混用。原版 Clash 是较早形成配置语法与规则模型的核心实现，提供代理组、规则分流、DNS、外部控制接口等基础能力。图形客户端围绕这些能力增加配置管理和系统集成。后来出现的 Clash.Meta 在兼容大量原版语法的基础上扩展协议、DNS、规则集与 TUN 能力；mihomo 是这一扩展内核当前常用的项目名称。

因此，“Meta 配置”与“mihomo 配置”在多数日常场景中指向同一演进路线，但历史文档、订阅生成器和客户端界面仍可能保留 Clash.Meta 字样。判断兼容性时不要只看名称，应查看客户端实际内核说明与运行日志。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 和 Clash Meta for Android 等现代客户端通常围绕 mihomo 生态提供能力，但不同平台的内核更新节奏与暴露选项不一定完全一致。

原版兼容是基础，不代表反向兼容

大部分基础 SS、VMess、Trojan、代理组与经典规则可以从原版配置迁移到 mihomo。反方向则不成立：包含 VLESS、Hysteria2、TUIC、GEOSITE、新式 rule-providers 或扩展 DNS 字段的 mihomo 配置，旧原版内核可能直接拒绝加载，或者忽略无法识别的字段。配置文件看似仍是 YAML，并不意味着任何 Clash 名称的程序都能执行。

兼容问题大致分为三类。第一类是代理类型不支持，日志通常指向 type；第二类是字段结构变化，例如某些 TLS、Reality 或 QUIC 参数需要嵌套对象；第三类是行为差异，同一字段可被解析，但 DNS、规则或接口绑定的默认行为不同。迁移时应先让最小配置通过解析，再逐步恢复 DNS、TUN、规则集和脚本能力，避免一次导入整份复杂文件后无法定位。

图形界面不会自动修复内核差异

图形客户端可以隐藏复杂字段、提供开关并显示错误，但不能让内核执行其不认识的协议。有些客户端会在导入时转换订阅，有些则把原始 YAML 直接交给内核。前者可能发生字段损失，后者可能直接报告语法错误。遇到同一订阅在不同客户端表现不一致时，应比较两边使用的内核家族、导入后的实际配置和日志，而不是只比较界面名称。

Clash for Windows 与 ClashX Meta 已属于停止维护的归档客户端。它们可用于理解历史生态，但不适合作为验证新协议兼容性的基准。需要 VLESS、Hysteria2、TUIC 或较新的 geodata 能力时，应选择仍采用 mihomo 路线的客户端。各平台当前可选软件及维护状态集中列在下载页面。

更新内核前先保存可回退配置

内核更新可能加入协议能力，也可能收紧错误配置的解析。升级前应保存当前可工作的配置与客户端设置，尤其是自定义 DNS、rule-providers、TUN 路由和外部控制接口。升级后先检查配置是否成功载入，再检查代理组是否完整，最后验证 DNS 与规则命中。若问题只在新内核出现，可以暂时回到已知可用环境并比较日志，不要同时修改订阅、规则和系统网络设置。

六、订阅格式、分享链接与转换兼容性

订阅是一种交付方式，不是一种代理协议

用户常把“订阅格式”和“协议格式”放在一起讨论。实际上，订阅负责批量描述节点、代理组和规则，节点内部才包含 SS、VMess、Trojan、VLESS、Hysteria2 或 TUIC。一个订阅可以只包含一种协议，也可以混合多种协议；同一协议也能以分享链接、通用 JSON、Clash YAML 或服务端专用响应交付。

客户端刷新订阅时通常经历下载、识别、转换、写入配置和内核加载五个阶段。下载失败表现为网络或授权错误；识别失败说明内容类型与预期不符；转换失败可能丢失扩展字段；写入失败与文件权限有关；加载失败才是 YAML 或内核兼容问题。把这五个阶段分开，能避免看到“更新失败”就重复更换协议。

Clash YAML 能表达完整结构

Clash YAML 可以同时描述 proxies、proxy-groups、rules、dns、rule-providers 等内容，适合作为客户端直接加载的完整配置。它的优势是结构清晰、可审阅和可组合；风险是不同内核支持的字段集合不同。若 YAML 由面向 mihomo 的服务生成，导入旧内核时可能出现不支持的代理类型或规则能力。

仅包含 proxies 的订阅不一定会自动生成理想的策略组。部分客户端会提供覆写或全局扩展功能，将远程节点合并进本地模板。此时要关注节点名称是否重复、策略组引用是否仍存在，以及更新后本地修改是否被覆盖。需要长期自定义规则时，通常应把远程节点与本地规则分层管理，而不是直接编辑每次都会被刷新替换的订阅文件。

分享链接适合单条迁移，但字段可能受编码限制

ss://、vmess://、trojan://、vless://、hysteria2:// 与 tuic:// 等链接便于传递单个条目。客户端读取链接后将查询参数映射到内部配置。简单 SS 或 Trojan 链接通常比较直接；携带 WebSocket、gRPC、Reality、ALPN、指纹或拥塞控制参数时，链接解析器必须识别完整参数集。

链接能被识别并出现于节点列表，不代表所有字段均已保留。导入后应查看生成配置或详情页，核对 server、port、uuid 或 password、network、servername、路径与扩展参数。若原链接来自不同生态，其参数名称可能需要转换。不要通过删除“不认识的参数”来追求导入成功，因为被删除的字段可能正是服务端握手所需信息。

刷新失败与协议不可用要分别处理

订阅 URL 无法下载时，客户端甚至还没有接触协议配置。此时应检查链接是否完整、有效期、访问方式和客户端请求行为。订阅成功更新但某个节点失败，才继续分析协议字段。所有新节点都无法加载，通常指向格式或内核；只有单个节点超时，则更可能是该服务器、端口或条目参数问题。

自动更新还可能覆盖手工改动。需要修改策略组时，优先使用客户端提供的覆写、扩展配置或本地配置功能，并保留远程订阅原件。关于链接过期、请求方式与自动更新间隔，可继续阅读Clash 订阅更新失败常见原因与自动更新间隔设置。

七、协议之外的 DNS、规则与 TUN 影响

连接失败可能发生在选择协议之前

客户端建立代理连接前，可能需要先解析服务器域名。若 DNS 无法得到地址，任何协议都会失败。日志中的 lookup、resolve 或 no such host 通常指向解析阶段；connect timeout 表示已获得地址但无法完成网络连接；handshake 或 certificate 错误则更接近协议与安全层。根据错误阶段处理，比不断切换节点更有效。

Clash 的 DNS 模块还负责目标域名解析，并可能使用 fake-ip 或 redir-host 模式。fake-ip 会先返回虚拟地址，再由内核还原域名并匹配规则，适合 TUN 与精确域名分流；redir-host 更接近返回真实解析结果。二者对应用兼容、缓存和规则行为有差异，但不改变远端节点自身属于 SS、VLESS 还是 TUIC。

规则决定使用哪个代理组

规则按顺序匹配，命中后停止继续向下。DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、GEOSITE 与 MATCH 处理的是流量去向，不负责改变节点协议。如果某条流量总是走 DIRECT，即使策略组内选中了 Hysteria2，该流量也不会经过它。排查时应同时查看规则命中记录和策略组选择。

GEOIP 依赖 IP 地理数据库，GEOSITE 依赖域名分类数据。数据库陈旧可能导致规则结果与预期不同，但不会让代理类型变得不受支持。mihomo 可使用 geodata、MMDB 与规则提供器等机制，具体文件来源和更新方式应保持一致。相关维护方法见GeoIP 与 GeoSite 数据库更新说明。

rules:
  - DOMAIN-SUFFIX,github.com,节点选择
  - DOMAIN-KEYWORD,google,节点选择
  - GEOSITE,category-ads-all,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

上述顺序先处理明确域名与广告分类，再处理 IP 地理规则，最后由 MATCH 兜底。若把 MATCH 放在最前面，后续规则永远不会执行。规则策略名必须与 proxy-groups 中的名称完全一致，包括大小写和空格。策略组引用了不存在的节点时，内核可能拒绝配置，也可能留下无法使用的组，具体取决于配置结构。

TUN 改变覆盖范围，也增加排查层级

系统代理依赖应用主动读取操作系统代理设置，浏览器通常支持，终端程序和部分游戏可能不会遵循。TUN 建立虚拟网络接口，从路由层接管更多流量，因此能覆盖更多应用，也会引入路由、DNS 劫持、MTU 和系统权限等变量。某协议在系统代理下正常、TUN 下异常时，不应立即断定协议不兼容，应先确认流量是否进入 TUN、DNS 是否被正确接管、目标是否被绕过。

移动设备通常通过系统 VPN 接口实现类似能力。操作系统可能在休眠、切换 Wi-Fi 与蜂窝网络或开启省电模式后重建接口。TUIC 和 Hysteria2 的 QUIC 会话具备适应网络变化的设计空间，但客户端、系统和服务端都必须支持相应行为；实际表现仍需在设备上验证。频繁断开时，先检查系统是否终止后台服务，再看协议日志。

用日志建立分层排查顺序

推荐顺序是：确认配置成功载入；确认代理条目出现在目标策略组；确认服务器域名解析；确认 TCP 或 UDP 端口可建立连接；确认 TLS、Reality 或协议认证；确认规则把目标流量送到该组；最后检查系统代理或 TUN 是否覆盖目标应用。每一步只回答一个问题，能明显缩小范围。

若浏览器有效而终端无效，通常是终端未读取系统代理环境，而不是协议只能支持浏览器。若所有应用在开启 TUN 后都无法解析域名，应检查 DNS 和 TUN 配置。更多常见错误可在FAQ 故障排查中按现象查找；浏览器与终端的差异流程见系统代理不生效排查。

八、按设备与网络场景选择协议

桌面日常使用：优先稳定与可维护

Windows 与 macOS 桌面设备资源相对充足，协议计算成本通常不是首要限制。若服务端提供成熟的 SS、Trojan 或带 TLS 的 VLESS 条目，可优先选择配置完整、长期稳定的一项。需要大量短连接、网络延迟较高且 UDP 通路稳定时，再比较 Hysteria2 或 TUIC。桌面端测试方便，应保留一条 TCP 类方案作为对照和故障回退。

客户端方面，优先从 Clash Plus 开始，随后可按界面与平台需求比较 Clash Verge Rev、FlClash 和 Clash Nyanpasu。客户端选择与协议选择应分开：更换图形界面可能改善配置管理体验，但若两者使用相近的 mihomo 内核，同一错误配置仍会失败。迁移客户端时导出原始订阅地址和必要的本地覆写，不要只复制界面缓存文件。

移动网络：观察切换恢复与后台行为

Android 与 iOS 经常在 Wi-Fi、蜂窝网络和休眠状态之间切换。此时应重点观察连接恢复时间、后台服务是否被系统保留、UDP 路径是否稳定以及全天电量变化。TUIC 与 Hysteria2 在条件合适时能提供较平滑的弱网体验，但如果当前运营网络对 UDP 质量不稳定，Trojan、VLESS TLS 或 SS 可能更可靠。

移动端不宜通过连续测速来选协议。高频测试本身会唤醒网络与处理器，也不能代表常用应用的长期体验。更实用的方法是分别使用候选协议一段完整工作时段，保持相同规则与 TUN 设置，记录切换网络后的恢复、音视频连续性和电量。一次峰值较高不应覆盖频繁断连的问题。

家庭路由器与小型设备：先看处理器和内存

路由器需要同时处理多台设备的连接、DNS 与规则匹配。较弱处理器上，简单 SS 或成熟的 TCP/TLS 方案通常更容易维持稳定负载。Hysteria2 与 TUIC 能改善某些高延迟链路，但 QUIC 的用户态传输和加密可能提高 CPU 占用。选择前应在真实并发下观察，而不是只让单台电脑完成一次测速。

规则集规模同样影响资源。大量 GEOSITE 分类、远程 rule-providers 和详细日志可能比代理协议多占用更多内存。若设备频繁重启或内核被终止，应先缩小配置：保留一个代理组、少量规则和单个节点，确认稳定后逐项恢复。mihomo 内核包适合熟悉命令行与服务管理的用户，普通桌面用户使用图形客户端更便于查看错误。

高延迟或存在丢包的链路：再考虑 QUIC 方案

当传统 TCP 在丢包后出现明显速率下降，而 UDP 可以稳定通过时，Hysteria2 与 TUIC 值得测试。两者都不是对所有网络自动更快。Hysteria2 的带宽与拥塞行为需要匹配链路，TUIC 需要服务端与客户端实现版本、凭据和中继模式一致。测试时与同服务器的 TCP 类条目比较，才能尽量排除线路差异。

如果小数据正常而大传输停止，检查 MTU、UDP 分片和路由器状态；如果首次可用但数分钟后断开，检查会话超时、NAT 映射与后台限制；如果从未建立连接，检查 UDP 端口、TLS 名称和认证字段。将现象归类后再调整参数，不要同时修改带宽、MTU、SNI 与证书验证。

最终决策清单

决定使用某条协议前，依次确认六件事：服务端确实提供该类型；客户端采用支持它的 mihomo 内核；订阅完整保留身份、传输和安全字段；当前网络允许所需的 TCP 或 UDP 通路；设备资源足以持续运行；同一条件下的实际测试结果稳定。六项都成立，才说明选择具有可重复性。

如果仍无法判断，优先使用服务端明确推荐且配置完整的条目，不修改高级参数。先完成导入、选择策略组、连接和验证的基础流程，再用本页方法做对照测试。首次连接的操作顺序也可参考选节点、测延迟与验证代理生效。协议没有脱离环境的永久排名，稳定、可诊断并适合当前设备，才是更有价值的结论。