為什麼在 Linux 上要用 Clash，又為什麼需要 systemd？

在 Linux 桌面上，許多人會同時需要規則分流、訂閱更新、跨應用程式的代理一致性。圖形化用戶端固然省事，但伺服器或無頭環境往往只能依賴命令列核心搭配設定檔運作。以社群生態來說，mihomo（過去常稱 Clash Meta）是目前較常被採用的核心之一，與傳統 Clash Premium 的行為不完全相同，但對一般使用者而言，最關鍵仍是：設定檔結構、訂閱匯入、DNS／規則與本機監聽埠是否一致而可預期。

systemd的角色則是把這個長駐行程變成「系統服務」：開機自動啟動、在異常退出後自動拉起、並把日誌集中交給 journalctl。相比手動開終端機執行二進位檔，systemd 能顯著降低「登出後程序跟著消失」或「重新開機忘記開代理」的概率。接下來的流程以 Ubuntu 22.04／24.04 這類長期支援版本為假想環境；若你使用衍生發行版，只要仍採 systemd，下列觀念同樣適用。

用戶端與核心建置的安全來源請優先透過本站 下載頁 取得，再與本文的目錄配置與服務檔搭配；進階鍵位說明可交叉參考 配置教學。若想先把訂閱更新節奏、proxy-providers 等觀念釐清，也可以先閱讀 訂閱管理實踐 一文，再回到本篇把服務化流程補齊。

安裝前準備：使用者、目錄與權限思維

Linux 與 Windows／macOS 最大的不同，在於行程使用者與檔案權限會直接影響是否能讀取設定、是否能綁定連接埠、以及是否在重新開機後仍能運作。實務上建議不要用 root 日常執行 Clash，而是為專用帳號或你的登入帳號建立一個固定目錄，例如 ~/.config/clash，並確保該目錄下的 config.yaml、Country.mmdb（若使用 GEOIP 規則）與快取檔案，皆由同一使用者擁有。

你也應先確認系統是否允許綁定本機埠：Mixed Port（常見 7890）與 External Controller（常見 9090）若與其他服務衝突，會造成「行程啟動了但立即失敗」的表象。可用下列指令粗查（將埠號替換成你的設定）： 

sudo ss -lntp | grep -E ':7890|:9090'

另外，若計畫使用需要建立 TUN 裝置或額外路由表的進階模式，通常會碰到能力集（capabilities）或開機順序議題；在桌面環境可把問題拆成兩階段：先用本機 HTTP／SOCKS 代理把連線走通，再視需求研究 TUN。與全系統透明代理有關的概念，亦可對照 TUN 模式指南，避免一次開太多變因而無法定位故障點。

取得二進位檔並放到固定路徑

請從可信來源下載對應 Linux amd64（或你的 CPU 架構）壓縮包，解壓後會得到可執行檔；實際檔名依專案發佈習慣而異，以下以 /usr/local/bin/clash-meta 為例。若你偏好「僅限單一使用者可用」，也可放在 ~/bin 並在服務檔裡撰寫絕對路徑。

  1. 解壓並確認執行位元：chmod +x /usr/local/bin/clash-meta
  2. 用該帳號手動執行一次：確認能讀到 config.yaml
  3. 確保 PATH 不是你在 systemd 裡依賴的前提——服務檔儘量寫絕對路徑
首次排錯時，先用前景模式執行並觀察輸出；等到設定穩定後再交給 systemd。這能省下大量「只看得到服務失敗但不知道原因」的時間。

設定目錄與訂閱匯入：把 YAML 放對位置

多數使用者會在 config.yaml 內以 proxy-providers 指向訂閱網址，或直接把服務商提供的完整設定貼上後再微調。訂閱匯入的本質是：讓核心能定期下載遠端清單並產生節點與策略組。請特別注意：

  • 路徑：相對路徑會相對於 -d 指定的設定目錄
  • 重新整理：過於頻繁的更新可能觸發服務商限速；過慢則節點資訊過期
  • 敏感資訊：訂閱網址具備「等同密鑰」的性質，請勿提交到公開程式庫

以下是一段極度精簡、僅示意結構的片段（實際鍵請依你的服務商與核心版本調整）： 

# excerpt — paths are relative to the config directory (-d)
mixed-port: 7890
external-controller: 127.0.0.1:9090

proxy-providers:
  sub:
    type: http
    url: "https://example.com/your-subscription"
    path: ./providers/sub.yaml
    interval: 3600

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    use:
      - sub

rules:
  - MATCH,PROXY

