Clash 协议与 mihomo 内核选型手册

建立可复用的协议选型模型

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

在 Clash 配置界面中看到的 SS、VMess、Trojan、VLESS、Hysteria2 和 TUIC，属于节点连接方式；Clash Plus、Clash Verge Rev、FlClash 等名称则指图形客户端；mihomo 是负责解析配置、建立连接和执行规则的内核。三者处于不同层级。客户端决定操作入口与系统集成方式，内核决定配置语法和协议能力，协议决定单条代理连接如何握手、加密、复用及传输数据。把这些概念混在一起，常会出现“更换客户端后速度是否一定提高”或“订阅能导入是否等于节点可用”一类误判。更换图形界面通常不会直接改变线路条件，但客户端携带的内核版本、默认 DNS、TUN 实现和连接参数可能改变最终表现。

协议选择也不是简单的速度排名。一次连接的实际体验由服务器处理能力、客户端设备性能、网络往返时间、丢包、传输层行为、域名解析路径以及规则命中结果共同决定。协议只控制其中一部分。比如在稳定的有线网络中，传统 TCP 协议往往表现平稳；在频繁切换基站、存在随机丢包的移动网络中，基于 UDP 并自行管理拥塞控制的方案可能恢复更快，但其持续运行、保活和重传策略也可能增加电量消耗。脱离网络条件讨论“最快协议”，结论通常不具备可重复性。

用四个问题缩小范围

第一，确认当前客户端内核是否支持目标协议及其必需字段。原版 Clash 的能力范围较早固定，后续出现的 VLESS、Hysteria2、TUIC 等类型主要由 Meta 分支和 mihomo 扩展。第二，确认订阅提供的是完整节点参数，还是仅有名称与服务器地址。协议名称相同并不代表配置可以互换，认证标识、TLS 服务器名称、传输类型、UDP 支持、跳过证书检查等字段都可能影响握手。第三，明确主要平台。桌面设备更看重系统代理、TUN 覆盖与长期稳定；移动设备还要评估后台保活、网络切换和电池限制。第四，判断主要流量是短连接浏览、持续下载、实时音视频还是大量并发请求，因为不同连接模式对握手成本、队头阻塞和复用的敏感程度不同。

1. 先确认可解析

   在客户端中导入后检查节点类型是否被识别，配置日志中不应出现未知类型或缺失字段。

2. 再确认可连接

   用同一网络分别测试握手、网页访问与持续传输，不只依据一次延迟探测。

3. 最后确认适合长期运行

   观察网络切换、系统休眠恢复、后台耗电和规则命中，避免把短时峰值当作稳定结论。

保持测试条件一致

对比协议时应固定客户端、内核、服务器区域、测试时段和 DNS 设置，并避免同时打开会持续占用带宽的同步程序。先记录直连网络的基础状态，再逐个测试候选节点。延迟测试主要反映探测请求的往返时间，不等同于页面打开速度；下载峰值也不能代表弱网恢复能力。更可靠的方法是连续完成三类任务：多次打开包含多个资源的网页、进行数分钟稳定传输、在 Wi-Fi 与蜂窝网络之间切换后观察连接恢复。若结果差异很小，应优先选择配置更简单、客户端支持更成熟的一项，而不是为了理论特性增加参数复杂度。

SS、VMess、Trojan、VLESS、Hysteria2 与 TUIC 的设计取舍

SS：结构简洁，兼容范围广

Shadowsocks 通常简称 SS，其设计重点是以较少的协议层完成加密代理。节点配置主要围绕服务器、端口、密码和加密算法展开，字段数量相对有限，因此在不同客户端与订阅格式之间迁移时更容易保持一致。现代实现通常使用 AEAD 类加密算法；选择算法时必须同时确认客户端和服务端支持，名称相近但实现范围不同的算法不能随意替换。SS 的优势是实现成熟、握手负担较低、设备覆盖广，适合希望减少配置变量的场景。它本身不定义复杂的传输伪装层，附加插件或其他传输封装会引入额外兼容要求，此时不能再把“支持 SS”理解成“支持所有 SS 扩展”。

VMess 与 VLESS：从一体化认证到轻量协议层

