Clash 协议与 mihomo 内核参考

一、协议选型：先区分客户端、内核与传输

界面里的协议名称只描述连接的一部分

一条代理连接通常包含本地接入、规则匹配、代理协议、底层传输和远端出口几个环节。浏览器先把请求交给本地端口，内核依据域名或地址选择代理组，再使用选中的节点连接服务器。协议名称主要描述客户端与服务器之间怎样认证、封装和转发，并不直接决定出口带宽、远端负载或目标网站的响应速度。

客户端负责订阅管理、界面设置、后台运行和系统集成；内核负责解析配置、建立连接、处理 DNS 与执行规则。同一个客户端名称不代表永远使用同一种内核，不同客户端也可能使用同一家族的内核。因此，判断能否使用某类节点，应同时查看客户端所带内核、相关功能入口和服务端要求，不能仅凭界面相似程度推断兼容。

把协议、传输与安全参数分别记录

例如，VLESS 是代理协议，WebSocket 是可能使用的传输封装，TLS 是安全会话机制，服务器名称则参与证书验证或握手选择。它们处在不同层次。订阅把这些字段组合成一条节点记录，用户只看到一个名称时，容易把所有差异归因于协议。比较之前，应先展开节点详情，记录协议类型、传输方式、远端端口和安全选项。

TCP 提供可靠、有序的数据流；UDP 提供数据报，不替应用保证重传与顺序。QUIC 运行在 UDP 之上，在协议内部实现安全连接、可靠流和拥塞控制。看到节点使用 UDP，并不能认定全部应用流量都变成不可靠传输。反过来，节点建立连接使用 TCP，也不代表它一定支持转发应用发出的 UDP 数据报，两件事需要分开确认。

先建立能够复现的比较条件

合理的比较应尽量固定设备、接入网络、目标服务和测试时段。若两条节点位于不同地区或使用不同线路，测试结果反映的是整条路径，而不是纯粹的协议差异。日常选型不必追求实验室测量，但至少应分别观察首次打开页面、持续传输、语音通话和待机恢复，避免用一个测试按钮替代全部使用体验。

客户端显示的延迟往往来自一次指定网址请求，结果可能包含解析、握手和服务器响应等不同阶段。各客户端的测试方法不一定相同，数字也不宜横向照搬。能够通过探测，只证明当时的测试路径可用；目标应用可能使用不同域名、不同协议或独立的 DNS 逻辑，仍需实际打开应用验证。

本页涉及的配置能力以实际内核实现为边界。订阅提供方决定服务器支持哪些协议和参数，客户端不能单方面把一条 SS 节点改成 TUIC 节点。需要另一种协议时，应获取服务端提供的对应记录，而不是只修改本地的类型字段。后续各章的比较，也都建立在认证正确、服务端可用和参数匹配的前提上。

二、Shadowsocks 与 VMess：轻量转发和协议演进

Shadowsocks 的取舍在于较少的协议层次

Shadowsocks，常写作 SS，围绕加密代理转发设计。典型配置包含服务器地址、端口、加密方法和密码。它没有要求每条连接都额外建立一层通用网页传输封装，因此在直接使用的场景里结构比较简洁。客户端仍需执行加密、认证和地址封装，不能把“轻量”理解成没有计算开销，也不能据此保证任何网络下都更快。

SS 的加密方法不是一个可以随意替换的装饰字段。传统流加密、AEAD 方法与较新的 Shadowsocks 2022 系列具有不同的实现要求，部分方法对密钥形式也有明确限制。节点详情里出现某个方法，并不代表旧内核能够加载。发生不支持加密方法的错误时，应确认内核能力与原始记录，而不是自行换成一个熟悉的名称。

SS 可以承载 TCP，也可以在相应实现和服务端配置下转发 UDP。两者可能具有不同的网络可达性：网页正常而通话异常时，应检查 UDP 是否被支持和放行。部分记录还使用插件扩展传输，这会增加额外依赖；完整节点需要同时保留插件名称与选项。只复制服务器、端口和密码，可能遗漏真正决定连接方式的部分。

VMess 的认证方式与传输组合需要一起看

