Clash 协议与内核
技术参考

一、连接层次：客户端、内核与协议

客户端界面中的一个节点，实际上是一组连接参数的集合。它通常包含远端地址、端口、认证信息、协议类型，以及可选的传输与安全设置。点击节点名称，只是把某个代理组的当前出口指向这组参数，并不会改变协议本身。理解这层关系后，就能区分“换一个节点”“更换协议类型”和“切换规则模式”：三者分别改变连接目的地、连接方法与流量决策，排查时不能混为一谈。

界面负责操作，内核执行连接

Clash Plus、Clash Verge Rev、FlClash 等客户端提供订阅管理、策略选择与系统集成界面，内核负责解析配置、解析域名、匹配规则、建立连接并转发数据。名称相近的客户端，可能使用不同内核构建；名称不同的客户端，也可能采用同一家族的内核。因此，界面上有没有一个开关，不等于底层是否支持某项协议；反过来，内核具备能力，也不保证当前客户端已经提供对应的图形设置入口。

可以把一条请求拆成四段：应用把流量交给本地入口，内核依据规则选出策略，协议实现与远端建立会话，远端再访问目标服务。本地入口可能是 HTTP 代理、SOCKS 代理或 TUN 虚拟网卡。代理协议主要作用于内核与远端之间这一段，不直接决定浏览器是否遵循系统代理，也不自动解决本机 DNS、路由或权限问题。某个应用无法连接时，应先确认它的流量是否真正进入内核。

区分应用流量与底层传输

TCP 和 UDP 既可能描述应用产生的流量，也可能描述代理协议使用的底层承载。两者不是同一个问题。例如，基于 QUIC 的协议以 UDP 作为承载，却可以代理应用的 TCP 连接；支持 UDP 转发的协议，也需要服务端、客户端和入口同时满足条件。游戏有 UDP 请求，不代表必须选择 QUIC 协议；打开 TUN，也不代表所有远端都接受 UDP。选型时应分别询问“应用需要什么”和“当前网络允许什么”。

安全参数不能脱离信任边界

代理连接的加密与目标网站的 HTTPS 是不同层次。代理链路加密保护本地到远端之间的数据传输，HTTPS 则提供应用与目标服务之间的安全会话。使用代理不意味着可以忽略证书验证，也不意味着远端对所有信息都不可见。目标地址、连接时间与流量特征仍可能被链路参与方观察，具体范围取决于协议、DNS 路径及应用自身是否加密。选择服务时，应同时考虑参数来源和远端运营方的可信程度。

实际记录配置时，建议先写下客户端名称、内核名称、协议类型、本地接管方式和发生问题的应用，再描述故障现象。这样比只说“Clash 不能用”更容易定位。若流量尚未进入内核，优先阅读TUN 模式与系统代理区别；若流量已命中正确策略，再进入后续协议章节。整份手册的比较都以参数正确、服务端可用为前提，不把服务质量差异归因于协议名称。

二、SS 与 VMess：轻量转发与会话设计

Shadowsocks 通常缩写为 SS，其设计重点是以相对简洁的结构提供加密代理转发。VMess 则来自 V2Ray 生态，将认证、请求描述和数据传输组织成另一套协议体系。两者都在 Clash 生态中长期出现，但不能因为使用时间较长，就认定所有客户端对它们的细节支持完全一致。比较时应明确加密方法、认证方式与外层传输，而不是只看订阅中的类型标签。

SS 的取舍在于结构简洁与算法选择

SS 的常见配置由服务器地址、端口、密码和加密方法构成。现代部署通常使用带认证的加密方案，使接收端能够检测数据是否被篡改；较早的流式加密方法与现代 AEAD 方法并不等价。部分配置还采用 Shadowsocks 2022 系列方法，其密钥格式、实现要求与传统密码型配置存在差别，不能把一段普通密码随意填入所有方法。客户端能够识别 ss 类型，只能说明支持这类协议入口，不能替代对具体方法的确认。

在支持相应硬件指令的设备上，AES 类算法可能获得加速；在缺少相关指令的处理器上，ChaCha20 类实现有时更合适。但最终开销还受到内核实现、数据包大小、并发数量与设备温度影响。选择算法首先应服从服务端参数，而不是为了“更快”自行修改名称。两端方法不一致通常导致连接失败，不会自动协商成另一种可用模式。相同 SS 节点在不同设备上的性能差异，也不应直接理解为配置损坏。

