Clash 协议与内核技术参考

01 · SELECTION MODEL

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

协议名称不是完整连接方案

在 Clash 客户端的节点列表中，用户通常先看到 ss、vmess、trojan、vless、hysteria2 或 tuic。这些名称描述的是代理会话如何认证、封装和传输数据，但它们并不等于一套完整的网络条件。一个节点的实际表现，还取决于底层使用 TCP 还是 UDP、是否叠加 TLS、是否通过 WebSocket 或 gRPC 承载、服务器距离、链路丢包、拥塞控制、域名解析方式以及客户端内核实现。

例如，同为 VLESS，TCP 与基于 WebSocket 的连接会呈现不同的握手开销；同为 Shadowsocks，不同加密方法对旧设备的 CPU 压力也不同。Hysteria2 和 TUIC 都建立在 QUIC 体系上，但会话管理、认证字段和拥塞策略并不相同。只比较协议名而忽略传输字段，容易把服务器质量、网络路径和协议设计混在一起。

因此，选型应按三层读取。第一层是节点协议，决定认证与基本封装。第二层是传输和安全参数，例如 network、tls、servername、ALPN、拥塞控制与 UDP 中继。第三层是客户端能力，包括内核是否识别该字段、图形界面能否完整编辑、Android 后台是否稳定，以及订阅转换过程是否保留原始参数。三层同时满足，节点才能按预期建立连接。

速度结论需要绑定测试条件

协议没有脱离环境的固定速度排名。短距离、低丢包链路中，TCP 协议通常已经足够稳定，测速差距可能主要来自服务器负载。高往返时延或波动明显的移动网络中，QUIC 类协议可能更快恢复传输，但也可能因运营商网络对 UDP 的处理方式而失去优势。节点延迟只表示探测请求的往返时间，不直接等同于网页首开速度、文件吞吐或视频缓冲能力。

合理的比较方式是固定客户端、内核、服务器区域、测试时间和规则模式，再分别记录首连接耗时、持续吞吐、切换网络后的恢复时间与设备耗电。至少进行多轮测试，排除单次无线抖动。若订阅中多个协议来自不同服务器，则结果只能用于比较节点整体质量，不能据此判断协议本身。

从使用约束开始，而不是从协议热度开始

协议选择首先回答四个问题：客户端内核是否支持，订阅是否能完整下发，当前网络是否稳定提供 UDP，设备是否需要长期后台运行。桌面端可接受更高的内存占用，移动端则要额外考虑射频唤醒、重连频率和电池优化。路由器还受到 CPU 架构、内存容量与硬件加速能力限制。同一节点在电脑上表现稳定，不代表适合低功耗设备长期承载全家流量。

如果只需要可靠连接与广泛兼容，成熟的 SS、Trojan 往往更易部署和迁移。需要现代传输组合时，可在确认内核支持后选择 VLESS。高延迟或丢包链路可测试 Hysteria2、TUIC，但应同时保留一个 TCP 类型节点作为回退。VMess 常见于既有订阅，继续使用没有问题；新配置是否采用它，应根据服务端生态与客户端兼容范围判断，而不是只按名称新旧决定。

本页后续章节按协议族、性能维度、内核关系和场景决策展开。若当前问题是“已经连接但网页打不开”，应先按八步网络排查清单检查节点、DNS、规则与系统时间，而不是立即更换协议。连接故障和协议选型属于两个问题，拆开处理更容易得到稳定结论。

02 · SS / VMESS

Shadowsocks 与 VMess：成熟实现和状态化会话

Shadowsocks 的设计重点

Shadowsocks，配置中通常写作 ss，核心结构相对直接：客户端使用预共享密码派生密钥，对代理流量进行加密并转发到服务端。现代配置通常使用 AEAD 或更新的 2022 系列加密方法。它的协议头较轻，客户端实现广泛，TCP 与 UDP 转发路径都比较成熟，因此常被用作兼容性基线。

SS 的优势不是“任何环境都最快”，而是实现数量多、配置字段少、资源开销容易预测。对普通网页、软件更新、长连接和常规 UDP 应用，它通常能够提供稳定结果。低性能路由器上，加密方法会明显影响 CPU 使用率。具备硬件加速的 AES 平台可能适合 AES-GCM；部分移动处理器或不同架构设备使用 ChaCha20-Poly1305 时更平衡。不能只看算法名称判断快慢，应观察设备实际负载。

