Debian 12 安裝 Clash Meta：從二進位到 systemd 自啟與 mixed-port 首配（2026）

1. 為什麼 Debian 12 不該照抄 Ubuntu／Arch 教學

Debian 12 與 Ubuntu 22.04／24.04 同屬 deb／apt 系，但預設套件集、建議的第三方套件導入方式、桌面預裝品項不同；若你直接把專寫 PPA、snap 捷徑、專有驅動精靈 的內容貼到公司裡的 純 Debian 伺服器，往往會在第一步就卡關。另一方面，Arch 的 yay／AUR 與 Fedora 的 dnf 路徑，也不會自動映射成你在 bookworm 上該把設定檔放在 /etc 還是家目錄。

核心觀念很單純：無論顯示名稱是 Clash Meta 還是上游專案名 mihomo，在 Linux 上你真正要設計的是二進位從哪裡啟動、設定與快取目錄誰能寫入、以及 systemd 用使用者單元還是系統單元承接開機。把這三點在 Debian 12 上回答清楚，就能自然接上 教學總覽 裡的訂閱、規則與模式，而不必在論壇從零拼解答。

2. 事前：架構、套件庫與非自由韌體（可選）

在乾淨的 bookworm 上，建議先以管理帳戶確認 dpkg 的架構，例如以 uname -m 或 dpkg --print-architecture 判斷是 amd64 還是 arm64，下載 mihomo 上游發行的對應壓縮包或執行檔名稱時才不會解錯檔。接著以 apt 安裝常用相依：curl 或 wget 用以下載、ca-certificates 用於 TLS 訂閱更新；若你會手動解壓縮，可再安裝 unzip 或 tar 依上游封裝型態補上。

非自由韌體在部分桌面／筆電硬體上與 Wi-Fi 有關，和 Clash 本體沒有必然依賴，但若你的 Debian 12 剛從最簡安裝升級、尚未把網路裝好，建議先依官方手冊安裝 firmware-linux 等套件，把底層上網補穩，再回來佈署代理；否則你會在「訂閱下載失敗」與「實體層斷線」兩邊分不清楚。

3. 下載 mihomo 二進位並安裝到 /usr/local/bin

實務上，多數團隊會直接從 MetaCubeX／mihomo 的 Release 取linux-amd64 或 linux-arm64 的壓縮包，展開後將可執行檔放入 /usr/local/bin，固定檔名為 mihomo 或 clash-meta，之後以 which mihomo 驗證 PATH 可見。之所以偏好 /usr/local/bin，是因為它符合 FHS 慣例、易於在 /etc 的 systemd 單元裡寫死完整路徑，也方便未來寫內部更新腳本；若權限僅能寫家目錄，亦可在 ~/bin 佈置，但呼叫 loginctl enable-linger 或系統服務時，路徑與帳戶要一致。

在 Debian 上不要假設某個 PPA 或隨便找來的 .deb 名稱與上游 mihomo 版本一一對應；若你已有可信的內部打包流程，可沿用，但審計角度仍以「可重現的來源＋校驗」為上。實作面記得 chmod +x 並在更新後 systemctl daemon-reload（若變更單元內容）再重啟服務。若你偏好在圖形客戶端內一鍵管理，可先至本站 下載頁 找桌面／行動裝置方案；本篇專注核心＋systemd 維運。

4. 工作目錄、config.yaml 與檔案權限

常見兩條目錄策略：系統級把設定放在 /etc/mihomo（或你自訂的 /etc/clash-meta），以 _mihomo 這類專用系統帳戶執行；使用者級則以 ~/.config/mihomo 存放 config.yaml、ruleset 快取與執行期資料，讓圖形登入帳戶能直接讀寫。無論何者，mihomo 啟動參數必須能指向該目錄（例如 -d 指定目錄），而不要用「剛好在家目錄執行所以猜得到」這種不穩的習慣，否則 systemd 重啟後常見的錯誤就是寫入路徑跑掉。

Debian 12 的 AppArmor 在部分自訂路徑上可能讓人困惑；若你堅持把核心放在不尋常位置，出現 寫入被拒 時，優先比對實際路徑與單元內的 ReadWritePaths 或專屬的 profile，再決定是否調整。下列片段用來展示 mixed-port 與其他埠位並存時的關係，實際鍵名與版本差異以上游說明為準。

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'

