Clash 协议与内核技术参考

01 / DECISION MODEL

先把协议选择拆成四个问题

协议名不等于实际体验

在 Clash 客户端里看到 SS、VMess、Trojan、VLESS、Hysteria2 或 TUIC，第一反应通常是比较谁“更新”、谁“更快”。这个顺序经常把判断带偏。协议只规定双方如何建立会话、封装数据、完成认证以及处理传输；实际体验还受服务器出口、用户到服务器的链路、节点负载、拥塞控制、客户端内核和目标站点路径影响。一个路由短、负载低、参数合理的传统协议节点，完全可能比配置粗糙的新协议节点稳定。协议是变量之一，不是单独决定结果的标签。

更可靠的拆法是四问。第一，底层走 TCP 还是 UDP，是否适合当前网络的丢包与抖动。第二，客户端内核能否完整识别该协议及其附加参数。第三，设备是否需要长期后台运行，CPU 唤醒、持续收发和连接迁移的成本能否接受。第四，订阅提供方是否给出了匹配的服务端实现与参数。四项中任何一项不成立，纸面优势都落不到真实连接上。

传输层决定问题长什么样

SS、VMess、Trojan 与 VLESS 常见部署大多基于 TCP，也可能再组合 TLS、WebSocket、gRPC 或其他承载。TCP 自带可靠传输、顺序交付和拥塞控制，适合网页、下载、代码托管等多数业务。代价是当内层应用本身也使用 TCP 时，链路出现丢包可能触发多层重传与队头阻塞。这里不能简单归结为“TCP 套 TCP 一定慢”；实际代理实现通常转发字节流，并非总是机械地嵌套两个完整 TCP 状态机，但长肥网络与高丢包环境下，恢复速度确实可能受限。

Hysteria2 与 TUIC 走 UDP，并借助 QUIC 或相近思路提供可靠流、多路复用和加密。它们的优势主要出现在高延迟、存在随机丢包、TCP 拥塞控制恢复偏慢的链路上。反面也很明确：部分网络会限制 UDP，路由设备的 UDP 会话保持时间可能较短，移动网络切换后还要看实现是否顺利迁移连接。所谓“UDP 协议更快”，应改写为“在允许 UDP 且链路特征匹配时，更有机会维持吞吐”。

节点、协议、传输与内核是四层

节点是可连接的服务端实例；协议定义认证和数据封装；传输层或承载方式决定数据通过 TCP、UDP、TLS、WebSocket 等哪条路径；内核负责把订阅字段转成实际连接。客户端界面只把这些层压缩成一个节点名称，很容易让人把“某个节点不通”误判成“整个协议不行”。排查时应先换同协议的另一节点，再换同节点组里的另一协议，最后检查客户端内核和订阅字段。一次只改一个变量，结论才有意义。

例如 VLESS 节点可能同时带 TLS、流控、服务器名称和传输类型；删掉其中一个字段，协议名仍显示为 VLESS，但握手行为已经不同。Hysteria2 的认证、服务器名称、端口跳跃范围和带宽提示也属于具体实现参数。仅看节点名称中的“高速”“专线”之类文字没有技术价值，应该打开配置查看真实字段，或在客户端的节点详情里确认协议类型。

测试要固定目标与时间窗口

协议比较至少应固定节点地区、测试目标、客户端模式和时间窗口。先用客户端延迟测试做可达性初筛，再用真实网页、持续下载、视频拖动和网络切换观察体验。延迟数字测到的通常是对测试 URL 的一次握手路径，不代表带宽，详细原理可看《Clash 延迟测试数字怎么来的》。同一节点连续测试三到五次，记录波动区间，比盯住一次最低值更有效。

最终选择也不必固定为单一协议。订阅里可以保留一组日常稳定节点、一组高丢包环境备用节点，再交给 url-test 或手动选择组管理。规则负责决定流量去哪一组，协议负责这一组里的节点怎样传输，两者分工不同。理解这层关系后，协议选型就从“站队”变成了可验证的工程问题。

02 / TCP FAMILY

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

Shadowsocks：结构简单，部署成熟

Shadowsocks 通常简称 SS。它的核心思路是用预共享密钥完成加密代理，协议结构相对紧凑，服务端与客户端实现很多，资源需求也容易控制。对于普通网页、下载和长期后台连接，SS 的优势不是某个夸张峰值，而是组件少、参数面较窄、部署经验充分。节点信息通常包含服务器、端口、密码和加密方法；现代实现应使用当前客户端与服务端共同支持的 AEAD 类加密方法，旧式流加密配置不适合继续作为新部署基线。

