📖 教學 ⏱ 約 19 分鐘閱讀

CentOS Stream 9／RHEL 9 安裝 Mihomo（Meta）：二進位部署、訂閱匯入與 systemd 開機自啟

在企業或實驗室常見的 RHEL 系（CentOS Stream 9、RHEL 9）上，許多人的目標很清楚：不要圖形介面、不靠發行版內建套件，而是直接使用官方釋出的 Mihomo（Clash Meta 系核心）二進位，把設定檔路徑、訂閱與開機行為一次寫死成可維運的形狀。本篇針對無圖形介面伺服器與SSH 遠端管理情境，從 Release 下載、目錄權限、最小可用 config.yaml、到 systemd 單元與 SELinux／firewalld 的注意點，依實務除錯順序整理，方便和站內 Debian 系、Fedora、Arch 等題材互補檢索。

這篇適合誰、與圖形客戶端路線有什麼不同？

若你本來在桌面環境習慣 Clash Verge 這類圖形包裝，底層多半已經是 Mihomo 核心；但在 CentOS Stream 9 或 RHEL 9 的純伺服器上，通常沒有 Tray 圖示、也沒有「按鈕匯入訂閱」這條捷徑，你面對的是檔案、權限、服務管理器三件事。相對於套件庫裡不一定跟上核心版進度的情況，自行放置官方釋出的單一二進位往往最能控制版本與稽核來源，也比較符合企業變更流程：下載檔可留 checksum、安裝腳本可收進版本庫。

若你希望對照「桌面＋systemd 使用者服務」的思路，可讀Ubuntu 24.04 上 Clash Verge 與 systemd 自啟；若你關心 Red Hat 系上SELinux與防火牆與圖形客戶端並存的經驗，可併讀Fedora 上 Clash Verge、SELinux 與 firewalld——觀念與RHEL 9高度可比。以下則專注在純命令列＋系統服務。

開始前：版本、帳號與合規

Mihomo專案由社群維護，發行成品見於公開的 GitHub Releases；實務上請只從你能驗證的正式釋出頁取得檔案，並在企業環境依內部資安流程登記版本與雜湊。本文僅示範技術路徑：如何放置執行檔、如何指定設定目錄、如何讓程序在開機後穩定拉起；請確保你對上游訂閱／節點服務的使用符合所在地法規與公司政策。

帳號方面，生產環境不建議長期以 root 身份跑應用程式；較穩健的是建立專用系統使用者（例如 mihomo），由該使用者擁有設定目錄與快取檔，再以 systemd 的 User=／Group= 限制權限。本文範例會同時說明固定路徑概念，你可在內部規範中對應到實際帳號與目錄命名。

安裝基底工具方面，CentOS Stream 9與RHEL 9皆預設 dnf；需有可用軟體庫以下載 curl、tar 等（商業版 RHEL 需先完成訂閱與啟用對應頻道）。若機器在無法直連外網的維護網段，可先於允許連線的主機下載 Release 成品與校驗資訊後，再以內部傳檔方式佈署到目標機。

第一步：確認 CPU 架構並下載對應二進位

在伺服器上執行 uname -m：x86_64 對應常見的 linux-amd64壓縮包；aarch64 則對應 linux-arm64。選錯架構會導致執行檔根本無法啟動，這是編譯型二進位部署最常見的一類「低級但致命」錯誤。下載後請習慣記錄版號與校驗方式（專案若提供 checksum 檔，應一併保存），以利事後稽核與升級回滾。

解壓後你會得到名為 mihomo（或階段性釋出所附檔名，仍以實際壓縮包為準）的執行檔。建議將其安裝到 /usr/local/bin/mihomo 這類PATH 內穩定路徑，而不是留在 /root/Downloads；後者容易在清理或換維運人員時被誤刪。安裝後以 chmod 755 確保具備執行權限，並避免把含敏感訂閱的目錄放在全體可讀位置。

💡 小提示 升級核心時，請先備份整個設定目錄（至少 config.yaml 與 providers 資料夾），再替換二進位；雙檔並存一段過渡期，遇到不相容語法時才好快速切回。

第二步：建立工作目錄與檔案結構

以下以 /etc/mihomo 為例（實務上亦常見使用 /var/lib/mihomo 搭配狀態檔，依你廠內標準為準）。目錄內至少需要：

  • 主設定檔 config.yaml：連接埠、模式、規則與群組。
  • 訂閱快取位置：例如 ./providers/，供 proxy-providers 下載後落地（實際相對路徑須與設定一致）。
  • 選用規則集／Geo 資料：若你啟用規則集，需確保程序對該路徑可讀寫並有足夠磁碟。

權限上，若服務以專用使用者執行，請以 chown -R mihomo:mihomo /etc/mihomo（示例）避免程序無法寫入提供者快取。反過來，若你把訂閱 URL 明文寫在設定檔中，也應限制檔案權限為僅該使用者可讀，降低同機其他帳號外泄風險。

第三步：撰寫最小可用的 config.yaml（含訂閱提供者）

無圖形介面時，「匯入訂閱」在實作上就是把訂閱網址放進 proxy-providers，讓核心按排程抓取並轉成節點清單。下列為教學用骨架：請將訂閱位址替換為你合法取得者，並依節點特性補上規則（此處只示範全走一群組，實務上多半會拆 DIRECT／REJECT 與細緻分流）。

# /etc/mihomo/config.yaml 範例骨架（請替換 YOUR_SUB_URL）
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxy-providers:
  sub:
    type: http
    url: "YOUR_SUB_URL"
    path: ./providers/sub.yaml
    interval: 3600
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 300

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

rules:
  - MATCH,PROXY

