Clash 协议与内核技术参考

一、先建立协议选型框架

协议、传输与客户端是三个层级

Clash 配置里的一个代理节点通常包含三层信息。第一层是协议本身，例如 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 TUIC，它规定双方如何认证、封装数据以及维护会话。第二层是承载协议的传输方式，例如普通 TCP、WebSocket、gRPC、HTTP/2、QUIC 或基于 UDP 的定制传输。第三层才是执行配置的客户端与内核。图形客户端负责订阅管理、策略组、系统代理和界面操作，mihomo 等内核负责真正解析节点并转发连接。

这三层不能混为一个结论。VMess 配合 TCP 与 VMess 配合 WebSocket，在握手次数、包头开销和连接复用方面并不相同；VLESS 本身很轻，但叠加 TLS、REALITY、gRPC 后，实际连接过程仍会包含对应传输层的计算与往返。客户端名称也不能证明它支持某个协议的全部扩展。判断兼容性时，应查看内核类型、节点字段和传输组合，而不是只看界面里是否出现相似名称。

先确定约束，再比较协议

实用的选型顺序是：先确定服务端已经提供哪些协议，再确认当前客户端内核能否完整解析，随后考虑网络特征和设备限制，最后才比较速度。用户通常无法只在本地把一个现有节点改成另一种协议，因为协议、端口、认证信息和服务端配置必须对应。订阅只提供 SS 节点时，客户端无法通过修改 type 字段把它转换成 Hysteria2；这种改动只会造成握手失败。

网络约束至少包含四项：UDP 是否稳定、往返时延是否高、丢包是否明显、连接是否频繁在 Wi-Fi 与蜂窝网络之间切换。设备约束则包括处理器性能、后台运行限制、电池容量和是否长期保持大量并发。桌面端持续供电，更适合优先追求吞吐和连接恢复；移动端需要同时衡量唤醒次数、持续发包、无线模块活跃时间和后台保活成本。

六个判断维度

本文统一使用六个维度比较协议：握手成本决定首次建立连接需要多少次往返；传输效率关注有效载荷占比和复用方式；弱网恢复关注丢包与抖动下的退化程度；资源占用包括加密、拥塞控制和会话维护带来的 CPU 与内存成本；移动端表现重点观察无线模块是否被频繁唤醒；生态兼容则考察订阅格式、内核和服务端支持范围。任何协议都可能在一个维度占优、另一个维度付出成本。

因此，协议选择的目标不是找出全局最强项，而是避免明显不匹配。例如 UDP 质量长期不稳定时，优先选择成熟的 TCP 组合通常比反复调节 QUIC 参数更有效；高时延且存在随机丢包时，Hysteria2 或 TUIC 可能获得更平滑的吞吐；老旧设备只承担网页与消息流量时，结构简单、实现成熟的 SS 往往更省资源。先把需求写成约束，结论会比协议排行榜可靠。

二、SS、VMess、Trojan 与 VLESS 的设计差异

Shadowsocks：简单结构与广泛实现

Shadowsocks 通常缩写为 SS。它的核心思路是使用预共享密钥保护代理数据，并以较精简的结构转发 TCP 与 UDP 流量。早期实现曾提供多种传统加密方式，现代配置更常见 AEAD 加密，例如 aes-128-gcm、aes-256-gcm 与 chacha20-ietf-poly1305。AEAD 同时提供加密和完整性保护，客户端与服务端必须使用完全一致的方法和密码。

SS 的优势来自实现成熟、节点字段少、客户端覆盖广。对于普通网页、软件更新、即时通信和多数桌面场景，它通常能以较低的配置复杂度提供稳定表现。AES 在带硬件加速的桌面处理器上效率很好；ChaCha20 在部分移动设备或低功耗处理器上可能更合适，但不能仅凭算法名称断定结果，具体实现与设备指令集同样重要。

