Clash 协议与内核参考

01 / 判断顺序

协议选型的四层关系

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

客户端是用户操作的界面，负责导入配置、保存设置和申请系统权限；内核负责解析规则、建立连接和转发数据。协议则约定客户端与服务端如何认证、组织数据和处理传输。线路包含本地接入、途中路由与服务端出口。四层相互配合，却不能互相替代。换一个界面未必更换内核，换一个协议也未必改变出口，更不能据此推断所有应用都会变快。

例如，同一台服务器同时提供 SS 与 Trojan，二者仍可能共享处理器、出口带宽和上游路由。晚间拥塞时，两种协议都可能下降；若只看名称，容易把线路负载误判为协议缺陷。反过来，同一协议放在不同服务端，证书部署、拥塞控制、用户限速与连接数限制又可能不同。因此比较时应先确认测试对象是否共享线路，再讨论协议产生的额外成本。

把一个连接拆开观察

打开网页通常经历域名解析、连接建立、安全握手、请求发送和内容下载。节点测试展示的一个时间值，可能只覆盖其中几段，不代表页面完整加载时间。浏览器还会并发请求图片、字体和脚本，复用已经建立的连接。一次测试较快而网页较慢，可能是目标站点响应、解析位置或规则选择不同，不应直接归因于加密算法复杂。

传输层也要与代理协议分开理解。TCP 提供可靠、有序的字节流，丢失的数据需要重传；UDP 提供数据报，不自行保证有序交付。QUIC 运行在 UDP 之上，加入加密、可靠流与拥塞控制，并非简单地取消可靠性。某个节点支持 UDP 转发，也不等于该节点自身使用 QUIC；应用的数据类型和客户端到服务端的承载方式是两个维度。

建立可复现的比较条件

比较前记录设备、接入网络、代理模式、目标网站与测试时间。尽量选择同一出口，关闭其他设备的大流量任务，先用正常网页确认连接可用，再测持续下载和交互响应。每次只改变一个变量，例如保留规则与 DNS 设置，仅切换协议。多次重复并记录波动范围，比只保存最好的一次结果更能反映日常体验，也能避免把短时缓存当成优势。

安全判断同样需要分层。传输加密保护的是相应链路，不会自动改变服务端运营者的权限，也不代替网站自身的 HTTPS。网站证书仍应由应用正常验证。节点中的服务器名称、证书名称与实际连接地址可以不同，但必须符合部署关系。遇到证书报错应核对名称、时间与信任链，而不是为了连通就关闭验证。

实际选择可按兼容性、稳定性、资源消耗、峰值吞吐的顺序进行。先排除设备不支持或网络不允许的类型，再看长时间使用是否稳定，最后在可接受的电量与流量成本内比较速度。如果目前配置已经满足网页、会议和文件传输需求，没有必要仅因协议较新而迁移。后文的差异用于缩小候选范围，不是给协议排列固定名次。

02 / 成熟协议

SS 与 VMess 的设计取舍

SS：紧凑的数据转发结构

Shadowsocks，通常写作 SS，围绕加密代理转发展开，协议结构相对紧凑。它的设计重点不是在协议里包办复杂路由，而是完成客户端与服务端之间的数据保护与目标转发。规则匹配、策略组和应用接管仍由客户端与内核完成。因实现广泛，SS 常用于对兼容性和部署简洁度有要求的环境，但不同实现支持的加密方法并不完全相同。

判断 SS 配置时，至少要同时核对服务器、端口、加密方法和密码。加密方法不是客户端可任意优化的本地选项，必须与服务端一致。较早的流加密方式与后来的 AEAD 方案不能视为同一种配置；SS 2022 又有单独的规范与密钥要求。订阅只写 SS 并不足以确认可用，还需要查看具体方法是否被当前内核支持。

