Clash 协议详解
mihomo 内核与兼容性

连接分层：协议、传输与出站路径

先区分四个配置层次

客户端界面常把协议、节点、代理组放在相邻位置，但三者不是同一对象。协议规定客户端如何与服务端认证和交换数据；节点是包含地址、端口、凭据及传输参数的配置实例；代理组负责在多个出站之间选择。规则再决定某个连接交给哪个代理组。同一种协议可以有很多节点，同一个代理组也可以容纳不同协议。因此，切换节点后速度变化，不能直接归因于协议变化，还可能来自线路、服务器负载或目标网站。

传输层还要单独辨认。某些协议直接工作在 TCP 连接上，某些可以搭配 WebSocket 或 gRPC，另一些以 QUIC 为基础。TLS 则提供身份验证与加密通道，可以与不同应用层协议组合。界面里出现 VLESS，并不意味着连接已经具有 TLS；出现 WebSocket，也不等于使用了一种独立的加密协议。阅读参数时，应把协议类型、底层传输、安全层和服务端身份四项分别确认，避免只看名称判断能力。

应用流量如何进入内核

系统代理通过操作系统设置告知应用使用 HTTP 或 SOCKS 入口，是否遵循取决于应用自身。TUN 模式通过虚拟网卡与路由接管符合条件的流量，覆盖范围通常更广，但也引入权限、路由与 DNS 协调问题。入口方式和远端协议彼此独立：打开 TUN 不会把 SS 节点变成 QUIC 节点，关闭系统代理也不必然停止已经由 TUN 接管的连接。排错前先判断流量有没有进入内核，再判断远端握手是否成功。

一次访问通常经过域名解析、规则匹配、策略选择、连接服务端、访问目标几个环节。具体先后会受 DNS 模式、域名规则和已有解析缓存影响。例如 IP 类规则可能触发解析，带有 no-resolve 的规则则限制该规则主动进行域名解析。若日志显示 DIRECT，问题可能在规则或模式，而不是节点协议；若日志显示握手失败，才应继续检查认证、时间、证书与传输字段。

延迟、吞吐与可用性分开记录

节点延迟往往是客户端经代理访问某个测试地址所需的时间，可能包含连接建立、TLS 协商、服务端转发与网站响应。它不是单纯的网络往返时间，也不代表大文件下载速度。吞吐量则受路径带宽、拥塞控制、窗口、目标限速和设备处理能力共同影响。可用性关注连接是否稳定成功。一个小请求返回很快的节点，可能在持续下载中受限；一个首次连接较慢的节点，也可能在连接复用后表现稳定。

比较协议时，最好保持服务端地区、测试目标、客户端版本和入口方式一致，并分别测试冷启动请求、连续浏览与持续传输。如果这些条件无法统一，应把结果称为当前节点组合的表现，而不是协议结论。日志中的超时也需要区分解析超时、连接超时和读取超时。前者优先排查 DNS，中间检查路径与端口，后者再观察服务端和目标站点。先建立这套分层模型，后续参数取舍才有明确依据。

SS 与 VMess：轻量转发和会话认证

Shadowsocks 的设计重心

Shadowsocks 通常简称 SS，设计重心是以相对精简的协议承载代理流量。常见配置由服务端、端口、密码和加密方法构成，不要求像 HTTPS 那样必须配置域名证书。其历史实现包含不同代际，不能把所有 SS 节点视作一种完全相同的线协议。传统流加密、AEAD 和 Shadowsocks 2022 在密钥处理、消息格式与实现要求上存在区别。选择时首先核对客户端支持的具体加密方法，而不是仅确认界面里有 SS 选项。

AEAD 将加密与完整性保护结合，密钥长度、密码派生或编码方式依方法而异。Shadowsocks 2022 的密钥有明确格式要求，不能把普通文本密码直接替换进去。服务端声明的方法必须与客户端一致，凭据也应原样使用。加密算法的实际开销还取决于处理器指令支持；某种方法在桌面设备上运行轻快，不代表在较老的移动设备或路由器上也有相同优势。应避免依据算法名称做跨设备的性能排序。

TCP、UDP 与插件不是同一个开关

