📖 チュートリアル ⏱ 約22分で読めます

CentOS Stream 9／RHEL 9 に Mihomo（Meta）をインストールする：公式バイナリ・systemd 常駐・購読インポート（ヘッドレス向け）

CentOS Stream 9 や RHEL 9 のような RHEL 系サーバーで、グラフィック無し環境へ Mihomo（従来通称の Clash Meta に相当する単体実装）だけを載せ、「公式リリースの Linux バイナリ → 適切な 構成パス → systemd で 起動自動化 → プロバイダの購読URLから初回構成」までをひとつの流れにまとめた実践ガイドです。DNF とリポジトリ制御、および firewalld を伴う環境にも触れ、既存の Debian/Ubuntu デスクトップ向け記事と切り口を変えました。

この記事が想定する読者と、他 Linux ガイドとの棲み分け

対象は SSH だけ触るヘッドレスで、企業イントラの CentOS Stream 9 や検証サーバーの RHEL 9 で「コアのみ常駐」したい方です。Fedora ワークステーション向けには GUI と SELinux／firewalld の整理を優先した Fedora 向け Clash Verge 記事 があり、そちらとは前提が異なります。Debian 12 と Clash Verge（デスクトップ）の構成は Debian の稿 に集約しました。自分の環境キーワードに合わせて記事を選ぶだけで時間の節約になります。Mihomo と Clash Meta という名前のゆれについては概観記事として Meta と Premium の比較 もあります。nix flake での恒久式管理は別の問題領域のため省略し、読者が検索語に含めやすい RHEL／CentOS と単体バイナリ systemd に絞っています。

まず用語だけ整理すると。mihomo と呼ばれる実行体は、UI のないまま YAML を読み、ローカルに mixed-port や SOCKS、必要なら TUN を割り当てます。GUI 版が内部で同種のコードを読み込んでいる例もあり、画面の話とコアのみの運用とはトラブルシュートの順序が異なります。全体俯瞰は エコシステム解説 を読むと速いです。操作の共通イメージは チュートリアルインデックス と合わせると頭のなかでの対応関係が掴みやすくなります。

事前確認：OS 版とアーキテクチャ、そして法的・社内遵守

cat /etc/os-release で CentOS Stream 9／RHEL 9 相当であることを確認してください。アーキテクチャは uname -m で x86_64 か aarch64 かを押さえ、リリース資産名に反映します。社内マシンであれば、外部通信・プロキシ・ログの社内規程に違反しないかを先に確認してください。本稿は技術手順の例示であり、利用可否の判断は読者側のポリシーに従います。

最低限、取得と展開のために curl／wget と tar（場合によっては gzip）が使えるとよいです。必要に応じて次のように入れます（環境のポリシーでリポジトリが制限されている場合は社内手順に合わせてください）。

sudo dnf install -y curl tar gzip

公式リリースからバイナリを取得して配置する

Mihomo の最新版は GitHub Releases にまとまっており、見出しに linux-amd64 や linux-arm64、互換性の注記が付いたビルド名が並びます。時期によっては -compatible などの接尾辞が付くため、一覧をよく読み、自分の glibc 世代に合うパッケージを選びます。固定版を使うならバージョン番号を変数に入れてから curl -L -o で落とし、展開して単一バイナリを取り出します。コマンド例は次の形です（URL とファイル名は実際のリリース表記に必ず置き換えてください）。

cd /tmp
curl -LO "https://github.com/MetaCubeX/mihomo/releases/download/vREPLACE/mihomo-linux-amd64-vREPLACE.gz"
gunzip -f mihomo-linux-amd64-vREPLACE.gz
sudo install -m 0755 mihomo-linux-amd64-vREPLACE /usr/local/bin/mihomo
/usr/local/bin/mihomo -v

/usr/local/bin はパスが通りやすく、OS パッケージと衝突しにくい典型例です。別パスに置く場合は後述の systemd の ExecStart と揃えてください。バイナリは公式以外から拾わないこと、SHA256 や署名の検証を社内基準で行うこと、を推奨します。クライアント群の入口は ダウンロードページ に集約してあるため、まずそこで入手導線を確認し、コア単体の取得はリリースページで行う、という二段構えが迷子を減らします。

設定ディレクトリとメイン YAML の骨格

システム全体でサービス運用するなら /etc/mihomo が分かりやすいことが多く、ログやプロバイダキャッシュには /var/lib/mihomo を使う構成も見られます。ここでは例として両方とも root 管理前提で並記します。

sudo mkdir -p /etc/mihomo/providers /var/lib/mihomo
sudo chown -R root:root /etc/mihomo /var/lib/mihomo

最小の起動だけを狙う構成ではない「実務で足りやすい骨格」を示します。購読URL はプロバイダが配る HTTPS のエンドポイントに読み替え、User-Agent 要件があれば proxy-providers 側の header で足します。external-controller はサーバー内だけに閉じるなら 127.0.0.1、管理用に限定開放するなら社内方針に沿ってバインドし、必ず secret を強い乱数にします。

sudo tee /etc/mihomo/config.yaml <<'EOF'
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: 'CHANGE_ME_TO_A_LONG_RANDOM'

proxy-providers:
  sub1:
    type: http
    url: "https://example.com/your-subscription-url"
    path: /var/lib/mihomo/providers/sub1.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

proxy-groups:
  - name: SELECT
    type: select
    use:
      - sub1

rules:
  - MATCH,SELECT
EOF

