Linux 安装 Clash 全流程:桌面客户端与命令行 systemd 服务部署

Linux 上跑 Clash 有两条完全不同的路线:桌面环境追求可视化操作,直接装带界面的客户端;服务器环境没有图形界面,需要用内核程序配合 systemd 做成常驻服务。本文分别讲清这两条路线的安装步骤、目录规划与权限要点。

两条路线怎么选

在动手之前先明确一件事:Linux 下"装 Clash"根本不是单一操作,而是要先判断自己所处的环境类型。桌面版 Linux(如 Ubuntu Desktop、Fedora Workstation、各类 Linux Mint 分支)有窗口管理器和系统托盘,适合装带图形界面的客户端,日常切换节点、查看流量走的是点击操作。服务器版 Linux(云主机、NAS、家庭网关)通常只有 SSH 连接,没有桌面环境,只能靠纯命令行的内核程序加进程管理工具让代理常驻后台。

这两条路线用的软件形态完全不同:桌面路线用的是 Clash Verge Rev 这类基于 Tauri 框架打包的图形客户端,内部集成了 mihomo 内核,提供订阅管理、规则编辑、流量图表的可视化界面;命令行路线直接跑 mihomo 内核可执行文件,没有界面,一切靠配置文件和终端命令,再用 systemd 管理进程生命周期,保证机器重启后自动拉起。

提示:不确定自己的环境属于哪种?执行 echo $XDG_CURRENT_DESKTOP,有输出说明存在桌面环境;云服务器控制台里通过 SSH 连接的机器,基本都是纯命令行环境。

桌面环境:Clash Verge Rev 的 deb 包安装

Clash Verge Rev 官方发行包里针对 Debian/Ubuntu 系发行版提供了 .deb 安装包,是目前桌面 Linux 上安装门槛最低的方式,不需要手动配置依赖,双击或用 dpkg 安装即可。以下是完整流程。

第一步:下载对应架构的安装包

Linux 桌面主流是 x86_64(即 amd64)架构,少数 ARM 设备(如某些国产笔记本、Raspberry Pi 桌面套件)需要选 aarch64 架构的包。架构判断可以执行:

uname -m
# 输出 x86_64 → 选 amd64 包
# 输出 aarch64 → 选 arm64 包

第二步:用 dpkg 安装并处理依赖

下载好的 deb 包放到本地目录后,执行安装命令。deb 包本身不会自动拉取依赖,如果提示依赖缺失,紧接着用 apt 补齐即可:

sudo dpkg -i clash-verge-rev_*.deb
# 若报依赖错误,执行以下命令自动修复
sudo apt --fix-broken install

安装完成后,应用会出现在应用程序菜单里,同时会在系统里注册一个用户级的后台辅助进程,用来处理系统代理设置与虚拟网卡权限申请。首次启动时,系统通常会弹出图形化的密码授权窗口,这是因为开启 TUN 模式需要建立虚拟网络接口,必须要 root 权限才能创建,这一步是正常流程,不是安装出错。

第三步:配置开机自启

Clash Verge Rev 的设置面板里有"开机自启动"开关,打开后程序会通过桌面环境的自启动机制(遵循 ~/.config/autostart/ 下的 .desktop 文件规范)在用户登录时自动拉起。如果开关无效,可以手动检查该目录下是否生成了对应的 desktop 文件:

ls ~/.config/autostart/ | grep -i clash

如果没有生成,可以从应用安装目录复制一份 desktop 文件到这个路径,或者在设置面板里关闭再重新开启一次自启动开关,大多数情况下能重新触发注册流程。

其他发行版的安装方式

非 Debian 系发行版有各自的处理方式:

  • 基于 RPM 的发行版(Fedora、openSUSE):官方发行包同样提供 .rpm 格式,用 sudo rpm -isudo dnf install 指向本地文件即可安装。
  • Arch 系发行版:可以通过社区维护的 AUR 包管理,用 yayparu 一类的 AUR 助手工具搜索安装,依赖会自动解析。
  • 其他发行版或需要免安装场景:官方也提供通用的 AppImage 格式,下载后赋予可执行权限直接运行,不写入系统目录,适合临时测试或权限受限环境。

服务器环境:mihomo 内核 + systemd 部署

服务器上没有桌面环境,不需要也不能装图形客户端,直接部署 mihomo 内核(Clash Meta 项目的延续)是更合理的方式。内核本身是单个可执行文件,占用资源极低,配合 systemd 管理后可以做到机器重启后自动恢复代理服务,不需要人工干预。

第一步:规划配置目录

在部署之前先规划好目录结构,避免配置文件和程序本体混在一起,后续升级内核版本时不会误删配置:

/etc/mihomo/           # 配置文件目录
  ├── config.yaml      # 主配置文件
  ├── geoip.dat         # GeoIP 数据库
  └── geosite.dat       # GeoSite 数据库
/usr/local/bin/mihomo   # 内核可执行文件