SS 可以承载 TCP，也有 UDP 转发机制，但实际可用性需要客户端、服务端和网络路径同时支持。客户端启用 UDP，只表示允许相关转发，并不能补齐服务端缺失的能力。部分节点还依赖额外插件提供传输封装，插件名称、模式和参数都属于配置的一部分。只复制地址与密码，可能可以导入，却无法完成连接。对于来源明确的订阅，应优先保留原配置，不应凭经验删除看起来陌生的插件字段。

如果 TCP 浏览正常而游戏或语音异常，应先确认应用确实进入代理、规则命中了该节点，再检查 UDP 支持和回程。DNS 请求成功并不能证明任意 UDP 应用都能工作，因为 DNS 可能由内核经另一条路径处理。遇到大包异常，还需要考虑路径 MTU 与分片问题。此时单纯更换加密方法通常缺乏针对性，反而会增加变量，使原本能够工作的 TCP 连接也失效。

VMess 的背景与认证约束

VMess 来自 V2Ray 生态，协议本身承担认证及数据保护，并能与多种传输方式组合。常见节点使用 UUID 标识用户，历史配置中还可能出现旧式认证相关字段。当前实现多围绕 AEAD 工作，但旧订阅与不同内核对历史字段的处理并不完全一致。不能把某个旧客户端曾经接受配置，等同于所有新内核都会以相同方式解释。迁移时应先获取适合目标内核的配置，再处理历史兼容选项。

VMess 的认证涉及时间有效性，因此系统时间明显偏差可能表现为认证失败。应先开启系统时间同步，再检查 UUID 和服务端设置。若节点采用 WebSocket，还要检查路径与 Host；若启用 TLS，则继续核对 SNI 与证书。UUID 正确只是必要条件之一。把所有失败都理解为凭据错误，容易忽略底层传输未建立的情况，也会导致反复重新导入订阅却没有改善。

在已知链路上，SS 适合优先考虑配置精简与实现成熟度的用户；VMess 则适合已有相应服务端与传输配置的环境。这是维护成本上的取舍，不是质量高低的结论。若现有节点稳定，单凭协议较早出现就替换没有充分理由；若需要现代传输能力，也应先核对服务端是否提供，而不是只在客户端下拉框中改变协议类型。

Trojan 与 VLESS：认证和安全层的组合

Trojan 将安全职责交给 TLS

Trojan 的设计以 TLS 通道为基础，在通道内完成代理认证与数据交换。与协议内部自行承担全部加密职责的方案相比，这种分工依赖成熟的 TLS 实现和证书体系。客户端常见参数包括地址、端口、密码与服务端名称。它的配置项看起来不多，但域名解析、证书有效性和服务端部署必须一致。能连接到端口，不代表 TLS 身份验证通过；TLS 成功，也不代表密码认证一定成功。

连接地址与 SNI 可以不同。连接地址用于找到服务器，SNI 用于在 TLS 握手中表明期望访问的服务名称，证书校验也需要与预期身份匹配。服务端使用多站点部署时，SNI 错误可能使请求落到另一套证书或服务。直接把域名替换成 IP 后出现证书错误，不应立即关闭校验，而应检查原配置是否要求独立的服务端名称，以及该名称是否与服务端提供的证书一致。

VLESS 的轻量来自职责拆分

VLESS 同样源自 V2Ray 相关生态，其设计移除了 VMess 协议层的内置加密负担，把用户标识与外部安全传输分开。UUID 主要用于认证，不应理解成加密密钥。没有配置适当安全层的 VLESS 连接，不能仅凭协议名称推断通信内容受到保密保护。实际使用中必须看清 TLS、REALITY 或其他部署要求，且相关能力需要客户端内核与服务端共同支持。

REALITY 是另一种需要专门支持的安全握手机制，不能简单当作普通 TLS 的别名。公钥、短标识和服务端名称等参数都有特定语义，不能从普通证书配置随意拼装。VLESS 的 flow 也不是通用加速按钮，只有在指定传输和服务端配置匹配时才成立。客户端若不认识相关字段，删除字段后能够导入，并不代表语义仍然正确；更稳妥的方式是确认目标内核支持并重新获取匹配配置。

WebSocket、gRPC 与复用的成本

WebSocket 将双向数据放在 HTTP 升级后的连接中，路径、请求头与服务端入口需要一致。gRPC 通常依赖 HTTP/2，服务名称、连接协商和反向代理配置同样会影响结果。这些封装可以适配既有部署，但也会增加协议层次和故障定位环节。原生 TCP、WebSocket 与 gRPC 没有脱离部署条件的统一速度顺序；中间代理、连接复用和服务器资源配置常常比封装本身更影响体验。