常见 AEAD 实现会提供 AES-GCM 或 ChaCha20-Poly1305 一类选择。带有硬件加速的处理器可能更适合某些 AES 实现，另一台低功耗设备则可能表现不同。不能根据算法名字直接推断手机续航，也不宜单独更改订阅中的方法来试速。如果服务端提供多个配置，应在相同线路和实际负载下比较，并关注处理器占用是否持续偏高。

VMess：认证与传输配置分层

VMess 来自 V2Ray 生态，包含用户认证和数据保护机制，并经常与不同传输方式组合使用。用户界面中的 VMess 节点可能承载于普通 TCP，也可能组合 WebSocket 或其他被实现支持的传输。额外的 TLS 层、反向代理和路径配置都会影响连接过程。因此两个都标为 VMess 的节点，在握手步骤、服务端拓扑和故障位置上可能差别很大。

VMess 配置通常涉及用户标识、安全方式和传输参数；较旧资料中的兼容字段不能直接套用到现有实现。协议认证对时间同步有要求，设备时钟明显偏离时，可能出现网络正常而认证失败的情况。遇到持续失败，应先启用系统自动校时，确认服务端信息仍有效，再查看内核日志。不应把认证错误误认为 DNS 问题而反复更换解析服务器。

插件和封装不能只看节点名称

部分 SS 配置依赖额外插件，分享链接可能通过参数描述插件名称及其选项。客户端能导入基础 SS 信息，不代表能执行对应插件；有的只支持少数兼容实现，有的完全不提供插件入口。VMess 也有类似情况：订阅解析成功只证明字段可以读取，实际的传输组合仍须由内核实现。选型时应要求提供方明确组合，而不是只问是否支持 SS 或 VMess。

这两类协议都不能凭名称保证应用 UDP 可用。客户端的 UDP 开关、内核支持、服务端转发设置以及中间网络都可能成为限制。网页正常而语音或游戏异常时，可先查看应用流量是否命中预期策略，再核对 UDP 转发条件。盲目切成全局模式可能掩盖规则问题，却不会补齐服务端缺失的能力。

已有稳定 SS 配置的用户，可以优先保留成熟组合，重点检查加密方法与插件兼容；已有 VMess 配置的用户，应特别留意传输字段、时钟和订阅来源。新建环境不必为了追求某个协议标签而叠加多层传输。每增加一层，就多出一组需要保持一致的参数，也增加证书、路径或反向代理配置出错时的定位成本。

03 / TLS 与认证

Trojan 与 VLESS 的组合边界

Trojan：以 TLS 保护传输

Trojan 的常见部署把代理认证和数据转发放在 TLS 连接中，利用成熟的 TLS 实现保护链路。对用户而言，节点是否能用不仅取决于密码和端口，还取决于服务器名称、证书链以及服务端 TLS 配置。它的设计可以复用既有证书与服务器维护经验，但这不意味着只要端口开放就能连接，也不意味着所有标为 Trojan 的扩展实现可以相互替换。

连接地址是客户端实际拨号的位置，SNI 是 TLS 握手时声明的服务器名称，证书验证还会判断名称与信任关系。这些值有时相同，有时因部署方式不同而分开。订阅中若提供了服务器名称，应按服务端要求保留，不能因为地址是 IP 就直接删掉。证书到期、设备时间错误、名称不匹配与链不完整，都可能在代理认证之前使连接结束。

Trojan 运行在 TCP 与 TLS 的常见组合上，首次连接需要经历相应的连接建立过程。复用连接能减少重复建立的成本，但实际效果取决于客户端、服务端及应用请求模式。浏览器访问多个站点时，连接组织方式也会改变体感。不能把某次冷启动等待直接解释为协议持续速度慢，更不能用单次下载峰值证明网页首开一定更快。

VLESS：认证层不等于完整安全方案

VLESS 同样源自 V2Ray 相关生态，主要聚焦认证与转发，协议本身不提供与 VMess 相同的数据加密层。实际部署通常依赖 TLS 或其他受支持的安全传输组合。看到配置中的加密字段为空或表示不额外加密，不能立刻认定连接没有保护；需要继续检查外层安全配置。相反，若外层没有建立有效保护，也不能仅凭 VLESS 名称认为链路天然安全。

