Linux 部署 预计阅读 14 分钟

Linux 安装 Clash：桌面客户端、mihomo 命令行与 systemd 部署步骤

覆盖桌面发行版与无图形服务器环境，说明配置目录、服务启动、日志查看和代理变量设置。

先确定部署方式与处理器架构

Linux 上所说的“安装 Clash”通常包含两类方案。桌面方案由图形客户端管理内核、订阅、系统代理和策略组，适合 Ubuntu、Debian、Fedora、Arch Linux 等带桌面环境的发行版。命令行方案直接运行 mihomo 内核，再用 systemd 托管进程，适合服务器、软路由、开发机以及没有图形界面的设备。

两种方案的核心工作相同：读取 YAML 配置，监听本地代理端口，按规则选择策略，并把连接转发到配置中的节点。差异主要在管理方式。图形客户端会提供订阅更新、策略切换和日志窗口；命令行部署则需要自行维护配置目录、服务权限、日志与更新流程。

当前 Linux 命令行部署通常选择持续维护的 mihomo。它源于 Clash Meta 分支，支持 Clash 常见规则、策略组、代理提供器、DNS 和 TUN 配置。旧配置迁移时不能只看文件扩展名，还要检查其中使用的规则类型、脚本字段、DNS 选项和实验性功能是否受当前内核支持。

下载前先确认 CPU 架构。包名中的架构必须与系统一致，不能只根据发行版名称判断。执行以下命令查看内核报告的架构：

uname -m
getconf LONG_BIT
命令输出 常见包标识 常见设备
x86_64 amd64 或 x86_64 多数 Intel、AMD 台式机与服务器
aarch64 arm64 或 aarch64 64 位 ARM 服务器、开发板
armv7l armv7 部分 32 位 ARM 设备

桌面发行版安装图形客户端

桌面用户应优先选择仍在维护、明确提供 Linux 构建的客户端。常见分发格式包括 AppImage、Debian 软件包和 RPM 软件包。选择格式时要同时核对架构、桌面环境和应用发布说明。图形客户端通常会把用户配置写入主目录下的应用数据目录，而不是系统级的 /etc。

AppImage 安装

AppImage 是单文件运行格式，适合不希望修改系统软件源的桌面环境。下载与架构匹配的文件后，先赋予执行权限，再从终端启动。下例假定安装包已经下载到当前用户的 Downloads 目录，实际文件名应以下载结果为准：

cd "$HOME/Downloads"
chmod +x Clash*.AppImage
./Clash*.AppImage

如果终端能够启动而从文件管理器双击没有反应，应从终端读取启动错误。部分发行版需要可用的 FUSE 运行环境；也有 AppImage 支持解包运行。不要在不清楚文件来源和权限影响时使用 sudo 启动桌面客户端，否则配置可能被写入 root 用户目录，之后普通用户会看到“配置丢失”或无法修改文件。

DEB 与 RPM 软件包

Debian、Ubuntu 及其衍生发行版可安装对应的 DEB 包。使用 APT 安装本地文件，可以同时处理软件包声明的依赖：

sudo apt install ./客户端文件名.deb

Fedora、Rocky Linux 等使用 RPM 体系的发行版可以通过 DNF 安装本地包：

sudo dnf install ./客户端文件名.rpm

安装完成后，从应用菜单启动，再导入订阅或本地 YAML 文件。订阅地址应由服务提供方给出。客户端中的“更新订阅”通常只是重新下载配置，不等于更新客户端或代理内核，这三类更新需要分别确认。

桌面端首次检查

  1. 在配置页面确认订阅已经解析出节点和策略组。
  2. 打开日志，检查监听端口是否成功创建。
  3. 选择需要使用的策略节点，避免策略组仍停留在不可用项。
  4. 根据接管范围选择系统代理或 TUN，不要在未授权时直接开启 TUN。
  5. 关闭客户端后检查系统代理是否恢复，避免桌面环境保留失效的本地端口。

GNOME、KDE、Xfce 对托盘图标和系统代理的处理并不完全一致。托盘图标消失不一定代表内核停止，应通过进程、监听端口和日志联合判断。Wayland 会话下，部分客户端的窗口或托盘实现还会受到桌面扩展和打包方式影响。

安装 mihomo 命令行内核

无图形服务器不需要桌面客户端。基本目录可以拆成三部分：可执行文件放在 /usr/local/bin，配置放在 /etc/mihomo，运行日志交给 systemd journal。这样升级内核时不会覆盖配置，也便于统一管理权限。

先创建配置目录。随后把已经下载并解压的、与当前架构匹配的二进制文件移动到目标位置：

sudo install -d -m 0750 /etc/mihomo
sudo install -m 0755 mihomo /usr/local/bin/mihomo
/usr/local/bin/mihomo -v