2022 系列方法改进了密钥和会话处理方式，但要求客户端与服务端同时支持。订阅若把新方法错误降级为旧字段，常见表现不是速度下降，而是直接认证失败。导入后应检查 cipher 和 password 是否完整，特别是密码是否符合服务端要求的密钥格式。图形界面只显示节点名称时，可导出配置或查看原始 Profile 确认。

VMess 的状态与时间条件

VMess 使用用户标识完成认证，并包含会话相关处理。Clash 配置里常见字段包括 uuid、alterId、cipher、传输网络和 TLS 设置。较新的服务端通常采用简化后的认证组合，但旧订阅仍可能保留历史字段。由于生态中的配置来源跨度较大，VMess 节点最需要检查的不是名称，而是字段组合是否与服务端一致。

VMess 对系统时间更敏感。Android 或桌面系统时间偏差较大时，可能出现节点看似存在、网络权限也正常，但握手持续失败的情况。此时重装客户端通常没有作用，应先开启系统自动时间与自动时区，再重新连接。企业网络、虚拟机快照或长期离线设备更容易出现时间偏差。

VMess 可以承载在 TCP、WebSocket、HTTP 或 gRPC 等传输之上。传输层增加了部署弹性，也增加了配置项数量。WebSocket 节点需要路径与 Host 对应；TLS 节点需要服务器名称与证书名称匹配；gRPC 节点需要服务名正确。任何一个字段在订阅转换中丢失，都可能导致连接失败。因此，VMess 的兼容性不能只按“内核支持 VMess”判断，还要确认该内核支持订阅使用的具体传输组合。

适用范围与边界

需要配置简单、跨客户端迁移方便时，SS 通常是稳妥选择。已有 VMess 订阅且运行稳定时，不需要仅因协议名称改变配置。对于频繁在多个客户端之间切换的用户，VMess 节点应优先保留原始订阅，避免经过多层转换。每次转换都会增加字段重命名、默认值变化或传输参数缺失的概率。

在 Android 上长期运行时，两者的基础耗电通常不是由协议标签决定，而是由实际流量、TLS 连接数量、UDP 活跃度、DNS 模式与延迟测试频率共同决定。若后台耗电突然增加，可参照Android 后台耗电与保活设置，先关闭高频自动测速并检查厂商电池策略是否反复终止 VPN 服务。

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

示例展示 mihomo 兼容的基本字段结构。域名、端口和密码需要替换为订阅提供的真实值。手动填写时保持 YAML 缩进一致，不要用制表符；若客户端由订阅管理，优先在原始配置源修正，而不是每次更新后重复修改本地副本。

03 · TROJAN / VLESS

Trojan 与 VLESS：TLS 会话和精简认证

Trojan 的连接结构

Trojan 通常以 TLS 作为连接基础，客户端通过密码完成认证。配置的关键字段包括服务器地址、端口、密码、SNI 对应的 servername、证书校验与 UDP 开关。它的字段数量不算多，但 TLS 名称必须准确。服务器地址可以是 IP，SNI 仍应填写证书对应域名；如果把 IP 同时当作服务器名称，证书校验通常无法通过。

Trojan 的常见优势是建立在成熟 TLS 栈上，桌面与移动系统的实现普遍稳定。其性能主要受 TLS 握手、连接复用、服务器配置和链路质量影响。已建立的长连接不会在每次传输时重复完成完整握手，因此持续吞吐通常平稳。大量短连接场景下，连接复用和 DNS 结果更值得关注，单看加密开销没有足够解释力。

客户端中存在“跳过证书验证”一类选项，但它不应作为长期修复方法。证书错误通常说明系统时间、SNI、域名或服务端证书配置不一致。临时关闭校验会掩盖根因，也会改变原有安全边界。正确顺序是确认自动时间、核对 servername、检查订阅是否保留该字段，再由服务端维护者检查证书链。

VLESS 的职责边界

VLESS 将认证与传输安全分开处理，本身不提供传统意义上的内置加密层，通常依赖 TLS 或其他受支持的安全传输。它使用 UUID 类标识认证，协议头相对精简，可与 TCP、WebSocket、gRPC 等传输组合。部分配置还包含流控或 Reality 相关字段，这些能力是否可用，取决于服务端实现和客户端内核。

