Clash 在 Linux 下的兩條部署路線:桌面用戶端安裝與 mihomo 命令列運行

為什麼 Linux 部署要分兩條路線看

Windows 與 macOS 的 Clash 用戶端基本是「下載安裝檔、雙擊安裝、圖形介面設定」這一套固定流程,差異主要體現在系統權限彈窗上。Linux 則不同,原因在於生態本身的分裂:桌面發行版(Ubuntu、Debian、Fedora 桌面版等)有視窗系統和系統匣,能跑得動圖形用戶端;而雲端伺服器、NAS、路由器、Docker 容器這類無圖形環境,連顯示伺服器都不存在,任何依賴 GTK 或 Webview 的用戶端都無法啟動。

這也決定了兩條部署路線服務的是完全不同的使用場景。圖形用戶端 Clash Verge Rev 面向的是日常辦公、開發除錯這類需要頻繁切換節點、查看流量、調整規則的桌面場景,操作上追求直觀;而 mihomo 核心配合 systemd 面向的是長期掛機的伺服端場景,追求的是開機自動啟動、當機自動重啟、無人值守運行,不需要也不適合圖形互動。選路線之前先確認自己的系統有沒有圖形環境,是決定走哪條路的第一步。

路線一:deb 套件安裝 Clash Verge Rev(桌面環境)

Clash Verge Rev 是目前 Linux 桌面上維護活躍、介面完整度較高的圖形用戶端選擇,基於 Tauri 框架建構,資源占用比早期 Electron 方案更輕量。以 Ubuntu / Debian 系發行版為例,建議使用官方發布的 .deb 安裝檔,流程如下。

第一步:確認系統依賴

Tauri 應用依賴系統的 WebKitGTK 元件渲染介面,大多數桌面發行版預設已經安裝,但精簡安裝或最小化映像檔可能缺失。安裝前建議先手動補齊:

sudo apt update
sudo apt install -y libwebkit2gtk-4.1-0 libgtk-3-0 libayatana-appindicator3-1

第二步:安裝 deb 套件

下載對應架構(amd64 或 arm64)的安裝檔後,用 apt install 而不是 dpkg -i 直接安裝,前者會自動處理依賴關係,後者失敗後還需要手動補依賴:

cd ~/Downloads
sudo apt install ./clash-verge-rev_amd64.deb

安裝完成後可以在應用程式選單中找到 Clash Verge Rev 的圖示,首次啟動會請求寫入網路設定的權限提示,按提示授權即可。

第三步:匯入訂閱與驗證代理

啟動後在用戶端的訂閱管理介面貼上訂閱連結完成拉取,隨後進入代理頁面選擇節點。開啟系統代理或 TUN 模式後,可用以下指令驗證流量是否已經走代理出口:

curl -s https://ipapi.co/json/

回傳結果中的地理位置欄位若變為節點所在地區,說明代理鏈路已經生效。若命令列工具沒有走代理(命令列代理與瀏覽器代理走的是不同的系統設定項),需要額外設定 http_proxy 與 https_proxy 環境變數,或者直接在用戶端裡開啟 TUN 模式接管全域網路層流量,避免逐個工具單獨設定。

桌面路線的常見依賴問題

路線二:mihomo 核心 + systemd 常駐運行(無圖形環境)

伺服器、NAS、容器等無圖形環境不能安裝圖形用戶端,這類場景下通常直接運行 mihomo(Clash Meta 專案延續下的核心實作)二進位檔,再用 systemd 管理其生命週期,實現開機自動啟動與異常當機後的自動重啟。

第一步:下載並放置核心二進位檔

根據系統架構下載對應的 mihomo 二進位檔,解壓後放入系統可執行路徑,並賦予執行權限:

tar -zxvf mihomo-linux-amd64.tar.gz
sudo mv mihomo /usr/local/bin/mihomo
sudo chmod +x /usr/local/bin/mihomo

第二步:準備設定目錄與設定檔

建議將設定檔統一放在 /etc/mihomo/ 下,便於 systemd 服務統一讀取路徑,也方便後續多份設定的管理:

sudo mkdir -p /etc/mihomo
sudo cp config.yaml /etc/mihomo/config.yaml

設定檔中需要確認 mixed-port(混合代理埠)、external-controller(外部控制 API 位址)兩個欄位是否符合無圖形環境下的使用習慣。由於沒有圖形介面查看流量與切換節點,通常會開啟 external-controller,配合瀏覽器存取的第三方面板(如 metacubexd)遠端管理節點選擇。

mixed-port: 7890
external-controller: 0.0.0.0:9090
secret: "設定一個存取密碼"

第三步:編寫 systemd 服務單元

新建服務檔案 /etc/systemd/system/mihomo.service,內容如下:

[Unit]
Description=mihomo Daemon
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNPROC=500
LimitNOFILE=1000000
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW

[Install]
WantedBy=multi-user.target

其中 -d /etc/mihomo 表示以該目錄為工作目錄讀取設定;Restart=on-failure 保證核心程序異常結束後由 systemd 自動拉起;CAP_NET_ADMIN 與 CAP_NET_RAW 兩項能力是開啟 TUN 模式接管網路層流量所必需的權限,不用完全以 root 身分運行程序也能滿足需求,相對更安全。

第四步:啟用並檢查服務狀態

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

enable 指令設定開機自動啟動,status 指令確認程序是否處於 active (running) 狀態。若狀態顯示失敗,先查看詳細日誌定位問題:

journalctl -u mihomo -n 50 --no-pager

常見的啟動失敗原因集中在設定檔欄位格式錯誤、埠已被其他程序占用,或 TUN 模式缺少對應網路能力權限,日誌中通常會給出具體錯誤行號或欄位名稱,按提示逐條修正即可。

無圖形環境下如何管理節點與規則

沒有視窗介面並不代表只能盲跑,常見的管理方式有以下幾種,可以按自己熟悉程度組合使用。

• 第三方 Web 面板:開啟 external-controller 後,可以在同一區域網路內用瀏覽器存取該位址搭配一套開源 Web 面板,完成節點切換、延遲測試、規則查看等操作,體驗接近圖形用戶端。
• curl 呼叫控制 API:mihomo 的外部控制介面本質是一套 REST API,可以直接用 curl 發送請求查詢目前代理群組狀態或切換節點,適合寫進自動化腳本。
• 直接編輯設定檔後重啟服務:對規則、代理群組的調整可以直接修改 YAML 檔案,再用 systemctl restart mihomo 使其生效,適合改動頻率不高的固定環境。

訂閱更新方面,若設定檔裡寫了訂閱連結,可以配合 cron 排程定期拉取更新後自動重啟服務,避免節點資訊過期。需要注意的是自動更新腳本最好先做格式驗證,避免拉取到損毀的設定檔直接覆蓋導致服務重啟失敗。

兩條路線的選擇建議

如果日常使用場景是個人筆電或桌面工作站,能看到視窗和系統匣圖示,直接選圖形用戶端路線,操作門檻更低、也更符合大多數人的使用習慣,不需要記憶 systemd 指令。

如果場景是雲端伺服器、家用 NAS、路由器刷機環境或 Docker 容器,這些環境本身不具備圖形介面運行條件,只能走 mihomo 核心加 systemd 的路線,把設定維護、當機復原這類工作交給系統服務管理,再配合遠端 Web 面板完成日常的節點管理,是目前無圖形環境下較為穩妥的做法。

兩條路線並不互斥,同一使用者在不同裝置上完全可以並行使用:辦公筆電裝圖形用戶端,家裡的常駐伺服器跑 mihomo 加 systemd,兩者共用同一份訂閱,只是運行形態不同。