VLESS 的现实兼容性经常由组合参数决定，例如传输类型、TLS 设置以及服务端要求的 flow。某些部署还使用 REALITY，这属于必须单独核对的安全握手方案，不是普通 TLS 字段换个名称。公钥、短标识、服务器名称及客户端支持情况均需匹配。错误地混合两套示例，可能在导入时通过语法解析，却在连接时始终失败。

传输名称相同，也需要核对细节

WebSocket 组合需要核对路径、请求头与反向代理转发关系；gRPC 组合可能涉及服务名称及 HTTP/2 配置。路径通常区分具体字符，尾部斜线的变化也可能影响服务端路由。连接被接受后马上断开，不一定是用户凭据错误，也可能是请求到了错误的后端。应先看 TLS 是否完成，再查传输层是否建立，最后检查协议认证。

部分参数主要用于客户端兼容特定的服务端握手行为，不能被当作普适的加速开关。多路复用也需要关注协议组合是否支持、连接如何隔离以及服务端限制。把许多请求集中在少量连接中，可以减少握手，也可能让一个受损连接影响更多请求。默认设置已经可用时，先保留默认，只有在可复现的问题下才比较修改前后的差异。

实际选择上，已有规范证书与明确部署说明的 Trojan 配置通常容易按层排查；VLESS 则应把完整组合视为一个整体核对。初学者不宜手工拼接不同文章中的参数。优先使用提供方为当前内核生成的完整配置，保留原始文件作为对照。如果客户端提示未知字段，应先判断内核能力，而不是删除字段后把导入成功当成问题解决。

这两种协议都可能适合日常网页与长连接业务，但不能承诺哪一种总是更省电。外层传输、握手频率、连接保活和无线信号往往比认证层差异更显著。想比较移动端表现，应保持接入点、应用与后台权限一致，并观察待机和使用两个阶段，避免把信号变化或系统后台清理误判为协议本身的特点。

04 / UDP 承载

Hysteria2 与 TUIC 的网络条件

共同基础是 QUIC，而非任意 UDP

Hysteria2 与 TUIC 都采用基于 QUIC 的设计，目标之一是改善特定网络条件下的代理传输体验。QUIC 将可靠流、加密与拥塞控制放在用户态协议实现中，底层使用 UDP 数据报。这使它们具备不同于传统 TCP 组合的调度空间，但前提是本地接入、中间路径和服务端都允许相应 UDP 通信。UDP 被限制时，协议名称再合适也无法发挥作用。

QUIC 的不同流之间不必像同一 TCP 字节流那样共同等待有序交付，能够减少某些跨流等待。但所有流依然共享可用带宽与拥塞状态，丢包仍然需要恢复，也不可能凭空扩大物理链路容量。网络拥塞、无线重传和服务端处理不足依然会影响体验。把 QUIC 理解为不怕丢包或不受延迟影响，会导致错误的调参预期。

Hysteria2：带宽信息与拥塞策略

Hysteria2 是独立于早期 Hysteria 的协议代际，不能把旧配置只改类型名称就直接使用。其设计关注高延迟或有损网络上的吞吐能力，并提供不同的拥塞控制路径。部分部署会使用带宽相关配置，这些数值表达预期条件，而不是测试结果。客户端与服务端支持的策略、服务端限制以及是否提供带宽信息，会共同决定实际行为。

手工填写带宽时，应参考当前接入网络可以持续达到的能力，而不是宽带套餐标称值，更不能把数值填大当作提速按钮。高估可能引起排队、丢包或争抢带宽，使同一网络内的会议和网页响应恶化；低估也可能限制吞吐。频繁在蜂窝与无线网络之间切换的设备，环境变化很大，宜先使用提供方建议或实现默认设置，再进行受控比较。

TUIC：连接组织与实现兼容

