Linux 用 Clash 的两条路线:桌面客户端安装与命令行内核部署

Linux 上 Clash 的两条部署路线怎么选

严格来说,"Clash"在今天更多指代生态而不是单一软件——底层跑的引擎是 mihomo(前身为 Clash Meta,原版 Clash 内核已停止更新),上层可以套一个带图形界面的桌面客户端,也可以直接把内核二进制文件丢到系统里当服务跑。两条路线的差异不只是"有没有界面",而是使用场景本身就不同:

• 桌面客户端路线:适合日常用 Ubuntu、Fedora、Debian 等发行版跑桌面环境(GNOME、KDE 等)的场景,图形界面里切节点、看规则日志、开关 TUN 模式都是鼠标点击,上手成本最低,代表产品是 Clash Verge Rev 和 FlClash。
• 命令行内核路线:适合没有图形界面的服务器、NAS、旁路由、云主机,或者你就是想把 Clash 变成一个开机自启的后台服务,不需要也不方便打开窗口操作,靠一份 config.yaml 加 systemd 单元文件长期挂机。

两条路线用的是同一个 mihomo 内核,规则语法、订阅格式完全通用,区别只在"谁负责把内核跑起来、谁负责暴露控制面板"。如果你的 Linux 机器同时兼顾日常上网和长期挂机(比如一台常年开着的迷你主机),完全可以两条路线都装,按需切换。

桌面客户端路线:Clash Verge Rev 与 FlClash 安装要点

桌面客户端路线里,Clash Verge Rev 和 FlClash 是目前 Linux 桌面上维护活跃、开源可查的两个选择,底层都套着 mihomo 内核,界面风格和依赖体积略有差异。

Clash Verge Rev:主流发行版通吃

Clash Verge Rev 官方发布 .deb、.rpm 和 .AppImage 三种打包形式,基本覆盖了 Debian/Ubuntu 系、Fedora/openSUSE 系,以及任何发行版都能跑的 AppImage 通用格式。安装要点:

1. Debian/Ubuntu 系用 dpkg -i 装 .deb 包,遇到依赖缺失报错时补一句 apt --fix-broken install 即可。
2. Fedora/openSUSE 系用 rpm -i 或对应包管理器安装 .rpm 包。
3. 不想装系统包、只想临时跑一下的场景,给 AppImage 文件加执行权限后直接双击或命令行运行:chmod +x Clash-Verge-Rev.AppImage && ./Clash-Verge-Rev.AppImage。
4. 首次启动如果提示 TUN 模式需要额外授权,按界面引导执行一次带 sudo 的辅助进程安装,之后开关 TUN 就不需要每次输密码。

FlClash:轻量跨平台的另一种选择

FlClash 基于 Flutter 构建,同样提供 Linux 的 .deb 和 .AppImage 包,界面更简洁,资源占用相对更小,适合配置不算高的桌面机或者虚拟机环境。安装方式与 Clash Verge Rev 类似,解压或安装后直接运行,首次进入需要手动导入订阅链接或本地配置文件。

两者安装完成后的使用逻辑基本一致:导入订阅链接 → 选一个代理模式(规则/全局/直连)→ 需要时开启 TUN 模式接管全局流量 → 在节点列表里选组切换。具体的图形界面操作步骤和各平台通用的排坑清单,可以参考本站另一篇关于首次安装设置的文章。

命令行路线:直跑 mihomo 内核的完整步骤

命令行路线跳过一切图形界面,直接管理 mihomo 二进制文件本身。整套流程分三步:下载对应架构的二进制、准备配置文件、手动跑一次验证没问题。

第一步:下载对应 CPU 架构的二进制

mihomo 官方发布页会区分 amd64、arm64、armv7 等架构,先用以下命令确认自己机器的架构再下载对应版本:

uname -m
# x86_64 对应 amd64;aarch64 对应 arm64

下载后的文件通常是 .gz 压缩包,解压并赋予执行权限,再放进一个固定目录方便后续 systemd 引用:

gunzip mihomo-linux-amd64.gz
chmod +x mihomo-linux-amd64
sudo mkdir -p /etc/mihomo
sudo mv mihomo-linux-amd64 /usr/local/bin/mihomo

第二步:准备配置文件

把订阅转换出的 config.yaml 放进 /etc/mihomo/ 目录,最少要确认以下几个字段是自己需要的值:

• port / socks-port:HTTP 与 SOCKS5 本地代理端口。
• allow-lan:如果这台机器要给局域网内其他设备提供代理,设为 true。
• mode:rule(按规则分流)、global(全部走代理)或 direct(全部直连)。
• external-controller:控制面板监听地址,例如 127.0.0.1:9090,配合 secret 字段设一个访问密钥。

第三步:手动跑一次验证

先不接 systemd,直接在终端里跑一次,确认配置能正常加载、没有语法错误:

mihomo -d /etc/mihomo

看到日志里出现规则加载成功、监听端口打开的提示,没有报错刷屏,就说明配置文件是可用的,可以进入下一步做成常驻服务。

用 systemd 守护 mihomo 服务并验证连通性

手动跑通之后,下一步是让 mihomo 开机自启、崩溃自动重启,这一步交给 systemd 最省心。新建一个单元文件:

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

写入以下内容(按实际路径调整):

[Unit]
Description=mihomo Clash kernel service
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
User=root

[Install]
WantedBy=multi-user.target

保存后依次执行以下命令启用并启动服务:

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

systemctl status 显示 active (running) 就说明服务已经常驻。日常排错和查日志推荐用:

journalctl -u mihomo -f

验证连通性可以直接用 curl 走本地代理端口测试:

curl -x socks5h://127.0.0.1:7890 https://www.google.com -I

返回正常的 HTTP 状态行,说明代理链路已经通了。如果需要看当前生效的节点、流量和规则匹配情况,可以在浏览器打开 external-controller 配置的地址(如 http://127.0.0.1:9090/ui),搭配开源的 Web 控制面板项目查看,不需要额外装桌面客户端。

两条路线的订阅更新与日常维护差异

选好路线之后,长期维护的方式也不一样,提前了解可以少踩一些坑。

桌面客户端路线的订阅更新一般在界面里就有"更新订阅"按钮,支持设定自动更新间隔,规则集、节点列表更新后立即生效,不需要重启客户端本身。切换节点、临时改分流模式都是点击操作,适合需要频繁调整的日常使用。

命令行内核路线没有按钮,更新订阅通常靠一条定时任务(crontab)去重新下载最新的 config.yaml 并覆盖旧文件,再执行一次 systemctl restart mihomo 让新配置生效。如果不想每次更新都重启进程打断已有连接,也可以研究 mihomo 提供的配置热重载接口(通过 external-controller 面板发起重载请求),避免服务中断。

无论走哪条路线,配置文件的规则语法都是通用的——同一份 config.yaml 理论上可以在桌面客户端和命令行内核之间直接复用,只是桌面客户端往往会在导入时自动补一层图形化的分组和面板设置。如果你同时维护一台桌面机和一台常驻服务器,不妨保留同一份规则来源,减少两边配置不一致带来的排错成本。