VMess 来自 V2Ray 生态，提供身份认证和代理数据封装，并可与不同传输方式组合。它的设计演进涉及认证和安全机制的变化，因此同为 VMess 的历史配置并不总能互换。识别记录时，除了用户标识，还应查看传输类型、是否启用 TLS、对应路径和请求主机等字段，不能把一个分享链接中的长字符串当成全部配置说明。

较旧的 VMess 记录可能包含与旧认证流程有关的参数。现代配置通常使用 AEAD 认证方式，历史字段的默认解释可能因实现而异。迁移时不要照搬过时教程中的固定参数组合，也不要为消除报错盲目增删字段。系统时间明显不准确还可能影响认证或证书判断，所以在反复修改账号前，应先确认设备的日期、时间与自动校时状态。

VMess 的实际性能经常受外层传输影响。直接使用 TCP，与经过 WebSocket、TLS 或其他中间层承载的记录，在握手过程、头部封装和连接复用上可能不同。若两个节点的传输层次不同，即便协议名称相同，首次请求时间和持续传输表现也会有差别。分析时应把“VMess 节点较慢”进一步拆成解析、连接、认证和应用请求哪个阶段较慢。

在客户端中怎样判断是否适合继续使用

导入后先确认节点没有被内核丢弃，再通过代理组选中它，完成一次普通网页请求和一次实际业务测试。若客户端显示节点存在却始终无法连接，应查看日志中最早出现的错误。方法不支持、认证失败、连接超时属于不同分支：前者偏向兼容问题，中者应核对凭据与时间，后者还需检查地址、端口和当前网络。

已有稳定 SS 或 VMess 服务时，没有必要仅因另一种协议名称更新就迁移。真正值得更换的理由是当前内核停止维护、所需传输不被支持，或业务在现有组合下存在可复现的问题。桌面浏览和一般下载可以先保留熟悉的工作配置；涉及实时通话时，则单独确认 UDP 转发能力，不用网页能否打开来代替判断。

这两类协议也能作为迁移时的基准。更换客户端后先加载一条参数明确、过去可用的记录，确认本地接入和规则链路正常，再测试新协议。若所有类型都同时失败，应优先检查配置是否启用、代理组是否选对和系统代理是否生效，而不是分别修改每条节点。这样能够减少把客户端接入问题误判为协议问题的情况。

三、Trojan 与 VLESS：认证、TLS 和外层传输

Trojan 把 TLS 会话作为重要基础

Trojan 的常见实现使用 TLS 承载代理通信，并在安全会话中完成密码认证和请求转发。配置通常包含服务器、端口、密码与服务器名称。它利用成熟的 TLS 机制提供传输保护，因此证书链是否可信、名称是否匹配和设备时间是否准确，都是连接成立的重要条件。仅确认密码正确，并不能排除握手阶段的问题。

服务器地址与 TLS 服务器名称可以承担不同职责。前者决定连接到哪里，后者通常影响服务端证书选择及客户端名称验证。有些部署使用地址连接、域名验证，订阅必须保留相应字段。若迁移时丢失服务器名称，客户端可能按另一名称验证证书，结果就是旧客户端正常、新客户端握手失败。这种差异不应直接归因于协议实现速度。

证书验证失败时，应先检查节点要求的名称、服务端证书和系统信任状态，不应把跳过证书验证当成常规修复。跳过验证会改变安全边界，也可能掩盖配置错误。若服务端使用专门的信任方案，应依据该服务的明确说明配置，而不是从不相关节点复制开关。错误日志中的名称不匹配、证书过期和连接超时也需要分别处理。

VLESS 的轻量认证不等于完整安全方案

VLESS 主要承担身份识别和代理封装，不应把它单独视为完整的加密传输方案。实际部署常与 TLS、REALITY 或其他外层机制结合，使用哪种组合由服务端决定。用户需要核对用户标识、传输方式以及配套安全参数。只看到 VLESS 就断言连接一定采用某种保护机制，或者认为所有 VLESS 记录都能被同一旧内核识别，都不准确。

部分 VLESS 记录带有 flow 设置，部分 REALITY 组合还涉及公钥、短标识与服务器名称。它们不是可有可无的备注，也不能在不同服务器之间互换。flow 的可用值与具体组合有关；把订阅中的字段删掉以换取成功解析，可能只让配置加载通过，却让真正的连接认证失败。需要确认的是组合支持，而非单独一个协议名称的支持。

