Bocchi

Mihomo 核心怎么更新？Linux 命令行替换、校验与回滚

更新于 2026-11-07 · bocchi.icu

简答：如果你在 Linux 上直接运行 Mihomo 或用 systemd 管理服务，最稳妥的方法是先读取真实的 ExecStart 路径，备份配置和旧核心，再从当前发布页下载匹配架构的文件。校验与官方摘要对应的压缩包后解压、替换并重启服务，最后用 -v、-t、systemctl status 和 journalctl 验证；图形客户端、Docker、Android 和路由器不应直接套用本页命令。

定义：Mihomo 核心更新，是在保留现有配置和运行目录的前提下，用匹配系统与 CPU 架构的新 Mihomo 可执行文件替换旧文件，并通过配置测试和服务状态检查确认它能够正常启动。

先判断：你是否适合使用这篇 Linux 更新流程

本文为第三方使用指南，不代表 Mihomo 或任何客户端官方。适用对象是 Linux 上直接运行 Mihomo，或由 systemd 管理的 Mihomo 服务。若 Mihomo 由图形客户端、容器、Android 应用、路由器固件或其他面板托管，核心文件的位置和更新入口可能不同，请按对应宿主的当前文档操作。

30 秒环境分流
你的运行方式是否直接照做先确认什么
Linux 命令行直接运行可以确认启动命令中的二进制路径和配置文件
Linux systemd 服务可以执行 systemctl cat 服务名 查看 ExecStart
图形客户端内置核心不要直接照做查看客户端自己的核心版本和更新入口
Docker、路由器或 Android不要直接照做确认核心由镜像、固件还是应用管理

Mihomo 当前启动文档提供了 Stable 与 Alpha 渠道，并按 Windows、Linux、macOS、FreeBSD、Android 以及 amd64、arm64 等架构筛选预编译文件。具体资产、版本和压缩格式会变化，应以Mihomo 当前启动文档和Mihomo Releases 发布页显示内容为准。

先试这一步：定位当前核心、服务名和配置目录

不要先假设核心一定安装在 /usr/local/bin/mihomo，配置也不一定在 /etc/mihomo。先用实际服务名检查；如果服务名不是 mihomo，把下面命令中的服务名替换为你的名称。

systemctl status mihomo --no-pager
systemctl cat mihomo

重点查看 ExecStart= 行。例如，官方 systemd 示例使用了类似 /usr/local/bin/mihomo -d /etc/mihomo 的启动方式，但这只是文档示例，不代表你的安装路径固定如此。Mihomo systemd 文档同时给出了服务文件、启动、状态和日志检查示例。

定位结果怎么读
项目查看位置用途
二进制路径ExecStart= 后面的可执行文件确认旧核心和新核心最终替换到哪里
配置目录-d 后面的目录备份整个运行目录并进行配置测试
配置文件-f 后面的文件测试单个配置文件
服务名称systemctl status 使用的名称停止、启动和读取日志

如果是命令行前台运行而不是 systemd，可直接执行当前二进制的版本命令，例如：

/实际核心路径 -v

如果你不知道当前二进制路径，可以先使用 command -v mihomo；但该命令只会查找 PATH 中的程序，不能替代读取 systemd 的 ExecStart。

Linux 更新 Mihomo 核心：安全替换的完整步骤

  1. 记录旧版本。根据上一步找到的实际路径执行 /实际核心路径 -v，并保存终端输出。版本命令 -v 和配置测试参数 -t 可在 Mihomo 源码的命令行参数定义中核对，参见Mihomo main.go。
  2. 停止 systemd 服务。如果由 systemd 管理，执行 sudo systemctl stop mihomo。如果只是前台运行，则在原终端按 Ctrl+C 停止；不要在旧进程仍占用文件或端口时直接覆盖。
  3. 备份配置和旧核心。把实际配置目录复制为带日期的备份，例如：
    sudo cp -a /实际配置目录 /实际配置目录.bak-$(date +%Y%m%d-%H%M%S)
sudo cp -a /实际核心路径 /实际核心路径.bak
    如果配置中包含订阅地址、密钥或其他凭据，备份文件应限制权限，不要上传到公开位置。
  4. 确认 Linux 系统和架构。执行：
    uname -s
