mihomo 内核与原版 Clash 的差异：特性、配置兼容与选择

比较范围：内核、客户端与配置文件

讨论 Clash 与 mihomo 的差异时，首先要把“内核”和“客户端”分开。内核负责读取 YAML、建立代理连接、执行 DNS 解析、匹配规则并开放本地监听端口；桌面或移动客户端则提供订阅管理、系统代理开关、日志查看、配置编辑和服务安装等界面。一个客户端采用 mihomo 内核，并不表示它的所有设置都写进主配置文件；反过来，配置中存在某个字段，也不代表客户端界面一定提供对应开关。

本文所称“原版 Clash”，主要指 Dreamacro 项目形成的经典开源内核及其常见配置基线。历史上还存在能力不同的 Premium 构建，因此不能把所有曾以 Clash 命名的版本归为同一套功能。mihomo 源自 Clash Meta 延续的内核分支，在经典配置结构之上扩展了代理协议、规则类型、DNS 行为、TUN 接管方式和外部资源管理能力。

两者的共同基础仍然很明显：配置通常使用 YAML；代理节点放在 proxies；策略组放在 proxy-groups；分流规则放在 rules；运行模式由 mode 控制。常见的 mixed-port、allow-lan、log-level 和 external-controller 等字段，也延续了相近的用途。正因基础结构相似，许多经典配置可以被 mihomo 读取，但“可以启动”不等于“行为完全一致”。

核心能力差异：从协议到流量接管

经典 Clash 配置主要围绕 HTTP、SOCKS5、Shadowsocks、VMess、Trojan、Snell 等代理类型组织。mihomo 在保留常用类型的同时，加入或完善了 VLESS、TUIC、Hysteria2、WireGuard 等类型，并为部分协议提供更细的传输层、TLS 指纹、UDP 与多路复用参数。若订阅中已经包含这些新类型，经典内核通常无法仅靠改字段名完成连接，因为相应的协议实现本身并不存在。

流量识别也是差异集中的位置。mihomo 可根据配置启用协议嗅探，用实际访问域名辅助处理只有目标 IP 的连接；它还可以结合进程名、进程路径、入站类型、网络类型和目标端口进行分流。此类能力适合 TUN 接管、透明代理或需要细分应用流量的场景，但也提高了配置复杂度。嗅探范围、跳过域名以及端口列表设置不当，可能让访问目标与预期规则不一致，因此不应把所有扩展项一次性全部开启。

外部控制接口的基础概念在两类内核中相近，客户端通常通过控制端口读取连接、日志和策略组状态。不过控制 API 的具体字段与功能会随内核版本变化。旧客户端界面即使能够启动新版 mihomo，也可能无法显示新增策略信息；新版客户端连接旧内核时，也可能出现按钮可见但调用不生效的情况。内核与客户端壳之间应按发布方提供的组合使用。

配置兼容边界：能解析、能运行与结果一致

检查配置兼容性可以分为三个层次。第一层是语法解析：YAML 缩进、列表和数据类型是否正确，内核是否认识字段。第二层是资源可用：代理节点、规则集、Geo 数据和 DNS 上游能否加载。第三层是运行行为：相同请求是否进入相同策略组，DNS 是否返回预期结果，系统流量是否实际经过对应入站。迁移时只看到“配置载入成功”，还不足以确认后两层。

下面是一段两类配置中都较常见的基础结构。实际节点参数应来自所使用的配置来源，示例重点是字段之间的关系。

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

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

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

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

迁往 mihomo 时，经典字段往往可以保留，再按需要增加扩展项。反向迁移则更严格：配置中的新协议节点、rule-providers、sniffer、扩展 DNS 字段、逻辑规则或 mihomo 专用策略参数，都可能被旧内核拒绝，或无法按原设计执行。删除“不认识的字段”并不是通用修复方法，因为被删除的部分可能正是节点建立连接或规则正确匹配所必需的条件。

还要区分主配置与客户端覆写。许多图形客户端会在启动内核前合并本地设置，例如控制端口、运行目录、TUN 开关、密钥、DNS 覆写或系统代理端口。用户编辑的 YAML 可能只是最终配置的一部分。排查兼容问题时，应从客户端导出或查看实际运行配置，并在日志中确认内核最终读取的路径，避免一直修改没有被加载的文件。