WebSocket、gRPC 等传输也会改变连接建立与数据封装方式。路径、请求主机和服务名等字段若与服务端路由不一致，连接可能到达服务器却无法进入对应服务。此时错误表现与密码错误不完全相同。排查顺序应是服务器可达、TLS 或其他安全握手通过、传输路由正确，最后才检查代理认证，避免在多个层次同时修改参数。

连接复用与 UDP 能力不能只看协议标签

Trojan 的 UDP 转发在常见实现中会经由可靠字节流封装；VLESS 的 UDP 承载方式也取决于具体配置和实现。应用能否正常通话，除了协议允许之外，还受客户端转发方式和服务端支持影响。可靠流上的数据报可能受到丢包重传的排队影响，但这并不意味着它在所有实时业务中都不可用，仍需依据实际网络测试。

复用可以让多项请求共享底层连接，减少重复建立连接的成本，但共享也意味着故障和拥塞可能相互影响。某种复用选项并非所有服务端都接受，也不是打开后必然提高速度。对已有订阅，优先保持提供方给出的设置；若要比较复用效果，应固定同一节点和业务，只改变一项设置，并观察短请求、长连接和恢复过程。

选型时，Trojan 适合已有匹配 TLS 服务且希望参数关系清楚的情况；VLESS 则需要更仔细地确认外层组合与内核能力。两者不存在脱离服务端的通用优胜关系。若客户端只报告解析成功，仍应完成实际请求验证；若需要补充字段，先向订阅来源确认原始参数，不使用相似节点的内容拼凑一条看似完整的配置。

四、Hysteria2 与 TUIC：QUIC 的收益与边界

QUIC 改变的是传输组织方式

Hysteria2 和 TUIC 都利用 QUIC 构建代理传输。QUIC 运行在 UDP 上，将安全握手、流管理和拥塞控制放在自身协议中处理。相比把多个业务简单串在一条 TCP 字节流上，它可以在不同流之间减少由有序交付造成的部分相互等待。不过，不同流仍共享链路容量与拥塞状态，不能把多流理解成每个请求都拥有独立带宽。

当一条流丢失数据时，其他流未必需要等它完成有序交付，这是理解 QUIC 多流的重要角度。但网络发生整体拥塞、服务器出口饱和或无线链路质量变差时，所有流仍可能受影响。QUIC 也不是让底层丢包消失，而是用自己的确认、重传和拥塞算法应对路径变化。因此，持续传输优势必须结合路径条件讨论，不能只按协议名称排序。

由于底层依赖 UDP，当前网络必须允许相应数据报往返。有些网络可以正常访问普通网页，却限制某些 UDP 通信；此时 Hysteria2 与 TUIC 可能无法建立连接，或在空闲后恢复异常。排查时应先用一条已知可用的 TCP 类记录做对照，再切换网络测试，而不是不断增加超时值。超时只能延后报错，不能改变底层可达性。

Hysteria2：关注带宽参数与服务端约束

Hysteria2 面向代理传输提供认证、TCP 流和 UDP 转发能力，并包含与拥塞控制相关的设计。其可用带宽表现取决于实现、路径、服务端策略和所采用的控制方式。配置中的上传、下载带宽提示不等同于购买的套餐总量，也不是填得越大越好；不切实际的数值可能增加排队、丢包和其他应用的竞争压力。

部分配置会提供特定混淆选项，需要客户端和服务端保持一致。密码、混淆设置、TLS 名称与证书信任仍是不同层次，任何一项不匹配都可能导致失败。Hysteria 的不同代际也不能仅靠改写类型名称互通。若订阅来源明确标注 Hysteria2，应使用真正支持该协议的内核，并保留原始认证字段，而不是套用旧协议教程。

用户通常没有必要自行调整全部高级参数。先使用订阅提供方的配置完成连接，再根据可复现的现象讨论修改。例如持续下载使其他请求明显变慢，应先排除链路满载与服务端限速，再考虑带宽提示；若连握手都没有完成，则应检查网络与认证。把吞吐参数用于修复认证问题，通常只会增加变量。

