# mihomo 内核 · 全平台客户端

Clash Meta下载mihomo 全平台客户端

按系统选择客户端,用 mihomo 内核执行规则分流;从订阅导入到系统代理与 TUN,逐项确认配置与流量走向。

  • 代码开源
  • Clash YAML
  • mode: rule
  • 中文文档

# 配置入口 → 规则匹配 → 策略出口

  • mihomo
  • Clash YAML
  • Rule Providers
  • Fake-IP
  • TUN

# proxy-groups

规则分流与流量接管

配置能解析,只代表第一步通过。接下来需要确认流量进入哪个入口、命中哪条规则、最终使用哪个策略组。以下五项沿实际配置顺序展开,设置示意只表达字段关系,不代表所有客户端都有相同的界面。

01

规则模式与匹配顺序

日常使用先选规则模式。mihomo 按配置中的 rules 从上到下判断,首条命中规则决定策略;前面的域名规则可能让后面的地区规则不再参与判断。自定义规则应放在兜底 MATCH 之前,规则引用的策略组名称必须真实存在。与全局模式相比,规则模式可以让工作站内网、常用直连服务和代理请求分别走不同出口。修改后在连接面板查看命中规则与策略链,而不是仅凭页面能否打开判断分流是否正确。

config.yaml · rules
mode: rule
rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY
02

系统代理与 TUN 的接管范围

系统代理适合作为首次连接的起点:开启后,遵循系统代理设置的浏览器和应用才会把请求交给本地端口。部分命令行工具、游戏或自行实现网络栈的程序不会跟随这一设置,此时再评估 TUN。TUN 通过虚拟网卡与路由接管流量,桌面端通常需要服务模式或相应权限。两者解决的是流量入口问题,不会替代节点或分流规则。先用系统代理建立可用基线,再单独测试 TUN,能更快定位权限、路由和 DNS 冲突。

config.yaml · tun
mixed-port: 7890
allow-lan: false
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
03

Fake-IP 与 DNS 映射

Fake-IP 模式为域名返回虚拟地址,内核通过映射恢复域名信息,再执行分流与实际连接。它不是把所有域名固定指向某个节点,也不是单独开启就能接管全部 DNS 请求。配置时应同时检查解析上游、TUN 的 DNS 接管以及浏览器自身的安全 DNS 设置。遇到局域网设备发现、企业域名或特定应用兼容问题,可对具体域名设置 fake-ip-filter,再观察结果;不要先把整个解析链替换掉,否则容易掩盖真正的故障位置。

config.yaml · dns
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
04

策略组选择与节点测试

节点测试衡量的是客户端访问指定测试地址的结果,并不等同于全部网站的实际速度。select 策略组用于手动选择,url-test 策略组则按测试结果自动选择候选节点;具体行为还受间隔、容差和健康检查配置影响。首次连接建议先在手动组中选定一个节点,确认目标服务可用,再启用自动选择。出现超时时,分别检查订阅有效性、节点协议和本地网络。不要反复切换全部设置,也不要把一次测试失败直接解释为内核故障。

config.yaml · proxy-groups
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    use:
      - subscription
05

订阅更新与本地覆写

订阅既可能提供完整配置,也可能仅提供节点列表,两者不能直接当作同一份文件使用。更新订阅时,客户端可能重新下载并替换原配置,因此长期使用的自定义规则更适合通过客户端支持的覆写、合并或独立规则集维护。更新完成后检查当前启用的配置、策略组引用和解析日志,确认新内容确实载入。订阅链接通常包含访问凭据,不应提交到公开仓库或在线转换页面;分享排障材料前,应移除链接、节点密码与其他识别信息。

订阅管理 · 检查项
配置类型       完整 Clash YAML
订阅更新间隔   按客户端设置
当前配置       确认已选中
本地规则       使用独立覆写
更新完成后     检查载入日志
查阅全平台安装与配置文档 →

# clients

按系统选择客户端

查看全部客户端 →

下载中心按平台列出客户端、架构和安装说明。先选图形客户端,再确认设备芯片与系统要求;mihomo 命令行内核主要面向服务器、路由器与需要自行管理进程的用户。不同客户端的界面与内核集成方式不同,不宜仅凭名称判断功能完全一致。

Windows

从 Clash Plus、Clash Verge Rev 等图形客户端开始。安装后导入订阅、选择规则模式,再开启系统代理。需要 TUN 时按客户端说明配置服务权限;同时运行多个代理工具可能造成端口占用或系统代理互相覆盖。

排查浏览器正常、终端失败的情况时,先检查终端是否设置代理环境变量,而不是重复安装客户端。退出软件前确认系统代理已恢复。

前往下载 →

macOS

先在“关于本机”确认是 Apple Silicon 还是 Intel,再选择对应安装包。系统代理、网络扩展与辅助服务的授权位置可能不同,安装后应阅读系统提示,并按客户端文档完成必要授权。

更换网络、睡眠唤醒或切换其他 VPN 后,若连接异常,先核对当前网络服务的代理设置。归档客户端适合兼容性查阅,日常使用优先考虑仍在维护的选项。

前往下载 →

Android

可选择 Clash Plus、Clash Meta for Android 等客户端,并按设备架构安装。首次连接会请求 VpnService 授权,这是系统允许应用建立本地 VPN 接口的步骤,不代表已经获得远端节点服务。

锁屏后断连应同时检查电池优化、自启动与后台限制。若设备已有其他 VPN 连接,需要先确认两者能否同时运行;连接图标存在也不能替代实际访问验证。