复用能够减少重复建连，但共享连接也可能让多个请求共同受到拥塞或底层连接异常影响。并非每个服务端都支持相同复用方案，也不是所有短连接工作负载都会受益。排查时可以在服务端允许的前提下对照复用开关，观察新连接耗时、持续传输与错误恢复，而不是只看一次节点延迟。不要同时改动复用、传输方式和 DNS，否则无法知道改善来自哪一项。

Trojan 适合已经具有正确 TLS 部署、希望维持清晰认证路径的环境；VLESS 更强调认证与安全传输的灵活组合，代价是用户需要识别更多组合条件。两者在客户端中的填写方式可能相似，却不能互换密码和 UUID，也不能只修改类型字段完成转换。选择前保留原始订阅，并在连接详情中检查实际采用的出站类型；有需要时参阅内核功能与配置兼容性笔记确认支持边界。

Hysteria2 与 TUIC：QUIC 和 UDP 路径

QUIC 改变传输方式，不改变物理链路

QUIC 以 UDP 为承载，在用户态实现可靠传输、拥塞控制与安全握手。它可以让不同数据流减少因单个流丢包而产生的传输层相互等待，但并不意味着丢包没有代价，也不能突破路径带宽。所有流仍然共享连接的拥塞状态与实际网络资源。把 QUIC 简化成更快的 UDP 容易误判：UDP 只是底层承载，可靠性、确认与流量控制依然需要协议实现承担。

Hysteria2 与 TUIC 都利用 QUIC，但它们是不同协议，认证字段、转发机制和参数语义不相同。服务端只提供其中一种时，客户端不能通过修改类型把它转换成另一种。网络必须允许到服务端的 UDP 通信，运营网络、企业网关、路由器或服务端防火墙中的任何一环限制 UDP，都可能导致连接失败。浏览器能打开普通 HTTPS 网站，只能证明 TCP 路径基本可用，不能证明 QUIC 节点的 UDP 路径可用。

Hysteria2 的带宽参数要贴近实际

Hysteria2 面向复杂链路提供基于 QUIC 的代理传输，并支持与带宽预期有关的拥塞控制选择。不同模式下带宽字段的作用并不完全相同，还可能受到服务端策略约束。填写很大的上行、下行数值不等于获得更大带宽，过于激进的预期反而可能造成排队、丢包和其他应用延迟升高。应根据当前接入网络与服务器限制保守配置，观察持续传输时交互请求是否同时恶化。

上行能力尤其容易被忽略。家庭宽带或移动网络的上行可能明显弱于下行，确认报文、应用上传和其他设备会共享这一资源。若仅在下载时出现通话卡顿，应先判断是否发生队列积压，而不是直接增加下载带宽值。Hysteria 与 Hysteria2 也不是可互换的同名写法，导入时需要确认服务端明确提供哪一代协议。认证信息、混淆设置和 TLS 参数应一并保留，不能只迁移一个密码字段。

TUIC 的会话、证书与实现匹配

TUIC 同样利用 QUIC 承载代理连接，其实现可结合可靠数据流和数据报机制处理不同业务。用户配置时需要关注实现支持的协议代际、UUID 与密码等认证参数，以及证书和服务端名称。某些实现暴露零往返、拥塞控制或 UDP 转发模式选项，但这些不是独立可用的开关集合，必须与服务端能力对应。订阅转换工具如果遗漏相关参数，节点即使成功出现在列表中，也可能无法正常转发。

零往返可以降低符合条件的恢复连接开销，但需要此前会话状态，并存在重放相关边界，不能保证首次连接也省去所有等待。移动设备更换网络后是否平滑恢复，还取决于连接迁移实现、地址变化、NAT 状态与客户端生命周期管理。QUIC 在协议层具备相应机制，不代表任何客户端在 Wi-Fi 与蜂窝切换时都不会断连。应使用实际应用验证恢复，而不是依据协议介绍推断体验。

这两类协议适合在 UDP 路径可靠、服务端部署匹配时作为候选。若经常经过不确定的访客网络，应保留一个 TCP 类节点作为独立备用，而不是反复修改同一份 QUIC 配置。备用的意义是覆盖不同路径条件，不是预设某一种协议始终更优。

性能与电量：测量方法和资源取舍

