Linux 安裝 Clash 全流程:桌面用戶端與命令列 systemd 服務部署

兩條路線怎麼選

在動手之前先明確一件事:Linux 下「裝 Clash」根本不是單一操作,而是要先判斷自己所處的環境類型。桌面版 Linux(如 Ubuntu Desktop、Fedora Workstation、各類 Linux Mint 分支)有視窗管理器和系統匣,適合裝帶圖形介面的用戶端,日常切換節點、查看流量走的是點擊操作。伺服器版 Linux(雲端主機、NAS、家用閘道器)通常只有 SSH 連線,沒有桌面環境,只能靠純命令列的核心程式加行程管理工具讓代理常駐後台。

這兩條路線用的軟體形態完全不同:桌面路線用的是 Clash Verge Rev 這類基於 Tauri 框架打包的圖形用戶端,內部整合了 mihomo 核心,提供訂閱管理、規則編輯、流量圖表的可視化介面;命令列路線直接跑 mihomo 核心可執行檔,沒有介面,一切靠設定檔和終端機命令,再用 systemd 管理行程生命週期,確保機器重啟後自動拉起。

桌面環境:Clash Verge Rev 的 deb 包安裝

Clash Verge Rev 官方發行包裡針對 Debian/Ubuntu 系發行版提供了 .deb 安裝包,是目前桌面 Linux 上安裝門檻最低的方式,不需要手動設定依賴,雙擊或用 dpkg 安裝即可。以下是完整流程。

第一步:下載對應架構的安裝包

Linux 桌面主流是 x86_64(即 amd64)架構,少數 ARM 裝置(如某些國產筆記型電腦、Raspberry Pi 桌面套件)需要選 aarch64 架構的包。架構判斷可以執行:

uname -m
# 輸出 x86_64 → 選 amd64 包
# 輸出 aarch64 → 選 arm64 包

第二步:用 dpkg 安裝並處理依賴

下載好的 deb 包放到本地目錄後,執行安裝命令。deb 包本身不會自動拉取依賴,如果提示依賴缺失,緊接著用 apt 補齊即可:

sudo dpkg -i clash-verge-rev_*.deb
# 若報依賴錯誤,執行以下命令自動修復
sudo apt --fix-broken install

安裝完成後,應用程式會出現在應用程式選單裡,同時會在系統裡註冊一個使用者層級的後台輔助行程,用來處理系統代理設定與虛擬網路卡權限申請。首次啟動時,系統通常會彈出圖形化的密碼授權視窗,這是因為開啟 TUN 模式需要建立虛擬網路介面,必須要 root 權限才能建立,這一步是正常流程,不是安裝出錯。

第三步:設定開機自啟

Clash Verge Rev 的設定面板裡有「開機自動啟動」開關,打開後程式會透過桌面環境的自啟動機制(遵循 ~/.config/autostart/ 下的 .desktop 檔案規範)在使用者登入時自動拉起。如果開關無效,可以手動檢查該目錄下是否生成了對應的 desktop 檔案:

ls ~/.config/autostart/ | grep -i clash

如果沒有生成,可以從應用程式安裝目錄複製一份 desktop 檔案到這個路徑,或者在設定面板裡關閉再重新開啟一次自啟動開關,大多數情況下能重新觸發註冊流程。

其他發行版的安裝方式

非 Debian 系發行版有各自的處理方式:

• 基於 RPM 的發行版(Fedora、openSUSE):官方發行包同樣提供 .rpm 格式,用 sudo rpm -i 或 sudo dnf install 指向本地檔案即可安裝。
• Arch 系發行版:可以透過社群維護的 AUR 包管理,用 yay 或 paru 一類的 AUR 助手工具搜尋安裝,依賴會自動解析。
• 其他發行版或需要免安裝場景:官方也提供通用的 AppImage 格式,下載後賦予可執行權限直接執行,不寫入系統目錄,適合臨時測試或權限受限環境。

伺服器環境:mihomo 核心 + systemd 部署

伺服器上沒有桌面環境,不需要也不能裝圖形用戶端,直接部署 mihomo 核心(Clash Meta 專案的延續)是更合理的方式。核心本身是單一可執行檔,佔用資源極低,配合 systemd 管理後可以做到機器重啟後自動恢復代理服務,不需要人工干預。

第一步:規劃設定目錄

在部署之前先規劃好目錄結構,避免設定檔和程式本體混在一起,後續升級核心版本時不會誤刪設定:

/etc/mihomo/           # 設定檔目錄
  ├── config.yaml      # 主設定檔
  ├── geoip.dat         # GeoIP 資料庫
  └── geosite.dat       # GeoSite 資料庫
/usr/local/bin/mihomo   # 核心可執行檔

