Clash 协议与内核选型

内核家族与客户端分工

Clash、Meta 与 mihomo 的关系

Clash 最初建立了以 YAML 配置描述节点、策略组和规则的工作方式。它把应用连接送入统一的路由流程，再按规则决定直连、代理或拒绝。原版开源项目已经归档，历史上的开源内核与 Premium 分支也并非完全相同的功能集合。因此，看到配置标注“适用于 Clash”，不能直接推断所有名称相近的客户端都能读取，更不能推断支持当前出现的每一种协议。

Clash.Meta 在这一配置体系上发展了协议、DNS 和路由能力，后续以 mihomo 名称继续维护。网络教程里的 Meta、Clash Meta 与 mihomo，经常指向同一条内核演进路线，但不同时间写成的教程可能描述不同阶段的行为。遇到新协议、规则参数或 DNS 字段，应该确认当前运行内核的实际能力，而不是只按文章标题里的名称判断兼容性。旧示例可以帮助理解结构，却不能替代当前字段说明。

界面负责管理，内核负责处理连接

客户端是管理入口，内核才执行协议握手、域名解析、策略选择与连接转发。Clash Verge Rev 提供桌面配置管理和连接查看界面；FlClash、Clash Meta for Android 等客户端也有自己的交互和系统集成方式。同一内核在不同界面中，设置名称、配置合并顺序和权限申请路径可能不同。客户端能启动，不代表订阅里的所有节点都已被内核接受；配置导入成功，也不代表每个节点都能完成认证。

跨平台选型可先查看首推的 Clash Plus，再根据所需功能比较其他客户端。Clash Plus 的平台覆盖不等于各平台内部实现完全相同，也不应仅凭产品名称推断其具体内核。需要桌面规则查看与覆写管理时，可进一步评估 Clash Verge Rev。安装包页列出了可选客户端；其中 Clash for Windows、ClashX Meta 已停止维护，阅读历史资料时需要把归档客户端与仍在演进的协议能力分开。

先确认正在运行的内核

打开客户端的设置或关于页面，查找内核名称；若界面只显示客户端信息，再查看启动日志中的内核标识。区分稳定通道与 Alpha 通道：后者通常用于验证较新的改动，不是连接性能自动提升的开关。日常使用优先保持稳定环境，只有明确遇到某项已修复的问题、或者需要验证特定能力时才测试其他通道。更换之前保留配置备份，避免把通道变化与订阅更新同时引入，导致故障来源难以分辨。

迁移时先检查配置能否通过解析，再看节点能否建立连接，最后看规则是否按预期命中。这三个阶段分别对应字段支持、协议互通和路由逻辑。共享 YAML 风格只意味着结构相近，并不保证字段、默认值和扩展功能完全一致。若旧配置依赖脚本、特定规则提供器行为或客户端专用占位机制，需要逐项确认替代方案；不要为了让解析通过而批量删除未知字段，否则可能留下能够启动但行为已经改变的配置。

SS 与 VMess：基础封装的取舍

Shadowsocks 的简洁结构

Shadowsocks，通常简称 SS，采用客户端与服务端共享密钥的方式建立加密代理。它的早期设计侧重较小的协议开销与直接的部署结构，不强制把每条连接包装成完整的 TLS 会话。对用户而言，最常见的参数是服务器地址、端口、加密方法和密码。参数少不代表可以互换：服务端采用什么加密方法，客户端就必须使用对应方法，密码相同却选错算法，依然无法正常通信。

现代部署应区分旧式流加密、AEAD 加密与 Shadowsocks 2022 系列。AEAD 把加密与消息认证结合起来，使接收端能验证数据是否被改变；2022 系列还调整了密钥和会话处理方式。它们不是给旧节点随意勾选的“加强模式”。某些方法需要符合长度要求的编码密钥，不能拿普通口令直接替代。订阅中出现具体的加密方法时，先确认当前内核支持该方法，再核对服务端参数，切勿为了通过输入框而手工改成另一个名称。