“支持 VLESS”只表示内核认识基础协议，不代表支持所有扩展。旧版原版 Clash 对 VLESS 及其后续扩展的支持范围有限；mihomo 作为 Meta 分支延续，覆盖的字段更完整。使用 Clash Plus、Clash Verge Rev、FlClash 等客户端时，还需确认其实际嵌入的内核与配置入口。图形界面可能只开放常用字段，但订阅导入仍能保留更多参数；也可能在内部转换时丢弃界面不认识的值。

VLESS 配置的排查顺序应从基础层开始。先检查地址、端口与 UUID，再检查 TLS、服务器名称和传输类型，最后检查路径、服务名、流控或 Reality 参数。不要一次修改多个字段，否则连接恢复后无法判断真正原因。订阅更新覆盖本地修改也是常见现象，验证完成后应把修正写回订阅源或客户端的持久覆写层。

两者如何选择

Trojan 更适合需要字段相对集中、TLS 配置清晰和多客户端迁移方便的场景。VLESS 更适合服务端已经采用相应生态，并且客户端明确使用 mihomo 等兼容内核的场景。两者都不能绕过服务器线路质量。若 Trojan 与 VLESS 位于不同服务器，测速结果无法用于证明某个协议更高效；只有同机、同线路、同时间窗口的对照才有参考意义。

移动端使用时，持续 TLS 会话通常不会造成异常耗电。真正影响电量的是连接是否频繁断开、系统是否反复拉起 VPN 服务、应用是否持续执行 URL 测试，以及 QUIC、语音或游戏等 UDP 流量是否长期活跃。一个配置正确且连接稳定的 Trojan 节点，可能比不断重连的轻量协议更省电。稳定性本身就是功耗因素。

proxies:
  - name: vless-tls
    type: vless
    server: proxy.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    network: ws
    tls: true
    servername: edge.example.com
    ws-opts:
      path: /proxy
      headers:
        Host: edge.example.com

该片段说明字段层级，不代表任何可连接节点。WebSocket 路径区分大小写，Host 与 SNI 可能相同，也可能由服务端分别指定。导入失败时应对照订阅原文，而不是根据其他节点复制字段。不同服务端的路径与认证信息不能混用。

04 · QUIC TRANSPORT

Hysteria2 与 TUIC：面向波动链路的 QUIC 协议

QUIC 改变了哪些连接行为

Hysteria2 与 TUIC 都使用基于 UDP 的 QUIC 传输。QUIC 将加密握手、可靠传输与多路复用结合在用户态实现，避免传统 TCP 多连接之间完全独立的队头阻塞。在往返时延较高、丢包呈波动状态的链路中，合理配置的 QUIC 会话可能更快恢复吞吐。网络从 Wi-Fi 切换到移动数据时，部分实现还可以通过连接迁移降低重新建立会话的成本。

这些特点不等于任何 UDP 环境都更快。如果接入网络限制 UDP 会话时长、路由设备对大流量 UDP 处理较弱，或者 NAT 映射频繁变化，QUIC 节点可能出现可连接但吞吐不稳、待机后恢复缓慢、语音正常但网页偶发超时等现象。此时应先确认 UDP 基础可用性，再调整协议参数。直接增加带宽声明通常不能修复网络路径问题。

Hysteria2 的带宽与拥塞配置

Hysteria2 简化了早期配置结构，常见字段包含服务器、端口、密码、SNI、证书校验和上下载带宽提示。带宽值不是客户端凭空获得的加速额度，而是拥塞控制用于估计发送节奏的输入。填写明显高于真实接入能力的数值，可能导致突发丢包和重传；填写过低则会限制吞吐。没有明确要求时，应优先采用订阅提供值或内核默认策略。

Hysteria2 对 UDP 路径质量敏感。测试时除了延迟，还应观察持续下载是否周期性降速、切换网络后是否恢复、待机唤醒后首个请求是否超时。Android 厂商电池策略若冻结客户端，QUIC 保活可能中断；恢复前台后重新连接属于系统后台限制，不一定是协议故障。应先把客户端加入合适的后台运行策略，再比较协议。