TUIC：版本与数据报转发方式需要对应

TUIC 同样基于 QUIC，围绕代理连接和数据转发展开，并提供与认证、拥塞控制、连接保持和 UDP 转发有关的配置。不同协议代际或实现之间可能存在兼容边界，不能只凭 TUIC 四个字判断可互连。客户端内核需要支持服务端实际使用的协议格式，订阅转换器也必须正确输出相应的身份与认证字段。

UDP 转发模式会影响数据报怎样被封装以及如何处理可靠性。使用 QUIC 数据报的方式与借助可靠流的方式具有不同取舍，应用包大小、丢包容忍度和网络路径都会影响结果。若服务端只支持其中一种模式，客户端不能随意切换。实时应用表现异常时，应先确认服务端说明，再检查转发模式，而不是只观察网页探测是否通过。

QUIC 支持连接迁移等机制，但实际切换无线网络后能否保持业务，还依赖客户端实现、连接标识、服务器策略和系统网络接口变化。不能承诺从无线网络切到蜂窝网络时所有应用都不中断。对会议或远程会话，应实测网络切换与休眠恢复；若业务无法自动重连，还需要关注应用自身的恢复机制。

因此，选择 Hysteria2 或 TUIC 的合理起点，是已有对应服务、当前网络允许 UDP，并且实际业务在该路径下表现合适。它们不是给任何旧节点增加速度的开关，也不能替代服务器容量和良好的网络路径。若频繁遇到仅当前网络不可用的现象，应将问题归入路径兼容，而不是一概归入客户端配置损坏。

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

把首次连接与持续传输分开测量

首次打开页面可能依次经历域名解析、连接建立、安全握手、代理认证和目标服务响应。协议握手只是其中一部分。缓存命中、已有连接复用或应用预连接，都可能让第二次访问明显快于第一次。比较不同节点时，应分别观察冷启动与连续使用，不把一次已经复用连接的请求和另一条全新连接直接对照。

持续传输更受瓶颈带宽、拥塞控制、丢包和服务端资源影响。下载逐渐提速不一定是协议切换成功，也可能是连接正在扩大可用发送窗口；速度忽快忽慢则可能来自无线干扰、远端竞争或目标站点限制。若要区分，应在相近时段访问同一目标，并留意其他设备是否同时占用网络，不以不同站点的下载结果代替协议比较。

连接复用减少重复握手，却可能让多项业务共享故障域。一个大下载与多个短请求共用传输时，排队和调度可能影响交互体验。多流协议能够改善部分等待，但无法突破共享出口容量。对于日常办公，页面响应稳定、会话恢复正常往往比短时间峰值吞吐更重要，应把测试任务设成实际工作，而不是只跑大文件。

加密开销与设备实现共同决定资源需求

CPU 使用率受加密算法、硬件加速、内核实现、数据吞吐和连接数量共同影响。同一种协议在桌面处理器和低功耗设备上可能表现不同。额外封装、数据复制、用户态协议栈以及详细日志也会增加资源消耗。因此不能给出脱离设备的固定“最省资源协议”，更不能把某台电脑的结果直接推到手机或路由器上。

内存占用同样包含连接状态、缓存、规则集、DNS 数据和客户端界面等部分。启用 TUN 后，应用流量进入内核的路径发生变化，资源表现可能不同，但 TUN 本身并不把节点协议换成另一种类型。若更换客户端后耗电增加，应分别确认接管范围、后台常驻、日志级别和订阅更新频率，再判断是否与协议实现有关。

低功耗设备尤其需要避免长时间无意义的全量探测。自动检测大量节点、频繁刷新订阅和过密健康检查都会产生网络唤醒。即使每次请求的数据很少，持续让无线模块保持活跃也可能影响待机。先把检测范围缩到实际使用的代理组，并采用符合需求的检查间隔，比为了省电反复切换协议名称更容易获得可解释的结果。

移动端应同时测试待机与网络切换

