访问验证

mihomo GitHub 怎么找？仓库、Release 与下载文件核验指南

更新于 2026-11-05 · liuheng2024.store

简答：先记住三步：优先从 <a href="https://github.com/MetaCubeX/mihomo/releases">MetaCubeX/mihomo 的 Releases 页面</a>核对版本和文件，再按系统与 CPU 架构选择压缩包，最后用配置检查命令确认文件可启动。2026-11-05 检索时，Release 列表显示 v1.19.33，同时还有 Prerelease-Alpha；如果你只是正常使用，优先选择稳定 Release，不要直接选 Alpha。本文是第三方使用指南，不能替代项目页面本身。

定义：Mihomo GitHub 通常指 MetaCubeX 组织下用于查看 Mihomo Release、源代码、Wiki 和相关 Dashboard 的 GitHub 入口，但仓库首页、版本发布页、文档和面板并不是同一个东西。

先看这张入口与选择表

搜索“mihomo github”时，最容易混淆的是仓库首页、Release 页面、安装文档和 Web Dashboard。它们的用途不同，下载时不要只凭搜索结果中的第三方镜像或二次打包页面判断。

你要完成的事情优先查看的位置判断重点
确认版本和下载文件GitHub Releases版本标签、Stable 或 Pre-release、系统、架构、文件扩展名和校验值
按系统和架构选文件mihomo 安装文档Windows、Linux、macOS、FreeBSD、Android，以及 amd64、386、arm64、armv7
查看配置语法和功能mihomo 文档YAML 配置、DNS、TUN、代理组、规则和 API
使用网页面板管理metacubexd它是 Dashboard，不是 Mihomo 内核本身；需要连接正在运行的控制器

需要特别注意：当前仓库首页的 About 文本与 Releases 页面中的 Mihomo 二进制内容并不完全一致。因此，核验下载时应同时检查组织名、Release 标签、文件名、提交或发布信息，不能只看仓库简介一句话。

2026-11-05 如何核对 Mihomo 最新 Release

  1. 打开 Releases 页面，确认列表顶部的版本标签。当前检索页面显示 v1.19.33，并单独列出 Prerelease-Alpha。
  2. 点击具体版本，确认它是否标记为 Pre-release。稳定使用通常选择普通版本标签；Alpha 适合需要测试最新提交、且能够自行回滚配置和程序的用户。
  3. 查看 Assets 文件名。文件名通常包含程序名、操作系统、CPU 架构、编译兼容标签和版本号，例如 Windows、Linux、macOS、Android 等系统标识。
  4. 如果页面加载不完整或只看到部分附件，不要根据搜索摘要猜文件名。回到 Release 页面展开完整 Assets，或者改用安装文档中的系统和架构筛选器。

版本号会随项目更新变化，本文只记录在 facts.today，即 2026-11-05 检索到的页面状态；以后下载前应重新打开 Release 页面核对。

按系统与 CPU 架构选择下载文件

官方文档的预编译入口提供 Windows、Linux、macOS、FreeBSD 和 Android，并列出 amd64/x86_64、386/x86_32、arm64/armv8、armv7 等架构。选择文件时，先看操作系统，再看架构，最后看兼容标签。

设备情况常见选择方向不要忽略的检查
普通 64 位 Windows 或 Linux 电脑系统名加 amd64/x86_64确认系统不是 ARM 设备；Windows 文件通常还要区分压缩格式
Apple 芯片 MacmacOS 加 arm64/armv8不要误选 darwin-amd64；旧 macOS 还要留意 go 兼容标签
Intel MacmacOS 加 amd64根据系统版本和文档提示选择 compatible 或 go 标签
旧 32 位设备386/x86_32 或 armv7先确认设备确实是 32 位，否则可能无法运行
Android 设备android 加对应架构arm64、armv7、amd64 和 386 不能混用

