Mihomo Linux 安装教程：从架构选择到代理测试与 systemd 自启动

更新于 2026-10-31 · mistybeta.site

简答：Linux 安装 Mihomo 的最短路径是：先用 uname -m 判断架构，再从官方 Releases 页面选择当前稳定构建，安装到 /usr/local/bin，使用 /etc/mihomo/config.yaml 做配置校验，最后用 systemd 启动并通过 curl 测试代理。本文重点解决“文件怎么选、服务是否启动、代理到底通不通”这三个问题，不固定旧版本下载地址，也不把进程运行误判为上游代理可用。

定义：Mihomo 是兼容 Clash 配置体系的代理内核；Linux 部署通常指运行预编译二进制、加载 YAML 配置，并通过 HTTP、SOCKS 或 mixed 端口为应用提供代理入口。

先看速查：5 步跑通 Linux 基础部署

如果你只想先把 Mihomo 内核和普通代理端口跑起来，按下面顺序操作。本文为第三方使用指南，不代表 Mihomo 官方。

确认架构：执行 uname -m，记录输出。
选择文件：打开官方 Releases 页面，选择当前稳定发布中的 Linux 构建；不要盲目复制旧教程中的固定版本 URL。
安装并校验：解压后执行 file mihomo，再用 sudo install -m 0755 mihomo /usr/local/bin/mihomo 安装。
测试配置：将配置保存为 /etc/mihomo/config.yaml，执行 sudo /usr/local/bin/mihomo -t -d /etc/mihomo。
启动并测试：用 systemd 启动后，先检查端口，再用 curl 发送 HTTP 或 SOCKS5 请求。

停止条件：架构与文件不匹配、出现 Exec format error、出现 illegal instruction、配置测试失败，或服务启动后立即退出时，不要继续启用 TUN，也不要同时修改 DNS、路由和端口。

架构与文件名速查

uname -m 结果	通常对应的发布文件	选择提示
`x86_64`	`linux-amd64`	常见 Intel、AMD 64 位服务器
`aarch64`	`linux-arm64`	常见 64 位 ARM 服务器、开发板和部分 NAS
`armv7l`	`linux-armv7`	32 位 ARM 系统
`i686` 或 `i386`	`linux-386`	32 位 x86 系统

官方安装索引会根据系统、架构和构建类型列出预编译文件，具体文件名随发布内容变化，应以当前页面为准。可查看mihomo 官方安装索引。

1. 判断架构并从官方页面选择文件

先执行：

uname -m

如果还需要确认内核版本，可执行：

uname -r

AMD64 文件名中可能出现 v1、v2、v3、compatible 或 Go 版本标记。对于来源不明、较老或经过虚拟化的 x86_64 设备，优先选择兼容性更高的构建；如果启动时报 illegal instruction，先更换构建，不要先修改 YAML。

官方安装页面当前会动态展示稳定发布和测试发布的文件列表。本文不把某个版本号写死，因为发布版本、文件名和页面标记会变化；截至 2026-10-31，下载时仍应以页面当前显示内容为准。

选择文件后的验证边界如下：

架构验证：uname -m 与 file mihomo 显示的目标架构应相互匹配。
可执行验证：/usr/local/bin/mihomo -v 能运行，只能说明二进制可以启动。
配置验证：mihomo -t 通过，才说明配置结构能够被读取。
链路验证：curl 通过实际代理端口发送请求，才可以进一步判断上游代理是否响应。

文件名和架构含义可参考mihomo 官方 FAQ；若 FAQ 页面与当前发布文件列表不一致，应以当前 Releases 页面中的文件为准。

2. 下载、校验、解压和安装二进制

官方页面的版本和文件名会变化，因此不要把旧文章中的完整下载地址直接复制到生产环境。更稳妥的流程是：在 Releases 页面点击或复制当前文件地址，再在 Linux 终端执行下面的通用命令。

下载到当前目录后，可以执行：

curl -fL -o mihomo-linux-build.gz '把官方 Releases 页面复制的当前文件地址粘贴到这里'

如果系统没有 curl，也可以使用：

wget -O mihomo-linux-build.gz '把官方 Releases 页面复制的当前文件地址粘贴到这里'

检查下载结果：

ls -lh mihomo-linux-build.gz

file mihomo-linux-build.gz

官方 Linux 压缩包通常需要先解压。对于 gzip 文件，可执行：

gzip -dc mihomo-linux-build.gz > mihomo

然后检查二进制：

file mihomo

chmod 0755 mihomo

sudo install -m 0755 mihomo /usr/local/bin/mihomo

/usr/local/bin/mihomo -v

