mihomo 内核新增了什么?与原版 Clash 内核的功能差异全览

先分清原版 Clash、Clash Meta 与 mihomo

这里所说的“原版 Clash”，通常指 Dreamacro 维护的 Clash 开源内核。它负责读取 YAML 配置、建立代理连接、执行规则匹配，并通过 HTTP、SOCKS5 或 mixed-port 向本机应用提供代理服务。原版项目停止更新后，社区分支 Clash Meta 继续扩展协议、规则、DNS 与透明代理能力，之后项目名称改为 mihomo。

因此，Clash Meta 与 mihomo 不是两套需要二选一的内核。前者是旧名称，后者是当前名称。部分客户端界面、订阅转换器和旧配置仍会显示“Meta”，判断时应查看实际内核版本，而不是只看客户端名称。

快速判断： 在终端执行 mihomo -v，或在图形客户端进入「设置」→「内核」→「内核版本」。输出中出现 Mihomo Meta 或旧版 Clash.Meta，说明使用的是 Meta 系内核。不同客户端的菜单文字可能略有差异。

内核与图形客户端也要分开理解。客户端负责托盘菜单、配置下载、系统代理开关和日志展示，真正识别 proxies、rules、dns、tun 等字段的是内核。同一份配置在两个客户端里表现不同，常见原因并不是界面，而是它们打包的内核类型或版本不同。

能力对比的基本范围

能力	原版 Clash	mihomo
基础规则代理	支持	兼容并扩展
现代代理协议	覆盖较早一代协议	增加 VLESS、Reality、TUIC、Hysteria2 等支持
TUN 透明代理	开源版能力有限，曾与 Premium 实现并存	集成多种协议栈与自动路由能力
逻辑组合规则	以线性规则为主	支持 AND、OR、NOT 与子规则
GEO 数据	基础 GEOIP、GEOSITE 使用方式	增加加载方式、下载地址与自动更新控制
流量嗅探	能力较少	提供独立 sniffer 配置段

协议支持：新增的不只是节点类型

原版 Clash 已能处理 Shadowsocks、VMess、Trojan、Snell、SOCKS5、HTTP 等常见节点。mihomo 在此基础上持续补充协议与传输层实现，较受关注的包括 VLESS、XHTTP、Reality、TUIC、Hysteria、Hysteria2、WireGuard，以及更多 Shadowsocks 插件和传输组合。具体可用字段仍取决于内核版本，订阅里出现新字段时，应先确认客户端打包的 mihomo 是否足够新。

VLESS 与 Reality

原版 Clash 不识别 mihomo 配置中的 VLESS 节点。mihomo 可读取 type: vless，并处理 uuid、flow、network、tls 等字段。使用 Reality 时，还可能包含 reality-opts、public-key 与 short-id。这些字段直接交给原版内核，通常会在配置校验阶段提示代理类型或字段不受支持。

proxies:
  - name: vless-reality-example
    type: vless
    server: example.net
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    network: tcp
    tls: true
    udp: true
    servername: www.example.com
    reality-opts:
      public-key: example-public-key
      short-id: "01234567"
    client-fingerprint: chrome

示例只用于展示字段层级，地址、UUID、公钥和短 ID 必须来自实际服务配置。Reality 相关参数需要成组匹配，不能只把普通 VLESS 节点的 tls 改为 true。

TUIC 与 Hysteria2

TUIC 和 Hysteria2 都以 QUIC、UDP 为基础，但配置字段并不通用。TUIC 常见字段包括 uuid、password、congestion-controller 与 udp-relay-mode；Hysteria2 常见字段包括 password、obfs、obfs-password 和带宽参数。节点提供方给出的协议类型必须与内核配置中的 type 一致。

网络只允许 TCP 时，这类基于 UDP 的协议可能无法建立连接。
移动网络切换 Wi-Fi 与蜂窝数据后，QUIC 会话可能需要重新建立。
节点能通过延迟测试，不代表大文件吞吐量一定更高，还要观察丢包和运营商限速。
客户端显示“配置正常”只表示 YAML 可解析，不表示服务器端参数匹配。

全局 TLS 指纹

mihomo 支持通过 global-client-fingerprint 设置全局客户端指纹，也允许部分代理节点单独填写 client-fingerprint。常见值包括 chrome、firefox、safari、ios 与 random。节点级字段通常比全局字段更具体，迁移配置时应避免同时写入互相冲突的值。

global-client-fingerprint: chrome
unified-delay: true
tcp-concurrent: true

unified-delay 用于统一延迟计算方式，使测试结果更接近完整连接过程；tcp-concurrent 会并发尝试解析结果中的多个 IP，以较快成功的连接继续工作。这些都是 mihomo 常见的顶层扩展字段，原版 Clash 配置不应依赖它们。

