Clash 协议与内核参考

1. 协议、传输与接管方式分开看

客户端里的一个节点，实际是一组连接参数，不只是协议名称。协议负责规定认证、请求封装和数据交换；传输方式决定这些内容经由什么通道送达；TLS 等安全层负责相应通道的保护；VPN 或 TUN 则决定手机上的流量怎样进入客户端。先分清这几层，才能解释为什么两条都标为 VLESS 的配置，兼容性和连接表现仍然不同。

节点标签不等于完整能力

一个节点通常还包含服务器地址、端口、认证信息、加密方法，以及传输相关设置。部分组合还需要服务器名称、路径或特定握手参数。界面里的名称由配置提供方填写，可以随意修改，不足以判断实际类型。核对时应查看节点详情或导出的配置字段，尤其关注 type、network 与安全层选项，不能仅凭名称里的“高速”或协议缩写下结论。

传输与代理协议并非任意组合。某个内核支持 VLESS，不代表它支持所有 VLESS 传输扩展；某个客户端能导入分享链接，也不代表它能完整表达链接中的每个参数。客户端界面还可能只开放内核能力的一部分。因此，确认兼容性需要同时看服务端配置、内核文档和客户端导入结果，缺少任何一层都可能得到误判。

VPN 图标不说明远端协议

手机状态栏出现 VPN 标识，通常说明客户端获得了系统提供的虚拟网络接口。它表示一种本地接管机制，不等于所有远端连接都采用同一种传统 VPN 协议。流量进入接口后，仍可被规则分配到 SS、Trojan 等代理出站，也可能直接连接目标地址。桌面端的系统代理只覆盖愿意遵守代理设置的程序，与此类接管的覆盖范围不同。

同样，开启 TUN 并不能自动修复协议不兼容。节点参数写错时，接管更多流量只会让更多应用受到影响。排查应先确定客户端能建立到服务端的连接，再检查应用流量有没有进入规则链。若日志中始终没有目标应用的连接记录，应检查接管范围；若已经出现连接但握手失败，则应转向协议参数、证书和网络可达性。

按连接链定位问题

一次访问可以拆成域名解析、本地接管、规则匹配、策略组选路、远端握手和目标请求。实际实现可能交错处理这些环节，但这个顺序适合作为检查框架。例如网站打不开而直连正常，不能立即归因于协议；规则可能选中了另一个出站，DNS 也可能返回不可达地址。每次只改变一处设置，并记录访问对象与时间，才容易把日志与现象对应起来。

2. SS 与 VMess：加密封装与兼容边界

Shadowsocks 常缩写为 SS，设计重点是较精简的代理转发与加密封装。VMess 则来自 V2Ray 生态，在协议层承担认证与数据保护，并常与多种承载方式组合使用。两者都经历过实现与配置方式的变化，因此“支持 SS”或“支持 VMess”只是核对起点。实际能否连接，还取决于具体加密方法、认证配置以及承载层是否一致。

SS 的简单不等于参数可以省略

SS 的核心参数通常比较集中：服务端地址、端口、密码和加密方法。现代配置常使用经过认证的加密方案，但不同方法的密钥处理与封装并不相同，不能因为名称相近就互换。订阅中若使用较新的协议扩展或特定插件，旧内核可能直接拒绝加载，也可能只能识别基础节点而无法建立连接。应按服务端给出的完整组合填写，避免自行替换字段。

加密方法的计算成本与设备硬件有关。支持相应指令加速的芯片，可能高效处理某类算法；另一种算法在不同处理器上却更合适。手机是否发热，还受无线信号、吞吐、后台应用和屏幕亮度影响。不要仅凭“算法名字更短”推断省电，也不要为了尝试性能而随意改动加密方法，因为客户端与服务端必须一致，单边修改通常无法连接。

SS 的 UDP 转发也要单独确认。客户端允许 UDP，并不代表服务端、路由和运营网络都允许对应数据通过。网页主要依赖 TCP 时，可能看不出 UDP 能力缺失；游戏、语音和部分名称解析才会暴露问题。遇到网页正常而实时应用异常，应核对节点 UDP 支持与规则选路，不宜立刻修改全局 DNS 或反复重新导入同一份订阅。

