Clash 协议与 mihomo 内核参考

一、协议、传输与接管方式的边界

先分清一次连接经过的几个层次

在 Mac 客户端里看到一个出站名称，实际涉及的不止一种技术。最内层是应用产生的访问，例如浏览器请求网页或终端连接代码仓库；客户端先决定是否接管，再根据规则选择策略组，最后由具体出站把请求交给服务器。代理协议约定客户端与服务器如何认证、描述目标地址和传递数据。TCP、UDP、TLS、WebSocket、HTTP/2、QUIC 则属于不同层次的传输或安全机制。把这些名称并列当成可互换的协议，容易在导入和排错时选错方向。

例如，VLESS 可以搭配不同传输方式，但服务端启用 WebSocket 时，客户端不能只填正确的地址与用户标识，再随意改成普通 TCP。路径、请求头、TLS 开关及服务端名称都可能参与连接建立。界面里显示的协议名称通常只说明其中一层，完整兼容性需要同时核对协议、传输、安全参数与扩展选项。订阅已包含这些字段时，优先保留原值，不要根据网络教程把几个不同服务端的设置拼在一起。

系统代理、TUN 与协议类型是两件事

系统代理告诉遵循 macOS 设置的应用，把连接交给本地代理端口。TUN 则创建虚拟网络接口，通过路由接管匹配的流量。二者决定流量如何进入客户端，不决定客户端向服务器使用 SS 还是 Trojan。同一个出站可以服务于系统代理，也可以被 TUN 使用。因此，终端无法访问时直接更换协议，不一定能解决问题；程序可能根本没有把请求送入客户端。应先观察连接记录，再判断是接管层、规则层还是出站层的问题。

规则模式、全局模式与直连模式同样不是协议。规则模式按照域名、地址或其他条件选择出口；全局模式把被接管的连接交给统一策略；直连模式通常让这些连接直接访问目标。即使开启全局模式，不遵循系统代理的应用也不会因此自动被接管。相反，TUN 接管后仍可使用规则分流，不必把所有请求都交给远端。需要详细操作时，可对照macOS TUN 增强模式说明检查授权与路由。

安全能力与可用条件需要一起判断

加密、服务器身份验证和配置保密分别解决不同问题。连接使用了 TLS，不代表可以关闭证书验证；配置用了随机标识，也不代表订阅地址可以公开。协议选型前应确认服务器由谁提供、证书是否可信、订阅是否来自预期渠道。代理服务器通常能观察连接目的地和时序等信息，而应用自己的 HTTPS 加密仍承担内容保护。不要为了让连接暂时成功，把证书检查当作可以长期跳过的可选项。

阅读后续对比时，还要区分“协议允许”和“当前实现支持”。某个协议具备 UDP 转发设计，并不说明所有服务端、插件和订阅转换器都完整实现了它。客户端界面中的开关也不能创造服务端没有的能力。实际选择应以所用内核的支持范围、服务端要求和连接日志共同为准，而不是以一个名称包含多少技术缩写为准。

二、Shadowsocks 与 VMess 的设计取舍

Shadowsocks：围绕加密转发的简洁结构

Shadowsocks 常写作 SS，核心设计是在客户端与服务器之间建立经过认证加密的转发通道。它的基础配置通常围绕服务器地址、端口、加密方法与密码展开，参数数量相对集中，适合已有明确服务端信息、希望减少传输层组合的场景。早期流加密方案与后来的 AEAD 方案存在安全和兼容性差异，不能把所有标为 SS 的链接视为同一种实现。选用当前内核和服务端共同支持的现代方法，比单纯追求参数少更重要。

传统 AEAD 与 Shadowsocks 2022 也不能只改一个加密方法名称就互通。后者对密钥格式、长度和部分协议处理有明确要求，客户端与服务端需要配套。若订阅导入后报告密钥长度不符，应核对原始配置与方法，而不是把密钥截短或补字符。某些 SS 配置还依赖插件；插件是额外条件，不是所有客户端都能运行同样的插件程序。Mac 图形界面能识别基础 SS 字段，并不等于具备外部插件所需的执行环境。

