代理协议与内核参考.

把客户端、内核和协议分开看

客户端是操作入口，负责显示节点、导入配置、管理系统代理和申请必要权限；内核负责解析配置、匹配规则以及建立连接；协议则约定客户端与服务端怎样认证、封装和转发数据。同一个界面可能允许切换内核，同一个内核也可能被多个界面使用。因此，看到客户端名称里有 Clash，并不能直接推出它支持全部 Clash 配置，更不能据此判断某个节点一定能连接。

节点还不只是一种协议。完整连接通常包含服务器地址、端口、认证信息、传输方式、加密或 TLS 设置，以及可能存在的路径、主机名和附加选项。两个都标成 VLESS 的节点，可以分别使用 TCP 与 WebSocket，证书和服务端部署也可能完全不同。比较之前应先展开节点详情，看清这些条件；只看列表中的类型标签，会把线路差别误认为协议差别。

先筛选可用范围，再讨论性能

第一步确认服务提供方实际交付了哪些类型，以及是否提供 mihomo 可直接读取的配置。第二步检查客户端当前使用的内核，而不是只看应用商店里的介绍。第三步了解当前网络是否允许对应传输，尤其是基于 QUIC 的方案需要 UDP 路径可用。前三步都满足以后，才值得比较打开网页的等待、长下载是否稳定、视频会议有无断续，以及手机待机后的恢复情况。

这种顺序能省掉不少重复操作。若内核根本不识别某个类型，换测速地址不会解决解析错误；若服务端只监听 TCP，客户端勾选 UDP 也不会让服务端新增支持；若证书主机名不匹配，修改规则组不会修复 TLS 握手。先辨认失败发生在导入、解析、连接还是应用请求阶段，再动对应设置，每次只改一类变量，通常比反复重装客户端更有效。

不要把连接模式当成协议类型

规则、全局和直连模式决定连接走向，系统代理与 TUN 决定哪些应用的流量进入内核，它们都不等于节点协议。开启 TUN 可以让更多不读取系统代理的应用进入规则处理，但不会把 SS 变成 Hysteria2，也不会自动补齐服务端的 UDP 转发。相反，接管范围扩大后，原先没有出现的 DNS、局域网访问和其他虚拟网卡冲突也可能浮现。

普通用户应先用已经能导入的配置完成一次稳定连接，再逐步扩大接管范围。在桌面和移动端选客户端时，可先查看首推的 Clash Plus；Linux 桌面则按下载页选择 Clash Verge Rev 或 FlClash。具体平台入口与安装格式见客户端下载页。这里的推荐是操作入口，不代表不同客户端中的同名节点会天然拥有不同的线路质量。

还应给比较确定目标：日常网页关注首次响应和失败率，大文件关注持续吞吐，远程终端关注交互停顿，移动设备关注网络切换和后台恢复。没有目标的综合排名容易让用户为了并不需要的功能增加维护负担。协议只是链路中的一段，服务器负载、出口拥塞、解析位置和应用本身都可能成为主要瓶颈。

Shadowsocks：较小的协议表面

Shadowsocks，常写作 SS，围绕加密代理转发建立了相对直接的配置模型，常见必需项是服务器、端口、密码和加密方法。它不像完整的隧道管理系统那样负责所有路由策略，哪些域名直连、哪些连接转发，通常交给客户端规则。这种职责划分让基础配置容易理解，也方便在资源有限的设备上部署；但实际资源消耗仍取决于实现、算法、并发和流量规模。

阅读 SS 配置时，先区分旧式流加密、常见 AEAD 方法和 Shadowsocks 2022 系列。它们不是单纯的名称更新，密钥形式和实现要求也有区别。尤其是 2022 方法，密码通常需要符合对应算法的编码和长度要求，不能随意替换成一句便于记忆的口令。若内核提示不支持加密方法，应核对精确的算法名及内核能力，而不是把方法改成列表里另一个选项。

SS 还可能附带插件。服务端要求某种插件时，只导入地址、密码和端口可能仍然不够，客户端必须支持对应插件及参数。手机界面能导入一个分享链接，不代表它实现了链接里所有扩展。UDP 也需要两端和中间网络共同支持；游戏或语音不通而网页可用时，应检查 UDP 转发与接管范围，不宜马上判断为密码错误。

VMess：认证与传输组合

