平台部署 預計閱讀 12 分鐘

Linux 安裝 Clash 用戶端：桌面介面與命令列部署步驟

完整說明 Linux 桌面用戶端、mihomo 命令列核心、服務自動啟動與設定目錄的部署方式。

選擇桌面用戶端或命令列核心

在 Linux 上部署 Clash 通常有兩種方式。桌面用戶端適合使用 GNOME、KDE Plasma、Xfce 等圖形環境的工作站，可透過介面匯入訂閱、切換策略組、查看連線紀錄，並從系統匣選單控制系統代理。mihomo 命令列核心則適合伺服器、軟路由、開發容器主機，以及希望以 systemd 統一管理程序的使用者。

mihomo 相容於 Clash 設定體系，並持續擴充功能。常見的 Clash 規則、策略組、代理節點、DNS 與 TUN 設定都由核心執行，桌面用戶端則在核心之上提供設定管理介面。兩者不必同時作為兩層代理執行：多數桌面用戶端已內建或管理核心，若再額外啟動系統層級的 mihomo，容易造成連接埠占用、控制連接埠衝突或系統代理反覆切換。

使用環境 建議路徑 主要管理方式
個人 Linux 桌面 圖形用戶端 透過介面匯入訂閱、切換節點與系統代理
無桌面的伺服器 mihomo 命令列核心 設定檔、systemd 與日誌
開發工作站 依管理習慣擇一 環境變數、桌面代理或 TUN
區域網路代理入口 mihomo 服務 固定監聽位址、防火牆與存取控制

安裝 Linux 桌面用戶端

下載前先確認處理器架構。在終端機執行 uname -m，常見結果包括 x86_64、aarch64 或 arm64。安裝套件中的 amd64、x64 通常對應 x86_64，arm64 則對應 64 位元 ARM。架構不相容時，程式通常會直接回報無法執行二進位檔，而不會進入用戶端介面。

桌面版發行套件常見格式包括 AppImage、DEB 與 RPM。選擇用戶端時，應優先確認目前的維護狀態、支援的核心類型、設定儲存位置，以及是否具備 Linux 系統代理與 TUN 管理能力。不同用戶端對訂閱覆寫、核心更新與權限提升的實作不盡相同，遷移時不要假設介面選項完全一致。

AppImage 執行方式

AppImage 不需要依循傳統套件安裝流程。下載與目前架構相符的檔案後，加入執行權限，再從終端機啟動。以下命令中的檔名請替換為實際下載的檔名：

mkdir -p "$HOME/Applications"
mv "$HOME/Downloads/用戶端檔案.AppImage" "$HOME/Applications/"
chmod +x "$HOME/Applications/用戶端檔案.AppImage"
"$HOME/Applications/用戶端檔案.AppImage"

若雙擊沒有反應，請從終端機執行一次並查看錯誤輸出。部分發行版需要提供 FUSE 相容元件；某些新版 AppImage 也可直接使用自身支援的解包模式。不要只因「圖示沒有出現」就判定安裝失敗，視窗系統、系統匣擴充功能與桌面入口快取都可能影響顯示。

DEB 與 RPM 安裝方式

Debian、Ubuntu 及其衍生系統可使用 APT 安裝本機 DEB 套件。APT 也會一併處理套件宣告的相依性：

cd "$HOME/Downloads"
sudo apt install ./用戶端檔案.deb

Fedora、Rocky Linux 等使用 RPM 套件的系統，可以透過 DNF 安裝本機檔案：

cd "$HOME/Downloads"
sudo dnf install ./用戶端檔案.rpm

安裝完成後，從應用程式選單啟動用戶端。首次執行時，先查看核心狀態，再匯入訂閱或本機 YAML 設定。若用戶端提供「設為系統代理」選項，通常只會修改目前桌面工作階段的代理設定，不代表透明接管所有程序。終端機程式、容器及以系統服務身分執行的軟體是否讀取桌面代理，仍需分別確認。

部署 mihomo 命令列核心

命令列部署的核心包含三個物件：可執行檔、工作目錄與設定檔。建議將可執行檔放在 /usr/local/bin/mihomo，將系統層級設定放在 /etc/mihomo/。如此可將程式升級與設定維護分開，也方便 systemd 使用固定路徑啟動。

從可信任的發布管道取得與架構相符的壓縮檔，解壓縮後將二進位檔重新命名為 mihomo。假設檔案已解壓縮至目前目錄，可以執行：

sudo install -m 0755 mihomo /usr/local/bin/mihomo
/usr/local/bin/mihomo -v
sudo install -d -m 0750 /etc/mihomo

mihomo -v 應輸出核心版本與建置資訊。若出現 Exec format error，通常代表下載了錯誤的架構；若提示沒有執行權限，請檢查檔案模式，以及所在檔案系統是否使用了 noexec 掛載選項。