连接速度需要拆成不同指标

首次连接耗时包含 DNS、到服务端的握手、协议认证，以及到目标的连接建立；已复用连接则可能省去其中一部分。页面加载还依赖多个域名和并发请求，因此一次测试地址的结果不能代表整个页面。比较时应同时记录首个响应、页面完成时间、持续下载和错误次数。只有明确哪一个环节拖慢体验，才知道应该更换节点、调整 DNS，还是检查握手与复用，而不是统一追求最小延迟数字。

吞吐量测试要避免把测试源本身的限速算到节点头上。优先使用固定、可信的测试目标，在相近时段进行多轮对照，测试期间暂停其他大流量任务。服务端位置和出口线路不同的两份配置，只能用于实际使用选择，不能用于证明协议优劣。持续下载会消耗流量并改变设备温度，移动网络下尤其需要控制测试时长。测试结果保留网络类型、入口模式和设备状态，比只保存一个速率更有参考价值。

CPU、内存与 TUN 开销

加密、解密、封装、包处理和规则匹配都会消耗处理器资源。高带宽下，用户态 QUIC 可能产生较多运算与数据包处理工作；某些具备硬件加速的加密方法则可能在特定设备上更高效。这些都是条件性判断。不能把 TCP 协议统一称为省电，也不能认定 QUIC 一定占用更多内存。连接数量、缓冲区、内核实现和应用请求模式同样影响结果，需要在目标设备上观察。

TUN 增加虚拟网卡与协议栈处理，DNS 接管、流量嗅探和大量连接记录也可能带来额外工作。如果系统代理已经覆盖日常应用，可以先用系统代理建立基线，再启用 TUN 比较覆盖范围和资源变化。需要 TUN 时，不应为了降低一点占用牺牲必要功能，但可以检查是否开启了不需要的调试日志、过密的自动测速或重复 DNS 查询。内存较高也可能只是缓存积累，应区分稳定占用与持续增长。

移动端耗电往往来自唤醒频率

手机电量不仅消耗在加密运算上，还与无线模块保持活跃、后台唤醒、信号强弱和重连有关。保活频率过高会增加唤醒，频率过低又可能让 NAT 映射过期，造成下一次请求重建连接。不存在适用于所有蜂窝网络的统一最优值。若锁屏后经常断线，先检查客户端后台权限和系统省电限制，再检查连接保活；只把保活改得非常频繁，可能让表面可用性改善，却明显增加待机消耗。

比较耗电时，应保持屏幕亮度、网络类型、后台应用和工作负载接近，并分别观察主动使用与锁屏待机。一次短时电量百分比变化容易受到电池估算误差影响，不适合做细微排序。可结合系统电池统计、后台活动时间、设备温度和连接日志判断。若客户端不断尝试连接一个不可达节点，即使实际传输很少也可能耗电；这时修正可用性和重试策略通常比更换加密算法更有效。

一套可复用的验证流程是：先在固定网络确认节点可用，再连续完成浏览、下载、语音或游戏等真实任务，随后观察锁屏恢复和网络切换，最后记录电池与错误情况。每次只改变协议或一个相关参数，至少进行重复对照。若低延迟伴随更高温度和更频繁重连，应按实际任务权衡，而不是认定测试数字更小的方案就是最终选择。关于模式变量，可对照规则、全局与直连模式说明。

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

客户端界面和代理内核分开判断

图形客户端负责订阅管理、系统代理、服务安装、交互界面与平台集成；内核负责解析配置、匹配规则和执行出站连接。相似界面不等于相同能力，同一个客户端在更换内核后也可能表现不同。用户询问是否支持 VLESS 或 Hysteria2 时，需要同时给出客户端名称与内核信息。仅凭应用名称包含 Clash，无法判断协议、TUN 或规则字段是否受支持，更不能保证一份配置可以直接迁移。

原版 Clash 建立了规则驱动代理、代理组和 YAML 配置的基础使用方式。Clash Premium 曾提供不同于普通开源版本的扩展能力，不能把它当作所有原版构建的统一特性清单。Clash.Meta 在相关生态基础上扩展协议与配置能力，项目后来以 mihomo 名称发展。Meta 与 mihomo 的关系更接近项目延续，而不是两个必须并列安装的服务。旧教程仍可能使用 Meta 字样，阅读时需要结合具体内核能力判断。

共同语法不等于完整向后兼容