VMess 来自 V2Ray 生态，在节点配置中通常使用 UUID 作为用户标识，并将协议认证与底层传输组合起来。常见部署可能配合 TCP、WebSocket 或其他受支持的传输，也可能外加 TLS。它的灵活性意味着配置项更多：除了地址和用户标识，还需要确认传输名称、WebSocket 路径、请求主机名与 TLS 服务器名是否和服务端一致。少一个字段也可能表现为一直等待。

部分旧资料会提到非零的 alterId，以及旧式 VMess 认证。现代配置常见的是 AEAD 方式，mihomo 中通常以 alterId: 0 表达。不能为了让导入通过，就把旧配置中的值机械归零；服务端认证方式也必须匹配。VMess 对时间同步也有要求，系统时间明显偏离时可能认证失败。遇到凭据正确但所有同类节点失败，可以先检查自动校时与时区显示。

如何看待兼容与开销

如果已有稳定的 SS 或 VMess 节点，客户端能完整解析，常用应用也正常，不必只因协议名称较早出现就迁移。成熟配置的优势是容易确认预期行为，问题发生时也有清晰的检查项。真正值得迁移的原因应是内核停止维护、必需功能缺失、服务端调整，或当前网络下重复出现可以验证的性能问题，而不是一次测速排名变化。

也不能把 SS 一概归为省电，把 VMess 一概归为高开销。TLS、外层传输、复用、连接数量和硬件加密能力都会改变结果。一个空闲时频繁探测的简单协议，可能比合理休眠的复杂配置更耗电；一个距离较近的 VMess 节点，也可能比拥塞的 SS 节点响应更快。跨线路测试只能帮助选节点，不能单独证明协议优劣。

QUIC 解决的是哪一层问题

Hysteria2 与 TUIC 都采用基于 QUIC 的设计，底层通常通过 UDP 承载。QUIC 可以把可靠传输、安全握手和多路流管理放到用户态实现中，避免一条 TCP 字节流上的丢包让所有逻辑流都按同一种顺序等待。不过，网络本身的带宽仍然共享，拥塞控制仍然约束发送速度；多路流不等于每条连接获得独立带宽，也不等于丢包以后没有恢复成本。

最先检查的应是 UDP 路径。某些访客网络只允许有限类型的通信，或者对长时间 UDP 会话处理不稳定。此时节点可能在一个网络上正常，在另一个网络上持续超时。切换系统代理与 TUN 只改变本机接管方式，不能保证外部网络放行 UDP。保留一个已经验证可用的 TCP 类节点，通常比继续增加同类 QUIC 节点更有诊断价值。

Hysteria2：带宽设置不是越大越好

Hysteria2 面向存在丢包和延迟波动的连接环境，提供认证、TLS 及拥塞控制相关能力。配置中的带宽参数需要结合内核实现与服务端协商行为理解；它不是订阅服务的带宽承诺，更不是把数值填大就能获得的速度。启用依赖带宽估计的发送策略时，填写远超真实链路能力的值可能增加排队与丢包，影响同一网络里的其他应用。

如果服务端和内核支持协商带宽信息，应先按提供方配置工作；如果需要手动填写，就以当前接入网络的可持续能力为参考，留出交互和其他设备的空间。手机从无线网络切到蜂窝网络后，原来的估计未必仍然合适。Hysteria 与 Hysteria2 也不是可以只改类型名的同一协议，导入时必须确认服务端代际与客户端实现匹配。

TUIC：认证、拥塞控制与会话维护

TUIC 也利用 QUIC 承载代理连接，常见配置涉及 UUID、密码、TLS 服务器名、ALPN 以及拥塞控制选项。不同协议代际和实现之间可能存在兼容差别，分享链接看起来相似也不能证明双方匹配。遇到导入成功却立即断开，应核对协议代际、认证字段和 ALPN，而不是先把心跳间隔缩短。维持一个错误会话并不会修复认证。

两类协议都可能包含 UDP 中继方式、连接保持或握手优化选项。某些零往返机制依赖已建立的会话信息和两端支持，还涉及重放风险边界，并不适合当成通用加速开关。连接迁移能力同样依赖实现和网络路径，不能承诺从无线网络切到蜂窝网络后，所有正在进行的应用会话都原样保留。应用层重连仍然可能发生。

在 UDP 可用、链路确有丢包或波动的环境里，这两类方案值得与现有节点并行测试。但它们也需要加密、计时器和用户态包处理，设备负载与电量表现要实测。不要仅因为一次大文件下载更快，就认定网页、语音、待机和所有网络切换都会一起改善；性能判断仍要回到具体任务。