在表现上，SS 的基础封装较少，但这不等于任何链路下都更快。加密方法是否利用硬件加速、服务器负载、单连接丢包和本地网络质量都会改变结果。UDP 转发还需要服务端允许相应流量，并与客户端配置一致。网页可以打开而语音或游戏失败时，要单独检查 UDP 能力、目标规则和 NAT 行为，不应因为 TCP 请求成功就断定整条出站完全正常。

VMess：身份认证与可组合传输

VMess 来自 V2Ray 生态，围绕用户身份认证和数据传递设计，常通过用户标识与加密选项描述出站。它可以搭配不同传输方式，也因此比基础 SS 多出需要一致的参数。服务端如果使用 TLS 加 WebSocket，客户端不仅要填对用户标识，还要匹配 TLS 服务端名称、路径以及必要的请求头。VMess 协议本身与外层传输各自承担职责，排错时应分别验证，而不是把一次握手失败统称为协议失效。

旧教程经常出现与历史认证机制相关的字段，现代配置通常采用 VMess AEAD，旧式组合未必仍被当前内核接受。不要为了沿用旧截图而添加过时参数。系统时间明显错误也可能影响认证，Mac 长时间离线后可先在系统设置中检查日期与时间。日志出现认证失败时，应同时检查时间、用户标识和服务端要求；若日志停留在证书或传输握手，则应先处理对应层次，不能仅凭失败结果推断标识错误。

实际选型时，如果已有稳定的 SS 服务且不依赖特殊插件，没有必要仅因另一种协议字段更多而迁移。VMess 服务若已经提供完整、经过维护的配置，也应先验证原配置，再讨论替换。协议复杂度带来的能力必须对应真实需求，否则只增加配置面。对于无法修改服务端的普通用户，最重要的任务不是自行设计参数组合，而是确认订阅输出适用于当前内核，并保留一条已验证可用的出站作为对照。

三、Trojan、VLESS 与 TLS 参数

Trojan：把身份验证建立在 TLS 连接内

Trojan 的典型部署以 TLS 作为外层安全通道，在通道内完成密码认证和代理请求。它沿用成熟的证书与 TLS 生态，因此配置看似集中在地址、端口、密码和服务端名称，实际可用性很依赖证书链、域名与部署方式。服务器地址用于找到连接终点，TLS 服务端名称用于身份验证等过程；两者有时不同，但不能任意互换。订阅指定了域名时，随意改成 IP 可能改变解析结果，也可能使证书名称校验失败。

客户端的 SNI 或服务端名称字段不等于 HTTP Host。前者参与 TLS 握手，后者属于 HTTP 请求语义；在带 WebSocket 等外层的部署中，它们可能分别出现。把同一个域名机械填进所有字段，既不能保证兼容，也可能掩盖原配置的真实结构。排查证书错误时，应检查系统时间、证书有效范围和中间证书链，再核对订阅中的名称。长期启用跳过证书验证，会失去确认服务器身份的重要保护。

VLESS：轻量协议与外层安全组合

VLESS 也是 V2Ray 相关生态中的代理协议，采用较精简的协议设计。它本身不提供与 SS 相同意义的内建数据加密，常依赖 TLS 或其他明确配置的安全层保护连接。因此，“VLESS 更轻量”不能简化为“少开几个安全选项就更快”。若服务端要求 TLS，客户端必须保持一致；没有可信外层保护的链路不能因为使用了用户标识就被视作已经加密。用户标识用于认证，不等于内容保密机制。

VLESS 可与不同传输及扩展组合，兼容范围随内核实现而变化。Reality 相关参数、客户端指纹和流控选项都有各自的匹配条件，不能把某一种组合的教程套到全部 VLESS 出站。尤其是流控字段，它不是通用提速按钮。只有服务端、传输结构和客户端实现都满足条件时才有意义。订阅未提供的公钥、短标识等值，不能在客户端随意生成后期待连接成功；这些参数应来自配套的服务端配置。

把证书问题与协议问题分开处理

TLS 连接失败可能发生在认证之前。证书过期、名称不符、系统信任链异常、网络中间设备干预，都可能让 Trojan 或带 TLS 的 VLESS 失败。这些问题不一定来自代理协议本身。若浏览器访问普通 HTTPS 网站也出现异常，应先确认 Mac 时间与网络环境。若只有某一出站失败，再检查服务端配置。有关错误分类，可继续阅读HTTPS 证书报错成因与排查，不要通过给系统安装来源不明的根证书来绕过问题。

