為什麼在 Linux 上要用 systemd 管 Mihomo
許多使用者在圖形介面或臨時終端機裡執行 Mihomo（Clash Meta 核心），關掉視窗或登出後程序就結束，重開機也要手動再跑一次。若你希望代理在背景常駐、開機自動啟動，並在異常崩潰時自動恢復，最務實的做法是交給 systemd：它是現代主流發行版預設的服務管理器，能統一處理啟停、依賴順序、日誌匯流與重啟策略。
這條路線也與「桌面用戶端教學」互補：Windows、macOS、Android 或 Clash Verge 類工具，多半已內建常駐與介面；而 Linux 伺服器、無頭主機、或自行整合核心的使用者，更需要一份可複製的服務化流程。下文假設你已能手動啟動 Mihomo 並載入設定檔；若尚未熟悉 YAML 結構，可先參考站內Mihomo 升級與設定指南把基本欄位對齊。
請在合法合規前提下使用代理工具；本文僅說明系統服務管理與除錯方法，不提供規避法規或濫用網路資源的指引。
前置條件：執行檔、設定目錄與權限
撰寫 unit 之前，請先固定三件事：核心執行檔的絕對路徑、設定檔目錄（-d 參數），以及該目錄下的 config.yaml 是否可被服務帳號讀取。常見做法是將二進位檔放在 /usr/local/bin/mihomo 或發行版套件路徑，設定放在 /etc/mihomo 或使用者家目錄下的專用資料夾。
若使用系統層級服務（multi-user），服務預設會以 root 或你在 unit 裡指定的 User= 身分執行；請確保該帳號對設定目錄與訂閱快取路徑有讀寫權限，否則會出現「手動跑正常、服務起不來」的落差。若你僅在個人桌面登入後需要代理，可改採使用者層級的 systemd（--user），讓服務跟著該使用者工作階段走，無需把設定放到全系統目錄。
需要監聽低於 1024 的連接埠或啟用 TUN 等能力時，可能牽涉 CAP_NET_BIND_SERVICE、CAP_NET_ADMIN 等；不同發行版對能力與安全模組（如 SELinux、AppArmor）的預設不同，若啟動失敗請對照日誌訊息調整，而非一律改為 root 長跑。
系統服務範例：mihomo.service
以下為示意用的系統服務檔，請將路徑改成你機器上的實際位置。重點是 ExecStart 使用 -d 指向設定目錄，並加上合理的重啟與檔案描述符上限。
[Unit]
Description=Mihomo (Clash Meta) Daemon
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
[Install]
WantedBy=multi-user.target將內容存成 /etc/systemd/system/mihomo.service 後，執行 sudo systemctl daemon-reload，再以 sudo systemctl enable --now mihomo.service 啟用並立即啟動。若你希望任何原因退出都自動拉起（包含非零離開碼以外的狀況），可把 Restart=on-failure 改為 Restart=always，並視情況調整 RestartSec，避免設定錯誤時進入狂重啟迴圈。
若要指定執行身分，可在 [Service] 區塊加入 User=mihomo 與 Group=mihomo，並事先建立系統使用者與目錄權限；這比長期以 root 跑核心更符合最小權限原則。
使用者服務範例：登入後常駐、適合桌面環境
在桌面 Linux 上，若你不希望動到 /etc，可把 unit 放在 ~/.config/systemd/user/mihomo.service，內容結構類似，但 [Install] 區塊通常寫 WantedBy=default.target。啟用方式改為：
systemctl --user daemon-reload
systemctl --user enable --now mihomo.service若你希望未登入圖形介面時也能在背景跑使用者服務，可能需在系統層啟用 linger（例如 loginctl enable-linger 使用者名稱），實際行為依發行版與登入管理器設定而異，請以官方文件為準。
日常操作：啟停、重載與開機自啟確認
熟悉幾個指令後，維護成本會大幅下降。systemctl status mihomo 可快速看是否 active、最近退出碼與最後幾行日誌摘要；修改 unit 後務必 daemon-reload 再 restart。若你更新的是設定檔而非服務檔，可依 Mihomo 版本支援方式處理：部分環境可透過 API 觸發重載，否則簡單的 systemctl restart mihomo 通常最直覺。
systemctl is-enabled 可確認是否已設定開機自啟；若顯示 disabled，表示僅手動啟動過，重開機後不會自動帶起。建議在變更訂閱或規則後，固定用「重啟服務 → 開瀏覽器抽樣測試」當作小型驗收，避免只在介面裡看到「已更新」但核心實際未載入。
日誌與排查：journalctl 與設定檔 log-level
服務化之後，標準輸出與錯誤會進入 systemd journal。常用檢視方式包括 journalctl -u mihomo.service -e 即時追蹤，或加上 --since "10 min ago" 縮小範圍。若你使用使用者服務，請改為 journalctl --user -u mihomo.service。
當連線異常時，請把 journal 內容與 Mihomo 設定裡的 日誌等級一併考量：等級過低可能看不到關鍵錯誤；過高則磁碟與 CPU 壓力上升。若你已能連上介面或 API，也可搭配檔案日誌（若你有另行設定）做交叉比對。
許多「連不上」其實要區分本機連接埠沒聽起來與對外撥號逾時兩類；這與 Windows／macOS 圖形客戶端讀到的訊息本質相同。建議搭配連線日誌與連接埠排查一文對照關鍵字，能更快決定是改 listener、換節點，還是查 DNS 與規則。
與訂閱更新、外部排程銜接
systemd 負責的是核心程序生命週期；訂閱 URL 的定期更新通常另需一層機制：例如在設定中啟用內建的更新間隔、或使用排程工具呼叫 Mihomo 的外部控制 API（若你已開啟並妥善保護）觸發重新載入。無論哪種方式，請避免把管理介面裸露在公網，並為本機 API 設定金鑰或限制監聽位址。
實務上可將「訂閱更新」與「服務重啟」拆開思考：更新檔案成功後，再決定是要 API 重載還是整體 restart；後者最簡單但會短暫中斷連線。若你在伺服器上還跑了其他依賴該代理的服務，可評估離峰時段更新，或採用支援平滑重載的流程。
需要強化 DNS 與規則一致性時，也可一併參考DNS 防洩漏與解析設定指南，減少「訂閱已更新但解析仍走錯路徑」造成的假故障。
常見坑：路徑、環境變數與重啟風暴
第一類問題是路徑不一致：互動式 shell 裡因為 PATH 或別名能找到執行檔，但 systemd 的乾淨環境找不到；解法永遠是在 unit 裡寫絕對路徑。第二類是工作目錄：若你的設定使用相對路徑引用規則集或 Geo 資料，請用 WorkingDirectory= 固定基準目錄。
第三類是過於激進的 Restart 策略：當 config.yaml 語法錯誤導致程序立刻退出，Restart=always 會讓 CPU 與日誌暴量。此時應先 systemctl stop，修正設定後再啟動；或在開發階段暫時改回 on-failure 並拉長 RestartSec。
最後，若你同時安裝了發行版套件與手動下載的二進位檔，請確認只有一個服務在監聽同一組 mixed-port／socks-port，否則會出現「address already in use」而反覆啟動失敗，這類訊息在日誌裡通常相當明確。
開源核心與用戶端取得方式
Mihomo 持續演進，參數與子命令可能隨版本調整；若要核對最新行為，可到 GitHub 上的 Mihomo 倉庫查閱文件與更新日誌。圖形用戶端與各平台安裝包仍建議以本站下載頁為主，方便取得與核心版本搭配較一致的體驗，並避免散落來源造成更新斷層。
小結
把 Mihomo 交給 systemd，本質上是把「長跑代理核心」納入與其他系統服務同一套治理模型：開機自啟、崩潰恢復、統一日誌與可預期的啟停流程。無論是無頭伺服器還是桌面環境，只要路徑與權限在 unit 裡寫清楚，維護成本通常遠低於手動終端機或自寫腳本輪詢。
相較於只在互動式環境裡啟動核心，服務化後與訂閱更新、日誌排查的銜接也更清楚：journal 對應系統時間軸，設定檔對應行為變更；再搭配站內連線排查文章，多半能穩定收斂問題。若你希望以已整合 Mihomo 的圖形用戶端降低自行撰寫 unit 的負擔，也可先到本站下載頁依平台選擇合適版本，再視需求回到本文的服務化流程做伺服器側補強。