Clash 在 Linux 下的两条部署路线:桌面客户端安装与 mihomo 命令行运行

为什么 Linux 部署要分两条路线看

Windows 与 macOS 的 Clash 客户端基本是"下载安装包、双击安装、图形界面配置"这一套固定流程,差异主要体现在系统权限弹窗上。Linux 则不同,原因在于生态本身的分裂:桌面发行版(Ubuntu、Debian、Fedora 桌面版等)有窗口系统和系统托盘,能跑得动图形客户端;而云服务器、NAS、路由器、Docker 容器这类无图形环境,连显示服务器都不存在,任何依赖 GTK 或 Webview 的客户端都无法启动。

这也决定了两条部署路线服务的是完全不同的使用场景。图形客户端 Clash Verge Rev 面向的是日常办公、开发调试这类需要频繁切换节点、查看流量、调整规则的桌面场景,操作上追求直观;而 mihomo 内核配合 systemd 面向的是长期挂机的服务端场景,追求的是开机自启、崩溃自动重启、无人值守运行,不需要也不适合图形交互。选路线之前先确认自己的系统有没有图形环境,是决定走哪条路的第一步。

路线一:deb 包安装 Clash Verge Rev(桌面环境)

Clash Verge Rev 是当前 Linux 桌面上维护活跃、界面完整度较高的图形客户端选择,基于 Tauri 框架构建,资源占用比早期 Electron 方案更轻。以 Ubuntu / Debian 系发行版为例,推荐使用官方发布的 .deb 安装包,流程如下。

第一步:确认系统依赖

Tauri 应用依赖系统的 WebKitGTK 组件渲染界面,大多数桌面发行版默认已经安装,但精简安装或最小化镜像可能缺失。安装前建议先手动补齐:

sudo apt update
sudo apt install -y libwebkit2gtk-4.1-0 libgtk-3-0 libayatana-appindicator3-1

第二步:安装 deb 包

下载对应架构(amd64 或 arm64)的安装包后,用 apt install 而不是 dpkg -i 直接安装,前者会自动处理依赖关系,后者失败后还需要手动补依赖:

cd ~/Downloads
sudo apt install ./clash-verge-rev_amd64.deb

安装完成后可以在应用菜单中找到 Clash Verge Rev 的图标,首次启动会请求写入网络配置的权限提示,按提示授权即可。

第三步:导入订阅与验证代理

启动后在客户端的订阅管理界面粘贴订阅链接完成拉取,随后进入代理页面选择节点。开启系统代理或 TUN 模式后,可用以下命令验证流量是否已经走代理出口:

curl -s https://ipapi.co/json/

返回结果中的地理位置字段若变为节点所在地区,说明代理链路已经生效。若命令行工具没有走代理(命令行代理与浏览器代理走的是不同的系统设置项),需要额外设置 http_proxy 与 https_proxy 环境变量,或者直接在客户端里开启 TUN 模式接管全局网络层流量,避免逐个工具单独配置。

桌面路线的常见依赖问题

路线二:mihomo 内核 + systemd 常驻运行(无图形环境)

服务器、NAS、容器等无图形环境不能安装图形客户端,这类场景下通常直接运行 mihomo(Clash Meta 项目延续下的内核实现)二进制文件,再用 systemd 管理其生命周期,实现开机自启与异常崩溃后的自动重启。

第一步:下载并放置内核二进制

根据系统架构下载对应的 mihomo 二进制文件,解压后放入系统可执行路径,并赋予执行权限:

tar -zxvf mihomo-linux-amd64.tar.gz
sudo mv mihomo /usr/local/bin/mihomo
sudo chmod +x /usr/local/bin/mihomo

第二步:准备配置目录与配置文件

建议将配置文件统一放在 /etc/mihomo/ 下,便于 systemd 服务统一读取路径,也方便后续多份配置的管理:

sudo mkdir -p /etc/mihomo
sudo cp config.yaml /etc/mihomo/config.yaml

配置文件中需要确认 mixed-port(混合代理端口)、external-controller(外部控制 API 地址)两个字段是否符合无图形环境下的使用习惯。由于没有图形界面查看流量与切换节点,通常会开启 external-controller,配合浏览器访问的第三方面板(如 metacubexd)远程管理节点选择。

mixed-port: 7890
external-controller: 0.0.0.0:9090
secret: "设置一个访问密码"

第三步:编写 systemd 服务单元

新建服务文件 /etc/systemd/system/mihomo.service,内容如下:

[Unit]
Description=mihomo Daemon
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNPROC=500
LimitNOFILE=1000000
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW

[Install]
WantedBy=multi-user.target

其中 -d /etc/mihomo 表示以该目录为工作目录读取配置;Restart=on-failure 保证内核进程异常退出后由 systemd 自动拉起;CAP_NET_ADMIN 与 CAP_NET_RAW 两项能力是开启 TUN 模式接管网络层流量所必需的权限,不用完全以 root 身份运行进程也能满足需求,相对更安全。

第四步:启用并检查服务状态

sudo systemctl daemon-reload
sudo systemctl enable mihomo
sudo systemctl start mihomo
sudo systemctl status mihomo

enable 命令写入开机自启,status 命令确认进程是否处于 active (running) 状态。若状态显示失败,先查看详细日志定位问题:

journalctl -u mihomo -n 50 --no-pager

常见的启动失败原因集中在配置文件字段格式错误、端口已被其他进程占用,或 TUN 模式缺少对应网络能力权限,日志中通常会给出具体报错行号或字段名,按提示逐条修正即可。

无图形环境下如何管理节点与规则

没有窗口界面并不代表只能盲跑,常见的管理方式有以下几种,可以按自己熟悉程度组合使用。

• 第三方 Web 面板:开启 external-controller 后,可以在同一局域网内用浏览器访问该地址搭配一套开源 Web 面板,完成节点切换、延迟测试、规则查看等操作,体验接近图形客户端。
• curl 调用控制 API:mihomo 的外部控制接口本质是一套 REST API,可以直接用 curl 发请求查询当前代理组状态或切换节点,适合写进自动化脚本。
• 直接编辑配置文件后重启服务:对规则、代理组的调整可以直接修改 YAML 文件,再用 systemctl restart mihomo 使其生效,适合改动频率不高的固定环境。

订阅更新方面,若配置文件里写了订阅链接,可以配合 cron 定时任务定期拉取更新后自动重启服务,避免节点信息过期。需要注意的是自动更新脚本最好先做格式校验,避免拉取到损坏的配置文件直接覆盖导致服务重启失败。

两条路线的选择建议

如果日常使用场景是个人笔记本或桌面工作站,能看到窗口和托盘图标,直接选图形客户端路线,操作门槛更低、也更符合大多数人的使用习惯,不需要记忆 systemd 命令。

如果场景是云服务器、家用 NAS、路由器刷机环境或 Docker 容器,这些环境本身不具备图形界面运行条件,只能走 mihomo 内核加 systemd 的路线,把配置维护、崩溃恢复这类工作交给系统服务管理,再配合远程 Web 面板完成日常的节点管理,是目前无图形环境下较为稳妥的做法。

两条路线并不互斥,同一用户在不同设备上完全可以并行使用:办公笔记本装图形客户端,家里的常驻服务器跑 mihomo 加 systemd,二者共用同一份订阅,只是运行形态不同。