SS 的简单也意味着它不负责解决所有传输问题。具体链路是否叠加插件、是否走 UDP、服务端是否正确开启 UDP 转发，都取决于部署。订阅里同为 SS 的两个节点，可能因加密方法、插件和服务器实现不同而表现明显不同。Clash 导入后若 TCP 网页正常、语音或游戏异常，应先检查节点的 UDP 支持和客户端 TUN 设置，而不是直接更换 DNS。

VMess：功能完整，但字段组合较多

VMess 是 V2Ray 生态中广泛使用的协议，包含用户标识、认证与时间相关校验，常与 TCP、WebSocket、HTTP/2 风格承载或 TLS 组合。它的历史价值在于把多种传输组合带进统一配置体系，许多订阅服务仍保留大量 VMess 节点。代价是参数较多：用户 ID、alterId、加密字段、传输类型、路径、Host、TLS、服务器名称等任一项不匹配，都可能导致握手失败。

旧教程经常把某些历史字段当作固定要求，但现代服务端可能已经采用不同默认值。处理 VMess 最稳妥的办法不是手动猜参数，而是使用服务端生成的完整订阅，并确认转换过程没有丢掉 network、ws-opts、servername 等字段。若订阅在一个客户端可用、转成 Clash YAML 后失效，优先怀疑转换器字段映射，而不是协议本身。

Trojan：基于 TLS 会话的简洁认证

Trojan 通常运行在 TLS 之上，以密码完成客户端认证。它借助成熟 TLS 栈保护传输，配置重点落在证书域名、服务器名称、端口和密码。与带大量自定义传输字段的配置相比，标准 Trojan 节点更容易读懂；但“使用 TLS”不代表可以忽略证书校验。客户端配置中的 sni 或 servername 必须与服务端证书和部署匹配，系统时间明显错误也可能使握手失败。

部分订阅会设置跳过证书验证。这个选项适合定位证书链问题，不适合作为长期默认。若开启后才可连接，应回到证书名称、服务端证书链和系统时间检查根因。Trojan 还可能组合 gRPC 或 WebSocket，组合后同样会增加路径、服务名称等字段。不要把“Trojan”理解成只有一个固定封装形态。

VLESS：轻认证框架，能力来自组合

VLESS 采用较轻的协议层设计，把加密与传输安全更多交给 TLS 等外层机制。它本身不是“打开就自动更快”的开关，真实能力来自 TLS、Reality 类安全层、流控和具体传输的组合。对于 Clash 用户，关键不是背诵组合名称，而是确认当前 mihomo 是否支持订阅给出的全部字段，并避免在手动精简 YAML 时删除 flow、reality-opts、client-fingerprint 或服务器名称。

VLESS 配置的常见问题是“协议名识别了，附加能力没识别”。有些旧内核能读取基本 VLESS，却无法处理更新的安全层或指纹字段；界面仍可能显示节点，点击后才报错。因此兼容判断不能停在导入成功，至少要完成连接、DNS 请求和真实 HTTPS 访问。使用持续维护的 mihomo 内核，通常比在旧原版 Clash 配置语法上反复删字段更省事。

四者之间没有通用冠军

在低丢包、路由稳定的有线或 Wi-Fi 环境里，这四类基于 TCP 的常见方案可能都能提供接近的网页体验。差异更常出现在首次握手、连接复用、服务端负载和复杂字段的容错上。SS 配置面较小，故障点少；VMess 的存量节点多，但转换时需要保留完整字段；Trojan 的证书链是重点；VLESS 的组合能力强，也更依赖新内核。

如果订阅同时给出四类节点，先按节点线路做同地区分组，再比较稳定性。不要拿一个高负载 SS 节点和一个低负载 VLESS 节点得出协议结论。也不要为了追求名称更新而删除稳定节点。客户端选型方面，Windows 用户可优先使用下载页首推的 Clash Plus，或选择 Clash Verge Rev、FlClash、Clash Nyanpasu；这些图形客户端底层能力仍取决于其集成内核和配置更新情况。

03 / UDP TRANSPORT

Hysteria2 与 TUIC：高丢包链路怎么选

为什么两者都把重点放在 UDP

传统 TCP 在稳定网络里工作得很好，但面对较高往返时间、随机丢包和带宽快速变化时，拥塞窗口恢复可能偏保守。Hysteria2 与 TUIC 都选择在 UDP 上构建加密、可靠传输和多路复用，让应用流不必完全受单条 TCP 字节流的队头阻塞限制。它们并不是把可靠性丢掉，而是把可靠传输放到 QUIC 或协议自身的会话层处理。

这类设计特别适合“链路还有可用带宽，但 TCP 因丢包持续降速”的情况。多条网页请求、视频分片和 DNS 查询可以在同一连接中分成独立流，某个流的丢包恢复不必阻塞所有其他流。连接建立通常也能减少额外往返。不过，底层 UDP 必须能稳定通过本地网络、路由器、运营网络和服务器防火墙；任一环节对 UDP 限速或缩短会话保持，优势都会变成频繁重连。