SS 可以处理 TCP，也可以在双方支持并启用时转发 UDP，但两者走的是不同的处理路径。网页能打开而语音连接失败，可能只是 UDP 没有端到端打通。插件又是另一层扩展：部分 SS 部署通过额外插件封装流量，客户端必须支持相同插件和选项。支持 SS 本身，不等于支持任意插件组合；迁移节点时漏掉插件字段，常表现为地址与密码看似正确，却在建立连接后立即断开。

VMess 的认证与传输组合

VMess 来自 V2Ray 生态，围绕用户标识、认证和数据传输设计，常用 UUID 作为身份参数。它与 SS 的差异不只是把密码换成 UUID，而是认证和封装方式不同。VMess 可以配合不同传输使用，因此同样标为 VMess 的两个节点，可能一个使用直接 TCP，另一个使用 WebSocket 与 TLS。连接过程、证书要求和中间设备兼容性会随之变化，不能把某一次测试结果推广到所有 VMess 节点。

检查 VMess 节点时，需要同时核对身份参数、传输类型、TLS 是否开启，以及路径或服务名等扩展字段。VMess 的认证还与时间有关，设备系统时间偏差可能导致认证失败；出现此类报错时先恢复自动校时，再检查账号。历史教程中还可能出现与旧认证方式有关的参数，新配置通常采用现代 AEAD 用法。不要只为模仿旧截图而添加历史字段，也不要把客户端接受某字段等同于服务端仍使用该机制。

怎样在现有节点中做选择

如果需求是普通网页与文件传输，服务端条件相近时，SS 的配置结构通常更容易核对，故障变量也相对少。若既有服务使用 VMess，且参数完整、运行稳定，没有必要只因协议名称较早就迁移。加密成本还取决于设备处理器和算法实现：具有硬件加速的桌面设备，与低功耗路由器的表现可能明显不同。不能仅按协议字段数量估算性能，更不能把协议的出现顺序当成质量排序。

实际比较应先固定同一设备、同一接入网络与相近的服务端区域，再分别检查连接建立、持续传输和 UDP 应用。若两个节点来自不同线路，线路差异往往比协议差异更大。记录失败发生在解析、认证还是传输阶段，会比反复切换加密方法更有帮助。参数不确定时回到订阅提供方核对；不要把试错后的配置覆盖订阅原件，否则下次更新可能恢复原参数，让问题看似反复出现。

Trojan 与 VLESS：认证和传输分层

Trojan 将认证放在 TLS 连接内

Trojan 的常见实现建立在 TLS 之上，把代理认证与请求放入受保护的连接中。TLS 负责传输加密和服务端身份验证，Trojan 负责确认用户是否有权使用代理。它的设计取舍是利用成熟的 TLS 生态，同时保留相对直接的代理请求结构。节点通常包含服务器、端口、密码与服务器名称；看起来字段不多，但证书、域名与服务端监听配置需要彼此对应，否则连接会在认证之前就失败。

服务器地址与 TLS 服务器名称不是同一个概念。地址决定向哪里建立连接，可以是域名或 IP；服务器名称通常参与 SNI 发送与证书名称验证，告诉服务端要使用哪个站点配置。订阅提供了专门的服务器名称时，应保持该值，而不是随手改成地址栏里的 IP。证书过期、证书链不完整或名称不匹配，都应在服务端或正确的配置位置修复，不应把关闭验证作为常规兼容步骤。

Trojan 并不保证比其他协议更快。新连接需要完成底层连接与 TLS 握手，实际耗时受往返时间、会话恢复和客户端复用行为影响。常见 Trojan 用法通过 TCP 隧道承载代理数据，UDP 转发也需要检查双方实现与配置支持；不能因为应用使用 UDP，就推断节点在外层也使用 UDP。协议名称描述的是代理层，实际网络表现还受其外层传输影响，这是理解节点差异的重要分界。

VLESS 把轻量认证与外层安全分开

