Linux 部署 预计阅读 14 分钟

Linux 部署 Clash：桌面客户端、mihomo 命令行与服务自启

从桌面环境到无图形服务器，梳理配置目录、启动命令、systemd 服务和终端代理变量。

先确定部署路径：桌面、命令行还是常驻服务

Linux 上的 Clash 部署通常不是单一方案。带有 GNOME、KDE、Xfce 等桌面环境的个人电脑，适合使用带图形界面的客户端；远程服务器、开发容器宿主机或只通过 SSH 管理的设备，更适合直接运行 mihomo 内核；需要开机启动、长期提供本机代理端口的设备，则应在命令行运行基础上增加 systemd 服务。

mihomo 是持续维护的 Clash Meta 内核名称。它负责读取 YAML 配置、建立代理连接、执行规则匹配并监听 HTTP、SOCKS 或 mixed 端口。图形客户端通常在它的上层提供订阅管理、节点切换、日志查看和系统代理开关。换句话说，桌面客户端解决交互问题，内核解决实际流量处理问题。遇到连接异常时，应区分是界面状态、配置内容还是内核运行状态导致。

使用环境 推荐方式 主要管理入口
Linux 桌面日常使用 图形客户端 托盘菜单、客户端设置与日志页
无图形服务器 mihomo 命令行 SSH、配置文件与运行日志
长期运行的工作站或服务器 mihomo 加 systemd systemctl 与 journalctl
需要接管更多应用流量 TUN 模式 配置文件、路由与权限设置

部署前还要确认处理器架构。常见个人电脑和云服务器通常是 amd64，部分开发板、路由设备和 ARM 云主机使用 arm64。可执行 uname -m 查看系统报告：x86_64 对应 amd64，aarch64 对应 arm64。下载到错误架构的二进制文件时，Shell 往往会报告无法执行或格式错误。

Linux 桌面客户端：安装包、配置目录与代理开关

桌面环境下可以优先选择仍在维护并明确支持 mihomo 的图形客户端。常见发布格式包括 AppImage、Debian 系的 .deb 和 Fedora、openSUSE 等系统使用的 .rpm。选择格式时应以发行版包管理方式为准，不必为了客户端更换系统软件源。

AppImage 的运行方式

AppImage 通常是单文件分发，下载后需要增加执行权限。以下命令假设文件已经放入当前目录，实际执行时使用下载得到的完整文件名：

chmod +x Clash-Linux.AppImage
./Clash-Linux.AppImage

如果双击后没有窗口，应从终端启动一次并阅读输出。较新的发行版可能缺少 AppImage 所需的 FUSE 兼容组件，也可能由桌面沙箱、显示服务器或权限设置阻止启动。终端输出通常比桌面弹出的简短提示更有定位价值。

deb 与 rpm 安装

Debian、Ubuntu 及其衍生系统可以通过包管理器安装本地 deb 文件，使依赖关系由系统处理：

sudo apt install ./clash-client-linux-amd64.deb

Fedora 系统可使用：

sudo dnf install ./clash-client-linux-x86_64.rpm

安装完成后，从应用菜单启动客户端。首次运行通常需要完成三个步骤：导入订阅或 YAML 配置、选择策略组中的可用节点、开启系统代理。开启系统代理只会影响遵循桌面代理设置的应用，部分终端程序、容器、游戏和自行实现网络栈的软件不会自动读取该设置。

图形客户端的配置目录会因项目而异，常见位置包括 ~/.config/ 下的应用专属目录，以及 ~/.local/share/ 下的数据目录。不要在客户端运行时直接覆盖其数据库或托管配置。需要迁移时，先退出客户端，再备份应用目录；如果客户端提供导出功能，应优先使用其导出流程。

桌面代理开启后，可先检查客户端日志是否出现监听端口成功的信息，再测试浏览器访问。若浏览器正常而终端命令失败，通常说明终端程序没有读取系统代理，而不是内核或节点本身失效。

mihomo 命令行部署：目录、配置与启动检查

无图形环境中，建议将可执行文件、配置文件和运行数据分开管理。系统级部署可以把二进制文件放在 /usr/local/bin/mihomo，配置目录放在 /etc/mihomo；仅供当前用户使用时，可以把配置放到 ~/.config/mihomo。配置目录需要允许运行账户读取和写入，因为内核可能在其中保存缓存、规则数据和运行状态。

安装二进制文件后，先确认它能够运行：

mihomo -v
mihomo -h

如果终端提示找不到命令，应检查文件是否位于 PATH 包含的目录，并确认执行权限。若二进制文件位于当前目录，需要使用 ./mihomo，Shell 默认不会从当前目录搜索命令。

mihomo 使用 YAML 配置。下面是一份用于验证监听端口和规则引擎的最小示例，它把所有流量直连，不包含远程节点：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

将文件保存为 config.yaml 后，可以先执行配置检查。不同版本支持的命令参数可能略有差异，应以 mihomo -h 输出为准；常见检查方式如下：