连接速度方面，Trojan 与 VLESS 的实际差异常被外层 TLS、传输方式和服务器网络盖过。首次握手、连接复用、拥塞控制和目标站响应都可能成为主要成本。一次网页打开更快，不足以证明某协议始终更优。对 Mac 用户而言，先选择字段完整、证书可信、内核明确支持的配置，再比较相同网络与相同目标下的表现，通常比追求最新组合更有效。维护难度也属于成本：如果每次更新都需要手工补字段，长期稳定性可能不如现有成熟配置。

四、Hysteria2、TUIC 与 UDP 网络条件

QUIC 提供不同的传输基础

Hysteria2 与 TUIC 都利用基于 UDP 的 QUIC 技术，但它们不是同一种协议，也不能互相导入后只改类型名称。QUIC 将安全握手、可靠流和拥塞控制等机制结合起来，允许多条流共享连接，在流之间减少 TCP 层队头阻塞的影响。不过，每条可靠流内部仍需按序交付，链路拥塞也仍影响整体带宽。QUIC 不会消除丢包，只是提供不同的恢复和调度方式，其优势需要实际网络允许 UDP 并具备合适的实现支持。

在部分访客网络、企业无线网络或热点中，UDP 可能被限制、限速或采用较短的会话超时。此时 TCP 类出站能连接，并不能证明 QUIC 出站也应正常。Mac 上应先保留一条已经验证的 TCP 类配置作为对照，再判断 UDP 路径。若网络只在休眠唤醒后失效，也要考虑 NAT 映射过期和客户端重连行为，而不是直接认定认证信息错误。相同协议在家用网络与公共网络上有不同结果，是可以解释的网络条件差异。

Hysteria2 的带宽配置不是测速结果

Hysteria2 面向包括高时延、丢包等条件在内的传输需求，具体拥塞控制行为与客户端、服务端配置有关。部分配置会声明上行与下行带宽，这些值用于影响发送策略，不是从服务器获得的可用速率承诺。把下行填写得越大，不代表下载就越快；如果远超真实瓶颈，可能导致排队、丢包或干扰同一网络上的其他应用。应参考稳定可持续的链路能力，并遵循服务端给出的限制，而不是照抄别人的数字。

Hysteria 与 Hysteria2 存在协议代际差异，旧配置不能只通过重命名类型完成迁移。认证字段、混淆选项和传输参数也需要对应。若导入器把类型识别成旧协议，优先重新获取适用于 mihomo 的配置输出。客户端显示配置已保存，只能证明文本被接受，不证明服务端握手成功。应观察实际连接日志是否进入认证阶段，以及失败发生在 UDP 建连、TLS 验证还是协议认证之后。

TUIC 的复用与 UDP 转发方式

TUIC 同样建立在 QUIC 之上，关注代理连接复用和 TCP、UDP 流量承载。不同代际实现之间可能存在不兼容，认证字段和转发选项应与服务端一致。某些 UDP 转发模式在可靠性、时效性和封装成本之间取舍，不能简单认为可靠传输一定适合实时应用。语音或游戏中的过期数据即使最终到达，也未必有价值；而文件传输更关注完整交付。应优先保留服务端推荐的模式，再用真实应用验证。

这两类协议适合纳入候选，而不是作为所有场景的默认答案。若网络 UDP 质量稳定、跨距离访问明显受丢包影响，可以进行对照测试；若网络对 UDP 的支持不确定，或者需要在多种办公网络间频繁切换，应保留 TCP 类回退出站。协议选择应减少不可控条件，不能为了追求某一种传输机制而让每次换网都需要重新配置。

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

把“快”拆成三个可以观察的指标

连接速度至少包含建立连接的时间、持续传输吞吐与交互响应稳定性。浏览网页关注首次响应和许多小资源能否及时完成；下载大文件更关注持续吞吐；远程终端与会议更在意抖动和中断。某个出站延迟测试较低，不代表它在所有任务中更快。客户端常见的延迟测试通常测量到指定地址的请求耗时，并非单纯的物理往返时间，结果还包含 DNS、握手和目标站处理等成本。

