Linux 部署 預計閱讀 14 分鐘

Linux 部署 Clash：桌面客戶端、mihomo 命令列與服務自動啟動

從桌面環境到無圖形介面的伺服器，整理設定檔目錄、啟動指令、systemd 服務與終端機代理變數。

先決定部署方式：桌面、命令列或常駐服務

Linux 上的 Clash 部署通常不只一種方式。配備 GNOME、KDE、Xfce 等桌面環境的個人電腦，適合使用圖形介面的客戶端；遠端伺服器、開發容器主機或僅透過 SSH 管理的裝置，則更適合直接執行 mihomo 核心；需要開機啟動、長期提供本機代理埠的裝置，應在命令列執行的基礎上加入 systemd 服務。

mihomo 是持續維護中的 Clash Meta 核心名稱。它負責讀取 YAML 設定、建立代理連線、執行規則比對，並監聽 HTTP、SOCKS 或 mixed 埠。圖形客戶端通常在其上層提供訂閱管理、節點切換、日誌檢視與系統代理開關。換句話說，桌面客戶端處理互動操作，核心則負責實際的流量處理。遇到連線異常時，應分辨問題來自介面狀態、設定內容，還是核心執行狀態。

使用環境 建議方式 主要管理入口
Linux 桌面日常使用 圖形客戶端 系統匣選單、客戶端設定與日誌頁面
無圖形介面的伺服器 mihomo 命令列 SSH、設定檔與執行日誌
長時間運作的工作站或伺服器 mihomo 搭配 systemd systemctl 與 journalctl
需要接管更多應用程式流量 TUN 模式 設定檔、路由與權限設定

部署前還要確認處理器架構。一般個人電腦和雲端伺服器通常是 amd64，部分開發板、路由器與 ARM 雲端主機則使用 arm64。可執行 uname -m 查看系統回報：x86_64 對應 amd64，aarch64 對應 arm64。若下載了錯誤架構的二進位檔，Shell 通常會回報無法執行或格式錯誤。

Linux 桌面客戶端：安裝套件、設定檔目錄與代理開關

在桌面環境中，可以優先選擇仍在維護且明確支援 mihomo 的圖形客戶端。常見發行格式包括 AppImage、Debian 系統使用的 .deb，以及 Fedora、openSUSE 等系統使用的 .rpm。選擇格式時應依照發行版的套件管理方式，不必為了客戶端更換系統軟體來源。

AppImage 的執行方式

AppImage 通常採單一檔案發行，下載後需要加入執行權限。以下指令假設檔案已放在目前目錄，實際執行時請使用下載所得的完整檔名：

chmod +x Clash-Linux.AppImage
./Clash-Linux.AppImage

如果雙擊後沒有視窗，應先從終端機啟動一次並查看輸出。較新的發行版可能缺少 AppImage 所需的 FUSE 相容元件，也可能因桌面沙箱、顯示伺服器或權限設定而無法啟動。終端機輸出通常比桌面跳出的簡短提示更有助於定位問題。

deb 與 rpm 安裝

Debian、Ubuntu 及其衍生系統可以透過套件管理器安裝本機 deb 檔案，讓系統處理相依套件：

sudo apt install ./clash-client-linux-amd64.deb

Fedora 系統可使用：

sudo dnf install ./clash-client-linux-x86_64.rpm

安裝完成後，從應用程式選單啟動客戶端。首次執行通常需要完成三個步驟：匯入訂閱或 YAML 設定、選擇策略群組中的可用節點，以及開啟系統代理。開啟系統代理只會影響遵循桌面代理設定的應用程式；部分終端機程式、容器、遊戲與自行實作網路堆疊的軟體，不會自動讀取這項設定。

圖形客戶端的設定檔目錄會因專案而異，常見位置包括 ~/.config/ 下的應用程式專屬目錄，以及 ~/.local/share/ 下的資料目錄。不要在客戶端執行期間直接覆寫其資料庫或受管理的設定。需要遷移時，先退出客戶端，再備份應用程式目錄；若客戶端提供匯出功能，應優先使用其匯出流程。

