為什麼在 Linux 上常選「無圖形介面＋systemd」？

許多使用者的第一印象是：在 Windows 或 macOS 上透過圖形客戶端切換訂閱、看連線日誌最直覺；但一到Linux 伺服器、容器主機或最小化安裝的桌面，往往沒有面板、也沒有托盤圖示，這時命令列與服務管理才是主戰場。Clash Meta（上游實作常見名稱為 mihomo）本質上是單一可執行檔加上一份 YAML 設定檔，非常適合交給 systemd 接手程序保活、開機自動啟動與標準日誌匯流。

相較於手動在 screen／tmux 裡開程式，systemd 能處理崩潰重啟、環境變數、安全隔離（以專用系統帳號執行），並把輸出集中到你熟悉的 journal，對遠端維運與問題還原都更友善。接下來我們假設你已能取得合法的訂閱與設定檔，重點放在「如何把同一套 Meta 核心穩定跑在無 GUI 環境」。

目錄與二進位：先固定「誰跑、讀哪裡」

在動手寫 unit 檔之前，建議先約定三個路徑：可執行檔位置、工作目錄（存放 config.yaml、GeoIP、快取等），以及執行身分（root、一般使用者或專用帳號 clash／mihomo）。常見做法是把二進位放到 /usr/local/bin/mihomo，設定與資料放在 /etc/mihomo/ 或 /var/lib/mihomo/，並以非特權使用者執行、只對該目錄擁有讀寫權限，降低外洩風險。

請確認二進位具備執行權限（chmod +x），並用同一條命令列手動跑一次，確保設定檔路徑與監聽埠無誤。多數發行版上，監聽 7890（HTTP）或 7891（SOCKS）等埠若小於 1024，可能需要 CAP_NET_BIND_SERVICE 或以 root 執行——實務上更建議使用高於 1024 的埠，或搭配本機 iptables／nftables 轉發。若你尚未熟悉 Meta 專屬欄位與新版協定，可先完成核心版本與功能對照，再回頭調整伺服器上的設定檔。

與桌面版客戶端的差異 無 GUI 時沒有「一鍵匯入訂閱」介面，訂閱更新多半靠 proxy-providers 或外部腳本；請務必確認檔案權限與排程，避免服務重啟後讀不到最新節點清單。

撰寫 systemd 服務：常駐、重啟與環境變數

以下為一則示意用的 unit 骨架（實際路徑與使用者名稱請依你的環境替換）。重點欄位說明：User／Group 限制執行身分；WorkingDirectory 讓相對路徑與快取目錄一致；ExecStart 指向 mihomo 並帶入 -d 或 -f 等參數（依你所用版本說明為準）；Restart=on-failure 搭配 RestartSec= 可避免設定錯誤時瘋狂重啟塞爆日誌。

# /etc/systemd/system/mihomo.service
[Unit]
Description=Clash Meta (mihomo) proxy
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=65535

[Install]
WantedBy=multi-user.target

寫入後執行 sudo systemctl daemon-reload，再以 sudo systemctl enable --now mihomo.service 同時完成開機自啟與立即啟動。systemctl status mihomo.service 應顯示 active (running)；若為 failed，先不要改設定盲試，下一節會說明如何從日誌讀出真正原因。

使用者層級（systemd --user）是否適合？

若你只在單一登入使用者下需要代理，且發行版已啟用 linger，亦可使用 systemctl --user 管理；但伺服器無人登入時，系統層級的 mihomo.service 通常更直覺。兩者擇一即可，重點是不要重複啟動兩份程序搶同一個埠。

日誌排查：journalctl、等級與「先看時間軸」

無 GUI時沒有內建「連線紀錄」視窗，systemd 匯集的 journal 就是你的第一現場。常用指令如下：journalctl -u mihomo.service -b 檢視本次開機以來的紀錄；加上 -f 可即時追蹤；--since "10 min ago" 能縮小時間範圍。若服務頻繁重啟，請先看第一筆錯誤出現的時間點，再對照你是否剛改過設定檔或訂閱網址。

若 journal 裡訊息過少，請到 YAML 中調整日誌層級（常見鍵名為 log-level，值如 info、debug）。除錯時可暫時調高，確認完畢後務必改回，以免磁碟與 CPU 被刷爆。若你懷疑是規則命中或 DNS 行為異常，可與YAML 分流指南中的 DNS、規則順序章節交叉比對；很多「以為是節點壞掉」的案例，其實是規則或解析路徑不一致。

與檔案日誌並行 若你在設定中另外指定了 log 輸出到檔案，請一併確認該檔案的旋轉與權限；否則磁碟寫滿會讓服務看似「無故停止」。

常見故障：埠、權限、設定檔與重啟循環

埠已被占用或無法綁定

日誌若出現 bind: address already in use，請用 ss -lntp 或 lsof -i :埠號 找出占用者。常見原因是先前手動啟動的 mihomo 未關閉，或另一個代理程式已佔用同埠；解法是統一只由 systemd 啟動一份實例。

權限拒絕讀寫設定或 GeoIP

若 User 非 root，請確認整個工作目錄與下載快取路徑對該使用者可寫；GeoIP 或規則檔若由 root 下載、屬主卻不符，會導致啟動失敗或規則異常。

YAML 語法或版本不相容

升級二進位後，舊設定可能含有已廢棄欄位；此時 journal 常會直接印出解析錯誤行號。請對照官方文件逐步修正，必要時先在另一台機器用較新版本試載入同一檔案。

網路尚未就緒就啟動

少數環境下，開機當下 DNS 或路由尚未就緒，導致訂閱拉取失敗。可考慮在 unit 中加上適當的 After 依賴，或以 timer 延遲啟動；亦可在設定中開啟重試型 proxy-providers 行為（依版本文件為準）。

可複製的自檢清單（無 GUI Linux）

  1. 二進位路徑、config.yaml 與工作目錄三者一致，且執行使用者對資料夾具備讀寫權限。
  2. systemctl enable --now 後，status 為 active (running)，且僅有一份程序監聽預期埠。
  3. journalctl -u mihomo.service -e 無持續錯誤迴圈；必要時暫時提高 log-level 以取得足夠脈絡。
  4. 訂閱與規則更新後曾執行 daemon-reload 或服務重載流程，避免讀到舊快取。
  5. 防火牆與雲端安全群組已放行本機應用程式所需的對外連線（以及你允許的區域網路連入規則）。

把上述步驟變成習慣後，你在純命令列環境裡維護 Clash Meta 的成本會明顯下降；出問題時也會習慣「先看 journal、再看設定與網路」，而不是反覆重裝二進位檔。

寫在最後：無 GUI 不是退步，而是把控制權交回給你

在 Linux 上跑 mihomo／Clash Meta，本質是把代理能力做成可預期的系統服務：systemd 負責生命週期與開機自啟，日誌則透過 journalctl 與設定檔中的層級收斂成可追查的線索。相較依賴圖形面板，這條路在伺服器與自動化場景更乾淨，也更容易寫進自己的部署腳本與監控。

若你同時需要圖形化訂閱管理、內建連線檢視與跨平台客戶端體驗，仍可從我們的下載中心取得適合桌面環境的版本，與本機或遠端 Linux 服務搭配使用。桌面與無 GUI部署並不衝突：一邊管好用戶體驗，一邊把常駐與日誌排查留在最擅長的地方即可。

→ 立即免費下載 Clash 客戶端，在圖形介面中管理訂閱與策略組，並與 Linux 上的 Meta 服務形成互補

更多主題請瀏覽技術專欄；若要強化 YAML 結構與 Rule Providers，建議延伸閱讀Clash YAML 規則分流完全指南。