版本命令能正常输出，说明二进制至少可以在当前系统执行。如果出现 Exec format error，优先检查 CPU 架构。如果提示找不到文件但路径确实存在，还应检查压缩包是否完整解压、动态链接要求是否满足，以及文件是否位于禁止执行的挂载点。

正式建立服务前，建议在前台进行一次启动测试。把配置保存为 /etc/mihomo/config.yaml 后运行：

sudo /usr/local/bin/mihomo -d /etc/mihomo

-d 指定工作目录。内核会从该目录读取主配置，并可能在其中保存缓存、规则数据或其他运行文件。前台启动便于直接观察 YAML 解析、端口占用、规则下载和 DNS 初始化错误。确认运行正常后按 Ctrl+C 停止，再切换到 systemd。

配置目录、订阅与最小启动配置

订阅通常返回一份完整 YAML，也可能返回经过服务端转换的配置。保存前应确认响应内容确实是配置文本，而不是登录页面、错误消息或访问验证页面。直接把 HTML 内容写成 config.yaml，内核会在启动时报告解析错误。

以下配置用于说明本地端口和控制接口的基本关系，并不是完整订阅。实际代理节点、策略组和规则应来自有效配置：

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

external-controller: 127.0.0.1:9090
secret: "设置一个仅供本机管理使用的口令"

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false

proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

mixed-port 同时接受 HTTP 和 SOCKS5 代理连接，便于命令行工具统一设置。allow-lan: false 表示不向局域网设备开放代理。若确实需要为局域网提供服务，应同时配置监听地址、防火墙规则和访问边界，不能只打开该开关。

external-controller 是控制接口，不是普通代理端口。需要搭配面板时，应限制它的监听范围并设置 secret。将控制接口暴露到所有网络接口会扩大管理面，服务器部署应优先监听回环地址，再通过受控的管理通道访问。

从订阅取得配置后，可以先备份现有文件，再原子替换。内核重新加载前先检查文件权限：

sudo cp /etc/mihomo/config.yaml /etc/mihomo/config.yaml.bak
sudo chown root:mihomo /etc/mihomo/config.yaml
sudo chmod 0640 /etc/mihomo/config.yaml

如果服务账户需要在配置目录写入缓存或下载规则集，目录所属组也要允许相应操作。权限设置过严会导致规则提供器无法更新；权限设置混乱则容易出现手动启动正常、systemd 启动失败的差异。

使用 systemd 托管 mihomo

systemd 可以在开机时启动内核，并统一处理重启、状态和日志。先创建低权限系统用户。该账户不需要登录 shell，也不需要主目录：

sudo useradd --system --no-create-home --shell /usr/sbin/nologin mihomo
sudo chown -R mihomo:mihomo /etc/mihomo

在 /etc/systemd/system/mihomo.service 写入以下服务单元。此基础版本适用于 HTTP、SOCKS 和规则分流。若配置启用了 TUN，还需要额外处理网络能力和设备权限。

