CreamData返回首页

Mihomo Linux 安装后怎么运行？架构选择、配置与 systemd 自启

更新于 2026-10-24 · creamdata.buzz

简答：在 Linux 上安装 Mihomo，先用 uname -m 判断 CPU 架构，再从官方 Releases 选择对应构建；完成配置文件后，可用 systemd 后台运行，并通过 mihomo -v、systemctl 和本地 API 验证。

定义：Mihomo 是一个基于规则进行流量转发与代理管理的网络核心，Homebrew Formulae 将其说明为原 ClashMeta 名称项目。

先判断你的 Linux 应该下载哪个 Mihomo 文件

本文与 Mihomo 项目及其开发者无隶属关系。Mihomo Linux 安装最容易出错的地方不是解压，而是选错 CPU 架构或把测试构建当成稳定构建。官方文档的预编译入口同时列出了 Linux、amd64/x86_64、386/x86_32、arm64/armv8 和 armv7 等选项；截至 2026-10-24，官方 Releases 页面将 v1.19.33 标记为 Latest，下载前仍应以发布页当前显示的稳定构建为准。

先执行下面的命令，目的只是读取当前内核报告的机器架构：

uname -m

判定标准：输出 x86_64，通常选择官方文件名中的 amd64；输出 aarch64，通常选择 arm64；输出 armv7l，选择 armv7；输出 i386、i686，选择 386。这是常见名称对应关系，若输出其他值，不要猜测，应回到mihomo 官方安装文档的构建选择器核对。

uname -m 常见输出应优先查找的构建后缀适合的安装方式自查结果
x86_64amd64压缩二进制、DEB、RPM、Arch 包文件名同时包含 Linux 和 amd64
aarch64arm64压缩二进制、DEB、RPM、Arch 包文件名同时包含 Linux 和 arm64
armv7larmv7压缩二进制或对应发行版包文件名包含 armv7，不要选 arm64
i386 或 i686386压缩二进制、DEB、RPM文件名包含 386，不要选 amd64

如果你不确定系统是否支持某个二进制，还可以补充执行：

getconf LONG_BIT

目的：查看用户空间位数。它只能作为辅助判断，不能替代 uname -m 和官方文件名核对。若架构和文件名不一致，常见结果是无法执行、启动后立即退出，或出现动态库兼容问题。

官方安装页还列出了压缩二进制、Debian/DEB、Red Hat/RPM 和 Arch Linux/PKG 等格式；不要把不同格式混装到同一套服务目录中。来源：mihomo 官方安装文档：预编译构建与架构列表；当前稳定版本应以MetaCubeX/mihomo 官方 Releases为准。

三种安装路径怎么选：二进制、发行版包还是 Docker

普通 Ubuntu、Debian、VPS：优先使用官方压缩二进制或 DEB 包。压缩二进制更容易统一目录和 systemd 服务，DEB 则适合希望由 Debian 系包管理器记录安装文件的情况。

RPM 系发行版：从官方构建列表选择 RPM 包，再交给系统包工具安装。文件后缀、CPU 架构和发行版类型必须同时匹配，不能因为系统是 64 位就直接选择任意 amd64 文件。

Arch Linux：可以选择官方构建列表中的 PKG 格式。若系统已有包管理流程，优先让包管理器处理文件；若只是临时测试，压缩二进制更容易回滚。

Homebrew：Homebrew Formulae 明确提供 brew install mihomo，并列出 Linux ARM64 与 x86_64 的二进制支持，同时给出 brew services start mihomo 的服务启动方式。适合已经使用 Homebrew 管理命令行工具的用户，不适合想把服务固定放在标准 /etc/mihomo 路径的极简服务器。

brew install mihomo
brew services start mihomo
mihomo -v

判定标准：安装命令无错误，mihomo -v 能输出版本信息，且 brew services list 中服务状态不是 stopped 或 error。Homebrew 的配置目录和直接运行方式以其公式页当前说明为准，参考Homebrew Formulae：mihomo。

Docker：容器适合已经使用 Docker Compose 管理服务、熟悉端口映射和持久化目录的用户。需要注意，本文没有把任意第三方 Mihomo 镜像视为官方安装包；MetaCubeX 公开的 metacubexd 项目提供包含面板、控制代理和 Mihomo 内核的 all-in-one Docker 方案，但它是面向面板和容器服务的组合部署，不等同于裸机二进制安装。使用容器时，至少要明确映射配置目录、代理端口和控制端口，并为控制接口设置密钥。相关部署说明可查看MetaCubeX/metacubexd 官方仓库。

官方二进制安装：从下载到第一次启动

