mihomo 内核特性解析：与原版 Clash 的规则、协议和运行能力差异

mihomo 与原版 Clash 的兼容关系

原版 Clash 建立了一套易于组合的配置结构：在 proxies 中定义节点，在 proxy-groups 中组织选择、自动测试或故障转移策略，再用 rules 按顺序把连接交给策略组。mihomo 延续了这一基本结构，因此常见的 Clash YAML 配置通常能够作为迁移起点。诸如 DOMAIN-SUFFIX、DOMAIN、IP-CIDR、GEOIP、MATCH 等基础规则，以及 select、url-test、fallback 等常见策略组，在两类配置中都有相近含义。

这种兼容并不代表两者的配置字段完全相同。mihomo 新增的字段、代理类型或规则语法，原版 Clash 不一定认识；反过来，旧配置中遗留的字段也可能已经被调整、废弃，或者只在特定客户端的预处理层生效。尤其是订阅转换服务生成的配置，里面可能混合内核字段、客户端专用字段和模板变量。迁移时应检查最终交给内核的 YAML，而不是只看订阅地址的名称。

配置兼容可分为三个层次

1. 语法可读取：YAML 缩进、列表和字段名称能够通过解析，内核可以启动。
2. 对象可识别：节点协议、策略组类型、规则类型和 DNS 字段受到当前内核版本支持。
3. 行为符合预期：规则命中顺序、DNS 返回结果、测速方式和流量接管范围与原配置目标一致。

仅仅显示“配置导入成功”通常只覆盖前两个层次的一部分。真正的兼容检查还要观察代理组是否完整、规则提供器是否更新成功、DNS 是否监听、日志中是否出现未知字段，以及目标网站最终命中了哪个策略。

规则系统差异：从顺序匹配到组合条件

Clash 与 mihomo 的规则处理都遵循一个关键原则：规则自上而下检查，先命中的规则决定连接去向。因此，规则数量多并不必然意味着分流准确，顺序和条件范围更重要。把宽泛的域名后缀规则放在具体规则前面，可能导致后面的规则永远没有机会执行；把 MATCH 提前，则会直接接管剩余流量。

mihomo 在基础规则模型之上提供了更丰富的匹配维度。除域名、目标 IP、来源 IP、端口和进程等常见条件外，还可以在受支持的版本中使用逻辑组合，把多个条件通过 AND、OR、NOT 关系组织起来。这样可以表达“某进程访问特定端口时走指定策略”“某域名集合且协议类型符合条件时使用代理”等更细的需求。具体规则名称与嵌套写法可能随版本演进，编写前应核对当前版本文档和启动日志。

基础规则与扩展规则的侧重点

• 域名规则：DOMAIN 精确匹配完整域名，DOMAIN-SUFFIX 匹配某个域及其子域，适合稳定的网站分类。
• IP 规则：IP-CIDR 与 IP-CIDR6 根据目标地址段判断。若需要避免为这条规则触发额外 DNS 解析，可结合规则支持情况使用相应选项。
• 地理数据规则：GEOIP 按 IP 数据库分类；mihomo 还常配合 GEOSITE 或规则集合处理域名分类。结果质量取决于数据文件来源和更新时间。
• 进程规则：可按进程名称或路径分流，适用于桌面系统，但权限、操作系统和接管方式会影响识别结果。
• 入站与网络条件：可依据入站来源、TCP 或 UDP、源地址及端口等信息细分策略，适合网关或多入口部署。
• 规则提供器：通过 rule-providers 把大型规则集拆出主配置，并按设定周期更新，再由 RULE-SET 引用。

规则提供器是大型配置中很实用的结构，但它不是“越多越好”。多个规则集可能覆盖相同域名，更新失败也可能让分流结果与预期不同。建议将必须直连的局域网和系统服务放在较前位置，将业务明确的规则集按优先级排列，并在末尾保留清楚的兜底策略。对于来源不明、长期未更新或体积异常庞大的规则集，应先确认其内容格式和行为。

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

rules:
  - DOMAIN,router.local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - RULE-SET,service-set,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

这段结构展示的是规则组织方式，不代表适合直接复制到所有环境。远程地址、策略组名称、规则集格式和存储路径都要与实际配置对应。特别是 behavior 与下载文件的内容格式必须一致，否则规则提供器可能加载失败。客户端显示更新成功后，还应查看内核日志是否完成解析。

协议支持差异：节点能导入不等于能够连接