開啟桌面代理後，可以先確認客戶端日誌是否出現成功監聽埠的訊息，再測試瀏覽器連線。若瀏覽器正常而終端機指令失敗，通常表示終端機程式沒有讀取系統代理，而不是核心或節點本身失效。

mihomo 命令列部署：目錄、設定與啟動檢查

在無圖形介面的環境中，建議分開管理可執行檔、設定檔與執行資料。系統級部署可以將二進位檔放在 /usr/local/bin/mihomo，設定目錄放在 /etc/mihomo；僅供目前使用者使用時，則可將設定放到 ~/.config/mihomo。設定目錄必須允許執行帳戶讀取與寫入，因為核心可能會在其中儲存快取、規則資料與執行狀態。

安裝二進位檔後，先確認它能夠執行：

mihomo -v
mihomo -h

如果終端機提示找不到指令，應檢查檔案是否位於 PATH 包含的目錄中，並確認執行權限。若二進位檔位於目前目錄，必須使用 ./mihomo；Shell 預設不會從目前目錄搜尋指令。

mihomo 使用 YAML 設定。以下是一份用於驗證監聽埠與規則引擎的最小範例，會讓所有流量直連，不包含遠端節點：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

proxies: []
proxy-groups: []

rules:
  - MATCH,DIRECT

將檔案儲存為 config.yaml 後，可以先執行設定檢查。不同版本支援的指令參數可能略有差異，應以 mihomo -h 的輸出為準；常見的檢查方式如下：

mihomo -t -d /etc/mihomo

檢查通過後，以前景模式啟動：

mihomo -d /etc/mihomo

-d 用於指定工作目錄，核心會從該目錄讀取主要設定與相關資料。第一次部署不要立即放到背景執行，先觀察啟動日誌，確認 YAML 可以解析、埠未被占用，且規則檔案能夠讀取。看到 mixed 埠成功監聽後，再開啟另一個 SSH 工作階段測試代理：

curl --proxy http://127.0.0.1:7890 https://example.com/

實際使用的訂閱設定通常會包含代理節點、策略群組、規則、DNS 與規則提供者。更新設定時，不應只確認 YAML 語法，還要檢查策略群組引用的節點或提供者名稱是否存在、規則末尾是否有合理的預設處理項，以及使用的欄位是否受到目前 mihomo 版本支援。

systemd 服務自動啟動：執行帳戶、重新啟動策略與日誌

需要長時間執行時，可以將 mihomo 註冊為 systemd 系統服務。系統服務適合開機後立即提供代理埠的機器，也方便統一查看退出狀態與執行日誌。建立服務前，先準備專用帳戶與設定目錄：

sudo useradd --system --home-dir /var/lib/mihomo --create-home --shell /usr/sbin/nologin mihomo
sudo mkdir -p /etc/mihomo
sudo chown -R mihomo:mihomo /etc/mihomo /var/lib/mihomo
sudo chmod 750 /etc/mihomo

接著建立 /etc/systemd/system/mihomo.service：