幾個與「首次跑起來」強相關的欄位說明：mixed-port同時承載 HTTP 與 SOCKS 客戶端常見需求；external-controller讓本機能用 REST 方式查狀態（務必勿對外網敞開，除非你清楚風險並另有加密／存取控制）。interval與健康檢查會影響對上游的請求頻率，內網或小型 VPS 可適度放寬以免被服務商标記為異常流量。

若你對訂閱連結為何會失效、如何與服務商儀表板對齊，建議延伸閱讀訂閱連結那些事；若你已能連線但想細調分流，可再對照自訂規則教學。

第四步：手動啟動驗證（一定要在加 systemd 之前）

在還沒寫入 systemd 前，先以前景或短暫背景方式跑一次：

sudo -u mihomo /usr/local/bin/mihomo -d /etc/mihomo

觀察終端輸出是否成功下載 providers、是否監聽預期埠。另開工作階段測試（示例）：

curl -x http://127.0.0.1:7890 -I https://www.example.com

若此處失敗，請不要急著把問題丟給 systemd；先確認訂閱、時間同步、DNS、以及本機是否已有其他程式占用同埠。若你懷疑作業系統層的 stub resolver 與核心假 IP 行為彼此打架，思路可對照Linux 上 Clash 與 systemd-resolved 的 DNS 排查——重點仍是單一事實來源，而不是同時開多套互相覆寫的解析鏈。

第五步：撰寫 systemd 單元並設定開機自啟

確認手動啟動沒問題後，新增 /etc/systemd/system/mihomo.service（檔名可自訂，但需與後續 enable 名稱一致）。範例：

[Unit]
Description=Mihomo (Clash Meta)
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=3
# 若使用 TUN 或需細網路能力，需依安全評估調整；純本機 mixed-port 可視情況精簡
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_ADMIN
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

接著執行：

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo.service
sudo systemctl status mihomo.service

status應顯示 active (running)；若為 failed，請立刻 journalctl -u mihomo.service -e看是因為權限、YAML 語法、還是網路連線失敗。實務上最常見的是設定目錄擁有者與 User=不一致，或 providers 目錄不可寫。

SELinux、firewalld 與「允許區網連進來」

RHEL 9預設啟用 SELinux；多數僅監聽 127.0.0.1 的情境不會與政策正面衝突，但若你打開 TUN、透明轉發、或讓程式對外介面綁定，就可能要調整政策或使用官方／內部核准的模組。起手式排查可包含 getenforce、檢視 AVC 拒絕記錄，再決定是否該申請政策變更，而不是在生產機器上長期設為寬鬆模式。

firewalld方面，預設本機迴環不受阻，但如果你設定 allow-lan: true並希望同網段其他主機用你這台的混合埠，必須另外在防火牆開對應埠並評估來源 IP 限制。企業內網常搭配僅管理網段可存取，避免把代理埠暴露給不可信任區。

維運習慣：日誌、升級與設定備份

把 Mihomo當正式服務時，建議固定：設定目錄納入備份、升級前快照、以及將 systemd 重啟策略寫清楚（例如 Restart=on-failure）。升級二進位後若規則集格式或內部欄位不相容，日誌會在啟動早期報錯；此時應先回滾二進位或修正設定，而不是重複 restart 造成上游訂閱端被連續抓取。

對於需要宣告式管理的環境，也可參考站內NixOS、Flake 與 Mihomo 的 systemd 使用者服務類題材，對照「可重現佈署」的思維如何映射到你廠內的 Ansible／Kickstart 流程；核心是同一段 desired state可被多人審核、重放。

若想從全站角度把「安裝—訂閱—分流」串起來，也可瀏覽Clash 使用教學主頁，把本文當成 RHEL 系伺服器分支篇章。下載與渠道整理仍以下載頁為準。

常見問題

RHEL 9 上為什麼服務能啟動但本機 curl 仍走不到代理？

多半是環境變數未設定 http_proxy／HTTPS_PROXY，或者你測試時使用的目標位址其實被規則指到直連。另請確認你是連向 127.0.0.1:7890（或你實際的 mixed-port），而不是從其他主機打到未開放或被防火牆擋住的介面。

啟用 TUN 模式時 systemd 服務失敗怎麼辦？

TUN 涉及路由與虛擬介面，需要的能力與 SELinux 上下文比一般「本機 HTTP 代理」複雜。建議先用 mixed-port／規則驗證訂閱與出口正常，再逐步開啟 TUN；並閱讀你所使用版本對 capability、進階路由與閉源驅動相依的說明，必要時在變更單上註記風險與回滾步驟。

企業內網只能透過代理抓 GitHub Release 時怎麼安裝？

可在允許外連的維護主機下載 artifacts 與 checksum，再經內部鏡像或嚴格控管的傳檔流程送到目標機；重點是完整性驗證與授權來源可追溯，而不是繞過資安檢查。若內部已有標準化的「供應鏈下載代理」，應優先使用該管道以便稽核。

整體來說，在CentOS Stream 9／RHEL 9這種長週期企業發行版上，用官方二進位裝好 Mihomo並不是「比桌面多打幾行指令」而已，而是要把權限邊界、服務行為與稽核證據一次想清楚。相較之下，部分只提供圖形精靈或高度封閉設定檔格式的同類工具，在純 SSH 與變更審查流程較嚴的環境裡，往往較難與《標準作業》對齊，也不好做版本差異比對；Clash／Mihomo這條開放生態則讓設定即文字、行為可觀測，搭配圖形客戶端或自動化都靈活。若你也想在本機或團隊環境用同一套規則心智模型驗證節點與分流，不妨從本站整理的下載與教學起點開始——→ 前往免費下載 Clash，延續分流式代理工作流程。