容易在迁移中遗漏的字段

• proxy-providers 与 rule-providers 的路径、URL、更新间隔和行为类型。
• 策略组内引用的节点名、提供者名，以及规则末尾引用的策略组名。
• external-controller、认证密钥和客户端控制接口地址。
• geodata-mode、Geo 数据加载方式及对应资源文件是否存在。
• DNS 的 enhanced-mode、fake-ip-range、过滤列表和上游分组。
• TUN 的协议栈、自动路由、DNS 劫持和接口排除设置。

规则支持：类型增多不等于优先级改变

Clash 系列内核的规则通常自上而下匹配，命中后就使用该行指定的策略。mihomo 增加了更多规则类型，但没有把“更具体的规则自动优先”作为普遍替代机制。若一条宽泛的 DOMAIN-SUFFIX 放在精确 DOMAIN 前面，前者仍可能先截获请求；若 MATCH 提前出现，后面的规则便没有机会执行。

常见规则包括 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、IP-CIDR6、GEOIP、DST-PORT、SRC-IP-CIDR、PROCESS-NAME 和 MATCH。mihomo 环境还经常使用 GEOSITE、RULE-SET、NETWORK、PROCESS-PATH 以及逻辑组合规则。具体可用类型仍应以内核版本文档和启动日志为准。

RULE-SET 本身不会凭空产生规则，它引用的是 rule-providers 中定义的外部规则集。规则集常见行为有 domain、ipcidr 和 classical。domain 适合域名类条目，ipcidr 适合 IP 网段，classical 则可容纳带规则类型的经典条目。行为类型与实际内容不匹配时，文件可能下载成功，但条目无法按预期加载。

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

rules:
  - RULE-SET,private-domains,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,PROXY

no-resolve 常用于不希望规则匹配阶段主动解析域名的 IP 类规则。它并不代表整个连接不需要 DNS，也不会关闭 DNS 模块；它只是影响该条规则匹配时是否触发解析。把它机械地加到所有规则后面，既不能提升所有场景的速度，也可能改变原本依赖解析结果的匹配路径。

进程规则在不同系统上的可用性也不完全相同。桌面系统通常更容易取得进程名或路径，移动系统受权限和网络栈限制，客户端未必能向内核提供相同信息。迁移一套依赖 PROCESS-NAME 的桌面配置到手机时，应准备域名或 IP 规则作为补充，而不是假设规则文本相同就会得到相同结果。

DNS 与 TUN：差异最容易被误判的区域

普通系统代理主要接收明确使用 HTTP 或 SOCKS 代理的应用流量，TUN 模式则通过虚拟网络接口接管更广范围的连接。mihomo 的 TUN 配置常见字段包括 enable、stack、auto-route、auto-detect-interface 和 dns-hijack。这些字段能否生效，还取决于操作系统权限、路由表、防火墙、客户端服务以及其他 VPN 软件是否同时占用网络接管能力。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

这段配置展示的是字段关系，不是所有设备都应直接采用的固定答案。不同 mihomo 版本支持的 TUN 协议栈选项可能调整，客户端也可能自动生成相关字段。若客户端已经管理 TUN，重复在订阅配置中写入另一套参数，可能在每次更新时被覆写，或者与本地路由设置冲突。

DNS 的 fake-ip 模式会先向应用返回保留地址段中的映射地址，再由内核关联真实域名并执行规则。它有利于在透明接管场景中保留域名信息，但局域网设备发现、部分游戏、特定认证流程和依赖真实 DNS 回答的程序可能需要加入 fake-ip-filter。redir-host 的处理路径不同，兼容表现也会随系统和应用变化。选择模式时应依据故障表现测试，而不是只比较字段数量。

mihomo 还提供 nameserver-policy、proxy-server-nameserver、direct-nameserver 等更细的 DNS 分工。前者可让特定域名使用指定上游；后两者用于区分代理服务器地址与直连目标的解析路径。它们能够减少 DNS 路径混用，但配置错误也可能形成循环：例如解析代理服务器域名时，所选 DNS 本身又必须先通过尚未建立的代理访问。