[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
sudo systemctl status mihomo

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

sudo journalctl -u mihomo -b
sudo journalctl -u mihomo -f

-b 僅查看本次開機後的記錄，-f 則會持續追蹤新日誌。修改 YAML 後，建議先單獨執行設定檢查，再重新啟動服務：

sudo -u mihomo /usr/local/bin/mihomo -t -d /etc/mihomo
sudo systemctl restart mihomo

如果只希望在目前使用者登入後執行，也可以使用 systemd 使用者服務，將單元檔案放到 ~/.config/systemd/user/，並使用 systemctl --user 管理。使用者服務不需要專用系統帳戶，但預設會受到使用者工作階段生命週期影響。需要登出後繼續執行時，應搭配系統的 linger 設定評估權限與維護方式。

不要將服務設定成無條件高速重新啟動。設定語法錯誤、埠衝突或檔案權限錯誤不會因為連續重新啟動而自動解決，反而可能產生大量重複日誌。Restart=on-failure 搭配數秒間隔，更適合處理偶發的程序退出。

終端機代理變數：HTTP_PROXY、ALL_PROXY 與 NO_PROXY

Linux 桌面中的「系統代理」通常不會自動套用到所有 Shell 指令。curl、Git、部分套件管理器與開發工具會讀取環境變數，因此命令列環境需要另外設定。假設 mihomo 的 mixed 埠為 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
export NO_PROXY=localhost,127.0.0.1,::1

同時設定大小寫變數，可以相容更多工具：

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
export no_proxy="$NO_PROXY"

socks5h 中的字母 h 表示連網域名稱解析也交由 SOCKS 代理端處理，適合希望減少本機 DNS 路徑差異的命令列請求。不過，各工具對代理協定與變數優先順序的實作並不完全相同。出現異常時，可以先用 curl 明確指定代理進行測試，再查看特定工具的文件。

需要長期啟用時，可以將匯出指令寫入 Shell 設定，例如 Bash 的 ~/.bashrc 或 Zsh 的 ~/.zshrc。更穩妥的方式是定義開關函式，避免存取區域網路服務或排查網路時忘記關閉代理：

proxy_on() {
  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=localhost,127.0.0.1,::1
  export http_proxy="$HTTP_PROXY"
  export https_proxy="$HTTPS_PROXY"
  export all_proxy="$ALL_PROXY"
  export no_proxy="$NO_PROXY"
}

proxy_off() {
  unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
  unset http_proxy https_proxy all_proxy no_proxy
}

執行 sudo 時，環境變數通常會被過濾，因此普通使用者的終端機已啟用代理，不代表 sudo 啟動的程式也會使用代理。不要為了省事而大範圍保留所有環境變數，應針對套件管理器或特定指令使用其支援的代理設定。

容器同樣不會自然繼承主機的 127.0.0.1 代理。容器內的回環位址指向容器本身，而不是主機。需要讓容器存取主機代理時，應依 Docker、Podman 與網路模式設定可連線的主機位址，並確認 mihomo 的監聽位址、區域網路存取設定與防火牆規則。在將代理埠暴露至區域網路前，也應限制允許存取的網路範圍。

TUN 模式：權限、路由與 DNS 的配合

系統代理與環境變數只會對主動讀取代理設定的應用程式生效。對於不支援代理設定的程式，mihomo 可以透過 TUN 虛擬網卡接管流量。TUN 模式會調整路由並處理更多連線，因此部署複雜度也高於一般埠代理。

Linux 系統首先需要提供 /dev/net/tun。可執行以下指令檢查：

ls -l /dev/net/tun

在容器或受限的虛擬環境中，這個裝置可能沒有被映射進來。即使裝置存在，執行 mihomo 的帳戶仍需要網路管理能力。systemd 服務可以視需求加入能力設定：

CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE

這兩行應放在服務檔案的 [Service] 區段。修改後執行 systemctl daemon-reload 並重新啟動服務。一般代理埠若高於 1024，通常不需要 CAP_NET_BIND_SERVICE；是否保留應依實際監聽埠決定。

設定 TUN 時需要注意自動路由、自動辨識出口介面、DNS 劫持與 IPv6 行為。不同 mihomo 版本支援的欄位會持續演進，應以目前版本的文件與啟動日誌為準。部署後至少驗證以下幾項：

  1. mihomo 停止後，系統預設路由與 DNS 是否恢復。
  2. 目前的 SSH 連線是否仍然穩定，遠端管理位址是否被錯誤送入代理。
  3. 區域網路網段、閘道器、NAS 與開發服務是否依預期直連。
  4. IPv4 與 IPv6 是否採用一致策略，避免只有其中一類流量繞過規則。
  5. 休眠喚醒、網路切換或 VPN 連線後，TUN 路由是否需要重建。

故障排查：從程序、埠、設定到規則逐層檢查

Linux 上的連線問題適合分層排查，不要一開始就反覆更換節點或重新安裝客戶端。先確認程序存在，再確認埠正在監聽，接著檢查代理請求、DNS 與規則命中情況。

程序啟動後立即退出

使用 systemd 時，先執行 systemctl status mihomo 與 journalctl -u mihomo -b。常見原因包括 YAML 縮排錯誤、設定欄位不受目前核心支援、工作目錄不可寫入，以及引用的規則檔案不存在。手動執行 mihomo -t -d /etc/mihomo 通常能取得更直接的設定錯誤位置。

埠已被占用

檢查 7890 埠的監聽程序：

ss -lntp | grep 7890

舊執行個體、其他代理客戶端或重複啟動的服務，都可能占用同一個埠。應停止不需要的執行個體，或在設定中更換埠，並同步修改終端機代理變數。只修改其中一端會導致程式繼續連線到舊埠。

本機可用，其他裝置無法連線

先檢查 allow-lan、監聽位址與主機防火牆。僅監聽 127.0.0.1 時，服務只接受本機連線。允許區域網路存取後，還應限制防火牆的來源範圍，並避免將控制介面直接暴露於不受信任的網路。如果設定了 external-controller，建議繫結回環位址並設定存取憑證。

瀏覽器可用，Git 或 curl 無法連線

這通常是系統代理與終端機環境分離所造成。執行 env | grep -i proxy 查看目前變數，並使用 curl 的 --proxy 參數進行對照測試。還要檢查工具本身是否儲存了舊代理位址，例如 Git 的全域代理設定可能會覆蓋目前環境。

代理已連線，但目標流量套用了錯誤策略

暫時提高日誌層級，觀察請求命中的規則與策略群組。Clash 規則會依序比對，前面的寬泛規則可能提前攔截流量。檢查網域規則、IP 規則、GEOIP 或規則集的先後順序，並確認清單末尾存在明確的預設規則。修改規則後，先檢查設定，再執行平滑重新載入或重新啟動服務。

更新核心與設定的順序

核心更新與設定更新應分開進行。先保留目前可執行的二進位檔與設定副本，再替換其中一項並進行驗證。更新 mihomo 後，先執行版本指令與設定檢查，確認現有欄位仍可解析；更新訂閱後，則重點檢查策略群組引用、規則提供者與節點名稱。一次只變更一個關鍵變數，發生故障時更容易回復與定位。

對於長期運作的伺服器，可以定期關注服務退出狀態、日誌大小與設定更新時間。訂閱自動更新不等於核心自動重新載入，應確認使用的客戶端或腳本是否會在檔案變更後觸發設定載入。直接覆寫正在讀取的設定檔時，建議先寫入暫存檔、完成語法檢查，再以原子方式替換正式檔案，降低讀到半寫入狀態的風險。

部署完成後的檢查清單

  • 確認下載的建置版本與 uname -m 回報的處理器架構一致。
  • 確認設定目錄歸執行帳戶所有，敏感設定未開放給其他本機使用者讀取。
  • 在前景啟動階段完成 YAML、監聽埠與基本代理請求測試。
  • systemd 服務使用明確的工作目錄、執行帳戶與失敗重新啟動策略。
  • 終端機代理變數與 mihomo 實際使用的埠一致，並為本機與區域網路位址設定合理的直連範圍。
  • 啟用 TUN 前檢查裝置節點、網路能力、SSH 管理路徑與路由復原方式。
  • 修改訂閱、規則或核心版本後逐項驗證，避免同時變更多個執行條件。

桌面客戶端、mihomo 命令列與 systemd 並不是互斥的方案。個人工作站可以使用圖形客戶端管理日常節點，同時保留命令列方法用於日誌診斷；無圖形介面的伺服器則可以透過 mihomo 與 systemd，取得穩定且便於稽核的執行方式。確定部署方式後，再依應用程式是否讀取系統代理，決定使用環境變數或 TUN，整體設定會更清楚。

下載Clash