Clash 协议与内核技术参考

02 · TCP FAMILIES

SS、VMess、Trojan 与 VLESS 的设计取舍

SS：结构紧凑，依赖明确的加密方法

Shadowsocks 通常简称 SS。它的核心思路是以较轻的协议结构承载代理流量，由预共享密码和指定加密方法完成数据保护。现代配置应使用受当前内核支持的 AEAD 方法，并保证服务端与客户端的加密方法、密码和端口完全一致。SS 本身字段较少，导入订阅和跨客户端迁移相对直接，日志中的失败原因也较容易沿着端口、密码、加密方法和网络可达性逐项排查。

字段少不代表所有 SS 节点表现相同。服务端实现、加密算法的硬件加速、UDP 中继、插件参数和底层网络都会影响结果。部分订阅还会附带 plugin 与 plugin-opts，用于增加额外承载层；如果当前内核不支持指定插件，即使基础的 server、port、cipher 和 password 均正确，节点仍无法使用。面对资源有限的路由器，SS 经常是易于理解的起点，但应在目标架构上测试加密开销，不能仅按桌面处理器的结果推断。

VMess：身份、时间与传输选项较多

VMess 来自 V2Ray 生态，配置常包含用户标识、alterId、加密选项、网络传输和 TLS 等字段。历史配置中常能看到不同的 alterId 取值，较新的服务端部署通常采用更简化的组合，但客户端仍可能为了兼容旧订阅保留解析字段。VMess 的认证过程对时间状态较敏感，设备时间明显偏差时可能出现认证失败，因此排查时除检查地址和用户标识，还应确认系统时间同步正常。

VMess 的实际复杂度主要来自可搭配多种传输。TCP、WebSocket、HTTP 和 gRPC 对路径、反向代理与服务端配置有不同要求。WebSocket 配置需要核对 path 与 Host；gRPC 需要核对 service-name；启用 TLS 时还要检查 servername、证书验证和 ALPN。订阅转换工具有时会遗漏较少见的传输字段，表现为节点名称存在、基础信息正确，但握手始终失败。处理这类问题时，应将转换前后的单节点配置逐字段比较，而不是不断切换代理模式。

Trojan：使用 TLS 承载，证书参数是关键

Trojan 通常通过标准 TLS 连接承载数据，认证核心是密码。其配置表面上不复杂，但 TLS 相关字段决定了连接能否建立。server 是实际连接地址，servername 或 SNI 用于 TLS 握手中的主机名，两者可以相同，也可能不同。若使用域名连接，DNS 解析、证书有效性与主机名匹配都需要成立。若订阅将域名替换为 IP，却没有保留正确的 servername，常见结果是 TCP 可达但 TLS 验证失败。

部分用户会直接打开 skip-cert-verify 绕过证书错误，这会掩盖域名、证书链或系统时间问题。更稳妥的顺序是先确认设备时间，再检查 servername 是否对应证书名称，然后确认服务端证书链和网络路径。只有明确知道证书验证为何失败并接受相应风险时，才应调整验证策略。Trojan 也可以使用 WebSocket 或 gRPC 等承载，排查逻辑与 VMess 类似：先确认 TLS，再核对 path、Host 或 service-name，最后检查 UDP 与策略组行为。

VLESS：减少协议层负担，安全依赖传输层

VLESS 同样来自 V2Ray 体系，但设计上不在协议层提供与 VMess 相同的加密机制，通常依赖 TLS 或其他安全传输提供机密性和身份校验。它使用用户标识进行认证，常见配置包括 uuid、flow、network、tls、servername，以及与传输对应的附加字段。由于协议层处理更直接，VLESS 经常被用于需要灵活传输组合的部署，但“字段更轻”不等于可以省略安全传输。

VLESS 配置的兼容问题集中在扩展能力。不同内核对 flow、Reality、客户端指纹、传输细节和 UDP 行为的支持时间并不一致。mihomo 对多种 VLESS 扩展提供支持，但具体可用字段仍应以当前内核文档和运行日志为准。订阅中出现未知字段时，解析器可能忽略它，也可能拒绝整个节点；忽略比报错更难发现，因为节点看起来已经导入，却在运行阶段失败。迁移到另一客户端前，应确认关键扩展没有在转换中消失。

proxies:
  - name: "SS baseline"
    type: ss
    server: example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