SS 的限制也与简单结构相关。它不是一套包含复杂传输编排的通用协议框架，扩展能力更多依赖具体实现、插件或服务端能力。订阅中若包含插件参数，mihomo 必须识别对应插件类型与字段；只复制服务器、端口和密码可能遗漏关键传输信息。遇到能导入但无法连接的 SS 节点，应先核对加密方式、插件选项和 UDP 开关，而不是反复切换系统代理。

VMess：带会话信息的完整协议

VMess 来自 V2Ray 生态，以 UUID 等身份信息完成认证，并可与 TCP、WebSocket、HTTP/2 等传输组合。它比 SS 承担更多协议层工作，配置字段也更丰富。历史配置中还能看到 alterId 等字段，但现代服务端通常采用不同的推荐值；导入旧订阅时，字段虽然可能被内核接受，服务端实际配置却未必仍然匹配。

VMess 的价值在于生态成熟、传输组合多、旧有订阅覆盖面广。其代价是配置链条较长：协议认证、传输类型、TLS、服务器名称、路径和请求头可能共同决定连接结果。任意一处与服务端不一致，都可能表现为超时或握手关闭。排查时应从订阅原始字段出发，不宜凭经验删除看似多余的参数。

从性能看，VMess 并非天然缓慢，但额外封装、传输层和加密会产生一定成本。若多个节点实际线路相同，普通 TCP 组合通常比叠加 WebSocket 与 TLS 的组合拥有更少的握手和帧开销；不过在真实使用中，线路拥塞往往比这部分差异更显著。只有在控制变量后，协议层比较才有意义。

Trojan：以 TLS 连接为基础

Trojan 通常建立在 TLS 之上，使用密码完成认证，并把数据承载在受 TLS 保护的连接中。其配置关键包括服务器地址、端口、密码、服务器名称和证书验证行为。客户端中的 sni 或 servername 必须与服务端证书及部署方式对应。随意关闭证书验证可能暂时绕过错误，但会改变安全边界，不应成为常规排错手段。

Trojan 的优势是标准 TLS 组件成熟，部署与证书体系清晰，很多内核都能稳定处理。建立新连接时需要完成 TCP 与 TLS 握手，高时延环境中的首包时间可能因此增加；连接复用和会话恢复可以减少部分成本，但具体效果取决于客户端与服务端实现。网页访问以大量短连接为主时，应同时观察首包时间；持续传输时，线路质量通常更重要。

Trojan 订阅常见问题集中在 SNI、证书域名、传输层和端口不一致。若节点在一个客户端可用、另一个客户端失败，先比较两边导出的完整节点字段，特别是网络类型、ALPN、SNI 与证书验证选项。只核对密码不足以确认配置等价。

VLESS：精简认证与可组合扩展

VLESS 采用较轻的协议层设计，本身不负责像 VMess 那样的内建加密，通常依靠 TLS、REALITY 或其他安全传输提供保护。它以 UUID 等信息认证，可与 TCP、WebSocket、gRPC 等承载方式组合。VLESS 的配置可读性较高，但这不意味着节点字段更少：流控、传输、安全层、服务器名称、公钥、短标识和路径等参数仍必须与服务端一致。

VLESS 常见于较新的服务端方案，也能通过组合不同传输适配多种部署需求。其协议层开销较轻，但最终性能由整个组合决定。VLESS 加普通 TCP、VLESS 加 gRPC、VLESS 加 WebSocket 是三种不同的数据路径，不能把它们视为同一个性能结论。REALITY 相关字段还依赖内核支持，旧版原版 Clash 通常无法完整解析，mihomo 的适配范围更广。

选择 VLESS 时，重点不是“新”这一属性，而是订阅与内核是否提供完整字段、服务端组合是否稳定、当前网络是否适合对应传输。若现有 VMess 或 Trojan 节点长期稳定，没有必要只因协议名称变化而迁移。协议更换应解决明确问题，例如降低配置复杂度、使用内核支持的新传输，或改善特定网络下的连接恢复。

