mihomo 内核与原版 Clash 有何不同：Mac 客户端用户的功能对照

先区分内核、图形客户端与订阅

在 Mac 上选择 Clash 客户端，首先要确认实际运行的内核。图形客户端负责菜单栏入口、订阅管理、系统代理开关和权限交互；内核负责解析配置、建立代理连接、匹配规则与处理 DNS。界面名称相似，不代表内部支持的协议相同；客户端更新，也不一定意味着内核同时更新。

mihomo 是由 Clash Meta 项目发展而来的代理内核。旧教程里的 Meta 配置、订阅服务中的 Clash Meta 输出选项，通常指向这一技术分支，但具体字段仍应以所用 mihomo 版本支持的配置为准。原版 Clash 的公开仓库已于 2023 年停止维护，历史安装包不会自动获得后续协议扩展。

Mac 用户需要核对的三个位置

• 客户端版本：在应用菜单中的「关于」窗口查看，用于确认界面和管理功能。
• 内核版本：在客户端的内核信息页面或启动日志中查看，重点记录 mihomo 名称与完整版本号；不同客户端入口名称不一致。
• 订阅输出格式：确认订阅服务生成的是 Clash 通用配置，还是面向 Clash Meta／mihomo 的配置。文件扩展名都是 YAML，并不表示字段完全相同。

功能对照：哪些差异会影响实际使用

升级收益应从需求判断。如果现有订阅只有传统节点，浏览器通过系统代理工作正常，换内核不一定明显改变速度。若订阅包含 VLESS、Hysteria2，或者需要更细的分流条件，内核能力差异就会直接决定配置能否加载、连接能否建立。

协议扩展：新增节点为什么不能交给旧内核

VLESS、Reality 与传输层是不同参数

VLESS 是代理协议，Reality 是相关 TLS 安全机制选项，WebSocket、gRPC 等属于传输方式。订阅中的 type: vless、reality-opts、network 各自承担不同作用。支持 VLESS 不等于任意 Reality 配置都能连接，公钥、短 ID、服务器名称和流控参数仍需与服务端匹配。

当原版内核报出不支持的代理类型时，修改节点显示名称、切换策略组或打开系统代理都不能解决。需要换用支持该类型的内核，或让订阅服务提供另一种服务端实际支持的节点。把 type: vless 强行改成 vmess 不是格式转换，只会造成协议不匹配。

Hysteria2 与 TUIC 还依赖网络条件

这类协议基于 QUIC，依赖 UDP 通信。mihomo 能解析配置，只说明具备协议实现；当前 Wi-Fi、公司网络或上游防火墙限制 UDP 时，仍可能超时。遇到“其他节点正常，只有这类节点失败”，应先用另一种协议交叉验证，再检查端口、认证信息和网络限制。

• 加载即报错：优先检查内核版本、节点类型和配置字段，不必先改 DNS。
• 加载成功但握手失败：检查服务端参数、Mac 系统时间和节点可达性。
• 连接建立但部分业务失败：继续排查 UDP、规则命中、DNS 与路径 MTU，避免直接归结为内核性能。

规则扩展：旧规则能保留，新规则要看语义

经典的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 和 MATCH 仍然是 mihomo 配置的重要组成。规则通常自上而下匹配，前面的规则已经命中，后面的同类规则就不会再决定该连接的出站。迁移时，保持规则顺序往往比单纯保留文本更重要。

逻辑规则与进程匹配

mihomo 可以使用逻辑组合表达更复杂的条件，也提供进程相关匹配能力。它们适合把域名、网络类型、进程等条件结合起来，但进程识别依赖操作系统、流量入口与运行权限。Mac 上不能因为规则写了 PROCESS-NAME，就认定所有连接一定能获得可靠的进程信息，应查看连接详情中的实际识别结果。

策略组名称也属于配置引用。规则末尾填写的策略名，必须能在配置中找到；订阅更新把组名改了，本地规则却保留旧名称，就可能导致配置校验失败。迁移时应一起检查 rules、proxy-groups 与 proxies，而不是只复制规则段。

规则集不是 mihomo 独有概念

rule-providers 用于把规则拆分到独立资源中，再由 RULE-SET 引用。Clash Premium 也有这类能力；mihomo 在格式和规则表达方面继续扩展。检查规则集时，需要同时核对行为类型、内容格式、下载地址以及实际文件内容。

配置字段：TUN、DNS 与嗅探应分别迁移

TUN 不等于规则模式，也不等于全局代理

TUN 负责通过虚拟网卡接收匹配路由的流量；规则模式决定接到流量之后如何选择出站。开启 TUN 后，流量仍然可以根据规则直连。所谓“全局接管”描述的是流量入口覆盖范围，不意味着所有网站都走同一个代理节点。

在 macOS 上，tun.enable、tun.auto-route、tun.dns-hijack 等字段还要与客户端的服务管理协同。部分客户端会在生成运行配置时改写这些字段。迁移时先完成普通系统代理验证，再单独启用 TUN，能把节点故障与权限、路由故障分开。

DNS：沿用 fake-ip 时要同时检查排除项

dns.enhanced-mode 中的 fake-ip 用于给域名分配合成地址，并由内核维护映射；它不是普通的公网 DNS 地址。历史 Clash 也有这套机制。mihomo 的扩展更多体现在策略与处理选项，不能把整个 DNS 模块视为全新功能。