uname -m
    常见的 x86_64 通常对应发布页中的 amd64，aarch64 通常对应 arm64；但兼容标签、内核版本和 CPU 指令集仍需结合发布页说明。Mihomo FAQ 说明，发布文件名通常包含程序名、操作系统、架构和编译兼容信息，下载前应按这些字段选择。详情见Mihomo 官方 FAQ。
  5. 从当前发布页选择文件。打开Mihomo Releases，先选择 Stable 或 Alpha，再选择 Linux 和匹配架构的资产。不要把文章中的旧版本号拼进下载地址，也不要使用搜索结果中的第三方镜像地址作为默认来源。
  6. 下载到临时目录。将发布页中实际复制的资产地址放入命令，不要修改文件名或版本号。例如压缩文件为 .gz 时：
    curl -fL '发布页中复制的实际资产地址' -o /tmp/mihomo-new.gz
    下载失败时，先检查返回状态和临时文件大小，不要把未完成文件放到生产路径。
  7. 校验与摘要对应的同一个文件。如果发布页显示的是 mihomo-linux-...gz 资产的 SHA-256，就对下载的压缩包执行：
    sha256sum /tmp/mihomo-new.gz
    将输出与发布页显示的摘要逐字比较。不要先解压再拿解压后的文件哈希去对比压缩包摘要；两者不是同一个文件。若摘要不一致，删除临时文件并重新下载。
  8. 解压并检查文件类型。校验通过后执行：
    gzip -dc /tmp/mihomo-new.gz > /tmp/mihomo-new
file /tmp/mihomo-new
chmod 755 /tmp/mihomo-new
    如果 file 显示的格式或架构与当前系统不符，停止后续操作，回到发布页重新选择资产。
  9. 先测试配置。如果 systemd 的 ExecStart 使用 -d，执行类似：
    /tmp/mihomo-new -t -d /实际配置目录
    如果使用 -f，执行类似：
    /tmp/mihomo-new -t -f /实际配置文件
    -t 只用于测试配置并退出；测试通过说明核心可以读取并检查配置，不等于节点、DNS、端口或外部网络一定正常。
  10. 用临时目标文件替换。先把新文件安装到目标目录中的临时名称，再移动到实际路径，示例为：
    sudo install -o root -g root -m 0755 /tmp/mihomo-new /实际核心路径.new
sudo mv /实际核心路径.new /实际核心路径
    这里的路径、属主和用户必须以你的服务文件为准；如果服务不是 root 运行，替换后要确认运行用户仍能执行该文件。
  11. 启动并读取状态。执行：
    sudo systemctl start mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -o cat -e
    官方 systemd 文档列出了 systemctl start、systemctl status 和 journalctl 的检查方式。若你修改了 service 文件本身，才需要先执行 sudo systemctl daemon-reload；仅替换 ExecStart 指向的二进制时，通常不需要重新加载服务文件。

更新后的验收：区分核心、配置和网络问题

更新后最小验证清单
验证目标命令或操作通过标准
核心版本/实际核心路径 -v输出来自新文件的版本信息
配置解析/实际核心路径 -t -d 配置目录配置测试成功并退出
服务状态systemctl status mihomo --no-pager服务保持运行，而非启动后立即退出
启动日志journalctl -u mihomo -o cat -e没有新的配置、权限、端口或架构错误
本地监听ss -lntup配置中的本地端口按预期监听
实际代理使用配置中的 HTTP 或 SOCKS 端口做一次已知目标测试能区分本地核心启动正常与节点、DNS、线路是否可用

“核心进程正常”与“实际网络连接正常”不是同一个结论。如果版本和服务状态都正常，但代理仍然超时，应先查看日志，再分别检查本地端口、DNS、节点和线路；不要因为更新后首次连接失败，就直接回退或修改全部配置。

如果日志出现配置字段不识别、配置解析失败或端口被占用，优先恢复更新前备份，确认问题是否由新核心引入。若配置测试通过但服务仍退出，则继续检查服务用户、工作目录、端口占用和日志中的具体错误。

回滚怎么做：恢复旧核心后还要检查什么

