Linux 部署 mihomo 内核：命令行运行、systemd 守护与桌面客户端配置

部署路线：后台服务还是桌面客户端

mihomo 是由 Clash Meta 演进而来的代理内核，负责读取配置、建立代理连接并执行分流规则。内核本身不提供桌面窗口，也不会因为启动了进程就自动让所有 Linux 应用走代理。应用需要使用本地代理端口，或由经过配置的 TUN 接管流量。

服务器、无图形界面的设备，以及需要开机持续运行的机器，适合二进制加 systemd。日常桌面使用、经常切换节点或更新订阅，则可以选 Clash Verge Rev、FlClashs 等带图形界面的客户端。两条路线可以分别测试，但不要让两个内核同时监听相同端口。

准备二进制：架构、权限与工作目录

确认系统架构和初始化系统

uname -m
ps -p 1 -o comm=
systemctl --version

x86_64 通常对应 amd64 构建，aarch64 对应 arm64。ARM 32 位还需要核对构建要求，不能仅凭设备品牌选择文件。第二条命令应显示 systemd；容器、WSL 环境或其他初始化系统可能需要不同的启动方案。

从可信的项目发布渠道取得对应架构的 mihomo 二进制，解压后将文件命名为 mihomo，放在当前目录。压缩包本身不能直接执行。若出现 Exec format error，先检查架构和文件是否已解压，而不是反复添加执行权限。

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

-v 用于记录实际内核版本。之后排查配置字段是否受支持，应以这条输出为依据，而不是以桌面客户端的版本号代替内核版本。

将程序、配置和运行数据分开

这里固定三处位置：程序放在 /usr/local/bin/mihomo，配置放在 /etc/mihomo/config.yaml，运行数据放在 /var/lib/mihomo。内核下载规则集、数据库或保存缓存时需要可写的数据目录；配置文件则可以保持只读。

sudo useradd --system --home-dir /var/lib/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -m 0750 -o root -g mihomo /etc/mihomo
sudo install -d -m 0750 -o mihomo -g mihomo /var/lib/mihomo

若专用用户已经存在，跳过 useradd，用 id mihomo 确认即可。某些发行版的 nologin 路径不同，可以先用 command -v nologin 查看。不要为了处理目录权限，把整个配置目录改为所有人可写。

配置文件：先验证本地端口，再接入订阅

用最小配置验证运行环境

先在当前目录创建 config.yaml，内容如下。这个配置只有直连规则，用来确认程序、端口和权限是否正常；它没有代理节点，也不能代替服务商提供的完整配置。

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

rules:
  - MATCH,DIRECT

mixed-port: 7890 在同一个 TCP 端口接受 HTTP 代理与 SOCKS5 请求。allow-lan: false 配合回环地址限制，适合只供本机使用的部署。没有配置 external-controller，因此本例不开放控制接口。

sudo install -m 0640 -o root -g mihomo ./config.yaml /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t -d /var/lib/mihomo -f /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml

-t 检查配置是否能被加载；-d 明确运行数据目录；-f 明确配置路径。前台运行时观察错误输出，在另一个终端检查端口：

ss -lntp 'sport = :7890'
curl -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

本例请求经过本地 mihomo 后直连目标。返回 HTTP 响应只能证明这条访问链路可用，不能证明已使用远程代理。验证结束后，在运行内核的终端按 Ctrl+C 停止前台进程，避免随后 systemd 启动时端口冲突。

替换为可用订阅配置

1. 取得服务商明确提供给 Clash 或 mihomo 的 YAML 配置。节点分享链接、网页订阅说明和其他客户端格式不能直接当作 YAML 使用。
2. 保留本地可用副本，将新文件安装到 /etc/mihomo/config.yaml，权限仍使用 0640，所有者为 root:mihomo。
3. 核对监听端口、proxy-groups、rules，以及规则所引用的策略名称是否一致。
4. 再次运行 -t，通过后再启动服务；远程规则集或数据库还需要检查网络访问和数据目录写入权限。

systemd 守护：开机启动、日志与配置更新

创建 /etc/systemd/system/mihomo.service，写入以下内容。本服务只提供普通本地代理，不包含 TUN 所需的权限设置。

