Clash 协议与内核手册

协议选型的四层边界

客户端、内核、协议与线路

Clash 生态中的名称处在不同层次。客户端负责窗口、订阅管理、系统代理和权限申请；内核负责建立连接、匹配规则与处理 DNS；协议规定客户端和服务器如何认证、封装与传输数据；线路则决定这些数据实际经过哪些网络。选择一个客户端，不等于选定一种协议。安装支持 mihomo 的图形界面后，仍需确认订阅中的节点类型和服务端参数。

这四层可以分别出现问题。界面能够导入配置，只代表文件进入管理器，不保证内核识别所有字段；节点显示连接成功，只代表一次探测完成，不保证视频、下载和实时通话都适用。协议名称相同的两个节点，也可能使用不同服务器、出口、传输层和带宽策略。因此，比较协议时应尽量保持服务器位置、测试目标与测试时段一致，否则结论往往只是线路差异。

从限制条件开始，而不是从排行榜开始

先列出设备系统、客户端内核、服务端协议和当前网络允许的传输方式。办公网络可能允许 TCP 连接，却限制 UDP；移动网络可能在切换基站后改变地址；旧设备可能缺少高效的密码运算能力。如果服务端只提供一种协议，客户端不能通过更改类型字段把它变成另一种。协议必须在两端对应，端口、认证信息与传输选项也必须一致。

随后明确主要任务。浏览网页更在意首个响应和短连接成本，大文件传输更在意持续吞吐，语音和游戏更在意抖动、丢包及 UDP 转发能力。远程桌面同时关心交互延迟和连接恢复。一个在长时间下载中表现稳定的配置，未必在弱网通话中更合适；对某项测试做出的优化，也可能增加后台流量和手机耗电。

安全属性与连接质量分别判断

加密认证回答的是连接对象是否可信、传输内容如何保护，速度测试回答的是当前路径能提供怎样的服务。二者不能互相替代。使用证书的配置应验证证书链和服务器名称，使用预共享凭据的配置应保证凭据来源可靠。不要因为某个节点测速较快，就长期关闭认证检查；也不要把一种较新的协议名称直接解释为更高的安全等级。

本手册不提供固定速度排名。协议开销会受到处理器、加密实现、路径最大传输单元、丢包和服务器负载共同影响。阅读后面的章节时，可以为每个候选节点记录三项信息：当前内核是否完整支持、当前网络是否允许其底层传输、实际任务是否得到改善。只要其中一项无法确认，就先保留已验证的配置，不必同时修改多个参数。

SS 与 VMess：独立加密代理的设计取舍

Shadowsocks 的轻量封装

Shadowsocks，通常简称 SS，采用相对精简的代理模型：客户端接收本地连接，把目标地址与业务数据封装后发给服务器，再由服务器建立目标连接。它不要求所有部署都采用网页传输或证书体系，基础配置主要围绕服务器、端口、加密方法与凭据展开。这种结构便于跨平台实现，也让排错可以从较少的必填字段开始，但并不意味着任意 SS 节点都具有相同特性。

SS 的加密方法不能随意互换。较早的流加密方案、常见的 AEAD 方案和后续的 Shadowsocks 2022 方案具有不同的密钥格式与实现要求。服务端采用哪一种，客户端就必须提供相应支持；某些方案需要特定长度和编码的密钥，而不是任意口令。看到导入错误时，应先核对方法名称和密钥格式，不要只尝试更改服务器端口。

SS 可以承载 TCP，也可以在两端与网络均支持时转发 UDP。客户端中的 UDP 开关只是本地允许条件，服务器、订阅与路径同样要满足要求。若网页正常而游戏或通话异常，应检查这些业务是否确实经过代理、服务端是否开放相关能力，以及当前网络是否限制 UDP。单次网页探测无法证明 UDP 转发可用。

VMess 的身份认证与传输组合

VMess 来自 V2Ray 体系，使用用户标识参与认证，并具有自己的协议加密与封装机制。实际节点可能叠加 TCP、WebSocket 等传输形式，也可能同时使用 TLS。比较时必须完整描述组合，不能只说 VMess 比另一种协议快。直接传输与经过额外网关的连接，在握手数量、封装成本和中间设备支持上可能差别明显。