VLESS 来自 V2Ray 相关生态，采用较精简的身份认证与请求结构。它本身不提供类似 SS 的独立内容加密，通常需要 TLS、REALITY 等外层机制保障传输。把 VLESS 看作“没有加密所以更快”会漏掉完整连接栈：实际节点可能包含认证、传输封装、加密握手和其他流量处理。应比较完整组合，例如 VLESS 加 TLS 与某种传输，而不是只比较配置里的类型名称。

REALITY 是与特定服务端部署配套的安全机制，不是随意附加在任何 VLESS 节点上的选项。使用时需要正确的公钥、短标识、服务器名称及相关握手参数，具体字段随客户端实现而异。公钥错误和 UUID 错误属于不同阶段的问题，前者可能导致安全握手失败，后者可能在后续身份验证时失败。订阅若缺少其中一项，不能用另一个节点的字段拼接补齐；这些参数必须来自同一套服务端配置。

VLESS 的 flow 也不是通用加速等级。它选择与服务端配套的流处理方式，需要满足对应的安全层与传输条件。WebSocket 的路径、gRPC 的服务名同样具有实际路由含义，并非备注文字。某节点只支持特定组合时，改传输类型并不会自动转换服务端。修改之前要先确认服务器实际提供什么入口；只在客户端里把下拉选项改成看起来更新的名称，通常只会造成协议不匹配。

证书与传输错误分别检查

遇到 TLS 错误，先看系统时间、证书有效性和服务器名称，再检查是否存在本机证书环境异常。若 TLS 已成功但随后被关闭，则继续核对密码、UUID、路径、请求头与服务名。日志中的“连接被重置”只说明对端或路径中的设备终止连接，并不能单独证明密码错误。需要结合失败阶段判断，必要时让服务端管理员检查对应入口的日志，而不是在客户端不断切换不相关的安全选项。

选型时，已有可靠 TLS 部署、希望参数结构直接的环境可以评估 Trojan；明确需要 VLESS 相关传输组合或流处理能力的环境，再选择相应的 VLESS 节点。两者都需要完整、可信的服务端参数。对只导入订阅的用户，优先保留提供方生成的配置，确认客户端支持整个组合。若仅需要理解字段名称，可结合术语表阅读，不必为日常使用手工重建整套节点。

Hysteria2 与 TUIC：基于 QUIC 的路径

为什么从 UDP 构建传输

QUIC 在 UDP 之上实现连接管理、安全握手、可靠传输与多流能力。它不是把 TCP 的数据直接改装成 UDP 包，而是把原本由传输层承担的一部分功能放入用户态协议实现中。多个流可以减少彼此因单流丢包造成的交付阻塞，但它们仍可能共享拥塞控制与路径容量。Hysteria2、TUIC 利用 QUIC 构建代理协议，目的是在特定网络条件下获得更灵活的传输行为，而不是保证所有网络都优于 TCP。

使用这两类节点之前，先确认接入网络允许相应的 UDP 通信。有些网络对 UDP 有不同的超时、限速或转发策略，网页直连可用并不意味着 QUIC 代理可用。若节点持续停在握手阶段，应先检查 UDP 可达性、端口与服务端监听，再检查认证信息。把失败统一归因于密码会浪费时间；相同服务器上的 TCP 节点能连，也只能证明另一条传输路径成立，不能证明 UDP 入口正常。

Hysteria2 的带宽与拥塞控制

Hysteria2 针对高往返时间、存在丢包的网络提供了基于 QUIC 的传输方案。其拥塞控制行为可以与带宽配置有关，具体还受服务端策略影响。配置中的上行和下行参数应理解为参与传输控制的输入，而不是购买带宽或解除线路限制的按钮。填写远高于真实接入能力的数值，可能造成排队、丢包和其他应用响应变慢。先依据本地网络能力与服务端说明配置，再在可重复条件下观察结果。

Hysteria2 与早期 Hysteria 的协议并不互通。节点名称都包含 Hysteria，并不代表可以只改类型字段完成迁移。认证、混淆、端口相关配置都需要按双方实现重新确认。若启用端口跳跃，也必须由服务端与中间转发设备共同支持相应范围；客户端单独填写多个端口不会生成服务端入口。家庭路由器或运营网络的会话跟踪行为，还可能使同一节点在不同网络下表现不同。