VMess 将用户标识、认证与连接流程组合在协议中，常见配置包含 UUID、传输网络、TLS、Host、Path 等字段。它诞生于需要统一管理多种传输方式的客户端生态，因此历史订阅中存量较多。其问题不在于无法使用，而在于参数组合较多：WebSocket、HTTP 类传输、gRPC 或普通 TCP 的字段位置不同，订阅转换时容易丢失路径、主机名或服务名称。排查 VMess 时，应从传输类型开始核对，不能只比较 UUID 与端口。

VLESS 将协议层做得更轻，通常把机密性与服务端身份验证交给 TLS 等外层机制处理。也就是说，VLESS 自身不是“选上名称就自动具备完整加密”的一体化方案；客户端必须正确处理 TLS、服务器名称、证书验证以及所选传输。其优势是协议开销较清晰，便于与不同传输组合，也因此更依赖配置完整性。若订阅转换工具只保留了服务器和 UUID，却遗漏 flow、server name、transport 或 Reality 相关字段，节点会导入但握手失败。mihomo 对 VLESS 的支持较完整，但仍应以实际配置字段和当前内核可识别的语法为准。

Trojan：以 TLS 连接为基础的直接模型

Trojan 的常见配置围绕密码、TLS 服务器名称和证书验证展开，数据承载于 TLS 连接之上。它的理解路径比较直接：先确保域名与证书关系正确，再确认密码和端口，最后检查是否启用 UDP。Trojan 不是“任何情况下都比 VMess 快”的同义词；当两者使用相同网络路径和相近传输时，差异可能小于线路波动。它更实际的价值是配置模型清楚、主流 Meta 与 mihomo 客户端支持成熟。若使用 IP 地址连接但 TLS 仍要求域名身份，必须保留正确的 server name，不能把服务器地址机械复制到所有 TLS 字段。

Hysteria2 与 TUIC：面向 UDP 传输和弱网恢复

Hysteria2 基于 QUIC 体系组织连接，并在应用侧关注拥塞控制与丢包环境下的吞吐恢复。它适合往返时间较高、带宽变化明显或偶发丢包的网络，但效果依赖 UDP 可达性、服务端参数和合理的带宽设置。把上行或下行能力填写得远高于真实网络，不会凭空增加速度，反而可能造成排队和抢占。配置时还需核对认证密码、TLS 服务器名称、端口跳跃或混淆等可选项是否由两端共同启用。

TUIC 同样建立在 QUIC 与 UDP 之上，强调多路连接、认证和网络变化时的连续性。它常见于 mihomo 兼容配置，字段可能包含 UUID、密码、拥塞控制算法、UDP 中继模式和证书选项。TUIC 与 Hysteria2 不能仅凭“都走 UDP”视为可替换协议：二者握手、认证、参数名称及服务端实现不同。选择时应看服务端实际提供哪一种，而不是在客户端中手动修改节点类型。移动网络下它们可能较快恢复连接，但持续保活、较活跃的 UDP 会话和系统后台策略也会影响耗电。

连接速度、稳定性与资源占用的正确比较方法

握手速度与持续吞吐不是同一指标

网页首次打开更容易受到 DNS 查询、TCP 或 QUIC 建连、TLS 握手以及首个请求响应时间影响；大文件传输则更依赖拥塞控制、线路容量和持续丢包状态。SS 的协议层较简洁，通常不会引入复杂的附加握手；Trojan、启用 TLS 的 VMess 和 VLESS 需要完成 TLS 流程，但连接复用与会话恢复会降低后续请求成本；Hysteria2 与 TUIC 通过 QUIC 建立安全连接，首次连接同样有握手过程，建立后可在一条连接中承载多个流。因而“点一下延迟测试”只能观察很窄的一段行为，无法完整表示持续下载或多资源页面的体验。

TCP 的队头阻塞意味着同一连接中的丢包可能让后续数据等待重传。QUIC 在流级别处理传输，可以降低一个流丢包对其他流的牵连，但底层网络若对 UDP 质量较差，理论优势可能无法体现。某些网络会给 UDP 较短的会话保持时间，导致空闲后重新握手；某些路由器在大量 UDP 会话下处理能力有限。选型时应观察真实应用：短连接频繁失败、长传输速度波动、休眠恢复慢，分别对应不同问题，不能统一归因于协议名称。