mihomo -t -d /etc/mihomo

检查通过后以前台方式启动：

mihomo -d /etc/mihomo

-d 指定工作目录，内核会从该目录读取主配置和相关数据。第一次部署不要立刻放到后台，先观察启动日志，确认 YAML 可以解析、端口没有被占用、规则文件能够读取。看到 mixed 端口监听成功后，再打开另一个 SSH 会话测试代理：

curl --proxy http://127.0.0.1:7890 https://example.com/

实际使用的订阅配置通常会包含代理节点、策略组、规则、DNS 和规则提供器。更新配置时，不应只确认 YAML 语法，还要检查策略组引用的节点或提供器名称是否存在，规则末尾是否有合理的兜底项，以及所用字段是否受到当前 mihomo 版本支持。

systemd 服务自启：运行账户、重启策略与日志

长期运行时可以把 mihomo 注册为 systemd 系统服务。系统服务适合需要开机后立即提供代理端口的机器，也便于统一查看退出状态和运行日志。创建服务前，先准备专用账户和配置目录：

sudo useradd --system --home-dir /var/lib/mihomo --create-home --shell /usr/sbin/nologin mihomo
sudo mkdir -p /etc/mihomo
sudo chown -R mihomo:mihomo /etc/mihomo /var/lib/mihomo
sudo chmod 750 /etc/mihomo

然后创建 /etc/systemd/system/mihomo.service：

[Unit]
Description=mihomo proxy service
After=network-online.target
Wants=network-online.target

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

[Install]
WantedBy=multi-user.target

服务文件写入后，重新加载 systemd 配置并启动：

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

查看本次启动日志可使用：

sudo journalctl -u mihomo -b
sudo journalctl -u mihomo -f

-b 仅查看本次开机后的记录，-f 持续跟踪新日志。修改 YAML 后，建议先单独执行配置检查，再重启服务：

sudo -u mihomo /usr/local/bin/mihomo -t -d /etc/mihomo
sudo systemctl restart mihomo

如果希望仅在当前用户登录后运行，也可以使用 systemd 用户服务，将单元文件放到 ~/.config/systemd/user/，并使用 systemctl --user 管理。用户服务不需要专用系统账户，但默认受用户会话生命周期影响。需要退出登录后继续运行时，要结合系统的 linger 设置评估权限和维护方式。

不要把服务配置成无条件高速重启。配置语法错误、端口冲突或文件权限错误不会因为连续重启而自动解决，反而可能产生大量重复日志。Restart=on-failure 配合数秒间隔，更适合处理偶发进程退出。

终端代理变量：HTTP_PROXY、ALL_PROXY 与 NO_PROXY

Linux 桌面中的“系统代理”通常不会自动覆盖所有 Shell 命令。curl、Git、部分包管理器和开发工具会读取环境变量，因此命令行环境需要单独设置。假设 mihomo 的 mixed 端口为 7890，当前终端可以执行：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5h://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1,::1

同时设置大写和小写变量能兼容更多工具：

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
export no_proxy="$NO_PROXY"

socks5h 中的字母 h 表示域名解析也交给 SOCKS 代理端处理，适合希望减少本机 DNS 路径差异的命令行请求。不过，各工具对代理协议和变量优先级的实现并不完全相同。出现异常时，可先用 curl 明确指定代理测试，再检查具体工具文档。

需要长期启用时，可以把导出命令写入 Shell 配置，例如 Bash 的 ~/.bashrc 或 Zsh 的 ~/.zshrc。更稳妥的方式是定义开关函数，避免访问局域网服务或排查网络时忘记关闭代理：

proxy_on() {
  export HTTP_PROXY=http://127.0.0.1:7890
  export HTTPS_PROXY=http://127.0.0.1:7890
  export ALL_PROXY=socks5h://127.0.0.1:7890
  export NO_PROXY=localhost,127.0.0.1,::1
  export http_proxy="$HTTP_PROXY"
  export https_proxy="$HTTPS_PROXY"
  export all_proxy="$ALL_PROXY"
  export no_proxy="$NO_PROXY"
}

proxy_off() {
  unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
  unset http_proxy https_proxy all_proxy no_proxy
}

执行 sudo 时，环境变量通常会被过滤，所以普通用户终端已经启用代理，并不代表 sudo 启动的程序也会使用代理。不要为了省事大范围保留全部环境变量，应针对包管理器或具体命令使用其支持的代理配置。

容器同样不会天然继承宿主机的 127.0.0.1 代理。容器内部的回环地址指向容器自身，而不是宿主机。需要让容器访问宿主机代理时，应根据 Docker、Podman 和网络模式设置可达的宿主地址，并确认 mihomo 的监听地址、局域网访问设置和防火墙规则。将代理端口暴露到局域网前，还应限制允许访问的网络范围。

TUN 模式：权限、路由与 DNS 的配合

系统代理和环境变量只对主动读取代理配置的应用生效。对于不支持代理设置的程序，mihomo 可以通过 TUN 虚拟网卡接管流量。TUN 模式会调整路由并处理更多连接，因此部署复杂度也高于普通端口代理。