TUIC 也基于 QUIC，包含认证、连接复用和数据转发机制。实际使用需要注意协议代际与实现参数是否一致，不能因为订阅都显示 TUIC 就忽略兼容边界。用户标识、密码、拥塞控制和 UDP 转发相关选项需要按服务端说明设置。不同内核对可选字段的支持可能不同，参数能被界面保存并不代表已经传递给底层实现。

一些 TUIC 实现提供降低重复握手等待的选项，包括与早期数据有关的机制。此类机制受会话恢复、服务端策略及安全边界约束，不是每次启动都能立即受益。涉及早期数据时，还要考虑重放风险与请求语义。普通用户无需为减少一次连接等待而自行开启所有相关选项，优先使用服务端明确支持并经过验证的组合。

把 MTU 与网络切换作为边界条件

隧道封装会增加数据开销，可用路径 MTU 因接入方式而变化。若小请求可用而较大传输反复停顿，可以结合日志检查数据报大小、路径探测及分片相关问题。不过 MTU 不是所有超时的通用答案，错误的证书和认证不会被降低 MTU 修复。只有在确认握手成功、服务端可达后，才有必要沿着传输大小与路径兼容方向继续排查。

网络切换后的表现也取决于实现。QUIC 具有连接迁移相关机制，但代理客户端、服务端与操作系统未必在所有情况下都保持原连接。蜂窝切换、休眠恢复和地址变化后，仍可能需要重连。应分别测试锁屏恢复、接入点切换和长时间下载，而不是只看首次启动。对移动端而言，稳定重连往往比一次测试的峰值更重要。

如果网络允许 UDP，设备处理能力充足，且现有 TCP 组合在有损路径上表现不佳，可以把这两类协议纳入候选；如果所在网络经常限制 UDP，应准备已经验证的 TCP 类配置。它们适合解决特定条件下的问题，而不是替代所有协议。实际比较仍应保持出口接近，避免将服务端线路优势误记为 QUIC 的普遍优势。

05 / 体验衡量

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

首开响应与持续吞吐分开测

连接速度至少包含两种体验：从点击到收到首个有效响应的等待，以及连接建立后持续传输的能力。前者受到解析、握手和目标站响应影响，后者更受带宽、拥塞控制和服务端负载影响。协议可能在其中一项占优而另一项接近。短网页、视频缓冲与大文件下载的需求不同，不能用一个测速文件的结果代表所有应用。

冷连接和热连接也应分开。冷连接可能需要重新解析域名、完成 TLS 或 QUIC 握手；热连接则可能复用既有会话。测试前是否重启客户端、浏览器是否已有缓存、连接池是否仍有效，都会影响结果。若为了观察真实首开，可以在相同条件下重新建立连接；若关注日常浏览，则应保留自然复用，避免把人为清空状态后的成本放大。

资源占用没有固定协议榜单

处理器成本来自加密、数据复制、协议栈处理、规则匹配和日志记录等环节。硬件加速、操作系统网络接口与内核实现会改变结果。内存占用则与连接数量、缓冲区、规则规模和缓存相关。一个客户端空闲时占用较低，不代表高并发转发时仍然较低；一个协议额外封装较少，也不能保证带有复杂规则的整体配置更轻。

观察时先区分界面进程与内核进程。桌面客户端界面可能基于不同技术实现，窗口打开与关闭时的占用不一定相同。用任务管理器看单个进程容易漏掉实际转发者。手机则应结合系统电池统计、屏幕时间和后台运行时长判断，不能用一次短测时温度上升就给协议下结论，尤其是在设备同时下载更新或进行媒体处理时。

无线唤醒与后台保活

移动端耗电不只是加密消耗。无线模块发送少量数据后可能继续维持活跃状态，频繁心跳、健康检查和自动更新会增加唤醒。信号较弱时，重传与发射功率变化也可能放大耗电。若设备待机仍明显消耗，应先检查定时任务和连接保活频率，再比较协议；单纯更换认证方式，往往无法消除由后台轮询引起的持续活动。