把等待时间拆成几段

节点列表里的延迟通常来自一次特定探测，不等于应用访问所有网站的真实耗时。完整请求可能经历 DNS 解析、连接服务器、协议认证、TLS 握手、连接目标和等待响应。有的探测复用了已有连接，有的每次新建；有的经过策略组，有的直接测节点。两种客户端显示的数字如果测试条件不同，就不能直接当作同一把尺子比较。

短网页请求容易受首次握手和目标响应影响，长下载更容易暴露带宽、丢包与持续拥塞，远程终端则对偶发的排队和停顿敏感。多路复用可能减少重复连接，却也可能把更多请求聚到一条外层连接上；遇到拥塞时，体验是否改善取决于传输设计和实现。应分别观察首次打开、重复访问与持续传输，避免只用一个下载速度概括日常体验。

资源占用不是协议名称的固定属性

处理器支持的加密指令、操作系统网络栈、内核实现、连接数量和日志级别都会影响资源占用。桌面电脑上差异不明显的设置，在旧手机或路由器上可能成为瓶颈。QUIC 的用户态处理与计时器会带来工作量，传统协议也可能因为插件、多层封装或大量并发增加负担。因此不宜给每种协议写一个跨设备通用的内存或功耗数字。

看任务管理器时，应把客户端界面与内核进程分开。窗口动画、日志滚动、订阅解析和后台更新可能消耗界面进程资源，而实际转发工作发生在另一进程。测试前关闭不必要的实时日志，等待订阅更新完成，保持应用任务一致，再观察处理器占用和持续内存变化。仅看刚启动时的峰值，不能推断长时间使用成本。

手机耗电常常来自唤醒频率

移动端除了加密负载，还要考虑无线模块的活跃时间。频繁健康检查、短间隔心跳、不断失败重试和多个策略组同时测速，都可能让设备反复唤醒。即使每次传输的数据很少，也未必省电。先减少没有必要的探测，避免重复订阅任务，再根据真实会话断开情况决定是否调整保持连接，比单纯更换协议更容易得到可解释的改善。

Android 的 VpnService 用于让客户端接收系统流量，授权成功不代表系统允许它永久留在后台。电池优化、厂商后台管理和自动启动设置都可能影响恢复速度。有关这些设置可以查看Android 后台常驻说明。允许后台运行解决的是进程存活，不应把所有耗电问题都归因于这项授权，也不必为了测试长期关闭全部系统省电策略。

比较时轮流使用候选节点，记录网络、时间、目标和失败现象，至少覆盖平常真正使用的任务。若节点位于不同服务器，结论应写成这个节点在当前条件下更合适，而不是某协议永远更快。手机评估还应留意蜂窝信号强弱与屏幕耗电；这些因素变化很大时，系统电池统计无法独立证明协议带来的差异。

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

订阅地址只是获取资源的入口，并没有统一规定返回内容。一条地址可能返回完整 Clash YAML，也可能是多条分享链接的编码集合，还可能根据请求头返回不同格式。完整配置往往包含节点、策略组、规则和 DNS；节点集合则只负责提供节点数据。二者混用时，常见表现是能看到节点却没有预期策略组，或者导入后提示缺少必需结构。

proxy-providers 用于从独立资源读取节点，再由策略组引用；rule-providers 则负责提供规则集合。它们并不是把任何完整订阅地址放进去都能自动拆分。尤其是规则提供器需要匹配声明的行为和文件格式，不能把域名列表、IP 列表与完整规则行当作同一种内容。排查前先看资源实际返回的结构，再核对引用位置。

转换时容易丢失哪些信息

订阅转换需要把源格式映射到目标内核认识的字段。基础地址和密码通常容易保留，较新的协议选项、插件参数、ALPN、flow、REALITY 设置和某些 UDP 传输选项则可能遇到支持缺口。转换成功只说明生成了目标格式，不代表节点的全部语义都保留。遇到某一类节点集中失败，可以逐项比较原始节点资料与导入后的详情，而不是重复转换同一份内容。

如果提供方能直接交付适合 mihomo 的配置，通常应优先使用对应格式，减少中间映射。确实需要转换时，要了解转换工具是否支持相关协议，以及它是否替换了规则模板和 DNS 设置。订阅 URL 可能包含个人访问凭据，不应提交给不了解的数据处理服务，也不要在公开截图、问题反馈或日志附件中保留完整地址。