Linux 系统首先需要提供 /dev/net/tun。可执行以下命令检查：

ls -l /dev/net/tun

在容器或受限虚拟环境中，该设备可能没有映射进来。即使设备存在，运行 mihomo 的账户还需要网络管理能力。systemd 服务可以按需加入能力设置：

CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE

这两行应放在服务文件的 [Service] 区段。修改后执行 systemctl daemon-reload 并重启服务。普通代理端口如果高于 1024，一般不需要 CAP_NET_BIND_SERVICE；是否保留应按实际监听端口决定。

配置 TUN 时需要关注自动路由、自动识别出口接口、DNS 劫持和 IPv6 行为。不同 mihomo 版本支持的字段会演进，应以当前版本文档和启动日志为准。部署后至少验证以下几项：

  1. mihomo 停止后，系统默认路由和 DNS 是否恢复。
  2. SSH 当前连接是否仍然稳定，远程管理地址是否被错误送入代理。
  3. 局域网网段、网关、NAS 和开发服务是否按预期直连。
  4. IPv4 与 IPv6 是否采用一致策略，避免只有一类流量绕过规则。
  5. 休眠唤醒、网络切换或 VPN 连接后，TUN 路由是否需要重建。

故障定位：从进程、端口、配置到规则逐层检查

Linux 上的连接问题适合按层次排查，不要一开始就反复更换节点或重装客户端。先确认进程存在，再确认端口监听，随后检查代理请求、DNS 和规则命中。

进程启动后立即退出

使用 systemd 时先执行 systemctl status mihomo 和 journalctl -u mihomo -b。常见原因包括 YAML 缩进错误、配置字段不受当前内核支持、工作目录不可写，以及引用的规则文件不存在。手动运行 mihomo -t -d /etc/mihomo 通常能得到更直接的配置错误位置。

端口被占用

检查 7890 端口的监听进程：

ss -lntp | grep 7890

旧实例、另一个代理客户端或重复启动的服务都可能占用同一端口。应停止不需要的实例，或在配置中更换端口，并同步修改终端代理变量。只修改一端会造成程序继续访问旧端口。

本机可用，其他设备无法连接

先检查 allow-lan、监听地址和主机防火墙。仅监听 127.0.0.1 时，服务只接受本机连接。允许局域网访问后，还应限制防火墙来源范围，并避免把控制接口直接暴露到不受信任网络。如果配置了 external-controller，建议绑定回环地址并设置访问凭据。

浏览器可用，Git 或 curl 不通

这通常是系统代理与终端环境分离造成。执行 env | grep -i proxy 查看当前变量，并用 curl 的 --proxy 参数进行对照测试。还要检查工具自身是否保存了旧代理地址，例如 Git 的全局代理配置可能覆盖当前环境。

代理已连接，但目标流量走错策略

将日志级别临时调高，观察请求匹配到的规则和策略组。Clash 规则按顺序匹配，前面的宽泛规则可能提前截获流量。检查域名规则、IP 规则、GEOIP 或规则集的先后关系，并确认列表末尾存在明确的兜底规则。修改规则后先检查配置，再执行平滑重载或服务重启。

更新内核与配置的顺序

内核更新和配置更新应分开进行。先保留当前可运行的二进制文件与配置副本，再替换其中一项并验证。更新 mihomo 后先运行版本命令和配置检查，确认现有字段仍可解析；更新订阅后则重点检查策略组引用、规则提供器和节点名称。一次只改变一个关键变量，出现故障时更容易回退和定位。

对于长期运行的服务器，可以定期关注服务退出状态、日志体积和配置更新时间。订阅自动更新不等同于内核自动重载，应确认所用客户端或脚本是否会在文件变化后触发配置加载。直接覆盖正在读取的配置文件时，建议先写入临时文件、完成语法检查，再原子替换正式文件，减少半写入状态被读取的风险。

部署完成后的检查清单

  • 确认下载的构建与 uname -m 报告的处理器架构一致。
  • 确认配置目录归运行账户所有，敏感配置没有开放给其他本地用户读取。
  • 在前台启动阶段完成 YAML、监听端口和基础代理请求测试。
  • systemd 服务使用明确的工作目录、运行账户和失败重启策略。
  • 终端代理变量与 mihomo 实际端口一致，并为本机与局域网地址设置合理的直连范围。
  • 启用 TUN 前检查设备节点、网络能力、SSH 管理路径和路由恢复方式。
  • 修改订阅、规则或内核版本后逐项验证，避免同时改变多个运行条件。

桌面客户端、mihomo 命令行和 systemd 并不是互斥方案。个人工作站可以使用图形客户端管理日常节点，同时保留命令行方法用于日志诊断；无图形服务器则可以用 mihomo 与 systemd 获得稳定、可审计的运行方式。部署方式确定后，再根据应用是否读取系统代理决定使用环境变量或 TUN，整体配置会更清晰。

下载Clash