Clash 协议与内核参考

内核关系：原版 Clash、Meta 与 mihomo

客户端、内核与服务端分别负责什么

客户端是用户操作的界面，负责导入配置、管理订阅、显示策略组，以及请求系统设置代理或建立虚拟网卡。内核负责解析配置、匹配规则、解析域名和建立实际连接。服务端则是远端提供协议入口的程序。三者不能相互替代：更换客户端界面不会自动改变远端协议，把订阅中的类型名称改成另一种协议，也不会让服务端随之支持它。判断兼容性时，应同时核对客户端调用的内核、内核实现的协议，以及服务端要求的参数。

原版 Clash 建立了以 YAML 描述代理、策略组和规则的使用方式，后续生态沿用了不少字段与概念。原版项目已停止维护，其开源实现与曾经存在的 Premium 分支也不是完全相同的功能集合，因此不能把所有标有 Clash 的旧教程视作同一份技术规格。Meta 最初是在这一生态中扩展协议和网络功能的内核项目，后来以 mihomo 名称继续发展。现在看到 Clash Meta 的历史文档时，应结合当前 mihomo 的配置说明理解，而不是仅根据名称判断新旧。

名称继承不代表所有字段双向兼容

mihomo 保留了许多常见配置结构，同时扩展了协议支持、DNS 行为和规则能力。这种兼容主要方便旧配置迁入新实现，不意味着新配置可以交给旧内核运行。包含 VLESS、Hysteria2 或特定 TLS 选项的订阅，可能在老客户端中直接解析失败；也可能成功导入，却在使用某个节点时才出现错误。图形界面显示的客户端版本与内核版本是两条信息，反馈问题时应分别记录，不能只报告安装包名称。

在桌面端确认实际生效的配置

选择客户端时，本站首推 Clash Plus；需要比较其他界面，可在安装包页面查看 Clash Verge Rev、FlClash 等选项。不同客户端可能使用不同的配置管理方式，不应假定每个项目都暴露相同的内核切换入口。进入关于、运行信息或日志页面，查找内核名称，再检查运行配置是否包含订阅内容。客户端还可能把订阅、全局覆写和本地规则合并后交给内核运行，所以原始文件与生效文件存在差异并不一定是异常。

迁移前先导出本地设置并保留原订阅来源，随后用一份已知可用的配置测试。不要同时迁移协议、DNS、TUN 与规则集，否则失败后很难定位变量。有关项目传承与图形界面分工，可继续阅读Clash 开源项目关系图。阅读生态介绍的目的，是找到实际执行连接的组件，而不是把某个项目名称当成兼容性的保证。

SS 与 VMess：轻量转发与认证封装

Shadowsocks 的设计边界

Shadowsocks，通常缩写为 SS，采用相对直接的加密代理模型。客户端向服务端提交目标地址并转发数据，协议本身不要求一套完整的 HTTP 页面或证书体系。它的设计重点是较小的协议负担和清晰的转发职责，而不是把路由、订阅和图形界面都放进协议。SS 节点在客户端中通常需要服务器地址、端口、密码与加密方法。四项必须与服务端一致，其中加密方法是协议参数，不是用户可以任意调整的性能档位。

早期 SS 使用过流加密方法，后续 AEAD 方案把机密性与完整性保护结合起来；Shadowsocks 2022 又采用了不同的密钥与会话设计。看到同样的 SS 标签，不代表这些实现可以互换。尤其是要求特定长度、编码格式密钥的方案，不能把普通文本密码直接填进去。选型时应优先确认双方支持的现代方法，而不是为了兼容旧客户端随意降低参数。处理器是否具备相应加速能力，也会影响不同方法的实际资源开销。

SS 的 TCP 与 UDP 转发能力需要分别核实。浏览器打开网页成功，只能说明这条访问路径能够建立，不能证明游戏、语音或其他 UDP 应用同样可用。某些 SS 配置还依赖额外插件，插件名称、参数和客户端支持情况也属于连接条件。基础 SS 节点可以用，附带插件的节点却失败时，应先检查插件实现与参数，而不是认定服务器整体故障。协议本体和外加传输层应分开理解。

VMess 的身份与传输选项