[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

Restart=on-failure 会在进程异常退出后尝试重启，不能修复无效配置。ProtectSystem=strict 限制文件系统写入，仅给数据目录开放写权限；如果配置引用了其他路径，必须确认该用户能够读取，并且下载文件的目标位于允许写入的位置。

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager
sudo journalctl -u mihomo -b -n 80 --no-pager

enable --now 同时设置开机启动并立即运行。network-online.target 是启动顺序约束，是否真正等待网络取决于系统对应的 wait-online 服务，不能把它理解为互联网一定可用。订阅、规则集和节点连通性仍需单独验证。

修改配置后的操作顺序

sudo cp -p /etc/mihomo/config.yaml /etc/mihomo/config.yaml.bak
sudoedit /etc/mihomo/config.yaml
sudo -u mihomo /usr/local/bin/mihomo -t -d /var/lib/mihomo -f /etc/mihomo/config.yaml
sudo systemctl restart mihomo
sudo journalctl -u mihomo -n 40 --no-pager

只有配置检查成功才执行重启。修改 service 文件需要先 daemon-reload；仅修改 YAML 不需要。这里使用重启应用配置，没有定义 ExecReload，因此不要假设 systemctl reload mihomo 可以生效。重启会中断已有代理连接，下载任务和远程会话应提前安排。

Linux 环境变量代理：终端、Git 与 APT

内核开始监听后，终端程序仍需知道代理地址。下面的变量只影响当前 shell 及之后从该 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.com/

https_proxy 的值仍可以是 http://，表示通过 HTTP 代理的 CONNECT 隧道访问 HTTPS 目标，并不是把目标连接改成明文。socks5h 表示由 SOCKS 代理端处理目标域名解析；本地内核如何继续解析，取决于它的 DNS 配置。

• 不同程序支持的变量不同。curl 出于安全考虑不接受大写 HTTP_PROXY，优先使用上面的小写形式。
• 若希望每次打开交互终端都生效，可按所用 shell 将变量写入 ~/.bashrc 或 ~/.zshrc；服务停止后需同时停用这些变量。
• sudo 往往清理代理环境变量。systemd 服务也不会自动读取用户的 shell 启动文件，需要独立配置环境。
• 容器中的 127.0.0.1 指向容器自身，不是宿主机。不要通过开放整个局域网代理来草率解决容器连通性。

为特定命令显式指定代理

git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/MetaCubeX/mihomo.git HEAD

sudo apt \
  -o Acquire::http::Proxy="http://127.0.0.1:7890" \
  -o Acquire::https::Proxy="http://127.0.0.1:7890" \
  update

这些设置只作用于本次命令，适合验证，不会长期改变 Git 或 APT 的配置。清理当前 shell 的代理变量可使用：

unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

如果某个应用不读取代理环境变量，也没有自己的代理设置，那么普通 mixed-port 无法自动接管它。这才是考虑 TUN 的场景，而不是通过重复导出变量来解决。

桌面客户端配置：导入、系统代理与 TUN

使用图形桌面时，可从下载中心选择 Linux 客户端。Debian、Ubuntu 通常选择 DEB 包，Fedora 等 RPM 系发行版选择 RPM 包，同时核对处理器架构。以下命令中的文件是已下载并重命名的本地安装包：

# Debian / Ubuntu
sudo apt install ./client.deb

# Fedora
sudo dnf install ./client.rpm

客户端界面和菜单名称会随版本变化，操作时按“配置导入、代理选择、网络接管”三个功能区查找，不要将应用版本与内核版本混为一谈。

1. 导入配置：在配置或订阅页面添加订阅 URL，也可导入本地 YAML。确认下载成功并选中该配置，只有列表里出现一项不代表它已启用。
2. 选择策略：进入代理组页面，按规则引用的策略组选一个可用节点。使用规则模式时，不是所有请求都会走这个节点；命中 DIRECT 的请求仍直连。
3. 查看端口：在设置中的网络或端口区域确认混合端口。桌面客户端可能使用 7897 等其他端口，不能照抄本文的 7890。
4. 启用系统代理：它主要配置桌面环境提供的代理入口，覆盖范围取决于应用是否遵循系统设置。验证浏览器后，还要单独验证终端程序。
5. 按需启用 TUN：使用客户端提供的服务安装与授权流程，随后检查虚拟网卡、路由和 DNS；不要先把客户端永久作为 root 运行。

TUN 不是“速度增强”按钮。它通过虚拟网络设备接管符合条件的流量，涉及 /dev/net/tun、网络管理权限和路由设置。启用后若远程 SSH、局域网访问或容器网络异常，应先关闭 TUN 恢复连接，再检查路由排除与 DNS。本文低权限 service 的限制需要按实际 TUN 部署重新评估，不能只添加 tun.enable: true 就期待正常运行。

启动失败与代理不生效：按层检查

建议按“进程、监听端口、应用接入、规则策略、远端节点”的顺序定位。先用显式 curl --proxy 排除应用设置问题，再观察日志中的规则与策略结果。节点超时和本地连接被拒绝属于不同层，不应一起归为“Linux 代理不生效”。

完成部署后，至少保留内核版本、有效配置副本、service 文件和恢复命令。升级二进制前先停止服务，保留旧程序，再替换并测试配置。需要更多规则与 DNS 解释时，可查看术语表；出现持续性错误时，可沿故障排查的步骤继续定位。