Clash 协议与内核选型

协议、传输与内核的分工

客户端界面不是协议实现本身

在 Clash 中看到一个连接条目，实际涉及多个层次。协议定义身份验证、目标地址描述以及数据封装方式；传输决定这些数据通过 TCP、WebSocket 或其他载体送达；TLS 等安全层负责相应的加密与服务端身份验证。三者常被压缩在同一个分享链接里，但不能混为一谈。看到 VLESS 名称，并不能据此断定它一定启用了 TLS，也不能确定底层使用哪一种传输。

图形客户端负责订阅管理、托盘菜单、系统代理和配置编辑，内核负责连接建立、规则匹配、DNS 与数据转发。界面能显示某个协议名称，不代表随附内核一定支持该协议的全部扩展；内核能识别参数，也不代表界面编辑器能完整保存这些参数。判断兼容性，应同时查看客户端说明、实际运行的内核，以及最终交给内核的配置，而不是只看安装包名称。

原版 Clash、Meta 与 mihomo 的关系

原版 Clash 建立了代理条目、策略组、规则与配置文件的基本使用方式。Clash.Meta 在这一生态上扩展协议和网络功能，后来沿用 mihomo 名称继续发展。因而旧资料里的 Meta 内核与现有 mihomo 资料有明显继承关系，但不意味着任意历史配置都能直接通用。某个功能何时加入、字段是否改名、默认行为是否调整，都需要结合实际内核文档确认。

尤其要区分原版开源内核、历史 Premium 分支与后来的衍生内核。旧教程提到的脚本、规则提供者或虚拟网卡功能，可能面向不同分支，不能仅凭“Clash 配置”四个字照搬。迁移时先保留代理条目与简单策略组，再逐步恢复 DNS、规则集和 TUN；一次加入所有高级字段，会让解析错误与运行行为变化叠在一起，难以定位。

先确认能力，再比较界面

Windows 新用户可先从下载页首推的 Clash Plus 入手，再根据配置需要比较 Clash Verge Rev、FlClash 或 Clash Nyanpasu。选择界面时，优先确认订阅能否导入、所需协议能否运行、系统代理与服务模式是否易于管理。不要因为两个客户端都能导入同一链接，就推断它们的 DNS、覆写顺序与 TUN 行为完全相同。

归档客户端更需要谨慎。Clash for Windows 已停止维护，保留旧环境或核对历史配置时有参考价值，但不适合用来推断新协议支持情况。内核替换也不是通用升级办法：客户端可能依赖特定控制接口、启动参数或目录结构。若界面没有提供明确的内核管理入口，应使用受支持的更新方式，而不是直接覆盖可执行文件。

SS 与 VMess：加密封装与连接组织

SS 的简洁结构与方法兼容

Shadowsocks 通常简称 SS，设计重点是较直接的加密代理封装。客户端与服务端约定服务器地址、端口、加密方法和密钥材料，再转发目标连接。它没有要求每条连接都模拟网页请求，也不强制叠加完整的证书体系，因此在配置较简单、双方能力明确的环境中容易管理。但结构简洁不等于任意组合都可连接，加密方法不一致仍会在早期直接失败。

阅读配置时，首先检查 cipher 与 password。传统 AEAD 方法与 Shadowsocks 2022 系列并非同一套密钥约定，后者对密钥长度与表示方式有具体要求，不能把普通短密码直接填进去。若服务端给出的分享链接包含特殊字符，应保留原始编码；手动拆解再粘贴时，多一个空格、错误解码或漏掉后缀，都可能表现为能够连到端口却不能完成通信。

部分 SS 条目还依赖插件。插件负责附加传输或其他封装，并不是 SS 核心协议的必选组成。内核支持某个加密方法，不代表同时支持分享链接所需的插件及其选项。排查时应把服务器、加密方法、插件名称和插件参数分别核对；只删除插件字段来消除配置报错，通常只会把问题从解析阶段推迟到握手阶段。

VMess 的身份验证与历史选项