原版 Clash 支持一批传统代理协议，并通过统一策略组完成节点切换。mihomo 在此基础上扩展了更多现代协议和传输组合，常见包括 VLESS、Reality、Hysteria2、TUIC、WireGuard，以及不同协议下的 TLS、WebSocket、gRPC 等参数组合。实际可用范围取决于 mihomo 版本、编译目标和客户端集成进度，不能只根据订阅中出现某种链接格式就判断一定可用。

订阅导入过程通常包括两个阶段：客户端或订阅服务先把节点链接转换为 YAML 对象，然后内核读取对象并建立连接。某个节点没有出现在代理组中，可能是转换阶段没有识别；节点已经显示但连接报错，则更可能是内核参数、服务器端配置、网络环境或系统时间问题。把这两个阶段分开检查，比反复重新导入订阅更有效。

协议迁移时需要核对的参数

• 服务器地址、端口、用户标识或认证信息是否完整。
• TLS 是否启用，服务器名称、ALPN 与证书相关参数是否匹配服务端。
• 传输层是 TCP、UDP、WebSocket、gRPC 还是其他形式，路径与服务名是否一致。
• Reality 场景中的公钥、短标识与指纹参数是否正确。
• Hysteria2、TUIC 等基于 UDP 的协议是否受到当前网络、路由器或防火墙限制。
• 策略组是否引用了对应节点，节点名称改动后是否产生悬空引用。

测速结果也不能完全代表真实访问体验。url-test 一般使用指定 URL 测量响应时间，并按间隔重新测试；它可以帮助选择可达且延迟较低的节点，却无法覆盖视频吞吐量、长连接稳定性、UDP 质量和目标站点自身限制。若所有节点测速正常但特定应用不可用，应继续检查规则命中、DNS 结果、IPv6 路径和应用是否绕过系统代理。

从原版 Clash 切换到 mihomo 的主要收益之一，是可以在同一策略体系中处理更多节点类型。但协议更多也意味着配置字段更复杂。对于订阅用户，优先让服务提供方生成与 mihomo 对应的配置格式；对于手工维护配置的用户，应先用单节点和简单策略组验证连接，再逐步加入自动选择、负载均衡与复杂规则。

运行能力差异：DNS、嗅探与 TUN 模式

内核的运行能力决定了流量如何进入代理系统，以及规则匹配时能看到哪些信息。系统代理通常只影响遵循操作系统代理设置的应用；TUN 模式则通过虚拟网络接口接管更广范围的 IP 流量，适合不读取系统代理设置的程序、部分游戏或需要统一处理的环境。mihomo 对 TUN、DNS 和流量识别提供了较多配置选项，但也更依赖系统权限和正确的网络参数。

TUN 模式的关键点

开启 TUN 后，客户端一般需要创建虚拟网卡、调整路由或启用自动重定向能力。不同系统上的实现细节不同，客户端可能提供 system、gVisor 或 mixed 等协议栈选项，具体可用项以当前内核和客户端为准。某个协议栈在一台设备上表现稳定，不代表在所有系统版本、虚拟机或企业安全环境中都有相同结果。

TUN 模式常见问题包括路由未正确写入、局域网访问被接管、DNS 请求走向不一致、休眠恢复后虚拟接口失效，以及其他 VPN 软件同时修改默认路由。排查时可以先关闭其他网络接管工具，确认普通系统代理模式是否可用，再开启 TUN 并检查日志。若只有局域网设备无法访问，应查看私有地址段是否配置为直连，而不是直接修改所有规则。

DNS 模式与域名规则

域名规则能否准确工作，与 DNS 处理方式紧密相关。mihomo 常见的增强 DNS 模式包括 redir-host 与 fake-ip。fake-ip 会为域名返回保留地址范围中的映射地址，再由内核在连接阶段恢复域名信息，这有助于让只发起 IP 连接的应用仍能参与域名规则匹配。某些局域网服务、设备发现、游戏平台或依赖真实地址判断的程序可能需要加入 fake-IP 过滤范围。

DNS 配置还可能区分默认解析器、代理节点域名解析器、按域名策略选择的解析器和后备解析器。这里最容易出现循环依赖：代理节点的服务器地址本身是域名，但解析该域名又被配置为必须通过尚未建立的代理访问。合理做法是为节点域名准备可直接访问的基础解析路径，并明确区分“解析代理服务器地址”和“代理建立后解析目标网站”这两个阶段。

流量嗅探的作用边界