SS 可以承载 TCP，并在实现与部署支持时转发 UDP。若订阅附带插件，还要额外检查插件名称及参数是否被当前内核接受。插件相当于在连接路径上增加一层处理，并不是每个支持 SS 的客户端都会支持所有插件。导入后只有这类节点失败时，应先查看插件字段和日志中的解析提示；与其删掉未知参数碰运气，不如向配置提供方索取当前客户端可用的完整形式。

VMess 的认证与外层传输应分开理解

VMess 使用用户标识参与认证，并有自己的会话与数据保护设计。常见分享链接还会携带 TCP、WebSocket 等传输信息，以及可选的 TLS 参数。WebSocket 是外层承载方式，不是新的代理协议；TLS 也不是 VMess 类型的同义词。一个 VMess 连接可能因为路径、主机名或证书设置错误而失败，这时更换 UUID 并不能解决问题。应按从远端地址到传输、再到认证的顺序逐层核对。

旧资料中出现的 alterId 和旧式认证配置，不宜直接当成新部署范本。现代配置通常采用 AEAD 认证路径，具体兼容行为仍由内核与服务端决定。VMess 的认证对系统时间有要求，设备时间偏差明显时可能出现看似参数正确却无法认证的情况。恢复网络自动校时后再测试，比反复导入同一链接更有意义；但时间正常而日志显示 TLS 错误时，应回到证书和服务器名称检查，不要把所有失败都归结为时钟。

如何在两者之间作实际选择

若已有一组稳定的 SS 参数，目标只是桌面浏览与一般应用连接，简洁配置往往便于管理；若服务端已经围绕 VMess 及指定传输部署，则保持两端约定比追求更短的字段更重要。两类协议都不能仅凭名称预测带宽或延迟。远端出口拥塞、链路距离和服务限制，通常足以盖过协议开销的差别。应使用同一应用、相近时段和相同目标测试，而不是拿两个不同服务商的节点判断协议优劣。

三、Trojan 与 VLESS：TLS、安全层与传输组合

Trojan 和 VLESS 经常与 TLS 一起出现在订阅中，因此容易被理解成同一种技术的两个名称。实际上，Trojan 的设计围绕 TLS 连接与其内部的代理请求展开；VLESS 则着重提供较精简的认证和请求格式，本身不承担与 VMess 相同的数据加密职责。两者的安全边界、配置结构和可组合能力并不相同，不能把相同的端口或证书设置视为互相兼容的证据。

Trojan：把安全传输交给 TLS

Trojan 通常以 TLS 提供链路的机密性与服务器身份验证，再在该连接内完成协议认证和目标请求。用户常见的字段包括地址、端口、密码与服务器名称。客户端连到的 IP 地址和证书对应的域名可以不同，但验证时必须使用正确的服务器名称。这里的名称不是任意备注，而是 TLS 握手及证书检查的一部分。把节点显示名填进服务器名称，往往会造成证书不匹配。

TLS 会话能否恢复、连接是否复用、服务端支持什么传输，都可能影响实际连接成本。不能简单地把 TLS 等同于“必然慢一次握手”，也不能假定所有实现都以同一种方式复用连接。首次连接、短时间内再次连接以及应用长期保持连接，可能表现出不同开销。阅读对比结果时，应确认测试测到的是冷启动连接，还是已经完成安全会话后的数据传输，否则同一协议也会得到看似矛盾的结论。

证书错误应通过正确域名、有效证书和系统时间解决，不宜把跳过验证当成日常配置。关闭验证会失去重要的服务器身份检查，连接成功本身并不能说明连接到了预期服务。若配置提供方要求特殊信任方式，应先了解其依据和风险，再判断客户端是否支持，而不是从其他节点复制一个相关开关。密码正确也不能补偿错误的证书信任关系，两者承担的是不同职责。

VLESS：协议、传输与安全层分别核对

VLESS 的轻量请求设计使它能够与不同传输及安全机制组合。看到 type: vless 时，还要继续检查 TCP 或其他网络承载、TLS 或 REALITY 相关设置，以及服务端是否要求特定的 flow。VLESS 自身不提供完整的数据加密保护，因此不能因为带有用户标识，就认为任意明文承载都具备安全性。应以完整连接组合为单位判断，而不是独立评价一个类型字段。