TUIC 的认证与 UDP 转发模式

TUIC 同样基于 QUIC，把可靠流传输与 UDP 转发纳入一条连接体系。不同协议代际的认证参数和行为可能不同，因此订阅中的类型、用户标识、密码及实现要求要整体匹配。客户端出现 TUIC 选项，只能说明具备某种 TUIC 支持，不能证明支持所有历史配置。与节点提供方核对其协议代际和推荐客户端，比尝试删除看不懂的认证字段更可靠，尤其是在旧分享链接导入新内核时。

TUIC 的 UDP 转发模式会改变数据如何承载和处理丢失。原生数据报方式与通过可靠流承载，并非只有速度差异：前者更接近原始 UDP 的丢失语义，后者可能让旧数据的重传影响及时性。拥塞控制选项也要遵循实现支持范围。在线游戏、语音与普通下载对丢包和重传的容忍度不同，应根据应用验证，而不是照着另一条线路的配置选择一个看起来更积极的模式。

QUIC 具备连接迁移等能力，但协议具备能力不等于某客户端在任何切网情况下都能保持业务。系统网络扩展、服务端策略和应用超时都可能中断会话。若设备经常在无线网络与蜂窝网络之间切换，应把实际切网测试纳入选择标准。选择 Hysteria2 或 TUIC 时，保留一条可靠的 TCP 类备用节点也有实际价值：当接入环境改变时，可以先恢复连接，再判断是否是 UDP 路径受限。

连接速度、吞吐与资源占用

把“快”拆成不同阶段

节点测试中最容易混淆的是连接耗时、首个响应和持续吞吐。连接耗时包括地址解析、底层握手及认证；首个响应还包含目标服务处理与回程；持续吞吐则受拥塞控制、路径容量和服务端资源影响。客户端里一次 URL 测试通常只反映特定目标、特定测试方法下的部分过程。数值较小不必然意味着下载更快，也不表示视频、语音或长连接会更稳定，必须先确定自己希望改善哪一项体验。

SS 的常见封装不强制增加完整的外层 TLS 握手；Trojan、VLESS 的实际握手过程取决于安全层与传输组合；Hysteria2、TUIC 则利用 QUIC 的连接机制。握手阶段可能受会话恢复和连接复用影响，同一节点第二次访问比第一次顺畅，并不一定是网络突然改善。比较时应区分冷启动与已有连接的使用体验，不要在一条节点已经预热、另一条刚刚启用的情况下直接下结论。

吞吐上限往往不在协议本身

持续下载的上限可能来自本地无线信号、服务端出口、目标网站、设备处理器或中间网络。高丢包路径上，拥塞控制可能显著影响结果；较稳定的低往返路径上，额外封装与实现效率又可能更容易被观察到。不能把某协议的一次峰值当成普遍能力。若切换节点同时改变了服务端区域与运营线路，就无法单独判断协议贡献，最多只能说明当前节点组合更适合这次测试条件。

多路复用可以减少重复建立连接的成本，但会改变多个业务之间的相互影响。把多条逻辑连接汇集到一条外层连接，可能降低握手次数，也可能集中排队与故障影响；是否改善需要看外层协议和实现。不要在没有服务端配套支持时主动打开复用，也不要把不同客户端同名开关视为同一种机制。对网页、多媒体和文件传输分别验证，通常比只看开关说明中的“优化”一词更有效。

处理器、内存与后台工作

资源占用不仅来自加密。用户态协议处理、包封装、规则查询、DNS 缓存、日志写入和连接统计都会消耗资源。低功耗设备上，算法是否有硬件加速、内核编译实现是否高效，可能比协议报文多几个字段更重要。路由器还要考虑并发连接和内存容量。桌面设备能轻松处理的配置，迁移到小型设备后可能出现处理器持续繁忙，表现为吞吐下降，却不是服务端线路变慢。