CPU、内存和连接数量

资源占用首先取决于内核实现与规则规模，其次才是协议。大量规则集、复杂 DNS 处理、TUN 流量接管、连接嗅探和日志级别都可能比协议加密本身占用更多资源。SS 使用现代 AEAD 算法时，桌面处理器通常可以高效执行；在较老的低功耗设备上，不同算法是否具备硬件加速会影响 CPU 使用。VMess 的协议处理和多层传输组合可能增加一定工作量，尤其是叠加 WebSocket、TLS 与复用时。Trojan 和 VLESS 的成本与 TLS 实现及所选传输紧密相关。Hysteria2、TUIC 需要维护 QUIC 状态、确认和拥塞控制，在高速或丢包环境中可能使用更多 CPU，但也可能用更好的吞吐恢复缩短任务完成时间。

内存占用不能只看客户端主进程。图形界面、WebView、系统托盘、日志缓存和内核通常共同存在。比较 Clash Plus、Clash Verge Rev 或 FlClash 时，应在相同配置、相同运行时间和相同连接数量下观察，并区分界面进程与 mihomo 内核进程。一个客户端空闲时占用较低，不代表加载数十万条规则后仍然相同；一个协议单连接开销较小，也不代表开启大量并发后没有累积成本。对于路由器和小型服务器，减少规则提供者数量、关闭不需要的详细日志、控制连接复用与并发，通常比反复更换协议更有效。

可重复的三阶段测试

第一阶段测试建连：清理旧连接后连续访问多个不同域名，记录是否出现首次等待或偶发握手失败。第二阶段测试稳定传输：在数分钟内观察速度曲线、CPU 使用和连接重置，而不是只记录瞬时峰值。第三阶段测试恢复：让设备休眠后唤醒，或在 Wi-Fi 与移动网络之间切换，检查节点是否自动恢复、DNS 是否继续工作、旧连接是否被正确清理。每个候选协议至少重复两轮，并保持规则模式一致。如果某次结果异常，应先查看日志中的 timeout、TLS、DNS 或 UDP 错误类型，再决定是否计入比较。

移动端电量、后台运行与网络切换

耗电来自持续工作，而不只来自加密

移动端运行 Clash 类客户端时，电量消耗由网络收发、CPU 唤醒、VPN 或 TUN 接管、DNS 查询、规则匹配、日志写入以及系统后台调度共同构成。协议加密只是其中一项。若应用持续保持大量连接、频繁进行健康检查，或策略组以较短间隔测试多个节点，即使实际流量很少，设备也可能不断从低功耗状态被唤醒。相反，一个计算稍复杂但能稳定保持连接的协议，实际耗电未必高于频繁断线重连的简单协议。因此应以一段完整使用周期观察，而不是依据几分钟内的系统电量百分比作结论。

SS、Trojan、VMess 和 VLESS 常运行在 TCP 或基于 TCP 的传输上。系统对 TCP 的连接状态管理成熟，空闲连接通常容易进入较低活动状态，但移动网络切换后旧连接可能需要超时或重新建立。Hysteria2 和 TUIC 基于 UDP 与 QUIC，能够在一定条件下更快处理网络变化，也可能通过更活跃的确认、保活与拥塞控制保持会话。其耗电结果取决于客户端实现、keep-alive 参数、网络质量和系统对 UDP 的处理，不能直接概括为某一类协议一定更省电或一定更耗电。

Android 的电池优化与后台限制

Android 厂商对后台应用、VPN 服务和自启动策略的处理差异较大。若客户端在锁屏后被系统停止，表面现象通常是通知消失、网络无法访问，重新打开应用后恢复。这种情况首先应检查系统的电池优化、后台活动、VPN 常驻通知和自启动权限，而不是立即更换节点协议。Clash Plus、Clash Meta for Android 与 FlClash 的界面路径不同，但判断逻辑一致：确认内核仍在运行，再确认 VPN 接口存在，最后查看节点连接日志。若内核反复重启，应降低健康检查频率、暂时关闭详细日志，并检查配置是否包含过大的规则集。