证书相关处理与其他 TLS 协议相同。SNI 必须对应服务端证书；系统时间需要准确；跳过校验不应作为日常配置。若订阅提供混淆密码或端口跳跃等扩展字段，必须确认 mihomo 内核和当前客户端版本所使用的字段名称一致。配置转换器可能识别基础 Hysteria2，却忽略扩展项。

TUIC 的会话与并发特点

TUIC 同样建立在 QUIC 上，常见认证由 UUID 与密码组成，并提供拥塞控制、UDP 中继模式、SNI 和 ALPN 等参数。其设计重视并发流与低延迟数据传输。对网页多请求、实时通信和同时存在 TCP、UDP 流量的场景，稳定链路下可以保持较好的响应。但服务端与客户端必须在协议版本和字段定义上匹配，旧格式配置不能只修改 type 后继续使用。

TUIC 的拥塞控制选项应依据服务端建议与链路特点选择。盲目复制他人的参数，可能在不同带宽、不同队列管理条件下得到相反结果。UDP 中继模式也会影响兼容范围；某些模式强调原生 UDP 行为，某些模式更适合通过 QUIC 流转发。若游戏、语音或 DNS 出现单独故障，应核对中继模式，而不是只看节点整体是否“连接成功”。

Hysteria2 和 TUIC 适合加入策略组作为特定链路的候选项，而不必替换所有 TCP 节点。可以建立一个手动选择组，保留一个成熟 TCP 节点和一个 QUIC 节点，在固定网站、固定文件和固定时间窗口下比较。这样既能利用波动链路下的恢复能力，也能在 UDP 条件变化时快速切换。

05 · PERFORMANCE / POWER

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

把“快”拆成四项指标

用户感知的速度至少包含连接建立时间、首字节时间、持续吞吐和故障恢复时间。网页打开慢可能是 DNS、TLS 或首连接延迟；大文件慢更接近持续吞吐问题；地铁或移动热点切换后长时间无响应，则属于连接恢复。不同协议优化的环节不同，用单次延迟测试无法覆盖全部指标。

SS 的基础封装较轻，低丢包环境中建立和传输都较直接。Trojan 与启用 TLS 的 VMess、VLESS 会增加握手过程，但长连接建立后，持续传输差异通常缩小。Hysteria2 与 TUIC 在高时延、波动或随机丢包链路上可能更快恢复，但前提是 UDP 路径稳定。协议速度不是固定属性，而是协议机制与当前链路相互作用的结果。

客户端延迟测试也有测量边界。URL-Test 通常向指定地址发起 HTTP 请求，结果包含 DNS、连接与服务端响应。不同节点同时测试会在短时间内创建大量连接，导致移动设备射频活跃和 CPU 唤醒。测速间隔设置过短时，用户看到的是频繁变化的数字，代价是后台耗电和额外流量。日常使用不需要持续刷新秒级延迟。

CPU、内存和连接数量

CPU 消耗主要来自加密、TLS、数据复制、规则匹配、DNS 处理和 TUN 协议栈。桌面处理器通常不会因单个普通连接产生明显压力，但高速下载、数百并发连接或低性能路由器会放大差异。SS 加密方法应结合硬件能力选择；TLS 类协议会使用系统或内核加密库；QUIC 在用户态维护丢包恢复与拥塞控制，可能比简单 TCP 代理占用更多计算资源。

内存占用不能只看协议。规则集规模、Geo 数据、Fake-IP 映射、连接追踪和日志等级都会增加常驻内存。相同节点在规则模式与全局模式下，资源差异可能来自规则匹配而非协议。排查时先固定配置，只替换一个节点，再观察稳定运行一段时间后的 CPU 与内存，避免把启动时加载规则的峰值当作长期状态。

连接复用可以减少握手，但过多长连接也会增加状态维护。浏览器、即时通信和系统同步服务可能同时保持连接。TUN 模式接管的应用范围更大，因此连接数通常高于仅使用系统代理。若切换 TUN 后耗电上升，应检查哪些应用被纳入代理、DNS 是否形成循环，以及后台同步应用是否持续重试。

Android 电量由唤醒模式决定

Android 上的 Clash 客户端通过 VpnService 建立本地 VPN 接口。只要 VPN 图标存在，系统就会把匹配流量交给客户端，但常驻服务本身不等于持续高负载。真正影响电量的是每秒处理的数据量、网络射频保持活跃的时间、定时测速、日志写入、连接重建和厂商后台策略。