流量嗅探可从 HTTP Host、TLS Server Name 等握手信息中识别目标域名，并补充只有目标 IP 时缺失的域名信息。这对 TUN 场景中的规则匹配很有帮助，但嗅探不是解密 HTTPS 内容，也不能保证所有连接都能提取域名。加密握手方式、QUIC、应用自定义协议或直接使用 IP 的连接，都可能限制识别效果。

启用嗅探后若出现个别应用连接异常，可以先查看被识别出的域名是否正确，再针对相关目标设置跳过策略。不要把嗅探、DNS 和规则问题混为一类：日志中有域名但策略错误，重点检查规则顺序；日志中只有 IP，重点检查 DNS 与嗅探；连接根本没有进入内核，则应检查系统代理、TUN 路由或应用自身设置。

从 Clash 配置迁移到 mihomo 的检查顺序

迁移配置最稳妥的方法不是一次启用全部扩展能力，而是先建立可验证的最小配置，再逐层恢复功能。这样能够判断错误发生在 YAML 解析、节点连接、策略组引用、规则加载、DNS 还是系统接管阶段。

1. 确认客户端实际内核。在客户端的关于页面、内核管理页或启动日志中查看内核名称与版本。界面标题中的 Clash 字样不能作为判断依据。
2. 备份原配置。保留原 YAML、订阅地址、自定义规则和 DNS 设置。客户端数据库与单独导出的 YAML 可能不是同一份内容，重要修改应单独保存。
3. 先验证 YAML 解析。导入后检查日志中的未知字段、重复键、缩进错误和规则提供器加载失败。YAML 使用空格表达层级，Tab 或错误缩进都可能改变结构。
4. 用简单策略测试节点。先建立一个手动选择组，只放少量节点，确认 TCP 与需要的 UDP 连接能够工作。此时暂不加入复杂测速和负载均衡。
5. 检查策略组引用。规则末尾指向的组必须存在；策略组内引用的节点或其他组名称也必须完全一致。名称中的空格和标点同样属于名称的一部分。
6. 逐步加载规则集。从局域网直连、核心业务规则、区域规则到最终兜底依次加入，每次观察规则提供器更新状态和实际命中结果。
7. 最后调整 DNS 与 TUN。先在系统代理模式下确认基础连接，再启用增强 DNS、嗅探和 TUN。每增加一层接管能力，都应重新测试网页、命令行程序、局域网和 UDP 应用。

出现异常时如何定位

如果内核无法启动，优先检查配置语法、字段支持和监听端口冲突；如果节点全部不可用，检查网络连通性、协议参数、系统时间和节点域名解析；如果只有部分网站方向错误，查看连接日志中的域名、目标 IP 与命中规则；如果浏览器正常而应用不可用，检查该应用是否读取系统代理，或者是否需要 TUN 接管；如果开启 TUN 后全局断网，则先恢复到系统代理模式，再检查虚拟网卡、默认路由和 DNS 监听状态。

日志级别也应按需调整。日常使用保留常规级别即可，排查时短暂启用更详细日志，并注意其中可能包含访问域名、节点地址和本地路径等信息。完成定位后恢复正常级别，可以减少无关输出和长期日志占用。

如何选择原版 Clash 或 mihomo

对当前仍在选择客户端的用户，更现实的问题通常不是单独安装哪一个命令行内核，而是选择采用何种内核的客户端。若配置只包含传统协议和基础分流，现有环境能够稳定运行，并且没有新增能力需求，迁移不必为了名称变化而仓促进行。稳定的配置、明确的规则和可重复的备份，比追逐每个新增字段更重要。

如果订阅包含 VLESS Reality、Hysteria2、TUIC 等节点，或者需要逻辑规则、规则提供器、细化 DNS 策略、流量嗅探及 TUN 接管，mihomo 通常提供更完整的实现基础。选择时还要确认图形客户端是否及时集成对应版本、能否管理内核更新、是否清楚展示日志，以及系统代理和 TUN 开关是否符合当前平台习惯。

最终可以把差异概括为：原版 Clash 奠定了配置和规则分流模型，mihomo 延续该模型并扩展协议、规则与运行能力。迁移重点不是把所有扩展开关全部打开，而是确认每个新增能力解决什么问题，并通过日志和分阶段测试验证结果。对大多数配置而言，先保证基础节点、策略组与规则顺序正确，再处理 DNS、嗅探和 TUN，能够减少最常见的连锁故障。