Clash 协议与内核参考

一、协议选型：先拆开连接的各个层次

协议、传输与客户端分别负责什么

在客户端里选择一个节点，实际上同时选中了服务端位置、认证方式、代理协议和底层传输。Shadowsocks、VMess、Trojan、VLESS 主要描述代理连接的组织方式；TCP、UDP、TLS、WebSocket 等描述不同层面的承载方式。Hysteria2 与 TUIC 则围绕 QUIC 设计传输。把这些名称放在同一列直接比较，容易把协议差异误当成线路差异。

客户端是配置与控制入口，内核负责解析配置、建立连接和执行规则。界面能显示某种节点，不代表当前内核能处理该节点的全部选项；内核支持一种协议，也不代表订阅转换器保留了相关字段。选型要沿着“服务端要求—订阅内容—内核能力—客户端设置”逐层核对，而不是只看节点名称中的缩写。

还要区分应用流量与代理隧道的传输。游戏发送 UDP 数据，不意味着任何标有 UDP 的节点都能正确承载；浏览器访问 HTTPS，也不意味着代理外层一定使用 TLS。一次连接可以有多层封装，各层的加密、拥塞控制与超时分别生效。排查时先确认出问题的是应用请求，还是客户端到代理服务端的连接。

兼容优先，再比较性能

实际选择顺序是：确认服务端允许使用哪些协议，检查当前系统的客户端与内核支持，再比较同一服务商、相近地区和相近时段的表现。若服务端只提供 Trojan，改写节点类型为 VLESS 不会产生有效连接。协议不是客户端单方面可以切换的外观选项，认证字段与传输参数必须与服务端对应。

同样不能把“支持 UDP”“支持多路复用”“支持 TUN”视为同一能力。UDP 转发属于协议与服务端能力；多路复用属于连接组织策略；TUN 属于本机流量接入方式。开启 TUN 可以接入部分不读取系统代理的应用，但不会为服务端增加 UDP 转发能力，也不会修复错误密码或证书域名。

安全与维护也是选型条件

优先使用仍在维护的客户端和内核，保留证书验证，并从可信来源取得配置。代理链路加密不等于应用可以发送明文敏感信息：数据离开代理服务端后的保护仍取决于应用协议。访问账号、支付或管理后台时，应继续使用有效的 HTTPS 连接，不能用代理外层的加密替代网站自身的安全连接。

订阅地址往往包含访问凭据，配置中也可能包含密码、UUID 或管理接口密钥。分享截图时隐藏地址与认证字段，排错只提供协议类型、错误类别和必要的非敏感参数。需要他人协助时，不应上传完整订阅文件到公开讨论区；节点名称也可能暴露服务商或个人命名信息。

二、Shadowsocks 与 VMess：加密代理的两种组织方式

Shadowsocks：结构精简，方法必须对应

Shadowsocks，常写作 SS，起点是相对轻量的加密代理设计。它使用服务端地址、端口、加密方法和密码建立代理关系，常见配置较短，适合需要明确管理少量节点的场景。轻量指的是协议组织方式，不代表所有设备、所有加密方法都具有相同的 CPU 开销，也不代表服务端必然支持全部可选扩展。

选择 SS 时，最重要的是核对加密方法与密码。现代部署应使用服务端与客户端共同支持的认证加密方案，不应为了兼容旧软件随意降级到过时方法。部分较新的 SS 方案对密钥格式、长度和多用户组织有专门要求，不能把任意文本密码直接填入。导入后报密钥长度错误，应先检查来源格式，而不是反复修改端口。

SS 的 TCP 与 UDP 转发需要分别验证。浏览网页正常，只能证明相关 TCP 请求完成；语音、游戏或部分 DNS 请求仍可能失败。若服务端未启用 UDP、网络路径限制了 UDP，或应用没有被本机代理入口接管，单独打开客户端中的 UDP 选项无法补齐条件。应先从日志确认请求是否进入内核，再检查服务端与传输。

有些 SS 部署还依赖插件。插件会改变外层连接方式，并引入额外的类型、路径或 TLS 参数，因此“支持 SS”不自动等于“支持该插件组合”。转换订阅后只保留地址和密码，可能让节点看似导入成功却无法使用。移动端尤其需要核对内核是否内置对应插件能力，不能照搬桌面端外部插件的使用方式。

VMess：认证与外层传输分开核对