策略组自动测试应与实际需求匹配。过短的测试间隔、过多的候选节点与频繁切换，会产生额外请求，也可能打断已有连接。需要自动选择时，可先减少不使用的候选项，观察默认间隔是否满足需求。关于自动策略组的选择逻辑，可继续阅读url-test、fallback 与 load-balance 对照，不要把它们当作相同的自动测速功能。

TUN 模式可能覆盖更多应用流量，系统代理则依赖应用读取代理设置，因此二者的总处理量可能不同。比较耗电前必须固定接管方式，否则是在比较两套流量范围。Android 的 VPN 服务与后台限制、iOS 的网络扩展管理也会影响连接生命周期。允许必要后台运行有助于稳定，但不应为了单个客户端关闭所有系统节能措施。

建议用相近时长分别记录正常使用与锁屏待机，并重复多个周期。排除系统更新、热点共享和信号变化后，才判断某个配置是否持续更耗电。需要优化时，先减少无用测试、过细日志与重复服务，再评估协议。网速问题可参考节点、线路与本地设置的分层排查，电量问题则应同时查看设备本身的统计证据。

06 / 实现能力

Clash、Meta 与 mihomo 的关系

配置传统相近，不代表能力相同

Clash 最初建立了广泛使用的代理配置与规则生态，许多客户端沿用其 YAML 结构和控制接口。Clash Meta 在这一生态基础上扩展了协议与网络功能，mihomo 则延续了 Meta 内核的维护脉络。实际资料中仍会出现 Meta、Clash Meta 或 mihomo 等称呼。阅读教程时应确认指的是内核、客户端还是订阅格式，避免把历史名称当作独立且完全兼容的产品。

原版开源 Clash、曾经提供额外功能的 Premium 分支，以及 Meta/mihomo，并不是功能范围一致的同一实现。某个旧教程在一种内核上可以运行，不代表另一种也支持相同的 DNS、TUN 或规则提供器字段。历史客户端还可能捆绑固定内核，界面能继续打开，并不能说明其实现能力仍适合新的订阅。应以正在运行的内核信息和实际文档为准。

先查内核，再查界面功能

桌面客户端通常在关于、设置或日志中显示内核名称与启动信息。核对时不要只看客户端标题，也不要只看安装包名称。部分客户端允许切换内核或更新内核，切换后应重新确认运行信息。若客户端自行生成运行配置，还需要了解界面设置是否覆盖了导入文件中的 DNS、端口或 TUN 字段，避免误以为编辑订阅就一定改变了实际运行状态。

协议支持只是能力的一部分。规则类型、规则集格式、域名解析模式、虚拟网卡实现以及外部控制接口的行为，都可能影响体验。两种内核都能识别同一节点，也可能因为默认 DNS、路由优先级或连接处理不同而表现不同。迁移时应先保留最小可用配置，确认基本转发，再逐步加入原有规则，不能只以启动成功判断所有功能迁移完成。

平台能力与归档客户端

本站 Windows 下载范围还包括 Clash Nyanpasu 与已停止维护的 Clash for Windows；macOS 包含已停止维护的 ClashX Meta；Android 包含 Clash Meta for Android 与 Surfboard；Linux 提供 Clash Verge Rev 和 FlClash。它们并非同一套界面的不同皮肤。尤其是 Surfboard，应按自身支持的配置体系使用，不能因为同处 Android 下载区就推断它能直接读取完整 Clash YAML。

iOS 入口提供 Clash Plus 的 App Store 页面，官网为clashplus.io。移动系统对网络扩展、后台运行和接管方式有独立约束，不能机械照搬桌面教程的系统代理或服务安装步骤。跨平台迁移时，先核对客户端支持的订阅类型和协议组合，再确认系统权限。账户凭据相同，也不意味着所有平台都应使用完全相同的运行配置。

迁移采用逐层恢复，而非整份替换