Hysteria2：吞吐导向，但带宽参数不是测速结果

Hysteria2 的设计重点之一是高吞吐链路下的拥塞控制与可靠传输。配置里可能出现上行和下行带宽提示，它们用于帮助拥塞控制理解链路能力，不等于客户端承诺达到对应速度。把数值写得远高于真实线路，可能造成过量发送、排队和抖动；写得过低，则会主动压住吞吐。若订阅已经提供参数，先保留服务端建议值；只有在持续测试确认队列积压或速度受限后再调整。

Hysteria2 还涉及认证字符串、TLS 服务器名称、证书验证与可选端口跳跃。端口跳跃需要服务端、防火墙和客户端同时配置，单独在客户端填一段端口范围不会自动生效。排查连接时应先固定单端口，确认基础连接成立，再恢复附加能力。移动网络下如果单端口能用而端口跳跃不稳定，通常要检查路由设备和网络对 UDP 映射的处理。

TUIC：QUIC 会话、并发流与连接迁移

TUIC 同样基于 UDP 和 QUIC 思路，常见配置包括用户标识、密码、服务器名称、拥塞控制算法、UDP 中继模式与连接保持参数。它适合承载并发连接，并可利用 QUIC 对流和会话的管理能力。对手机而言，连接迁移是值得关注的能力：Wi-Fi 切到蜂窝网络时，如果客户端、内核和服务端实现配合良好，已有会话可能比重新建立多条 TCP 连接恢复得更快。

但连接迁移不是所有场景都能自动成功。设备休眠、系统回收后台网络权限、NAT 映射变化、VPN 接口重建都可能使原会话失效。实际测试要包含锁屏后恢复、Wi-Fi 与蜂窝网络切换、弱信号区短暂断链，而不只是桌面上连续跑一次下载。TUIC 的拥塞控制选项也不宜照搬他人配置；服务端支持、链路特征和实现版本需要一致。

UDP 不通时，症状通常比 TCP 直接

典型症状包括节点延迟测试超时、连接刚建立就中断、短时间可用后失速、切换网络后长期无法恢复。先确认同网络下其他 UDP 应用是否正常，再检查路由器防火墙、服务器端口、客户端 TUN 与订阅字段。若换到另一 Wi-Fi 立刻正常，问题更可能在本地网络路径；若所有网络都失败，则回到服务端监听、证书名称和认证字段。

还要区分“协议连接使用 UDP”和“代理 UDP 应用流量”。Hysteria2、TUIC 的底层会话本身依赖 UDP，但客户端是否正确接管游戏、语音或 QUIC 网站流量，还受 TUN 模式、系统 VPN 接口、规则和 UDP 转发能力影响。网页能打开，只说明一部分 TCP 应用流量成功通过，不足以证明 UDP 应用链路完整。

选择顺序：先做可达性，再做持续压力

实际选择可以分三轮。第一轮测试连接建立、DNS 和普通 HTTPS；第二轮持续传输数分钟，观察吞吐是否突然归零、是否频繁重连；第三轮模拟真实设备行为，包括锁屏、切网、弱信号和同时打开多个应用。Hysteria2 在高丢包长链路上常有明显吞吐优势，TUIC 在多流和会话管理上有吸引力，但两者的胜负无法脱离服务端实现与本地网络单独判断。

proxies:
  - name: HY2-Example
    type: hysteria2
    server: example.invalid
    port: 443
    password: "your-password"
    sni: example.invalid
    skip-cert-verify: false

proxy-groups:
  - name: UDP-Fallback
    type: select
    proxies:
      - HY2-Example
      - DIRECT

上面的片段只展示 mihomo 常见字段结构，域名与认证值是明确示例值。真实配置应由服务端提供。若当前订阅没有 Hysteria2 或 TUIC 节点，不应只改 type 强行转换：协议必须由服务端与客户端成对支持，改节点类型不会把服务端变成另一种协议。

04 / PERFORMANCE

连接速度、吞吐与资源占用要分开测

“快”至少包含四个指标

客户端里的延迟只是第一个指标。完整性能判断至少包括连接建立时间、首字节时间、持续吞吐和抖动。连接建立时间受 DNS、TCP 或 QUIC 握手、TLS 和协议认证影响；首字节时间还叠加目标站点处理；持续吞吐取决于拥塞控制、丢包、服务器出口和 CPU；抖动则决定语音、游戏和实时交互是否顺滑。一个节点可能延迟低但吞吐差，也可能首开略慢但持续下载稳定。

