一、為何用命令列 + systemd 管理 Clash
在 Ubuntu 22.04 上，圖形介面客戶端（例如 Clash Verge）適合日常桌面；但若你維運無頭伺服器、或希望與既有腳本／容器化流程一致，直接執行 Mihomo 核心並交由 systemd 託管，是更貼近伺服器習慣的做法。systemd 能統一處理開機順序（等待 network-online）、程序崩潰後自動拉起、以及標準化的日誌與除錯入口（journalctl）。
與本站已發布的 Windows TUN 與防火牆專文、混合埠與區域網共享相比，本文聚焦Linux 安裝與服務化維運：讀者若在找「如何把核心裝上 Ubuntu、如何開機自啟、如何確認埠有在聽」，可依序完成本篇步驟。若需深入規則與訂閱語法，可併讀 設定說明與文件。
config.yaml 運行；與舊版 Clash 核心相比，Mihomo 延續 Meta 規則能力，並持續整合社群需求，適合作為長期常駐選型。
二、環境準備與取得 Mihomo 二進位檔
先確認系統架構（常見為 amd64），並安裝解壓與下載所需工具：
sudo apt update sudo apt install -y curl unzip
接著從上游發行頁取得對應平台的壓縮包或二進位檔（請依官方 Release 頁面為準，檔名會隨版本變動）。下載完成後，建議將可執行檔安裝至 /usr/local/bin/，以便全系統可直接呼叫：
sudo mv mihomo /usr/local/bin/mihomo sudo chmod 755 /usr/local/bin/mihomo mihomo -v
若 mihomo -v 能印出版本資訊，代表執行檔已就緒。接下來要建立工作目錄與設定檔，因為 Mihomo 預期透過 -d 參數指向「資料目錄」，在該目錄中讀取 config.yaml。
config.yaml 上傳至公開倉庫；檔案權限建議僅允許執行帳號讀取（見後文「檔案權限」一節）。
三、目錄結構與 config.yaml 要點
以下以系統級目錄 /etc/mihomo 為例（亦可用 /opt/mihomo，重點是與 systemd 中 -d 路徑一致）：
sudo mkdir -p /etc/mihomo sudo nano /etc/mihomo/config.yaml
一份可啟動的設定檔至少需要連接埠與基礎規則／代理結構。實務上多數使用者會匯入訂閱並沿用服務商提供的範本，再依本機需求調整 mixed-port、external-controller、DNS 等欄位。請注意：
- 連接埠：
port、socks-port、mixed-port擇一或併用時，須避免與系統其他服務衝突。 - 監聽位址：若僅本機使用，可將相關 bind 設為
127.0.0.1；若需區域網其他裝置連線，才考慮0.0.0.0並搭配防火牆，概念與 Windows 混合埠一文所述一致。 - DNS：若啟用
fake-ip或自訂nameserver，請留意與 Ubuntu 的systemd-resolved是否互相干擾；出現「能連線但解析怪異」時，優先對照 DNS 區塊與日誌。
撰寫或貼上設定後，可先以前景模式試跑，確認無語法錯誤再交給 systemd：
sudo /usr/local/bin/mihomo -d /etc/mihomo
若終端機持續輸出日誌且無報錯，可用另一終端機進行下一節的服務化；按 Ctrl+C 結束前景程序即可。
四、撰寫 systemd 服務單元
建議為 Mihomo 建立專用系統帳號，避免以 root 長期執行：
sudo useradd --system --home /etc/mihomo --shell /usr/sbin/nologin mihomo sudo chown -R mihomo:mihomo /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 ExecStart=/usr/local/bin/mihomo -d /etc/mihomo Restart=on-failure RestartSec=5 LimitNOFILE=65535 [Install] WantedBy=multi-user.target
Restart=on-failure 表示程序非正常退出時會在 RestartSec 秒後重啟；若你希望設定檔錯誤時也反覆嘗試，可改為 Restart=always，但可能導致日誌刷屏，需自行取捨。After=network-online.target 有助於在乙太網路或 Wi‑Fi 尚未就緒時降低啟動失敗機率；若仍遇開機時序問題，可再依環境調整。
使用者層級 service（選用）
若你只在單一登入使用者下使用桌面環境，亦可改用 systemctl --user 搭配 linger，無需 root；但伺服器與多使用者場景仍以系統單元較易統一管理。兩種模式擇一即可，避免重複啟動兩個核心。
五、啟用、開機自啟與日誌排查
載入設定並啟動服務：
sudo systemctl daemon-reload sudo systemctl enable --now mihomo.service systemctl status mihomo.service --no-pager
開機自啟已由 enable 寫入連結；重開機後可再次執行 systemctl is-enabled mihomo 確認為 enabled。除錯時請優先查看日誌：
journalctl -u mihomo.service -e --no-pager journalctl -u mihomo.service -f
若服務反覆重啟，日誌中通常會出現設定檔路徑、YAML 解析行號或埠被佔用等線索；請先修正設定或釋放埠，再 systemctl restart mihomo。
六、埠號、監聽位址與檔案權限校驗
埠號是否與 config.yaml 一致，可用下列方式檢查（依實際埠替換）：
ss -tlnp | grep -E '7890|9090'
若見到 LISTEN 且程序為 mihomo，表示核心已綁定成功。接著用 curl 走本機 HTTP 代理測試（埠請改為你的 mixed-port 或 port）：
curl -x http://127.0.0.1:7890 -I https://www.cloudflare.com
權限方面：/etc/mihomo 目錄應由執行使用者擁有；含訂閱的 config.yaml 建議 chmod 600，避免同機其他帳號讀取。若你將執行檔或目錄放於使用者家目錄，亦請避免世界可讀。
| 現象 | 建議優先檢查 |
|---|---|
| status 顯示 failed（exit code 非 0） | journalctl -u mihomo 內 YAML 錯誤、訂閱無法下載、或埠已被佔用 |
| 本機 curl 通，瀏覽器不走代理 | 瀏覽器是否另行指定 PAC／插件；桌面環境變數 HTTP_PROXY 是否未設定 |
| 服務啟動慢或開機偶發失敗 | 網路就緒時序、DNS 解析慢；可微調 After= 或延遲啟動策略 |
七、常見問題速查
- 埠已被佔用：用
ss -tlnp找出既有程序，修改config.yaml埠號或停用衝突服務。 - 權限拒絕：確認
mihomo使用者對資料夾與設定檔具備讀取權，對執行檔具備執行權。 - 訂閱更新失敗：檢查機器時間是否正確、出站網路是否需先走代理（可先以前景模式測試
curl訂閱網址）。 - 需要 TUN／透明代理：牽涉額外能力與路由，情境與 Windows TUN 類似但細節不同；建議在核心與文件確認 Linux 下所需權限與模組後再啟用。
以上排查與本站其他平台文章可交叉參考：Windows 讀者可對照 TUN 與路由防火牆；需要釐清監聽與區網分享時，可複習 混合埠與防火牆中的概念映射到 Linux。
八、小結
在 Ubuntu 22.04 上完成 Clash Linux 路線的關鍵，是將 Mihomo 二進位檔、設定目錄與 systemd 單元三者路徑對齊，並透過 enable 實現開機自啟、以 Restart= 處理崩潰重啟。相較僅手動執行可執行檔，服務化後的日誌與狀態可查性更佳，也更符合伺服器維運習慣。
相較功能單一、各平台設定互不連貫的工具，Clash 生態在規則、核心與多系統客戶端之間更容易沿用同一套心智模型；在 Linux 上把核心跑穩後，無論是桌面還是輕量雲主機，都能一致地管理出口與策略。
若你仍習慣圖形介面，也可先自本站取得適用於 Windows、macOS 或 Linux 圖形版的安裝包，再依環境選擇是否改走命令列託管。