频繁终止再拉起通常比稳定常驻更耗电。客户端被电池优化冻结后，系统应用仍可能产生请求；恢复时会集中重连，表现为短时 CPU 峰值与流量突发。需要长期使用时，应允许客户端维持必要的后台运行，同时降低自动测速频率，关闭排错结束后的详细日志，并避免多个 VPN 或网络过滤应用同时接管。

QUIC 协议可能保持 UDP 映射与保活，在移动网络下的耗电取决于实现和网络超时策略。若待机耗电异常，可分别测试一个 TCP 节点和一个 QUIC 节点，每轮保持相同规则、DNS 和应用使用方式。只切换协议组，不改其他设置。记录屏幕关闭后的电量变化、客户端重连次数与系统网络状态，才能判断差异来源。

如果客户端显示已连接，但应用完全没有流量，应先排除 DNS、规则和系统代理问题。浏览器与终端的代理读取路径并不相同，相关验证方法见系统代理不生效的两条排查路径。只有确认流量确实到达内核后，协议性能比较才有意义。

06 · KERNEL FAMILY

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

原版 Clash 的配置基础

原版 Clash 建立了广泛使用的 YAML 配置结构，包括 proxies、proxy-groups、rules、DNS、监听端口与运行模式。大量订阅和客户端界面仍以这套结构为基础。其核心价值在于统一节点、策略组和规则分流的表达方式，使不同协议可以进入同一选择与自动测试体系。

原版项目停止维护后，现有客户端仍可能继续使用其历史内核，但新协议、DNS 行为和平台适配不会自动获得后续改进。因此，“Clash 配置”与“原版 Clash 内核”需要分开理解。前者已成为生态中的通用配置称呼，后者指特定实现。一个文件采用 Clash YAML，不表示只能由原版内核读取。

Clash.Meta 到 mihomo

Clash.Meta 在原有配置模型上扩展协议、TUN、DNS、规则提供器和平台能力，随后以内核名 mihomo 持续发展。实际使用中，用户仍会看到 Meta 配置、Meta 节点或 Clash Meta for Android 等名称；这些名称反映项目演进与客户端品牌，不代表存在三套完全独立的配置语法。

mihomo 对原版 Clash 配置保持较高兼容，同时加入 VLESS、Hysteria2、TUIC、Reality 相关参数、更多 DNS 与 TUN 选项。兼容方向主要是“新内核读取旧配置”。反向并不成立：包含新协议和扩展字段的 mihomo 配置，无法直接交给原版内核完整运行。旧内核可能报告未知代理类型，也可能忽略不认识的全局字段，形成部分功能可用、部分行为偏离预期的状态。

配置兼容还受到字段默认值影响。新内核可能修正历史行为、增加严格校验，或改变某些边界条件。迁移后即使文件通过语法检查，也要验证 DNS、规则命中、UDP、局域网监听和 TUN 接管。语法通过只说明结构可解析，不说明运行结果完全相同。

客户端名称不等于固定内核能力

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android 等是图形客户端或应用名称；mihomo 是其中常见的代理内核。客户端负责安装、权限、配置管理、托盘或移动界面，内核负责协议连接、DNS、规则和流量处理。两层更新节奏可能不同，因此不能只看客户端名称推断全部协议能力。

本站下载页按平台列出当前可选客户端，并将 Clash Plus 作为全平台优先选择。需要 VLESS、Hysteria2、TUIC 等现代协议时，应选用明确采用 mihomo 或兼容实现的客户端。Clash for Windows 与 ClashX Meta 标记为停止维护，适合处理既有环境或归档需求，不应作为验证新协议字段的首选。

Android 还要区分应用版本、内核架构和安装包架构。ARM64 设备通常使用对应架构包，通用包则用于兼容更多设备。安装成功不代表订阅中的所有协议可用；内核加载 Profile 时仍会校验代理类型与字段。遇到“部分节点消失”时，应查看配置加载日志，确认是订阅未下发、客户端过滤，还是内核拒绝了未知字段。

迁移时先执行静态检查

mihomo 提供配置检查入口。具备命令行环境时，可以在启动前验证 YAML 是否可解析。该检查会发现缩进、未知类型和部分字段错误，但不会测试节点密码、服务器证书或实际网络路径。