VMess 来自 V2Ray 生态，结合用户标识、请求认证与数据加密机制，常见配置以 UUID 标识用户。它既可以运行在较直接的 TCP 连接上，也可能与 WebSocket、TLS 等组合使用。实际成本由整套组合决定：如果比较一个裸 TCP 条目和一个叠加 TLS、WebSocket 的条目，看到的差异不应全部归因于 VMess 协议本身。

旧资料常出现 alterId。它属于历史兼容语境，不宜按照旧教程随意填写。现代 AEAD 使用方式通常采用零值，但最终仍需与服务端要求一致。系统时间也值得检查：涉及时间窗口的认证机制可能因明显的时钟偏差失败。Windows 睡眠恢复、虚拟机暂停或手动改时间后，先同步系统时钟，比连续更换 UUID 更有针对性。

传输参数必须成对理解。WebSocket 的路径、请求 Host 与 TLS 的服务器名称可能相同，也可能承担不同职责；路径拼错时，远端可能返回普通网页或拒绝升级连接，而不是明确提示“协议参数错误”。用户应以服务端提供的完整参数为准，不能看到一个域名就把它复制到所有字段，也不要把浏览器能访问该域名当作代理握手正常的证明。

两类协议如何取舍

若已有稳定可用的 SS 配置，使用场景主要是网页、代码仓库和日常应用，没有必要仅因其他协议名字较新就迁移。SS 的参数较少，便于定位错误；但扩展插件与新加密方法会增加兼容条件。VMess 则常见于已有 V2Ray 配置体系，优势在于能衔接现有部署和传输组合，代价是需要同时维护更多相互关联的字段。

UDP 应单独验证。一个条目能打开网页，只说明相应的 TCP 业务链路可用，不能证明游戏语音、实时通信或其他 UDP 流量能够转发。还要核对协议实现、服务端设置、配置中的 UDP 开关，以及应用流量是否实际进入客户端。测试时保留同一网络、同一目标与同一种接管方式，否则难以区分协议能力与本地路由差异。

Trojan 与 VLESS：认证与安全层分离

Trojan 为什么依赖正确的 TLS

Trojan 的常见部署以 TLS 承载代理请求，在安全连接中完成口令认证和目标转发。它把成熟的 TLS 能力作为重要基础，因此证书验证不是可有可无的附加选项。配置里的服务器地址可以是 IP，证书对应的名称却通常是域名；这时需要理解连接地址与 TLS 服务器名称的分工，而不是要求所有字段填写同一个字符串。

客户端建立 TLS 时，会检查证书链是否受信任、有效期是否正确、名称是否匹配。任一环节失败，都可能阻止后续的 Trojan 认证。遇到证书错误，应先确认域名、系统时间和服务端证书配置；长期启用跳过验证会削弱对远端身份的确认能力，也可能掩盖连接到了错误服务器的问题。临时排查与长期配置应明确区分。

口令正确也不代表传输一定一致。有些部署使用直接 TLS，有些还附加 WebSocket 或其他承载方式，客户端必须按实际组合设置。若服务端只接受直接 TLS，而本地多加了 WebSocket 路径，连接不会因为密码正确而自动协商成功。订阅导入后尤其要检查转换工具是否保留了网络类型，以及相关扩展是否被当前内核识别。

VLESS 的轻量认证不等于完整加密

VLESS 同样来自 V2Ray 相关生态，设计上减少协议自身的部分开销，把安全保护更多交给外部传输层。常见部署采用 UUID 进行用户识别，并配合 TLS 或其他受支持的安全机制。这里最重要的边界是：VLESS 名称本身不保证链路已经加密。应查看实际安全层与传输参数，不能仅凭客户端列出的协议标签判断连接的保护方式。

VLESS 的兼容问题往往集中在扩展组合，例如特定的 flow、传输类型或 REALITY 相关字段。支持 VLESS 基础协议，不等于支持所有扩展，也不等于可以任意搭配。某些流控选项只适用于特定传输与安全组合；将他处看到的参数直接加进配置，可能被解析器接受，却在连接时失败。应以服务端约定和当前内核支持范围为准。

REALITY 也不能简化成“换一个服务器名称”。其连接涉及公钥、短标识及其他协商参数，客户端与服务端必须匹配。公钥属于需要准确传递的配置材料，而不是让用户随意生成一个字符串填入。遇到导入不完整时，应获取适配当前客户端的订阅，或逐项核对原始配置，不要用随机值补齐缺失字段来通过界面检查。