前往下载 →

iOS

下载中心提供 Clash Plus 的 App Store 入口与官网 clashplus.io。安装后按应用支持的方式导入订阅或配置,完成系统 VPN 授权,再选择策略组进行访问测试。

iOS 的流量接管由系统网络扩展机制管理,不能直接照搬桌面端的系统代理开关说明。配置兼容范围、后台连接行为及可用功能,应以当前应用说明为准。

前往下载 →

Linux

桌面环境可选 Clash Verge Rev 或 FlClash,按发行版选择适合的包格式。桌面代理设置不一定会自动传递给终端、容器或后台服务,需要分别确认各自的网络入口。

使用命令行内核时,应自行管理配置目录、运行权限与服务日志。启用 TUN 前检查已有路由、DNS 管理器和容器网段,先保留能够恢复网络的本地操作路径。

前往下载 →

# quickstart

订阅导入到首次连接验证

先完成一条最小可用链路,再添加复杂规则。客户端安装、节点服务与系统流量接管是三个独立环节:有软件不等于有节点,有节点不等于全部应用已经使用代理。

  1. 01

    导入并启用配置

    准备服务提供方给出的 Clash 兼容订阅,进入客户端的配置或订阅页面,选择通过链接导入;已有本地 YAML 文件时,也可使用文件导入。下载成功后选中该配置,确认代理页面能看到策略组。若提示解析失败,先核对订阅格式、链接有效性与文件缩进,不要把普通网页地址当作订阅链接。原始节点链接也不一定能作为完整配置直接载入。

    订阅链接导入步骤 →
  2. 02

    选节点,再开启接管

    在代理页面选择规则模式,进入实际承担代理出口的策略组,先手动指定一个节点。桌面端优先开启系统代理,移动端按系统提示授予 VPN 权限。不要在首次测试时同时修改 DNS、规则和 TUN;每次只改一项,便于比较结果。如果软件提示端口占用,应先退出其他代理进程,或明确调整本地监听端口及使用它的应用设置。

    系统代理设置步骤 →
  3. 03

    查看连接与规则命中

    先执行客户端的节点测试,再访问一个预期走代理的服务,并打开连接面板,检查目标域名、命中规则与最终出口。随后访问一个预期直连的服务,对照是否符合配置。延迟测试通过只说明测试请求成功,仍需验证实际应用。若浏览器可用而其他应用失败,应回到接管范围检查;若连接已进入内核却持续报错,再检查节点与远端服务。

    节点测试与生效验证 →
查看完整教程 →

# source & maintenance

开源内核与客户端边界

Clash Meta 是理解生态沿革时常见的名称,当前内核项目使用 mihomo 名称。下载站用于整理入口与配置知识;内核源码、客户端发行说明和节点服务状态应分别查阅对应项目或服务方的信息。

项目沿革:Meta 与 mihomo

搜索 Clash Meta 时,通常会同时遇到旧名称、移动客户端名称和 mihomo 内核文档。它们存在生态关联,但不是同一个安装包。mihomo 延续 Clash 兼容配置体系,并发展规则、协议和 DNS 等能力。理解这层关系后,遇到配置字段报错,应先确认实际运行的内核及其支持范围,而不是只看桌面软件的标题。

协议和字段的行为以项目文档为依据。网络上的旧教程可能沿用历史默认值,复制片段前应确认字段仍适用于当前环境,并保留可回退的配置副本。

开源协作:源码与问题反馈

mihomo 的源码、提交记录与议题可在 MetaCubeX 的公开仓库查阅。源码公开提供了追踪实现与变更的路径,但一个图形客户端可能还包含自己的订阅管理、服务进程和配置覆写逻辑。界面操作出错与内核解析出错应分别定位,反馈时给出操作路径、系统环境和已脱敏的最小配置,通常比只贴一张连接失败截图更有用。

排障日志可能带有域名、节点地址或订阅凭据。提交公开议题前先删去敏感内容,只保留复现问题所必需的字段与错误信息。

内核负责转发,界面负责管理

图形客户端通常负责导入订阅、切换配置、设置系统代理和展示连接;mihomo 内核负责根据已加载配置解析请求、匹配规则并建立连接。界面中的开关可能生成或覆盖配置字段,因此编辑文件后还需确认客户端是否保留该修改。iOS 等平台采用各自的应用集成方式,不能仅凭支持 Clash 格式就推断其内核实现完全相同。

订阅服务则提供节点及相关配置,它与客户端是另一层关系。节点到期、额度用尽或服务端异常,需要向订阅提供方确认,重新安装软件通常不能解决这些问题。

更新机制:分开检查三类内容

客户端更新、内核更新和订阅更新应分别处理。客户端更新可能改变界面与权限要求,内核更新可能调整协议或字段行为,订阅更新则刷新节点和服务方配置。升级前保存本地规则及必要设置,阅读发行说明;升级后沿首次连接流程重新检查系统代理、DNS 与规则命中,避免把旧设置残留误判为新程序故障。

需要长期维护的规则应采用可追踪的覆写方式。完整的平台安装步骤见准备工作与安装文档,配置解析、权限和路由问题可查阅配置常见问题。

# MetaCubeX / mihomo

获取内核源码

以下命令克隆源码仓库,不会安装图形客户端。编译、运行与许可证信息以仓库说明为准。

查看 mihomo 开源仓库 ↗
git clone https://github.com/MetaCubeX/mihomo.git

# technical-notes

最近技术笔记

查看全部文章 →