VMess 来自 V2Ray 生态，在代理请求中包含身份认证与数据保护机制，并允许搭配不同传输方式。常见配置会出现 UUID、加密设置、TLS 开关，以及 WebSocket 等传输参数。VMess 的历史配置涉及旧认证方式与后续 AEAD 机制，导入旧订阅时需要注意服务端和内核的支持范围。不要因为教程出现某个历史字段，就照抄到现有节点；服务端给出的配置语义才是判断依据，客户端也可能不再兼容部分旧组合。

VMess 对系统时间有要求。设备时钟明显偏离真实时间时，认证可能失败，表现却像普通连接超时。排错时先确认系统自动校时是否正常，再核对 UUID 和传输层设置。如果使用 WebSocket，路径与 Host 等信息应保持服务端要求的写法；如果外层启用 TLS，还要检查证书对应的名称。每增加一层封装，就多一组需要匹配的参数，成功导入订阅并不等于这些参数已被验证。

两类节点怎样比较

在相同服务条件下，基础 SS 的协议路径通常较简单；VMess 的实际开销则受加密和外层传输影响。但跨服务器比较时，距离、带宽、拥塞与服务端限制往往比封装差异更明显。已有稳定 SS 节点且应用需求得到满足时，没有必要只为更换标签而迁移。需要使用 VMess 时，应选择服务端完整提供的参数组合，并保留一条已验证的路径用于对照。对普通用户而言，参数完整、长期稳定且维护清楚，比协议名称本身更有决策价值。

Trojan 与 VLESS：认证和 TLS 的职责划分

Trojan：以 TLS 承担连接保护

Trojan 的设计把代理认证放在 TLS 连接中，使用密码识别客户端，并由 TLS 提供传输的机密性和完整性保护。它不是把某个 HTTPS 网站地址直接当作代理，也不是只填写密码就能建立连接。服务端地址、监听端口、密码、TLS 名称和证书信任关系需要一起成立。客户端通常通过系统或内核的信任配置验证服务端证书，证书过期、名称不匹配或设备时间异常，都可能在代理认证之前导致握手失败。

配置中用于拨号的服务器地址与用于 TLS 校验的名称可以不同，但这种区别必须来自服务端的实际部署。服务器字段决定连接到哪里，SNI 通常用于 TLS 握手时指示目标服务，证书校验则检查对端身份是否符合预期。随意把 SNI 改为另一个域名，不能修复证书问题。遇到验证失败，应检查正确名称、证书链和设备时钟，不应把跳过证书验证当成长期默认方案，否则会失去对服务端身份的重要检查。

VLESS：轻量认证不等于单独提供加密

VLESS 在 V2Ray/Xray 相关生态中形成，简化了协议层的认证与转发设计，常用 UUID 识别用户。VLESS 本身不提供与外层 TLS 等价的内容加密，因此讨论安全性时必须说明完整组合。VLESS 配合 TLS、REALITY 或其他受支持的传输方案，与只有一个 VLESS 类型标签不是同一件事。用户应导入服务提供方给出的整组参数，不要将“轻量”理解成省略连接保护，也不要把某个实现支持的扩展推断为所有客户端都支持。

REALITY 是特定实现提供的握手机制，并非普通证书模式的另一个拼写。配置可能需要公钥、短标识和服务名称等信息，这些值必须与服务端一致。某些 VLESS 组合还涉及 flow，例如 Vision 相关模式；flow 不是越长越好，也不是所有传输都应启用。服务端没有指定时，不要从其他节点复制。出现未知字段、握手失败或连接后立即断开，应优先核对内核支持和完整参数组合，而不是仅检查 UUID 是否正确。

传输层叠加后的性能判断

Trojan 与 VLESS 都可能因为传输组合不同而出现明显差异。直接建立 TCP 与 TLS 连接，和再叠加 WebSocket 或其他应用层传输，其握手与封装成本并不相同。外层服务的空闲超时、连接复用和中间网络设备，也会影响稳定性。评价节点时应记录完整组合，例如类型、是否启用 TLS、传输方式，而不是只记录 Trojan 或 VLESS 两个标签。服务端连接数限制与资源分配同样可能成为瓶颈。