时间同步是 VMess 排错中值得检查的条件。认证机制对设备时钟存在要求，系统时间偏差可能造成认证失败，而界面上往往只显示超时或连接被关闭。应先让操作系统自动同步时间，再检查用户标识和服务端日志。旧订阅还可能携带历史兼容参数，这些字段的含义取决于内核实现，不能照搬过时教程中的数值。

WebSocket 路径、请求主机名、TLS 服务器名称是不同层面的信息。路径参与应用层握手，请求主机名用于 HTTP 路由，TLS 名称参与握手与证书验证。它们有时相同，但不存在必须相同的通用规则。服务端经过反向代理时，漏掉路径或改错请求头，就可能连接到服务器却无法建立代理会话。这类问题不属于分流规则故障。

选择与维护的实际边界

在已验证的 TCP 网络和资源有限设备上，结构较简单的 SS 配置值得作为基线；已有完整 VMess 部署时，也没有仅因名称较旧就立即迁移的必要。真正需要评估的是服务端维护情况、加密配置、客户端支持和日常任务表现。增加传输封装可以满足特定部署需求，但也会增加需要保持一致的字段，无法自动带来速度提升。

如果 SS 配置带插件参数，应单独确认客户端是否实现该插件与具体模式。支持基础 SS 不等于支持全部插件，节点转换工具也可能丢掉插件选项。VMess 同样存在传输组合的兼容边界。保留原始链接和配置来源，逐项比对转换后的字段，比反复切换运行模式更有效。遇到导入问题，可先查看常见问题中的安装配置说明。

Trojan 与 VLESS：认证、TLS 与传输分工

Trojan：把安全通道交给 TLS

Trojan 的常见部署以 TLS 作为外层安全通道，在通道内完成代理认证与数据转发。它没有要求用户再维护一套独立的业务加密算法清单，配置重点转向密码、证书、服务器名称与服务端监听设置。这里的简化是职责分工：TLS 保护传输，代理协议描述目标与认证。实际部署是否可靠，仍取决于证书验证和服务器配置是否正确。

连接地址与证书名称可以不同。例如客户端通过一个地址连接服务器，但服务端证书签发给域名，此时需要正确设置 TLS 服务器名称，并保证证书确实匹配该名称。SNI 是握手中传递服务器名称的机制，证书验证则检查身份与信任链，两者有关但不是同一件事。仅填入一个看似合理的域名，不会让错误证书变得可信。

排查 Trojan 连接失败时，先区分 TCP 无法建立、TLS 握手失败与代理认证失败。前者通常涉及地址、端口与路径；中间一类应检查时钟、证书有效期、名称匹配与信任链；最后一类才重点检查密码和服务端认证配置。客户端可能把多种失败统一展示为超时，需要结合日志中发生失败的阶段判断，而不是直接修改所有 TLS 选项。

VLESS：轻量协议不等于独立加密层

VLESS 同样来自 V2Ray 相关生态，设计上减少协议自身的部分负担，把安全保护交给所搭配的传输安全机制。不能把它理解成只填用户标识就自然具备完整的加密保护。常见配置会使用 TLS 或 REALITY 等方案，但具体支持取决于客户端内核及所选传输组合。订阅中缺失安全层相关字段时，应向配置提供方核对，而不是猜测默认行为。

REALITY 的配置与普通证书式 TLS 并不相同，通常涉及公钥、短标识、服务器名称等对应参数。用户标识正确而这些字段不匹配，连接仍会失败。某些 VLESS 部署还指定流控方式，例如服务端配置要求特定的 Vision 流控；这属于两端协商与实现约束，不是一个通用加速按钮。应按服务端实际要求保留，不能见到相关字段就复制到所有节点。

同一种 VLESS 节点还可能采用不同传输。客户端支持 VLESS 基础协议，不代表支持服务端使用的每一种传输、安全层和流控组合。节点分享链接也未必能表达所有扩展字段。确认兼容时，应查看当前内核文档中的组合限制，并以实际生成的配置为准。仅凭客户端名称或一张协议支持列表，无法覆盖这些边界。

证书验证与复用策略

关闭证书验证会削弱客户端识别服务器身份的能力，不应作为长期修复方法。采用自签发证书的环境，应按客户端能力配置可信证书或相应的身份约束；使用公共证书时，应修正名称和证书链。若只有某台设备失败，还应检查系统时间、信任存储及安全软件是否介入连接。相同节点在不同设备上的表现，可能来自本地环境而非协议本身。