首次部署不要立即寫入複雜的 DNS、腳本與 TUN 規則。先使用一份能夠解析的基本設定，確認連接埠與節點可用，再逐項加入進階設定。mihomo 可透過 -d 指定工作目錄，目錄中的 config.yaml 會作為預設設定載入：

sudo /usr/local/bin/mihomo -d /etc/mihomo

前景啟動適合首次檢查。終端機會持續顯示設定解析、監聽連接埠、代理連線與規則比對資訊。確認設定能夠啟動後，再依照後文建立 systemd 服務，避免服務反覆重新啟動而掩蓋最初的錯誤。

設定目錄、訂閱檔案與基本連接埠

最簡單的目錄只包含 /etc/mihomo/config.yaml。啟用 GeoIP、規則集或其他外部資源後，工作目錄還可能出現資料庫、快取與下載檔案。執行服務的使用者必須能夠讀取設定，並對需要更新的快取位置擁有寫入權限。若設定中包含訂閱憑證或控制介面金鑰，應限制目錄與檔案權限。

sudo install -m 0640 config.yaml /etc/mihomo/config.yaml
sudo chmod 0750 /etc/mihomo
sudo ls -la /etc/mihomo

用於本機測試的基本設定可以包含混合代理連接埠、區域網路存取開關、運作模式與控制介面。以下僅展示結構，代理節點與規則應來自實際可用的 Clash 或 Mihomo 設定：

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: true

external-controller: 127.0.0.1:9090
secret: "請設定隨機且足夠長的控制金鑰"

proxies: []
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,PROXY

mixed-port 可同時接受 HTTP 與 SOCKS5 連線，方便瀏覽器、終端機工具與開發軟體共用一個連接埠。allow-lan: false 表示先限制為本機使用。即使 bind-address 設為萬用位址，只要未允許區域網路存取，就不應視為已完成共享設定。

external-controller 是控制介面，不是一般代理連接埠。僅在本機管理時，應繫結至 127.0.0.1，並設定控制金鑰。若確實需要遠端管理，還應同時規劃防火牆、可信任網路範圍與存取驗證，不應直接將控制連接埠暴露於不受信任的網路。

匯入訂閱時保留備援檔案

圖形用戶端通常會自行管理訂閱 URL、更新間隔與本機設定副本。命令列部署則需要明確指定由誰負責更新。可以透過受控腳本取得設定，先儲存為暫存檔，呼叫核心進行設定檢查，再替換目前使用的檔案。下載失敗時不要直接覆寫原有的 config.yaml，否則一次空白回應或驗證失效，就可能導致服務下次重新啟動失敗。

訂閱網址通常包含存取憑證，不適合直接寫入其他使用者可讀取的 shell 歷史紀錄、服務日誌或公開腳本。較穩妥的方式是將憑證放入權限受限的環境檔案，更新工作只讀取該檔案，並限制更新結果的存取權限。若訂閱提供者輸出的是通用節點清單而非 Clash YAML，還需要先進行相容性轉換，不能將任意文字直接作為 mihomo 設定啟動。

設定 systemd 服務與開機自動啟動

基本設定驗證通過後，可以建立 /etc/systemd/system/mihomo.service。以下服務單元以系統層級程序執行，並為可能使用的 TUN 功能保留網路管理能力。若只使用 HTTP 或 SOCKS 連接埠，可確認設定需求後縮小能力範圍。

[Unit]
Description=Mihomo proxy service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

儲存後重新載入 systemd 設定，啟動服務並設為開機自動啟動：

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
sudo systemctl status mihomo --no-pager

查看本次啟動日誌可以使用：

sudo journalctl -u mihomo -b --no-pager
sudo journalctl -u mihomo -f

Restart=on-failure 只會在異常結束時重新啟動，適合用來暴露設定解析與執行錯誤。若服務不斷重新啟動，請先執行 systemctl stop mihomo，再以前景方式啟動相同的設定目錄，以定位第一個錯誤。常見原因包括 YAML 縮排錯誤、監聽連接埠已被占用、規則引用的策略組不存在、設定目錄權限不足，以及 TUN 裝置或網路能力不可用。

連接桌面系統代理、終端機與 TUN 模式

核心正在執行不代表所有流量都已自動經過代理。只設定 mixed-port: 7890 時，應用程式仍需主動連接該連接埠。桌面環境可以將 HTTP、HTTPS 與 SOCKS 代理指向 127.0.0.1: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"

socks5h 表示網域解析也交由 SOCKS 代理端處理，但具體支援情況取決於應用程式。環境變數只對目前 shell 及其子程序生效。使用 sudo、systemd 服務、容器或圖形啟動器時，變數不一定會被繼承，因此應在對應的執行環境中個別設定。

TUN 模式的作用與前提