用小片段理解结构，不拼接未知字段

下面是一个可以被 mihomo 读取的最小直连配置，用于展示监听端口、策略组和规则的关系，不包含远端节点，也不会建立远端代理连接。它适合在备份之后单独保存到测试文件中做语法检查；不要覆盖正在使用的订阅配置。真实节点应由可信来源提供，不能靠修改这个片段中的名字生成。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,Route

YAML 的缩进表达层级，列表前的短横线和同级键的位置都影响含义。合并多个订阅时，重名节点可能让策略组引用变得含混，重名策略组可能覆盖原有定义，规则顺序变化则会改变首次匹配结果。不能只把两个文件首尾相接。应给来源设置清楚的命名范围，确认所有组引用存在，再检查最终规则是否仍以预期的兜底项结束。

更新失败也不总是格式问题。请求可能超时、认证可能失效、返回内容可能是网页登录页，远程规则集也可能暂时不可达。先看下载状态与返回类型，再看解析错误；不要把订阅失败和节点握手失败混在一起。有关订阅更新的常见情况见订阅问题，关于配置切换与备份可继续阅读Profile 入门。

保留一份能工作的配置快照尤其重要。备份应包含本地规则、策略组选择和覆写逻辑，而不只是订阅地址。分享排错材料时可以保留协议类型、字段名和错误阶段，移除认证内容、个人域名与订阅凭据；这样既便于复现结构问题，也不会把恢复工作变成新的凭据迁移。

日常桌面与 Linux 工作环境

主要使用浏览器、代码托管和桌面办公时，先选维护状态清楚、能够完整读取订阅的客户端，再从现有 SS、VMess、Trojan 或 VLESS 节点中选择稳定的一项。跨设备可先查看 Clash Plus，Linux 桌面按发行版选择 Clash Verge Rev 或 FlClash。是否需要新协议，应由实际故障或功能要求决定，而不是把所有类型凑齐才算配置完整。

Linux 还要区分应用是否遵循系统代理。浏览器能访问而终端工具失败，可能是终端没有读取代理环境；容器和独立网络命名空间也不会天然继承桌面设置。此时先确认接管入口，必要时再按TUN 模式教程处理授权与路由。远程服务器和路由器适合由理解服务管理的用户直接运行内核，普通桌面用户通常更适合图形界面。

移动网络、实时应用与大文件

手机经常在无线与蜂窝网络之间切换时，关注恢复连接、后台存活和电量，而不是只看首次测速。若 UDP 路径稳定，可以把 Hysteria2 或 TUIC 加入候选；若某些接入网络经常超时，保留已经验证的 TCP 类节点作为备选。不要在未确认服务器能力前，把所有节点统一强制复用或开启额外传输选项，这可能让原本独立的问题同时出现。

语音、会议和游戏需要关注实际 UDP 支持、抖动与偶发停顿。协议标签中出现 QUIC，并不保证每个实时应用都受益；应用的服务器位置、转发路径和系统接管范围同样重要。大文件传输则应观察持续速度与设备发热，同时为交互应用保留带宽。某条线路能跑满链路，不代表它在家庭多人共用时是最合适的默认选项。

用一条闭环判断是否值得保留

先保存当前可用配置，选择一个候选节点，固定接入网络和测试目标。依次做一次网页访问、一次持续传输以及一个日常交互任务，查看连接记录中的策略组、匹配规则和实际出站。确认请求确实经过候选节点后，才把体验差异记入结果。若规则让目标直连，测速结论就与所选协议无关，需要先修正测试条件。

失败时按阶段停止：导入失败查格式，启动失败查字段与引用，握手失败查地址、认证和 TLS，请求返回异常再查目标服务与规则，只有部分应用失败则查系统接管和 DNS。每次只修复一个阶段，成功后再继续下一步。连接日志可能包含目标地址等信息，排错结束应恢复适合日常使用的日志级别，不要长期为收集细节保持高频输出。

最终保留的方案应能解释为什么适合当前场景：例如兼容现有订阅、移动网络恢复可靠、长下载更稳定，或者维护项更少。对比过程与节点测速的具体操作可查看测速与验证教程；客户端界面差异可在客户端对比页继续查阅。协议、内核和界面各自解决不同问题，把这三层分清，比追逐一个统一排名更有用。