连接复用能够让多个逻辑请求共享底层连接，减少重复建连，但可能改变拥塞竞争和故障影响范围。共享连接发生阻塞时，多个请求可能一起受影响；服务端不支持对应复用方式时，还可能出现看似随机的断流。选择 Trojan 或 VLESS 时，先使用服务端明确支持的最小配置完成验证，再评估复用、传输封装与流控，通常比一开始叠加选项更容易定位问题。

Hysteria2 与 TUIC：基于 QUIC 的连接模型

QUIC 改变了哪一层

QUIC 通常运行在 UDP 之上，结合加密握手、可靠传输与多路流等能力。这里的 UDP 是底层承载，不代表应用数据一定以不可靠方式传送：网页和文件内容仍可通过可靠流交付。与多个逻辑流共享一个 TCP 字节流相比，QUIC 能减少跨流的有序交付阻塞，但共享连接仍受到同一条路径的拥塞与可用带宽限制，不会绕过物理网络容量。

Hysteria2 与 TUIC 都利用 QUIC，但它们不是同一种协议的不同名称，也不能互换认证字段。服务端监听 Hysteria2 时，客户端必须按 Hysteria2 建立会话；TUIC 的不同协议代际也需要对应支持。客户端界面显示“支持 QUIC”，不足以证明能连接任意基于 QUIC 的代理服务，仍需核对节点类型与实现范围。

Hysteria2 的带宽估计与拥塞取舍

Hysteria2 面向具有丢包与复杂链路条件的传输需求，提供与带宽配置相关的拥塞控制选择。配置中的上传和下载带宽通常描述客户端侧的预期能力，不应简单照抄服务器网卡标称速率。若把可用带宽估计得过高，可能增加排队、竞争与丢包，使网页交互和同一网络中的其他设备受到影响；填写得过低，又可能限制持续传输。

服务端也可以限制带宽或影响协商结果，因此不能仅凭客户端填入的数值判断最终行为。应先使用维护方建议的配置，再通过持续下载与交互任务共同观察。某些可选混淆设置要求两端一致，它们不会替代证书验证和认证。修改后完全无法握手时，应先恢复这些选项，不宜立即把故障解释成带宽不足。

TUIC 的流、数据报与连接维护

TUIC 同样利用 QUIC 承载代理会话，配置可能涉及用户标识、密码、拥塞控制、UDP 转发方式与连接维护参数。TCP 代理流和 UDP 业务的处理方式不同，选择可靠转发或数据报方式时，应考虑应用对及时性和完整性的不同要求。实时通话通常更关心过期数据是否被及时丢弃，而文件内容要求按序可靠到达，不能用一个抽象的“稳定”概括。

保活和空闲超时决定连接在没有业务时如何维持。移动网络中的地址转换设备可能较快回收 UDP 映射，适当保活有助于后续数据到达；但过于频繁的保活会增加无线唤醒和后台流量。网络切换后连接能否继续，还依赖实现、服务器和路径，不应把 QUIC 的连接迁移能力理解成任何客户端都能保证会话连续。

UDP 路径不是始终可用

如果当前网络对 UDP 限制明显，这两类协议可能比基于 TCP 的方案更难建立连接。增加重试次数通常不能解决底层不可达。还应留意封装后的包尺寸：额外代理层、隧道或接入网络可能缩小路径可用的传输单元，出现小请求正常、大流量停顿的现象。应通过日志与对照网络逐层确认，不要随意降低所有设备的系统参数。

适合的评估方式是准备一条已验证的 TCP 配置作为对照，在同一网络上分别测试网页、持续传输和空闲恢复。QUIC 方案在某些丢包路径上可能更合适，也可能受到运营环境的速率限制。选择依据应是当前任务的可重复改善，而不是单次峰值。后续调整仍需兼顾服务器承载能力和共享网络中的其他应用。

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

把一次测速拆成多个阶段

用户感知的等待包含域名解析、底层连接、协议握手、目标站点响应和内容传输。节点延迟测试通常只覆盖其中部分过程，不等于每个网站的首屏时间。一个节点在探测中响应较快，仍可能因为出口到目标站点的路径较差而下载缓慢。判断协议差异时，需要分别记录首次访问、重复访问和长连接任务，避免把缓存与会话复用带来的变化算成协议优势。