从旧内核迁移前，保存原始订阅与本地覆写，并记录模式、DNS 和接管方式。先用少量节点确认认证与传输，再加入策略组，接着恢复规则提供器，最后启用 TUN 等系统级功能。每完成一层都测试一次网页、域名解析和必要的应用连接。这样遇到问题能退回上一层，而不必在完整配置中同时寻找多个不兼容字段。

内核面向服务器或路由器部署时，还要负责启动管理、监听范围与权限控制。外部控制接口不是公共服务入口，应限制在可信本机或必要的受控环境，并按部署要求配置访问保护。普通用户优先选择图形客户端，通常更容易管理系统代理和权限。只有在明确需要自动化运行、服务管理或路由器接管时，才直接使用内核并维护相关系统配置。

07 / 配置交换

订阅格式与配置兼容性

分享链接、节点列表与完整配置

订阅是配置的交付方式，不是代理协议。一个订阅地址可能返回完整 Clash YAML，也可能返回编码后的分享链接列表，或者返回供某种客户端使用的专有格式。分享链接通常描述一个节点，完整配置还可能包含策略组、规则、DNS 和监听端口。两者信息量不同，不能因为文件能被下载，就判断导入后一定具备完整的分流逻辑。

完整 YAML 中，节点通常位于 proxies，策略组位于 proxy-groups，规则位于 rules；使用提供器时，还可能引用 proxy-providers 或 rule-providers。客户端导入后，可能把它保存为配置档，也可能提取节点后重新生成配置。应先明确导入入口期待哪一种内容。把节点列表填入完整配置入口，可能触发缺失字段错误，也可能只得到没有预期规则的运行状态。

转换不是补齐功能

订阅转换可以改变字段表达与目标格式，却不能让内核突然支持原本不支持的协议。某些分享格式无法完整表达传输细节，转换过程中可能丢失插件、路径、UDP 或特殊握手参数。转换结果可以通过语法检查，也可能在实际连接时失败。应优先索取目标客户端可直接使用的订阅，确需转换时保存原始输入，并逐项核对复杂节点。

订阅链接往往包含访问标识，取得链接的人可能能够读取相关配置。不要将完整地址放进公开截图、问题帖子或不熟悉的在线转换页面。求助时只展示已经去除凭据的错误信息、协议类型与相关字段名称。需要本地转换时，应明确工具的数据处理方式；仅仅把链接换成短地址，并不会改变其本身具有访问能力的事实。

用小片段理解规则引用

下面是可并入配置的规则片段，用于展示从上到下匹配和内置 DIRECT 策略的写法。它不包含代理节点，也不是完整订阅；其中的示例域名只用于说明语法。真实分流应按应用需求调整，不能直接用这一小段替换现有全部规则。对于已建立的连接，修改规则后未必立即改变去向，验证时应创建新的连接。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,DIRECT

规则里的策略名称必须引用实际存在的策略组或内置策略，名称差一个字符就可能解析失败。订阅更新后若节点被重命名，按名称筛选的策略组也可能变空。对于提供器，还要确认资源是否下载成功、返回格式是否正确。只检查主订阅更新成功，不能证明所有外部规则集与节点提供器都已正常加载，日志中应分别查看相关结果。

覆写、更新与解析错误

许多客户端提供覆写、合并或扩展配置功能，使本地规则不被订阅更新覆盖。它们的合并顺序不同，有的替换整段，有的追加列表，有的通过脚本生成结果。使用前先确认最终运行配置在哪里查看，修改后核对实际结果。不要在来源订阅与覆写层同时维护两份相反的 DNS 设置，否则下一次更新很难判断哪一层真正生效。

YAML 错误常来自缩进、制表符、列表层级与包含特殊字符的值。订阅地址返回登录页或错误页面时，也可能被误报为配置解析问题。排查应先确认响应确实是所需配置，再按日志定位行与字段；不要把整个文件粘贴到公开校验工具。更新失败时保留最近一次可用配置，并区分网络获取失败与获取后解析失败，这两类问题处理路径不同。

