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

选择桌面客户端或命令行内核

Linux 上的 Clash 部署通常分为两条路径。桌面客户端适合带 GNOME、KDE Plasma、Xfce 等图形环境的工作站，可以在界面中导入订阅、切换策略组、查看连接记录，并通过托盘菜单控制系统代理。mihomo 命令行内核适合服务器、软路由、开发容器宿主机以及希望由 systemd 统一管理进程的用户。

mihomo 是兼容 Clash 配置体系并持续扩展功能的内核。常见的 Clash 规则、策略组、代理节点、DNS 与 TUN 配置都由内核执行，桌面客户端则在内核之上提供配置管理界面。两者不是必须同时运行的两个代理层：多数桌面客户端已经携带或管理内核，再额外启动一个系统级 mihomo，容易出现端口占用、控制端口冲突或系统代理反复切换。

安装 Linux 桌面客户端

下载前先确认处理器架构。终端执行 uname -m，常见结果为 x86_64、aarch64 或 arm64。安装包中的 amd64、x64 通常对应 x86_64，arm64 对应 64 位 ARM。架构不匹配时，程序通常会直接报告无法执行二进制文件，而不是进入客户端界面。

桌面发行版常见安装格式包括 AppImage、DEB 和 RPM。选择客户端时，应优先确认其当前维护状态、支持的内核类型、配置存储位置以及是否具备 Linux 系统代理和 TUN 管理能力。不同客户端对订阅覆写、内核更新和权限提权的实现并不相同，迁移时不要直接假设界面选项完全一致。

AppImage 运行方式

AppImage 不依赖传统软件包安装流程。下载与当前架构匹配的文件后，添加执行权限，再从终端启动。以下命令中的文件名需要替换成实际下载文件名：

mkdir -p "$HOME/Applications"
mv "$HOME/Downloads/客户端文件.AppImage" "$HOME/Applications/"
chmod +x "$HOME/Applications/客户端文件.AppImage"
"$HOME/Applications/客户端文件.AppImage"

如果双击没有反应，应从终端运行一次并读取错误输出。部分发行版需要提供 FUSE 兼容组件；某些新 AppImage 也可以直接使用自身支持的解包模式。不要仅依据“图标未出现”判断安装失败，窗口系统、托盘扩展和桌面入口缓存都可能影响显示。

DEB 与 RPM 安装方式

Debian、Ubuntu 及其衍生系统可使用 APT 安装本地 DEB 包。APT 会同时处理软件包声明的依赖：

cd "$HOME/Downloads"
sudo apt install ./客户端文件.deb

Fedora、Rocky Linux 等使用 RPM 包的系统，可以通过 DNF 安装本地文件：

cd "$HOME/Downloads"
sudo dnf install ./客户端文件.rpm

安装完成后，从应用菜单启动客户端。第一次运行时先查看内核状态，再导入订阅或本地 YAML 配置。若客户端提供“设置为系统代理”选项，它通常只修改当前桌面会话的代理设置，不等同于透明接管所有进程。终端程序、容器和以系统服务身份运行的软件是否读取桌面代理，需要分别确认。

部署 mihomo 命令行内核

命令行部署的核心是三个对象：可执行文件、工作目录和配置文件。建议将可执行文件放在 /usr/local/bin/mihomo，将系统级配置放在 /etc/mihomo/。这样可以把程序升级与配置维护分开，也便于 systemd 使用固定路径启动。

从可信发布渠道取得与架构匹配的压缩包，解压后将二进制文件重命名为 mihomo。假设文件已经解压到当前目录，可以执行：

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

mihomo -v 应输出内核版本和构建信息。如果出现 Exec format error，通常是下载架构错误；如果提示没有执行权限，应检查文件模式及所在文件系统是否使用了 noexec 挂载选项。

首次部署不要立即写入复杂的 DNS、脚本和 TUN 规则。先用一份能够解析的基础配置确认端口与节点可用，再逐项加入高级设置。mihomo 可以通过 -d 指定工作目录，目录中的 config.yaml 会作为默认配置加载：

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