上例只展示 SS 节点的最小结构，用于识别字段关系。实际地址、端口、密码和加密方法必须来自服务端配置。YAML 对缩进敏感，列表项下的字段需要保持同一层级；密码中含有冒号、井号或其他特殊字符时应使用引号。配置加载失败与连接失败是两类问题：前者先检查 YAML 语法和字段名，后者再检查网络、认证与服务端状态。

04 · PERFORMANCE

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

连接建立时间与持续吞吐不是同一个指标

网页打开速度受 DNS、TCP 或 QUIC 握手、TLS、服务器处理和页面资源数量共同影响。协议握手较轻，只能减少其中一部分时间；如果 DNS 缓慢或页面需要连接多个域名，节点的单连接优势未必能转化为明显体验。持续下载则更依赖路径容量、拥塞控制和服务端出口。短连接测试应重复访问多个目标并清理缓存影响，持续传输测试应保持足够时间，观察速度是否稳定、是否周期性归零以及切换网络后的恢复。

多路复用也需要谨慎理解。将多个逻辑连接放到较少的底层连接中，可以减少重复握手，但底层连接出现拥塞或中断时，影响范围也会扩大。TCP 上的多路复用仍可能受单条 TCP 连接丢包恢复影响；QUIC 的多流设计能减少流之间的阻塞，但会增加用户态状态管理。对于大量短请求，多路复用可能有效；对于少量长期大流量连接，收益不一定明显。默认关闭或开启都不应被视为绝对结论，应依据应用类型测试。

CPU、内存与加密开销

SS 的资源消耗与加密方法、处理器指令集和并发数相关。支持硬件加速的桌面处理器可以高效处理常见 AEAD 算法，而某些低功耗架构对另一类算法更友好。Trojan、VMess over TLS 和 VLESS over TLS 都要承担 TLS 处理，实际开销还取决于传输层是否使用 WebSocket、gRPC 或额外多路复用。Hysteria2 与 TUIC 除加密外，还要在用户态维护 QUIC 的确认、重传、拥塞和流状态。

内存占用通常不由协议名称单独决定。连接数量、规则规模、DNS 缓存、TUN 路由、日志级别和 provider 数量都可能比单节点差异更明显。路由器上出现内存压力时，应先减少不必要的规则集、缩短过多的 provider 链路、限制详细日志持续写入，再比较协议。桌面端则应观察长时间运行后是否持续增长，而不是只记录刚启动的数值。发生异常增长时，保存配置结构和触发步骤，比简单判断某协议“更吃内存”更有定位价值。

移动端耗电由唤醒频率主导

手机电量表现不仅取决于加密计算，更取决于无线模块和 CPU 被唤醒的频率。频繁的节点健康检查、较短的 DNS 缓存、持续日志、后台测速和过于积极的保活都会增加唤醒。即使每次处理量很小，长时间累积也会明显影响待机。基于 QUIC 的节点可能为了保持 NAT 映射发送保活，TUN 模式还要处理更多系统流量；如果设备上有大量后台应用，这些因素会叠加。

优化顺序应先处理全局行为，再换协议。将健康检查间隔设置为满足故障发现需要的合理值，不要让多个 provider 同时高频探测；只保留实际使用的策略组；调试结束后恢复常规日志级别；不需要接管全部流量时优先使用系统代理；确认局域网连接开关与实际需求一致。完成这些调整后，再在同一时间段比较 TCP 与 QUIC 节点。测试期间应保持屏幕亮度、应用活动和网络类型接近，否则系统调度差异会掩盖协议差异。

建立可重复的测试记录

测试表应至少记录设备、操作系统、客户端、内核、网络类型、接管方式、DNS 模式、节点协议和测试时段。一次只修改一个变量，例如先固定规则模式与系统代理，仅替换 SS 和 Hysteria2 节点；下一轮再固定节点，比较系统代理与 TUN。每轮同时记录成功率和错误类型。若五次连接中两次超时，即使成功时速度很高，也不适合作为自动选择组的唯一节点。

移动端电量至少观察一个完整的日常使用周期，并查看系统电量页面中客户端的前台与后台活动。短时间运行几分钟无法代表待机保活成本。出现耗电异常时，可以先停止所有主动健康检查并关闭详细日志，再逐项恢复，以定位唤醒来源。关于后台运行与省电策略的进一步步骤，可阅读Clash 手机耗电快怎么办。

06 · SUBSCRIPTIONS

订阅格式、配置兼容与字段保真

节点链接、节点列表与完整配置