mihomo -t -f ./config.yaml

检查通过后，再按“DNS 解析—单节点连接—规则命中—UDP—TUN”顺序验证。不要先开启全部覆写、脚本和复杂规则，否则出错时很难定位层级。想理解 Profile 各区域的职责，可继续阅读配置文件结构与多配置管理。

07 · PROFILE COMPATIBILITY

订阅格式、字段转换与配置兼容边界

链接订阅与 YAML Profile

Clash 客户端常见的导入来源有两类。第一类是完整 YAML Profile，直接包含节点、策略组、规则和 DNS 设置。第二类是 URI 或聚合订阅，服务端返回节点链接，再由客户端或转换服务生成 Clash 配置。前者结构完整，适合保留规则与高级字段；后者便于跨应用分发，但转换过程可能丢失特定协议扩展。

单节点 URI 的表达能力受协议格式限制。SS、Trojan、VMess、VLESS、Hysteria2 和 TUIC 各有自己的链接字段，客户端解析器也可能采用不同容错规则。链接中的域名、路径、SNI 和节点名称需要 URL 编码；若服务端输出不规范，某个客户端可能接受，另一个客户端则拒绝。此类差异不是节点本身失效，而是解析阶段不一致。

完整 YAML 更适合检查问题。节点字段可以逐项读取，策略组引用关系也清晰。订阅更新时，客户端通常用远程内容替换缓存 Profile；直接编辑生成文件可能在下一次更新后消失。需要长期修改时，应使用客户端提供的覆写、合并或脚本入口，并确认覆写执行顺序。

转换器最容易丢失的字段

基础字段如服务器、端口和认证信息通常能够保留，容易缺失的是传输扩展。VMess 与 VLESS 的 WebSocket Host、路径、gRPC 服务名、流控参数，Trojan 的 SNI，Hysteria2 的混淆和带宽提示，TUIC 的拥塞控制与 UDP 中继模式，都需要转换器显式理解。转换器只识别协议基础结构时，节点仍会出现在列表中，但建立连接时失败。

另一类问题是字段名称变化。某些订阅使用上游项目的原始命名，Clash 配置要求另一套键名；部分客户端会自动映射，部分直接保留未知字段。排查时应获取转换前的原始节点信息，与导入后的 YAML 对照。只在图形界面中查看节点名称无法确认字段是否完整。

策略组也会在转换中改变实际体验。节点虽然全部导入，但可能没有加入当前选中的组；规则最终指向另一个策略；自动测试组可能因测试 URL 不可达而把可用节点标为失败。判断协议之前，应在手动选择组中直接选定单个节点，排除策略组自动切换。

最小可验证配置

当完整订阅无法加载时，可以建立最小配置，只保留监听、一个节点、一个手动策略组和最终规则。这样能区分节点字段错误与大型规则、DNS、Provider 的问题。最小配置验证成功后，再逐层加入 DNS、规则提供器和 TUN。每次只增加一类功能，并保留上一份可工作的文件。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: test-node
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: edge.example.com
    udp: true

proxy-groups:
  - name: MANUAL
    type: select
    proxies:
      - test-node
      - DIRECT

rules:
  - MATCH,MANUAL

该配置结构可用于 mihomo 的基础验证，示例地址和认证值需要替换。测试期间使用 log-level: info 即可；需要定位握手字段时可短暂提高日志详细度，完成后恢复，避免长期写入大量记录。若客户端自行管理端口，应遵循客户端生成的基础模板，不要与界面设置重复声明。

兼容性检查清单

多配置共存时，应给 Profile 使用明确名称，并记录其内核要求，例如“基础兼容”“mihomo 扩展”“移动端低功耗”。名称用于说明配置目的，不要只用日期区分。客户端切换 Profile 后还要确认当前策略组选择，因为部分应用会为每个 Profile 分别保存状态，另一些则沿用同名策略组的上次选择。

08 · DECISION GUIDE

按使用场景选择协议并保留回退路径

日常网页与多设备迁移

主要需求是网页、软件更新和常规应用，并且需要在 Windows、macOS、Android 与 Linux 之间迁移时，应优先选择字段较少、客户端覆盖广的协议。SS 和 Trojan 通常适合作为基础节点。SS 需要确认加密方法得到所有设备支持；Trojan 需要确认 SNI 与证书。两者都建议开启服务端实际支持的 UDP 转发，以免 DNS、语音或部分应用单独失败。