策略组也是常见耗电来源。url-test 会按设定间隔探测多个候选节点；节点数量多、间隔短时，会产生持续网络唤醒。fallback 需要监测可用性，load-balance 则可能同时维护更多连接。移动设备若主要使用固定节点，可以减少候选数量并适当延长测试间隔。关于这些策略的差异，可继续阅读Clash 策略组类型详解。规则提供者的更新间隔也应合理设置，没有必要在短时间内重复拉取变化很少的列表。

iOS 与系统 VPN 生命周期

iOS 客户端通过系统提供的网络扩展能力工作，应用界面退出并不必然代表代理连接停止，真正状态应以系统 VPN 标识和客户端内核状态为准。Clash Plus 在 iOS 端通过 App Store 提供，配置时应注意系统首次建立 VPN 的授权提示。若切换 Wi-Fi 后短暂无法解析域名，应先等待系统网络路径稳定，再检查 DNS 与节点重连；频繁手动开关可能让问题更难复现。后台运行受系统统一管理，用户可调整的项目比 Android 少，因此应优先保持配置简洁，减少高频探测和不必要的日志。

用系统统计做长期观察

评估协议耗电时，选择两个日常使用强度接近的时段，分别运行候选协议，保持屏幕亮度、网络类型、策略组和后台应用大致一致。观察系统电池页面中的前台时间、后台时间与网络活动，而不是只比较总百分比。若某次出现异常耗电，先判断是否伴随客户端重启、连接失败、节点探测增多或网络信号较弱。弱信号会让蜂窝基带增加发射功率，其影响可能明显大于代理协议本身。更完整的检查流程见Clash 移动端耗电异常排查。

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

原版 Clash：配置基础与兼容基线

原版 Clash 建立了广泛使用的 YAML 配置结构，包括 proxies、proxy-groups、rules、DNS、规则提供者与控制接口等核心概念。许多订阅转换器和图形客户端仍以这些字段作为兼容基线。它对 SS、VMess、Trojan 等常见类型形成了成熟语法，但项目维护状态和功能范围已经固定，后续协议与更复杂的网络能力不应默认存在。看到某份配置标注“Clash 格式”，通常只表示它采用了这一配置家族，并不保证能在原版内核中解析所有节点。

原版语法仍有重要价值：基础代理组、域名规则、IP 规则和 MATCH 规则具有较强可迁移性。若配置只使用这些通用能力，在不同衍生内核间移动通常较平稳。问题主要出现在扩展节点类型、规则语法、DNS 高级选项、TUN 参数和协议专属字段上。因此，判断兼容性不能只看文件扩展名是 YAML，也不能只看顶层键名；应逐项确认内核是否认识节点的 type、策略组行为和扩展规则。

Clash Meta：面向新协议与高级网络能力的分支

Clash Meta 在原版配置模型上扩展了 VLESS、Hysteria、Hysteria2、TUIC、WireGuard 等类型，并加强 DNS、规则、TUN、嗅探和传输参数。许多旧资料把支持这些能力的内核统称为 Meta。对用户而言，关键不是记忆分支历史，而是理解 Meta 配置可能包含原版不认识的字段。将 Meta 订阅导入只支持原版 Clash 的客户端，轻则忽略部分参数，重则在载入阶段直接报错。反向迁移通常更容易：基础原版配置大多能被 Meta 系内核读取，但某些默认行为仍可能不同。

mihomo：当前常用的延续实现

mihomo 延续并维护 Meta 系能力，是 Clash Plus、Clash Verge Rev、FlClash 等现代客户端常见的内核选择。它保留 Clash 配置的主要组织方式，同时继续支持新协议、规则集、TUN 与 DNS 相关功能。名称变化并不意味着配置必须从零重写，许多 Meta 配置可继续使用；但“通常兼容”不等于所有历史字段永久等价。升级客户端或迁移配置后，应查看启动日志中的弃用提示、未知字段和解析错误，并针对当前文档调整，而不是让转换器反复改写整份文件。