如果 Releases 页面同时提供校验值，应使用页面显示的校验方法核对下载文件；不要把旧版本的 SHA256 值套用到新文件。若 file 显示架构不匹配，停止安装并重新选择文件。若出现 Exec format error，优先检查文件架构；若出现 illegal instruction，优先检查 AMD64 指令集构建。

官方 systemd 文档也采用将二进制重命名为 mihomo 并放入 /usr/local/bin/ 的部署路径，详见mihomo 官方 systemd 服务文档。

3. 创建配置：先区分“端口启动”与“代理链路可用”

先创建配置目录：

sudo install -d -m 0755 /etc/mihomo

sudo nano /etc/mihomo/config.yaml

如果你只是验证内核、端口和 systemd，可以先使用下面的本地监听配置：

mixed-port: 7890

allow-lan: false

mode: rule

log-level: info

external-controller: 127.0.0.1:9090

这份配置的作用是启动本地 mixed 端口，并把控制接口绑定到本机。它不包含任何上游代理节点，因此只能验证内核是否能读取配置和监听端口，不能证明代理链路可用。

要进行真正的代理请求测试，配置必须包含你自行核验来源的节点，或者包含代理提供方给出的配置、代理集合或订阅内容。Mihomo 官方文档将代理节点写在 proxies 数组中，并通过代理组引用节点。例如结构可以写成：

proxies: - name: "example-node" type: "协议类型" server: "服务器地址" port: 443 uuid: "替换为实际参数"

上面的结构只是脱敏示意，不能直接运行；不同协议需要不同字段，不能把示例中的协议类型、服务器地址或认证字段当成真实节点。代理组需要引用已定义的节点，例如：

proxy-groups: - name: "Proxy" type: select proxies: - "example-node" - DIRECT

官方文档说明，代理组的 proxies 字段用于引用代理节点或其他代理组，可参考代理节点配置文档和代理组配置文档。

保存后先测试：

sudo /usr/local/bin/mihomo -t -d /etc/mihomo

只有测试通过后，才进入 systemd。配置测试通过仍不等于上游节点可用，后面还必须用 curl 发出实际请求。

4. 用 systemd 启动，并用 curl 完成代理测试闭环

创建服务文件：

sudo nano /etc/systemd/system/mihomo.service

普通 HTTP、SOCKS 或 mixed 端口部署可以先使用较小权限的基础单元：

[Unit] Description=mihomo service After=network.target [Service] Type=simple ExecStart=/usr/local/bin/mihomo -d /etc/mihomo ExecReload=/bin/kill -HUP $MAINPID Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target

执行：

sudo systemctl daemon-reload

sudo systemctl enable --now mihomo

sudo systemctl status mihomo --no-pager

sudo journalctl -u mihomo -o cat -e

这里显式加入了 ExecReload，因此可以在配置已经通过测试后使用：

sudo systemctl reload mihomo

如果你使用的服务文件没有 ExecReload，不要直接假设 reload 可用，应改用：

sudo systemctl restart mihomo

官方 systemd 示例包含 ExecReload=/bin/kill -HUP $MAINPID，并给出了 systemctl 与 journalctl 的管理方式，具体以官方 systemd 文档为准。

先检查端口，再测试 HTTP 代理

检查监听状态：

sudo ss -lntp | grep 7890

看到监听结果，只能说明本地端口存在。若配置中已经有可用上游节点，可执行 HTTP 代理测试：

curl -I -x http://127.0.0.1:7890 https://example.com --max-time 15

如果希望让代理端解析目标域名，可执行：

curl -I --proxy http://127.0.0.1:7890 https://example.com --max-time 15

测试 SOCKS5 和 mixed 端口

mixed 端口可以按 SOCKS5 方式测试：

curl -I --socks5-hostname 127.0.0.1:7890 https://example.com --max-time 15

--socks5-hostname 会让代理端解析目标主机名；如果只想测试 SOCKS5 地址连接，也可以使用：

curl -I --socks5 127.0.0.1:7890 https://example.com --max-time 15

结果判断要分层：

端口无监听：先看 systemctl status 和日志，不要测试上游。
端口监听但 curl 连接被拒绝：检查端口号、监听地址和服务日志。
curl 能连接端口但返回超时：可能是上游节点、规则、DNS、出口网络或认证参数问题，应查看 Mihomo 日志。
curl 返回 HTTP 响应：只能证明这一次请求通过当前代理路径获得响应，不能推导长期速度、稳定性或所有网站都可用。
没有上游节点却请求成功：可能是规则选择了 DIRECT，这不能证明代理节点工作正常。

5. TUN、订阅和 Docker 为什么不放在首次安装里