REALITY 属于特定的安全握手机制，Vision 则涉及特定流控与数据处理路径；两者不是可以随意叠加到任何节点上的通用提速按钮。服务器名称、公钥、短标识以及 flow 等字段，都必须与服务端配置匹配，并由当前内核实现支持。不同客户端对这些字段的界面名称可能不同，有的只接受完整 YAML。遇到导入成功但连接失败的情况，要看字段是否真正传递给内核，而不只看列表里是否出现节点名称。

选型重点是完整支持，而非字段多少

如果服务端同时提供两类入口，优先选择客户端明确支持、参数来源完整且能够保持证书验证的组合。字段少不必然更省电，组合复杂也不必然更快。对日常浏览而言，连接稳定、应用恢复及时和配置更新可靠通常更重要。对需要特定 VLESS 功能的用户，先确认 mihomo 构建与客户端导入路径，再比较实际效果；若仅有节点链接而缺少传输说明，应索取完整配置，不凭链接外观猜测。

四、Hysteria2 与 TUIC：QUIC 承载的取舍

Hysteria2 与 TUIC 都利用 QUIC 构建代理传输，但它们并不是同一种协议的别名。QUIC 以 UDP 为基础，整合安全握手、流管理和拥塞控制等能力，为代理会话提供不同于传统 TCP 连接的组织方式。选择它们时，应先确认当前网络对 UDP 的可达性与限制，再研究拥塞控制和带宽参数。若底层 UDP 路径不通，再完整的认证参数也不能建立有效会话。

QUIC 解决了什么，又没有解决什么

QUIC 的多个流可以减少不同流之间因单个数据包丢失造成的传输层相互阻塞，这与把所有数据简单塞进一条 TCP 字节流有所不同。但一个流内部需要按序交付的数据仍可能等待重传，所有流也仍共享带宽、拥塞状态和端点资源。它不是“丢包不影响速度”的技术。网络发生拥塞时，协议仍须协调发送速率；应用自身的请求依赖和服务器响应时间，也不会因为使用 QUIC 而消失。

某些网络对 UDP 有独立的限速、超时或丢包策略。能使用视频通话，不代表任意远端端口的 UDP 都具有同样质量；一次握手成功，也不代表长时间大流量传输稳定。测试应包括持续访问、短暂停顿后恢复以及设备休眠后重连。QUIC 可以具备连接迁移能力，但具体代理实现、地址变化方式和网络设备状态会影响结果，不应将 Wi-Fi 切换蜂窝网络时的连续性视为必然保证。

Hysteria2：发送策略需要真实链路条件

Hysteria2 的设计面向不稳定链路下的数据传输，其部署中常见带宽相关设置与不同的拥塞控制路径。若采用依赖带宽声明的发送策略，填写的上下行能力需要接近可持续的实际条件，而不是设备标称速率。数值填得很高并不会创造带宽，反而可能导致排队增加、丢包扩大，影响同网络中的其他应用。服务端也可能设置自己的限制，客户端参数并不能绕过远端资源约束。

在 mihomo 配置里，应按实际支持的 Hysteria2 类型与字段导入，不能将旧 Hysteria 配置仅改名称后继续使用。认证信息、TLS 服务器名称和可选混淆参数都需要与远端一致。带宽字段是否省略、采用何种策略，应遵循提供方说明与当前内核文档。若出现连接建立正常、持续下载却明显波动，应同时检查 UDP 路径、带宽估计和设备处理能力，不先把 DNS 改来改去。

TUIC：会话组织与 UDP 转发方式

TUIC 同样使用 QUIC，围绕代理会话、认证和数据转发定义自己的机制。不同协议代际和实现之间可能存在不兼容，分享信息必须与内核接受的形式对应。UDP 转发方式、拥塞控制选项、连接保活与超时设置都可能影响体验；一些模式强调低额外开销，另一些侧重交付语义，不能只看选项名称决定。特别是应用需要实时数据时，应关注突发停顿和丢包，而不是仅观察大文件是否下载完成。

QUIC 常在用户态处理较多协议逻辑，加密、包处理和高包速率会占用 CPU。较新的桌面设备可能轻松承担，低功耗路由器或持续发热的手机则可能先达到处理极限。协议开销与设备实现相关，不存在所有平台通用的资源排名。在同一条线路上，如果 TCP 类入口已经稳定满足需求，换成 QUIC 未必有明显收益；若链路确实存在高延迟和丢包，再用受控测试确认改善更可靠。

五、性能与电量：如何比较才有意义