VMess 需要看认证与承载组合

VMess 的常见配置使用 UUID 标识用户，并可能包含安全选项和传输参数。其认证机制涉及时间因素，设备时间明显偏差会导致连接失败。出现此类情况，应先启用系统自动日期与时间，并确认时区与时钟状态正常，再检查服务端认证配置。反复更换 DNS 无法修复认证不一致，这也是按连接层次排查比同时修改多个选项更有效的原因。

VMess over TCP 与 VMess over WebSocket 的路径并不相同。后者还可能经过反向代理，需要正确的路径、请求头和 TLS 设置。服务器地址负责建立底层连接，TLS 服务器名称用于相应握手，WebSocket 的 Host 又属于应用层请求；它们有时相同，有时不同。不能把订阅里所有类似域名的字段统一改成一个值，也不应从其他节点复制一组看似通用的参数。

旧配置迁移时保留差异

历史 VMess 配置可能带有旧认证方式或遗留字段。迁移到新内核时，能够通过语法检查不代表服务端仍接受这种组合。应优先向配置提供方取得适配当前内核的条目，再对照导入前后的关键字段。如果转换工具静默忽略某个参数，界面里仍然可能出现节点名称，但实际连接会在后续阶段失败，不能把“成功导入”等同于完整兼容。

需要保留旧订阅时，可先在独立配置中测试，不要覆盖日常可用配置。若只有个别节点失败，比较该节点的加密方法和承载类型；若全部失败，则检查认证来源、设备时间和整份配置格式。这样可以区分节点自身问题与客户端加载问题，减少重复安装带来的额外操作。

3. Trojan 与 VLESS：安全层与传输搭配

Trojan 通常把代理请求置于 TLS 连接内，借助成熟的 TLS 体系保护传输，并使用密码认证。VLESS 则更强调轻量的协议层设计，通常将数据保护交给外部安全层。二者经常出现在同一类订阅中，但安全职责并不相同。选型时既要看协议名称，也要看 TLS、REALITY 或其他组合要求，不能把某个协议当作天然包含所有安全能力的标签。

Trojan 的关键是正确建立 TLS

Trojan 节点除了服务器、端口和密码，还需要正确处理 TLS 服务器名称与证书验证。连接地址可以是域名或 IP，而用于验证身份的名称必须与服务端证书及配置相符。如果证书过期、链不完整或名称不匹配，客户端可能在认证前就结束连接。此时应查看握手相关日志，先确认时间、名称和证书部署，而不是反复修改代理模式。

关闭证书验证会削弱身份确认，不适合作为长期修复方式。若订阅要求跳过验证，应了解其部署原因与信任边界；自建服务应修正证书链和名称配置。手机网络使用登录门户时，还应先完成无线网络登录，因为门户可能拦截初始请求，表现得像远端 TLS 故障。换一个已确认可用的网络进行对照，能帮助区分本地接入与服务器问题。

Trojan 常见于 TCP 加 TLS 的组合，也有实现提供其他传输方式。额外的 WebSocket 或 gRPC 层通常与反向代理部署有关，不是客户端单方面开启就能获得的优化。它们会增加需要匹配的参数和中间环节。若普通 TCP 方案已满足需求，没有必要仅为了名称更多而叠加承载；若服务端依赖特定路径，则必须按其配置准确保留。

VLESS 的轻量有明确前提

VLESS 协议层本身不负责通用的数据加密，因此导入后必须检查外部安全层，而不能看到 UUID 就认为连接已经得到保护。常见配置会结合 TLS，或使用实现支持的 REALITY 组合。不同组合需要的字段不同，客户端支持 VLESS 也不代表支持所有相关流控与握手方式。应以实际内核的功能文档为准，尤其注意移动端界面是否能保留这些字段。

配置里的 flow 是需要双方支持的协议相关设置，不是通用的速度档位。把其他节点的流控值填入当前节点，可能直接破坏兼容性。REALITY 相关的公钥、短标识和服务器名称也必须来自对应服务端，不能任意拼接。遇到参数不完整时，合理做法是补齐原始信息或使用提供方给出的兼容订阅，而不是靠随机组合试错。