把核心可執行檔放進 /usr/local/bin 這類系統層級可執行目錄,設定檔獨立放在 /etc/mihomo,是 Linux 下軟體部署的通行慣例,便於用 systemd 統一管理,也方便後續手動排查設定問題時快速定位。

第二步:下載核心並賦予執行權限

mkdir -p /etc/mihomo
cd /usr/local/bin
# 假設已下載對應架構的核心壓縮包並解壓得到 mihomo 檔案
chmod +x mihomo
mihomo -v   # 驗證是否能正常執行並輸出版本號

伺服器架構判斷同樣用 uname -m,雲端主機絕大多數是 x86_64,部分海外便宜服務商或 ARM 雲端執行個體(如某些輕量應用伺服器)是 aarch64,下載前務必核對清楚,架構不符的可執行檔執行時會直接報錯退出。

第三步:準備設定檔

把訂閱轉換出來的 YAML 設定檔放到 /etc/mihomo/config.yaml,確認裡面的關鍵欄位沒有問題,尤其是 external-controller 這一項——伺服器環境下如果開放了這個位址且綁定在 0.0.0.0,相當於把核心的控制介面暴露給公開網路,必須設定存取密鑰或者只綁定本地位址:

external-controller: 127.0.0.1:9090
secret: "設定一個足夠複雜的密鑰"

第四步:編寫 systemd 服務單元

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

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

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

其中幾個欄位需要重點說明:-d /etc/mihomo 指定核心讀取該目錄下的設定檔;Restart=on-failure 表示行程異常退出時自動重啟,避免因為一次網路抖動導致代理服務徹底中斷;LimitNOFILE 調高檔案描述符上限,是因為代理服務需要同時維持大量並發連線,系統預設限制在高負載場景下容易觸發連線失敗。

第五步:啟用並啟動服務

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

enable 命令負責建立開機自啟的軟連結,這樣伺服器重啟後無需手動執行任何命令,mihomo 會隨系統一起拉起。status 命令用來確認目前執行狀態,重點看 active (running) 這一行是否正常。

權限要點與執行驗證

Linux 環境下部署代理最容易踩坑的地方集中在權限問題上,這裡單獨梳理清楚。

TUN 模式的權限需求

如果設定檔裡開啟了 tun.enable: true,核心需要建立虛擬網路介面並修改路由表,這個操作在 Linux 下必須要 CAP_NET_ADMIN 權限。以 root 身分執行 systemd 服務是最簡單的解決方式(如上文服務單元裡的 User=root),但如果出於安全考量不想讓代理行程以 root 權限常駐,也可以用 setcap 命令給可執行檔單獨授權,再用一般使用者身分執行:

sudo setcap cap_net_admin,cap_net_bind_service=+ep /usr/local/bin/mihomo

授權之後把服務單元裡的 User=root 改成專門為代理服務建立的一般使用者,進一步收緊權限範圍,是伺服器安全實踐裡更推薦的做法。

設定目錄的讀寫權限

如果用一般使用者執行服務,記得給設定目錄賦予對應使用者的讀取權限,否則核心啟動時會因為無法讀取設定檔而直接退出:

sudo chown -R clash-user:clash-user /etc/mihomo

驗證代理是否生效

服務啟動後,先確認連接埠是否正常監聽:

sudo ss -tlnp | grep mihomo

再透過命令列發起一次帶代理的請求,驗證出口 IP 是否變化:

curl -x http://127.0.0.1:7890 https://api.ip.sb/ip

如果回傳的 IP 是節點出口位址而不是伺服器本機位址,說明代理鏈路已經跑通。桌面環境下用 Clash Verge Rev 的話,直接看用戶端裡的連線狀態和延遲測試結果即可,不需要手動執行 curl 驗證。

日常維護建議

兩條路線部署完成後,日常維護重點略有不同,分別列一下。

桌面用戶端一側:Clash Verge Rev 內建了訂閱自動更新功能,可以在設定裡設定更新週期,不需要每次手動重新匯入訂閱連結;如果切換了多個訂閱來源,建議給每個設定檔重新命名成能一眼識別的名字,避免誤切到失效訂閱。

命令列服務一側:設定檔更新後,不需要重啟整個服務,mihomo 支援透過 RESTful API 觸發熱重載,或者直接用 systemctl restart mihomo 重啟服務生效;建議給設定目錄做定期備份,尤其是自訂規則較多的場景,一次誤操作覆蓋設定會導致規則全部遺失。

另外,無論哪條路線,GeoIP 與 GeoSite 資料庫都建議定期更新,資料庫過舊會導致分流規則誤判,出現「該走代理的網域沒走、該直連的位址反而走了代理」的情況,具體的更新方法和排查步驟可以參考資料庫更新相關的技術筆記。

兩條路線對照小結