图形客户端与内核并非固定绑定关系。有些客户端允许切换内核或更新内核组件，有些则将内核与应用发布包一同提供。排查时应在“关于”“内核”或日志页面确认实际运行的是哪一类实现，不要只根据客户端名称推断。Clash for Windows 与 ClashX Meta 已停止维护，它们仍可能读取部分旧配置，但不适合作为验证新协议兼容性的唯一环境。需要 VLESS、Hysteria2 或 TUIC 时，应优先使用明确采用 mihomo 或兼容 Meta 能力的客户端。

mixed-port: 7890
mode: rule
ipv6: false

profile:
  store-selected: true
  store-fake-ip: true

以上片段只使用常见顶层设置，可作为检查 YAML 缩进和内核载入的最小起点。它不包含节点、订阅地址和规则，不能单独完成代理连接。完整配置应由可信订阅或明确的手动参数补充。进一步了解项目关系，可阅读Clash 开源生态项目关系与原版、Meta 与 mihomo 功能兼容性对比。

订阅格式、YAML 字段与转换兼容性

能导入不代表字段完整

订阅通常以两种形态进入客户端：一类是完整 Clash YAML，已经包含节点、策略组、规则和 DNS；另一类是节点链接集合，由客户端或转换服务解析后生成本地配置。完整 YAML 更容易保留策略结构，但可能使用特定内核扩展；节点链接更便于在不同软件间传递，却不一定能表达所有高级字段。导入成功只说明文件可以被读取，不能证明每个节点都保留了原始传输参数。尤其是 VMess、VLESS、Hysteria2 和 TUIC，字段较多，转换链越长，遗漏的可能性越高。

SS 节点链接通常包含加密算法、密码、服务器和端口，结构相对直接；Trojan 还需关注 TLS 服务器名称、ALPN 和证书相关选项；VMess 与 VLESS 可能包含网络类型、Host、Path、service name、flow、指纹和 TLS 配置；Hysteria2 涉及认证、服务器名称、端口及可选传输参数；TUIC 则常见 UUID、密码、拥塞控制和 UDP 中继设置。若转换后节点名称仍在但无法连接，应将转换前后的关键字段并排比较，而不是反复点击更新订阅。

Clash YAML 的三个层次

第一层是节点定义，即 proxies 中每个连接的类型和参数。第二层是策略组，即 proxy-groups 如何组合节点、决定手动选择或自动检测。第三层是规则，即 rules 如何把域名、IP 或其他匹配结果交给策略组。三层相互引用：规则写的是策略组名称，策略组引用节点或其他组，节点才包含服务器连接信息。修改名称时必须同步引用，否则会出现策略组找不到节点或规则指向不存在目标的错误。

proxies:
  - name: "HY2-example"
    type: hysteria2
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    skip-cert-verify: false

proxy-groups:
  - name: "手动选择"
    type: select
    proxies:
      - "HY2-example"
      - DIRECT

rules:
  - MATCH,手动选择

该示例展示节点、策略组和最终规则的引用关系，服务器与密码为明确示例值。真实配置中应替换为实际提供的参数，并保持空格缩进一致。YAML 不允许用制表符代替层级缩进；含特殊字符的名称建议加引号。若客户端提示解析错误，先检查缩进、冒号后的空格和重复键，再检查协议字段。若配置能载入但节点握手失败，则转向服务器地址、认证、TLS 和传输参数，不应继续修改 YAML 排版。

订阅转换的边界

订阅转换适合完成格式整理、节点筛选、名称处理和基础策略组生成，不适合猜测缺失参数。转换器无法从一个普通 SS 链接推导出 VLESS 的 UUID 与 TLS 结构，也不能把 Hysteria2 节点仅通过改写 type 变成 TUIC。即使源和目标都属于 Clash 配置家族，目标模板若基于原版字段，也可能过滤 mihomo 扩展。转换后应保存一份源配置用于对照，并重点检查节点数量、协议类型、TLS 字段、策略组引用和规则末尾的 MATCH。