前台启动适合首次检查。终端会持续显示配置解析、监听端口、代理连接和规则匹配信息。确认配置可以启动后，再按后文创建 systemd 服务，避免服务反复重启掩盖首个错误。

配置目录、订阅文件与基础端口

最简单的目录只包含 /etc/mihomo/config.yaml。启用 GeoIP、规则集或其他外部资源后，工作目录还可能出现数据库、缓存和下载文件。运行服务的用户必须能够读取配置，并对需要更新的缓存位置拥有写权限。配置中若包含订阅凭据或控制接口密钥，应限制目录和文件权限。

sudo install -m 0640 config.yaml /etc/mihomo/config.yaml
sudo chmod 0750 /etc/mihomo
sudo ls -la /etc/mihomo

用于本机测试的基础配置可以包含混合代理端口、局域网访问开关、运行模式和控制接口。下面只展示结构，代理节点与规则应来自实际可用的 Clash 或 Mihomo 配置：

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: true

external-controller: 127.0.0.1:9090
secret: "请设置随机且足够长的控制密钥"

proxies: []
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,PROXY

mixed-port 同时接受 HTTP 与 SOCKS5 连接，便于浏览器、终端工具和开发软件共用一个端口。allow-lan: false 表示先限制为本机使用。即使 bind-address 写为通配地址，只要未允许局域网访问，也不应把它当作已经完成共享配置。

external-controller 是控制接口，不是普通代理端口。只在本机管理时应绑定到 127.0.0.1，并设置控制密钥。若确实需要远程管理，还应同时规划防火墙、可信网络范围与访问认证，不应直接把控制端口暴露到不受信任的网络。

导入订阅时保留回退文件

图形客户端通常会自行维护订阅 URL、更新间隔与本地配置副本。命令行部署则需要明确由谁负责更新。可以通过受控脚本取得配置，先保存为临时文件，调用内核进行配置检查，再替换正在使用的文件。不要在下载失败时直接覆盖原有 config.yaml，否则一次空响应或认证失效就会导致服务下次重启失败。

订阅地址通常包含访问凭据，不适合直接写进可被其他用户读取的 shell 历史、服务日志或公开脚本。更稳妥的方式是把凭据放入权限受限的环境文件，更新任务只读取该文件，并限制更新结果的访问权限。若订阅提供方输出的是通用节点列表而不是 Clash YAML，还需要先经过兼容转换，不能把任意文本直接作为 mihomo 配置启动。

配置 systemd 服务与开机自启动

基础配置验证通过后，可以创建 /etc/systemd/system/mihomo.service。下面的服务单元以系统级进程运行，并为可能使用的 TUN 功能保留网络管理能力。若只使用 HTTP 或 SOCKS 端口，可在确认配置需求后缩小能力范围。

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

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

保存后重新加载 systemd 配置，启动服务并设为开机启动：

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

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

sudo journalctl -u mihomo -b --no-pager
sudo journalctl -u mihomo -f

Restart=on-failure 只在异常退出时重启，适合暴露配置解析和运行错误。若服务不断重启，先执行 systemctl stop mihomo，再以前台方式启动同一配置目录，定位第一条错误。常见原因包括 YAML 缩进错误、监听端口已被占用、规则引用的策略组不存在、配置目录权限不足，以及 TUN 设备或网络能力不可用。

接入桌面系统代理、终端与 TUN 模式

内核运行并不代表所有流量已经自动经过代理。只配置 mixed-port: 7890 时，应用需要主动连接该端口。桌面环境可以把 HTTP、HTTPS 与 SOCKS 代理指向 127.0.0.1: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"

socks5h 表示域名解析也交给 SOCKS 代理端处理，但具体支持情况取决于应用。环境变量只对当前 shell 及其子进程生效。使用 sudo、systemd 服务、容器或图形启动器时，变量不一定会被继承，因此应在对应运行环境中单独配置。

TUN 模式的作用与前提

