平台部署 预计阅读 14 分钟

Linux 部署 Clash：桌面客户端与无桌面 mihomo 服务配置

分别梳理图形客户端和命令行内核的部署路径，解释配置目录、systemd 服务、代理环境变量与日志查看，避免混用两套入口。

先确定部署路径：桌面客户端还是 mihomo 服务

Linux 上常见的“安装 Clash”实际对应两条不同路径。第一条是在 GNOME、KDE Plasma、Xfce 等桌面环境中安装图形客户端，由客户端负责订阅导入、配置切换、内核启动、系统代理和日志展示。第二条是在服务器、软路由、开发机或没有桌面环境的主机上直接运行 mihomo 内核，再用 systemd 管理进程。两种路径可以使用相近的 YAML 配置，但操作入口、权限边界和故障定位方式并不相同。

部署方式 适用环境 配置入口 进程管理 流量接管
桌面客户端 日常桌面、开发工作站 客户端界面与配置目录 客户端自身 系统代理或 TUN
mihomo 服务 服务器、无桌面主机、旁路网关 手动维护 YAML 文件 systemd 环境变量、显式代理或 TUN

桌面客户端和 mihomo 不是两个可以互换称呼的产品层级。客户端提供界面、更新和配置管理，mihomo 是读取配置并执行代理、DNS 与规则的内核。某些客户端内置 mihomo，另一些客户端允许选择内核版本。若已经由桌面客户端启动内核，就不要再同时启动监听相同端口的 systemd 服务，否则通常会出现 address already in use。

Linux 桌面客户端：安装后先核对内核与配置目录

按发行版选择安装包

Debian、Ubuntu、Linux Mint 等系统通常使用 .deb，Fedora、RHEL 系列和 openSUSE 常见 .rpm，其他发行版可根据客户端提供情况选择 AppImage 或压缩包。下载前先用 uname -m 查看架构：输出 x86_64 对应 amd64 或 x64，输出 aarch64 对应 arm64。安装包格式与 CPU 架构必须同时匹配。

uname -m

# Debian、Ubuntu 安装本地 deb
sudo apt install ./client-linux-amd64.deb

# Fedora 安装本地 rpm
sudo dnf install ./client-linux-x86_64.rpm

首次启动后，先进入客户端的「设置」→「内核设置」或「设置」→「参数设置」，确认当前内核名称、内核版本和工作目录。不同客户端的菜单文字可能略有差异，判断重点是找到内核、配置目录、监听端口与日志四项。不要把“客户端版本”当成“内核版本”；排查规则或 DNS 兼容问题时，应记录两者。

导入订阅不等于流量已经进入代理

  1. 在「配置」或「订阅」页面粘贴订阅地址并执行导入。
  2. 选择刚导入的配置，等待客户端完成解析并启动内核。
  3. 在「代理」页面选择策略组；配置中的 PROXY 一般是策略组名称，不是固定内置出口。
  4. 按需要开启「系统代理」或「TUN 模式」，两者解决的流量范围不同。
  5. 查看日志，确认没有端口占用、YAML 解析或 DNS 初始化错误。

系统代理通常向桌面环境写入 HTTP 和 SOCKS 代理参数，适合遵循系统代理设置的浏览器与图形应用。TUN 模式通过虚拟网络接口接管更广范围的流量，可能需要管理员授权、网络能力或额外 DNS 设置。只导入订阅但没有启用任何流量入口时，内核即使正在运行，应用也不会自动使用它。

用端口确认客户端是否真正启动内核

Clash 系配置常把混合代理端口设为 7890，也可能分别使用 HTTP 7890 与 SOCKS 7891。这些只是常见值，最终应以当前配置和客户端设置为准。可以使用 ss 查看监听进程：

ss -lntp | grep -E '7890|7891|9090'

# 通过本机 HTTP 代理测试
curl -I -x http://127.0.0.1:7890 https://example.com

# 通过 SOCKS5，并让代理端解析域名
curl -I --proxy socks5h://127.0.0.1:7891 https://example.com

curl 成功而浏览器失败，通常应检查浏览器自己的代理扩展或桌面系统代理；浏览器成功而终端失败，则应检查终端环境变量。两类应用的代理入口可能完全独立，切换规则模式不能替代入口配置。

无桌面主机：准备 mihomo 二进制与工作目录

建立固定目录和专用账户

服务器部署应把二进制、配置和运行状态分开。下面示例将程序放在 /usr/local/bin/mihomo，主配置放在 /etc/mihomo/config.yaml，运行时数据放在 /var/lib/mihomo。专用系统账户可以限制普通代理服务的文件访问范围。