三、Hysteria2 与 TUIC：面向高时延和丢包的 UDP 方案

为什么使用 QUIC 或定制拥塞控制

传统 TCP 按连接维护可靠有序的数据流。发生丢包时，重传和拥塞窗口调整可能让后续数据等待，多个逻辑请求若共享同一条 TCP 路径，还可能相互影响。QUIC 在 UDP 之上实现可靠传输、加密和多路流，把更多传输控制放在用户态。Hysteria2 与 TUIC 都利用这一方向改善高时延、随机丢包或带宽变化明显场景中的连接表现，但两者不是简单的“UDP 加速开关”。

UDP 方案能否发挥作用，首先取决于端到端 UDP 质量。若本地网络、路由设备或服务端入口对 UDP 存在严格限速、映射时间短或持续丢包，协议再先进也无法补偿基础路径问题。常见症状包括刚连接时正常、数十秒后吞吐骤降，或测速可用但长连接频繁重建。此时应先与同线路的 TCP 节点对比，确认问题来自协议、线路还是本地网络。

Hysteria2 的带宽利用思路

Hysteria2 使用基于 QUIC 的传输，并针对高时延与丢包环境强调吞吐利用。配置通常包含服务器、端口、认证信息、TLS 服务器名称以及证书验证设置。部分服务端还会提供混淆相关参数。客户端下载订阅后应保留这些字段，不要把认证字符串误当作 SS 密码，也不要把普通 HTTPS 地址直接填入 Hysteria2 节点。

Hysteria2 在长距离、高带宽延迟积和随机丢包环境中可能比保守的 TCP 拥塞控制更积极。积极发送有助于维持吞吐，但也意味着网络条件较差时可能产生更多重传、CPU 工作和无线模块活跃时间。它适合持续下载、视频传输或远程大文件访问，不代表所有短连接网页都会更快。短请求的体验还受到 DNS、QUIC 建连、证书验证和应用自身连接复用影响。

配置中的带宽相关参数应反映真实可用能力，而不是填写越大越好。过高估计可能造成突发发送、排队和额外丢包；过低估计则限制吞吐。服务提供方已经通过订阅给出参数时，优先保留原值。需要手动调整时，应在稳定网络下测量多次，使用略低于持续可用吞吐的值，再观察延迟是否因排队明显升高。

TUIC 的连接迁移与多路流

TUIC 同样建立在 QUIC 体系上，常见配置包含 UUID、密码、服务器名称、拥塞控制器和 UDP 中继模式。其设计关注低延迟、多路复用和连接状态管理。QUIC 使用连接标识而非只依赖传统四元组，在实现与网络条件允许时，设备从 Wi-Fi 切换到蜂窝网络后可能更容易恢复会话。不过“支持迁移”不等于切换过程一定没有中断，移动系统的后台策略、地址变化和中间设备映射都会影响结果。

TUIC 的拥塞控制选项会改变吞吐与延迟取舍。较积极的算法可能在带宽充足时快速提升发送速率，也可能在共享网络上增加排队；较保守的策略通常更平稳，但高时延线路爬升速度较慢。客户端应遵循订阅或服务端建议，不宜只依据算法名称修改。客户端和服务端对 TUIC 代际及字段解释不一致时，最常见表现是认证后立即断开或 UDP 转发不可用。

Hysteria2 与 TUIC 的选择通常由服务端支持决定。如果两者位于相同线路，可以用三个任务比较：连续访问一组短网页，观察首包与失败重试；保持十分钟以上持续传输，观察吞吐波动；在移动设备上切换一次网络，观察恢复时间和电量变化。结论应基于任务而不是单一测速数值。

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

把速度拆成首包、吞吐和稳定性