协议比较至少要分开四个指标：新连接需要多久、持续传输能达到什么速度、请求体验是否稳定，以及设备为此消耗多少资源。客户端显示的测速毫秒数，通常只是某条测试路径上的一次或少量请求耗时，不是带宽，更不是完整的应用体验。只有测试目标、出口、时间和设备条件接近时，协议差异才有可讨论的基础。跨地区、跨服务商的节点成绩不能直接作为协议排名。

连接速度、带宽与尾部停顿

首次访问会受到 DNS、底层连接、安全握手、代理认证和目标服务器响应共同影响。应用若复用已有连接，后续请求可能绕过其中一部分成本，因此冷启动慢与连续浏览快可以同时发生。大文件传输更容易反映持续吞吐，却难以代表页面中许多小请求的完成情况。实时业务则对突发丢包和长尾延迟更加敏感，即使平均耗时相近，少量明显停顿也可能改变主观体验。

较合理的对照方式，是选择两条服务端条件尽可能一致的入口，在相近时段交替执行同一组任务：首次打开页面、刷新已有页面、短时间传输文件，以及运行实际需要的语音或远程应用。每项重复几次并记录失败情况，不只保留最好的一次。协议测试不应同时开启多个大流量任务，否则带宽争抢会掩盖差别。更完整的原理说明可查阅节点延迟测试与实际网速的区别。

资源占用没有固定的协议排行榜

CPU 负载取决于加密实现、系统调用、包处理与数据复制等因素，内存还受连接数量、缓冲区和规则数据库影响。TUN 模式增加的流量接管工作，也可能大于两个代理协议之间的差别。观察到内存增长时，应先确认是连接增多、缓存积累还是持续异常，不能看到某个协议在用就直接归因。比较客户端时还应区分界面进程和内核进程，否则桌面界面的占用容易被算进协议成本。

硬件加速与网络卸载会改变结果。具有相关加密指令的处理器、不同操作系统的网络栈，以及内核构建时采用的实现，都可能让同一协议在两台机器上呈现不同表现。低功耗设备还可能因温度升高而降低频率，出现前几分钟很快、随后逐渐下降的情况。此时应观察温度、处理器负载与链路表现的关联，而不是继续提高连接并发或缓冲参数，加重已经存在的资源瓶颈。

移动端电量主要看唤醒与连接生命周期

手机耗电不仅来自加密计算，也来自无线电持续活跃、后台唤醒和反复重连。过于频繁的健康检查、订阅刷新或保活，会让原本空闲的设备持续产生网络活动。相反，把超时设置得过短又可能导致会话频繁失效，恢复应用时不断重建连接。应优先使用客户端的合理默认值，再依据实际断流现象调整，而不是为追求一个即时测速数字，长期启用高频探测。

比较电量时，应固定屏幕亮度、网络类型、使用时长与业务负载，并查看系统电池统计中的后台活动。蜂窝信号较弱时，无线电消耗往往会盖过协议差异；Wi-Fi 与蜂窝的结果也不宜直接对照。Android 的省电限制可能终止后台服务，iOS 的网络扩展则由系统管理生命周期，两者的行为并不完全一样。恢复后重新连接并不一定说明协议异常，要结合系统是否保留了运行条件判断。

六、内核家族：原版、Meta 与 mihomo

Clash 最初形成了以 YAML 配置、策略组和规则分流为核心的使用方式，后续生态围绕这些概念发展出多种内核与图形客户端。原版开源内核、历史上的其他发行分支，以及 Meta 分支并不是完全相同的实现集合。mihomo 是 Clash.Meta 后续使用的项目名称，因此在资料和客户端界面里仍可能看到 Meta 字样。这个命名关系解释了许多旧教程，却不能替代对实际内核能力的确认。

共同语法不等于功能全集一致

常见配置保留 proxies、proxy-groups 和 rules 等结构，使大量基础概念能够沿用。但协议类型、DNS 行为、TUN 功能、规则提供器及扩展字段，会随着分支与构建不同而变化。原版资料里能找到某个字段，不表示它在所有客户端中表现一致；mihomo 支持的扩展，也不能直接交给较早的原版内核。迁移时应把兼容性理解为具体字段的兼容，而不是文件扩展名相同。

Hysteria2、TUIC、特定 VLESS 组合以及更丰富的路由能力，是用户核对现代内核支持时经常遇到的项目。是否支持还要结合具体构建、平台限制和客户端集成方式判断。某些图形界面会过滤字段，有的会生成中间配置，有的则直接加载原始 YAML。出现“独立内核可以运行，客户端导入后不行”的情况时，应比较最终生效配置，而不是只比较导入前保存的文件。