比较协议时，应固定 Mac、网络、目标和测试时段，尽量选择同一服务端位置与相近资源条件。若两种配置来自不同服务器，测得的首先是两条完整路径的差别，而非协议本身。连续测试也会受缓存、连接复用和服务器负载变化影响。可以分别记录首次打开、重复访问和持续传输的表现，但不要把其中一次最好成绩当成稳定水平。更有价值的是正常工作过程中是否反复超时、重连或出现明显停顿。

CPU、内存与网络封装不是单一排序

CPU 开销来自加密、解密、协议解析、数据复制和网络栈处理。不同算法在 Apple 芯片与 Intel 上的硬件加速表现可能不同，客户端构建方式也会影响结果。TUN 额外引入虚拟接口与流量处理，DNS、规则匹配、连接记录和详细日志也占用资源。因此，不能把打开 TUN 后的总体耗电变化全部归因于所选协议，也不能拿两个不同图形客户端的内存占用直接比较它们背后的协议效率。

在 macOS“活动监视器”中，可同时观察客户端与相关内核进程的 CPU、内存和能耗趋势。测试期间保持任务相同，避免一边进行全量下载、一边比较空闲状态。若内存持续增长，应检查连接数量、日志量和订阅规模，而非先认定协议泄漏。若 CPU 只在高速传输时升高，可能是正常处理成本；若空闲仍持续高占用，再排查循环重连、DNS 请求异常或路由回环，并在帮助中心按症状继续定位。

移动端电量更受唤醒与链路状态影响

移动设备的电量不仅消耗在加密计算上。蜂窝无线模块的活跃时间、保活频率、后台重连、信号强度和 NAT 超时都可能占据更大比例。长连接能够减少重复握手，也可能因为过于频繁的保活增加无线唤醒。基于 UDP 的方案在某些网络上表现良好，在另一些网络上却需要持续重建会话。不能仅按 SS、Trojan 或 QUIC 这样的名称给出固定省电排名，更不能直接把 Mac 的 CPU 测试结论搬到手机。

如果 Mac 通过手机个人热点上网，还需把热点设备视为独立耗电环节。大流量测试可能同时提高 Mac 网络处理负载与手机无线负载。用于日常选择时，应测试常见任务和休眠唤醒，而不只是跑满带宽。减少不必要的频繁测速、过密的策略组检查以及调试日志，有时比更换协议更有效。检查周期也不宜盲目缩短：更快发现故障与更多后台请求之间存在成本，需要按实际切换需求权衡。

最终决策应允许不同任务使用不同策略组。网页、开发工具与实时应用未必需要同一出站，但分组应有清晰目的，避免为了测试把规则拆得过细。先找到稳定基线，再针对具体问题增加一个候选方案，比同时调整协议、DNS、TUN 和策略组更容易得到可信结论。

六、原版 Clash、Meta 与 mihomo 的关系

内核负责执行，图形客户端负责管理

Clash 生态中的内核负责解析配置、匹配规则和处理网络连接；图形客户端提供菜单栏、订阅管理、系统代理、权限授权和设置界面。二者有联系，但不能混为一谈。Clash Plus、Clash Verge Rev、FlClash 等是用户选择的客户端，具体协议支持仍要看它们实际集成或调用的内核。客户端界面更新也可能只调整交互，不一定同时更新所有协议实现。下载与选型可在安装包页面核对，初次配置优先从 Clash Plus 开始。

原版 Clash 建立了广泛使用的 YAML 配置习惯，包括出站、策略组与规则等基本结构。原版开源内核与曾经的其他发行分支不能简单画等号，不同分支的功能并不完全一致。Clash Meta 在相关生态基础上扩展协议和网络能力，后来项目使用 mihomo 名称。订阅或教程中出现 Meta，很多时候是在描述这一演进路线，而不是要求再安装一个独立的“Meta 插件”。理解名称沿革有助于判断资料，但不能代替功能核对。

基本结构相似，不等于所有字段双向兼容