VMess 来自 V2Ray 生态，围绕身份认证与代理数据传输组织连接。节点一般使用 UUID 等认证信息，并可能结合 TCP、WebSocket 或其他受支持的传输方式。相较于只观察一个协议标签，VMess 的实际行为更依赖整套参数。相同 UUID 配上不同路径、主机头或 TLS 设置，也可能得到完全不同的连接结果。

旧资料常混有历史认证方式与遗留字段，不能直接当作当前推荐配置。遇到订阅里的旧参数，应先确认提供方要求与内核说明，不要按搜索到的片段逐个试值。设备时间也值得检查：认证相关机制可能依赖合理的时间状态，系统时钟明显偏差时，应先恢复自动校时，再判断是否是节点失效。

使用 WebSocket 时，要分别核对连接端口、请求路径、Host 头和 TLS 的服务器名称。Host 是 HTTP 层信息，服务器名称参与 TLS 连接与证书校验，两者可能有关联，但不能认为始终等价。反向代理部署中，路径必须与服务端转发规则一致；路径写错时，日志可能先表现为 HTTP 响应异常，而不是认证失败。

两类协议怎样比较才有意义

SS 参数相对集中，适合希望减少外层组合的部署；VMess 的组合方式更多，便于接入已有的传输设施，但排错项目也随之增加。不能据此下结论说前者总是省电、后者总是慢。加密实现、CPU 指令支持、网络往返时间与是否复用连接都会改变结果，低性能路由器和现代手机的表现也可能不同。

比较时尽量控制出口地区、服务端资源与目标文件。如果两个节点来自不同机器，结果主要说明这两个节点的综合质量。对日常用户而言，更有用的指标是首次打开页面是否顺畅、持续传输是否稳定、空闲后能否及时重连，以及切换网络后是否恢复；单次测试连接耗时只能作为辅助线索。

三、Trojan 与 VLESS：TLS、认证与传输组合

Trojan：把 TLS 条件检查完整

Trojan 将代理认证与数据放在 TLS 连接中，常见部署使用密码认证。它的设计取舍是利用成熟的 TLS 传输保护，再在其中承载代理请求。对客户端用户来说，节点地址、端口、密码与服务器名称是主要检查项；证书链是否可信、系统时间是否准确，同样会影响连接，不能只盯着密码输入框。

证书验证针对的是服务器身份，不只是“有没有加密”。连接地址可以是 IP，也可以是域名，但证书必须与用于验证的名称正确对应。某些部署要求另外指定服务器名称，这时要照提供方参数填写，不能用节点显示名称代替。证书已过期、域名不匹配或证书链不完整，应由配置来源或服务端维护者修正。

跳过证书验证会削弱身份认证，不应作为日常修复方案。若只有某个设备报证书错误，先检查该设备的时间、系统信任库、网络中间设备与客户端日志；若所有设备同时失败，则更应关注服务端证书和部署变化。修改验证选项可能让报错消失，却无法证明实际连到的是预期服务器。

Trojan 的 UDP 能力也不能简单等同于原生 UDP 传输。常见实现会把 UDP 数据封装在可靠连接中，具体路径取决于内核与配置。这样可以提供应用所需的转发语义，但在丢包时可能受到外层可靠传输等待的影响。语音或游戏体验应通过实际应用测试，而不是仅凭节点支持 UDP 的标识判断。

VLESS：轻量认证不等于独立完成加密

VLESS 的设计强调将认证与外层传输保护分离，协议本身不提供内容加密。实际部署通常结合 TLS、REALITY 等受支持的安全传输机制，因此不能把 VLESS 节点理解为只需填写 UUID。服务端使用哪种安全层、哪种传输、是否要求特定流控，客户端就需要支持对应组合，缺少任意一项都可能连接失败。

REALITY、Vision 与 VLESS 不是三个可以互换的协议名称。VLESS 是代理协议，REALITY 属于安全传输机制，Vision 是特定流控方案。订阅中的公钥、短标识、服务器名称与流控等字段各有作用，不能因为界面没有显示就认为可以删除。客户端支持 VLESS 的基础连接，也不代表支持所有这些扩展。

VLESS 搭配 WebSocket 等传输时，仍需要核对路径、主机头与 TLS 条件；搭配特定流控时，则要确认服务端和客户端所选传输满足要求。不能把一种部署的流控字段复制到另一种部署上。迁移配置时，先保持原有组合，通过连接验证后再考虑调整，避免同时改变协议、传输和 DNS 而无法定位问题。

