Arch Linux 安裝 Clash Meta：systemd 自啟與首配步驟（2026）

1. 為什麼 Arch 路線和 Ubuntu、Fedora 不一樣

Arch 的設計是「精簡基底＋你決定上層要堆什麼」：官方庫不承諾內建每一種圖形導向的代理前綴，mihomo 這類元件多半出現在 AUR（Arch User Repository），由社群以 PKGBUILD 包裝。好處是安裝路徑與檔名通常一致、可用 pacman -Ql 追蹤；代價是你必須養成讀 AUR 頁、看維護者、看上次更新時間的習慣，與在 paru 或 yay 裡一鍵裝了就算的惰性不相容。若你從 已發表的 Ubuntu 稿 轉過來，心理上要把「deb 管理員」換成「AUR 審查者」。

Manjaro 等衍生版在預設倉庫、鏡像與測試節奏上與純 Arch 不盡相同，但啟用 AUR 後的檔案佈局與 systemd 模型大多一致。這代表本篇關於 ~/.config、systemd --user 與 journalctl --user 的建議，多數能直接遷移；需要額外留意的反而是內建防火牆工具是否有預設啟用、以及圖形套件管理員是否幫你延後了某次系統更新。

2. 安裝 mihomo：AUR、yay／paru 與手動二進位

實務上兩條主線並存：從 AUR 安裝，以及手動下載上游釋出檔、放到自己的路徑。前者讓 mihomo 常出現在 /usr/bin 並隨 pacman -Syu 慣例一併被提醒更新；後者讓你完全控制版本，但要自己處理替換、簽名驗證與 systemd 的 ExecStart 寫成絕對路徑。常見的輔助器包含 yay 與 paru，搜尋關鍵字可用「mihomo」或與 Clash Meta 相關的套件名，再閱讀 AUR 描述是否將服務單元一併提供。

你不需要在教學裡背下某一個 PKGBUILD 的套件名，因為 AUR 會變、維護者會換、命名會拆。比較穩定的判準是：安裝完後在終端機執行 command -v mihomo 與 mihomo -v 能否得到預期輸出；以及該次安裝是否同時在 /usr/lib/systemd 寫了範本單元。若 AUR 自帶的 .service 行為你不同意（例如寫死工作目錄在 /etc），寧可複製到 ~/.config/systemd/user 自己改，也不要默默接受與你的帳號與權限模型衝突的內容。

圖形客戶端或整包分發，請優先參考本站 下載頁 取得入口；本文明講 核心＋系統層可維運性，與按鈕導向的圖形介面有時不會一一對應，屬正常切割。

3. 設定目錄、權限與首次訂閱匯入

mihomo 讀寫的檔名仍是大家熟悉的 config.yaml（實務上亦可能以 -f 指向其他檔名），而訂閱 URL 與規則集下載會產生快取與臨時檔。桌面使用者多數以 ~/.config/mihomo 為工作目錄，優點是權限與你的登入帳號一致、備份容易；系統層佈署則可能落在 /etc/mihomo 與專屬的 /var/lib 子目錄，讓 User= 指向的帳號可以寫入。無論你選何者，同一條執行路徑裡的「參數 -d 或 -f」與「WorkingDirectory」必須彼此一致，否則 systemd 顯示 active 卻讀到空白設定 的狀況會屢見不鮮。

訂閱導入可以走「圖形客戶端產生檔案」或「在 YAML 手寫 proxy-providers 區塊」兩願。第一次上線建議以最小可用為目標：一組節點、一條 MATCH 預設、一組 DNS 與一個模式，讓 journalctl 裡的錯誤訊息可讀，再逐步加規則。若一開始就堆滿 Rule Providers、GEOIP 與 Sniffer，出問題時很難判斷是「沒導到 mixed-port」還是「規則衝突」。

4. 首配 mixed-port 與 external-controller 邊界

mixed-port 讓你在多數桌面情境中用單一 TCP 埠同時滿足常見的 HTTP 與 SOCKS 形態的客戶端連入，好處是 GNOME／KDE 的「系統代理」欄位可以填成同一個 127.0.0.1:PORT，終端機的 ALL_PROXY 也較不容易與瀏覽器打架。實作上可將獨立 port 與 socks-port 關到 0 或關閉，把火力集中在 mixed；埠號只選「不與本機已存在服務衝突」的數字即可，7890 常見卻非標準。

Example only — keys vary by mihomo / Meta version
mixed-port: 7890
port: 0
socks-port: 0
allow-lan: false
external-controller: '127.0.0.1:9090'

external-controller 提供 REST 介面，方便搭配儀表板與轉匯。請預設綁在 127.0.0.1、避免在尚未理解風險前就把 API 丟在區網。若 Linux 桌面代理只開 mixed-port 卻不經意把 controller 也暴露出去，惡意鄰近裝置或不良 Wi‑Fi 的風險面會比你想像中大。