观察资源时应保持相同负载：先在空闲状态记录后台表现，再开启固定数量的应用，最后测试持续传输。调试日志会增加写入与格式化开销，排查结束后恢复正常日志级别。若连接数不断增加但业务已经停止，要检查应用是否持续重试、DNS 是否失败或策略是否循环，而不是直接认定协议“占内存”。有些资源增长来自缓存与连接生命周期，短时间截图不能说明长期泄漏。

策略组会进一步影响观察结果。url-test 通常根据指定探测结果自动选择节点，fallback 侧重按顺序选择可用项，load-balance 则可能把不同连接分配给不同节点。测试某协议时，应暂时选择固定节点，避免策略组在后台改变出口。需要了解各类策略的边界，可读策略组类型详解；策略组负责选节点，并不会改变节点自身的协议实现。

最终结论应写成带条件的判断，例如“此设备在当前无线网络中使用这条节点更稳定”，而不是“某协议永远最快”。当网络或设备发生变化，旧结果需要重新验证。若所有协议都在相同目标上失败，还应考虑目标服务自身、DNS 与路由规则。把问题拆到具体阶段，能避免为了追逐协议名称而更换客户端，却没有处理真正限制连接的环节。

移动端电量与系统接管范围

耗电来自整条工作链

移动端的电量表现由屏幕、无线通信、处理器、后台调度和代理工作共同决定。协议加密只是其中一部分。蜂窝网络持续收发与频繁唤醒，会让设备保持较活跃的无线状态；弱信号、重复重传和应用不断重试，也会增加消耗。因此不能给 SS、Trojan 或 QUIC 类协议排出固定的耗电名次。同一协议在无线网络和蜂窝网络中，甚至在同一地点的不同信号条件下，都可能呈现不同结果。

保持连接与反复重连有不同成本。长连接可以减少重复认证，但心跳过密会增加后台活动；心跳过疏又可能让中间设备释放会话，使应用下次访问时重新建立连接。QUIC、TCP 及具体代理实现的保活机制各不相同，不应把另一个客户端的心跳间隔直接照搬。日常先使用服务端与客户端的合理默认值，只有明确观察到空闲断连或后台频繁唤醒时，再针对相应机制调整。

系统代理不等于完整接管

桌面系统代理主要影响遵循该设置的应用，并不自动接管所有 UDP 与自建网络栈流量。TUN 模式通过虚拟网络接口接收流量，再交给内核处理，通常覆盖范围更广，但会引入路由、DNS 和权限等额外条件。它们是流量入口方式，不是代理协议。把系统代理切到 TUN 并不会把 VMess 变成另一种协议，也不会修正服务端密码错误；它只会改变哪些连接能够进入代理规则流程。

Android 客户端通常通过系统 VPN 接口接收设备流量，后台保活还受厂商电池策略、后台权限与应用休眠影响。若锁屏后断开，先检查系统是否限制客户端后台运行，再看是否只是某个节点的空闲会话被回收。允许后台运行能够改善持续连接，但也可能增加设备保持活动的机会。调整时一次只改一项，并通过实际待机观察确认效果，不必把所有电池限制都关闭。

iOS 客户端依赖系统网络扩展机制运行，内存与后台行为受到系统管理。选择客户端时可从首推的 Clash Plus 开始，结合实际订阅支持和设备使用方式评估，安装入口见iOS 客户端区。不要把桌面上的内核切换方法、进程管理习惯或本地文件路径直接套到移动端。系统终止网络扩展、应用显示断开和节点握手失败属于不同层面，需要分别观察系统状态与客户端日志。

策略探测与日志也会消耗电量

策略组定时探测会主动发起请求，配置里同时存在大量健康检查时，即使用户没有浏览网页，设备也可能持续产生网络活动。缩短探测间隔不一定让业务更稳定，反而可能增加唤醒和请求开销。按实际需求保留必要的检查目标与周期，并区分“后台检查”与“主动测试所有节点”。订阅更新、规则数据更新也应采用合理周期，避免为了追求即时刷新而在移动网络下重复获取大文件。