相同安全层下，差异仍需实测

Trojan 与 VLESS 都可能使用 TLS，握手和证书处理的成本因此有共同部分。但它们的认证、封装与扩展能力不同，不能把所有性能差异都归因于 TLS。实际首包时间还包含 DNS 解析、TCP 建连、安全握手和目标站点响应。只测试一个轻量探测地址，不能完整反映网页中大量资源的加载表现。

如果提供方同时给出这两类节点，先选择字段完整、当前内核明确支持的配置，再观察日常应用。需要多种传输接入现有服务设施时，核对组合的意义大于比较协议名称；只希望稳定使用已有订阅时，不必为了更换标签手工重建节点。服务端维护质量、证书续期与配置更新是否及时，都会直接影响长期可用性。

四、Hysteria2 与 TUIC：QUIC 连接的优势与边界

QUIC 改变了哪一层

QUIC 基于 UDP 承载，集成安全握手、可靠流与连接管理能力。Hysteria2 和 TUIC 围绕这些能力组织代理流量，目标包括减少部分连接开销、改善并发处理和适应复杂链路。但 UDP 只是承载基础，不保证路径更好；如果当前网络对 UDP 有限速、丢弃或严格超时，QUIC 类节点可能比 TCP 类节点更难保持稳定。

QUIC 的多条可靠流可以减少不同流之间由传输层有序交付造成的相互等待，但同一流中的丢失数据仍需处理，所有流还可能共享拥塞窗口和底层链路。它不会消除无线信号波动，也不能突破服务端带宽。网页资源并发较多时可能受益，单个文件下载则仍主要受可用容量、丢包与拥塞控制影响。

连接标识为网络路径变化提供了机制基础，但移动网络切换能否平滑恢复，还依赖协议实现、服务端状态、NAT 与客户端行为。不要把 QUIC 等同于始终不断线。手机从 Wi-Fi 切到蜂窝网络后，应观察原有应用是否恢复、内核是否重新握手，以及系统是否允许后台继续运行，分别判断问题所在。

Hysteria2：带宽参数不是加速倍率

Hysteria2 侧重在不理想链路上提供可调整的传输策略。常见配置包含认证、TLS 及可选的带宽声明等信息，具体拥塞控制行为取决于双方设置。上行与下行声明用于表达链路条件，不是填得越大越好。把有限上行误填为很高的容量，可能引起队列积压、重传和其他应用响应变慢，反而损害整体体验。

核对带宽参数时，先确认填写方向与单位，再考虑实际可用容量。家庭网络标称带宽不等于代理路径持续可用带宽，蜂窝网络更会随信号和负载变化。若无法合理估计，应优先沿用可信配置来源的设置与内核默认行为，不要复制网上的夸张数值；调节后应同时观察吞吐、交互响应和丢包现象。

Hysteria2 与早期 Hysteria 的配置并非简单改名兼容。订阅转换器若混淆类型、认证字段或混淆设置，可能生成能读入但不能连接的节点。涉及混淆、端口跳跃等可选能力时，还需要内核与服务端共同支持。排错应先使用提供方给出的完整配置，确认基础连接，再逐项检查这些扩展条件。

TUIC：并发与 UDP 转发需要共同支持

TUIC 同样利用 QUIC 建立连接，并设计了认证、流转发和 UDP 转发相关机制。不同实现或配置代际可能对认证字段与参数有不同要求，因此不能只依据一个 TUIC 标签判断兼容。导入时应确认当前内核明确支持提供方所用的配置形式；遇到未知字段，优先查看内核日志和订阅目标格式，而不是直接删除字段。

TUIC 的拥塞控制、UDP 转发方式与连接保活等选项会改变运行行为。可靠转发与不可靠数据报各有适用范围：前者重视送达，后者更贴近允许丢失但关注时效的应用。最终效果仍依赖双方实现，不能从选项名称推断所有游戏都会受益。对于实时应用，应使用实际通话或游戏会话观察抖动、断续和恢复时间。

两类 QUIC 节点都需要关注 MTU、路径 UDP 条件和路由器状态。出现小请求正常、大传输卡住时，可以怀疑路径分片或包长相关问题，但不应直接把所有超时归为 MTU。先比较另一网络、查看是否仅 QUIC 节点失败，再按客户端文档调整；同时保留可用的 TCP 类节点作为对照，避免失去判断基准。

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

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