如何判断是否值得更换

如果现有 Trojan 节点稳定，更换为 VLESS 不必然缩短网页打开时间；反过来，轻量的协议头也不能抵消服务端拥塞。先比较连接是否容易建立、长连接是否稳定、切网后是否需要重启，再考虑持续吞吐。对手机用户而言，恢复速度与后台稳定性往往比短时间下载峰值更有实际价值，尤其是在通勤和频繁锁屏的场景下。

排查时可把错误分成连接地址不可达、TLS 或安全层握手失败、用户认证失败、目标转发失败四类。日志措辞随内核不同而变化，应理解阶段而非只搜索固定报错文本。一次只测试一条节点，并暂时固定策略组，避免自动选择过程中换到另一条配置，导致修改与测试对象不一致。

4. Hysteria2 与 TUIC：基于 QUIC 的取舍

Hysteria2 与 TUIC 都建立在 QUIC 相关技术之上，面向代理场景组织可靠流和数据报。QUIC 通常运行于 UDP，在用户态处理连接、加密与拥塞控制。它与“直接把应用 UDP 原样转发”不是同一概念。即使目标网站使用 TCP，代理段仍可能经由 QUIC 承载，因此必须先确认手机到服务器之间的 UDP 路径可用。

QUIC 改变了什么

传统 TCP 字节流需要按序交付，一处丢包可能让同一连接后续数据等待重传。QUIC 能在不同流之间改善这种相互阻塞，但单个可靠流内部仍要保证顺序，也依然受到带宽和拥塞约束。它不是消除丢包的机制，更不能绕过物理链路容量。网络状况良好时，额外的用户态处理未必比成熟 TCP 实现更省资源，应按实际访问体验判断。

QUIC 具备连接迁移相关机制，但手机从 Wi-Fi 切到蜂窝网络时能否平滑恢复，还受协议实现、客户端生命周期、网络地址变化和服务端策略影响。不能把底层技术的能力直接当作每个客户端的保证。测试切网时，应观察已有会话是否恢复、后续新请求能否建立，而不是只看状态栏里的 VPN 标识是否一直存在。

Hysteria2 的带宽参数需要克制

Hysteria2 面向有损和高波动路径提供相应传输设计。在使用带宽估计驱动的发送策略时，填写的上下行数值会参与发送行为，不是展示给用户的测速结果。把数值设得远高于真实可用带宽，可能增加排队、丢包和对其他应用的影响。应理解客户端与服务端的协商方式，再从保守值开始验证；采用其他拥塞控制路径时，也不能照搬同一套经验。

服务端可能对发送行为作出限制，订阅也可能已经包含合适参数。手机流量套餐的标称速率，不等于当前无线环境和远端路径的稳定吞吐。若视频更容易卡顿，同时系统网络队列增长或其他应用明显变慢，继续提高带宽值通常不是正确方向。应先降低目标、缩小测试负载，并检查无线信号与服务端资源是否成为瓶颈。

TUIC 的复用与数据报选择

TUIC 利用 QUIC 的流与数据报能力承载代理请求，认证信息和拥塞控制设置需要双方一致。它的不同实现可能提供 UDP 转发方式、连接保活和零往返相关选项。零往返依赖已建立的信任状态与实现策略，并伴随重放方面的安全考虑，不是每次首次连接都能省去握手。不要为了追求“更快”而盲目启用所有可见开关。

可靠承载与不可靠数据报各有用途。对实时语音或游戏而言，过期数据重传未必有价值；对需要完整交付的请求，则必须由相应层保证可靠性。订阅中的 UDP 模式应符合服务端能力和目标应用需求。如果只有实时应用异常，先比较数据报路径与 MTU 等因素，不宜因为浏览器访问正常就认定整条 QUIC 链路没有问题。

协议升级还可能改变认证和配置结构。Hysteria 与 Hysteria2 不能仅靠修改显示名称互换，TUIC 的不同协议代际也需要对应支持。导入前应确认提供方指的是哪一种实现和格式；界面看不到关键选项时，查看实际配置与内核报错，比反复切换相似名称的节点更有效。

5. 连接速度、资源占用与手机电量

