内核进阶 预计阅读 13 分钟

mihomo 内核特性解析：与原版 Clash 的配置差异和迁移重点

对照内核能力、规则语法与兼容边界，说明从旧版 Clash 配置迁移时需要关注的项目。

在 Clash 客户端中，图形界面负责配置导入、策略切换和运行状态展示，真正处理连接、DNS、规则匹配与代理协议的是内核。mihomo 是由 Clash.Meta 延续发展的兼容内核。很多客户端已经把它作为默认核心，但界面仍可能沿用 Clash、Meta 或 Premium 等名称。因此，判断当前能力时不能只看客户端名称，还要查看实际加载的核心类型、核心版本和启动日志。

旧版 Clash 配置通常可以作为迁移起点，但“能够读取”不代表运行结果完全一致。mihomo 扩展了代理协议、规则类型、DNS 控制、流量嗅探、TUN 路由和规则集格式，也对部分字段采用了更明确的处理方式。迁移的重点不是一次性启用全部新功能，而是先保持原有分流结果，再逐项打开增强能力。

内核定位与兼容边界

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

原版 Clash 建立了 YAML 配置、代理组、规则分流和外部控制接口等基础结构。Clash.Meta 在这套结构上扩展了协议、DNS、TUN、规则表达式和流量识别能力。项目后续以 mihomo 名称继续维护，所以配置文档、日志或客户端设置中仍可能看到 Meta 字样。对迁移而言，可以把 mihomo 理解为延续 Clash 配置模型、同时加入更多网络处理能力的内核，而不是一套完全独立的配置体系。

兼容边界主要受三层因素影响。第一层是内核本身：某个字段是否被当前 mihomo 版本支持。第二层是客户端：界面能否把字段写入实际配置，是否会在启动前合并覆写。第三层是订阅来源：远程配置是否包含目标内核不认识的协议或规则。排查时需要把三层分开，不能只根据界面上的开关判断最终配置。

为什么同一份 YAML 会出现不同结果

一份配置在旧内核中启动成功，换到 mihomo 后仍可能出现 DNS 结果、规则命中或路由范围变化。常见原因包括客户端自动注入 DNS 配置、不同内核对网络接口的选择不同、GeoData 数据库版本不同，以及 TUN 栈和系统路由实现发生变化。相反，mihomo 专属字段放回旧版 Clash 时，可能被拒绝、忽略或导致配置载入失败。

迁移前应先确认客户端是否提供“查看运行配置”或“导出最终配置”功能。订阅原文、客户端覆写后的配置和内核实际载入的配置可能不是同一个文件。只有最终配置才能解释端口、DNS 与路由为何按当前方式工作。

检查层级 重点项目 常见现象
客户端 核心选择、覆写脚本、运行权限 界面已保存，但内核参数没有变化
内核 版本、支持字段、启动日志 字段未知、规则集解析失败
配置 YAML 缩进、策略引用、端口 配置无法载入或策略组为空
系统网络 路由、DNS、网络接口、防火墙 TUN 已启动但部分程序无法联网

mihomo 的主要能力差异

代理协议与出站能力

原版 Clash 的配置核心是把多个代理节点组织进策略组，再由规则选择策略。mihomo 保留了这一逻辑，并扩展了可用协议与传输选项。实际可用范围仍取决于具体版本和客户端打包方式。迁移订阅时，如果节点使用较新的协议，应先确认当前客户端附带的 mihomo 版本能够解析对应字段，再检查服务端参数是否完整。

协议支持并不等于节点一定可连接。证书名称、传输层参数、用户标识、加密方式、UDP 支持和系统时间都会影响握手。遇到单个节点失败时，应先看内核日志中的连接阶段，而不是反复切换全局模式。若全部节点都失败，再检查订阅是否被客户端转换、网络是否限制目标端口，以及 DNS 是否能解析服务器地址。

规则系统与规则集合

mihomo 延续从上到下匹配规则的方式。连接命中第一条符合条件的规则后，就会交给指定策略。常见规则包括域名、域名后缀、IP 网段、进程、GeoIP、GeoSite 和远程规则集合。最后通常使用 MATCH 接收尚未匹配的流量。

rules:
  - DOMAIN-SUFFIX,example.net,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,cn,DIRECT,no-resolve
  - MATCH,Proxy

迁移时要检查规则引用的策略名称是否真实存在。策略名区分具体字符，订阅更新后如果把 Proxy 改成了其他名称，规则即使语法正确也无法按预期运行。GeoSite 与 GeoIP 还依赖本地数据文件；数据库缺失、下载失败或版本不一致时，同一域名可能得到不同判断。