远程规则提供者与远程订阅还涉及更新失败后的行为。客户端通常会保留最近一次成功下载的配置，但具体缓存策略取决于实现。更新后突然出现大量节点缺失，应先查看配置更新时间与下载日志，避免立即覆盖仍可工作的本地副本。订阅地址属于敏感配置，不应发布到公开页面或日志截图中。需要排查时，可遮盖地址参数，只保留错误状态、响应类型和客户端提示。

客户端、操作系统与协议能力的匹配

图形客户端首先解决系统集成

选择客户端时，先看操作系统支持、内核类型、系统代理与 TUN 集成，再看界面偏好。Clash Plus 覆盖 Windows、macOS、Android 与 iOS，是本站各平台的首推入口，适合希望在多个设备上保持相近操作逻辑的用户。Clash Verge Rev 适合 Windows、macOS 与 Linux 桌面环境，常用于 mihomo 配置管理、系统代理和 TUN。FlClash 覆盖桌面与 Android，可作为跨平台备选。Clash Nyanpasu 面向 Windows；Clash Meta for Android 与 Surfboard 可用于 Android；ClashX Meta 和 Clash for Windows 已停止维护，更适合处理已有环境，而不是承担新协议选型。

客户端支持某协议通常意味着其所带内核能够解析并建立该类型连接，但还需确认图形界面是否完整暴露参数。例如手动添加节点时，界面表单可能只覆盖常用字段，而导入 YAML 可以保留更多高级参数。遇到表单没有 flow、sni、udp relay mode 或拥塞控制选项时，不要用含义相近的字段代替，可改用完整配置导入并通过日志确认。各平台可用安装包和客户端顺序见下载页，下载相关问题可查看下载页常见问题。

Windows：系统代理、TUN 与应用差异

Windows 上的系统代理主要影响遵循系统设置的应用，部分程序会使用自己的网络栈。需要更完整接管时可使用 TUN，但通常需要额外权限和虚拟网络接口。协议本身不会改变哪些应用遵循系统代理；这是客户端运行模式决定的。若浏览器正常而商店应用异常，应检查应用回环限制与代理路径，参考Windows UWP 应用无法使用 Clash 的处理步骤。启用 TUN 后若出现局域网访问变化，还应核对路由、DNS 与排除项，而不是先更换 SS 或 VLESS。

macOS 与 Linux：权限、系统服务和架构

macOS 的系统代理适合常规桌面应用，TUN 或增强模式涉及系统网络扩展与权限确认。Apple Silicon 与 Intel 安装包架构不同，但配置文件中的协议语法通常相同。Linux 桌面可以使用 Clash Verge Rev 或 FlClash；服务器和路由环境则更适合直接运行 mihomo 内核，通过配置文件与控制接口管理。普通桌面用户若不需要自行维护服务、权限和启动脚本，优先使用图形客户端更省步骤。内核包的处理器架构必须与设备一致，AMD64、ARM64、ARMv7 与 MIPS 不能互换。

Android 与 iOS：系统 VPN 接口优先

Android 和 iOS 上的 Clash 类客户端通常通过系统 VPN 接口接管流量。此时“系统代理开关”与桌面含义不同，是否覆盖应用还会受到分应用设置、系统 VPN 限制和本地网络权限影响。Android 可在 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard 之间选择；需要 mihomo 扩展协议时，应确认实际内核和导入结果。iOS 以 Clash Plus 为主要入口。移动端导入包含大量规则的桌面配置前，应评估内存和更新时间，必要时使用更精简的规则集。

更换客户端前应导出或备份当前配置，并记录手动修改的 DNS、TUN、策略组和规则。迁移后先在规则模式下验证基础网页、DNS 与单个节点，再恢复复杂设置。一次同时更换客户端、内核、订阅模板和协议，会让错误来源难以定位。较稳妥的迁移方式是每次只改变一层：先保持配置不变更换客户端，确认运行；再升级内核能力；最后导入新协议节点。

按使用场景形成协议与内核选型结论

日常桌面使用：先选成熟配置，再比较协议