“协议速度”至少包含首次连接耗时、请求响应、持续吞吐和故障恢复四个维度。网页打开慢可能来自 DNS 与握手，文件下载慢可能来自拥塞与服务端限速，游戏卡顿又可能来自抖动和丢包。把这些现象压成一个延迟数字，会掩盖真正的瓶颈。手机上的测试还受温度、电池模式和无线制式变化影响，短时间跑一次并不足以决定长期选择。

延迟测试不能替代实际访问

客户端里的延迟测试通常是向指定地址发起请求，具体是否包含解析、握手和复用，取决于实现与已有连接状态。它不一定是单纯的网络往返时间，也不能代表所有目标网站。两个节点若测试地址不同，结果更不适合直接比较。理解测试方式后，再参考节点延迟与访问验证步骤，用日常目标进行补充检查。

做对照时，尽量在相同位置、同一网络和相近时间段，固定一个策略组选项。先用少量网页请求观察首次响应，再使用合法且稳定的下载源观察持续传输，最后进行锁屏与切网测试。不要同时开启多个测速任务，否则它们会争抢带宽并改变队列状态。记录现象比记录单个峰值更有用，例如是否偶发停顿、重连后能否恢复以及后台是否断流。

CPU、内存与电量不是同一指标

加解密、数据复制、用户态网络栈和规则匹配都会占用计算资源。内存还会受到活动连接数、规则集合、DNS 缓存和日志缓冲影响。某个协议的基础封装较小，并不代表整套配置的内存一定更低；保留大量连接或加载庞大规则集，可能比协议头差异更明显。因此应比较完整配置在相同任务下的表现，而不是给协议排列固定的资源名次。

手机电量同时取决于处理器与无线模块。即使应用 CPU 使用率不高，过于频繁的保活、健康检查和订阅刷新也可能让无线链路反复保持活跃。弱信号下的大量重传会进一步增加耗电。遇到待机掉电，先查看系统电池统计和后台活动，区分客户端、前台应用与无线信号的影响，再调整检测频率，不要仅凭节点类型判断原因。

后台稳定性与检测频率平衡

自动选择策略组通常需要健康检查。检查越密，越容易及时发现变化，但也带来额外请求和连接维护。多个组重复检测同一批节点时，开销会叠加。先确认是否真的需要频繁自动切换，再适当延长间隔或缩小检测范围。对于连接一直稳定的手机，保守设置往往更容易维持可预测的电量表现。

安卓后台限制可按需要为所用客户端调整，但不必关闭所有应用的电池管理。iOS 的网络扩展则受到系统生命周期和资源约束，不能照搬桌面常驻进程的经验。设备发热或系统内存紧张时，应先减少并发测试、详细日志和不必要规则，再判断是否更换客户端。性能优化的目标是日常使用稳定，而不是让所有高级选项同时开启。

6. Clash、Meta 与 mihomo 的内核关系

Clash 既可能指最初的代理内核，也常被用来泛指兼容其配置思路的客户端生态。Meta 是在相关基础上演进的分支名称，mihomo 是这一分支后续使用的内核名称。它们之间有继承关系，但不是所有功能都向前、向后完全兼容。判断一个客户端能运行什么配置，应查实际内核及其能力，不能仅凭应用名字里有没有 Clash 来决定。

内核负责执行，客户端负责交互与集成

内核通常承担节点连接、规则处理、DNS 和策略组等任务；图形客户端负责订阅管理、权限申请、设置界面、后台服务与系统接管。两者边界会随项目变化，但这个区分有助于定位问题。同样的内核放进不同客户端后，配置导入、覆写顺序和系统路由仍可能不同。界面能显示某个开关，也不代表所有平台上的实现细节完全一致。

原版 Clash 的基础配置结构影响了大量订阅格式，但其公开开源实现、曾有的其他发行形态与后续分支不能混为一谈。mihomo 在协议与规则等方面扩展了能力，相应也增加了专有字段。含有新协议或扩展语法的配置，交给较旧或能力不同的内核时可能被拒绝。配置沿用了 YAML 外观，并不意味着语义与功能已经兼容。

选客户端时核对实际能力