规则集合适合把大量域名或网段拆出主配置。mihomo 支持多种规则集行为和格式，但旧客户端未必能识别较新的格式。迁移初期可以保留已经验证过的 YAML 或文本规则集，确认稳定后再考虑更紧凑的格式。不要在同一次迁移中同时更换内核、规则数据源和全部策略名称，否则出现偏差时难以定位变量。

DNS、Fake IP 与域名映射

mihomo 的 DNS 模块可以独立指定上游服务器、代理节点域名解析服务器、回退策略和按域名选择的解析器。在 fake-ip 模式下，内核会向应用返回保留地址，并保存这个地址与原域名的映射。后续连接进入内核后，可以继续按域名规则分流。该机制对只提供目标 IP 的应用尤其重要，但也要求 DNS 请求确实进入内核。

如果系统仍把 DNS 请求发送到其他本地服务，或者浏览器启用了独立的加密 DNS，内核可能看不到原始域名。此时会出现域名规则未命中、检测结果混合或部分应用绕过分流的现象。TUN 场景下可配合 DNS 劫持，但端口冲突、局域网 DNS 和企业网络策略仍需单独评估。

TUN、嗅探与应用流量接管

系统代理通常只影响遵循操作系统代理设置的程序。命令行工具、游戏、部分商店应用和直接建立 UDP 连接的程序可能绕过它。TUN 模式通过虚拟网络接口和系统路由接收更广范围的流量，再交给内核判断。mihomo 提供多种 TUN 栈及自动路由相关选项，但各系统的权限和路由实现不同。

流量嗅探用于从已建立连接中识别域名信息，以改善只有目标 IP 时的规则匹配。它不是对所有协议都有效，也不应替代正确的 DNS 配置。迁移时建议先验证常规 DNS 与规则，再按应用范围启用嗅探，避免把规则偏差和嗅探改写目标混在一起。

配置字段与语法迁移重点

先保留基础端口与控制接口

基础字段在两类内核之间较为接近。迁移时可以先保留混合端口、局域网访问、运行模式、日志等级和外部控制接口。端口号需要与客户端界面和系统代理设置一致，控制接口则应配合访问密钥及合理的监听范围。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "local-control-key"

mixed-port 同时接收 HTTP 与 SOCKS 代理请求，适合大多数桌面客户端。如果旧配置分别使用 port 和 socks-port，可以暂时保留原结构，确认调用这些端口的程序已经迁移后再合并。不要让多个客户端同时监听相同端口，否则后启动的内核会直接报地址占用。

规则提供器的行为类型

rule-providers 的关键不只是下载地址，还包括 behavior、format、本地路径和更新周期。domain 适合域名集合，ipcidr 适合 IP 网段，classical 可以容纳带类型和策略前条件的经典规则。行为类型与文件内容不匹配时，规则集可能下载成功却无法解析。

rule-providers:
  private-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domains.yaml
    url: https://example.invalid/rules/private-domains.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - MATCH,Proxy

规则提供器的 URL 只是数据来源，最终仍要通过 RULE-SET 放入有序规则列表。定义了提供器但没有引用，不会参与分流。迁移后应从连接日志或客户端连接页面查看规则命中项，确认流量确实进入预期规则集。

DNS 配置的最小可验证结构

DNS 配置适合分阶段增加。第一阶段只启用内核 DNS、指定监听地址和稳定上游；第二阶段启用增强模式；第三阶段再增加按域名策略、代理节点专用解析器与过滤列表。下面的结构展示字段关系，具体上游应按所在网络和使用需求选择。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

proxy-server-nameserver 主要用于解析代理服务器自身的域名，避免在建立代理连接前出现解析依赖。若节点服务器直接填写 IP，该项影响较小。启用 IPv6 前，应确认本地网络、代理节点和规则都能正确处理 IPv6；仅打开 DNS 的 IPv6 返回，并不能保证后续连接具备可用路径。

TUN 字段不能脱离系统环境复制

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

这组字段表达的是常见方向，不代表所有系统都应使用完全相同的值。虚拟机、容器、VPN、企业安全软件和多网卡环境会改变默认路由。Windows 通常需要客户端具备创建虚拟接口和修改路由的权限；macOS 可能触发网络扩展或系统授权；Linux 则需要相应网络管理能力。若启用后局域网设备不可达，应检查路由表和排除网段，而不是直接修改代理规则。

