Linux 用 Clash 的兩條路線:桌面客戶端安裝與命令列內核部署

Linux 上 Clash 的兩條部署路線怎麼選

嚴格來說,「Clash」在今天更多指代生態而不是單一軟體——底層跑的引擎是 mihomo(前身為 Clash Meta,原版 Clash 內核已停止更新),上層可以套一個帶圖形介面的桌面客戶端,也可以直接把內核二進位檔案丟到系統裡當服務跑。兩條路線的差異不只是「有沒有介面」,而是使用場景本身就不同:

• 桌面客戶端路線:適合日常用 Ubuntu、Fedora、Debian 等發行版跑桌面環境(GNOME、KDE 等)的場景,圖形介面裡切節點、看規則日誌、開關 TUN 模式都是滑鼠點擊,上手成本最低,代表產品是 Clash Verge Rev 和 FlClash。
• 命令列內核路線:適合沒有圖形介面的伺服器、NAS、旁路由、雲端主機,或者你就是想把 Clash 變成一個開機自啟的後台服務,不需要也不方便打開視窗操作,靠一份 config.yaml 加 systemd 單元檔案長期掛機。

兩條路線用的是同一個 mihomo 內核,規則語法、訂閱格式完全通用,差異只在「誰負責把內核跑起來、誰負責暴露控制面板」。如果你的 Linux 機器同時兼顧日常上網和長期掛機(比如一台常年開著的迷你主機),完全可以兩條路線都裝,按需切換。

桌面客戶端路線:Clash Verge Rev 與 FlClash 安裝要點

桌面客戶端路線裡,Clash Verge Rev 和 FlClash 是目前 Linux 桌面上維護活躍、開源可查的兩個選擇,底層都套著 mihomo 內核,介面風格和依賴體積略有差異。

Clash Verge Rev:主流發行版通吃

Clash Verge Rev 官方發布 .deb、.rpm 和 .AppImage 三種打包形式,基本涵蓋了 Debian/Ubuntu 系、Fedora/openSUSE 系,以及任何發行版都能跑的 AppImage 通用格式。安裝要點:

1. Debian/Ubuntu 系用 dpkg -i 裝 .deb 包,遇到依賴缺失報錯時補一句 apt --fix-broken install 即可。
2. Fedora/openSUSE 系用 rpm -i 或對應套件管理器安裝 .rpm 包。
3. 不想裝系統套件、只想暫時跑一下的場景,給 AppImage 檔案加執行權限後直接雙擊或命令列執行:chmod +x Clash-Verge-Rev.AppImage && ./Clash-Verge-Rev.AppImage。
4. 首次啟動如果提示 TUN 模式需要額外授權,按介面引導執行一次帶 sudo 的輔助程序安裝,之後開關 TUN 就不需要每次輸密碼。

FlClash:輕量跨平台的另一種選擇

FlClash 基於 Flutter 構建,同樣提供 Linux 的 .deb 和 .AppImage 包,介面更簡潔,資源佔用相對更小,適合配置不算高的桌面機或虛擬機環境。安裝方式與 Clash Verge Rev 類似,解壓或安裝後直接執行,首次進入需要手動匯入訂閱連結或本地設定檔。

兩者安裝完成後的使用邏輯基本一致:匯入訂閱連結 → 選一個代理模式(規則/全域/直連)→ 需要時開啟 TUN 模式接管全域流量 → 在節點清單裡選組切換。具體的圖形介面操作步驟和各平台通用的排坑清單,可以參考本站另一篇關於首次安裝設定的文章。

命令列路線:直跑 mihomo 內核的完整步驟

命令列路線跳過一切圖形介面,直接管理 mihomo 二進位檔案本身。整套流程分三步:下載對應架構的二進位檔、準備設定檔、手動跑一次驗證沒問題。

第一步:下載對應 CPU 架構的二進位檔

mihomo 官方發布頁會區分 amd64、arm64、armv7 等架構,先用以下命令確認自己機器的架構再下載對應版本:

uname -m
# x86_64 對應 amd64;aarch64 對應 arm64

下載後的檔案通常是 .gz 壓縮包,解壓並賦予執行權限,再放進一個固定目錄方便後續 systemd 引用:

gunzip mihomo-linux-amd64.gz
chmod +x mihomo-linux-amd64
sudo mkdir -p /etc/mihomo
sudo mv mihomo-linux-amd64 /usr/local/bin/mihomo

第二步:準備設定檔

把訂閱轉換出的 config.yaml 放進 /etc/mihomo/ 目錄,至少要確認以下幾個欄位是自己需要的值:

• port / socks-port:HTTP 與 SOCKS5 本地代理埠。
• allow-lan:如果這台機器要給區域網路內其他設備提供代理,設為 true。
• mode:rule(按規則分流)、global(全部走代理)或 direct(全部直連)。
• external-controller:控制面板監聽位址,例如 127.0.0.1:9090,搭配 secret 欄位設一個存取金鑰。

第三步:手動跑一次驗證

先不接 systemd,直接在終端機裡跑一次,確認設定能正常載入、沒有語法錯誤:

mihomo -d /etc/mihomo

看到日誌裡出現規則載入成功、監聽埠開啟的提示,沒有報錯刷屏,就說明設定檔是可用的,可以進入下一步做成常駐服務。

用 systemd 守護 mihomo 服務並驗證連通性

手動跑通之後,下一步是讓 mihomo 開機自啟、崩潰自動重啟,這一步交給 systemd 最省心。新建一個單元檔案:

sudo nano /etc/systemd/system/mihomo.service

寫入以下內容(按實際路徑調整):

[Unit]
Description=mihomo Clash kernel service
After=network.target

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

[Install]
WantedBy=multi-user.target

儲存後依次執行以下命令啟用並啟動服務:

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

systemctl status 顯示 active (running) 就說明服務已經常駐。日常排錯和查日誌推薦用:

journalctl -u mihomo -f

驗證連通性可以直接用 curl 走本地代理埠測試:

curl -x socks5h://127.0.0.1:7890 https://www.google.com -I

返回正常的 HTTP 狀態行,說明代理鏈路已經通了。如果需要看目前生效的節點、流量和規則匹配情況,可以在瀏覽器打開 external-controller 設定的位址(如 http://127.0.0.1:9090/ui),搭配開源的 Web 控制面板專案查看,不需要額外裝桌面客戶端。

兩條路線的訂閱更新與日常維護差異

選好路線之後,長期維護的方式也不一樣,提前了解可以少踩一些坑。

桌面客戶端路線的訂閱更新一般在介面裡就有「更新訂閱」按鈕,支援設定自動更新間隔,規則集、節點清單更新後立即生效,不需要重啟客戶端本身。切換節點、暫時改分流模式都是點擊操作,適合需要頻繁調整的日常使用。

命令列內核路線沒有按鈕,更新訂閱通常靠一條定時任務(crontab)去重新下載最新的 config.yaml 並覆蓋舊檔案,再執行一次 systemctl restart mihomo 讓新設定生效。如果不想每次更新都重啟行程打斷已有連線,也可以研究 mihomo 提供的設定熱重載介面(透過 external-controller 面板發起重載請求),避免服務中斷。

無論走哪條路線,設定檔的規則語法都是通用的——同一份 config.yaml 理論上可以在桌面客戶端和命令列內核之間直接複用,只是桌面客戶端往往會在匯入時自動補一層圖形化的分組和面板設定。如果你同時維護一台桌面機和一台常駐伺服器,不妨保留同一份規則來源,減少兩邊設定不一致帶來的排錯成本。