多路复用也不是越多越好。它可以减少重复握手，让多个逻辑连接共享底层会话；但如果所有流被压进单一不稳定连接，底层会话发生拥塞或重置时，影响范围会扩大。对网页浏览，多路复用通常能降低大量短连接成本；对长时间大流量传输，则要观察单会话是否形成瓶颈。协议实现、客户端内核和服务端参数必须一起评估。

握手开销与连接复用

SS 的基础握手较紧凑，标准配置的 CPU 和往返开销容易预测。Trojan 依赖 TLS，首次连接需要完成 TLS 过程，但后续是否复用会显著影响实际成本。VMess 和 VLESS 的表现取决于外层传输；WebSocket、TLS、gRPC 等组合会引入各自的握手与封装。Hysteria2、TUIC 借助基于 UDP 的会话与多流能力，可能减少并发短连接反复建链，但初次证书验证和 QUIC 会话仍有成本。

因此不能仅按协议头大小排序真实速度。网页访问常由几十个并发资源组成，连接池和复用策略的影响可能大于单个数据包多出的少量字节。反过来，在低性能路由器上，高并发加密、用户态网络栈和复杂规则匹配会占用 CPU，理论吞吐还没到网卡上限，处理器就先满载。

CPU、内存与规则规模

资源占用主要来自加密、数据复制、网络栈、DNS 缓存、规则集和连接状态。协议差异会影响加密与会话处理，但配置规模同样关键。载入多个大型规则集、启用 TUN、开启流量嗅探、保存大量连接记录，都可能让内存占用高于只运行基础系统代理的配置。判断“某协议占内存更多”前，应保持规则集、DNS、日志级别和运行模式一致。

在桌面设备上，几种协议的资源差异通常不如服务器线路差异直观；在低功耗路由器和旧手机上，差异会被放大。Hysteria2 与 TUIC 的用户态可靠传输、计时器和持续 UDP 会话可能增加 CPU 唤醒；复杂 VLESS 组合也可能引入额外 TLS 与传输处理。SS 的简单结构常适合资源受限设备，但前提是服务质量满足需求。

测速顺序决定结论是否可信

第一步清空变量：固定客户端、内核、DNS 模式、规则和目标，只切节点。第二步做可达性测试，淘汰握手失败与波动极大的节点。第三步在相近地区、相近线路里比较协议。第四步把测试放到日常时段重复，避免只在网络空闲时得出结论。最后才看设备温度、CPU 与电量。协议测试需要多轮，而不是一次点击全部延迟后选择最小数字。

下载测试也应避免同时触发多线程、系统更新和云盘同步。若浏览器使用 HTTP/3，目标流量本身可能走 UDP；若客户端没有完整接管 UDP，结果会与普通 HTTPS 不同。为了比较代理协议，可以同时准备一个明确使用 TCP 的测试目标和一个真实视频或实时应用场景。工具输出是切片，真实任务才是最终判断。

日志只开到足够定位

排查连接时可临时把日志级别提高到 debug，确认失败发生在 DNS、规则匹配、代理握手还是目标连接。长期保持高日志级别会增加磁盘写入、界面刷新和 CPU 唤醒，尤其不适合手机与路由器。问题定位后应恢复 info 或客户端推荐级别。日志中若出现证书名称、认证失败、UDP 超时，应按对应层处理，不要一次性重置全部配置。

log-level: info
mode: rule

profile:
  store-selected: true
  store-fake-ip: true

unified-delay: true
tcp-concurrent: true

unified-delay 用于让延迟测试口径更接近统一连接过程，tcp-concurrent 可并发尝试解析得到的地址以缩短部分连接等待。它们不是协议加速器，也不会修复服务端故障。配置项是否生效取决于 mihomo 内核支持；使用旧原版内核时，未知字段可能被忽略或导致加载错误。

05 / MOBILE POWER

移动端电量、后台与切网表现

耗电来自持续唤醒，不只来自加密

手机上的代理客户端通常通过系统 VPN 接口接管流量。数据先进入虚拟接口，再由内核匹配规则、解析域名、建立代理连接并写回系统网络栈。耗电来自多处：加密计算、数据复制、规则查找、DNS、连接保活、日志、界面刷新和无线基带唤醒。单看协议加密算法无法准确预测续航，持续小包和过短的保活间隔往往比一次大流量传输更容易让设备无法进入低功耗状态。

Wi-Fi 下的结论也不能直接套到蜂窝网络。蜂窝基带从休眠恢复到活跃状态有额外成本，频繁保活会延长高功耗尾部时间。Hysteria2 与 TUIC 为维持 UDP 会话可能使用周期性活动；TCP 协议同样可能因心跳、连接池或应用后台请求保持活跃。真正要测的是“固定应用负载下的整机耗电”，而不是协议名称。

系统后台策略比桌面端严格