确认内核的操作顺序

先在客户端的关于、内核管理或运行日志中查看内核名称，再确认当前真正启动的是哪一个构建。客户端安装目录里存在多个内核文件，不代表它们同时工作；界面版本号也不是内核版本号。如果客户端提供切换内核功能，切换后要等待服务重启，再查看日志确认。没有明确显示时，应以客户端说明和运行输出为准，不凭安装包名称推断。版本记录可以用于排查，但不需要为了选型追逐每次变化。

升级前保存原始订阅和必要的本地覆写，记录当前使用的接管方式、端口及 DNS 设置。升级后先用最简单的可用配置确认基本连接，再恢复自定义规则和扩展功能。这样能够区分“协议解析变化”“系统集成变化”和“本地覆写冲突”。如果第一次启动即失败，应先看配置解析日志；如果内核已经运行而应用不通，再检查系统代理、TUN 权限和路由。两种故障不应采用同一套处理方式。

客户端选择与维护边界

普通用户可先从 Clash Plus 开始，按设备平台核对协议导入与系统要求；有特定桌面管理习惯时，再比较 Clash Verge Rev、FlClash 或 Clash Nyanpasu。Android 上还可根据配置来源比较 Clash Meta for Android 与 Surfboard，但后者的配置体系不能直接等同于 Clash YAML。Linux 桌面可从 Clash Verge Rev 与 FlClash 中选择；服务器或路由器才需要进一步考虑独立 mihomo 内核和服务管理。

Clash for Windows 与 ClashX Meta 在本站按已停止维护的归档客户端说明，不宜作为新协议功能的默认参照。旧环境为了既有流程继续使用时，应明确它能接受的协议和配置范围。不要将新配置中的未知字段逐个删除到“可以启动”为止，这可能改变路由与安全行为。各平台入口及归档标记见客户端下载页，界面取舍可继续阅读选型指南。

七、订阅与配置：格式识别及兼容检查

订阅链接是一种内容获取入口，不是固定格式的保证。相似的 HTTPS 地址，返回的可能是节点分享链接集合、经过 Base64 编码的文本，也可能是完整 YAML 配置。客户端导入后能否直接使用，取决于返回内容与导入方式是否匹配。一个地址能在浏览器打开，只说明服务器返回了内容；若返回的是登录页面、错误提示或空白文本，仍然不是有效的代理配置。

区分节点集合、提供器与完整配置

节点链接通常描述单个代理的连接参数，多个链接组成的集合未必包含本地端口、DNS、策略组与规则。完整 Clash 配置则会组织这些部分，说明流量如何进入、如何解析和如何选择出口。代理提供器又是另一种边界：它主要为已有配置提供一组代理，不承担全部运行设置。导入时选错入口，可能出现节点看得见却没有合适策略组，或文件可以解析但无法作为独立配置运行的情况。

Base64 只是编码方式，不提供额外的保密保护，也不会自动把节点集合转换成 YAML。订阅转换工具需要解析源格式，再生成目标内核接受的字段和策略结构。转换过程可能丢失不认识的扩展信息，例如传输细节、特定安全参数或 UDP 设置。转换结果出现节点名称，并不代表所有功能都被保留。涉及复杂 VLESS 或 QUIC 配置时，应优先使用提供方明确支持的目标格式，并对照关键参数。

用结构检查代替反复重新导入

读取配置时，先找代理定义，再找引用这些代理的策略组，最后检查规则指向的策略是否存在。下面是展示引用关系的最小片段，不是完整运行配置：它假定现有配置已经定义了名为“已有节点”的代理。使用时应在现有配置中对应合并，不能创建第二份同名顶层键。片段采用常见的规则写法，能帮助判断一条规则究竟会选择哪个出口。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 已有节点
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,DIRECT

这段关系里，规则先尝试匹配域名后缀，命中后交给 PROXY 组，再由该组当前选择决定出口；未命中则进入最后的 DIRECT。组内保留 DIRECT 不表示所有请求都会直连，而是提供一个可手动选择的选项。规则从上到下首条命中后停止，若更宽泛的规则放在前面，后续细分项可能永远没有机会执行。具体语法与排序可查阅自定义规则与 MATCH 兜底。

YAML、覆写与更新各有边界