當你能用手動指令成功啟動、且瀏覽器或 curl 透過本機代理連線正常，就代表「設定面」大致完成，接下來才進入 systemd 服務化。

撰寫 systemd 服務：開機自啟與自動重啟

在 /etc/systemd/system/clash.service（檔名可自訂）建立服務單元，重點是：User、WorkingDirectory、ExecStart 與重啟策略。以下範例示範常見寫法，請將使用者與路徑替換成你的環境： 

[Unit]
Description=Clash Meta (mihomo) daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=youruser
WorkingDirectory=/home/youruser/.config/clash
ExecStart=/usr/local/bin/clash-meta -d /home/youruser/.config/clash
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

寫入後套用並啟動： 

sudo systemctl daemon-reload
sudo systemctl enable --now clash.service
sudo systemctl status clash.service --no-pager

若狀態顯示失敗，請立即檢視日誌： 

journalctl -u clash.service -b --no-pager -e
不要把 external-controller 大咧咧綁在 0.0.0.0 卻又未設密碼；這會讓區域網路甚至外網有機會直接操作你的代理核心。預設僅監聽 127.0.0.1 會安全許多。

讓桌面應用程式走本機代理：環境變數與桌面整合

在沒有 TUN 的情況下，許多 CLI 工具會讀取 HTTP_PROXY／HTTPS_PROXY／ALL_PROXY。你可以選擇在 shell 設定檔內加入導出指令，或透過桌面環境的「系統 Proxy」設定指向 127.0.0.1:7890（埠請與設定檔一致）。要點是：不同登入階段、不同終端機分頁是否讀到同一組環境變數；若你發現「瀏覽器正常、終端機不走代理」，通常就是變數沒有在同一層級生效。

另一個常見誤會是把代理設好卻忽略DNS 查詢路徑：Clash 若採 fake-ip 或特定 DNS 設定，終端與瀏覽器看到的解析結果可能不同步。遇到「只有某些網域異常」時，請同時檢查規則與 DNS 區塊，而不是只更換節點。

輕量伺服器場景：你可能還需要什麼？

若這台 Ubuntu 不只是本機翻牆，而是作為內網的出口機，除了本機代理之外，可能還要處理轉送、防火牆與路由。這類需求已超出「安裝＋自啟」的範疇，而且高度依賴你的網路拓撲；務必先在測試環境驗證，再觸碰 sysctl 或 iptables／nftables 規則，以免把自己鎖在機器之外。

對多數讀者而言，先把單機連線穩定做好，再評估是否要讓其他裝置指向這台機器的埠，會是最穩健的路線。

故障排除：依序收斂問題範圍

服務起不來或立即結束

先確認 ExecStart 路徑與參數是否能在該 User 下手動執行；再檢查設定檔 YAML 是否因縮排錯誤而無法解析；最後閱讀 journal 是否有「權限不足」「埠占用」或「找不到檔案」之明確訊息。這三類占了 Linux 上初次部署失敗的大宗。

訂閱能下載但節點全紅或無法連線

先驗證你選中的策略組是否指向正確的 provider；再確認本機時間是否嚴重偏移（TLS 會失敗）；最後才懷疑遠端節點品質。把變因一次只改一個，會比同時替換訂閱與 DNS 更容易定位。

權限問題導致無法寫入快取或資料庫

請確認 WorkingDirectory 下相關檔案的擁有者與服務 User 一致；若你曾用 sudo 執行過核心，可能留下 root 擁有的檔案，接下來在降權服務裡就會寫入失敗。

總結：自動化的價值在於「可預期的長期運維」

在 Ubuntu 上使用 Clash 類核心，真正的難點往往不在「下載執行檔」，而在設定檔是否一致、權限是否正確、長駐方式是否可靠。把手動啟動改為 systemd 後，你能獲得清楚的啟停命令、可追蹤的日誌，以及開機後自動回到可用狀態；相比隔一陣子才發現代理其實早已退出，這種穩定度對桌面與輕伺服器都同樣划算。持續維護的核心與乾淨的訂閱管理習慣，則會決定你在數個月後是否還能「無痛重裝或遷移」。

若你正在從其他平台轉到 Linux，建議沿用同一套規則與 DNS 策略，只替換執行與自啟層；相比四處收集零散文檔，把流程標準化成可重複的目錄結構與服務單元，通常能顯著減少來回試錯。相較於偶發手動啟動、版本混用的環境，採用固定路徑、固定帳號、可快速還原的設定檔備份，在穩定性與安全性上通常會好得多。

→ 立即免費下載 Clash，開啟流暢上網新體驗