连接“快”至少包含首次响应、持续吞吐、交互抖动和断线恢复几个维度。首次响应受 DNS、建连、安全握手与目标服务处理时间影响；持续吞吐受容量、丢包、拥塞控制和服务端负载影响。一个首次打开较快的节点，未必适合长时间下载；一个下载吞吐较高的节点，也可能在视频会议中出现明显抖动。

客户端的连接测试通常访问指定目标，只能说明这条探测路径的结果。测试目标不同、是否复用连接不同，数字就不适合直接横比。自动选择策略还可能因探测波动频繁切换节点，使长连接应用受到影响。先读清测试方式，再决定是否启用自动选择；对稳定会话而言，固定合适节点往往更容易定位问题。

做对照时，固定设备、网络、目标资源和规则，关闭占用带宽的后台任务，每次只改变一个条件。先测页面冷启动，再测持续传输，最后测空闲后的恢复；多轮交替测试，避免把高峰时段变化算到协议头上。若节点出口或服务端不同，应把结果记录为节点体验，不宣称已经证明某个协议整体更快。

CPU 与内存主要花在哪里

CPU 开销来自加解密、封装、数据复制、规则匹配与协议栈处理。现代设备的硬件加速可能让某些加密方式成本较低，老旧路由器则可能首先卡在单核处理能力。QUIC 的用户态处理、频繁的小包和大量并发也可能增加负担。看到吞吐不足时，要同时检查处理器占用与链路条件，不能只继续更换节点。

内存占用受连接数量、缓冲区、规则集合、DNS 缓存和客户端界面影响。界面进程与内核进程应分开观察，日志级别也要恢复正常，避免长期详细记录增加开销。连接复用可能减少反复握手，但需要维护额外状态；启用更多并发或更大的缓冲并不总有收益，特别是内存较小的路由器和后台受限的手机。

TUN 会增加本机接入和处理环节，DNS 劫持、进程识别与规则匹配也可能改变开销。系统代理与 TUN 的测试结果因此不能直接作为协议对照。如果应用在两种接入方式下走了不同规则，连实际出口都可能不同。比较前应从连接记录确认同一应用、同一目标确实使用同一节点与策略。

电量取决于唤醒、信号与实际流量

移动端耗电不仅来自加密计算。蜂窝无线电保持活跃、弱信号重传、后台保活和应用频繁联网，往往占有较大影响。协议连接保持得更久，可能减少握手，也可能延长无线电活跃时间；较短超时可能降低空闲状态占用，却让后续请求反复重建连接。不存在适用于所有手机的固定省电排名。

对照电量时，固定屏幕亮度、信号条件、使用应用和测试时长，分别观察空闲与持续使用。系统电池统计会受归因方式影响：使用 VPN 接口的流量有时被集中计入客户端，但不代表全部消耗来自代理计算。需要结合总耗电、流量和后台活动判断，不要仅凭客户端在电池榜中的位置下结论。

日常优化先减少无必要的高频检测与详细日志，保留合理的订阅更新间隔，并检查是否有应用持续请求失败后重试。系统电池限制过严又可能终止后台连接，因此应在续航与持续接入之间取舍。Android 检查后台运行权限，iOS 检查 VPN 状态与按需连接设置；这些系统行为不能通过更换协议完全解决。

六、原版、Clash Meta 与 mihomo：内核和客户端关系

家族名称相近，能力不能混用

Clash 最初指代理内核项目，后来也被用作相关配置与客户端生态的统称。原版开源内核、历史上的 Premium 分支，以及后续的 Meta 路线并非同一份功能集合。旧教程若只写“Clash 支持”，可能省略了具体分支前提。遇到规则类型、TUN 或协议扩展时，应寻找明确的内核名称，而不是依靠界面标题判断。

Clash Meta 是在原有生态基础上扩展协议与功能的内核路线，mihomo 延续了这一路线。很多客户端和订阅仍保留 Meta 字样，因此名称不同不一定表示完全不同的配置体系。不过，名称连续也不代表任何时期的构建都支持所有新字段；实际能力以正在运行的内核和相应文档为准，不能按最新资料反推旧安装包。

Premium 曾包含与开源原版不同的能力，其专有配置或脚本机制不应默认可以迁移到 mihomo。某些字段具有相似用途，但实现与语法不同，简单保留可能导致解析失败或行为变化。旧配置迁移时，应先建立最小可运行配置，再逐项恢复规则集、DNS、TUN 和自动化设置，避免把历史功能整体照搬。

