为什么 Linux 桌面要特别谈「常驻」?

在 Windows 或 macOS 上,许多用户已经习惯「装一个图形客户端、勾选开机启动」这条路径;到了 Linux 桌面,发行版多样、权限模型更细,单纯依赖桌面自启动项往往会出现三类问题:其一是会话尚未完全就绪时进程拉起过早,订阅或 Geo 资源更新失败;其二是笔记本休眠恢复后路由或 DNS 状态与内核预期不一致;其三是图形界面只是「控制台」,真正承接流量的是后台 mihomo(Clash Meta)进程——若它退出,界面仍开着也会表现为「突然上不了网」。把核心守护进程交给 systemd 管理,可以获得统一的依赖顺序、日志入口与失败重试策略,这正是本文要补齐的场景:在已有图形端或纯 CLI 部署之上,再加一层可靠的自启与常驻

下文默认读者使用带桌面环境的 Debian / Ubuntu 或其衍生发行版,并已具备基础的终端操作能力。若你刚从 Clash Premium 迁到 Meta 系,可先对照本站《Clash Meta 升级完全指南》理清配置差异,再回到 Linux 落地。

先选路径:图形客户端还是独立内核?

常见有两种组合。第一种是图形客户端 + 内置 mihomo:例如 Clash Verge Rev 等在 Linux 上提供的版本,负责订阅管理、规则编辑与系统代理切换,内核仍由应用 bundle。第二种是仅运行官方 mihomo 可执行文件,配置文件与日志由你自行维护,适合已经在服务器上用过 Meta 内核、希望在桌面复用同一套 YAML 工作流的用户。两种方案都可以叠加 systemd;差别在于 ExecStart 指向的是「GUI 包内的 mihomo」还是「你解压到固定路径的二进制」,以及配置目录是否与应用数据目录共用。

若你希望少写 YAML、多靠界面完成日常维护,可优先走图形客户端路线,并仍为核心进程写用户服务,避免「只启动了托盘、没拉起内核」的灰色状态。无论哪条路径,都建议通过本站客户端下载页获取与当前架构匹配的包,减少来源不明二进制带来的风险。

环境准备:架构、权限与目录约定

安装前在终端执行 uname -m:输出 x86_64 对应 64 位 AMD/Intel,aarch64 对应 ARM 桌面或树莓派等。下载 AppImage、deb 或 tar 包时必须与架构一致。若使用 TUN 模式,通常需要额外能力位或授权(例如 CAP_NET_ADMIN),不同客户端会给出图形化提示;若仅使用 HTTP/SOCKS 级系统代理,权限要求相对宽松。

为便于备份,推荐将「你亲手改过」的配置集中放在家目录下某一固定路径,例如 ~/.config/mihomo/ 或客户端文档中说明的 profiles 目录。订阅 URL、规则提供者与自定义规则片段,至少保留一份离线备份,以便重装系统后快速恢复。对 YAML 结构尚不熟悉的读者,可结合《Clash YAML 配置深度解析》理解 proxiesproxy-groupsrules 的优先级关系,再映射到桌面客户端里的同名界面。

图形客户端安装与首次拉取订阅

以常见 deb / AppImage 流程为例:deb 包可用系统软件中心或 sudo apt install ./package.deb 安装,注意依赖若提示缺少 WebKitGTK、libayatana 等库,按终端建议补装即可。AppImage 需赋予可执行权限后直接运行,首次可能提示集成桌面菜单,可按需选择。启动后请在关于或设置页确认内核为 mihomo,并检查监听端口是否与配置一致,避免与系统上其它代理软件冲突。

在「订阅」页粘贴机场提供的 HTTPS 订阅,设置合理的更新间隔,手动执行一次更新以验证链路。若更新失败,优先排查本机时间、是否形成「代理拉取订阅」的环路、以及防火墙是否拦截出站 TLS。成功导入后激活对应配置档案,再打开系统代理或按需启用 TUN。若浏览器可走代理而部分桌面应用仍直连,多半是应用未遵循 http_proxy 环境变量——这与 Windows 上「系统代理 vs TUN」的差异类似,可优先在文档中查阅DNS 与模式相关章节

小提示

图形客户端更新版本后,内置 mihomo 路径可能变化。若你使用下文 systemd 单元硬编码了 ExecStart,请在升级后重新确认二进制绝对路径,避免服务静默失败。

用 systemd 用户服务托管 mihomo

对大多数桌面用户,用户级 systemd(无需 root 写全局单元)足够:服务随用户会话登录而启动,配置与数据也在家目录,权限边界清晰。先确保用户 lingering 已开启,否则未登录图形界面时用户服务不会运行——在共享工作站的场景这是优点;若你希望机器一开机即拉起(即使用户未登录桌面),再考虑系统级单元或以特定系统用户运行,并评估安全边界。