sudo install -m 0755 mihomo /usr/local/bin/mihomo
sudo useradd --system --home /var/lib/mihomo --shell /usr/sbin/nologin mihomo
sudo install -d -o mihomo -g mihomo /etc/mihomo
sudo install -d -o mihomo -g mihomo /var/lib/mihomo
sudo install -m 0640 -o mihomo -g mihomo config.yaml /etc/mihomo/config.yaml

部分发行版的 nologin 位于 /sbin/nologin，可以先执行 command -v nologin 确认路径。若配置引用 GeoIP、GeoSite、规则集或证书文件，还要保证 mihomo 账户对相应文件具有读取权限。配置中使用相对路径时，路径通常以 mihomo 的工作目录为基准，因此 systemd 中的 WorkingDirectory 与启动参数需要保持一致。

先做配置测试，再交给 systemd

sudo -u mihomo /usr/local/bin/mihomo \
  -t \
  -d /var/lib/mihomo \
  -f /etc/mihomo/config.yaml

-t 用于测试配置，-d 指定运行目录，-f 指定配置文件。测试通过只说明配置能够被当前内核解析，不代表所有节点都可连接，也不代表系统流量已经进入代理。升级 mihomo 或修改规则提供器后，应重复执行测试，再重启服务。

使用 systemd 管理 mihomo 服务

基础代理服务单元

只提供 HTTP、SOCKS 或 mixed-port 时，通常不需要 TUN 权限。创建 /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=/var/lib/mihomo
ExecStartPre=/usr/local/bin/mihomo -t -d /var/lib/mihomo -f /etc/mihomo/config.yaml
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
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
sudo journalctl -u mihomo -n 100 --no-pager

ExecStartPre 会在每次启动前验证 YAML。若测试失败，主进程不会启动，旧进程在执行重启操作时仍可能已经退出，因此生产环境修改配置前仍应先手动运行测试命令。Restart=on-failure 适合处理异常退出，但不会修正无效配置或被其他进程占用的端口。

开启 TUN 时再增加网络能力

mihomo 的 TUN 配置常见结构如下。具体可用字段取决于当前 mihomo 版本及系统网络栈，迁移旧配置时应以所用版本的文档为准。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

使用专用账户运行 TUN 时，服务通常需要 CAP_NET_ADMIN，并且主机需要提供 /dev/net/tun。可以在服务的 [Service] 段加入：

AmbientCapabilities=CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_ADMIN
DeviceAllow=/dev/net/tun rw

修改服务后执行 sudo systemctl daemon-reload 和 sudo systemctl restart mihomo。随后用 ip link、ip route 与服务日志检查虚拟接口和路由。容器环境还需要宿主机向容器开放 TUN 设备及网络管理能力；仅在容器内修改 YAML，无法突破宿主机的设备与能力限制。

代理环境变量：让终端程序使用 mihomo

当前终端临时生效

没有开启 TUN 时，命令行程序通常需要显式代理。假设 mihomo 在本机监听 mixed-port 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

curl -I https://example.com

变量名同时存在大写和小写写法，不同程序读取习惯不完全一致。需要兼容特定工具时，可以同步设置 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 与 NO_PROXY。但 CGI 等环境对大写 HTTP_PROXY 有额外安全约束，服务器全局设置前应确认实际运行场景。

socks5h 中的字母 h 表示由 SOCKS 代理端处理域名解析。使用 socks5 时，应用可能先在本地解析域名，再把 IP 交给代理，这会改变 DNS 路径。诊断 DNS 问题时，应明确记录使用的是 socks5 还是 socks5h。

Git、APT 与 systemd 服务分别配置

Git 可以使用自身配置，而不依赖当前 shell：

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

# 查看
git config --global --get http.proxy

# 删除
git config --global --unset http.proxy
git config --global --unset https.proxy

APT 可在 /etc/apt/apt.conf.d/80proxy 中指定代理：

Acquire::http::Proxy "http://127.0.0.1:7890";
Acquire::https::Proxy "http://127.0.0.1:7890";

如果另一个 systemd 服务需要经过 mihomo，不要假定它会继承登录 shell 的变量。使用 systemctl edit 服务名 创建覆盖配置：

[Unit]
After=mihomo.service
Wants=mihomo.service

[Service]
Environment="HTTP_PROXY=http://127.0.0.1:7890"
Environment="HTTPS_PROXY=http://127.0.0.1:7890"
Environment="NO_PROXY=localhost,127.0.0.1,::1"

保存后执行 sudo systemctl daemon-reload 并重启目标服务。注意 After 只约束启动顺序，Wants 表示弱依赖；它们不会等待 mihomo 的某个代理节点完成连通性检测。对启动阶段必须联网的任务，可以增加应用自身的重试机制。