域名字段分别解决什么问题

连接服务器地址决定数据包发往哪里，TLS 的 SNI 用于握手中的名称指示，证书验证名称用于确认服务端身份，HTTP Host 则属于应用层请求信息。这些字段在简单部署中经常一致，但逻辑上并不是同一个概念。排错时先标明每个值来自哪里，再判断是否符合服务端要求，比把所有域名统一替换为某个“能打开的网站”更可靠。

选择 Trojan 或 VLESS，应先考虑现有服务端支持与配置完整度。若服务端提供标准 Trojan TLS 参数，且证书维护清楚，通常更容易按常规 TLS 流程检查。若服务端明确要求 VLESS 的某种扩展，应选择已确认支持该组合的客户端与内核。不要为了减少几个配置字段而去掉安全层，也不要为了追求新功能在稳定配置中叠加不需要的扩展。

Hysteria2 与 TUIC：基于 QUIC 的取舍

QUIC 带来的变化与前提

QUIC 在 UDP 之上提供安全连接、多路复用与拥塞控制等能力。与多个逻辑流共用一条 TCP 连接相比，QUIC 能避免某个流的数据丢失在传输层直接阻塞其他独立流，但同一流内部仍然需要按要求处理丢失数据。它并不消除丢包，也不会把受限带宽变成额外容量。网络是否允许持续的 UDP 通信，是讨论相关协议之前的基础条件。

Hysteria2 与 TUIC 都利用 QUIC，但它们不是可以互换名称的同一种协议。认证方式、UDP 转发组织、拥塞控制选项和具体参数存在差异。服务端使用其中一种时，不能在客户端里仅切换协议类型并沿用剩余字段。尤其不要把旧代 Hysteria 的配置直接视为 Hysteria2 配置，两者有明确的协议与配置差异。

Hysteria2 的带宽估计与发送行为

Hysteria2 的设计关注高延迟、丢包等复杂链路中的传输表现，提供与带宽设定和拥塞控制相关的机制。配置中的上行、下行带宽并不是测速结果展示，而可能参与实际发送策略。填写远超可用链路的数值，不一定更快，反而可能造成队列积压、额外丢包和交互延迟。带宽参数应按当前实现说明、服务端限制和真实接入能力设置。

某些实现可根据带宽配置或协商条件选择不同的拥塞控制行为，因此“留空一定更快”与“填满一定更快”都不成立。共享网络中，其他用户和应用也在争用上行队列；即使下载方向容量充足，上行被占满仍会影响确认与交互。测试时应观察网页响应、语音稳定性和持续传输，而不是只看一次大文件下载峰值。

端口跳跃、混淆与其他可选功能也需要服务端配合。开启后若本地防火墙、网络设备或服务端规则没有放行对应 UDP 范围，可能出现连接偶尔建立、随后中断的现象。这些功能不是性能问题的通用修复开关。基础连接尚未稳定时，应先使用服务端确认可用的简单配置，再逐项恢复额外选项。

TUIC 的连接复用与 UDP 处理

TUIC 同样重视利用 QUIC 传输代理流量，常见配置包含 UUID、密码、拥塞控制及 UDP 中继模式。它的不同协议代际并不保证互通，订阅转换时若只保留类型名称而丢失认证字段，导入成功也无法连接。UDP 中继模式会影响报文如何承载，应确认客户端与服务端支持同样的行为，不要把网上某个模式名称当作所有环境的固定答案。

零往返相关选项可在满足条件时降低恢复连接的等待，但不是首次连接的普遍加速按钮。它涉及会话恢复、安全取舍和服务端支持；协议库提供能力，也不代表应用会在所有情况下使用。对日常用户而言，稳定的证书、正确的认证和合适的空闲超时，通常比盲目开启所有低延迟选项更值得优先检查。