代理、代理组、规则等基础结构具有较强延续性，但新增协议、DNS 选项、规则类型和 TUN 字段可能超出旧内核范围。旧配置进入新内核也不一定毫无变化：字段默认值、过时选项处理和平台实现可能不同。解析成功只说明配置被接受，不能证明连接路径与过去一致。迁移后的验证至少应覆盖订阅节点、代理组选择、域名分流、局域网访问与 DNS 行为，避免仅以启动成功作为完成标准。

操作系统同样影响功能边界。TUN 的权限、系统服务、虚拟网卡与路由实现存在平台差异；桌面端能工作的配置不必然可以原样用于手机。部分图形客户端会生成或覆盖内核配置，用户直接编辑运行文件后，订阅刷新或重启可能恢复默认内容。修改前应确认客户端提供的是配置覆盖、合并脚本还是原文件编辑入口，并把长期定制放在适当层级，避免将界面行为误判成内核不支持。

迁移时先检查，再替换

对独立运行的 mihomo，可以使用下方命令检查指定目录中的配置。目录中需要有准备使用的 config.yaml 及相关本地依赖，命令路径则按实际安装位置调整。检查不会替代真实连接测试，但能提前发现不少格式、引用和字段问题。图形客户端若提供配置检查，应优先使用其入口，因为运行目录、合并过程和权限可能由客户端管理，直接在另一个目录执行命令不一定复现实际环境。

mihomo -t -d ./profile

客户端下载可以先从 Clash Plus 开始比较，具体平台入口见下载中心。Windows 另有 Clash Verge Rev、FlClash、Clash Nyanpasu；macOS 可比较 Clash Verge Rev 与 FlClash；Linux 可比较 Clash Verge Rev 与 FlClash。Clash for Windows 和 ClashX Meta 已停止维护，适合识别历史环境，不宜只因熟悉界面而忽略维护状态。最终仍以所选客户端实际内核、平台支持与现有配置为准，不把推荐顺序当成协议能力证明。

订阅兼容：格式、字段与覆盖关系

订阅地址不是统一文件格式

订阅本质上是通过地址获取一份数据，返回内容可以是完整 YAML、代理提供器内容，也可以是分享链接集合及其编码文本。链接都以 HTTPS 开头，只说明获取方式相同，不代表客户端能够按同一种格式读取。有的服务根据请求参数或客户端标识返回不同内容，复制同一个地址到不同应用后结果可能不同。导入失败时应先确定返回格式，不要立即断言节点协议不兼容，更不要反复更换认证信息。

完整配置一般包含代理、代理组、规则，可能还包含 DNS、监听端口和控制接口等设置。代理提供器通常只提供节点集合，需要主配置引用；分享链接则主要描述单个连接，往往不包含规则和完整 DNS 策略。把节点列表作为完整配置导入，可能缺少分流结构；把完整配置放进只接受节点集合的入口，也可能解析失败。应先区分客户端的订阅导入、配置导入与提供器管理入口，再选择对应格式。

转换可以重排字段，不能补造能力

订阅转换工具可以解析分享链接、生成 YAML 或套用规则模板，但不能让旧内核理解不存在的协议，也不能从缺失信息中可靠还原证书、flow 或 QUIC 参数。转换器不认识某些扩展字段时，可能报错，也可能直接丢弃；后者更难发现，因为节点看起来已经导入成功。遇到新协议，优先使用服务方直接提供的目标内核格式，并比较转换前后参数，而不是把能显示节点数量当作转换完整性的证据。

订阅地址通常包含访问凭据，完整配置也可能包含节点密码和 UUID。排错时应在本地查看必要字段，分享日志或截图前遮蔽敏感内容，不把完整订阅提交给不明第三方服务。需要转换时，先了解转换过程是否会把原始地址和内容发送到远端。客户端能读取的配置本身也是一种能力边界：规则提供器、外部资源与控制接口可能改变网络行为，应仅导入来源明确且能够理解用途的内容。

本地覆盖与远端更新要分层

订阅刷新后，本地修改消失通常不是保存失败，而是远端内容覆盖了同一层文件。适合长期保留的规则、DNS 设置或端口定制，应通过客户端支持的合并或覆盖机制管理。合并顺序尤其重要：同名代理组可能替换原有成员，规则追加到 MATCH 后面可能永远无法匹配。先确认是替换整个字段、追加列表还是按名称合并，再决定修改位置。名称中的空格与大小写也应保持一致，避免引用指向不存在的对象。