如果用途主要是日常网页和远程工作，优先选择证书有效、参数完整且能稳定复测的配置。仅凭 VLESS 不在协议层重复加密，不能推导出其必然比 Trojan 更快；仅凭 Trojan 使用 TLS，也不能推导出其一定更耗电。实际成本包含整个连接栈。发生异常时先保持 TLS 校验开启，读取错误类别，再分别验证拨号地址、服务名称和身份参数，避免通过放宽安全选项掩盖真正的不匹配。

Hysteria2 与 TUIC：基于 QUIC 的传输取舍

QUIC 改变了哪一层

Hysteria2 与 TUIC 都利用 QUIC，但它们不是同一个协议的不同名称。QUIC 通常运行在 UDP 上，将加密握手、可靠传输与多路流管理结合起来。对于多条独立流，某条流丢失的数据不必像共享一条 TCP 字节流那样阻塞其他流的交付。不过，所有流仍可能共享连接的拥塞状态与带宽，所以“减少队头阻塞”不等于“丢包没有代价”。底层 UDP 不可达时，QUIC 也无法凭空建立连接。

代理承载应用 TCP 流量时，应用看见的仍可以是一条可靠连接，外部承载则由协议负责。应用本身的 UDP 数据报通常走另一套转发语义。两者的可靠性要求不同，不能因为代理运行在 UDP 上，就认为所有应用数据都变成不可靠传输。反过来，也不能认为所有数据报都会获得与 TCP 完全相同的保证。判断实时语音、游戏与文件传输表现时，需要分别检查应用流量类型和代理的实际处理方式。

Hysteria2：带宽配置与拥塞行为

Hysteria2 面向吞吐和复杂链路条件设计，提供与带宽估计、拥塞控制相关的机制。配置中的上行和下行带宽参数不是购买带宽的凭证，也不是填写越大速度越快。它们会影响实现对发送速率的判断，实际行为还取决于服务端策略和协商结果。过高估计可能导致排队、丢包或与其他应用争用链路；过低估计则可能限制可用吞吐。只有服务提供方明确要求并说明单位时，才应调整这些参数。

还应区分 Hysteria 的代际。标为 Hysteria 的旧节点并不等于 Hysteria2，类型、认证和参数不能只通过改名完成迁移。部分部署使用额外混淆或端口相关设置，这些都要按服务端要求匹配。看到客户端支持 Hysteria2，只能说明存在相应实现，不能保证支持订阅里所有扩展项。排查时先确认协议代际，再确认 UDP 路径、认证信息和 TLS 名称；不要直接把复杂选项全部打开作为尝试。

TUIC：连接复用与转发方式

TUIC 同样以 QUIC 承载代理连接，关注连接复用和 UDP 转发等需求。常见配置会包含 UUID、密码、拥塞控制算法以及 UDP 转发模式。不同协议修订或不同实现的兼容范围可能不同，类型名称一致也需要继续核对。某些选项会改变数据报如何通过 QUIC 发送，影响开销、丢包处理和路径要求；这些选项属于服务端与客户端共同约定的行为，不是可以脱离对端任意切换的优化按钮。

QUIC 包头、加密和用户态传输处理也消耗资源。在高吞吐场景下，较旧设备可能出现 CPU 占用增加；在无线网络切换时，是否能够平滑维持连接，还取决于协议实现、地址变化和服务端策略。不能因为 QUIC 具有连接迁移相关能力，就保证手机切换网络后所有会话都不断开。需要重新认证的应用也可能主动建立新连接，这与代理是否保留会话并不是同一层面的事情。

选择 Hysteria2 或 TUIC 的前提，是服务端支持、内核兼容且当前网络适合 UDP。对大文件和多流任务，可以在真实使用时段做重复对照；对耗电敏感的移动设备，则应同时观察温度、后台活动和网络切换后的恢复情况。保留一个 TCP 系列节点作为对照更容易定位问题，但它应作为独立候选配置存在，不要把一个 QUIC 节点的类型直接改成 TCP 协议尝试连接。

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

把“快”拆成四个可观察阶段