手机的无线模块具有不同工作状态，连接保持和数据包唤醒会影响活跃时间。保活太频繁可能增加消耗，过于稀疏又可能让中间网络设备回收空闲映射。这是一种连接恢复与待机成本之间的权衡，不存在适合所有运营环境的固定间隔。使用订阅默认值后仍有问题，应记录熄屏时长、网络类型和恢复现象，再针对性调整。

系统后台策略可能暂停客户端，电池优化也可能限制网络活动。此时所有协议都可能在锁屏后表现异常。先检查客户端是否获得维持连接所需的系统权限，再核对是否由另一个 VPN 类应用接管。排查时可先在前台复现，再熄屏测试；若只有后台失败，重点应转向系统生命周期，而不是直接更改节点的加密方法或传输端口。

推荐建立一份简短测试记录，写明设备、网络、节点组合、任务和异常阶段，不需要记录敏感凭据。每轮只改变一项设置，并在相近使用条件下重复。若某种组合吞吐较高却造成持续发热，而另一种组合满足业务且待机恢复稳定，应优先后者。选型目标是满足具体需求，并非给所有协议排出一张永久有效的名次表。

六、Clash、Clash Meta 与 mihomo 的内核关系

沿用相似配置结构，不代表能力完全一致

Clash 原版建立了常见的 YAML 配置结构，包括代理条目、代理组、规则和 DNS 等部分。Clash Meta 在相关生态中扩展协议与功能，mihomo 则承接了这一分支的后续发展。名称变化容易让用户以为是三个互不相关的客户端，实际上这里主要讨论的是内核家族；图形客户端还会在其上提供配置管理和系统集成。

历史上的 Clash Premium 与原版开源内核也需要区分。某些旧教程以 Premium 的特定能力为前提，但不能据此认定任意名为 Clash 的程序都具备相同功能。迁移时应确认当前实际运行的内核名称与功能，而不是把旧客户端界面的每个开关逐项照搬。TUN、规则集与 DNS 的支持和默认行为，都应按目标内核及客户端集成方式检查。

mihomo 保留了大量熟悉的配置组织方式，并扩展了协议与网络功能，但兼容旧结构不等于兼容所有历史字段、私有扩展和错误写法。有些旧配置依赖宽松解析，有些功能已经改变默认行为。正确做法是让目标内核先完成配置检查，再分层验证运行结果；如果程序提示未知字段，应查明其来源，而不是认为忽略提示后功能仍然存在。

客户端显示的配置不一定就是最终运行配置

图形客户端可能把远程订阅、本地设置、覆写规则和运行时端口合并，再交给内核。用户编辑的文件只是来源之一。一个常见问题是订阅里写了某个端口，界面实际使用另一个端口；这不一定是内核不兼容，也可能是客户端设置具有更高优先级。排查时应查看运行配置或客户端提供的配置预览，确认最终生效内容。

规则顺序也会在合并过程中改变结果。代理条目能被识别，并不代表所有请求都会到达该条目；前面的规则可能已经选择直连或另一个组。迁移后网页出口变化，应检查命中的规则与组，而不是先换协议。DNS 与路由设置更应单独核对，因为解析结果和接管路径改变后，即使节点参数完全相同，访问行为也可能不同。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

上面仅展示本地入口与运行模式字段，不是一份包含代理服务的完整配置。混合端口供支持相应代理方式的应用接入；规则模式要求继续提供适用规则。把这些字段写入订阅后，仍可能被客户端界面设置覆盖，因此应以运行状态为准。它们也不会自动启用系统代理，更不会自动配置终端环境变量。

迁移时采用逐层恢复，而不是一次复制全部目录

建议先备份订阅地址、本地 YAML、覆写内容和需要保留的选择记录。随后在新客户端导入一份配置，确认节点与代理组，再验证 DNS、系统代理和 TUN。客户端数据目录可能包含缓存、数据库或与旧程序绑定的状态，不能认为整个目录复制过去就完成迁移。保留来源文件通常比保留所有运行缓存更有价值。

客户端选择可先从安装包页面的 Clash Plus 开始，再依据平台和配置习惯比较 Clash Verge Rev、FlClash 等选项。需要保留旧工作环境时，应避免两个客户端同时修改系统代理或同时启用 TUN。历史客户端可以用于理解旧配置，但不应只因界面熟悉，就忽略其维护状态与新协议兼容范围。