配置端口、规则与控制接口

最小监听配置的边界

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

external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-secret"

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

mixed-port 同时接受 HTTP 与 SOCKS 连接。allow-lan: false 适合只给本机使用的场景；若确实需要局域网设备访问，应同时配置监听地址、防火墙和访问边界。external-controller 是控制接口，不是代理端口，示例绑定到回环地址 127.0.0.1:9090。控制密钥应改成实际随机值，并避免把控制接口直接暴露到不受信任网络。

规则按顺序求值，第一条匹配项决定去向。DIRECT 表示直连，REJECT 表示拒绝，PROXY 必须对应配置中已经定义的策略组。no-resolve 表示该 IP 规则不主动触发域名解析，并不等于关闭全部 DNS。

订阅维护与本地覆写分开

图形客户端通常有自己的订阅缓存、运行配置和覆写机制，手工修改生成后的运行文件可能在下次更新时被覆盖。无桌面 mihomo 则不会自动理解某个订阅网址等同于完整生产配置；应由单独的更新脚本、配置生成工具或代理提供器完成下载与转换，再执行测试、替换和重载。

  1. 把远程内容下载到临时文件，而不是直接覆盖当前配置。
  2. 检查策略组名称、规则引用、DNS 字段和规则提供器路径。
  3. 使用当前运行的 mihomo 二进制执行 -t 测试。
  4. 测试通过后原子替换配置文件。
  5. 重启服务，并检查最近 100 行日志与监听端口。

日志与故障排查：从进程、端口、入口逐层确认

systemd 服务启动失败

systemctl status mihomo --no-pager
sudo journalctl -u mihomo -b --no-pager
sudo journalctl -u mihomo -f
  • 出现 YAML 行号或字段错误：先运行配置测试，检查缩进与当前内核支持的字段。
  • 出现 permission denied：核对配置、规则集、运行目录以及 /dev/net/tun 权限。
  • 出现 address already in use：使用 ss -lntp 找出占用 7890、7891 或 9090 的进程。
  • 服务不断重启：查看第一次失败的日志，不要只观察重启计数。
  • TUN 启动失败：确认内核模块、设备节点、systemd capability 和路由权限。

端口存在，但请求仍然失败

先用本地代理请求排除应用配置问题，再检查 mihomo 日志中的连接目标、匹配规则和最终策略。若日志完全没有出现该请求，流量通常没有到达代理端口；若日志出现请求但策略不符合预期，应检查规则顺序与策略组选择；若策略正确但连接超时，再检查节点可用性、服务器时间、DNS 和上游网络。

# HTTP 代理入口
curl -v -x http://127.0.0.1:7890 https://example.com

# SOCKS 代理入口，远端解析域名
curl -v --proxy socks5h://127.0.0.1:7890 https://example.com

# 查看本机路由
ip route

# 查看 DNS 状态，适用于 systemd-resolved
resolvectl status

若 mihomo 运行在另一台主机，把测试地址改成那台主机的局域网 IP，并确认 allow-lan、监听地址和防火墙规则。不要把控制端口 9090 当成 HTTP 代理端口使用，也不要把 SOCKS URL 写成 HTTP URL。

桌面客户端与 systemd 冲突

同一台 Linux 工作站既安装桌面客户端又配置 systemd 服务时，建议只让其中一个负责常驻运行。可以执行 systemctl disable --now mihomo 暂停系统服务，再启动桌面客户端；或者退出桌面客户端并确认其内核进程结束后，启动 systemd。只关闭客户端窗口未必等于退出托盘进程，应再次检查监听端口和进程命令行。

部署完成后的检查清单

  • 记录客户端版本与 mihomo 内核版本，明确当前由谁启动内核。
  • 确认配置文件、运行目录、规则集文件都可被运行账户读取。
  • 使用 mihomo -t 测试当前配置。
  • 使用 ss -lntp 确认代理端口和控制端口没有冲突。
  • 使用 curl -x 或 curl --proxy 验证显式代理入口。
  • 按应用分别设置终端变量、Git、APT 或 systemd 环境变量。
  • 启用 TUN 后检查虚拟接口、默认路由、DNS 与 SSH 回程路径。
  • 更新订阅或内核后重新测试配置，并查看启动日志。

Linux 桌面部署的核心是让客户端统一管理配置、内核和系统入口；无桌面部署的核心是把 mihomo 当成普通系统服务管理。只要始终区分“配置已导入”“内核已监听”“应用已指向代理”和“TUN 已接管流量”这四个状态，就能避免大多数端口冲突与代理不生效问题。

下载Clash 按平台选择客户端