“订阅”可能指三种不同内容。第一种是若干协议链接组成的节点列表，例如 ss、vmess、trojan 或 vless 链接；客户端或转换服务负责将链接解析为 Clash 节点。第二种是已经转换好的 proxies 列表，只包含节点，不含完整规则和 DNS。第三种是完整 Clash 或 mihomo 配置，除节点外还包含 proxy-groups、rules、rule-providers、dns、tun 等部分。导入前先判断类型，可以避免把完整配置当节点 provider，或用订阅更新覆盖本地规则。

节点链接适合跨工具传递，但并非所有扩展参数都有统一表达。VLESS 的 flow、Reality 字段，Hysteria2 的带宽与混淆参数，TUIC 的认证和拥塞控制选项，都可能因链接规范、生成端或转换端不同而丢失。完整 YAML 能表达更多字段，但对目标内核的依赖更明确。需要在多个 mihomo 客户端之间迁移复杂配置时，保留 YAML 通常比反复转成分享链接更可靠。

proxy-providers 负责来源，不等于协议转换

proxy-providers 可以让 mihomo 从文件或 URL 加载节点集合，并按 interval 更新。它适合把节点来源与主配置分离，再由多个策略组引用同一个 provider。provider 的 health-check 可以定期访问测试地址，用于判断节点是否可用，但检查频率会影响网络请求和移动端耗电。provider 读取的是目标内核能够解析的内容；如果远端返回的是不兼容格式，单纯放入 provider 并不会自动完成任意协议转换。

proxy-providers:
  primary:
    type: http
    url: "https://example.com/subscription.yaml"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 1800
      url: "https://www.example.com/"

示例中的域名仅表示结构。url 应替换为实际订阅地址，并避免将带访问凭据的链接公开分享。path 指向内核工作目录下的缓存文件；interval 是更新周期；health-check 的 interval 是健康检查周期，两者含义不同。测试地址应稳定、响应较小，并与实际网络目标具有可比性。若多个 provider 都设置很短的检查周期，客户端会持续产生后台连接，移动端尤其需要控制频率。

转换过程最容易损失扩展字段

订阅转换通常经历解析源格式、映射字段、生成目标 YAML 三步。传统 SS、VMess 和 Trojan 的常见字段映射较成熟，但插件、gRPC、Reality、客户端指纹、Hysteria2 与 TUIC 的扩展项更容易受转换器能力限制。转换后应抽查每种协议至少一个节点，比较 server、port、uuid 或 password、network、tls、servername、alpn、flow、udp 等关键字段。不要只比较节点数量；数量相同也可能存在字段缺失。

节点名称也可能影响管理。转换器为了去重会重命名节点，而 proxy-groups 中若直接写旧名称，加载时会出现找不到代理的错误。使用 providers 引用节点集合可以减少名称耦合，但规则目标与策略组名称仍必须存在。完整配置迁移时，先检查所有规则最后指向的策略组，再检查策略组引用的节点或 provider，形成从 rules 到 proxy-groups 再到 proxies 的引用链。

YAML 语法正确仍可能语义错误

YAML 检查能够发现缩进、重复结构和类型问题，却无法确认远端地址、密码、SNI 或规则目标是否正确。常见语义错误包括端口被写成字符串后由某些解析器拒绝、布尔值使用不一致、同名策略组重复、规则指向不存在的组、provider 路径没有写入权限，以及节点启用了服务端不支持的 UDP。应先运行内核配置检查，再启动并观察第一轮 provider 更新、DNS 初始化和节点握手日志。

当完整订阅由服务方维护时，本地修改可能在下一次更新时被覆盖。需要长期保留的规则应放在客户端支持的覆写、合并或本地配置层，而不是直接编辑远端缓存文件。不同客户端对覆写机制的名称和能力不同，迁移前应导出本地规则。Clash Plus 等客户端可以简化配置管理，但依然需要区分远端订阅、生成后的运行配置和本地覆写三层，排查时确认实际生效的是哪一份。

08 · MIGRATION

协议测试、配置迁移与故障定位

迁移前建立可恢复的最小配置

从旧客户端迁移到 Clash Plus、Clash Verge Rev、FlClash 或其他 mihomo 客户端时，先保留旧客户端可工作的配置，不要立即删除。新客户端中只导入一个节点或一个 provider，建立包含 DIRECT、单个代理和 MATCH 的最小规则，确认核心启动、DNS 和系统代理正常。基线通过后，再加入完整策略组、规则集和 TUN。这样可以把客户端安装问题、内核兼容问题和复杂配置问题分开。