TUN 模式通过虚拟网络接口接管更多无法手动设置代理的流量，适合需要统一处理桌面应用、命令行工具和部分游戏连接的场景。它依赖 Linux 的 /dev/net/tun 设备、路由规则和相应网络管理能力。容器、精简内核或受限虚拟机可能没有开放 TUN 设备，即使配置语法正确也无法创建接口。

典型配置会在现有 DNS 方案确认可用后再启用：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true

auto-route 用于自动配置路由，auto-detect-interface 用于识别默认出口。auto-redirect 的实际支持效果与 Linux 网络环境、内核功能及 mihomo 版本有关。机器同时运行 Docker、Podman、VPN、NetworkManager 自定义路由或多张网卡时，应检查路由优先级与防火墙规则，避免把容器网段、内网地址或代理服务器自身连接错误地再次送回 TUN。

启用 TUN 后若出现域名无法解析，不要只反复切换节点。应分别检查 DNS 监听、上游 DNS 可达性、规则中的 DNS 策略、虚拟接口路由以及系统是否仍向其他本地解析服务发送请求。DNS 与 TUN 同时大幅调整会增加定位难度，建议先验证端口代理，再启用 DNS，最后加入 TUN。

启动检查与常见故障定位

部署完成后的检查顺序应从进程向外展开，而不是先依据网页能否打开作判断。第一步确认服务正在运行，第二步确认端口处于监听状态，第三步通过显式代理发起请求，第四步查看规则命中和节点连接日志，最后再启用系统代理或 TUN。

systemctl is-active mihomo
ss -lntup | grep -E '7890|9090'
curl --proxy http://127.0.0.1:7890 https://example.com/
journalctl -u mihomo -n 100 --no-pager

如果 7890 没有监听，先看配置解析和端口冲突。可以使用 ss -lntup 查找占用进程。若端口存在但请求失败，应观察日志中是 DNS 失败、连接超时、认证错误还是没有可用代理。策略组中显示节点并不代表节点一定可连接，最终仍要以连接日志和实际请求为准。

桌面客户端启动但无法接管流量

• 检查客户端内核是否处于运行状态，而不只是窗口已经打开。
• 确认当前配置已经激活，策略组没有指向失效或不可用节点。
• 检查桌面系统代理是否成功写入，并确认目标应用是否遵循系统代理。
• 若使用 TUN，确认提权流程完成、虚拟接口存在且路由没有被其他 VPN 覆盖。
• 退出其他代理客户端，避免多个程序同时修改代理与路由。

服务启动后立即退出

使用 journalctl -u mihomo -b 读取本次开机日志，并重点查看最早出现的错误。YAML 使用空格缩进，Tab 字符、层级错位或未正确引用的特殊字符都可能导致解析失败。规则指向不存在的策略组时，内核也可能拒绝加载配置。修改后先在终端前台运行，确认没有错误，再重新启动 systemd 服务。

局域网设备无法连接

共享代理需要同时满足四个条件：配置允许局域网访问、服务监听可被局域网访问的地址、主机防火墙放行对应 TCP 或 UDP 端口、客户端填写的是 Linux 主机的局域网地址而不是 127.0.0.1。还应确认无线网络没有启用客户端隔离。开放端口前应限定可信网段，并避免将代理端口暴露到公网接口。

Linux 部署完成后的维护清单

1. 记录当前内核来源、版本、架构和可执行文件路径。
2. 限制配置目录权限，妥善保存订阅凭据与控制接口密钥。
3. 确认只有一个实例占用计划中的代理、DNS和控制端口。
4. 为配置更新保留临时文件与回退副本，验证成功后再替换。
5. 升级前检查配置兼容变化，升级后查看启动日志和规则命中。
6. 使用 TUN 时记录额外路由、防火墙规则及与 VPN、容器网络的关系。
7. 不再使用桌面客户端时，同时恢复系统代理设置，避免留下失效端口。

桌面客户端的重点是选择仍在维护且适配当前发行版的界面，并理解系统代理与 TUN 的差别；命令行部署的重点是固定目录、先验证配置、再交给 systemd 管理。沿着“二进制文件—配置解析—端口监听—显式代理—系统接管”的顺序检查，可以把大多数 Linux 安装问题限定在明确环节。