[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
systemctl status mihomo --no-pager

检查日志时使用 journalctl。首次启动建议查看完整近期日志，持续排障时再跟随输出：

journalctl -u mihomo -n 100 --no-pager
journalctl -u mihomo -f

修改 YAML 后可以执行 sudo systemctl restart mihomo。重启前最好先在前台测试副本，避免配置语法错误导致服务中断。若只修改订阅中的策略选择，还要确认该客户端或控制面板是否把选择结果写入缓存，而不是写回 YAML。

TUN 模式的 systemd 权限

TUN 会创建虚拟网络接口并修改路由，需要比普通本地代理更高的网络权限。在服务单元的 [Service] 区段加入能力限制，比直接让整个服务长期以 root 身份运行更容易控制权限范围：

AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW

同时确认系统存在 /dev/net/tun，内核模块可用，服务账户可以访问该设备。容器或受限虚拟机还需要宿主平台允许 TUN 设备和网络管理能力。配置里开启 TUN 并不代表运行环境已经提供这些条件。

不同发行版的 systemd 安全策略、SELinux 或 AppArmor 规则可能继续限制网络操作。日志中的 permission denied 应结合内核审计记录判断，不要反复扩大目录权限来处理网络能力问题。

让终端、软件包管理器和远程会话使用代理

mihomo 监听端口成功后，应用仍需把请求送到该端口。系统代理、环境变量和 TUN 是三条不同路径。命令行服务器最常用环境变量；桌面程序通常读取桌面环境的系统代理；不遵循代理设置的程序才需要考虑 TUN。

当前终端临时设置

假设 mixed-port 为 7890，当前 shell 可以这样设置：

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="127.0.0.1,localhost,::1"

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

socks5h 中的 h 表示让代理端处理目标主机名解析，适合支持该写法的工具。并非所有程序都会读取同一组变量，因此同时设置大小写形式可以提高命令行工具的兼容性。退出当前 shell 后，这些临时变量就会失效。

如果把变量写入 ~/.profile 或 shell 初始化文件，每次登录都会生效。但服务停止时，所有读取这些变量的程序仍会尝试连接本地端口。长期服务器环境更适合用单独脚本按需启用和清除代理：

unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

APT、DNF 与 Git

APT 和 DNF 通常可以继承执行环境中的代理变量，但通过 sudo 运行时，环境变量可能被安全策略清除。需要长期配置时，应使用软件自身的代理配置文件，并限制只影响必要的源。Git 可按用户设置 HTTP 代理：

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

清除 Git 设置时执行：

git config --global --unset http.proxy
git config --global --unset https.proxy

SSH 不会自动读取 HTTP 代理变量。通过 SSH 拉取仓库时，连接路径由 SSH 配置和代理命令决定，不能用浏览器访问正常来推断 SSH 一定正常。

远程服务器上的访问边界

通过 SSH 管理远程服务器时，127.0.0.1:7890 指的是远程服务器自身，而不是管理员电脑。若 mihomo 运行在本地电脑，需要使用 SSH 端口转发把代理端口送到远程端；若 mihomo 安装在服务器，就应让应用连接服务器本机监听端口。不要把回环地址和局域网地址混为一处。

启动失败、端口冲突与 DNS 排查

服务反复重启

先执行 systemctl status mihomo 查看退出码，再读取最近 100 行日志。YAML 缩进错误、字段类型错误、配置文件不可读和工作目录不可写都可能触发启动失败。systemd 的自动重启会让日志快速滚动，因此应先停止服务，再用相同账户前台运行：

sudo systemctl stop mihomo
sudo -u mihomo /usr/local/bin/mihomo -d /etc/mihomo

这一步可以暴露“root 手动运行正常、服务账户运行失败”的权限差异。修复后再启动服务，不要把临时测试实例与 systemd 实例同时保留。

端口已经被占用

使用 ss 检查监听端口及对应进程：

sudo ss -lntup | grep -E '7890|7891|9090|1053'

常见冲突来自另一个 Clash 图形客户端、旧的 mihomo 进程或其他本地代理。应停止重复实例或修改端口，并同步更新环境变量、桌面系统代理和控制面板地址。只修改 YAML 而不修改应用侧代理地址，会表现为内核运行正常但请求全部失败。

节点存在但无法连接

先看日志中的失败阶段。域名解析失败、连接超时、TLS 握手失败和认证失败代表不同问题。确认服务器时间准确，检查订阅是否过期，再测试策略组当前选择。规则模式下，还要查看请求最终命中了哪个规则和策略，避免把规则分流问题误判成节点不可用。

如果只有局部域名异常，应检查 DNS 配置、规则集更新状态和 IPv6 路径。配置里关闭 IPv6 只影响内核相关解析与连接选择，不一定会关闭操作系统所有 IPv6 行为。桌面浏览器还可能启用自己的安全 DNS，需要分别核对浏览器、系统和 mihomo 的解析路径。

系统代理已开但部分程序直连

系统代理只是桌面环境提供的代理参数。浏览器和多数桌面应用会读取它，但游戏、容器、部分命令行程序和自行实现网络栈的软件可能忽略该设置。此时先尝试程序自身的代理选项或环境变量；确实需要接管更多流量时，再部署 TUN。

Docker 容器中的 127.0.0.1 指容器自身。容器要访问宿主机代理，应使用可达的宿主地址，并确认 mihomo 监听范围和防火墙允许该来源。开启 allow-lan 后还需评估监听接口，不应把代理端口直接暴露到不受控制的公网接口。

升级、备份与日常维护

命令行内核升级应把二进制和配置分开处理。先记录当前版本，停止服务，替换 /usr/local/bin/mihomo，再次检查版本输出，然后启动服务并观察日志。配置格式发生变化时，应先阅读对应版本说明，在测试环境验证后再替换生产实例。

建议备份以下内容：主配置、手工维护的覆写规则、systemd 服务单元以及环境变量脚本。缓存数据库和自动下载的规则集通常可以重新生成，但如果策略选择依赖缓存，删除工作目录可能使策略组恢复默认值。

服务器长期运行时，可定期检查以下状态：

  • systemctl is-active mihomo 是否返回运行状态。
  • 本地代理、DNS 和控制端口是否只监听预期地址。
  • 日志是否持续出现规则下载失败、DNS 超时或连接重试。
  • 订阅更新时间与节点可用状态是否符合预期。
  • TUN 路由在服务重启后是否正确恢复。
  • 软件包升级后，服务账户、设备权限和安全策略是否发生变化。

继续安装与配置

先选择匹配 Linux 架构与使用环境的客户端，再按快速上手完成订阅导入、策略选择和代理模式设置。

前往下载页 查看快速上手
下载Clash