Windows 或 macOS 上以网页、办公应用和常规下载为主时，优先选择 mihomo 客户端，并使用订阅中字段完整、连接稳定的协议。SS、Trojan、配置规范的 VMess 或 VLESS 都可以作为候选。若同一服务提供多种协议，先在相同线路下测试首次打开、数分钟持续传输和休眠恢复。差异不明显时，选择字段更少、更新后更少出错的一项。客户端方面首选 Clash Plus，也可按桌面管理需求选择 Clash Verge Rev 或 FlClash。

移动网络与频繁切换：关注恢复和后台状态

手机经常在 Wi-Fi 与蜂窝网络之间切换时，可将 Hysteria2 或 TUIC 纳入测试，因为 QUIC 类连接在网络变化和丢包条件下可能具备更好的恢复表现。但前提是当前网络稳定支持 UDP，客户端内核能够完整解析配置，服务端参数也正确。若出现锁屏后中断，应先处理系统后台限制；若出现空闲后首次访问缓慢，应查看连接保活和 DNS；若耗电增加，应减少健康检查与候选节点，而不是立即判定协议不可用。

高延迟或存在丢包的链路：同时看吞吐与公平性

在往返时间较高、带宽变化明显的网络中，Hysteria2 与 TUIC 的拥塞控制可能比普通 TCP 连接更快恢复吞吐。不过测试不能只看单任务是否跑满，还要观察其他应用是否明显受影响、路由器 CPU 是否持续升高以及网络空闲后是否频繁重连。带宽参数应接近可持续能力，不应以接入速率上限代替实际测量。若 UDP 路径不稳定，配置成熟的 Trojan、VLESS 或 SS 可能反而更可预测。

旧设备、路由器与小型服务器：减少变量

资源有限的设备应优先控制规则数量、日志级别、DNS 复杂度和并发连接。协议选择可从实现成熟、参数较少的 SS 或现有稳定 TCP 方案开始，再依据实际需求测试其他类型。运行 mihomo 内核时必须下载与处理器匹配的包，并使用最小配置确认服务能启动，然后逐步加入 DNS、规则提供者和 TUN。不要直接把桌面端的大型配置复制到低内存设备，因为界面不存在并不代表规则和连接状态没有资源成本。

已有订阅：尊重服务端实际提供的类型

用户不需要为了追求协议名称而自行改写节点。订阅提供 SS 就按 SS 参数使用，提供 VLESS 就核对其 TLS 与传输字段，提供 Hysteria2 或 TUIC 则确认 mihomo 支持和 UDP 环境。服务端未部署对应协议时，客户端侧修改类型无法建立匹配握手。若同一订阅包含多个协议，可建立手动选择组和单独测试组，保留一项已知稳定节点作为基线，再比较其他节点。

出现故障时按层排查

第一层检查配置是否载入：若出现 YAML 解析、未知类型或缺失字段错误，问题位于格式或内核兼容。第二层检查节点握手：若日志提示认证、TLS、timeout 或 UDP 错误，核对节点参数与网络条件。第三层检查系统接管：节点可连接但应用无法访问时，检查系统代理、TUN、VPN 权限和 DNS。第四层检查规则：只有部分域名异常时，确认规则顺序、策略组选择和 MATCH 去向。按层排查能避免把系统代理问题误判为协议问题，也能避免在节点参数错误时反复调整规则。

• 需要尽快完成首次使用

  前往快速上手，按导入订阅、选择模式、启用系统代理和验证连接的顺序操作。

• 需要选择安装包

  前往下载页，按 Windows、macOS、Android、iOS 或 Linux 选择客户端。

• 需要比较内核

  优先确认当前客户端实际运行的内核，再参考内核兼容性对比处理迁移。

• 需要优化策略组

  阅读url-test、fallback 与 load-balance 区别，避免探测行为与实际目标不匹配。

最终选择应以“配置能完整表达、客户端能稳定解析、当前网络可重复运行”为标准。协议名称代表设计方向，不代表脱离环境的固定等级。对于大多数用户，稳定的 mihomo 客户端、结构清楚的订阅、适量规则和可复现的测试流程，比追逐单次延迟或频繁更换协议更重要。保留已验证的配置作为基线，每次只调整一个变量，并记录日志中的具体错误，才能让后续升级和故障排查保持可控。