如果旧配置带有 fake-ip-filter，迁移时应保留必要的本地域名排除规则，并检查当前版本对过滤模式的解释。出现局域网设备名称无法解析、系统门户认证失败或个别应用异常时，应结合 DNS 日志检查，而不是把所有域名都加入排除列表。

嗅探：帮助识别域名，不负责解密 HTTPS 正文

sniffer 可以根据可观察到的协议握手信息辅助识别目标域名。它不能凭空获得所有连接的域名，也不是安装根证书后解密流量的替代说法。加密握手机制、应用行为和协议差异都会限制识别结果。旧配置迁移时，不建议为了“功能齐全”一次打开全部嗅探选项。

旧配置能否直接用：按三个层次检查

多数使用常见节点、基础策略组和传统规则的旧 Clash 配置，可以作为迁移起点。但“YAML 能解析”“内核接受字段”“应用实际联网正常”是三个不同层次，不能只看到客户端显示导入成功就结束验证。

1. 结构层：检查缩进、重复键和列表格式。YAML 缩进使用空格；含特殊字符的密码和名称应正确引用。
2. 内核层：确认节点协议、规则类型、字段组合与当前版本兼容。某些未知字段可能被忽略，校验通过也不代表每个功能已经生效。
3. 运行层：观察实际使用的配置、监听端口、DNS 结果和连接命中的策略，排除图形客户端覆盖配置的影响。

本地校验示例

如果已经取得可执行的 mihomo 文件和本地配置，可以在终端进入对应目录后执行下面两条命令。示例使用文件名 mihomo 与 config.yaml，应对应本机实际文件；使用图形客户端时，优先采用客户端提供的配置检查入口，不必改动应用包内部文件。

./mihomo -v
./mihomo -t -f ./config.yaml

第一条用于确认真正运行的内核版本，第二条检查配置是否能被该内核加载。它不会替你验证所有远程节点、规则集下载与网站访问。远程资源还可能涉及网络连接和本地缓存，运行后的日志仍然需要检查。

订阅更新与本地修改分开保存

直接编辑订阅下载生成的文件，下一次更新可能覆盖修改。更稳妥的方式是保留订阅原件，再通过客户端支持的覆写或合并机制添加本地规则。不同客户端的合并顺序不一样，应查看最终运行配置，确认规则到底追加在末尾还是插入在前面。

Mac 迁移步骤：先系统代理，再验证 TUN

1. 保留可回退配置。导出当前订阅和本地覆写，记录系统代理端口、策略组选择及旧内核版本。迁移时先退出旧客户端，避免两个进程争用端口或同时写入系统代理。
2. 检查芯片与安装包。通过苹果菜单 →「关于本机」查看「芯片」或「处理器」。Apple 芯片通常对应 arm64 安装包，Intel Mac 对应 x64；架构影响程序运行方式，不改变 YAML 的基本语法。
3. 导入配置并检查日志。先处理不支持的代理类型、找不到的策略组和规则集加载错误。此时暂不同时开启 TUN、嗅探和复杂 DNS 覆写。
4. 核对系统代理。在 macOS Ventura 13 及后续系统中，可进入「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」。确认地址和端口与客户端实际监听项一致。
5. 验证规则命中。访问一个预期直连的网站和一个预期代理的网站，在客户端连接页面核对匹配规则及出站。只有网页打开，不能证明分流正确。
6. 按需启用 TUN。完成客户端要求的授权或服务安装后，再测试终端、其他应用及局域网访问。出现问题时先关闭 TUN，与系统代理结果对照。

用明确端口测试，避免把终端行为误判为内核故障

下面假设当前配置确实把混合代理端口设为 7890。如果客户端显示的是其他端口，应替换为实际值。该命令显式指定 HTTP 代理，因此不依赖终端是否读取 macOS 系统代理：

curl --proxy http://127.0.0.1:7890 --head https://example.com

收到 HTTP 响应可以说明这条显式代理请求已到达目标，但不能证明所有应用都被接管，也不能单独证明请求用了远程节点；出站仍由规则决定。如果提示无法连接 127.0.0.1:7890，先检查本地监听和端口，不要立刻更换订阅。

测试 TUN 时，应使用没有显式代理参数的请求，并留意终端是否还设置了 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。否则请求可能继续经过环境变量指定的代理，使测试结论失真。

如何判断是否需要升级 mihomo

• 订阅已使用新协议：优先确认内核支持 VLESS、Reality、Hysteria2 或 TUIC，以及对应字段是否适用于当前版本。
• 需要接管更多应用：同时比较客户端的 macOS TUN 服务管理、权限提示和故障恢复能力，不能只看内核功能表。
• 需要复杂分流：检查逻辑规则、进程识别和规则集格式，并为关键规则准备实际访问测试。
• 现有使用已经稳定：先备份再迁移，保留原来的验证清单；内核更新不能替代节点质量、网络环境和配置正确性。

对于 Mac 用户，可靠的升级路径是：确认图形客户端实际使用的内核，选择匹配的订阅格式，校验配置，再逐项验证系统代理、DNS 和 TUN。mihomo 扩展了协议与分流能力；这些能力能否转化为可用连接，取决于服务端参数、客户端集成和本机网络设置是否一致。

需要继续核对字段含义，可查阅本站协议手册；遇到端口冲突或系统代理未恢复，可先按帮助中心的排查路径定位。