客户端负责界面，内核负责执行

客户端提供订阅管理、节点选择、系统代理和日志展示，也可能附带配置覆写与内核更新机制。界面设置通常会生成或修改运行配置，所以磁盘上的原始订阅不一定等于内核最终加载的内容。排查时应查阅客户端提供的运行配置或合并结果，尤其注意 DNS、端口、策略组与 TUN 是否被界面选项覆盖。

新用户按平台优先查看 Clash Plus，再根据需要比较 Clash Verge Rev、FlClash 等客户端。Windows 还可比较 Clash Nyanpasu，Linux 可在 Clash Verge Rev 与 FlClash 之间选择。首推客户端不意味着每个平台的内部实现完全相同；需要某项协议扩展时，仍应核对该平台构建的能力与实际参数支持。

Android 的 Clash Meta for Android 与 Surfboard 也应按各自能力判断。Surfboard 使用自己的配置体系，不能因为同属代理客户端就直接套用 Clash YAML。iOS 可从下载页查看 Clash Plus 的商店入口与官网 clashplus.io。跨系统迁移时，比较的应是具体配置与能力，而不只是应用名称。

归档软件、内核更新与迁移边界

Clash for Windows 与 ClashX Meta 在本站下载清单中标为已停止维护，适合有明确兼容需求的用户查阅。归档客户端可能缺少后续协议字段、系统适配与安全修复，不宜因为旧教程截图熟悉就作为新安装首选。相关区别可继续查看归档客户端说明，再决定保留旧环境还是迁移。

更新客户端与更新内核可能是两个操作，也可能由客户端一起管理。更新前保存本地规则、覆写、策略组命名与系统接入设置，更新后验证订阅解析、规则命中、DNS 和常用应用。不要在同一次变更中同时更换客户端、订阅格式和全部节点，否则出现问题时难以确定是哪一层发生变化。

直接运行 mihomo 适合服务器、路由器和需要自行管理服务的用户，还需要处理进程权限、启动方式、日志与配置路径。桌面用户通常使用 GUI 更方便。内核直跑并不会自动完成透明接入，也不会替代路由、DNS 与防火墙设计；部署之前应明确哪些设备的哪些流量需要进入内核。

七、订阅格式、YAML 配置与迁移兼容

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

订阅是配置的获取方式，不是一种统一文件格式。一个链接返回的可能是编码后的分享链接集合、完整 Clash YAML，或者其他客户端使用的配置。分享链接一般描述单个节点，完整配置还包含策略组、规则、DNS 和监听端口。导入后看见节点列表，不代表原有分流逻辑也被保留，应继续检查策略组与规则。

选择订阅目标格式时，要让提供方输出与实际客户端匹配的内容。传统 Clash 格式、面向 mihomo 扩展的格式与其他应用格式不能笼统互换。格式转换通常能处理常见字段，但新协议扩展、特殊传输和插件参数可能被忽略。转换完成后应核对节点类型与关键参数，不能把“转换成功”当成端到端验证结果。

订阅返回内容还可能随请求方式、账户状态或提供方设置变化。若更新后突然没有节点，先查看是否返回了网页、登录提示或错误说明，再判断是否 YAML 语法问题。不要立即删除原配置；保留可用副本能帮助比较变化。分享排错材料时，只提供去除认证信息后的结构与错误，不公开原始订阅 URL。

配置层次决定覆盖与更新行为

Clash 风格配置中，节点、代理集合、策略组与规则分别承担不同职责。代理集合可从另一个来源加载节点，策略组决定如何选择出口，规则按顺序把请求分配到策略。规则里引用的组名必须存在，名称变化可能造成启动失败或分流变化。订阅更新新增节点，并不一定会自动把它们加入手工写死的策略组。

客户端覆写通常用于保留本地偏好，避免每次订阅更新后重做设置。但合并策略可能是替换、追加或按名称合并，不能假设所有客户端行为一致。尤其要检查规则追加的位置：被放到最终兜底规则之后的条目通常不会生效。先阅读覆写说明，再查看实际运行配置，确认结果符合预期。

下面是可放入相应配置位置的规则片段，示例中的 PROXY 必须对应已存在的策略组。域名规则在前，局域网与区域规则随后，最终由兜底规则处理未匹配连接。它只展示规则顺序，不包含节点或完整 DNS 设置；区域规则还需要相应数据可用，具体匹配效果要结合实际解析与连接记录检查。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - GEOIP,LAN,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