把内核可执行文件放进 /usr/local/bin 这类系统级可执行目录,配置文件独立放在 /etc/mihomo,是 Linux 下软件部署的通行惯例,便于用 systemd 统一管理,也方便后续手动排查配置问题时快速定位。

第二步:下载内核并赋予执行权限

mkdir -p /etc/mihomo
cd /usr/local/bin
# 假设已下载对应架构的内核压缩包并解压得到 mihomo 文件
chmod +x mihomo
mihomo -v   # 验证是否能正常执行并输出版本号

服务器架构判断同样用 uname -m,云主机绝大多数是 x86_64,部分海外便宜服务商或 ARM 云实例(如某些轻量应用服务器)是 aarch64,下载前务必核对清楚,架构不匹配的可执行文件运行时会直接报错退出。

第三步:准备配置文件

把订阅转换出来的 YAML 配置文件放到 /etc/mihomo/config.yaml,确认里面的关键字段没有问题,尤其是 external-controller 这一项——服务器环境下如果开放了这个地址且绑定在 0.0.0.0,相当于把内核的控制接口暴露给公网,必须设置访问密钥或者只绑定本地地址:

external-controller: 127.0.0.1:9090
secret: "设置一个足够复杂的密钥"

第四步:编写 systemd 服务单元

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

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

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

[Install]
WantedBy=multi-user.target

其中几个字段需要重点说明:-d /etc/mihomo 指定内核读取该目录下的配置文件;Restart=on-failure 表示进程异常退出时自动重启,避免因为一次网络抖动导致代理服务彻底中断;LimitNOFILE 调高文件描述符上限,是因为代理服务需要同时维持大量并发连接,系统默认限制在高负载场景下容易触发连接失败。

第五步:启用并启动服务

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

enable 命令负责建立开机自启的软链接,这样服务器重启后无需手动执行任何命令,mihomo 会随系统一起拉起。status 命令用来确认当前运行状态,重点看 active (running) 这一行是否正常。

权限要点与运行验证

Linux 环境下部署代理最容易踩坑的地方集中在权限问题上,这里单独梳理清楚。

TUN 模式的权限需求

如果配置文件里开启了 tun.enable: true,内核需要创建虚拟网络接口并修改路由表,这个操作在 Linux 下必须要 CAP_NET_ADMIN 权限。以 root 身份运行 systemd 服务是最简单的解决方式(如上文服务单元里的 User=root),但如果出于安全考虑不想让代理进程以 root 权限常驻,也可以用 setcap 命令给可执行文件单独授权,再用普通用户身份运行:

sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo

授权之后把服务单元里的 User=root 改成专门为代理服务创建的普通用户,进一步收紧权限范围,是服务器安全实践里更推荐的做法。

配置目录的读写权限

如果用普通用户运行服务,记得给配置目录赋予对应用户的读取权限,否则内核启动时会因为无法读取配置文件而直接退出:

sudo chown -R clash-user:clash-user /etc/mihomo

验证代理是否生效

服务启动后,先确认端口是否正常监听:

sudo ss -tlnp | grep mihomo

再通过命令行发起一次带代理的请求,验证出口 IP 是否变化:

curl -x http://127.0.0.1:7890 https://api.ip.sb/ip

如果返回的 IP 是节点出口地址而不是服务器本机地址,说明代理链路已经跑通。桌面环境下用 Clash Verge Rev 的话,直接看客户端里的连接状态和延迟测试结果即可,不需要手动执行 curl 验证。

注意:服务器场景下用 mihomo 通常是为了给内网设备提供统一代理出口,而不是让服务器自身"翻墙",配置 bind-address 时要明确开放给哪些内网 IP 段访问,避免端口对公网无限制开放带来的安全风险。

日常维护建议

两条路线部署完成后,日常维护重点略有不同,分别列一下。

桌面客户端一侧:Clash Verge Rev 内置了订阅自动更新功能,可以在设置里设定更新周期,不需要每次手动重新导入订阅链接;如果切换了多个订阅源,建议给每个配置文件重命名成能一眼识别的名字,避免误切到失效订阅。

命令行服务一侧:配置文件更新后,不需要重启整个服务,mihomo 支持通过 RESTful API 触发热重载,或者直接用 systemctl restart mihomo 重启服务生效;建议给配置目录做定期备份,尤其是自定义规则较多的场景,一次误操作覆盖配置会导致规则全部丢失。

另外,无论哪条路线,GeoIP 与 GeoSite 数据库都建议定期更新,数据库过旧会导致分流规则误判,出现"该走代理的域名没走、该直连的地址反而走了代理"的情况,具体的更新方法和排查步骤可以参考数据库更新相关的技术笔记。

两条路线对照小结

维度桌面路线(Clash Verge Rev)命令行路线(mihomo + systemd)
适用场景日常办公/开发用的桌面 Linux云服务器、NAS、无桌面网关设备
操作方式图形界面点击操作终端命令 + 配置文件
安装形式deb/rpm/AppImage单个内核可执行文件
常驻方式桌面自启动机制systemd 服务单元
权限要点首次启动图形授权CAP_NET_ADMIN 或 root 运行
下载客户端