“速度快”至少包含三种不同指标。首包时间是从应用发起连接到收到首段有效数据的时间，受 DNS、协议握手、TLS 或 QUIC 建连和服务端处理影响；持续吞吐描述大文件或视频在稳定阶段的传输能力；稳定性则关注一分钟到数小时内是否出现断流、重连和明显抖动。协议可能在持续吞吐上占优，却因为首次建连较复杂而不改善短网页体验。

比较时应保持服务端位置、线路、设备、时间段和客户端内核一致。两个名称不同但线路也不同的节点，测试结果主要反映线路差异。建议分别使用网页加载、持续文件传输和实时语音三类任务，每类执行多次，并记录中位体验而不是最高峰值。Clash 的策略组延迟测试适合筛除明显不可用节点，不适合作为完整吞吐基准。自动策略组的差异可进一步阅读url-test、fallback 与 load-balance 选型说明。

CPU、内存与并发连接

协议资源占用来自加密运算、数据复制、拥塞控制、连接复用、日志和规则匹配。SS 的协议结构较简洁，通常具有较低的常驻开销；AES 与 ChaCha20 的实际成本取决于硬件加速。VMess 与多层传输需要处理更多封装。Trojan 借助成熟 TLS 库，但大量短连接会重复承担握手。VLESS 本身较轻，若叠加 gRPC、TLS 或复杂流控，最终开销仍取决于整个组合。

Hysteria2 与 TUIC 的 QUIC 处理位于用户态，需要维护丢包检测、拥塞窗口和多个逻辑流。在高速传输或弱网重传较多时，CPU 占用可能高于简单 TCP 协议。现代桌面设备通常能够承担，但低功耗路由器、旧手机或小型服务器需要关注持续负载。内存方面，节点数量、规则集、GeoIP 数据、连接面板记录和 DNS 缓存往往比单个协议对象更显著，不能看到客户端占用增加就直接归因于协议。

诊断资源问题时，先固定同一份规则和 DNS 配置，只更换一个节点协议；关闭连接详情页的持续刷新，并将日志级别保持在常规水平。分别观察空闲、普通浏览和持续传输三种状态。如果空闲时资源仍高，原因更可能是图形界面、规则更新、DNS 循环或系统代理冲突；如果只在高速传输时升高，则更接近加密和传输处理成本。

移动端电量不是协议名称的单变量

移动设备的主要能耗通常来自屏幕、无线基带、CPU 唤醒和后台保活。代理协议会通过发包频率、重传数量、连接保持和加密计算间接影响电量。持续发送小包会让无线模块更长时间保持活跃；弱网下大量重传会同时增加网络与 CPU 成本；过短的连接保活可能频繁唤醒系统，过长的保活又可能维持不必要的会话。

日常轻量浏览中，成熟的 SS、Trojan 或 VLESS TCP 组合通常容易获得可预测的功耗。Hysteria2 与 TUIC 在移动网络质量好、持续传输明显时可能用更短时间完成任务，从而抵消部分瞬时负载；但在 UDP 丢包严重的网络中，重传和连接维护可能增加耗电。是否省电必须以完成同一任务的总耗时和总电量判断，不能只比较某一刻 CPU 百分比。

Android 与 iOS 还会限制后台网络活动。客户端被系统暂停、VPN 服务被节能策略回收或网络切换后未及时重建，都可能表现为协议断线。Android 用户应确认客户端的 VPN 权限和后台运行策略；iOS 用户应使用系统允许的客户端与网络扩展方式。需要选择对应软件时，可在Android 下载区或iOS 下载区查看 Clash Plus 等客户端。

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

原版 Clash 的定位

原版 Clash 建立了配置文件、规则分流、策略组、DNS 和多平台代理入口等基础模型。大量现有配置仍沿用它形成的字段和结构，例如 proxies、proxy-groups、rules、mixed-port 与 mode。理解这些基础结构仍然有价值，因为 Meta 系列和 mihomo 保留了广泛兼容性。