从旧版 Clash 迁移到 mihomo 的操作顺序

  1. 记录当前基线。

    保存原始 YAML、客户端覆写规则和订阅地址，记录当前系统代理端口、控制端口、DNS 模式、TUN 状态及正常工作的策略组。截图只能辅助对照，仍应保留可恢复的配置文件。

  2. 确认客户端实际核心。

    在客户端的内核设置、关于页面或启动日志中查看核心名称与版本。部分客户端切换核心后需要完全重启，只重载配置可能仍由旧进程处理流量。

  3. 执行语法检查。

    先处理 YAML 缩进、重复键、空策略组和不存在的策略引用。字符串中包含冒号、井号或特殊字符时使用引号。配置解析错误应从日志指出的行附近开始检查，但真正问题可能位于上一段缩进。

  4. 以系统代理验证基础链路。

    暂时关闭 TUN、嗅探和复杂 DNS 覆写，只启用一个已确认可用的代理节点与简单规则。测试直连、代理和拒绝三种策略是否分别命中。如果基础链路失败，优先处理节点与端口，不继续叠加高级功能。

  5. 恢复策略组与规则集。

    逐个确认 select、url-test、fallback 等组内成员有效，规则目标与策略名一致。自动测试组的测试 URL、间隔和容差会影响选中结果，不能把一次延迟最低直接视为长期最优。

  6. 迁移 DNS。

    先确保内核监听端口没有被占用，再确认系统或 TUN 把查询交给该监听地址。分别测试普通域名、规则集域名和代理服务器域名，观察日志中的解析器与最终规则。

  7. 最后启用 TUN 与嗅探。

    启用后检查默认路由、局域网访问、休眠恢复和网络切换。对出现异常的程序记录目标地址、协议和命中规则，再决定增加排除项或调整嗅探范围。

订阅迁移还要区分“远程配置”和“本地覆写”。远程更新可能覆盖节点与策略组，本地覆写则用于保留端口、DNS 或自定义规则。若客户端支持配置合并，应明确合并顺序；否则每次订阅更新后都要确认自定义字段是否仍然存在。不要直接编辑客户端管理的缓存文件，因为下一次更新可能重新生成它。

迁移后的常见问题与定位方法

配置可以载入，但没有流量经过内核

先确认系统代理是否指向当前 mixed-port，再检查客户端进程是否真的在监听该端口。浏览器可能保留旧代理设置，命令行程序也可能读取环境变量中的旧端口。使用 TUN 时，则应查看虚拟接口是否建立、默认路由是否变化，以及当前网络接口是否被正确识别。

域名规则不命中，只显示 IP 规则

这通常表示内核没有取得目标域名。检查应用是否使用独立 DNS、系统查询是否进入内核，以及 Fake IP 映射是否有效。若只是少量协议无法提供域名，可以再评估嗅探；若所有程序都只剩 IP，优先修复 DNS 路径。还要确认规则顺序，位于前方的 IP 或规则集合可能已经提前接收流量。

规则提供器更新失败

检查下载 URL、网络路径、文件格式和本地目录权限。首次启动时，远程规则可能尚未缓存；如果下载本身依赖尚未建立的代理策略，就会形成启动阶段的依赖问题。可以先让规则源具备明确的访问路径，待文件成功落盘后再恢复完整分流。日志中的 HTTP 状态、解析错误和文件路径比界面的统一“更新失败”提示更有定位价值。

TUN 启用后局域网或部分应用断开

先关闭 TUN 验证问题是否与虚拟路由相关，再检查私有网段、网关、局域网 DNS 和其他 VPN。多网卡设备还应确认自动检测选择了正在联网的接口。若只有特定 UDP 应用异常，应查看节点是否支持 UDP、策略组是否选择了正确出站，以及系统防火墙是否允许虚拟接口流量。

订阅更新后策略名称变化

规则、规则集合和客户端快捷选择都可能引用策略名称。更新后若策略被重命名，旧规则会指向不存在的目标。处理方式是统一命名并检查所有引用，而不是仅在界面中重新选择一次。对于长期保留的自定义规则，可使用稳定的本地策略组作为中间层，再把订阅节点放入该组。

mihomo 迁移检查清单

mihomo 的价值主要体现在持续维护的内核能力、更完整的规则与 DNS 控制，以及对现代网络接管场景的适配。迁移是否成功，应以连接日志、规则命中、DNS 路径和系统路由的实际结果为准。只要按基础代理、规则、DNS、TUN 的顺序逐层验证，旧版 Clash 配置通常可以平稳过渡，同时保留清晰的故障回退点。

下载Clash