规则系统：从逐条匹配扩展到逻辑组合

两类内核都遵循“从上到下，首次命中即停止”的基本规则顺序。原版常用规则包括 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、PROCESS-NAME、RULE-SET 与最终的 MATCH。mihomo 保留这些写法，同时增加了更多网络属性和逻辑组合能力。

AND、OR 与 NOT

逻辑规则适合表达“同时满足多个条件”或“排除某个条件”。例如，只让 UDP 且目标端口为 443 的流量进入指定策略组，可以把网络类型和端口条件组合起来。逻辑规则的括号与逗号层级较严格，建议先用内核校验命令检查，而不是直接覆盖正在使用的配置。

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),QUIC策略
  - OR,((DOMAIN-SUFFIX,example.com),(DOMAIN-SUFFIX,example.net)),代理
  - NOT,((GEOIP,CN)),非国内流量
  - MATCH,最终选择

逻辑组合的价值不是减少规则数量，而是避免把一个条件拆成多组重复列表。规则越复杂，越需要把高频、明确的域名规则放在前面，把大范围 GEOIP、规则集和 MATCH 放在后面。

端口、网络与进程规则

mihomo 可按源端口、目标端口、入站类型、网络协议和进程路径进一步分流。常见字段包括 SRC-PORT、DST-PORT、IN-TYPE、NETWORK、PROCESS-NAME 与 PROCESS-PATH。例如 DNS 通常使用 53 端口，HTTPS 通常使用 443 端口，本地 mixed-port 则常配置为 7890。

注意： 进程规则依赖操作系统权限和内核查找方式。TUN 模式下若进程名始终为空，可检查 find-process-mode，并确认客户端具有读取连接归属所需的系统权限。容器、虚拟机和部分沙盒应用可能无法稳定返回宿主进程。

规则集与子规则

rule-providers 仍是维护大量域名和 IP 规则的主要方式。mihomo 支持 domain、ipcidr 与 classical 等行为类型，并可使用 YAML 文本或 MRS 等载荷格式。规则提供器的 behavior 必须和文件内容对应：纯域名集合不应标记为 ipcidr，包含完整规则语法的列表则应使用 classical。

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

rules:
  - RULE-SET,private-domains,DIRECT
  - MATCH,代理

interval: 86400 表示每 86400 秒，也就是 24 小时检查一次更新。远程规则首次下载失败时，内核无法凭空生成内容；应检查 URL 可访问性、文件格式、写入目录权限和日志中的 HTTP 状态码。

TUN 模式：接管范围与协议栈更完整

系统代理只影响主动读取代理设置的应用。浏览器通常可以使用系统代理，但游戏、命令行工具、部分商店应用和直接创建 UDP 套接字的软件可能绕过它。TUN 模式会创建虚拟网卡，把符合路由条件的 IP 流量交给内核，因此接管范围更广。

原版开源 Clash 与旧 Premium 内核曾存在不同的 TUN 能力边界。mihomo 将 TUN、DNS 劫持、自动路由和流量嗅探放进持续维护的同一套配置体系，并提供 system、gvisor、mixed 等协议栈选项。不同平台可用情况仍受操作系统和客户端权限影响。

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

三种 stack 怎么选

system：更多利用系统网络栈，通常性能和系统兼容性较好，但行为会受到操作系统实现影响。
gvisor：使用用户态网络栈处理更多协议细节，隔离更明确，遇到特殊网络环境时可用于对照排障。
mixed：按连接类型组合处理，是不少桌面环境的常用起点，但仍应以实际客户端建议为准。

auto-route 自动写入路由，使流量进入 TUN；auto-detect-interface 用于识别当前出口网卡；strict-route 会更严格地限制绕过路径。Windows、macOS 与 Linux 的路由实现不同，开启后若局域网打印机或 NAS 无法访问，应先检查私有网段是否被正确直连，而不是立即修改代理节点。

流量嗅探补上域名信息

TUN 接管到的连接有时只包含目标 IP，缺少原始域名。mihomo 的 sniffer 可从 TLS ClientHello、HTTP Host 或 QUIC 握手中提取域名，再交给域名规则匹配。这能减少“规则写了域名但连接只命中 IP”的情况。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - Mijia Cloud

嗅探不是 DNS 解析的替代品，也不能从所有加密连接中恢复完整域名。配置时应限制端口范围，并用 skip-domain 排除已知不适合改写目标信息的服务。排障时可先关闭嗅探对比结果，确认问题究竟来自节点、DNS、规则还是域名覆盖。

DNS 与 GEO 数据：控制项明显增加

原版 Clash 已提供 nameserver、fallback、fallback-filter、enhanced-mode 和 fake-ip-filter。mihomo 延续这些字段，并增加 default-nameserver、proxy-server-nameserver、direct-nameserver、nameserver-policy、respect-rules 等细分控制。