点击网页到内容出现，至少涉及域名解析、连接建立、首批响应和后续传输四个阶段。节点延迟测试通常只覆盖其中一部分，还会受测试 URL、连接复用与缓存影响。短握手不一定带来更高下载速度，高带宽也不一定让小网页更早出现。比较协议时，应先确定要解决的是首次打开慢、持续下载慢，还是偶发断连。三种现象对应的瓶颈不同，用一个测试数字概括容易得出相反结论。

首次建立连接时，TCP、TLS 或 QUIC 的握手都可能占用往返时间，但实际成本会受到会话恢复、已有连接复用与实现策略影响。不要用固定握手次数给所有节点排序。远端服务的响应时间、DNS 查询位置以及是否复用连接，也会影响用户感受。若第一次打开慢、随后正常，可分别检查冷启动解析和握手；若持续传输才变慢，则更应关注拥塞、服务器限速和设备处理能力。

公平比较需要控制变量

尽量选相近地区、相近服务条件和相同测试目标，在同一设备与同一接入网络中交替测试。每次记录协议的完整传输组合，固定策略组选择，并确认规则没有把其中一次访问送到直连。不要同时更换节点、DNS 和 TUN 状态，也不要用一边后台下载、一边空闲的结果对比。测试顺序可以轮换，避免前一个测试刚好遇到空闲链路、后一个碰到高峰，误把时间差解释成协议差异。

移动端的成本往往来自唤醒

手机电量不仅消耗在加密计算上，还消耗在无线通信、后台唤醒和持续重连上。过于频繁的保活会让连接更容易保持，但也可能增加无线电活跃时间；过长的间隔又可能让路由器或运营网络清理空闲映射，导致后续重新握手。具体取舍与接入网络有关。不要为所有协议统一套用网上流传的极短保活间隔，也不要只凭锁屏几分钟的电量变化判断长期表现。

系统代理与 TUN 的作用范围也会改变耗电观测。系统代理主要影响遵循系统代理设置的应用，TUN 则可能接管更多流量，连带处理更多 DNS 和连接事件。同一节点切换到 TUN 后耗电增加，原因可能是工作量扩大，而不是协议突然变差。调试级日志、频繁自动测试策略组和高频订阅刷新，也会增加额外活动。比较之前应统一这些设置，并保留足够长的观察时间。

桌面端可同时观察内核进程的 CPU、内存和连接行为；移动端则结合系统电池统计、发热和后台限制判断。短暂吞吐峰值触发 CPU 占用并不等于持续异常，内存缓存增长也不必然代表泄漏。真正有价值的是相同工作负载下的重复趋势。最终选择应以常用应用的响应与稳定性为主，把测试结果当作定位工具，而不是为协议制作脱离环境的速度榜或电量排名。

订阅格式与配置兼容：从导入到生效

先分清节点列表与完整配置

订阅 URL 是取得内容的地址，不是格式本身。同一个地址可能根据参数或客户端标识返回不同内容。Clash YAML 通常包含代理、策略组和规则；节点分享链接可能只包含一条连接的信息；Base64 列表往往只是多条分享链接的编码集合。文件扩展名或网页上的下载按钮文案不能保证实际内容符合预期。导入前应确认提供方明确标注的目标格式，遇到解析错误时查看内容类型，不要反复更改链接的字符碰碰运气。

mihomo 配置中，proxies 描述连接参数，proxy-groups 组织策略，rules 决定流量使用哪个策略。只拿到节点列表时，客户端可能代为生成策略组，也可能要求用户补齐完整配置。导入成功后只有节点、没有可用规则，与协议不兼容是不同问题。相关格式的具体导入路径可查阅订阅链接与本地 YAML 文件导入说明，不要把配置生成行为误认成协议自动转换。

格式转换不能补出缺失信息

转换工具可以重排已有字段，但不能推断丢失的密码、TLS 名称或服务端特定参数，也不能让旧内核实现尚未支持的协议。某些分享格式无法完整表达复杂传输选项，转换后看似得到合法 YAML，实际却丢失关键字段。若来源同时提供专用于 mihomo 的订阅，应优先使用适配输出，再检查客户端是否仍进行了二次处理。涉及订阅地址的工具还会接触访问凭据，使用前应了解处理位置和保存方式。