如果新核心无法启动，先停止服务，再恢复更新前保留的旧文件：

sudo systemctl stop mihomo
sudo cp -a /实际核心路径.bak /实际核心路径
sudo chmod 755 /实际核心路径
ls -l /实际核心路径
/实际核心路径 -v
sudo systemctl start mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -o cat -e

回滚后至少检查四项：第一，恢复的路径是否与 service 文件中的 ExecStart 完全一致；第二，文件是否仍具有执行权限；第三，属主和属组是否符合服务运行用户；第四，服务是否读取了原来的配置目录。如果实际路径是符号链接，不要只检查链接名称，还要用 readlink -f /实际核心路径 确认最终目标。

如果旧核心恢复后仍无法启动，问题可能不只来自核心版本，还可能是配置、权限、端口、工作目录或外部资源变化。此时以 systemctl status 和 journalctl 中的具体错误为准，不要默认关闭校验、扩大监听地址或改成 root 运行。

常见问题 FAQ

Mihomo 核心更新会删除配置或订阅吗？

直接替换二进制文件通常不会主动修改配置文件，但新版本可能改变字段支持或运行行为。因此更新前应备份实际配置目录、订阅地址和旧核心，更新后先执行 -t 配置测试，再启动服务。

Linux 上应该下载 amd64 还是 arm64？

先执行 uname -m，再对照当前发布页资产名称。x86_64 通常对应 amd64，aarch64 通常对应 arm64；如果发布页出现 compatible、v1、v2、v3 或 Go 兼容标签，还要结合 FAQ 和当前资产说明判断，不能只按设备品牌选择。

为什么校验 SHA-256 时结果对不上？

最常见原因是拿解压后的文件去对比压缩包摘要。发布页显示哪个资产的摘要，就对同一个文件计算哈希：如果摘要对应 .gz，先对 .gz 执行 sha256sum，确认一致后再解压。

更新后 systemd 启动失败怎么办？

先执行新核心的 -t 配置测试，再查看 journalctl -u mihomo -o cat -e。若提示架构错误，重新选择 Linux 和 CPU 架构匹配的资产；若提示权限错误，检查执行权限、属主和服务运行用户；若确认新核心不兼容，则按回滚步骤恢复旧文件。

Mihomo 核心和客户端版本是一回事吗？

不是。客户端通常负责界面、配置管理或服务编排，核心是实际读取配置并处理连接的可执行文件。客户端升级不一定同步升级核心，核心替换也不一定改变客户端界面；Linux 命令行部署应直接检查二进制的 -v 输出。

常见问题

Mihomo 核心更新会删除配置或订阅吗？

直接替换二进制文件通常不会主动修改配置文件，但新版本可能改变字段支持或运行行为。更新前应备份实际配置目录、订阅地址和旧核心，更新后先执行 <code>-t</code> 配置测试。

Linux 上应该下载 amd64 还是 arm64？

先执行 <code>uname -m</code>，再对照当前发布页资产名称。<code>x86_64</code> 通常对应 amd64，<code>aarch64</code> 通常对应 arm64；出现兼容标签时，以当前 FAQ 和资产说明为准。

为什么 SHA-256 校验结果对不上？

发布页显示哪个资产的摘要，就对同一个文件计算哈希。如果摘要对应 <code>.gz</code>，应先对下载的压缩包执行 <code>sha256sum</code>，确认一致后再解压。

更新后 systemd 启动失败怎么办？

先执行新核心的 <code>-t</code> 配置测试，再查看 <code>journalctl -u mihomo -o cat -e</code>。根据日志分别检查架构、权限、配置、端口和工作目录；确认新核心不兼容时再恢复旧文件。

相关阅读

参考资料

  1. Mihomo 官方启动文档：预编译文件、系统和架构选择
  2. MetaCubeX/mihomo 官方 Releases：当前发布资产与 SHA-256 摘要
  3. Mihomo 官方 systemd 文档：服务文件、启动、状态与日志
  4. Mihomo 官方 FAQ：发布文件名、系统架构和兼容标签
  5. Mihomo 源码：-v 版本参数、-t 配置测试参数及 -d、-f 参数