如果网络对 UDP 限制较多，Hysteria2 与 TUIC 可能都不适合作为唯一连接方式。保留一个经过验证的 TCP 类条目作为对照，有助于区分服务端问题与接入网络限制。切换 Wi-Fi 和移动网络后应重新验证，因为两种网络的 UDP 空闲映射、路径 MTU 与拥塞状况可能不同；不能把办公室测试结果直接用于通勤场景。

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

把“快”拆成可比较的指标

连接速度至少包含三个不同问题：新连接多久建立、交互请求多久返回、长时间传输能达到多少吞吐。某个协议减少握手等待，不一定提高长文件下载速度；某个配置适合持续传输，也可能让小请求等待更久。客户端显示的延迟通常只是特定测试地址与测试方法的结果，它不等同于所有应用的往返时间，更不能直接代表网页完整加载耗时。

影响结果的因素包括本地接入、服务器负载、目标站响应、链路路由、加密实现以及传输封装。比较协议时，应尽量固定同一设备、同一接入网络、相近的服务端位置和相同目标。若两条配置分别连接不同地区、不同带宽的服务器，差异首先反映整条链路，而不是协议优劣。缺少这些控制条件时，记录“当前更合适”比写成性能排名更准确。

CPU 和内存不能只看协议标签

加密算法是否能利用处理器指令，会改变实际 CPU 开销；用户态网络栈、TUN、规则集规模与连接数量，也会影响资源占用。Windows 任务管理器里看到的客户端进程可能只包含界面，真正负责传输的内核可能是另一个进程。应同时观察相关进程，而不是因为界面占用较低，就推断整个代理链路几乎不消耗资源。

连接复用可以减少重复建连和握手，但也增加连接生命周期管理。对大量短请求可能有帮助，对少量长连接则未必明显。规则提供者更新、订阅刷新、连接日志和频繁测速，同样会制造后台工作。排查异常占用时，先暂停密集测速与详细日志，再观察空闲和传输状态；不要在所有后台任务同时运行时，将占用直接归因于某个协议。

手机耗电更依赖唤醒与网络状态

移动端除了计算成本，还要考虑无线模块被唤醒和保持活跃的时间。过于频繁的保活、短间隔健康检查及反复重连，都可能延长无线模块工作时间。TCP 或 QUIC 本身不能决定哪一种一定省电：弱信号下持续重传的连接，可能比信号稳定时的另一种协议消耗更多。后台应用数量、系统省电策略与网络切换也会改变结果。

实际比较可选取固定的阅读、视频或语音任务，保持相似亮度和网络条件，重复观察电量、温度与断流情况。测试前停止大规模自动测速，避免把测试流量本身算进正常使用。若待机耗电明显，优先检查保活间隔、健康检查频率和循环重连日志；若只有大流量时发热，再观察吞吐、CPU 与加密实现，分清空闲消耗和工作负载。

日常选择应追求足够快且稳定，而不是一直追逐最高峰值。对笔记本可分别观察电源模式与电池模式，对手机则应分别记录 Wi-Fi 与蜂窝网络。把测试条件连同结果记下来，保留可恢复的配置；进一步理解客户端测试项，可阅读节点延迟与验证步骤，避免将测试失败直接等同于所有业务不可用。

配置文件、订阅格式与参数兼容

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

订阅链接只是获取内容的入口，返回内容可能是完整的 Clash YAML、编码后的分享链接集合，也可能是某个应用专用的配置格式。扩展名和网页标题不能可靠判断格式，应查看客户端识别结果与服务提供方说明。完整配置通常同时包含代理条目、策略组和规则；节点集合可能只有连接信息，需要客户端模板补充其余结构，两者导入后的行为并不相同。

单条分享链接能够被识别，也不代表能恢复全部高级参数。转换工具可能遗漏传输扩展、UDP 模式、客户端指纹或安全层字段；目标格式还可能根本没有对应表示。出现“导入后能看到名称，但始终无法连接”时，先比较关键字段是否完整，而不是反复刷新同一个订阅。涉及账号访问能力的订阅地址应妥善保存，避免提交给不可信的在线转换工具。

YAML 语法与配置语义分别检查