若从原版 Clash 配置迁入 mihomo，多数基础字段可以继续使用，但仍应检查 DNS 和 TUN 默认行为。若反向迁移，则需要删除 VLESS、Hysteria2、TUIC 等原版不支持的节点及 Meta 扩展规则。策略组引用必须同步更新，否则配置会因目标不存在而失败。任何批量修改都应先复制文件，并用内核检查命令确认语法，再替换正在运行的配置。

按阶段读取日志

启动阶段日志回答“配置能否加载”。重点查看 YAML 解析、未知字段、provider 文件、监听端口和 TUN 权限。更新阶段日志回答“远端内容能否获取并解析”，重点查看订阅请求、返回格式、缓存路径和节点数量。连接阶段日志回答“目标流量是否命中规则并完成握手”，重点查看规则目标、节点名称、DNS、超时、TLS 和认证信息。将不同阶段混在一起会导致错误判断，例如订阅更新成功并不能证明节点握手成功。

常见的 dial tcp timeout 表示在规定时间内没有完成 TCP 连接，可能来自地址不可达、端口受阻、DNS 结果异常或服务端未监听；connection refused 表示目标明确拒绝连接，优先检查端口与服务状态；TLS 错误应检查系统时间、servername 和证书；authentication failed 指向密码、UUID 或认证字符串。QUIC 节点若持续超时，应先换网络判断 UDP 路径，再检查协议参数。更多日志文本和定位顺序见Clash 运行日志怎么看。

端口、系统代理与 TUN 的分层检查

mixed-port 常用于同时提供 HTTP 与 SOCKS 入口。系统代理开启后，操作系统应指向客户端实际监听的地址与端口；如果端口被其他程序占用，内核可能启动失败，界面开关仍不代表监听已经成功。可以先关闭其他代理工具，再查看日志中的监听错误。局域网共享还需要 allow-lan、防火墙和正确的监听地址，不能只把本机地址填写到另一台设备。

TUN 模式位于更低的接管层，需要系统权限、虚拟网卡或相应网络扩展。启用后无网络时，先关闭 TUN 回到系统代理基线。如果系统代理正常，说明节点、订阅和基本 DNS 大体可用，问题更可能在 TUN 权限、路由或 DNS 劫持。然后重新启用 TUN，逐项检查自动路由、接口选择、私有地址排除和 DNS 模式。不要在 TUN 故障时同时更换协议节点，否则会失去有效对照。

协议替换采用单变量顺序

从 VMess 切换到 VLESS，或从 Trojan 切换到 Hysteria2 时，应保持目标服务、客户端、规则、DNS 和接管方式尽量一致。先确认新节点能在手动选择组中单独连接，再加入自动测试或回退组。测试网页、持续下载、UDP 应用和切网恢复四类行为，并记录错误。若新协议只在某类业务中表现更好，可以建立专用策略组，而不是把全局默认一次性替换。

复杂协议的调优应分层：第一轮使用订阅默认参数；第二轮只调整传输相关选项；第三轮再考虑多路复用、带宽或拥塞控制；最后处理 TUN 与 DNS。每轮都应能回到上一步。调参后若性能下降，应撤销最近一个变化，而不是继续叠加设置。可恢复性是生产配置的重要属性，它让升级内核、切换客户端和更换网络时都有明确退路。

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

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

这份片段展示用于排查的基础结构：规则模式、混合端口、局域网开关、常规日志级别和三条规则。实际配置还需要定义名为 PROXY 的策略组或代理。规则按顺序匹配，明确域名应放在更通用的 GEOIP 与 MATCH 之前。若日志显示目标命中 DIRECT，就不应继续排查代理协议握手，而应先修正规则目标。

形成最终选型记录

完成测试后，为每个默认节点记录协议、传输、TLS 主机名、适用网络、是否支持 UDP、对应 provider 和回退节点。不需要保存密码等敏感内容，只记录定位所需的结构信息。移动端额外记录是否启用 TUN、健康检查间隔和后台限制；路由器记录核心架构、服务启动方式和规则集来源。下一次客户端或内核更新后，按同一记录复测，比重新凭感觉选择更可靠。

最终配置通常不需要覆盖所有协议。保留一到两个稳定 TCP 节点、一个经过验证的 QUIC 节点，再通过清晰的策略组组织，已经能应对多数桌面与移动场景。节点数量过多会增加健康检查、名称管理和故障定位成本。协议手册的作用不是要求同时启用所有技术，而是帮助识别每种方案解决的问题、依赖的条件和失败时的回退路径。