Release 文件名中的 v1、v2、v3主要用于 AMD64 CPU 指令集等级；go120等标签表示编译时使用的 Go 版本，可能用于兼容特定系统。官方 FAQ 也说明，不能只看“amd64”四个字符，还要结合系统版本和编译标签判断。

如果你无法确认架构，不要下载后反复尝试。Windows 可在“设置—系统—关于”查看系统类型；macOS 可在“关于本机”查看芯片信息；Linux 可运行下面的命令。

uname -m

适用系统：Linux 和 macOS。预期结果通常是 x86_64、amd64、aarch64 或 arm64。如果命令不可用或结果与设备信息冲突，先以系统设置页面为准，不要继续猜测下载文件。

下载、解压与首次启动的最小流程

Windows

  1. 从 Release Assets 下载与 Windows 和架构匹配的压缩包。
  2. 新建一个独立目录，例如 C:\mihomo-test，先把压缩包解压进去，不要直接覆盖旧程序。
  3. 将配置文件放在同一测试目录，文件名保持为 config.yaml 或按你的启动方式指定路径。Mihomo 使用 YAML 配置格式，缩进必须使用空格，不能使用 Tab。
  4. 在该目录打开 PowerShell，运行程序。若程序立即退出，先查看控制台错误，不要直接删除配置。

Linux

  1. 下载 Linux 对应架构的压缩文件并解压。
  2. 赋予程序执行权限：
    chmod +x mihomo
  3. 在测试目录运行配置检查：
    ./mihomo -t -f config.yaml
  4. 预期结果是配置检查通过；如果失败，先根据报错修正 YAML、字段名或引用的代理组，再重复检查。通过检查不等于节点或网页一定可用，它只说明配置能够被内核解析。

macOS

  1. 根据芯片选择 darwin-arm64 或 darwin-amd64 文件；如果系统较旧，查看文档中的 go 兼容标签。
  2. 将程序解压到独立目录，并在终端执行 chmod +x mihomo。
  3. 先运行 ./mihomo -t -f config.yaml 检查配置，再启动内核。
  4. 如果系统提示无法验证开发者或阻止执行，先确认文件确实来自目标 Release 页面，再根据 macOS 的安全设置处理；不要为了启动未知文件而长期关闭系统安全功能。

Linux 文档还提供 systemd 服务方式：把二进制放入 /usr/local/bin/、把配置放入 /etc/mihomo，再通过 systemd 启动。首次安装建议先用测试目录验证，确认配置可解析后再迁移到系统服务目录，并保留原配置备份。

如果你使用图形客户端，Mihomo 内核通常由客户端管理。此时不要同时启动两个内核或让两个程序抢占相同代理端口；先确认客户端实际使用的内核版本、配置目录和端口。

Mihomo、metacubexd 与图形客户端有什么区别

Mihomo 内核负责解析配置、建立连接、处理 DNS、规则、代理组和 TUN 等功能；GitHub Release 中的二进制文件属于这一层。

metacubexd是用于查看流量、代理组、连接和规则的 Web Dashboard。它不是内核本身，必须连接 Mihomo 的 external-controller。官方 Dashboard 仓库说明，配置编辑或切换前可以使用 mihomo -t 做校验，校验通过后再重启内核。

图形客户端则可能把内核、配置管理、系统代理和托盘操作打包在一起。使用图形客户端时，通常不需要手动下载独立内核；如果客户端自带版本较旧或需要切换版本，应先查看客户端自己的内核管理入口，避免手动替换导致路径或权限不匹配。

控制器、secret 和 CORS 的安全检查