YAML 的缩进、字段类型和引用关系也属于兼容性的一部分。端口通常应是数字，布尔值使用 true 或 false，名称引用则必须与目标对象一致。策略组名称写成 Proxy，规则却指向另一个拼写，会造成策略不存在。语法能被 YAML 解析器读懂，也不意味着字段符合内核的配置模式。应依次区分格式错误、配置语义错误和运行时连接错误，不要用重新安装客户端处理所有情况。

# 本地入口与路由片段；Proxy 策略组需在完整配置中定义
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

上面是合并进完整配置的示意片段，不包含服务端凭据。mixed-port 设置 HTTP 与 SOCKS 共用的本地入口；allow-lan: false 不向局域网开放这一代理入口；mode: rule 让请求按规则匹配；log-level: info 用于常规运行观察。端口可以按实际环境修改，这些值不代表所有客户端的出厂设置。规则从上向下匹配，首条命中后使用指定策略，末尾 MATCH 承接剩余请求。

订阅更新、覆写与配置迁移

直接修改订阅生成的文件，下一次更新可能覆盖改动。优先使用客户端提供的覆写、扩展或合并入口，并确认它们在更新后仍会执行。不同客户端对数组是替换还是追加，处理方式可能不同；规则追加到 MATCH 后面通常无法达到预期效果。关于插入位置，可参阅自定义规则语法与优先级。迁移时先保留节点与基本策略，验证后再恢复 DNS、规则集和其他扩展，逐项确认运行配置而不是只看编辑器中的文本。

按使用场景选择协议与客户端

日常网页、办公与持续下载

日常浏览与远程工作优先考虑稳定建立连接、证书验证正常，以及常用服务能否持续访问。若现有 SS、Trojan 或 VLESS 配置已经满足这些条件，不必为了较新的协议名称更换。办公应用可能维持长连接，也可能受单位网络的访问策略约束，应先确认允许的使用方式。遇到远程桌面或协作工具断开时，检查空闲超时和网络切换，比只测一次网页延迟更贴近问题本身。

持续下载需要关注长时间吞吐、丢包恢复与服务器限制。UDP 路径正常时，可把 Hysteria2 或 TUIC 作为对照候选，但不是默认赢家。若链路本身带宽有限，任何协议都无法突破实际接入能力。过于激进的发送策略还可能拖慢同一网络中的视频会议和其他设备。比较时应同时观察下载任务与其他应用的响应，选择能满足整体工作负载的配置，而不是只保留短时峰值最高的一条。

语音、游戏与移动网络

实时应用对抖动、丢包和突发停顿更敏感，平均吞吐反而可能不是主要指标。首先确认应用确实经过代理，以及节点和内核支持需要的 UDP 转发。有些应用不会遵循系统代理设置，单独开启系统代理并不足以覆盖它们；需要 TUN 时，应先完成权限与路由检查。协议承载了 UDP，也不等于远端出口、目标服务或中间网络一定允许相应数据。应通过连接记录核对目标和出口。

手机频繁在 Wi-Fi 与蜂窝网络间切换时，重点观察恢复速度、后台重连与锁屏行为。一个在固定宽带中表现优秀的 QUIC 节点，可能在另一个接入环境中受到 UDP 路径影响；一个普通 TCP 系列节点，也可能因服务端空闲超时而频繁重建。应在真实通勤或移动场景中评估，而不是把桌面端结果直接搬到手机。对电量敏感时，先减少不必要的后台探测，再比较协议差异。

客户端选择以配置支持为入口

首次安装时可优先查看 Clash Plus，再根据系统与操作习惯比较其他客户端。Windows 下载页还提供 Clash Verge Rev、FlClash 和 Clash Nyanpasu；Clash for Windows 标为已停止维护。macOS 可比较 Clash Plus、Clash Verge Rev 与 FlClash，ClashX Meta 为停止维护的归档项目。旧项目能读入部分订阅，不代表适合承担新的协议扩展；应避免用历史界面截图推断当前内核能力。