从原版 Clash 迁移到 mihomo 的校样步骤

稳妥迁移应从一份能够正常工作的配置副本开始，不要在唯一文件上连续叠加修改。先验证基础代理，再增加规则集、DNS 和 TUN，可以快速判断故障属于节点连接、规则匹配还是系统接管。

1. 记录当前运行信息。 保存原内核版本、客户端版本、监听端口、系统代理状态、DNS 模式和可用策略组。若迁移后行为变化，这些信息可作为对照。
2. 检查 YAML 结构。 确认缩进只使用空格，节点名与策略组引用完全一致，端口是数字，布尔值没有被意外写成字符串。先解决解析错误，再处理网络错误。
3. 建立最小连接测试。 暂时使用一个已知可用的节点、一个 select 策略组和少量规则。确认本地混合端口可访问后，再导入完整订阅或代理提供者。
4. 逐项恢复规则资源。 查看每个 provider 的下载状态、文件路径、behavior 和 format。规则集更新失败时，不要只观察策略组是否存在，还应在日志中确认条目数量。
5. 单独验证 DNS。 分别检查代理服务器域名、直连域名和需要代理的域名。若域名失败而直接访问 IP 正常，问题通常更接近 DNS 路径，而不是节点协议。
6. 最后启用 TUN。 先关闭其他 VPN 或流量接管工具，确认管理员权限与服务组件正常，再观察路由表、DNS 劫持和局域网访问。普通系统代理可用而 TUN 不可用时，应集中检查系统层配置。
7. 核对最终生效配置。 若客户端支持覆写、脚本或混入功能，应查看合并结果。订阅更新后再次确认本地规则和 DNS 修改是否仍然存在。

日志中的错误类型能缩小范围。出现 unknown field 或配置解析失败，通常指向字段与版本不匹配；出现规则提供者下载失败，应检查 URL、网络路径和保存目录；出现连接超时，则要继续区分代理服务器解析、传输握手、路由与规则选择。不要因为多个错误同时出现，就一次改动端口、DNS、节点和 TUN，批量改动会失去可比较的基线。

如何选择：依据配置来源与实际功能

如果现有配置只使用经典协议、简单策略组和少量域名规则，并且客户端与内核组合长期稳定，继续使用兼容的经典环境可以减少变更成本。但应留意项目维护状态、操作系统升级和客户端支持情况，尤其是控制接口、系统代理服务与证书组件是否还能正常配合。

如果订阅包含 VLESS、TUIC、Hysteria2 等较新的节点类型，或配置依赖 GeoSite、规则提供者、逻辑规则、协议嗅探、精细 DNS 分流和持续维护的 TUN 能力，mihomo 通常是更匹配的选择。此时应选择明确标注所用内核版本的客户端，并让客户端、内核和配置语法处于相互支持的版本范围内。

选择时不必追求字段最多。对普通桌面用户，稳定的系统代理、可更新的订阅和清晰的策略组已经覆盖主要需求；对需要游戏 UDP、局域网共享、容器网络、按进程分流或全局 TUN 接管的用户，则应重点测试对应操作系统上的实现。相同 YAML 在 Windows、macOS、Linux、Android 与 iOS 上可能因为权限和网络框架不同而表现不同。

选择前的四项确认

• 订阅中的节点协议是否被目标内核支持。
• 规则是否依赖 mihomo 专用类型、Geo 数据或外部规则集。
• 客户端是否能管理所需的 TUN、服务模式和系统代理设置。
• 配置更新机制是否会保留本地覆写与自定义规则。

从配置管理角度看，mihomo 更适合承载正在扩展的规则与协议需求，经典 Clash 配置则仍是理解端口、策略组和自上而下规则机制的重要基础。迁移的关键不是把旧文件改成更多字段，而是逐项确认协议实现、资源文件、DNS 路径和系统接管方式。保持一份最小可用配置，并让每次改动都可验证，通常比直接复制一份复杂配置更容易得到稳定结果。

常见问题