首次配置 Dashboard 时，重点不是“能否打开网页”，而是控制器是否只对必要范围开放。external-controller、代理端口和 TUN 配置属于不同层次，不要因为网页面板打不开就直接把所有监听地址改成公网地址。

  • 不需要局域网访问时，优先绑定本机回环地址，避免把控制器暴露给同一网络中的其他设备。
  • 如果必须允许局域网访问，限制监听地址和允许网段，并设置 secret；不要把包含控制器地址和密钥的配置文件公开上传。
  • 不要把控制器端口直接暴露到公网。远程管理应先配置访问控制、加密传输和防火墙规则。
  • CORS 只放行确实需要使用的面板来源，不要为了“解决跨域”而设置过宽的来源。
  • 配置修改前复制一份备份；如果修改后面板或代理异常，恢复备份并重新执行配置检查。

官方配置文档说明，allow-lan会影响其他设备是否能够通过代理端口访问网络；这不等于控制器应该对公网开放。面板仓库也强调要保护 external controller，因此连接成功后仍应检查监听地址、secret 和防火墙。

下载后打不开或连不上：按最小闭环排查

  1. 先看程序层：运行版本查询或直接启动，确认文件没有因架构不匹配而立即退出。
  2. 再看配置层：执行 mihomo -t -f config.yaml。如果报 YAML 缩进、字段或引用错误，先修配置，不要先改 DNS 或 MTU。
  3. 再看监听层：确认代理端口、控制器端口没有被其他程序占用。
  4. 再看连接层：检查日志中是 DNS 解析失败、代理握手失败、规则走了 DIRECT，还是目标网页自身不可达。
  5. 最后才做回滚：恢复最近一次可用配置，关闭刚新增的规则、TUN 或 DNS 改动，逐项重新启用。

延迟有返回不等于网页可用。排查时应分别记录 DNS 是否解析、代理是否建立、网页是否加载、日志是否持续报错，避免只凭一次 ping 或单个节点结果判断整体连接状态。

常见问题

mihomo GitHub 的下载入口是哪一个？

优先从 <a href="https://github.com/MetaCubeX/mihomo/releases">MetaCubeX/mihomo Releases 页面</a>查看版本和 Assets，再用 <a href="https://wiki.metacubex.one/en/startup/">安装文档</a>确认系统与架构。不要仅凭搜索结果中的第三方镜像下载。

2026-11-05 Mihomo 最新版本是多少？

本文检索时，Release 列表显示 v1.19.33，并另有 Prerelease-Alpha。版本会继续变化，实际下载前应重新打开 Release 页面核对，不能把本文日期的版本号当成永久最新。

Windows 应该下载 amd64、arm64 还是 386？

普通 64 位 Intel 或 AMD Windows 电脑通常查看 amd64/x86_64；ARM Windows 设备才考虑 arm64；32 位系统才考虑 386。以系统“关于”页面显示的系统类型为准。

Alpha 版本和普通 Release 怎么选？

普通使用优先选择非 Pre-release 的稳定 Release；Alpha 属于测试通道，适合需要验证新功能并能自行备份、回滚的用户。官方 FAQ 还说明 alpha 分支与 meta 分支的更新关系，不能简单把分支名称当成稳定性保证。

下载后运行报错，应该先改 DNS 或 MTU 吗？

不建议。先确认系统和架构匹配，再执行 <code>mihomo -t -f config.yaml</code> 检查配置，随后查看端口占用和启动日志。只有确认程序与配置层正常后，才进一步排查 DNS、规则、TUN 或 MTU。

metacubexd 是 Mihomo 内核吗？

不是。Mihomo 是负责运行配置和网络连接的内核；metacubexd 是用于管理和查看运行状态的 Dashboard，需要连接 external-controller。

相关阅读

参考资料

  1. MetaCubeX/mihomo GitHub Releases
  2. MetaCubeX/mihomo GitHub 仓库
  3. mihomo 官方文档：安装与预编译文件
  4. mihomo 官方 FAQ：版本分支与文件名说明
  5. metacubexd GitHub 仓库
  6. metacubexd README：配置校验与控制器安全
  7. mihomo 文档：YAML 配置语法
  8. mihomo 文档：Linux systemd 服务
  9. wiki.metacubex.one