为什么要在 Linux 上用 systemd 管 Clash
在 Linux 上运行 Clash 内核（社区广泛使用的 mihomo，即原 Clash Meta）通常意味着：用一个长期驻留的进程提供本地 HTTP/SOCKS 入口，再由规则把流量分流到节点。桌面用户可能只在登录后要代理，但很多人也希望「开机即就绪」：重启后不依赖手动 screen、不畏终端被误关。
systemd 的价值在于把「启动顺序、崩溃重启、日志汇聚、权限隔离」这些运维题变成声明式配置。对 Ubuntu 而言，这是默认且文档最齐全的服务管理器，和你在服务器上已经用过的 systemctl 同一套工具链。下文默认你使用的是近年 LTS（例如 22.04/24.04），架构为 amd64；其它发行版思路相通，仅包管理命令不同。
准备：权限、目录与安全边界
在开始之前，先统一三件事实，能避免后面一半「莫名其妙连不上」。第一，Clash 需要监听本地端口（常见如 7890），若端口已被占用或被防火墙策略拦截，表现为面板打不开、应用报连接被拒绝。第二，若配置需要从公网拉取订阅，请确认运行用户对配置目录拥有读写权限，否则自动更新会静默失败。第三，把二进制与配置放在不含空格与非 ASCII的路径里，是 Linux 侧排错的好习惯。
获取发行版与更新说明请优先使用本站 下载页，把「安装包入口」和「自行克隆开源仓库了解协议」分开；后者适合写在脚注，而不是替代面向新手的分发路径。更多概念性说明也可对照 使用文档。
systemctl --user），不必全局安装；需要「未登录也常驻」时，再配合 loginctl enable-linger。下文同时给出系统级与用户级的取舍建议。
安装 mihomo 二进制与工作目录
Linux 上没有统一的「应用商店式」Clash 安装体验，更常见的是下载与内核匹配的单文件二进制，授予可执行权限后放入 /usr/local/bin 或 /opt/mihomo/。你可以把可执行文件命名为 mihomo 或维持发行压缩包内的名称，只要在 systemd 单元里写同一路径即可。
建议单独创建工作目录用于配置、规则缓存与运行时文件，例如 /etc/mihomo（系统级）或 ~/.config/mihomo（用户级）。把 config.yaml、Country.mmdb 等就近放置，备份时直接打包该目录即可。请避免把整个配置目录设成 777，宁可细分为目录属主与组权限——订阅链接含有敏感信息，目录过于开放会增加本机多用户场景下的泄露面。
# Example: place binary and verify (adapt paths to your layout)
sudo install -m 0755 ./mihomo /usr/local/bin/mihomo
sudo mkdir -p /etc/mihomo
sudo chown root:mihomo /etc/mihomo # optional dedicated groupconfig.yaml、订阅导入与健康检查
订阅导入在 Linux 上的本质是：让内核能定期把订阅拉下来并生成可用的 proxies 与 proxy-groups 段。若你的服务商提供标准 Clash 配置片段，可直接合入；若是通用订阅链接，请确认转换输出与当前内核特性匹配。本站订阅管理专题对 Base64、远端规则与自动更新的注意点有更系统的整理，这里不重复堆砌字段说明。
写最小可用配置时，务必显式设置 port / socks-port（如需要）、mode（日常建议 rule）、以及对外的 external-controller（若你要用控制面板）。首次启动前，用 curl 在本机探测端口是否返回预期，比凭感觉开关更快定性。
# Minimal sketch (illustrative). Fill proxies / groups from your subscription.
port: 7890
socks-port: 7891
mode: rule
allow-lan: false
external-controller: 127.0.0.1:9090
log-level: info
# proxy providers / rules omitted
启动后可用 curl -x http://127.0.0.1:7890 https://example.com -I 之类命令验证 HTTP 代理链路（示例域名仅作连通性探测，请替换为你环境允许的地址）。若此处失败，先不要怀疑规则复杂度，而应检查进程是否真的在听端口、配置是否被 SELinux/AppArmor 策略拦下（Ubuntu 桌面默认影响相对小，但企业镜像可能加固）。
桌面会话：环境变量与「只做终端代理」
很多用户在 Linux 桌面只需要让浏览器或终端走本地代理。常见做法是导出 http_proxy、https_proxy、all_proxy，并在不需要时 unset。GNOME/KDE 也有图形化的系统代理页，但其行为与桌面版本强相关；若你遇到「终端有代理、图形应用不走代理」之类割裂，多半不是 Clash 坏了，而是应用未读系统代理。
这类需求不一定立刻要上 TUN；反而应先确认 Clash 的本地入口稳定、规则没有把国内站点送往失效节点。需要系统级透明代理时，再阅读 TUN 模式完全指南，避免与本文的安装主线互相干扰。
编写 systemd 单元：ExecStart 与权限
系统级单元一般放在 /etc/systemd/system/mihomo.service。关键字段是 ExecStart 指向二进制、以及工作目录 WorkingDirectory 指向配置文件所在路径。若你不希望以 root 身份跑内核，可以用 User= 与 Group=，并相应地把目录属主改成该账户——这比「为了省事先 root」更安全。
CapabilityBoundingSet、AmbientCapabilities、NoNewPrivileges 等硬化项可视环境启用；初学者可先用较简单的单元跑通，再逐步收紧。对需要 TUN 的场景，额外能力集与设备节点权限要单独评估，这与是否使用 systemd 无关。
# /etc/systemd/system/mihomo.service
[Unit]
Description=Mihomo (Clash Meta) daemon
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
WorkingDirectory=/etc/mihomo
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=3
LimitNOFILE=1048576
[Install]
WantedBy=multi-user.target可选：用户级单元与 linger
若你更想把配置放在家目录并避免 sudo，使用 ~/.config/systemd/user/mihomo.service 是正确的方向。启用命令为 systemctl --user enable --now mihomo.service。当你希望在图形界面未登录时也能拉起服务，需要为账户开启 linger：sudo loginctl enable-linger $(whoami)，否则用户会话结束会带走用户级服务。
这套模式适合做「单用户工作站」；多用户服务器则更应使用系统级单元并明确账号隔离，不要把每个人的订阅文件堆在同一目录下仅依靠文件名区分——那是在给未来的权限事故埋伏笔。
开机自启、保活策略与依赖顺序
安装单元后执行 sudo systemctl daemon-reload，然后 sudo systemctl enable --now mihomo。此时同时完成了「立即启动」与「开机自启」。Restart=on-failure 能在进程崩溃退出后自动拉起；若你遇到「配置热重载导致短暂退出」之类行为，可视情况改为 always 或配合健康检查脚本——但不要把重启间隔设得过短，以免错误配置触发抖动刷日志。
依赖网络就绪是关键：在笔记本上，NetworkManager 可能在登录后很久才拿到 IP；在服务器上，云厂商有时较晚注入 DNS。若服务早于可用网络启动，表现为首轮订阅更新失败。除了使用 network-online.target，还可以在配置里为重试留余地，或延后拉取订阅，这些属于「可观测性」与「容错」之间的平衡。
journalctl 日志与排障顺序
systemd 一体的好处是日志直接进入 journal。用 journalctl -u mihomo -e 跟随最新输出，比到处找散落的文本日志更省心。遇到问题时建议固定顺序：先确认进程存活与端口监听，再看订阅是否成功拉取，然后查DNS 是否异常，最后才深入规则命中与策略组默认节点。这条路径能把「配置写错」与「网络根本没起来」迅速区分开。
若你把 log-level 提到 debug，请注意磁盘占用与隐私：调试日志里可能出现解析域名与握手细节，排错结束应调回 info。
常见问题：权限、端口、DNS 与路由
端口占用或无法监听
7890、9090 等端口被其它代理或开发服务占用时，systemd 会在日志中给出 bind: address already in use 一类提示。用 ss -lntp 找出占坑进程，要么结束冲突进程，要么在配置中更换端口并同步更新你的环境变量与面板地址。
权限不足或无法读取配置
WorkingDirectory 不可读、或 User= 与目录属主不匹配时，常表现为启动即退出。用 namei -l /etc/mihomo/config.yaml 逐级查看权限链，比盲目 chmod 更可靠。订阅自动更新写临时文件失败也会在日志里留下线索。
DNS 解析失败或污染
Linux 全局解析走 systemd-resolved 时，与 Clash 内置 DNS 模块的组合偶发「看似通了但部分域名间歇失败」。先确认本机 resolv.conf 的实际链路，再决定 fake-ip 与否、以及回落 DNS 列表。规则层面的域名分流可配合 规则分流详解渐进调试，不要一上来就把规则复杂度拉满。
规则环路与错配默认策略
当你把「本地入站」误送交上游，或默认策略指向已失效节点时，会出现奇怪的断续连接。此时把模式短暂切到 direct 做基线验证，再回到 rule，结合日志里的命中记录定位是哪一个策略组在引入环路。
小结：把「能跑」升级成「敢长期跑」
Linux 上的 Clash 链路，看似只有「下载二进制 + 填 YAML」两步，真正决定体验的是：订阅是否可持续更新、端口与权限是否干净、失败时是否自动复苏、日志是否易于阅读。把这几件事交给 systemd，并不是炫技，而是把桌面与轻量服务器的日常维护成本压到最低。相比临时起一个前台进程，自启动单元在稳定性与可预期行为上通常更胜一筹——尤其在远程 SSH 场景里，你不会希望每次断开会话还要记得手动重启。
若你希望减少手工拼配置文件、在图形界面里完成节点切换与更新，也可以从本站获取带 UI 的跨平台客户端；相比只靠命令行与小面板，一体化工具在策略切换与状态可视化上往往更省力。