YAML 的缩进决定层级，应使用空格，避免制表符混入。包含冒号、井号或特殊符号的值可以使用合适的引号包围，防止被解析成结构或注释。语法通过只说明文件能读取，不代表代理组名称存在、规则目标正确或协议参数有效。例如规则引用了一个不存在的策略组，可能在加载阶段报错，也可能让预期路由无法建立。

下面是可由 mihomo 读取的最小直连检查配置，用于确认本地监听、策略组与规则结构，不含远端代理连接。它不会产生远端代理能力，也不能作为某个协议的性能测试。使用独立测试配置时，先备份当前文件；若客户端会自动合并端口或 DNS 设置，还需在界面检查最终生效内容，而不是仅根据编辑窗口判断。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: ROUTE
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,ROUTE

这里的 mixed-port 是应用连接本地客户端的入口，不是远端服务端口。allow-lan: false 限制局域网访问，适合本机检查；MATCH 是兜底规则，会把未被前置规则匹配的连接交给指定目标。把本地混合端口与服务器端口混淆，是迁移配置时常见的问题，两者应在检查清单里分别记录。

覆写、提供者与规则顺序

图形客户端可能对订阅应用全局覆写、脚本处理或配置合并，因此下载到的原始文件与内核使用的文件并不总是相同。手动改订阅缓存，下次更新后也可能被覆盖。稳定做法是在客户端支持的位置保存覆写，并确认覆盖顺序；涉及协议凭据与服务器参数时，不要让通用模板无意间覆盖单条连接的专用字段。

proxy-providers 与 rule-providers 分别管理代理集合和规则集合，虽然都能从远端获取文件，但内容结构与引用方式不同，不能互换。规则通常按顺序匹配，较宽泛的规则放在前面，可能让后面的精细规则永远没有机会生效。迁移后应检查组名、提供者引用与兜底目标，而不仅仅确认代理列表数量看起来相近。

订阅更新失败应先区分访问失败、认证失效、返回内容异常与格式不支持。相关步骤见订阅更新失败与自动更新设置。需要重新导入时可对照订阅导入教程；先在独立配置中验证，再迁移规则和覆写，避免把格式问题与原有环境问题叠加。

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

网页、开发工具与日常办公

浏览器、文档站点和常见开发服务通常首先需要稳定的 TCP 访问。已有 SS、Trojan、VMess 或 VLESS 配置能满足需求时，应优先检查连接稳定性、证书管理与订阅维护，而不是仅为协议名称迁移。首次选择 Windows 客户端可从 Clash Plus 开始，具体安装入口在Windows 客户端列表，再按工作习惯比较其他受支持的客户端。

命令行工具不一定遵循系统代理。浏览器能访问而终端失败，可能只是终端没有设置代理环境变量，或者工具只识别自己的代理选项。此时更换远端协议通常没有帮助。先确认应用如何进入客户端，再决定使用显式代理还是 TUN；开发环境里还应注意容器、虚拟机与宿主机的回环地址不同，容器内的本机地址不自动指向 Windows 主机。

实时通信、游戏与复杂网络

语音和实时交互更关注抖动、丢包与连续性，而不只是平均延迟。应用可能同时使用 TCP 登录和 UDP 媒体流，因而“能登录但听不到声音”与“完全连不上”对应不同路径。协议必须支持相应 UDP 转发，接管方式也必须覆盖应用流量；有些应用还会绕过系统代理直接建立连接，需要通过连接列表和规则命中情况确认。

面对高延迟或丢包链路，可把 Hysteria2 与 TUIC 加入候选，但应保留 TCP 类连接对照。若 QUIC 类连接在当前网络根本无法稳定建立，继续调整拥塞控制参数意义有限。反过来，若 UDP 可达且长期表现更稳定，也不必因为某条传统经验就排除它。最终结论应对应具体接入环境，网络切换后允许重新选择。

多设备与长期维护

手机与桌面共用订阅时，应以所有目标客户端的共同能力为基础，而不是假设桌面能用的扩展在手机上也能使用。Android 可按需要比较 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard；iOS 可从下载页进入 Clash Plus 的商店页面。客户端名称不同不一定意味着协议不通，但配置格式、网络扩展与后台行为需要分别确认。