Android 厂商常对后台进程、电池优化和自启动权限做额外限制。客户端被系统冻结后，VPN 图标可能仍短暂存在，但内核已经不能及时处理新连接。遇到锁屏后无法访问、解锁后恢复，应检查系统对客户端的电池策略、后台运行权限和省电模式。Clash Plus、Clash Meta for Android、FlClash 与 Surfboard 的界面路径不同，但底层都要服从系统 VPN 和后台规则。

iOS 的网络扩展由系统管理，Clash Plus 通过 App Store 安装后，连接与后台行为同样受系统调度。不要用桌面端“进程一直运行”的思路理解手机。系统可能在网络变化时重建隧道，也会控制扩展的内存和运行时间。节点数量特别多、规则集特别大、日志持续刷新，都可能增加网络扩展压力。

协议对移动体验的实际影响

SS 的连接结构较简单，CPU 与内存开销容易控制，适合作为移动端稳定基线。Trojan 和带 TLS 的 VLESS、VMess 会承担 TLS 处理，但现代移动处理器对常见加密已有良好支持，日常网页中的差距未必明显。复杂传输、多层封装和大量并发连接更值得关注。若同一节点组中协议体验接近，优先选故障点少、切网恢复稳定的一项。

Hysteria2 与 TUIC 在弱网、多流和链路变化中可能更顺，但持续 UDP 会话对部分移动网络并不友好。有的网络会快速回收 UDP NAT 映射，有的网络对大流量 UDP 调度保守。手机从 Wi-Fi 切到蜂窝后，如果节点长时间停在连接中状态，可先切换到 TCP 回退节点，再判断是协议会话迁移失败还是系统 VPN 接口没有及时重建。

一套可复现的续航测试方法

先选两个线路相近、负载稳定的节点，保持规则、DNS、应用和屏幕亮度一致。充电结束后等待设备温度恢复，分别运行相同时间的网页浏览、音频后台、短视频和待机场景。记录系统电池统计中的客户端、网络和屏幕占比，同时观察设备是否频繁唤醒。一次测试不足以排除应用后台活动，至少跨两个相似时间段复测。

测试中不要同时更新订阅和规则集。规则下载、解压、解析会制造短时 CPU 与网络峰值，把它算进协议耗电没有意义。也不要用持续满速下载代表日常待机；满速场景主要测吞吐效率，待机场景主要测保活与系统调度。两类结果应分开记录。

减少设备成本的配置路径

第一，规则集只保留实际需要的部分，避免重复加载多个职责相同的大型列表。第二，日志保持常规级别，排查结束后关闭实时调试。第三，节点自动测试间隔不要设置得过短；每隔几十秒扫描一大组节点，会持续唤醒网络和 CPU。第四，启用按需连接时确认系统行为，避免多个自动化规则互相触发。第五，DNS nameserver 数量保持合理，过多并发解析并不会线性提高速度。

如果客户端提供 TUN 栈、流量嗅探、IPv6、UDP 转发等开关，应按需求启用，而不是全部打开。关闭某项前先确认使用场景：游戏与语音通常需要 UDP，依赖域名规则的应用可能需要嗅探补充目标信息，IPv6 网络则要确认 DNS 与规则是否完整覆盖。节电不是删功能，而是让功能与实际流量对应。

移动端最终建议是保留两条路径：一条简单、稳定的 TCP 节点作为常驻基线；一条 Hysteria2 或 TUIC 节点用于弱网和高丢包环境。通过实际切网、锁屏和待机测试决定默认项。协议越复杂，越需要验证系统后台行为，而不是只在前台测速页面里比较数字。

06 / CORE FAMILY

原版 Clash、Clash Meta 与 mihomo 的关系

先区分客户端外壳与代理内核

Clash 生态里“客户端”和“内核”经常被混用。图形客户端负责配置管理、订阅更新、系统代理、托盘菜单和日志界面；内核负责监听端口、DNS、规则匹配、协议连接与 TUN。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等是图形客户端，它们可能集成 mihomo，也可能允许切换内核。看到相似界面，不代表底层协议支持完全一致。

排查兼容问题时，先在客户端关于页面或日志启动行确认内核名称，再看配置文件。仅凭应用名称判断会出错。例如某个客户端版本可能更换内核构建方式，另一个客户端可能保留兼容选项。本站不硬写具体版本号，原因很简单：内核与客户端持续变化，实际安装包内的内核标识才是当前事实。

原版 Clash：基础语法的来源

原版 Clash 奠定了常见 YAML 结构：proxies 定义节点，proxy-groups 定义选择与测试逻辑，rules 按顺序匹配流量，DNS、监听端口和运行模式位于顶层。大量教程与订阅格式都沿用这套模型。它对 SS、VMess、Trojan 等基础协议和经典规则语法的影响仍然存在。