但原版项目停止继续扩展后，较新的协议和传输并不在其完整支持范围内。含 VLESS 新扩展、Hysteria2、TUIC、REALITY 或较新 DNS 能力的配置，不能假定原版内核可以解析。部分旧客户端界面仍使用 Clash 名称，内部内核却可能不同，因此需要查看客户端关于页面、内核设置或运行日志，而不是依据产品名称猜测。

Clash Meta 与 mihomo 的延续关系

Clash Meta 在原版配置模型上扩展协议、DNS、规则提供器、TUN 和网络栈能力。mihomo 是这一内核路线延续使用的名称。实际讨论中，“Meta 内核”和“mihomo”常被用于指向同一技术家族的不同时期或包装方式。新配置优先以 mihomo 文档与当前客户端实际内核为准，旧教程中的 Meta 字段多数仍有参考价值，但不能机械照搬所有默认值。

mihomo 的主要价值不是单纯增加协议数量，而是让协议、策略组、规则、DNS 与 TUN 在同一内核中协同。它能处理 SS、VMess、Trojan、VLESS、Hysteria2、TUIC 等多类节点，并支持更丰富的规则集与 DNS 行为。协议可解析仍不等于节点可连接：服务端参数、证书、传输字段和本地网络必须同时正确。

图形客户端与内核应分开理解。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等提供不同的界面、更新方式和系统集成；真正决定配置语法与协议能力的是其内置或调用的内核。客户端可能为某些字段提供图形开关，也可能只允许通过 YAML 修改。首推 Clash Plus 是基于全平台图形操作与常用设置覆盖，并不改变底层协议需要与服务端匹配这一事实。

配置兼容是“基础兼容加扩展识别”

一份只使用基础端口、常规策略组、DOMAIN-SUFFIX 规则和 SS 节点的配置，通常容易在多个 Clash 家族内核间迁移。加入 mihomo 专属协议、规则集格式、DNS 选项或 TUN 扩展后，向旧内核迁移可能失败。失败方式有三种：配置检查直接报未知字段；未知字段被忽略，导致行为与预期不同；节点能够显示，但连接时因协议实现缺失而失败。第二种最隐蔽，因此迁移后必须验证实际流量路径。

配置检查是最低成本的第一步。mihomo 可通过命令检查语法和字段是否能被当前内核接受。命令中的路径应替换为本机真实配置位置：

mihomo -t -f config.yaml

检查通过只说明 YAML 结构和已知字段基本有效，不证明订阅地址可访问、节点认证正确或 DNS 路径符合预期。随后应启动客户端，查看运行日志是否出现 provider 更新、证书、DNS 或监听端口错误，再分别验证直连规则、代理规则和最终 MATCH 规则。

六、订阅格式、节点字段与兼容性判断

分享链接、YAML 与订阅转换

常见订阅可能返回完整 Clash YAML、节点分享链接集合，或由服务端按客户端类型动态生成的内容。完整 YAML 可以同时携带节点、策略组、规则和 DNS；分享链接通常只描述单个节点；订阅转换服务则把上游数据重组为某种客户端格式。三者的信息量不同，导入成功也不代表内容完整。

SS 分享链接通常包含加密方式、密码、服务器和端口；VMess 旧式链接常把 JSON 信息编码后传输；Trojan、VLESS、Hysteria2 与 TUIC 多使用 URI 查询参数表达 SNI、传输、安全层和其他扩展。中间工具若不认识新字段，可能保留节点名称却丢失关键参数，最终形成“列表存在但全部超时”的配置。

优先使用服务提供方明确标注为 Clash Meta 或 mihomo 的订阅格式。只有原始分享链接时，应使用能够识别对应协议和扩展字段的导入工具。不要连续经过多层转换，因为每一层都可能重命名字段、删除未知参数或改变转义。订阅解析失败的系统检查可参考订阅链接失效或解析失败自查步骤。

用最小节点检查字段是否完整