持续吞吐受发送窗口、拥塞控制、往返时间和丢包影响。高带宽链路若往返时间较长，需要足够的数据在途才能利用容量；出现丢包后，不同控制策略恢复速度也不同。但更积极地发送并不总是更好，可能把接入链路队列填满，让交互延迟升高。因此评估下载速度时，还应同时打开常用网页或进行语音测试，观察是否以其他业务的可用性为代价。

处理器开销来自整条处理链

加密只是资源成本的一部分。用户态网络栈、数据复制、传输封装、连接复用、规则匹配和日志输出都会消耗处理器时间。不同处理器对特定密码算法的硬件支持也不同，不能把桌面电脑上的测试直接套用到手机或路由器。低功耗设备如果出现持续高负载，应分别比较系统代理与 TUN、精简配置与完整配置，确认瓶颈所在。

内存占用通常还受到连接数量、规则集合、订阅规模、缓存和界面进程影响。只比较两个客户端的总内存，不一定能得出内核效率差异：其中一个可能加载了更多规则，另一个可能没有打开连接面板。应保持规则和业务一致，并把图形界面与核心进程分开观察。路由器上的余量尤其重要，内存紧张引发的进程退出会被误认为协议断流。

手机耗电与无线唤醒

手机电量不仅消耗在加密上，也消耗在无线连接保持、后台唤醒、重连和流量探测上。频繁检查所有节点、过短的保活周期、持续输出详细日志，都可能让空闲状态难以保持。协议名称本身无法给出固定耗电排名。使用同一部手机、同一网络和相近业务量比较，才有参考价值；屏幕亮度和信号强弱也应尽量一致。

移动系统通常通过 VPN 或网络扩展机制接管流量，具体方式由平台和客户端决定。客户端显示的 TUN 名称，不一定代表它与桌面环境采用相同实现。系统省电策略可能暂停后台活动，恢复后又需要重新建立会话。若锁屏后异常而前台正常，应先查看后台权限和网络恢复行为，再调整协议。盲目缩短保活可能掩盖问题，却增加日常电量消耗。

建立可复现的比较记录

每次只改变一个因素：保持节点地区与目标站点一致，固定是否启用 TUN，暂停自动节点检测，再分别观察短请求、大文件和空闲恢复。不要在下载过程中同时更新订阅、切换 DNS 与修改拥塞参数，否则无法解释结果。建议记录发生时段、网络类型、错误阶段和任务表现，而不是只保留一张峰值截图。

若只有特定应用异常，还需要检查分流规则与解析路径。Fake-IP 是域名映射机制，不是速度增强协议；TUN 扩大流量接管范围，也不保证所有连接更快。开启后表现变化，可能只是原本直连的流量进入代理。可结合连接记录确认命中的规则与出口，再阅读网速慢的三层定位方法，按节点、线路、本机顺序排查。

原版 Clash、Clash Meta 与 mihomo

项目沿革与能力来源

原版 Clash 建立了以 YAML 描述代理、策略组与规则的使用方式，许多图形客户端沿用这一配置模型。原版项目停止维护后，既有安装仍可能运行，但不应期待它持续获得新协议和兼容修复。旧客户端能够识别常见配置，不代表能够处理后来扩展的协议字段。遇到未知类型时，首先要确认实际执行连接的内核，而不是只看窗口标题。

Clash Meta 是在 Clash 相关基础上发展出的扩展内核路线，后来以 mihomo 名称继续维护。用户口中的 Meta、配置文件里的扩展能力和当前的 mihomo 文档，往往指向同一条演进脉络，但历史安装包仍可能保留旧实现。名称关系说明项目来源，不代表所有写着 Meta 的客户端都包含相同能力，仍需查看客户端提供的内核信息与维护说明。

mihomo 扩展了协议、规则、DNS 和网络接管等能力，成为多个桌面与移动客户端的连接基础。图形界面通常额外负责订阅下载、覆写与权限管理。因此某个功能可能分布在两处：内核能读取相关字段，界面却没有对应开关；或界面提供开关，但当前核心不支持相应写法。查阅时应把界面文档与内核文档分开核对。

兼容配置结构，不等于兼容所有字段

三者之间常见的连续性体现在代理列表、策略组与规则等基本结构上，但扩展协议、规则行为和 DNS 字段并非完整向后兼容。新配置交给旧内核，可能直接加载失败，也可能忽略部分字段；旧配置交给新内核，也可能因为字段约束更严格而暴露问题。成功加载只是第一步，还要核对规则实际走向、域名解析结果和 UDP 业务。