但原版内核已经停止维护。面对 Hysteria2、TUIC、更新的 VLESS 安全组合、规则集格式和现代 TUN 能力，继续以原版功能边界作为新配置基线会遇到大量缺口。旧配置可以作为语法起点，不应把旧内核当作新协议兼容目标。Clash for Windows 也已停止维护，下载页将其放在归档位置，适合处理旧环境，不适合作为新安装首选。

Clash Meta：扩展兼容阶段

Clash Meta 在原版配置模型上扩展了协议、DNS、规则提供器、TUN 和网络能力。许多原版 YAML 可以直接加载，再逐步加入 Meta 扩展字段。这一阶段解决了生态对新协议与复杂配置的需求，也形成了常见的“Meta 配置”称呼。配置文件里出现 rule-providers、更完整的 DNS 项、sniffer 或新协议字段时，通常已经超出原版 Clash 的稳定能力范围。

兼容是单向倾斜的：Meta 系内核通常能读取大量原版配置，但原版内核无法理解所有 Meta 扩展。把一份 mihomo 配置直接交给旧原版内核，可能出现未知代理类型、未知字段或规则提供器加载失败。删除报错行有时能启动，但也可能悄悄改变 DNS、路由和节点安全参数，不应把“能启动”当作等价兼容。

mihomo：当前持续维护的延续

mihomo 是 Clash Meta 项目的后续名称与持续维护内核，沿用 Clash 配置思路，并继续处理新协议、网络栈、DNS 与规则能力。很多客户端界面仍使用 Clash 或 Meta 术语，底层实际运行 mihomo。对新安装用户，优先选择集成并持续更新 mihomo 的客户端更直接；Windows 平台本站首推 Clash Plus，也可根据界面和平台需求选择 Clash Verge Rev、FlClash 或 Clash Nyanpasu。

mihomo 的能力多，不代表所有开关都要启用。TUN、嗅探、Fake-IP、规则提供器、外部控制接口分别解决不同问题。把网上的大配置整份复制进来，常见后果是字段互相覆盖、DNS 回环、规则顺序错误或资源占用上升。更稳的做法是从订阅生成的可用配置起步，每次添加一个模块，确认日志与流量路径后再继续。

配置兼容要看行为，不只看语法

第一层兼容是 YAML 能解析；第二层是节点字段能完整识别；第三层是 DNS、规则和 TUN 行为与预期一致。某些未知字段可能被忽略，配置仍能启动，却在流量路径上产生差异。例如代理节点缺少服务器名称可能导致 TLS 失败，规则提供器未加载会使流量落入最终规则，Fake-IP 过滤缺失会影响局域网域名解析。升级内核后应检查日志、节点连接和关键规则命中。

迁移时保留三个副本：原始订阅、客户端当前可用配置、准备修改的新配置。先比较顶层字段，再比较节点协议与代理组，最后比较规则和 DNS。不要让多个客户端同时写同一份配置目录，以免自动更新覆盖手工修改。需要长期维护的自定义规则，宜放在客户端支持的覆写或 merge 机制中，而不是直接改订阅生成文件。

mixed-port: 7890
mode: rule
log-level: info

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

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

这份最小结构只展示层级关系，不包含真实节点。配置能被解析后，再由订阅或客户端覆写加入代理节点、DNS 与规则提供器。若最小配置能启动，而完整配置失败，就按模块逐段恢复；这种二分方法比盯着整屏日志猜字段快得多。路由器直接运行 mihomo 的部署差异，可继续看《路由器直跑 mihomo 内核部署思路》。

07 / PROFILE FORMAT

订阅格式、节点字段与转换兼容性

订阅链接不等于 Clash 配置文件

订阅链接只是获取数据的入口，返回内容可能是完整 Clash YAML、若干分享链接组成的文本、base64 编码列表或服务商自定义结构。完整 Profile 除了节点，还可能包含代理组、规则、DNS、TUN 与规则提供器；通用订阅通常只携带节点。客户端导入后若只出现节点而没有预期规则，不一定是导入失败，可能是源订阅本来就不提供完整策略。

反过来，一份完整 Clash YAML 也不一定适合直接交给所有客户端。客户端可能使用 mihomo，但对覆写、脚本或外部规则集路径有自己的管理方式。导入前先确认文件类型：看到 proxies:、proxy-groups:、rules: 三段，通常是完整配置；看到多行 ss://、vmess:// 等链接，则更接近节点集合。

分享链接能带什么，取决于协议

SS 分享链接通常携带加密方法、密码、服务器和端口，也可能通过查询参数附加插件。VMess 常见分享结构会编码用户标识、传输、Host、路径、TLS 等字段。Trojan 链接重点是密码、服务器、端口、SNI 和传输参数。VLESS 链接可能包含安全类型、flow、指纹、公钥标识、服务器名称和传输字段。Hysteria2、TUIC 同样需要认证、SNI、拥塞或 UDP 相关参数。