排查兼容问题时，可以从订阅中复制一个节点到单独测试配置，保留服务端提供的全部字段，再建立一个 select 策略组。下面示例展示字段层级，不包含真实服务器信息。缩进使用空格，协议参数必须替换为服务端实际值：

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

proxies:
  - name: SS-Test
    type: ss
    server: server.example
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - SS-Test

rules:
  - MATCH,PROXY

这个最小配置适合确认内核能否监听端口、解析节点并建立基本连接。它不应直接覆盖原配置，因为其中没有生产环境需要的 DNS、规则集和本地网络选项。若最小配置可用而完整订阅不可用，问题通常位于策略组引用、规则提供器、DNS 或重复节点名称；若最小配置也失败，应回到协议字段、认证信息、服务端状态和本地网络。

字段映射比文件扩展名更重要

文件名为 YAML 并不能保证内容符合 mihomo 结构。有效文档需要正确缩进，列表项与映射层级必须明确。订阅可能以文本形式返回错误页面、登录提示或超时信息，客户端随后会报告解析失败。检查时先确认返回内容开头是否符合 YAML 或节点链接格式，再看 HTTP 状态、编码和更新日志。

不同内核对同一概念可能接受别名，但不应依赖未记录的隐式转换。例如服务器名称可能表现为 sni 或 servername，跳过证书验证可能使用不同字段，WebSocket 路径与请求头也有特定嵌套层级。最可靠的方法是保留订阅生成器输出，并对照当前内核支持格式。手工迁移时一次只改一个字段，修改后立即执行配置检查。

策略组还会引用节点名称或 provider 名称。节点重命名后若未同步更新组内引用，内核可能报告找不到代理。provider 更新失败时，已有缓存有时仍会让旧节点显示，容易误判订阅正常。应查看更新时间、日志和实际选择项，确认客户端使用的是新内容。节点列表为空、某类协议被过滤或更新后字段丢失，通常都与订阅格式和内核能力有关。

订阅安全边界与本地覆盖

订阅包含服务器、认证和策略信息，应只导入信任来源。分享配置前需要移除真实认证内容。客户端提供覆写或合并功能时，应明确哪些字段来自远程订阅、哪些由本地补充。常见做法是让远程内容提供节点，本地配置维护策略组、规则和 DNS；这样订阅更新不会反复覆盖个人规则，但合并顺序错误也可能造成同名组被替换。

每次大幅调整前保存可用配置副本，并记录当前内核类型。更新订阅后若连接异常，可先回退配置而不是同时更换客户端、协议和 DNS。一次改变多个变量会让问题无法定位。常见问答与错误现象可在常见问题中继续查找。

七、按网络、设备与任务选择协议

桌面办公与普通浏览

Windows、macOS 与 Linux 桌面环境通常供电稳定，系统允许客户端长期运行。办公网页、文档同步、代码托管和即时通信更重视连接稳定、首包一致性与兼容性。已有成熟 SS、Trojan 或 VLESS TCP 节点时，应优先使用稳定项，不必为了追求协议名称更新而频繁迁移。SS 配置简单，Trojan 的 TLS 部署清晰，VLESS 则适合已经采用较新服务端组合的环境。

客户端方面，Clash Plus 适合需要图形界面、系统代理、TUN 与订阅管理的用户；Clash Verge Rev、FlClash 和 Clash Nyanpasu 也可按系统与操作偏好选择。服务器或脚本环境可以直接使用 mihomo 内核。客户端差异主要体现在界面与系统集成，协议能否连接仍由内核和节点字段决定。安装入口集中在下载中心。

办公网络里若 UDP 表现不确定，先使用 TCP 协议建立稳定基线，再决定是否测试 Hysteria2 或 TUIC。策略模式建议保持 rule，让业务域名按规则进入对应策略组；全局模式适合短时诊断，不宜用来掩盖规则错误。节点选择使用 url-test 时要理解它按测试地址延迟择优，不会持续评估所有业务的真实吞吐。