mihomo 延续了大量 Clash 配置结构，同时增加了协议类型、规则能力和网络设置。原版内核无法识别某些新出站，是功能边界，不是 YAML 缩进一定错误。相反，旧配置迁移到新内核时，也可能受到字段弃用、默认行为变化或验证更严格的影响。配置能加载只是第一关，还应检查规则是否按预期命中、DNS 是否正确、策略组引用是否有效，以及 TUN 是否真的接管目标应用。

迁移前先保存当前可用配置与客户端设置。然后确认新客户端导入的是原始订阅、合并后的配置，还是导出的运行配置；这三者未必一样。图形客户端可能在启动内核前覆盖端口、DNS、控制接口和 TUN 字段。直接复制旧运行文件，可能把不适用的新环境参数一起带过去。应先使用客户端默认网络设置导入订阅，确认基础连接，再逐项恢复自定义规则和覆盖项，避免同时引入多个故障来源。

用小配置验证语法与默认值

下面片段是 mihomo 配置中的通用字段示例，用于理解模式、端口和日志等级，不包含远端出站，不能单独建立代理连接。合并前应检查完整配置是否已有同名顶层键，避免重复定义。混合端口同时提供本地 HTTP 与 SOCKS 入口，端口值应以当前客户端实际监听结果为准；它不是远端服务器端口，也不保证所有客户端采用相同默认值。

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

如果日志提示未知协议类型，先确认内核是否支持该类型，以及订阅是否输出正确格式。如果提示找不到策略或代理名称，应检查引用关系和订阅筛选结果。如果配置能运行但规则不生效，再看规则顺序和客户端覆盖设置。详细差异可查阅mihomo 与原版 Clash 功能对照。不要把所有错误都归为“内核太旧”，也不要在没有备份的情况下反复替换整个配置文件。

Apple 芯片与 Intel 安装包解决的是程序架构匹配，不是协议差异。优先运行适合本机架构的构建，可以减少不必要的转译环节，但同一协议是否可用仍取决于内核实现。ClashX Meta 等归档客户端可用于已有环境参考，长期使用应同时考虑维护状态与系统兼容性。选择仍在维护、能够清楚展示内核状态的客户端，通常比只看界面外观更便于处理后续配置问题。

七、Clash YAML、节点列表与订阅转换

订阅地址不直接说明内容格式

订阅链接是获取配置数据的入口，返回内容可能是完整 Clash YAML、仅含出站列表的 YAML、编码后的分享链接集合，或者 sing-box JSON。网址后缀和链接名称不足以确认格式，一些服务还会根据请求参数或客户端标识返回不同内容。导入失败时，先看错误属于下载、内容解析还是运行验证。下载成功却出现 HTML，可能是登录页、错误页或访问提示，并不意味着 YAML 语法需要修复。

完整配置通常同时描述出站、策略组、规则与其他运行设置；节点列表可能只提供连接所需字段。客户端能够导入列表，不代表列表自带适合所有用户的分流规则。有些客户端会用自己的模板补齐缺失部分，另一些要求用户明确指定。若导入后能看到出站但没有预期策略组，应检查订阅类型与模板，而不是重新填写服务器密码。配置结构的完整程度与出站数量是两个独立问题。

编码、转换与合并分别做什么

Base64 只是编码方式，不是加密，也不是代理协议。编码后的内容可能是一组 SS、VMess、Trojan 等分享链接，每条链接再携带各自字段。把文本解码出来只恢复原始表示，不会自动生成规则、DNS 或策略组。不同分享链接标准对参数的表达能力也不同，某些较新的扩展字段未必能被旧解析器理解。链接能在一个客户端导入，不代表所有客户端都按完全相同的方式解释它。

订阅转换器把一种数据模型映射为另一种数据模型，通常还会附加模板、重命名或筛选。转换可能丢失目标格式没有对应项的字段，例如特定传输扩展、指纹选项、策略组行为和 DNS 路由语义。sing-box JSON 与 Clash YAML 不只是括号和缩进不同，顶层结构及部分行为模型也不同。简单把文件扩展名改掉，或把字段逐字翻译，并不能得到可靠配置。转换后必须按实际内核重新验证。

隐私边界与更新覆盖需要提前确认