YAML 对缩进和结构敏感，建议使用空格并保持同级对齐。密码、带特殊符号的字符串或容易被识别成其他类型的值，应按格式正确引用。解析错误通常会指出附近行号，但真正的问题可能位于上一行，例如缺少冒号或列表层级不对。先解决解析，再检查引用，最后验证协议连接，效率比一次性修改许多字段更高。长规则或节点名称也应保持完整，不把界面换行误当成文件中的换行。

订阅更新可能覆盖手动修改，所以持久化的本地规则宜使用客户端支持的覆写或合并机制。不同客户端的合并顺序不完全相同，列表可能替换，也可能追加；修改后应查看最终生效结果，尤其是规则前后顺序和 DNS 项。DNS 的 Fake-IP 是解析与映射策略，不是代理协议类型，转换节点格式不会顺带解决应用对 Fake-IP 的兼容问题。调整 DNS 前，先确认当前故障发生在域名解析还是远端连接阶段。

如果同一订阅在两个客户端中节点数量或协议类型不同，应检查过滤设置、格式选择和内核支持，而非立即判定订阅失效。完整的格式对照见Base64 节点链接与 YAML 配置说明。保留原始来源与本地修改的分工，能够让后续更新和迁移更容易追溯。

八、场景与排查：从需求缩小选择范围

协议选择的起点不是“哪一种最先进”，而是设备、网络、应用和配置来源四个条件是否相互匹配。先选能够持续维护、正确导入现有参数的客户端，再确定接管方式，最后比较同类服务端入口的表现。对于普通用户，首推从 Clash Plus 与提供方支持的配置开始；只有当存在明确兼容性需求或可重复的性能问题时，再增加新的内核或协议组合，避免把排查环境变得过于复杂。

桌面、移动与路由器的关注点

桌面浏览与办公应用，首先确认系统代理能否覆盖需要的程序。浏览器可用而命令行不可用时，问题可能是命令行没有读取系统代理，并非远端协议不支持。需要接管更多应用再考虑 TUN，同时留意虚拟网卡权限、路由冲突和本地网络访问。协议方面，已经稳定运行的 SS、Trojan 或完整 VLESS 组合都可以继续使用，没有必要只为名称更新而迁移。开发工具还要分别检查自身代理和环境变量设置。

移动端更适合关注休眠恢复、网络切换和后台稳定性。若经常从 Wi-Fi 转到蜂窝，应在真实切换后检查已有会话与新会话，而不只在固定网络下测速。QUIC 类协议可以作为候选，但要验证当前运营网络的 UDP 条件。不要为了减少一次重连，随意增加持续保活；也不要把系统暂停后台服务造成的断开解释为认证失效。iOS 可从 Clash Plus 商店入口开始，并在其官网 clashplus.io 核对产品信息。

路由器与服务器通常需要独立内核、自动启动、日志管理和明确的路由边界。低功耗处理器对高吞吐加密及 QUIC 包处理更敏感，内存也可能被大量连接与规则占用。先以少量连接确认稳定，再逐步增加负载；不要从桌面设备直接复制复杂配置后便长期运行。旁路由、多网口或已有透明代理规则的环境，还需避免流量回环。协议改变不能修复错误的路由表，也不能替代管理员对防火墙规则的检查。

失败时按层排查，不同时改多个变量

第一步看内核是否启动。解析错误、未知协议或缺失字段，优先检查配置与内核兼容性；监听失败则检查端口和服务占用。第二步看应用请求是否出现在连接记录中，没有记录就检查本地接管。第三步看规则命中了哪个策略，确认不是错误地选择 DIRECT 或一个不可用代理组。第四步才查看远端连接中的超时、认证、证书和 UDP 路径问题。这样的顺序能避免远端正常，却反复更换节点的无效操作。

如果日志提示证书错误，核对服务器名称、时间和证书链；提示认证失败，核对密码或用户标识；持续超时则结合 TCP 或 UDP 承载检查可达性。仅某个网站失败时，还要考虑远端出口与目标服务的关系，以及 DNS 解析结果。端口冲突属于本地运行问题，可以参考端口占用定位与混合端口修改；首次导入流程和常见操作问题则回到使用指南，不必从头更换整个配置体系。

保留一份可复现的选型记录

最后留下简短记录：设备与系统、客户端和内核、协议完整组合、接管方式、测试业务、网络类型以及可重复的现象。每次只改变一个关键因素，并保留已知可用配置。若新组合只是测速数字更好，却带来休眠重连、资源占用或兼容问题，继续使用原有稳定方案完全合理。协议是连接工具，不是等级标签；参数来源可靠、行为能够解释、更新后可以恢复，才是适合长期使用的配置。