客户端选择与旧环境迁移

初次选择可先从下载页首推的 Clash Plus 入手，再按系统确认支持范围和配置方式。桌面环境还可比较 Clash Verge Rev、FlClash 与 Clash Nyanpasu；移动端可按下载页查看 Clash Meta for Android、FlClash 或 Surfboard 的格式要求。不同客户端不必使用相同配置语法，尤其不能因为都能接收订阅链接，就认定可以直接共享完整文件。

Clash for Windows 与 ClashX Meta 在下载清单中属于已停止维护的归档选择。迁移前应保留原始订阅地址、个人规则、覆写内容与必要的本地设置；不要直接覆盖旧目录。先在新客户端导入订阅，再分别验证系统代理、TUN 权限、开机启动和端口。旧环境中的可执行脚本不宜直接复制运行，应先理解它修改了哪些配置字段。

内核切换只在客户端明确支持时进行。不同内核包可能依赖特定控制接口、启动参数和权限管理方式，手动替换文件可能导致界面状态与真实运行不一致。若要验证是否切换成功，应查看运行进程和启动日志中的内核信息，再检查配置加载结果。不要只依据设置菜单显示的选项判断，残留进程可能仍占用旧端口。

迁移排错宜分两次进行：先以最小订阅配置建立连接，再逐项恢复规则与覆写。这样出现异常时，可以判断来自协议兼容还是个性化设置。项目关系的延伸解释见三代内核功能与兼容对照；从旧桌面环境搬迁时，可参考Clash for Windows 迁移步骤，避免把客户端管理层的问题混入协议测试。

订阅格式、字段保留与配置合并

订阅地址不是一种固定文件格式

订阅是一种更新入口，返回内容可能是完整 Clash YAML、节点列表、编码后的分享链接集合，或面向其他客户端的配置。相同网址还可能依据请求方式返回不同格式。因此，“链接能打开”不能证明“当前客户端能解析”。先确认订阅提供方标注的目标客户端，再查看导入提示。返回网页、登录页或错误文本时，应处理访问与授权问题，而不是修改 YAML 缩进。

完整配置可以包含代理、策略组、规则与 DNS；节点订阅通常只描述连接端点，需要由本地配置提供策略和分流。二者混淆容易造成规则突然消失或策略组引用不到节点。某些客户端在导入时自动生成模板，让问题暂时不明显，换一个客户端后才暴露。阅读配置时应先辨认顶层结构，再检查其中的协议字段，不能只搜索节点名称。

转换能改变表达方式，不能补齐未知信息

格式转换工具通常把已知字段映射到另一种语法，但无法凭空恢复源数据中没有的公钥、证书名称、插件参数与传输路径。遇到目标格式不支持的能力，还可能丢弃字段。转换完成后应检查协议类型、地址、端口、身份信息、TLS 与传输选项是否完整，尤其留意 Hysteria2、TUIC 和带扩展组合的 VLESS 节点。

分享链接适合传递单个节点，但完整配置还包含规则顺序、策略组依赖和本地解析行为。把一组节点链接导入另一客户端，不等于迁移了原来的网络策略。Surfboard 等客户端使用的配置体系也有独立要求，不能把 Clash YAML 改一个后缀就使用。若格式不匹配，应向提供方获取适合目标客户端的订阅，而不是依靠不断转换叠加不确定性。

分离远程更新与本地策略

订阅更新通常会替换远程管理的内容，直接在下载得到的文件中修改节点或规则，下次更新就可能丢失。更稳妥的方式是让订阅负责节点来源，本地覆写负责个人规则、DNS 与分组，但具体合并顺序由客户端决定。有的以本地键覆盖远程键，有的对列表追加或替换。操作前应查看合并说明，并检查最终交给内核的配置。

以下片段只展示可解析的最小规则结构，不包含远程节点。它适合说明顶层字段之间的关系，不应替换现有订阅。实际使用时，代理组中的名称必须引用真实存在的节点或内置策略；规则按顺序匹配，较宽的规则放在前面会遮住后面的精细条件。改动后先运行客户端提供的配置检查，再观察连接记录是否命中预期规则。

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

proxy-groups:
  - name: 默认策略
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,默认策略

解析设置也属于配置兼容范围