GeoIP 与 GeoSite 等数据还属于规则运行依赖，不等同于节点订阅。配置已更新而数据库未能加载时，部分规则仍可能异常。可继续查阅GeoIP 与 GeoSite 数据库更新说明。管理订阅的目标应是可追踪：知道内容来自哪里、本地修改在哪一层、失败后如何恢复，而不是不断更换导入方式直到偶然连通。

08 / 落地选择

按场景选型与分层排查

桌面日常与移动设备

桌面日常浏览优先考虑完整订阅兼容、连接稳定和维护方便。可从 Clash Plus 开始，按系统与操作习惯比较其他客户端，再使用服务端已经验证的协议组合。若现有 SS、Trojan 或 VLESS 配置表现稳定，不需要为了名称更新而换协议。会议、开发工具与浏览器并存时，应分别验证规则命中，确保工作流所需连接没有被误分到其他策略。

移动设备需要把接入变化和后台恢复放在前面。通勤时的信号波动、蜂窝与无线网络切换、锁屏后的系统限制，往往比峰值速度更影响体验。候选协议应测试启动、待机、恢复和切网四种状态。若 QUIC 类配置在当前网络稳定，可以继续比较电量；若 UDP 经常不可达，则优先保留经过验证的 TCP 类配置作为日常选择。

大文件、实时应用与受限网络

大文件传输应关注持续吞吐与对其他业务的影响。先确认源站与出口没有限速，再比较协议，不宜用多个并行下载把网络占满后评价网页响应。Hysteria2 的带宽设置或其他拥塞策略，需要与实际链路相符。若同一家庭网络正在开会，稳定的排队表现通常比单次跑满更有价值；协议不能代替路由器的合理带宽管理。

语音、游戏或其他实时应用需要检查应用自身是否使用 UDP，以及该流量是否被客户端接管和服务端转发。较低的节点测试时间不等于较低的游戏内延迟，因为测试目标和游戏服务器可能不同。先看连接日志中的目标与策略，再判断是否需要更换线路。对 UDP 限制明显的网络，也不要假定切换到另一种基于 QUIC 的协议就能解决基础可达性。

按失败阶段定位，而非连续换节点

完全无法连接时，先确认本地网络、服务器地址解析与端口条件，再检查证书或协议握手，最后检查认证。握手成功但网站打不开时，继续查看规则命中、出口连通与 DNS。只有部分应用失败时，优先判断接管范围和 UDP 条件。每次保留一条完整错误及发生时间，避免在同一轮里同时切换模式、修改 DNS、开启 TUN 和更换协议。

域名打不开而 IP 相关测试可用，可能提示解析链路异常，但直接访问 IP 不一定是有效的网站测试，因为 HTTPS 需要正确名称。应在客户端日志中确认域名查询与实际连接，而不是关闭证书检查。Fake-IP 模式下，应用看到的合成地址也不等于服务端地址异常。相关原理与常见处理可从常见问题继续查阅，先辨认机制再修改设置。

把结论写成适用条件

一份有用的比较记录应写清在哪台设备、哪种网络、什么时间段、访问什么业务时更稳定，而不是只写某协议更快。若测试对象不共享线路，就把结论限定为这两个节点的体验，不上升为协议结论。持续失败也要区分可达性、认证、解析和出口问题，这样向服务提供方反馈时，才能给出可复现信息，而不必暴露完整订阅。

后续维护不需要每天重调全部参数。订阅更新、系统升级或切换网络后，运行一组简短检查即可：网页解析正常、常用应用连通、必要的 UDP 业务可用、锁屏恢复符合预期。要理解模式切换的影响，可阅读规则、全局与直连模式差异；需要重新完成安装流程时，返回教程按主线操作。

最终选择应同时满足四点：当前客户端能实现完整协议组合，服务端参数明确且有效，所在网络允许对应传输，设备资源与电量成本可以接受。满足这些条件后，才比较性能细节。对于服务器与路由器，再增加权限、监听范围和重启恢复检查。这样得到的是可维护的配置方案，而不是依靠一次测试或某个协议名称做出的临时判断。