Android 可按下载页顺序比较 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard，逐个核对目标协议和订阅格式，不要假定所有选项具有完全一致的配置语法。iOS 首推 Clash Plus，官网为 clashplus.io；Linux 可比较 Clash Verge Rev 与 FlClash。普通桌面用户通常先选图形客户端，只有明确需要自行管理进程、服务与权限时，才直接部署 mihomo 内核。

可把决策顺序固定为：当前设备支持什么，服务端提供什么，接入网络允许什么，最后才比较性能。对每个候选保留完整参数说明和一次成功验证记录，避免后续只剩一个无法解释的节点名称。多个候选并存时，用手动选择固定测试出口，再逐步启用自动策略。若自动选择掩盖了真实出口，就无法判断提升来自协议、服务器还是策略组切换。有关操作路径可回到使用指南，术语含义可查名词解释。

验证与排错：按错误发生的层次定位

先确认请求进入了客户端

排查从本地入口开始，而不是先更换协议。确认内核运行、配置加载成功，再核对系统代理所指的地址和端口。若应用不遵循系统代理，检查是否需要 TUN 以及相应权限。打开一个明确的测试目标后，在连接记录中查找目标域名、命中规则与出口策略。完全没有记录时，优先检查应用的代理设置、例外名单和路由接管；已经出现记录却走 DIRECT 时，重点检查模式与规则，而不是远端节点密码。

需要独立验证本地入口时，可以在已安装 curl 的终端中使用下面的短命令。端口应与实际运行配置一致；如果修改过混合端口，就同步调整命令。返回响应只表明本次请求完成，仍应结合连接记录确认出口。命令使用普通公开网页作为请求目标，不代表该目标能覆盖所有应用协议，也不能替代 UDP 应用的独立验证。

curl -I --proxy http://127.0.0.1:7890 https://example.com/

把解析、握手与认证错误分开

出现域名解析失败时，先分清失败的是代理服务器域名还是最终访问目标。前者会阻止建立任何远端连接，后者则可能只影响特定网站。直接把服务器替换为 IP 有时会改变 TLS 名称处理，因此即便做临时对照，也应保留服务端要求的名称设置。连接超时通常意味着在限定时间内没有完成某个阶段，并不自动等于密码错误；错误日志若没有给出更细原因，应通过其他可用节点和网络环境交叉验证。

TLS 错误优先核对系统时间、证书有效期、服务名称与信任链。认证错误再检查密码、UUID、密钥格式及服务端是否允许当前账户。VMess 还要注意时间偏差，VLESS 要确认 flow 与外层方案，Hysteria2 和 TUIC 则先确认协议代际、UDP 路径和相关认证字段。不要为了消除一条报错同时关闭验证、更换 DNS 和修改传输方式；一次只改一个已识别的变量，结果才具有解释价值。

能连接但应用异常时检查中间环节

如果小网页正常、大传输停顿，应检查路径 MTU、丢包、服务器限制与设备资源。QUIC 对数据报路径有具体要求，异常网络设备或受限路径可能导致建立或传输问题；但不要未经验证就套用统一 MTU 数值。若只有一个应用失败，检查该应用是否使用独立 DNS、自己的代理设置或不受系统代理影响的连接方式。若只有某个域名失败，核对规则和 DNS 结果，不能据此判定整个协议失效。

订阅更新失败属于取得配置的链路，不一定是运行中节点的链路。浏览器能访问订阅地址，也不保证客户端更新时使用相同代理与信任环境。可参考订阅更新失败与自动刷新设置分别检查超时、证书和格式错误。不要公开完整订阅 URL：路径或查询参数可能带有账户访问凭据，截图和日志都应遮盖。节点密码、UUID 及其他身份参数也不应出现在公开反馈中。

保留可复现结果，再决定是否迁移

一份有效的问题记录应包含操作系统、客户端名称、实际内核、协议及传输组合、错误发生阶段，以及已做过的单变量测试。必要时短暂提高日志级别，复现后恢复常规设置，避免长期产生过量记录。若新配置失败而旧配置正常，先比较字段与支持范围；若所有节点同时失败，先检查本机网络和入口。更多通用问题见帮助中心。只有明确发现内核能力不足或项目已停止维护，再计划迁移，比反复重装更容易得到稳定结果。