迁移后若只有某一类节点失败，应优先核对该协议新增或变化的字段；若所有节点正常但应用不走代理，应检查系统接入；若仅规则模式异常，则检查规则引用和组名。按层分类能减少无效尝试。有关家族关系与配置差异，还可阅读原版、Meta 与 mihomo 内核对照，将概念关系与实际运行日志对应起来。

需要特别注意，协议支持也可能受客户端附带内核的更新节奏影响。客户端程序更新与内核更新未必完全同步，界面存在某个入口，也不证明当前二进制支持全部选项。查看运行内核信息时应记录真实结果，但不必为了追求新名称而频繁替换。先确认目标功能确有需要，再按客户端支持的更新方式操作。

七、订阅格式与 YAML：能下载不等于能加载

先识别拿到的是哪一类内容

订阅地址只是获取内容的入口，不代表返回格式必然相同。常见内容包括完整 Clash YAML、仅包含代理条目的提供者文件，以及由分享链接组成或经编码处理的列表。完整配置可以定义规则与代理组；代理提供者通常负责加载节点集合。两者用途不同，不能把任意可下载文本直接放进同一个导入入口。

一条完整配置通常通过 proxies 定义本地节点，或通过 proxy-providers 引入外部节点，再由 proxy-groups 组织选择关系，最后由 rules 决定请求去向。提供者文件常见的是 proxies 列表，不一定包含运行所需的其他部分。若把提供者当完整配置启用，可能出现没有可用组或缺少规则的情况，这并不意味着节点密码已经失效。

分享链接则是另一种表示方式，字段可能经过编码，且不同协议有不同约定。订阅转换需要解析这些字段，再映射到目标内核语法。能够输出 YAML 只说明生成了文本，不证明路径、服务器名称、UDP 模式或安全参数都被保留。涉及复杂传输时，优先使用订阅来源明确提供的目标内核格式，减少中间转换造成的信息丢失。

提供者引用需要完整的依赖链

proxy-providers:
  my-sub:
    type: http
    url: "https://example.com/sub?token=xxxx"
    path: ./providers/my-sub.yaml
    interval: 86400

proxy-groups:
  - name: PROXY
    type: select
    use:
      - my-sub

rules:
  - MATCH,PROXY

这段示例说明提供者、代理组与最终规则之间的引用关系。示例域名和令牌是假值，不能直接获得节点；实际使用需替换成返回代理提供者格式的合法来源。interval 的单位是秒，表示计划更新间隔，而不是连接超时。path 用于本地缓存，具体落点由客户端运行目录和权限决定，不应假定所有平台都保存到同一位置。

这里的 MATCH 会将其匹配到的请求交给 PROXY，不是适用于所有需求的分流方案。真实配置若需要区分直连与代理，应在最终匹配规则之前添加相应规则。提供者名称、代理组 use 中的名称以及规则指向的组名必须一致。只更改显示名称却遗漏引用，会造成加载错误或规则无法找到目标，和节点协议本身没有关系。

从获取失败到连接失败，分开检查

订阅更新失败首先应检查是否取得正确响应。地址失效、认证失败、返回登录页面或返回错误说明，都可能让客户端得到非配置内容。不要把完整订阅地址贴到公开求助页面，因为查询参数可能具有账号访问能力。分享日志前应遮去令牌、账号和专用地址，只保留错误类型、返回内容类别和必要的配置结构。

成功取得文本后，再检查 YAML 语法与配置语义。缩进应使用空格，同级字段保持层次一致；包含特殊字符的值适合按语法要求加引号。语法通过只代表结构可解析，仍需确认内核认识协议类型、必填字段齐全、代理组引用存在。若提示某个协议不受支持，应回到内核能力检查，而不是反复调整无关缩进。

配置加载成功后仍可能出现单个节点连接失败。此时重点转向服务端可达性、认证与传输参数。反过来，订阅更新失败也不一定让已缓存节点立即不可用，已有配置可能仍在运行。应分别记录更新时间、当前启用配置和实际连接状态，避免看到更新提示便认定所有访问失败都来自同一个原因。