规则分流可以让不需要代理的业务直接连接，减少不必要的代理封装，但效果依赖规则正确。全局代理把更多连接送到节点，不代表每个应用都因此改善；直连模式也不代表客户端完全没有后台工作。应用排除、局域网访问与 DNS 路由需要协调，避免业务从一条路径访问、解析却走另一条不可用路径。若某应用只在代理开启时异常，可先检查连接是否进入内核，再确认命中哪条规则。

移动端选型的实用顺序是：先保证订阅兼容，再验证后台连接与切网恢复，最后观察电量。经常语音或游戏的用户，还需要验证 UDP 业务，而不只是网页访问。若 TCP 类节点在当前蜂窝网络表现稳定，就没有必要仅为“新协议”切换到 QUIC；反过来，某条 QUIC 节点在弱网络中更适合业务，也应以持续体验为依据，而不是因为后台耗电标签看起来较高就立即排除。

订阅格式与配置兼容性

链接、节点集合与完整配置

订阅 URL 是获取内容的地址，不是内容格式本身。服务器可能根据请求方式返回节点分享链接、编码后的链接集合、Clash 风格 YAML，或其他客户端的专用格式。一个地址能在某应用导入，并不代表另一个应用收到的内容完全相同。导入失败时，先确认提供方是否提供适合当前客户端的入口，再看返回内容是否为正常配置；登录页面、错误提示和流量到期说明都可能被误当作订阅正文下载。

节点分享链接描述单个节点；节点集合主要提供可选服务器；完整配置还可能包含策略组、规则、DNS 与监听设置。这三者不能互相等同。只导入节点时，客户端往往需要生成或补充路由结构；导入完整配置时，又可能覆盖原有设置。转换服务能改变表示格式，却不能为目标内核增加协议能力。目标不支持某个传输组合时，即使转换后生成合法 YAML，该节点仍可能无法运行。

转换时最容易丢失的字段

基础地址和端口通常容易保留，复杂选项更容易在转换中丢失，包括 TLS 服务器名称、WebSocket 请求头、gRPC 服务名、REALITY 参数、流处理方式和 UDP 相关设置。出现“节点在原客户端可用，转换后不可用”时，应比较同一个节点的脱敏参数，而不是只比较显示名称。有些转换器会过滤未知字段，也有些会把字段写到目标内核不认识的位置，二者都可能让表面导入成功却无法连接。

共享订阅给第三方转换服务还涉及访问凭据。订阅 URL 往往含有能够识别账号的路径或参数，上传完整链接可能让对方获得相同订阅内容。优先使用提供方直接生成的适配格式，或者在可信环境中处理。向他人求助时，移除地址中的凭据以及节点密码、UUID 等身份信息，只保留排查所需的字段结构。节点名称、服务器域名也可能暴露个人使用信息，应按实际需要脱敏。

区分订阅原文与本地覆写

客户端可能将订阅内容与本地覆写、全局设置及配置增强组合，生成内核运行配置。若直接修改订阅缓存，下次更新常会覆盖改动。需要长期保存的 DNS、规则或策略调整，应使用客户端明确支持的覆写机制，同时确认合并语义：列表可能追加，也可能整体替换。特别是规则按顺序匹配，追加到兜底规则之后的条目可能永远无法命中，不能只看到文本存在就认为已经生效。

下面是用于理解规则顺序的 mihomo 配置片段，不包含节点定义。域名后缀规则先处理指定域名，私有地址直连，最后才使用兜底策略。这里的 PROXY 必须在完整配置中对应一个真实节点或策略组。no-resolve 的作用是避免为这条地址规则额外触发域名解析，并不是关闭整个配置的 DNS 功能，也不保证连接在所有阶段都不发生解析。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,private,DIRECT,no-resolve
  - MATCH,PROXY