下面片段用于说明规则结构，适用于已经定义了 Proxy 代理组的配置。局域网目标先直连，指定域名交给代理组，其余连接由最后一行兜底。它不是完整节点订阅，不应单独当作可连接配置导入。no-resolve 只约束这条 IP 规则的解析行为，不会全局关闭 DNS。实际分流还应结合已有规则顺序，不能机械覆盖服务方提供的整个列表。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,github.com,Proxy
  - MATCH,Proxy

维护时保留一份可工作的配置备份，更新后先检查解析结果，再测试代表性节点与常用规则。若只有个别新协议节点失败，优先检查字段和内核；若全部节点失败，先看订阅获取结果、系统时间与本地入口；若连接正常但分流变化，检查规则和覆盖顺序。详细匹配方法可参阅GEOIP 与 DOMAIN-SUFFIX 分流实践。将故障归到正确层级，才能避免用协议更换去处理规则问题。

场景选型：候选协议与验证闭环

日常浏览和桌面办公

日常浏览优先考虑连接稳定、订阅维护清晰和规则可控，而不是追求协议名称更新。已有可靠 SS、VMess 或 Trojan 节点时，可以先建立日常基线；需要 VLESS、Hysteria2 或 TUIC 时，再确认内核和服务端组合。办公网络若存在明确代理要求，应遵循所在网络的使用规则，并避免同时运行多个争用系统代理、路由或 DNS 的客户端。客户端选择可先看 Clash Plus，再按平台比较其他选项。

浏览器正常、桌面应用失败时，不要立刻换协议。先检查应用是否遵循系统代理、是否具有独立代理设置，以及它的连接是否出现在客户端日志中。确有覆盖需求时再评估 TUN。局域网打印、文件共享和开发服务需要保留合适的直连路径，否则代理可用也可能影响办公体验。相关原理见TUN 虚拟网卡接管说明，实际开启步骤则由教程页承接。

移动网络、实时通信与持续下载

移动端先测网络切换、锁屏恢复和待机活动。Android 可从 Clash Plus 开始，并比较 Clash Meta for Android、FlClash 或 Surfboard 的实际格式与功能支持；iOS 可查看 Clash Plus 的商店入口及官网 clashplus.io。这些客户端不应被假定为内核与订阅格式完全相同，尤其不能因为都能导入一个链接，就认为所有协议扩展和规则行为一致。

语音、游戏等任务关注抖动、丢包和 UDP 可用性，单次 HTTP 延迟不足以判断。先确认应用进入正确出站，再在实际会话中观察断续、恢复和延迟波动。Hysteria2 或 TUIC 可以列入候选，但网络限制 UDP 时应使用匹配条件的其他方案。大文件下载则关注持续吞吐、温度与其他任务是否被排队影响；达到接入带宽后继续提高带宽预期通常没有收益，反而可能降低并行交互体验。

路由器、服务器与受限资源设备

路由器和服务器更看重常驻稳定性、配置可重复部署与故障恢复。独立 mihomo 内核适合需要自行管理进程和配置的用户，普通桌面用户通常先用图形客户端更容易维护。处理器架构、可用内存、系统权限和 TUN 支持需要逐项确认；不能把桌面端的吞吐测试直接套用到低功耗设备。规则集规模、连接数量和日志写入也会影响资源，应先用简单配置建立基线，再逐步增加功能。

设备级代理会影响多个终端，变更前应准备回退方案。保留原配置与已验证节点，先在少量流量上测试，再扩大接管范围。DNS 若同时由路由器、客户端和其他服务处理，要明确各自职责，避免循环查询。服务器出口若有防火墙限制，应分别检查 TCP 和 UDP，而不是通过降低证书校验要求尝试解决。协议连接失败与路由、权限失败属于不同问题，处理措施也应不同。

最终决策可以按固定顺序完成：先排除内核或服务端不支持的组合，再排除当前网络不可用的传输，接着用真实任务比较延迟、吞吐、温度与恢复，最后保留一个不同传输路径的备用节点。不要同时改变协议、DNS、TUN 和分流规则。每次调整后确认常用网站、局域网与实时应用，出现回归就恢复上一份已验证配置。协议选型不是一次性的排行榜，而是在明确条件下建立可解释、可维护的连接方案。