客户端方面，Clash Plus 作为本站全平台首选，适合需要统一界面和配置入口的用户。Clash Verge Rev、FlClash 等可作为桌面替代，Clash Meta for Android 与 Surfboard 可覆盖不同 Android 使用习惯。选择客户端时先看平台与内核，再看界面功能，不要因为两个应用都带有 Clash 名称就假设配置能力完全相同。

高时延、波动网络与实时流量

网络往返时间较高、移动过程中丢包波动明显时，可以测试 Hysteria2 或 TUIC。测试前确认 UDP 可达，并保留一个 TCP 节点。固定同一应用和同一测试内容，观察连接恢复、首开和持续传输，不要只比较延迟数字。若 QUIC 节点在 Wi-Fi 稳定而移动数据频繁中断，优先保留双协议策略组，根据网络环境手动切换。

游戏、语音和视频会议更关注抖动、丢包恢复与 UDP 中继。节点能打开网页并不能证明实时流量正常。TUIC 需要核对 UDP 中继模式，Hysteria2 需要核对 UDP 与拥塞参数，SS、Trojan、VLESS 则需要确认客户端和服务端均启用 UDP。测试时应观察实际应用，不用网页测速替代实时场景。

低功耗设备与路由器

低性能路由器应优先控制规则集、日志和并发连接，再比较协议。轻量 SS 配合适合硬件的加密方法通常容易预测资源占用；Trojan 和 VLESS TLS 需要考虑握手与加密库；Hysteria2、TUIC 的用户态 QUIC 会增加 CPU 与内存压力。高吞吐目标下，路由器 CPU 可能先达到上限，表现为速度无法继续提升。

Android 长期后台运行时，优先选择连接稳定的节点，而不是理论封装最轻的节点。一个频繁断开并重新握手的节点会造成更多唤醒。建议把测速周期设为分钟级或按需执行，保持日志为常规等级，确认系统没有反复终止 VPN 服务。若只在特定应用使用代理，可以利用应用分流减少不必要的后台连接。

旧订阅与新内核迁移

已有 VMess、SS 或 Trojan 订阅运行正常时，迁移到 mihomo 不需要先更换协议。第一步只替换内核或客户端，保持 Profile 内容不变；第二步验证 DNS、规则、UDP 和 TUN；第三步再加入 VLESS、Hysteria2、TUIC 等新节点。分阶段迁移可以把内核差异与协议差异分开。

从 mihomo 回退到旧内核时，需要删除或替换旧内核无法识别的节点和字段。仅仅把文件名改回去没有作用。策略组如果引用了被删除节点，也会加载失败。回退配置应作为独立 Profile 保存，并使用基础协议和通用字段。这样在新配置出现问题时，可以快速恢复，而不是临时修改复杂主配置。

一个可执行的决策顺序

1. 确认客户端。检查操作系统、CPU 架构和实际内核。需要现代协议时优先选择采用 mihomo 的客户端。
2. 确认订阅。查看节点类型和扩展字段是否完整，避免经过不支持目标协议的转换器。
3. 建立基础节点。先用 SS、Trojan 或已有稳定节点验证 DNS、规则、系统代理与 TUN。
4. 加入候选协议。在同一手动策略组中加入 VLESS、Hysteria2 或 TUIC，每次只测试一个变量。
5. 按场景测试。分别观察网页首开、持续下载、实时 UDP、网络切换和待机恢复。
6. 保存回退配置。保留上一份可工作的 Profile，不让订阅更新覆盖唯一可用配置。

协议选型的最终目标不是获得一个固定排名，而是建立可解释、可回退的连接组合。稳定节点负责日常基线，现代协议负责特定网络条件，手动策略组负责快速切换，独立 Profile 负责变更隔离。出现故障时，从订阅、解析、策略、连接、DNS 和系统接管逐层判断，避免把所有问题归因于协议。

完成选择后，可前往安装包页面确认对应平台客户端，或按使用指南完成导入和首次连接。若 Profile 更新后出现结构变化，继续参考Profile 结构拆解；若连接成功却不能访问网络，则回到已连接但无法上网排查清单逐项验证。