迁移先验证语法，再验证行为

YAML 对缩进和数据类型有要求，缩进应使用空格。密码、特殊字符和容易被误判的数据应按来源要求正确引用，不能在复制时把英文标点替换成中文标点。解析报错先看行号附近的缩进、列表标记和键值关系；若是未知字段或不支持的类型，再检查内核能力，而不是把所有错误都当成格式问题。

迁移可以分三次验证：先确认配置能够加载，再确认一个明确节点能完成访问，最后恢复自动策略与复杂规则。若基础节点可用但域名失败，检查 DNS；若单个节点可用而自动组不可用，检查组成员与探测条件；若系统代理正常而 TUN 失败，检查本机接入与权限。这样的顺序能减少互相干扰。

订阅更新间隔应与提供方变化频率匹配。过于频繁的更新可能触发来源限制，也会增加移动端后台活动；长期不更新则可能保留失效节点或旧证书参数。更新失败时先确认链接与账户状态，再检查网络与返回内容。规则数据和节点订阅可能来自不同来源，需要分别查看更新时间与加载日志。

八、按使用场景选择，并建立排查顺序

桌面办公与移动使用的选择起点

桌面办公优先保证浏览器、开发工具、会议软件的连接路径明确。先在 Clash Plus 等合适客户端中导入完整订阅，用规则模式确认常用目标的命中情况。若应用支持显式代理，可以先用系统代理或应用内代理验证；只有需要接入更多应用时再考虑 TUN，避免把权限、路由与协议问题同时引入。

手机日常使用应优先考虑恢复能力与后台稳定性，而不是只比较下载峰值。保留可信配置的默认传输设置，分别测试 Wi-Fi 和蜂窝网络；若 QUIC 节点仅在某个网络失败，保留 TCP 类节点作为备用。弱信号环境下，应先改善信号或换网络，继续加大带宽声明通常不能解决重传与无线电耗电。

实时语音与游戏要确认应用 UDP 确实进入内核，再检查节点和服务端的转发支持。优先关注抖动、丢包和会话持续性，不以大文件速度代替判断。部分游戏还依赖本地发现、专用端口或地区服务策略，代理仅处理其承载范围内的连接，不能据一个网页访问成功就认定整个游戏网络已经配置完成。

路由器、旁路由与大量并发

路由器使用 mihomo 时，应先核对硬件架构、可用内存与 CPU 能力，再选择协议和规则规模。较复杂的传输组合、较多并发和较大的规则数据可能增加资源压力。出现全屋设备同时变慢时，先观察路由器负载和连接状态，避免把设备处理能力不足误判成所有节点质量下降。

旁路由还需要明确网关、DNS 与回程路径。某个设备能访问、另一个设备不能访问，可能是接入方式不同，而非代理协议不兼容。不要先给所有设备修改协议；先确认默认网关、DNS 去向与路由规则，再验证同一目标。部署边界可参考路由器与旁路由运行 mihomo 概览，与本页的协议选择配合阅读。

按错误阶段逐层缩小范围

第一步检查加载。若内核无法启动或节点没有出现，关注 YAML、订阅格式、未知协议和字段支持。第二步检查连接到服务端：地址解析失败看 DNS，连接拒绝看地址与端口，超时则比较其他网络和其他传输。第三步检查安全握手与认证：证书名称、系统时间、密码、UUID 和扩展参数都应按来源逐项核对。

第四步检查目标访问。服务端连接建立后仍失败，要查看规则命中了哪个策略、目标域名如何解析、是否只有某类请求失败。出现网页正常而应用异常时，优先确认接入方式；出现域名异常而 IP 连接正常时，重点查 DNS。不要通过长期关闭证书验证、任意添加直连规则或删除报错字段来隐藏根因。

第五步才是性能调整。先换同条件节点，再换传输类型，最后逐项改变带宽声明、复用或 TUN 设置。每次记录改了什么、观察到什么，并保留恢复方法。若要提交问题，提供系统、客户端、内核名称、错误阶段和去敏日志；原始订阅、密码与完整配置不应放在公开附件中。

最终选择应是能够解释、能够恢复、能够稳定使用的组合，而不是参数最多的组合。需要继续处理速度问题，可按节点、线路与本地设置三层定位法逐项检查；安装与权限问题回到快速上手文档，零散报错则查看常见问题，避免跨层盲目修改。