订阅通常包含可用于连接的认证数据，地址本身也可能带访问凭据。不要将完整地址贴到公开截图、在线讨论或未经确认的转换服务。远程转换意味着第三方可能接触订阅内容，应了解处理方与数据路径；若来源提供原生 mihomo 或 Clash Meta 格式，优先使用该输出，减少中间转换。需要技术协助时，可只提供错误类别、协议类型和已脱敏的结构，不必公开密码、用户标识或完整订阅网址。

更新机制同样会影响配置维护。直接编辑订阅生成的文件，下一次更新可能覆盖修改；客户端提供的覆写、合并或扩展功能更适合保存本地规则。不过，不同客户端的合并顺序不一样，追加列表也可能造成重复或顺序变化。先确认哪些字段由订阅管理，哪些由客户端控制，再决定修改位置。尤其是规则列表，前面的宽泛规则可能让后面的精细规则永远没有机会命中。

如果更新后只有部分出站消失，应检查过滤条件、重命名规则和类型支持；如果全部消失，再确认返回内容与下载状态。若更新成功但行为变化，查看模板与覆盖项是否同步变化。可以保留一份已脱敏的字段清单用于前后对照，而不是保存多份含凭据的文件到公共同步目录。关于三种常见格式的映射边界，可继续阅读订阅链接格式与转换说明，再决定是否需要转换环节。

八、按场景选型与逐层验证

先建立稳定基线，再增加协议候选

普通网页和办公访问，优先选择服务端信息完整、当前网络稳定可达、客户端明确支持的出站。成熟 SS、Trojan、VMess 或正确配置的 VLESS 都可以成为候选，没有必须统一替换为某一种协议的理由。若现有配置在常用网络中稳定，迁移应针对具体问题，例如某种传输受限、证书维护困难或应用需要 UDP，而不是单纯依据名称新旧。保留原有配置，可让新方案的变化有清楚对照。

开发工具需要先判断流量入口。浏览器正常但终端失败时，检查工具是否读取系统代理，必要时配置工具自己的代理选项或环境变量，再考虑 TUN。不要先换协议并反复测速，因为请求可能没有进入客户端。在 macOS 终端执行下方命令，可以查看当前系统代理信息；它不验证远端协议，也不能证明命令行工具一定遵循这些设置。实际监听端口仍应从客户端设置页确认。

scutil --proxy

实时会议、语音与游戏更应关注 UDP 转发、抖动和断线恢复。先确认应用是否已被接管，再检查规则命中与出站 UDP 能力。Hysteria2 或 TUIC 可以纳入候选，但只有网络允许 UDP、服务端配置匹配时才值得比较。对于频繁在家庭、办公室和访客网络间切换的 Mac，保留 TCP 类回退出站通常更实用；策略组的健康检查只能判断测试目标，不能保证每一种应用都可用。

使用一个固定任务完成验证闭环

每次修改后，用同一个目标和相同操作验证。先在客户端确认配置加载成功，再打开目标应用，查看是否出现连接记录。没有记录时排查系统代理、TUN 授权与应用自身设置；有记录但走错策略时检查规则顺序和域名解析；策略正确却握手失败时，再检查协议、认证、证书和网络路径。这样可以把一次“无法上网”拆成可定位的阶段，避免把 DNS、端口和协议同时改动。

恢复与回退也是选型的一部分

Mac 合盖后重新打开，客户端可能需要恢复接口、路由或连接。若只在唤醒后失败，可先检查网络已恢复，再切换一次已验证出站或重新建立客户端连接，并观察日志。反复失效时再检查服务权限、网络扩展以及其他 VPN 是否同时修改路由。多个接管工具并行运行可能产生回环或优先级冲突，单纯改协议无法解决。退出客户端后，也要确认系统代理是否恢复，避免指向已经停止监听的本地端口。

最终可按四项条件收敛选择：当前内核支持、服务端参数完整、常用网络可达、真实任务稳定。满足这些条件后，再比较性能与电量。若某种新组合必须依赖大量手工修补才能维持，维护成本应计入判断。首次安装按快速上手完成主线；具体症状在帮助中心查找；不熟悉的术语可到术语表对照。协议手册提供判断框架，最终依据应是本机、当前网络和实际应用的可重复结果。