覆写同样有边界。替换一个完整列表与追加一条规则，产生的结果可能不同；客户端之间的合并策略也不一定一致。每次更换配置来源后，都应检查最终运行配置，尤其是组名和规则位置。关于远程订阅、本地文件与多份配置的管理方式，可继续阅读Clash Profile 与多配置管理，避免将更新行为误认为内核随机修改了配置。

八、按使用场景选择协议并验证结果

桌面浏览与移动使用有不同的优先级

日常桌面浏览应优先选择现有服务中稳定、参数完整且客户端支持的记录。SS、VMess、Trojan 或 VLESS 都可能满足需求，关键是实际路径和传输组合。若没有可复现的问题，不必为了追求一种协议更换全部配置。安装客户端可先考虑 Clash Plus，再到下载页按系统比较其他客户端；协议选择应在客户端兼容范围内继续进行。

移动端还要观察锁屏恢复、无线网络切换与后台限制。持续传输表现良好的 QUIC 类节点，在某个网络中可能遇到 UDP 可达性问题；TCP 类节点也可能因空闲连接被回收而需要重建。适合手机的配置，应同时满足前台访问和日常待机，不以刚打开客户端时的一次测试作为最终结论。

语音、会议和游戏需要关注应用的数据报转发、抖动与丢包，而不是只看文件下载。先确认应用是否被代理接管，再确认节点支持所需 UDP 转发。部分应用同时连接多个服务，其中登录成功不代表媒体通道正常。测试时应实际完成语音收发或会话建立，并留意持续使用和切换网络后的恢复。

服务器与低功耗设备先解决运行边界

服务器或路由器通常使用内核直接运行，需要自行处理启动服务、配置路径、权限和监听范围。它们与图形客户端的工作量不同，不建议仅为了减少一个界面就切换部署方式。设备处理能力有限时，先减少不必要的全量检测和复杂接管，再比较协议开销；无法正确处理流量入口的内核，即使协议支持齐全，也不会自动代理整个网络。

局域网共享还会引入新的访问边界。允许其他设备接入意味着需要确认监听地址、防火墙与认证策略，不能把本机可用直接等同于局域网可用。协议选择解决的是客户端到远端服务器的一段连接，局域网设备如何到达本地代理端口是另一段。出现其他设备无法联网时，应先检查本地接入，不必立即更换远端协议。

使用固定顺序定位问题所在层次

第一步确认配置成功加载，代理组里存在目标节点，并手动选中该记录。第二步观察日志，判断是解析错误、连接超时、认证失败还是安全握手失败。第三步确认应用确实经过客户端，可以通过连接页面或规则命中记录观察。若浏览器正常但终端异常，应转查接入方式，参考浏览器与终端系统代理排查。

第四步再做交叉比较：同一节点换网络，同一网络换不同传输类型，或同一配置换到确认兼容的客户端。每次只变更一个条件，并记录结果。如果只有 UDP 底层的协议失败，优先检查当前网络路径；如果某种安全组合始终失败，核对该组合字段；如果全部协议都正常探测而应用失败，则重点查看规则、DNS 和应用自己的代理设置。

DNS 问题尤其容易伪装成协议问题。目标域名无法正确解析、返回不可达地址，或者解析请求没有沿预期路径发送，都可能导致访问失败。客户端的 Fake-IP 与真实地址模式也会影响部分应用的行为。不要在没有记录的情况下同时切换 DNS 模式、TUN 和节点协议；应先确定域名解析是否成功，再确认后续连接去向。

最后保留一份已经验证的基准配置与必要备份。更换协议或覆写规则后，使用同一组任务复测，确认订阅更新后仍能加载。若发现改动没有改善，应恢复基准而不是继续叠加开关。需要逐步操作时返回快速上手，需要按错误现象查找分支时进入帮助中心。协议参考的作用，是缩小问题范围并解释取舍，而不是为所有网络提供同一组固定参数。

可靠的选型结论应能写成具体条件，例如当前设备、当前接入网络与既定应用下，某条记录连接稳定且恢复正常。这样的结论可以复测，也能在环境改变后重新评估。单独说某个协议最快、最省电或最适合全部用户，既忽略实现差异，也难以指导下一次排查。保留条件与验证过程，比记住一张没有边界的排名更有用。