首次部署建议先使用普通 mixed 端口，因为它的流量范围更容易观察：只有明确设置代理的应用会经过 Mihomo。TUN 则会改变系统路由、DNS 或透明转发范围，适合在基础端口和上游链路已经验证后再单独测试。

官方 TUN 文档列出了 auto-route、auto-redirect、DNS 劫持和严格路由等配置项。Linux 上启用这些选项后，路由和防火墙行为可能发生变化；如果你正通过 SSH 远程操作，建议先保留备用登录通道，并备份配置。具体字段以mihomo TUN 配置文档为准。

订阅导入也不应与首次内核安装混在一起。订阅地址、节点内容和可用性需要由读者自行核验；导入后仍要重新执行：

sudo /usr/local/bin/mihomo -t -d /etc/mihomo

Docker、GeoIP、GeoSite 和复杂 DNS 属于后续部署问题。当前页面只覆盖 Linux 二进制基础部署、配置校验、普通代理端口、curl 测试和 systemd 托管，避免把多个故障变量同时引入。

按现象排查：每次只改一个变量

常见现象与下一步命令

现象	先执行	判断边界
`Exec format error`	`uname -m` `file /usr/local/bin/mihomo`	优先检查架构是否匹配
`illegal instruction`	检查 Releases 中的 compatible、v1、v2、v3 或 Go 构建标记	可能是 CPU 指令集不兼容，先换构建
服务立即退出	`sudo journalctl -u mihomo -o cat -e`	区分配置错误、路径错误和权限错误
7890 未监听	`sudo systemctl status mihomo --no-pager`	先确认服务是否启动，不要先改节点
端口监听但 curl 超时	`sudo journalctl -u mihomo -o cat -f`	进一步检查上游、规则、DNS 和出口网络
改配置后未生效	`sudo mihomo -t -d /etc/mihomo` `sudo systemctl restart mihomo`	没有 ExecReload 时使用 restart

回滚顺序建议固定为：停止服务、恢复备份、运行配置测试、重新启动、查看日志、再次测试端口。备份命令如下：

sudo cp /etc/mihomo/config.yaml /etc/mihomo/config.yaml.bak

如果启用 TUN 后 SSH 中断，应优先通过备用控制台或备用登录方式停止服务并恢复配置，不要在失去连接后继续修改路由规则。

本文范围与核验边界

本文适合使用 Linux 服务器、软路由或 NAS 的读者，目标是完成 Mihomo 二进制基础部署，并确认“内核已运行、端口在监听、curl 请求是否真正经过代理”。

本文不提供固定旧版本下载直链，不声称某个版本在当前页面一定标记为 Latest，也不提供节点状态、价格、测速、可用率或具体订阅服务结论。版本和发布文件以官方 Releases 页面当前内容为准。

如果你只看到 active (running)，不要把它等同于代理可用；如果只看到端口监听，也不要把它等同于上游节点可用。至少完成配置测试、端口检查和一次带代理参数的 curl 请求，才能完成基础链路验证。

常见问题

Mihomo Linux 下载 amd64 还是 arm64？

先执行 uname -m。输出 x86_64 通常选择文件名中的 linux-amd64，输出 aarch64 通常选择 linux-arm64，输出 armv7l 通常选择 linux-armv7。最终以官方 Releases 页面当前文件名和 file 命令结果为准。

Mihomo 端口监听正常，为什么 curl 仍然超时？

端口监听只说明本地进程在接收连接。请先确认配置中存在可用上游节点或代理集合，再查看 journalctl -u mihomo -o cat -f，并分别测试 HTTP 代理和 --socks5-hostname。也要确认规则没有把请求选成 DIRECT。

没有节点配置时，能不能测试 Mihomo 代理？

可以测试内核启动、配置解析和端口监听，但不能证明代理链路可用。没有上游节点时，curl 可能因规则选择 DIRECT 而成功，因此必须结合日志、代理组选择和实际上游配置判断。

为什么 systemctl reload mihomo 可能失败？

如果 systemd 服务文件没有配置 ExecReload，reload 可能返回未实现或失败。本文模板加入了 ExecReload=/bin/kill -HUP $MAINPID；如果你使用其他服务文件，配置变更前先运行 mihomo -t，之后优先使用 systemctl restart mihomo。

Linux 上安装 Mihomo 要不要马上开启 TUN？

不建议。先用普通 mixed 端口完成配置校验、systemd 启动和 curl 测试，再在有备用登录通道和配置备份的前提下单独测试 TUN。TUN 会影响路由、DNS 或透明转发范围，远程 SSH 场景尤其需要保留回滚路径。