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