Linux 部署 mihomo 内核:桌面客户端与 systemd 命令行两种方式

先选运行方式：桌面管理或独立服务

日常在 Linux 桌面切换节点、导入订阅，优先使用图形客户端。需要在无桌面的主机上持续运行，或希望登录前就启动代理入口，再选择独立 mihomo 内核与 systemd。两种方式共用规则配置概念，但配置目录、更新入口与权限来源不同，不能把客户端的开机启动和系统服务当成同一个开关。

mihomo 是网络处理内核，也常被称为 Clash Meta 内核；图形客户端负责配置管理、界面与系统集成。安装内核不会自动添加托盘、修改 GNOME 代理设置，也不会让所有命令行程序自动走代理。本文先建立只监听本机 127.0.0.1:7890 的代理入口，再验证应用是否实际连接该端口。

Ubuntu、Debian、Arch 安装桌面客户端

确认架构与安装包类型

先执行下面两条命令。x86_64 通常对应 x64 或 amd64 包，aarch64 通常对应 arm64 包。Ubuntu、Debian 优先选择适配发行版的 DEB；Arch 不使用 DEB 或 RPM 直接安装。客户端能否运行还取决于系统库和桌面环境，不只取决于处理器架构。

uname -m
cat /etc/os-release

前往客户端下载页确认 Linux 包与维护状态，可比较 Clash Verge Rev、FlClash 等客户端的实际发行支持。本文不固定客户端版本号，安装后应在「关于」页记录客户端版本，并在日志或内核信息页记录内核版本，便于后续复现问题。

• Ubuntu / Debian：下载适配本机的 DEB 后，可将本地文件重命名为 client.deb，再运行 sudo apt install ./client.deb。这里的名称仅是本地重命名约定，不是发行包名称。
• Arch：选择维护者提供且适配 Arch 的安装方式。使用 AUR 时先阅读 PKGBUILD 和下载来源；AUR 包由社区维护，不等同于官方仓库包。不要为迁就安装包混用其他发行版的系统库。
• 便携包：若发行方提供 AppImage，赋予可执行权限后运行。遇到 FUSE 或图形库错误，按该发行包的说明补齐依赖，不要通过 root 启动图形界面来绕过错误。

导入配置后，先验证本地端口

1. 在客户端「配置」页导入兼容 mihomo 的 YAML 或订阅，并确认当前启用项。订阅地址通常含访问凭据，不要贴到公开日志。
2. 在「设置」中确认实际的 HTTP、SOCKS 或混合端口。本文示例统一使用混合端口 7890；客户端默认值可能不同，命令必须跟着实际设置改。
3. 先关闭 TUN，只开启需要测试的代理入口。查看日志，确认配置加载成功，再用下文的显式代理命令验证。
4. 需要桌面应用接入时，启用客户端的「系统代理」。GNOME 也可在「设置」→「网络」→「网络代理」→「手动」检查地址与端口；不同桌面环境的路径不同。

桌面客户端的「开机启动」通常依赖用户会话。若目标是无人登录也可运行，使用下面的 systemd 方案；不要同时保留桌面内核的自动启动。退出客户端前还应确认它已撤销系统代理，避免系统继续指向一个关闭的端口。

独立 mihomo：准备目录与最小配置

安装二进制，建立专用用户

从内核发行渠道取得匹配架构的 Linux 二进制，按包格式解压，并将解压得到的可执行文件命名为 mihomo。下面的命令从当前目录安装这个文件，不假设任何远程安装包名称。先确认版本能输出，再继续配置服务。

chmod +x ./mihomo
./mihomo -v
sudo install -m 0755 ./mihomo /usr/local/bin/mihomo

sudo useradd --system --user-group --no-create-home \
  --home-dir /var/lib/mihomo --shell /bin/false mihomo
sudo install -d -o root -g mihomo -m 0750 /etc/mihomo
sudo install -d -o mihomo -g mihomo -m 0750 /var/lib/mihomo

若专用用户已存在，不要重复创建，先用 id mihomo 核实身份与组。二进制由 root 管理，运行数据归服务用户所有；配置目录只允许 root 和 mihomo 组访问。订阅内容可能包含节点密码，这比把配置放进全员可读目录更合适。

先用直连配置验证服务，不把它当节点配置

执行 sudoedit /etc/mihomo/config.yaml，写入下面的配置。它只提供本地混合代理入口，所有请求仍然直连；用途是隔离安装、权限与监听问题。没有代理节点时，运行成功不代表获得了远程代理出口。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

tun:
  enable: false

rules:
  - MATCH,DIRECT

sudo chown root:mihomo /etc/mihomo/config.yaml
sudo chmod 0640 /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t \
  -d /var/lib/mihomo -f /etc/mihomo/config.yaml

-f 指定主配置，-d 指定数据目录，-t 进行配置测试。测试通过说明配置可以加载，不保证远端节点可连接。换成真实订阅配置后，还要检查策略组名称、规则引用与 provider 路径；相对运行数据路径应统一安排在可写的数据目录，不要指向桌面用户的私有目录。

用 systemd 托管：启动、日志与开机自启

执行 sudoedit /etc/systemd/system/mihomo.service，写入以下完整服务定义。该方案用于普通本地代理，不启用 TUN，不绑定 53 等低端口。工作目录与可写目录一致，配置文件保持只读。