本站安装入口首推 Clash Plus，适合先按设备平台查看可用安装方式。涉及特定协议、规则扩展或系统接管能力时，仍应检查对应平台的说明，不能把一个平台上的能力自动套到另一个平台。桌面端还可比较 Clash Verge Rev、FlClash 和 Clash Nyanpasu；安卓可查看 Clash Meta for Android、FlClash 与 Surfboard，各自支持的配置与协议范围需要分别确认。

Surfboard 使用自己的配置体系，不能因为同样能管理代理，就直接把完整 Clash YAML 当作等价输入。Clash for Windows 与 ClashX Meta 属于已停止维护的归档选择，适合识别历史配置或处理旧设备迁移，不宜据此推断当前协议支持。iOS 的安装方式和能力应查看对应应用说明，不能把安卓内核文件直接装入 iOS 客户端。

具体选择可结合客户端选型指南，安装文件与平台入口统一放在下载页。如果客户端允许查看内核信息，记录实际内核名称与构建信息，排查时连同配置中使用的协议类型一起核对。仅提供应用名称而没有内核信息，往往不足以判断某个高级字段为何无法使用。

升级内核与升级应用分别验证

有的客户端随应用一起更新内核，有的提供单独切换入口。更新前应保留当前订阅来源、本地覆写和必要设置，确认可以恢复。不要只备份一份自动生成的运行文件，因为其中可能已经混入客户端重写的端口、路径和系统设置，换设备后不能直接复用。完成更新后先检查加载日志，再验证节点、DNS、规则和后台行为。

如果更新后出现启动异常，应先回到最小可加载配置，区分语法不兼容与系统权限冲突。项目谱系的进一步背景可读Clash、Meta 与 mihomo 的关系梳理。理解名称沿革是为了确认能力来源，不是为了把某个分支名称当作性能或可靠性的统一保证。

7. 订阅格式、字段保留与规则兼容

订阅地址返回的内容可能是完整 YAML、节点列表、分享链接集合，也可能是客户端识别的专用格式。完整配置除了节点，还可能包含策略组、规则、DNS 和远程规则来源；节点列表通常只提供出站信息。导入后看到了节点，不代表已经取得完整的分流方案。先确认订阅类型，再决定由订阅负责规则，还是由本地配置引用这些节点。

语法能解析，语义仍可能不兼容

YAML 缩进、字段类型和列表结构决定文件能否解析；协议支持、策略组引用和规则行为决定配置能否按预期运行。例如某个规则引用了不存在的组，或者节点使用当前内核不支持的类型，即使文件是合法 YAML，也不能得到正确连接。日志中的解析错误、字段错误和运行错误属于不同阶段，应先解决最早出现的问题，避免把后续连带报错逐项当作独立故障。

格式转换不是协议转换。转换工具可以调整字段名称、组织节点和生成规则，却不能凭空给内核增加协议实现，也无法补出缺失的认证参数。源格式没有表达的流控、安全层或数据报设置，在目标配置里可能被省略。复杂节点应对照转换前后的关键字段；无法确认保留情况时，优先索取原生适配目标客户端的配置，而不是层层转码。

规则顺序与名称引用一起核对

Clash 风格规则通常自上而下匹配，先命中的规则决定出站。宽泛规则放得过早，会遮住后面的精细规则。下面是一段规则片段，不是完整配置：它不引用自定义策略组，可用于理解顺序；其中的直连示例也不代表每个用户都应使用同一套分流政策。正式使用时，应根据目标服务与自身需求调整，并确认客户端不会在更新时覆盖本地改动。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

DOMAIN-SUFFIX 按域名后缀匹配，GEOIP 依赖相应地理数据及解析条件，MATCH 用于兜底。需要代理时，应把动作改成实际存在的策略组名称，而不是照抄另一个配置里的组名。涉及 IP 规则时还应理解是否触发域名解析，以及是否使用避免额外解析的相关选项，否则可能误以为域名规则没有生效。

更详细的规则写法见自定义规则与手机端覆写技巧。把本地补充规则放在客户端支持的覆写或合并入口，通常比直接修改远程订阅更容易维护。不同客户端的合并方式可能是替换、追加或专门的脚本处理，不能假定同名列表一定会自动合并，也不能仅凭编辑界面的位置推断最终顺序。