5. systemd 使用者服務：圖形登入後自啟

在桌機上，systemd --user 幾乎永遠是第一選擇：設定檔與金鑤檔多數在家目錄、不需要把敏感資料擴寫到 /etc。建立 ~/.config/systemd/user/mihomo.service 時，要同時寫出 ExecStart 的絕對路徑與 -d 指向的設定目錄。完成後以 systemctl --user daemon-reload、systemctl --user enable --now mihomo.service 啟用；開機自啟在此語意是「圖形或文字登入後，帶起使用者工作階段的預設目標（default.target）再啟動服務」。

Example user unit — adjust paths and binary name
# ~/.config/systemd/user/mihomo.service
[Unit]
Description=mihomo (Clash Meta) for current user
After=network-online.target

[Service]
Type=simple
WorkingDirectory=%h/.config/mihomo
ExecStart=/usr/bin/mihomo -d %h/.config/mihomo
Restart=on-failure

[Install]
WantedBy=default.target

本機若未拉 network-online，某些極小安裝可以把 After= 改成實際存在的目標，但不要在沒有症狀時亂刪依賴。若服務一啟動就觸發重啟風暴，先檢查是否「配置檔根本不存在或 YAML 寫壞」。

6. loginctl linger 與「未登入也要跑」的取捨

當你使用使用者服務，卻又希望筆電開機在顯示管理員（GDM 等）畫面時，背景就已經讓 mihomo 聽在 mixed-port 上，便會牽涉 loginctl enable-linger 使用者帳號 這類行為。它讓該帳號的 [email protected] 可以在沒有互動圖形登入時也維持，使你在登入前某些情境（例如 TTY、某些自動化）也能走到代理。代價是程序可能在你以為「未使用電腦」的時間仍長駐、埠仍開著，安全邊界要重新評估。

7. systemd 系統服務與專用系統帳號

當主機是閘道、家用伺服器、或你堅持只有單一系統帳號擁有代理設定，可以改用 /etc/systemd/system/mihomo.service 並在 [Service] 內寫 User=／Group=。要確定該帳號對 /etc/mihomo 或 /var/lib/mihomo 有權限，訂閱下載的暫存也不會變成 root 擁有。與 Fedora 稿 類似，多使用者桌機則更建議讓系統層的「閘道」與桌機使用者的 檔案與顯示工作階段 分清楚，減少誤用彼此的金鑰與權限。

8. 桌面系統代理與終端機變數

圖形桌面通常提供「手動／PAC／系統讀取環境變數」幾類策略；若你設成手動在代理欄位貼上 127.0.0.1:7890 這類，請確認 HTTP 與 HTTPS 兩層欄位一致。終端機則要留意大寫與小寫變體，例如 https_proxy 與 HTTPS_PROXY 在部分工具上不一致會讓人誤以為 Clash Meta 沒有工作。要補上規則與模式觀念，可延伸閱讀 使用教學總覽，把 訂閱、規則、DNS 三者的動線和本篇的「本機入站口」一併串起。

9. 本機 127.0.0.1 與防火牆前端的直覺

純 Arch 安裝不一定預裝圖形防火牆；若你另外裝了 ufw、firewalld 或自訂 nft 規則，要記得只監聽 127.0.0.1 時，通常不須為代理埠對外「開洞」。當 allow-lan 打開、或你刻意讓 mihomo 聽在區網位址，才要把它納入防火牆邏輯，並審核來源 IP。這與 站內 allow-lan 專文 所談的威脅模型是同一套邏輯，差別在 Linux 上工具從圖形精靈變成指令列與防火牆規則。

10. 驗證、日誌與常見沒有真的走到代理

執行 systemctl --user status mihomo.service 確認 Active，然後 ss -lntp | grep 7890（埠號以你的設定為準）檢查監聽。接著以 curl -x http://127.0.0.1:7890 測一個 HTTPS 目標。日誌使用 journalctl --user -u mihomo.service -b 讀本開機週期；系統層則用 sudo journalctl -u mihomo.service -b。當 瀏覽器正常、終端機卻不動，第一個偵查點永遠是殼層有沒有帶上 proxy 變數，而不是去改 mihomo 的規則集。

11. 上游專案與下載入口分開說明

mihomo 的原始碼、釋出與 Issue 在 MetaCubeX／mihomo 儲存庫；用來釐清授權、行為變更與除錯。與此分開，若你要在圖形介面或我們整理過的導向取得客戶端，請以本站 下載頁 為主路徑，避免把「唯一取得安裝包」的想法綁在 GitHub Release 上。