~/.config/systemd/user/ 新建单元文件,例如 mihomo.service,示例如下(请把路径改成你机器上的真实配置目录与二进制位置):

[Unit]
Description=Mihomo (Clash Meta) daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/.config/mihomo
ExecStart=/usr/local/bin/mihomo -d %h/.config/mihomo
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

执行 systemctl --user daemon-reload 后,用 systemctl --user enable --now mihomo.service 启用并立即启动。日志通过 journalctl --user -u mihomo.service -e 查看。若单元多次重启,重点检查配置路径、端口占用、以及订阅是否能直连拉取。

与图形客户端并存时的策略

若图形客户端也会自动启动并尝试独占同一配置目录或同一控制端口,可能出现「两个进程争用一份配置」的冲突。实践中更稳妥的做法是二选一:要么完全由 systemd 托管 mihomo,图形端仅作为前端通过 API 连接已有实例(若客户端支持外部内核);要么仅使用图形端内置守护进程,不在 systemd 里重复启动同一二进制。若你不确定当前客户端是否支持外接内核,可先只启用图形端,观察其启动命令与数据目录,再决定是否拆分。

对只需要「登录后自动有代理」的用户,也可以退而求其次:在桌面环境的「自动启动」里勾选客户端,同时把 systemd 单元作为兜底——但务必避免双实例。更简单的折中是把图形客户端加入自启,并在设置里打开「启动时最小化到托盘」(若提供),以减少重复配置成本。

TUN、能力与安全基线

启用虚拟网卡级接管时,除内核模块可用性外,还要关注发行版对非特权用户创建 TUN 设备的策略。部分客户端通过 polkit 规则或 setcap 解决;若你自行解压二进制,不要随意给整个文件 chmod 777。遵循「最小权限」:仅对必需的能力位授权,配置与日志目录保持用户私有读写。

公司或学校网络环境可能存在透明代理或准入认证,TUN 与系统代理的表现可能不同。遇到仅浏览器可用、终端仍走直连的情况,可先用 rule 模式与 DNS 设置缩小问题范围,再决定是否启用 TUN。更多 DNS 与 Fake-IP 细节仍以官方文档与机场要求为准。

验收清单:怎样确认「常驻」真的生效?

重启前后各检查一次:systemctl --user is-active mihomo.service 是否为 active;监听端口是否与配置一致;浏览器访问依赖规则的站点是否正常。若使用图形端,请确认托盘图标状态与内核日志无报错。再执行一次订阅手动更新,确保自动拉取链路在开机后仍可用。

建议在稳定后把单元文件与 config.yaml 一并纳入备份策略(加密磁盘或私有仓库,勿公开订阅 token)。当发行版大版本升级(例如 glibc major bump)后,若预编译二进制无法运行,优先从本站或上游发布页获取匹配构建,再更新 ExecStart 路径。

常见问题

  • 服务启动后立即退出:查看 journal 是否提示配置解析错误、端口占用或权限不足;用同一 ExecStart 在终端前台运行一次可快速复现。
  • 用户服务未随登录启动:确认已 enable 而非仅 start;检查是否登录了与创建单元相同的用户;Wayland 与显示管理器切换有时影响会话触发时机,可尝试延迟依赖 network-online
  • 休眠恢复后断流:尝试在客户端或单元中增加轻量重启策略,或于恢复网络后手动 systemctl --user restart mihomo.service;同时检查 DNS 缓存是否过期。
  • 与图形端双重启动冲突:保留单一真源进程;关闭其一的自启或禁用对应单元,直至 ss -lntp 中仅有一套监听。

开源仓库适合查阅变更记录与提交问题;若需了解协议与源码方向,可自行访问相关 GitHub 项目。安装包选择与版本对齐仍建议以本站下载页为主,避免与站内教程路径脱节。

结语

Linux 桌面上的 Clash Meta / mihomo 并不难装,真正消耗时间的是把「能上网」固化成「重启、休眠、换网络之后仍然稳定可预期」。把核心守护交给 systemd,并不是为了炫技,而是用发行版自带的基础设施换取可重复的启动顺序与排错入口;图形客户端则继续承担订阅与规则的可视化编辑。相比在论坛碎片信息里拼凑命令,按本文顺序完成路径选择、目录约定、单元编写与冲突规避,通常一次投入即可长期受益。

若你希望跳过来源甄别与架构比对,可直接打开客户端下载页获取当前系统可用构建;需要继续深入规则与分流,可在博客索引中挑选相关主题延伸阅读。→ 立即免费下载 Clash,开启流畅上网新体验