更新失败与内容变化分开处理

更新失败可能来自地址失效、认证过期、下载路径不可达或返回内容格式错误。返回成功也不保证内容有效：登录页面、提示页面或空响应，都可能被保存成所谓配置。应先看更新日志与内容类型，再判断是否需要更改更新请求的出站。切勿把含访问权限的订阅地址贴到公开反馈区，也不要上传到不明转换服务。

迁移设备时，应分别导出远程来源和本地规则，并隐藏认证信息。若只有新设备异常，先用同一份最小配置比较内核能力；若多台设备同时失败，再检查订阅来源和服务端状态。将问题限定到一层，比反复删除所有数据更容易保住原有分流设置。

8. DNS 路径、场景选型与验证顺序

DNS 决定域名如何得到地址，也影响域名规则是否拥有足够信息。它不是代理协议本身，但配置不当会表现为节点可用、部分应用却打不开。所谓 DNS 泄漏，应先明确希望哪些查询走哪条路径，再检查实际是否符合预期。查询使用加密传输，与查询是否经由代理，是两个不同问题；即使启用加密 DNS，请求也可能仍从本地网络直连发出。

分清目标域名与节点域名的解析

客户端既要解析用户访问的域名，也可能要解析代理服务器自己的域名。若解析节点域名又依赖尚未建立的代理，可能形成循环。部分配置通过独立解析器或专门的节点解析设置解决这个问题。调整 DNS 前应查看当前内核的字段含义，不要把其他内核的同名配置机械套入。报错中若首先出现服务器域名解析失败，应先恢复这条基础路径。

Fake-IP 通过分配合成地址，让客户端在后续连接中保留域名关联；另一类模式则返回真实解析结果。Fake-IP 并不修改网站的真实地址，也不等于天然阻止所有旁路查询。局域网发现、某些游戏和自行处理 DNS 的应用可能需要例外。添加例外时要对应具体域名与现象，避免直接把所有域名排除，导致原本需要的域名关联能力失效。

IPv6 同样需要纳入检查。只配置 IPv4 代理路径，而系统或应用仍直接使用 IPv6，可能产生与预期不一致的访问。正确做法是核对双栈路由、客户端接管范围和 DNS 返回策略，再决定是否在特定环境中限制某一栈。关闭 IPv6 可以作为定位手段，但不应被描述为所有手机的通用优化，也不能掩盖接管规则本身不完整的问题。

按使用场景保留适当组合

日常网页和消息场景，优先选择服务端参数完整、首次连接稳定且后台恢复正常的配置。SS、VMess、Trojan 或 VLESS 都可能满足需求，没有必要仅因协议新旧更换可用方案。移动办公应额外测试会议、文件传输与锁屏恢复；需要访问局域网设备时，单独验证直连规则和本地名称解析，避免把打印机或存储设备的请求错误送往远端。

实时语音与游戏需要关注 UDP 支持、抖动和切网行为，不能只比较网页测试值。高波动链路可对照 Hysteria2 或 TUIC，但应先验证 UDP 路径，并保留 TCP 类备用出站。大文件传输则应观察持续吞吐、温度与对其他应用的影响，不要为了追求峰值把带宽估计设得过高。电量敏感时，减少无效重连与重复探测通常比频繁更换协议更直接。

从最小变化开始验证

建议按以下顺序收敛问题：确认网络能正常登录和访问基础服务；确认节点地址能解析且握手参数匹配；固定策略组验证一个目标；检查连接日志命中了哪条规则；最后核对 DNS、IPv6 与系统接管范围。每步保留前后结果，不同时更换内核、订阅和网络。若只在某个应用异常，再检查它是否使用自带解析、特殊传输或不同于浏览器的连接方式。

检测 DNS 路径时，应结合客户端连接记录、解析日志和预期出口综合判断。浏览器页面显示的解析服务商名称，只能作为线索，不能独立证明所有应用的查询都符合预期。临时启用详细日志后及时恢复常用级别，分享记录前移除订阅地址、认证信息和个人访问内容。确认问题已修复后，还应再做一次锁屏、切网和后台验证，避免只修好了前台浏览器。