不同 nameserver 的职责

default-nameserver：主要用于解析其他 DNS 服务器的域名，通常填写可直接访问的 IP 地址服务器。
nameserver：处理一般域名解析，是 DNS 配置中的主要上游。
proxy-server-nameserver：专门解析代理节点服务器域名，避免节点地址解析陷入代理循环。
direct-nameserver：为按规则判定为直连的域名提供独立上游。
nameserver-policy：按域名或规则集指定 DNS 上游，实现更细粒度的解析路径。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

示例把内核 DNS 监听在 1053 端口，而不是直接占用系统常见的 53 端口。TUN 中的 dns-hijack 再把符合条件的 53 端口查询送入内核。若系统上已有本地 DNS 服务，应先确认端口占用，避免两个进程监听同一个地址。

GEOIP、GEOSITE 与 GeoSite.dat

GEOIP 根据目标 IP 所属地区匹配，GEOSITE 根据维护好的域名分类匹配，两者不是同一种数据。域名规则在 DNS 解析前就可能命中，而 GEOIP 通常需要取得目标 IP。将所有流量都交给 GEOIP 判断，既不能替代域名分类，也可能增加解析后的匹配成本。

mihomo 提供 geodata-mode、geodata-loader、geox-url、geo-auto-update 与 geo-update-interval 等顶层配置，用于控制数据格式、加载方式、下载位置和更新周期。部分版本也支持 GeoIP、GeoSite、MMDB 与 ASN 数据的独立地址。

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: https://example.net/data/geoip.dat
  geosite: https://example.net/data/geosite.dat
  mmdb: https://example.net/data/country.mmdb
  asn: https://example.net/data/ASN.mmdb

geo-update-interval: 24 通常按小时理解，表示每 24 小时检查更新。实际字段支持和数据格式会随 mihomo 版本变化，部署前应以当前内核文档及启动日志为准。下载地址返回 HTML 错误页时，即使 HTTP 状态看似正常，数据加载仍会失败。

哪些字段迁回原版 Clash 会出问题

基础的 port、socks-port、mixed-port、allow-lan、mode、log-level、proxies、proxy-groups 与常规 rules 通常容易兼容。真正造成迁移失败的，往往是 mihomo 扩展节点类型、逻辑规则和顶层增强配置。

字段或写法	mihomo 用途	迁移注意事项
`global-client-fingerprint`	设置全局 TLS 客户端指纹	原版内核不应依赖此字段
`sniffer`	从 HTTP、TLS、QUIC 流量识别域名	需要移除相关域名覆盖逻辑
`geox-url`	指定 GEO 数据下载地址	原版的数据管理方式不同
`tcp-concurrent`	并发尝试多个解析地址	旧内核可能忽略或拒绝
`VLESS`、`TUIC`、`Hysteria2`	现代代理协议	必须更换节点或继续使用 mihomo
`AND`、`OR`、`NOT`	逻辑组合规则	需要拆成原版可识别的线性规则
`listeners`	定义多个自有入站监听器	原版通常使用固定端口字段

先校验，再替换运行配置

修改 YAML 后可先在独立目录执行校验。mihomo 常用命令形式如下，其中 -d 指向包含配置与数据文件的工作目录，-f 指定配置文件：

mihomo -t -d ./mihomo-work -f ./config.yaml

校验通过只说明语法、字段和本地文件基本可读取。随后还应检查运行日志中的节点握手、规则提供器下载、DNS 监听和 TUN 路由。建议至少完成四项测试：访问一个应直连的站点、访问一个应代理的站点、执行一次 UDP 请求、关闭系统代理后验证 TUN 是否仍能接管目标应用。

如何判断是否需要 mihomo

如果配置只有 Shadowsocks、VMess、Trojan 和简单域名规则，系统代理也能覆盖所有应用，那么更换内核带来的可见变化可能不大。配置是否稳定，仍主要取决于节点参数、规则顺序和 DNS 路径，而不是内核名称本身。

以下场景更适合使用 mihomo：订阅包含 VLESS Reality、TUIC 或 Hysteria2；需要用 TUN 接管游戏和命令行程序；希望通过进程、入站或逻辑条件分流；需要独立管理节点域名 DNS；使用 GEOSITE、ASN、MRS 规则集或自动 GEO 数据更新；需要在透明代理场景中通过嗅探恢复域名。

先在客户端的「设置」→「内核」查看实际内核名称和版本。
导出当前配置，搜索 type: vless、type: tuic、type: hysteria2、sniffer: 和 geox-url:。
执行配置校验，处理未知字段、缩进错误和缺少数据文件等问题。
打开日志，将级别暂时设为 info；只有排查复杂连接时再短时间使用 debug。
逐项启用 TUN、DNS 劫持和嗅探，不要一次改动全部网络路径。