macOS 用户还需结合芯片架构选择安装包，Linux 则要区分图形客户端和直接运行内核的部署方式。桌面可比较 Clash Verge Rev 与 FlClash，服务器环境更适合明确管理配置目录、权限与进程服务。可进一步阅读Linux 部署 mihomo 与 systemd 服务配置；系统服务稳定运行并不代表桌面应用已自动使用代理。

长期维护时，保留一份经过验证的基础配置和简短变更记录很有价值。更新客户端、替换内核、迁移订阅和启用 TUN 尽量分开进行；每一步确认浏览器、终端与所需 UDP 应用正常，再继续下一项。这样出现回归时可以退回明确状态，而不是面对一组同时变化的协议、规则和系统设置。

协议连接失败的分层检查

先定位失败阶段，再改参数

排错从一条明确失败的请求开始：记录应用、目标、使用的配置和发生时间，再查看对应日志。配置无法加载、远端无法连接、握手认证失败和业务请求超时，是不同阶段。不要看到超时就立即改协议，也不要看到配置加载成功就认定远端正常。先找最早出现的有效错误，后续大量重试日志往往只是同一个原因的重复结果。

配置加载阶段重点检查未知协议、未知字段、缩进与组名引用。如果提示不支持某种类型，应确认正在运行的内核，而不是只查看客户端安装名称。网络连接阶段则检查服务器域名解析、地址和端口。Windows 可用下面的命令检查 TCP 端口是否可建立连接；其中域名和端口应替换成服务端实际提供的信息，示例保留文档用途的域名。

Test-NetConnection -ComputerName example.com -Port 443

这个命令不能验证代理认证，也不能验证 Hysteria2 或 TUIC 所需的 UDP 链路。TCP 端口通过，只能说明相应 TCP 连接具备基础可达性；QUIC 类连接需要结合内核日志与服务端记录判断。不要因为同一个数字的 TCP 端口能连接，就推断 UDP 也已放行，防火墙和网络设备可能分别处理两种传输。

握手、DNS 与规则分别核对

进入握手阶段后，按协议核对认证材料、加密方法、TLS 名称和传输路径。证书错误先看时间与名称，认证错误先看 UUID 或口令，HTTP 升级错误先看网络类型、Host 与路径。日志未必直接给出最终原因，但通常能缩小范围。若启用了详细日志，完成排查后应恢复适当级别，并在分享日志前移除订阅地址和敏感连接信息。

连接建立后仍无法访问，要继续检查 DNS 和规则。域名解析可能由本地系统、内核或远端完成，三者结果与路径不一定相同。某条规则把目标交给直连，会让原本可用的代理条目没有被使用；另一条宽泛规则也可能抢先匹配。应在客户端连接列表中确认目标、命中规则与出口策略，而不是只观察当前选中的策略组名称。

全局模式可以作为缩小规则变量的临时方法，但不能修复协议认证、服务端故障或应用没有进入客户端的问题。验证后应恢复原来的分流方式，避免测试状态长期保留。若只有部分域名失败，检查目标解析与规则更有价值；若所有条目突然失败，再检查系统网络、订阅有效性与服务端状态，避免逐条修改原本正确的协议参数。

本地端口与 TUN 的排查边界

浏览器提示无法连接本地代理时，先确认内核仍在运行、监听端口与系统代理一致。端口冲突与远端协议无关，处理方法见7890 端口占用定位，修改后同步核对端口设置。随意结束占用进程可能影响其他软件，应先查明进程用途，再决定关闭旧客户端或更换端口。

TUN 开启后异常，应把服务权限、虚拟网卡、路由和 DNS 接管作为另一层检查。先关闭 TUN，用显式本地代理验证同一条远端连接；若显式代理正常，再返回检查系统接管。具体步骤可参阅TUN 模式与服务模式教程。Windows 商店应用还可能涉及回环限制，不能直接据此判定协议不兼容。

最后保留一份可复现记录：客户端与内核名称、协议及传输组合、出错阶段、是否仅在某个网络发生，以及已经验证过的对照结果。记录事实比堆砌猜测更便于继续处理。需要重新选择客户端时返回下载页；需要恢复基本操作顺序时返回上手教程。先让最简单的连接路径可用，再逐项恢复复杂配置。