下面以手动安装为例。下载地址中的版本号和文件名必须替换成你在官方 Releases 页面实际看到的稳定构建，不要直接照抄旧版本。

  1. 创建工作目录：
    sudo install -d -m 0755 /etc/mihomo
mkdir -p "$HOME/mihomo-download"
cd "$HOME/mihomo-download"
    目的：把配置放到固定目录，同时把下载文件与系统目录分开。
  2. 下载对应构建：
    # 示例：把下面的 URL 替换为官方 Releases 中与你的架构匹配的实际下载地址
curl -fL -o mihomo.gz '替换为官方 Releases 中的 Linux 构建地址'
    如果系统没有 curl，先安装发行版提供的 curl 包。判定标准：命令返回成功，文件大小不是 0 字节；可以执行 ls -lh mihomo.gz 检查。
  3. 解压并检查文件类型：
    gzip -dc mihomo.gz > mihomo
file mihomo
    目的：把压缩文件还原为可执行文件。判定标准：file 的输出应与系统架构相符；若显示其他架构或只是文本文件，立即停止，不要继续安装。
  4. 安装到系统路径：
    chmod 0755 mihomo
sudo install -m 0755 mihomo /usr/local/bin/mihomo
/usr/local/bin/mihomo -v
    判定标准：版本命令能执行并输出版本字符串。若报 Exec format error，优先重新检查 uname -m 和下载文件名；若报找不到动态库，先保留错误输出，不要随意下载来源不明的库。

官方 systemd 文档采用将二进制放入 /usr/local/bin/、配置放入 /etc/mihomo 的目录结构，并通过 -d /etc/mihomo 指定工作目录。可对照mihomo 官方文档：使用 systemd 创建运行服务。

创建最小 config.yaml：先验证服务，再接入真实节点

首次启动不建议直接粘贴一份来源不明的大型配置。先创建一个只用于验证进程、端口和 API 的最小配置；它不会凭空提供可用节点，也不会替你生成订阅内容。

sudo tee /etc/mihomo/config.yaml > /dev/null <<'EOF'
 mixed-port: 7890
 allow-lan: false
 mode: rule
 log-level: info
 ipv6: false
 external-controller: 127.0.0.1:9090
 secret: "请替换为本机 API 密钥"
 proxies: []
 rules:
   - MATCH,DIRECT
EOF

上面的配置中，mixed-port 用于同时接收常见 HTTP 和 SOCKS 流量；allow-lan: false 先限制为本机访问；external-controller 绑定回环地址，避免控制接口直接监听所有网卡；secret 应替换成自己的随机密钥。官方配置文档说明了 allow-lan、mode、external-controller 和 secret 的字段作用，参考mihomo 官方文档：通用配置。

检查配置文件是否存在并确认权限：

sudo ls -l /etc/mihomo/config.yaml
sudo sed -n '1,80p' /etc/mihomo/config.yaml

判定标准：文件存在、内容缩进清楚、密钥没有保留示例文字。YAML 对缩进敏感，不能把 Tab 混入空格。若你已经有合法来源的 Clash/Mihomo 配置或订阅，应先备份原文件，再逐步合并，不要在排查阶段同时修改端口、DNS、规则和节点协议。

用 systemd 后台运行并设置开机自启

创建服务文件：

sudo tee /etc/systemd/system/mihomo.service > /dev/null <<'EOF'
[Unit]
Description=mihomo service
After=network.target NetworkManager.service systemd-networkd.service

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3
LimitNOFILE=1000000

[Install]
WantedBy=multi-user.target
EOF

这份服务文件保留了官方文档中的核心启动方式：使用 ExecStart=/usr/local/bin/mihomo -d /etc/mihomo 指定程序和配置目录；Restart=on-failure 是本文为排查方便采用的较保守重启策略。如果你需要 TUN、透明代理或特定系统权限，不要直接照搬高权限配置，应先根据实际功能查看官方文档并单独评估。

依次执行以下命令：

sudo systemctl daemon-reload
sudo systemctl enable mihomo
sudo systemctl start mihomo
sudo systemctl status mihomo --no-pager
sudo journalctl -u mihomo -o cat -e

判定标准：systemctl status 显示 active (running)；日志中没有 YAML 解析失败、端口绑定失败或权限错误。若服务反复重启，先看日志最后 30 行：

sudo journalctl -u mihomo -n 30 --no-pager

修改配置后，不要重复创建服务文件，先检查语法和日志，再执行：

sudo systemctl restart mihomo
sudo systemctl status mihomo --no-pager

官方文档还给出了 systemctl reload mihomo、journalctl -u mihomo -o cat -e 和持续跟踪日志的方式，可对照mihomo systemd 服务文档。

安装后怎么验证：版本、端口、代理和 API 分开检查