高时延、随机丢包与持续传输

当网络往返时间较高、偶发丢包明显，并且任务以视频、远程文件或持续下载为主时，Hysteria2 与 TUIC 值得优先测试。它们的 QUIC 传输和拥塞控制可能比保守 TCP 更快恢复发送。但测试前应确认 UDP 可持续使用，并确保服务端位于可比线路。若 UDP 受限，Trojan、VLESS 或 SS 的 TCP 组合通常更可预测。

持续传输场景应观察十分钟以上，而不是只看开始几秒的峰值。记录平均吞吐、最低吞吐、断流次数和同时进行网页访问时的延迟。如果高吞吐造成其他应用明显排队，应降低并发或调整带宽参数，而不是继续提高发送上限。家庭共享网络尤其需要平衡单设备吞吐与整体延迟。

实时语音、在线会议和交互式远程桌面更关注抖动与丢包恢复，不一定需要最高带宽。Hysteria2 或 TUIC 在合适网络下可能改善波动，但持续重传也可能带来反效果。应进行真实通话或交互测试，并保留一个稳定 TCP 节点作为 fallback。fallback 策略组按顺序检查可用性，适合明确主备关系；它与按延迟择优的 url-test 不是同一种逻辑。

移动设备与频繁网络切换

Android 和 iOS 的选择应把电量、后台限制与网络迁移放在同一层面。轻量浏览、消息和邮件可以先选择成熟的 SS、Trojan 或 VLESS 节点；长时间视频与大文件任务再比较 Hysteria2、TUIC。若设备经常在 Wi-Fi 与蜂窝网络之间切换，可观察 QUIC 连接恢复是否更平滑，但仍需接受系统切换网络时可能短暂重连。

移动端测试至少持续一个完整使用周期。保持屏幕亮度、应用组合和网络条件接近，比较相同任务后的电量变化。瞬时 CPU 占用高不一定意味着总耗电高，因为更快完成传输可能缩短无线模块活跃时间；反之，后台持续小包和频繁重试可能看似负载不高，却延长唤醒时间。客户端被系统回收时，应先调整后台权限，而不是立即更换协议。

路由器、低功耗主机与家庭网关

路由器和低功耗主机的处理器、内存与散热余量有限，协议选择需要关注持续 CPU 占用。SS 往往是较稳妥的起点，具体加密算法应结合硬件能力测试。Trojan 的 TLS、VMess 的封装以及 QUIC 协议在高吞吐下可能增加计算压力。设备无法跑满线路时，先查看单核占用、软中断和温度，再判断是协议瓶颈还是系统转发瓶颈。

作为家庭网关时，连接数和 DNS 请求量通常比单设备更高。规则集规模、TUN 网络栈、连接跟踪和日志级别都会影响资源。不要只通过更换协议解决整体负载，应同时精简重复规则、避免调试日志长期运行，并为 DNS 缓存设置合理策略。mihomo 内核适合需要完整规则和多协议支持的网关，但图形客户端通常更适合个人电脑。

八、验证、迁移与故障定位方法

建立一条可重复的验证流程

协议迁移不应从删除旧节点开始。先保留现有可用配置，把新节点加入独立策略组，并使用相同规则测试。第一步执行配置检查，确认 YAML 和字段能被当前内核解析；第二步在客户端中选择新节点，测试基本 TCP 连接；第三步确认 DNS 查询与规则命中；第四步再测试 UDP、持续传输和网络切换。每一步只验证一个层级，失败时能够快速回退。

基本连接成功后，应分别验证短连接、长连接和多并发。短连接可通过连续打开多个未缓存页面观察首包和失败率；长连接可保持文件传输或视频播放，观察十分钟以上的波动；多并发用于确认策略组和内核在日常负载下是否稳定。移动端还要锁屏一段时间，再解锁观察连接能否恢复。一次测试无法覆盖全部状态。