[Unit]
Description=mihomo local proxy service
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
WorkingDirectory=/var/lib/mihomo
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5
UMask=0027
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict
ReadWritePaths=/var/lib/mihomo

[Install]
WantedBy=multi-user.target

network-online.target 的效果取决于系统是否启用对应的网络等待服务，不能把它理解为远程订阅必然可访问。首次启动如需下载规则或地理数据，应查看日志确认完成情况；对启动时不能联网的环境，可预先准备配置所需的数据。

sudo systemd-analyze verify /etc/systemd/system/mihomo.service
sudo systemctl daemon-reload
sudo systemctl enable --now mihomo.service
systemctl status mihomo.service --no-pager
sudo journalctl -u mihomo.service -b -n 80 --no-pager
ss -lntp 'sport = :7890'

• enable --now 同时建立开机启动关系并立即启动；仅执行 enable 不会立刻运行进程。
• 正常状态应为 active (running)，端口检查应出现本地 7890 的监听记录。普通用户执行 ss 时可能看不到其他用户的进程名称。
• 配置更新后先重复 -t 测试，再执行 sudo systemctl restart mihomo。仅修改 YAML 不需要 daemon-reload；修改服务文件才需要。
• 临时停用执行 sudo systemctl stop mihomo；同时取消开机启动执行 sudo systemctl disable --now mihomo。

本文没有配置 ExecReload，所以不要用 systemctl reload 代替重启。若接入外部控制器来热加载配置，需另行设计认证与监听范围；基础服务不必为了管理面板而开放控制端口。

验证代理链路：端口、请求、规则分别检查

先显式指定代理，再检查环境变量

下面两条命令分别验证 HTTP 代理与 SOCKS5 代理。--noproxy "" 清空此次请求的绕过列表，避免已有 NO_PROXY 让测试直接跳过代理。SOCKS 示例使用 socks5h，让目标域名交由代理端解析。

curl --noproxy "" -I --connect-timeout 10 --max-time 20 \
  -x http://127.0.0.1:7890 https://example.org/

curl --noproxy "" -I --connect-timeout 10 --max-time 20 \
  --proxy socks5h://127.0.0.1:7890 https://example.org/

收到 HTTP 响应说明这次请求完成，仍需结合内核日志确认命中规则。最小配置会显示直连；启用真实节点后，才检查是否命中预期策略组、该组选择了哪个节点。延迟测试成功也不能代替一次实际 HTTPS 请求。

如果显式代理成功，而普通终端命令不走代理，可以在当前 shell 临时设置环境变量。不同程序支持的变量名称不同；以下写法适合常见命令行工具，不会全局接管所有程序。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5h://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

curl -I --connect-timeout 10 --max-time 20 https://example.org/

unset http_proxy https_proxy all_proxy no_proxy

https_proxy 的值使用 http:// 并不矛盾：这里表示通过 HTTP 代理的 CONNECT 隧道访问 HTTPS 目标。若写进 shell 配置文件，关闭服务后也要撤销；浏览器、APT 与 systemd 启动的其他服务不一定继承这些变量，应分别按应用配置。

常见失败按错误类型定位

• Connection refused：先看 7890 是否监听，核对端口和服务状态；此时不应先换节点。
• address already in use：检查桌面客户端或旧内核进程是否占用端口，只保留一个入口。
• permission denied：核实文件及父目录权限，用服务用户执行配置测试；避免用 chmod 777 掩盖原因。
• 规则或数据下载失败：检查 provider 地址、数据目录可写性与启动时网络。先保留完整错误上下文，再判断是否为 DNS 问题。
• 服务反复重启：用 journalctl 找到最早的配置或资源错误。修复后如触发启动限流，可执行 sudo systemctl reset-failed mihomo 再启动。

TUN 与更新维护：保持权限边界

TUN 不只是把 enable 改成 true

TUN 需要访问 /dev/net/tun，并通常涉及创建接口、调整路由与 DNS 接管所需的网络管理权限。检查 ls -l /dev/net/tun 只能确认设备节点存在，不能证明当前服务已获得所需授权。本文的普通用户服务刻意不配置这些权限，因此不能直接用于 TUN。

需要 TUN 时，先选择客户端提供的授权服务，或根据当前 mihomo 版本的说明重新设计 systemd 权限与能力限制。不要只把服务用户改成 root 后照搬全部设置。应先关闭另一套接管，明确 DNS 监听端口、路由范围以及是否接管局域网流量，再验证内网访问和关停后的路由恢复。

更新前记录版本，更新后重复验证

1. 记录 /usr/local/bin/mihomo -v 输出，并备份当前二进制与配置。备份配置同样保留受限权限。
2. 下载匹配架构的新内核，先执行新文件的 -v 和 -t；测试时仍使用服务用户与同一数据目录。
3. 停止服务后用 install -m 0755 替换二进制，再启动服务。不要尝试直接覆盖正在执行的文件。
4. 复查日志、7890 监听与 HTTPS 请求。若新版本出现兼容问题，停止服务，恢复旧二进制和配置后重新启动。

最终验收分成三个结论：systemd 能稳定托管进程，本地应用能进入代理端口，实际请求能命中正确规则与节点。三个结论分别成立，才算完成部署。更多基础配置可继续查看使用指南；遇到浏览器与终端结果不一致，可按故障排查逐项确认应用的代理来源。