问题出在转换器是否认识这些字段。转换器若只实现了协议基础字段，可能把节点名称和服务器保留下来，却丢掉 flow、Reality 配置、WebSocket 头、gRPC 服务名或 Hysteria2 带宽提示。生成的 YAML 看起来整齐，实际握手必然失败。新协议或复杂组合出现导入问题时，先尝试客户端直接读取原订阅，再与转换结果逐字段比较。

YAML 本身也有容易忽略的边界

YAML 对缩进敏感，Tab 字符、层级错位和冒号后的特殊文本都可能破坏解析。节点名称中包含冒号、井号、方括号或前后空格时，使用引号更稳。布尔值应按内核要求写成 true 或 false，端口保持数字。相同键重复出现时，不同解析器的处理可能不同，不应依赖后一个键覆盖前一个键的偶然行为。

代理组引用的是节点名称，改名后必须同步修改组内引用。规则最后通常需要一个兜底项，例如 MATCH,PROXY；规则按从上到下顺序匹配，前面的宽泛规则会截走后面的精细规则。订阅转换只负责生成结构，不会自动判断业务规则是否合理。配置文件结构与多配置管理可继续看《Clash 配置文件是什么》。

导入后做四层验收

第一层看数量：节点数是否与源订阅大致一致，协议类型是否齐全。第二层看字段：抽查一条复杂 VLESS、一条 Trojan 或 VMess、一条 Hysteria2 或 TUIC，确认 TLS、SNI、传输和认证字段。第三层看策略：代理组是否引用存在的节点，规则集是否成功加载，最终规则是否存在。第四层看行为：分别测试 DNS、普通 HTTPS、UDP 应用和切换节点。

如果只有个别节点失败，复制失败节点与同协议正常节点的字段结构做对照。若整类协议都失败，检查内核支持和转换器映射。若所有节点都正常但网页打不开，问题更可能在系统代理、TUN、DNS 或规则，而不是订阅格式。把故障限定到一层后再修改，避免重复导入导致配置列表越来越乱。

订阅更新与自定义规则要分层

直接编辑订阅生成的 Profile，下一次更新通常会覆盖修改。客户端若支持覆写、合并配置或扩展脚本，应把本地规则、DNS 调整和代理组改动放到独立层。基础订阅负责提供节点，覆写层负责本站或设备策略。这样节点更新时不需要重新手改整份 YAML，也能快速停用有问题的自定义模块。

多机场或多用途配置并存时，名称要表达来源和用途，例如“日常”“移动备用”“测试”，不要用“配置一”“配置二”。记录上次更新时间与自定义覆写是否启用。切换 Profile 后重新确认系统代理或 TUN 状态，因为部分客户端只切配置，不会自动恢复先前连接状态。

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

示例展示 mihomo 的代理提供器结构，地址为明确示例域名。interval 控制订阅更新间隔，健康检查有自己的独立间隔。把二者设得过短会增加网络请求和移动端唤醒。真实订阅地址应通过客户端界面保存，不要公开粘贴到文章、截图或共享配置中。

关于 base64、YAML 与通用格式的进一步拆解，可阅读《Clash 订阅格式科普》。转换的目标应是保留语义，而不是追求文件看起来更短。遇到新协议字段时，少一次不必要的格式转换，通常就少一个兼容故障点。

08 / FIELD GUIDE

按设备与网络场景完成协议选型

Windows 与 macOS 日常桌面

桌面设备通常有更宽松的后台资源和稳定网络，选择重点应放在客户端维护状态、节点线路与配置兼容。Windows 新安装优先从 Clash Plus 开始，再按界面需求考虑 Clash Verge Rev、FlClash 或 Clash Nyanpasu；macOS 同样可优先使用 Clash Plus，也可选择 Clash Verge Rev、FlClash。Clash for Windows 与 ClashX Meta 已停止维护，在下载页作为归档选项保留。

协议方面，先用订阅中稳定的 SS、Trojan 或 VLESS 节点建立基线。固定地区后，再加入 Hysteria2 或 TUIC 对照高丢包和持续吞吐。桌面设备可以同时保留手动选择组与自动测试组，但自动测试只能发现可达性和测试 URL 的握手表现，最终默认节点仍应通过实际网页、下载和视频任务确认。

Android 与 iOS 长期后台

Android 可在 Clash Plus、Clash Meta for Android、FlClash 与 Surfboard 之间按界面和配置需求选择；iOS 使用 Clash Plus。移动端先把后台权限、VPN 状态和切网恢复跑通，再比较协议。若日常以消息、网页和音频为主，简单稳定的 SS、Trojan 或 VLESS 常适合作为默认；弱网或高丢包环境可切 Hysteria2、TUIC，但必须验证锁屏和蜂窝网络。