判断代理是否实际生效时，不要只看界面开关。检查系统代理或 VPN 状态、连接面板中的目标域名、规则命中和出口结果。首次连接的完整操作可参考选节点、测延迟与确认代理生效。若所有节点同时超时，再按节点超时排查顺序区分客户端、节点和本机网络。

按故障层级定位，而不是反复重装

配置解析错误通常发生在连接之前，日志会指出 YAML 行号、未知字段或策略组引用。此时应检查缩进、冒号后的空格、列表层级和内核支持，不需要更改防火墙。节点能显示但连接超时，则检查服务器、端口、协议类型、认证信息和本地网络。TLS 握手错误重点检查系统时间、SNI、证书验证和 ALPN。QUIC 节点认证后断流，应再检查 UDP 路径、拥塞控制与服务端代际。

只有部分网站异常时，协议本身通常不是第一嫌疑。应查看规则是否把域名送入预期策略组、DNS 是否返回适合当前模式的结果，以及应用是否绕过系统代理。TUN 模式能接管更多应用流量，但也会引入路由、权限和 DNS 接管变量。排查时可以暂时使用最小规则确认连接，再逐项恢复规则和 DNS 配置，避免全局模式长期掩盖规则错误。

所有协议都突然失效时，优先检查订阅更新、系统时间、本地监听端口、系统代理、VPN 权限、防火墙和当前网络。单个节点失败而同协议其他节点正常，问题更可能在服务端或节点字段。只有某一协议全部失败，则比较内核支持、订阅转换和该协议依赖的传输层。这样的分组判断比逐个随机点击节点更快。

从旧内核迁移到 mihomo

迁移前先列出旧配置中的端口、代理节点、策略组、规则、DNS、TUN 和 provider。第一轮只迁移基础端口、一个可用节点、一个 select 组和 MATCH 规则，确认内核运行。第二轮加入 DNS 与常用规则，第三轮再加入远程 provider、TUN 和新协议。分阶段迁移能明确是哪组功能造成差异。

原版 Clash 配置中的基础字段通常可以继续使用，但旧教程中的默认值不应直接视为 mihomo 的最佳设置。特别是 DNS 增强模式、Fake-IP 范围、嗅探、TUN 网络栈和规则集格式，应根据当前客户端与系统调整。遇到弃用提示时，按照当前内核文档替换字段，不要仅通过关闭日志隐藏问题。

迁移新协议时保留服务端生成的完整节点对象。VLESS 的流控与安全层、Hysteria2 的认证与带宽字段、TUIC 的 UUID、密码和拥塞控制都不应凭旧节点模板补写。配置通过后再把节点纳入 url-test 或 fallback 组。自动组测试地址和间隔会产生额外请求，移动端不宜设置过短间隔。

形成长期可维护的配置

稳定配置应把变化频率不同的内容分开：订阅负责节点更新，本地策略组表达选择逻辑，规则负责流量分类，DNS 与 TUN 负责系统接入。不要在多个位置重复维护同一节点，也不要让远程更新覆盖关键本地设置。节点名称应清晰且稳定，策略组名称避免频繁修改，以免规则和应用引用失效。

每次变更记录四项内容：修改了哪个层级、预期解决什么问题、如何验证、如何回退。协议迁移若没有明确目标，就应保留当前稳定方案。SS、VMess、Trojan、VLESS、Hysteria2 与 TUIC 都有适用边界，最终选择应由可用服务端、网络特征、设备资源和任务类型共同决定，而不是由协议的新旧顺序决定。

简化后的决策路径是：普通浏览先选稳定 TCP 协议；高时延持续传输再测试 Hysteria2 或 TUIC；新协议与扩展优先使用 mihomo；移动端额外比较后台恢复和总电量；订阅异常先核对格式与字段；更换协议后按配置、连接、DNS、规则、应用五层逐项验证。完成这套过程后，协议选择就从一次性测速变成可重复的工程判断。