不要只看到进程存在就判断代理已经生效。建议按四层检查，哪一层失败就只处理哪一层。

  1. 检查版本：
    /usr/local/bin/mihomo -v
    正常标准：输出版本信息并返回 0。
  2. 检查服务：
    systemctl is-active mihomo
systemctl is-enabled mihomo
    正常标准：第一条输出 active，第二条输出 enabled。如果只是手动启动而未自启，第二条可能不是 enabled。
  3. 检查监听端口：
    ss -lntp | grep -E ':(7890|9090)\b'
    目的：确认混合代理端口和 API 端口是否被 Mihomo 监听。正常标准：能看到对应端口；如果提示端口被占用，执行 sudo ss -lntp 找出占用进程，再决定是否修改配置。
  4. 检查 API：
    curl -sS -H 'Authorization: Bearer 请替换为你的 API 密钥' http://127.0.0.1:9090/version
    目的：请求 Mihomo 的版本 API。正常标准：返回 JSON，并包含版本信息。官方 API 文档列出了 /version 接口及返回字段，可参考mihomo 官方 API 文档。
  5. 检查代理端口：
    curl -I --proxy http://127.0.0.1:7890 https://example.com
    这里的 example.com 只是示例域名，请替换为你有权访问且能稳定解析的测试地址。由于最小配置使用的是 MATCH,DIRECT，这一步只能验证端口转发路径，不代表已经通过某个远端节点连接。若要验证真实代理，必须先导入合法、可用且格式兼容的节点配置，再比较直连和代理结果。

如果 API 能访问但浏览器不能使用，优先检查浏览器是否填写了 HTTP 代理 127.0.0.1:7890，以及应用是否只支持 SOCKS5。若 7890 未监听，回到 systemd 日志；若 7890 已监听但请求失败，检查配置规则、节点配置和 DNS，不要先盲目更换 MTU 或关闭系统防火墙。

常见故障排查：按错误现象定位

现象先执行什么判定与处理
Exec format erroruname -m、file /usr/local/bin/mihomo两者架构不一致，重新选择 amd64、arm64、armv7 或 386 构建。
服务启动后立即退出journalctl -u mihomo -n 50 --no-pager重点看 YAML 行号、配置路径和端口错误；不要只重复执行 start。
端口已被占用sudo ss -lntp找出占用 7890 或 9090 的进程，停止冲突服务或修改对应字段。
API 返回 401检查 Authorization 请求头和 secret密钥不一致时会认证失败；不要为了省事把 API 绑定到公网。
服务器能运行，局域网设备不能连接检查 allow-lan、bind-address 和防火墙本文默认只允许本机访问；开放局域网前应限制来源地址并保留 API 密钥。

官方文档说明，allow-lan: true 会允许其他设备通过代理端口访问网络，绑定地址为 * 时会监听所有 IP；因此服务部署在 VPS 或办公网络时，不应把控制接口和代理端口无条件暴露到公网。先保持 127.0.0.1，确认本机链路正常后再逐项开放。参考mihomo 通用配置中的 Allow LAN 与 External Control。

常见问题

Mihomo Linux 应该下载 amd64 还是 arm64？

先执行 uname -m。输出 x86_64 通常选择 amd64，输出 aarch64 通常选择 arm64；如果输出 armv7l 或其他值，应以 Mihomo 官方构建列表为准，不要仅凭“64 位”判断。

Mihomo Linux 安装后为什么 systemctl 显示启动失败？

先执行 journalctl -u mihomo -n 50 --no-pager，重点检查 config.yaml 缩进、配置路径、端口冲突和二进制架构。不要只重复 systemctl start，因为日志通常会给出更直接的错误位置。

最小 config.yaml 没有节点，能证明 Mihomo 可用吗？

可以证明程序、配置目录、监听端口和本地 API 是否正常，但不能证明远端节点或订阅可用。要验证真实代理，需要再导入格式兼容且来源合法的节点配置，并单独检查节点连接。

Mihomo 的 external-controller 可以直接改成 0.0.0.0 吗？

不建议作为默认设置。官方配置支持监听所有 IP，但公网或局域网暴露会扩大控制接口风险。优先使用 127.0.0.1，并设置 secret；确需远程管理时，再结合防火墙、来源限制和 HTTPS 做最小范围开放。

相关阅读

参考资料

  1. mihomo 官方安装文档：预编译二进制与架构选择
  2. MetaCubeX/mihomo 官方 Releases
  3. mihomo 官方文档：使用 systemd 创建运行服务
  4. mihomo 官方文档：通用配置、Allow LAN 与 External Control
  5. mihomo 官方 API 文档：版本接口与运行状态
  6. Homebrew Formulae：mihomo（formulae.brew.sh）
  7. MetaCubeX/metacubexd 官方仓库：Docker 部署说明