TUN 模式透過虛擬網路介面接管更多無法手動設定代理的流量，適合需要統一處理桌面應用程式、命令列工具與部分遊戲連線的情境。它依賴 Linux 的 /dev/net/tun 裝置、路由規則與相應的網路管理能力。容器、精簡核心或受限虛擬機器可能未開放 TUN 裝置，即使設定語法正確也無法建立介面。

典型設定會在確認現有 DNS 方案可用後再啟用：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-redirect: true
  auto-detect-interface: true

auto-route 用於自動設定路由，auto-detect-interface 用於識別預設出口。auto-redirect 的實際支援效果，與 Linux 網路環境、核心功能及 mihomo 版本有關。機器同時執行 Docker、Podman、VPN、NetworkManager 自訂路由或多張網卡時，應檢查路由優先順序與防火牆規則，避免將容器網段、內網位址或代理伺服器本身的連線錯誤地再次送入 TUN。

啟用 TUN 後若出現網域無法解析，不要只是不斷切換節點。應分別檢查 DNS 監聽、上游 DNS 可達性、規則中的 DNS 策略、虛擬介面路由，以及系統是否仍向其他本機解析服務發送請求。DNS 與 TUN 同時大幅調整會增加排查難度，建議先驗證連接埠代理，再啟用 DNS，最後加入 TUN。

啟動檢查與常見故障排查

部署完成後，檢查順序應由程序向外展開，而不是先根據網頁能否開啟來判斷。第一步確認服務正在執行，第二步確認連接埠處於監聽狀態，第三步透過明確指定的代理發出請求，第四步查看規則命中與節點連線日誌，最後再啟用系統代理或 TUN。

systemctl is-active mihomo
ss -lntup | grep -E '7890|9090'
curl --proxy http://127.0.0.1:7890 https://example.com/
journalctl -u mihomo -n 100 --no-pager

若 7890 沒有監聽，先查看設定解析與連接埠衝突。可以使用 ss -lntup 尋找占用中的程序。若連接埠存在但請求失敗，應觀察日誌判斷是 DNS 失敗、連線逾時、驗證錯誤，還是沒有可用代理。策略組中顯示節點不代表節點一定能連線，最終仍應以連線日誌與實際請求為準。

桌面用戶端啟動但無法接管流量

  • 檢查用戶端核心是否正在執行，而不只是視窗已經開啟。
  • 確認目前設定已啟用，策略組沒有指向失效或不可用的節點。
  • 檢查桌面系統代理是否成功寫入，並確認目標應用程式是否遵循系統代理。
  • 若使用 TUN，確認權限提升流程已完成、虛擬介面存在，且路由沒有被其他 VPN 覆蓋。
  • 退出其他代理用戶端，避免多個程式同時修改代理與路由。

服務啟動後立即退出

使用 journalctl -u mihomo -b 讀取本次開機日誌，並優先查看最早出現的錯誤。YAML 使用空格縮排，Tab 字元、層級錯位或未正確引用的特殊字元都可能導致解析失敗。規則指向不存在的策略組時，核心也可能拒絕載入設定。修改後先在終端機以前景方式執行，確認沒有錯誤，再重新啟動 systemd 服務。

區域網路裝置無法連線

共享代理需要同時符合四個條件：設定允許區域網路存取、服務監聽可由區域網路存取的位址、主機防火牆放行對應的 TCP 或 UDP 連接埠、用戶端填寫的是 Linux 主機的區域網路位址而非 127.0.0.1。還應確認無線網路未啟用用戶端隔離。開放連接埠前應限定可信任網段，並避免將代理連接埠暴露於公網介面。

Linux 部署完成後的維護清單

  1. 記錄目前核心的來源、版本、架構與可執行檔路徑。
  2. 限制設定目錄權限，妥善保存訂閱憑證與控制介面金鑰。
  3. 確認只有一個執行個體占用規劃中的代理、DNS 與控制連接埠。
  4. 為設定更新保留暫存檔與備援副本，驗證成功後再進行替換。
  5. 升級前檢查設定相容性變更，升級後查看啟動日誌與規則命中情況。
  6. 使用 TUN 時記錄額外路由、防火牆規則，以及它與 VPN、容器網路之間的關係。
  7. 不再使用桌面用戶端時，同時還原系統代理設定，避免留下失效連接埠。

桌面用戶端的重點是選擇仍在維護且適配目前發行版的介面，並理解系統代理與 TUN 的差異；命令列部署的重點則是固定目錄、先驗證設定，再交由 systemd 管理。沿著「二進位檔—設定解析—連接埠監聽—明確代理—系統接管」的順序檢查，就能將大多數 Linux 安裝問題限定在明確環節。

Next route

選擇 Linux 用戶端並繼續設定

先依桌面環境、處理器架構與維護狀態選擇用戶端，再按照使用文件匯入訂閱、檢查策略組並設定系統代理。

前往下載中心 查看教學