當 port 與 socks-port 關閉、僅以 mixed-port 監聽時，Linux 桌面的系統代理欄位與終端機 http_proxy／all_proxy 能對到同一埠號，維運心智負擔最低；之後如要導到 容器閘道 再讀專文即可。

5. mixed-port 與訂閱（proxy-providers）首配

mixed-port 解決的是「應用程式把流量送進核心」的邊；進入 mihomo 之後，是否走代理解析、最後從哪個節點出去，仍取決於 proxy-providers 是否成功下載、rules 與 Rule 模式。第一次上線建議在一組 proxy-providers 內寫好 type: http 的 訂閱 URL、搭配命名清楚的 proxy-groups，讓 PROXY 之類的策略組有實際後端。若 訂閱 在 systemd 內因 TLS 或 DNS 失敗，請先用 journalctl 捕捉錯誤，再分開測 curl 與系統 resolve 行為。

讀者若從 Ubuntu deb 專文 轉到 Debian，最常見的落差是 設定路徑 與 服務帳戶 不同導致「同一個 YAML 在 A 機可跑、B 機訂閱讀取失敗」；請以本文目錄策略重新對齊，再移植規則，而不是只複製內層的 rules。

6. systemd 使用者服務、daemon-reload 與 linger

在 GNOME／KDE 桌面帳戶內，通常優先採 ~/.config/systemd/user/mihomo.service，用 systemctl --user enable --now mihomo.service 自啟。單元內建議寫明 WorkingDirectory 與 ExecStart=/usr/local/bin/mihomo -d %h/.config/mihomo 這類資訊，讓 開機自啟 不因工作目錄變成 / 而讀不到訂閱。變更單元檔後務必 systemctl --user daemon-reload 再 restart。若你希望在圖形未登入時仍讓使用者的背景服務存在，可研究 loginctl enable-linger <使用者名>，同時審慎評估 mixed-port 是否只綁 127.0.0.1 與 allow-lan 是否保持關閉。

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

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

[Install]
WantedBy=default.target

7. systemd 系統服務：無人登入也保持監聽

在公司伺服器或單一用途的閘道主機上，若沒有常駐圖形登入，卻要讓內部工具永遠能連到本機的 127.0.0.1:7890 這類 mixed-port，就適合使用 /etc/systemd/system/mihomo.service，以 User 指向專屬帳戶、把 /etc/mihomo 與 /var/lib/mihomo 權限切乾淨。單元內的 After=network-online.target 在 Debian 上多數情況與 Ubuntu 類似，但若你的主機有 bridge／VPN 等延遲啟動的介面，仍要在首配後用 journalctl -u mihomo 觀察是否出現重試或綁定失敗。

8. UFW 與僅本機監聽：什麼時候才要開洞

Debian 12 上許多管理員慣用 ufw 作為 nftables 的簡化介面。若 mihomo 只監聽 127.0.0.1 的 mixed-port，通常不需要對 ufw 額外放行；但當你開了 allow-lan: true 或把綁定改到區域網路位址、或希望其他裝置打進 LAN 代理，就必須同時審查介面、來源 IP 範圍 與潛在的 DNAT，而不是只關 Clash 本身。

9. 驗證：ss、curl、journalctl 與桌面代理

啟用後，先用 ss -lntp 看 mihomo 是否在預期埠、預期介面，再用 curl -x http://127.0.0.1:7890 -I 測一個公開 HTTPS 端點（把埠改為你設定的 mixed-port）。服務層以 systemctl --user status mihomo 或 systemctl status mihomo 配合 journalctl -b -u mihomo 追日誌。桌面端在 GNOME 網路代理頁，HTTP 與 HTTPS 可填同組 127.0.0.1:7890；純 CLI 場景則在殼層匯出 http_proxy 等變數，必要時針對內部網段設定 no_proxy，避免內部儲庫也錯入代理。

10. 上游與授權（與下載入口分開說明）

mihomo 之開發、Issue 與版本說明可參考 MetaCubeX／mihomo 儲存庫。取得圖形客戶端或安裝包作為個人主機的替代路徑，仍以本站 下載頁 為主；本段連結的用途是審查原始碼與回報問題，與「一鍵下載可執行檔」分開，符合站內對 GitHub 的用途約定。