Fake-IP 通过虚拟地址映射保留域名信息，配合规则与流量接管使用；它不是节点协议的一部分。订阅导入后若同时改变 DNS 模式，应用表现可能发生变化，即使代理节点本身完全相同。需要核对解析请求由谁接收、是否存在系统或应用自带的加密 DNS，以及接管范围是否覆盖预期流量。单看一个 DNS 开关无法确认完整路径。

排查合并问题时，先保留原始内容与最终配置的副本，隐藏订阅凭据后比较相关字段。不要把订阅地址上传到不明转换服务，也不要在公开日志中保留认证信息。若出现域名相关异常，可参照DNS 请求路径与 Fake-IP 配置说明。每次只调整一组配置，确认后再继续，避免更新、合并和解析问题互相叠加。

按场景选择协议并完成验证

桌面浏览、开发与持续传输

日常网页与开发工具可先采用服务端维护明确、客户端支持完整的配置，不必先追求复杂传输组合。浏览器遵循系统代理时，通常容易确认流量走向；命令行工具和独立运行时则可能需要单独配置代理。终端访问失败而网页正常，应先检查该程序是否使用代理，而不是立即更换协议。容器、虚拟机与远程开发环境也可能拥有独立网络设置。

下载大型文件时，应观察持续吞吐与恢复能力，而不只看开始时的峰值。若 TCP 方案稳定，保留它作为基线；若路径存在明显丢包且 UDP 可用，可对照测试 Hysteria2 或 TUIC。测试期间同时留意交互响应和设备负载。通过调整带宽参数得到的提升，应在不影响其他业务的前提下确认，不能把短时间占满链路当作普遍最优配置。

移动通勤与实时应用

手机通勤经常发生网络切换、信号变化和后台休眠。应优先测试锁屏后恢复、无线网络转蜂窝网络，以及长时间空闲后的首次请求。支持连接迁移的底层机制可以改善部分情况，但客户端与服务端是否真正启用仍需验证。若某种配置在固定网络速度很好，却在每次切换后需要手动重连，它可能不适合当前的移动使用场景。

游戏和通话需要确认 UDP 转发、规则命中与出口位置。显示节点可用，不意味着实时业务使用了该节点；有些应用同时连接认证、媒体与更新服务，可能分别命中不同规则。应先查看具体连接，再判断是否需要调整协议。远程桌面还应关注画面更新、键鼠反馈与短时丢包后的恢复，不要只用文件下载速度作为依据。

服务器、路由器与受限网络

服务器与路由器通常更适合直接管理 mihomo 内核，但需要自行维护进程、权限、配置更新和日志轮转。资源有限时，应控制规则规模与连接探测频率，避免调试日志长期占用存储。远程变更前应保留可恢复的管理通道，先检查配置，再重载服务。把桌面客户端生成的完整配置搬到路由器时，还要检查文件路径、监听地址与权限差异。

办公或访客网络若限制 UDP，应优先验证可用的 TCP 配置，而不是持续重试 QUIC。需要经过额外代理或网关时，也应确认是否出现多层封装及地址解析差异。如果某节点只在一种接入网络失败，先以另一网络复测，再检查本机配置。相反，所有网络都在相同认证阶段失败，通常更应检查凭据、证书和协议字段。

统一的验收与回退顺序

首次验收先检查配置能否加载，再建立基础连接，然后确认规则、DNS 和目标应用。每一步都保留一个明确结论：内核识别了什么协议、请求命中了什么策略、实际出口是否符合预期。失败时回到最近一次正常配置，不要同时切换内核、订阅来源与网络模式。客户端异常退出与协议握手失败也要分开，前者可参照启动闪退与日志排查。

1. 核对服务端协议与客户端内核，检查身份、传输和安全层字段。
2. 在已知可用网络上测试一个普通网页，确认真实命中的策略。
3. 分别测试持续传输、实时应用和空闲恢复，记录失败阶段。
4. 只调整一个变量，重复相同任务，再决定保留还是回退。

最终选型应形成一套主用配置和一套经过验证的替代配置。替代方案最好具有不同的底层传输条件，避免两者依赖同一条失效路径，但仍需保持凭据与配置来源可信。需要安装客户端时，按下载页的平台入口选择，首推 Clash Plus；具体操作回到使用指南，通用故障查阅常见问题。协议是连接方式，不是对任何网络结果的保证。