この例はあくまで雛形です。地域ルールや社内向け GEOIP、社内ドメインの DIRECT 例外などは運用に合わせて後段に足してください。ルールの書き方の土台は カスタムルールのガイド が参考になります。購読が失敗する典型は 購読 FAQ に整理してあります。

💡 ヒント メイン構成を自動生成ツールへ丸投げしないのが安全です。providers 以下は更新で上書きされる前提で、自分で触るのは rules やグループ側に寄せると事故が少なくなります。

SELinux とファイルコンテキスト

RHEL 9 系では SELinux が enforcing のままで動く環境が多く、単体バイナリや独自パスにおいて拒否イベントが残ることがあります。まずは journalctl と ausearch -m avc で「何パスが弾かれたか」を読みます。RPM 由来でない実行ファイルでも、適切な fcontext を限定付与したうえで restorecon するだけで済むことがあります。「とりあえず permissive」は切り分けには使えますが、恒久運用としてはログに沿った是正を優先してください。

systemd で常駐化する

ユーザーセッションではなく マルチユーザーターゲット 向けに、root のユニットを置くパターンを示します。-d は構成ディレクトリを指します。

sudo tee /etc/systemd/system/mihomo.service <<'EOF'
[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=3
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target
EOF

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

TUN を有効にするほど CAP_NET_ADMIN などカーネル側の許可が要る構成が増えます。要件がなければまずは ローカルの mixed／SOCKS とアプリ側の環境変数／プログラム指定で十分かを検証します。レイヤごとの考え方は TUN モード記事 に詳しく書いてあります。ログは journalctl -u mihomo -b --no-pager で追えます。単純監視のみなら curl での疎通とあわせ、必要に応じて社内監視基盤へメトリクスを送る設計にします。

firewalld とリッスン範囲

この例では allow-lan: false とし、待受をローカルに閉じています。別ホストから同サーバーのプロキシを使うなら allow-lan とバインドを見直し、firewalld で必要最小限のゾーンにポート追加が要るケースがあります。手順の形は Fedora ガイドの firewall-cmd と同種です。社内ゲートウェイや上流プロキシが挟まれる場合は、アウトバウンドのパスだけでなく、購読取得のタイムアウトもセットでログに出ていないかを確認してください。

疎通と DNS 異常の切り分け

サービスが active でも、アプリが期待どおりに流れないことがあります。まずは次のように HTTP プロキシ経由で外部疎通を見ます（ポート番号は自分の mixed-port に合わせます）。

curl -I --proxy http://127.0.0.1:7890 https://www.gstatic.com/generate_204

ここまで通ればプロキシの出口までは生きている可能性が高いです。名前解決がループしていたり systemd-resolved と fake-ip の組み合わせで期待とズレていたりすると、体感は「サイトがすべて死んでいる」に近くなります。Linux での代表的なチェックリストは Linux DNS 切り分け記事 にありますので、構成を広げたら必ず並読してください。

アップデートとロールバック

コアのみの長所は手順がシンプルなことです。新しい単体ファイルを並行取得し、サービス停止 → 実行体の退避ディレクトリへ退避 → 新規バイナリを install → サービス開始、の順だと復帰も容易です。メジャー変更で YAML キーの非互換 が増えるときは Release Notes とサンプル構成の差分を先に読み、アップグレード前に構成のバックアップを別パスへ複製してください。

よくある質問

root で systemd を使うしかないか

サービス運用が root 直下であれば単純です。非 root で動かしたいときはユーザー向けディレクトリと capabilities の付与方法を読み替える必要があります。GUI ユーザー向け自動起動の発想が近いのは Debian 側のユーザーユニット例です。

Podman などコンテナでの実行は

可能ですが、ポート公開とプロセス権限、cgroup の制約が絡むため本稿よりもコンテナ側の資料を主に参照した方が早いことが多いです。ホスト側に単体実行体を載せておく構成の方が手数は少なくなりがちです。

OpenShift 環境とも言えるか

OpenShift と混同されがちですが、本稿の範囲は通常のサーバー OS でのサービス単位の話です。Kubernetes 側のサイドカー構成は運用モデルが別です。

まとめ

CentOS Stream 9／RHEL 9 において GUI を介さず Mihomo を載せる流れは、①アーキに合わせた単体ファイルの確実な取得、②/etc/mihomo など恒久パスの整理、③購読 URL 駆動のプロバイダ YAML、④systemd ユニットで常駐化、⑤journalctl と curl による確認、という五段になります。社内ゲートウェイや DPI フィルタ、SELinux と DNS は「バイナリが動いた直後より先」で効いてくる典型なので、最初から全体を一段ずつ増やしてください。

同じような用途でも、伝統的な単一トンネル型のVPN クライアントは OS 全域をまとめて乗せ替える前提のため、アプリ単位での迂回や国内直結を細かくしたいワークロードとは相性が分かれます。また、構成をスクリプトで暗黙に書き換えるスタイルだと変更履歴が追いづらく、障害復旧に時間がかかることがあります。

一方で Clash 系ツールなら、アプリ単位またはドメイン単位のルールを YAML でバージョン管理しやすく、デスクトップからサーバーまで同じ構成思想を転用できる点が運用側の負荷を下げやすいです。GUI とコアのみの両方があるため、ワークステーションとデータセンターで役割分担もしやすいでしょう。まず全体像と入手経路は Clash を無料ダウンロード に揃えると、この後読む資料の読みどころも明快になります。

→ 本サイトから Clash を入手し、RHEL / CentOS と合わせて他端末にも展開してみる