YAML 对缩进与数据类型有要求，建议使用空格缩进，不要把制表符混入层级。含特殊字符的值需要正确引用；字段拼写也必须符合内核要求。解析错误通常会指出附近行号，但根因可能在上一行，例如引号未闭合或列表标记缺失。先修复语法再测试网络，避免在配置根本没有加载的情况下反复切换节点。若客户端保留旧运行配置，界面看似仍能连接，也不代表新配置已经被采用。

更新配置前保留可恢复副本，更新后先确认解析成功，再检查策略组引用和关键规则。若所有节点同时消失，多半应从订阅内容和过滤条件查起；若只有一种协议报错，再检查协议字段与内核支持。若节点能连但业务走错出口，则查看规则命中和覆写结果。将格式、协议与路由分成三层检查，比把所有异常统一归为“订阅失效”更准确，也能减少向提供方反馈时的来回确认。

按场景选型与故障定位

先选可维护的客户端与完整配置

普通用户首先需要的是参数完整、更新路径清楚、能在设备上稳定运行的客户端。可先评估首推的 Clash Plus，再按桌面管理、移动端后台或 Linux 使用需求选择其他客户端。Clash Verge Rev 适合需要桌面配置与连接查看的用户，FlClash 覆盖多个平台，Clash Meta for Android 提供 Android 侧的选择。Surfboard 的导入格式与功能应单独核对，不能因为同列在下载页就推断支持全部 Clash YAML 扩展。

服务器和路由器用户可直接使用 mihomo 内核，但需要自行处理服务启动、文件权限、路由和配置更新。桌面用户通常更适合带界面的客户端，避免把时间花在与业务无关的进程管理上。安装前确认系统与处理器架构，安装后再核对内核能力。客户端选择与协议选择是两个问题：前者决定管理与系统集成体验，后者决定节点如何通信，不必为了切换一个现有支持的协议就重装整套环境。

根据业务选择测试重点

日常浏览与办公，优先关注首次访问、连接稳定和规则正确性，已有稳定的 SS、VMess、Trojan 或 VLESS 节点都可以使用。大文件传输应观察持续吞吐、处理器负担及其他业务是否被排队影响。高往返或存在丢包的路径，可以评估 Hysteria2、TUIC，但前提是 UDP 路径可靠。会议、语音和游戏需要验证真实应用的数据流，不能仅以浏览器页面加载成功作为通过标准。

经常访问局域网设备的环境，还应验证私有地址、局域网域名与虚拟网卡路由。若使用 TUN，检查打印机、共享目录和本地服务是否仍按预期访问。远程办公软件可能有自己的代理设置与证书要求，应按应用文档配置。此类兼容性常与接管方式和路由有关，不一定需要更换节点协议；盲目切换协议可能暂时改变连接行为，却留下未解决的路由冲突。

按失败阶段逐层收敛

排错从本机开始：确认当前配置已启用，内核正在运行，应用确实进入代理入口。接着检查 DNS 是否得到预期地址、服务器端口是否可达，然后看安全握手与身份认证。最后再检查目标连接和规则命中。只有进入内核的连接，日志和连接页才有机会解释其路由；如果完全看不到该应用的连接，应先检查系统代理、应用设置或 TUN 接管，而不是修改节点密码。

同一订阅中所有节点同时失败，优先检查本机网络、配置加载、订阅状态和统一 DNS 设置；只有某一节点失败，先看服务器与参数；只有某一类协议失败，则检查内核支持及对应传输路径。节点连接成功但个别网站失败，应查看目标 DNS、规则与服务端出口。这个分支顺序可以缩小范围，避免同时改动多个参数。更多本机问题可查看常见问题，首次验证方法见系统代理设置。

向提供方反馈时，说明设备系统、客户端、内核名称、协议类型和失败阶段，并附上脱敏后的相关日志。保留错误原文通常比“不能用”更有价值，但不要提交整个订阅或认证信息。节点超时的具体排查可参考由近到远的排查顺序。如果正在比较协议，也记录测试时的接入网络与是否使用固定节点，便于对方复现相同条件。