节点组不要堆得过大。自动测试几十个节点会增加 DNS、连接和电量成本。可以按地区和用途拆成小组：日常组只放经过验证的少量节点，备用组保留不同协议和不同线路。旅行、酒店 Wi-Fi 或临时访客网络中，若 UDP 节点全部超时，直接切 TCP 回退组，不必在现场反复修改证书与 DNS。

路由器与低功耗设备

路由器运行 mihomo 时，CPU 架构、内存、散热和硬件转发能力比桌面端更关键。SS 的实现通常较轻，适合作为资源基线；TLS、复杂 VLESS 组合、Hysteria2 与 TUIC 需要更多用户态处理，实际吞吐可能受 CPU 单核能力限制。设备标称网口速率不等于代理吞吐，TUN、透明代理、规则集和 DNS 都会占用资源。

先用小规则集和单一协议测试稳定吞吐，再逐步开启透明代理、Fake-IP、嗅探和规则提供器。若 CPU 满载而网络未到预期速度，换协议之前先减少日志、缩小规则规模并检查软路由是否发生重复转发。路由器要服务多个终端，稳定性通常比单连接峰值更重要。Hysteria2 或 TUIC 在链路匹配时可提高吞吐，但也要确认 UDP 会话表和防火墙容量。

实时语音、游戏与视频

实时业务看重抖动、丢包恢复和 UDP 转发。首先确认客户端 TUN 或系统 VPN 已接管对应流量，规则没有把应用错误分到 DIRECT 或 REJECT。其次比较节点到目标服务的实际路由，不要只看节点服务器延迟。Hysteria2 与 TUIC 可能在高丢包网络中保持更平滑的多流传输，但额外一层可靠机制并不保证所有实时 UDP 应用都更低延迟。

视频更看持续吞吐和拥塞恢复。低延迟但出口拥挤的节点会频繁缓冲，高延迟但吞吐稳定的节点反而可能更适合。选择节点时可按《Clash 节点怎么选》中的延迟、倍率、地区和协议四个维度筛选。倍率属于流量成本，地区影响内容与路由，协议只是其中一项。

一条可直接执行的选择流程

1. 确认内核。在客户端关于页面或日志里确认使用 mihomo，避免新协议字段落到旧原版内核。
2. 检查订阅。确认节点数量、协议类型和复杂字段，保留原始订阅，不先做多次转换。
3. 建立 TCP 基线。从 SS、Trojan、VMess 或 VLESS 中选择一个稳定节点，验证 DNS、HTTPS 和持续连接。
4. 测试 UDP 路线。在同地区加入 Hysteria2 或 TUIC，验证 UDP 可达、持续吞吐、切网与恢复。
5. 检查设备成本。桌面看 CPU 与稳定性，手机看待机和后台，路由器看多终端并发与温度。
6. 建立回退组。把不同底层传输放进同一手动选择组，网络变化时快速切换，不临时改配置。

如果某协议只在一条节点上出现，不具备公平比较条件，就把它当作节点选择，而不是协议结论。若多个同协议节点都在同一网络失败、换网络恢复，优先检查 UDP 或传输路径；若只有一个客户端失败，优先检查内核与字段；若所有客户端都失败，回到服务端与订阅源。分层排查可以避免不断更换客户端却保留同一个错误配置。

结论：按约束选，不按名称排队

SS 的价值是简单成熟，适合作为通用和低资源基线；VMess 的存量与传输组合仍有现实价值，重点是完整字段；Trojan 依赖标准 TLS 路线，证书和服务器名称必须正确；VLESS 的能力来自安全层与传输组合，更需要持续维护的内核；Hysteria2 面向高丢包与高吞吐链路；TUIC 强调 QUIC 多流和会话能力。它们解决的问题不同，不存在脱离线路、设备和服务端实现的固定排名。

内核方面，新配置以 mihomo 为主要检查对象，原版 Clash 语法继续作为结构基础，Clash Meta 配置通常可以沿迁移路径进入 mihomo。订阅方面，优先保留原始语义，减少不必要转换，导入后按节点、字段、策略、行为四层验收。客户端方面，首选持续维护且能清楚显示内核状态的产品；Windows 与 macOS 可优先考虑 Clash Plus，其他平台按下载页清单选择。

完成选型后，回到入门指南执行订阅导入、模式选择和连接验证；需要安装包时进入下载页；出现无法上网、DNS 或规则命中问题时转到帮助中心。协议选择到这里应该变成一套可重复动作：确认内核，保存原配置，固定变量，测试真实任务，保留回退路径。