なぜ Linux では Mihomo を直接動かすのか

Windows や macOS 向けの Clash Verge Rev のような GUI 記事は多い一方、サーバーやミニマル環境では画面がなくてもプロキシだけ欲しいケースがよくあります。Mihomo（旧 Clash Meta 系コア）は Clash 互換の YAML をそのまま活かしやすく、コマンドラインと設定ファイルだけで運用できます。さらに systemd に載せれば、クラッシュ時の再起動やブート時の自動起動、journalctl による一元ログという「サーバーらしい」運用が可能になります。

サブスクリプション URL から config.yaml をどう用意するかまだ不安な場合は、先にサブスクリプション取り込みの記事で全体像を押さえてから本稿に戻るとスムーズです。

対象ディストリビューションとアーキテクチャ

以下は systemd を採用している一般的なディストリビューション（Debian 系、Ubuntu、Fedora、Arch など）を想定しています。Init が異なる環境でも「実行ファイル＋設定ディレクトリ＋スーパーバイザ」という発想は同じです。

CPU アーキテクチャはリリース資産と一致させる必要があります。多くの PC とクラウド VM は amd64、Raspberry Pi や一部 ARM インスタンスは arm64 です。取得前に uname -m で確認し、誤ったバイナリを置かないようにしてください。

ダウンロード、実行権限、配置パス

GitHub Releases から Linux 向けアーカイブを入手し、mihomo バイナリを取り出します。配置例は次のとおりです。

  • システム全体で使うなら /usr/local/bin/mihomo
  • 単一ユーザーなら ~/.local/bin/mihomo（PATH に含める）
  • chmod +x を必ず実行
  • 本番では公開されているハッシュ値で改ざん検知できると安心です

Mihomo が従来の Clash コアとどう違い、どのプロトコルが使えるかはコアアップグレードガイドも参照してください。Linux に置く前の知識整理に役立ちます。

設定ディレクトリと読み込み方法

Mihomo は -d で設定ディレクトリを指定します。中に config.yaml が必要です。例としてユーザー別なら ~/.config/mihomo、共有ゲートウェイなら /etc/mihomo が扱いやすいです。

設定の入れ方は大きく三つあります。プロバイダが配布する完成 YAML をそのまま保存する方法、proxy-providers でリモート購読 URL を引く方法、他クライアントからエクスポートした互換 YAML をコピーする方法です。いずれも mixed-port や external-controller のポートが既存サービスと衝突していないか確認してください。

TUN による透過プロキシは権限とルーティングの話が増えます。まずは HTTP/SOCKS の常駐まで成功させ、必要になったらTUN モードの記事で段階的に進めるのが安全です。

フォアグラウンドでの起動テスト

systemd 化の前に必ず対話的に確認します。

mihomo -d ~/.config/mihomo

ログに設定読み込みやリスナー待受が出るか、YAML のインデントミスや未知フィールド、ポート競合がないかを見ます。問題なければ Ctrl+C で止め、同じコマンドラインをユニットに写します。

systemd ユーザーサービス（デスクトップ／単一ユーザー向け）

~/.config/systemd/user/mihomo.service を作成し、次の例を実パスに合わせます。

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

[Service]
Type=simple
ExecStart=/usr/local/bin/mihomo -d /home/ユーザー名/.config/mihomo
Restart=on-failure
RestartSec=3
LimitNOFILE=65536

[Install]
WantedBy=default.target

続けて systemctl --user daemon-reload、systemctl --user enable --now mihomo.service を実行します。SSH サーバーではログアウト後もユーザーサービスを残したい場合、sudo loginctl enable-linger ユーザー名 が必要になることがあります。

systemd システムサービス（共有機器向け）

/etc/systemd/system/mihomo.service に ExecStart=/usr/local/bin/mihomo -d /etc/mihomo のように書き、sudo systemctl enable --now mihomo で有効化します。設定には秘密情報が含まれるため、ディレクトリ権限を厳しめに設定してください。

動作確認：API・ポート・ログ

external-controller が 127.0.0.1:9090 なら curl http://127.0.0.1:9090/version で JSON に mihomo が含まれるか確認します。リスナーは ss -tlnp などで見られます。

ログはユーザーユニットなら journalctl --user -u mihomo.service -f、システムユニットなら sudo journalctl -u mihomo.service -f です。一時的に log-level を上げるときは容量とプライバシーに注意してください。

セキュリティと更新の心得

不要なら root で常駐させない、設定ファイルのパーミッションを絞る、更新時はサービス停止→バイナリ差し替え→再起動、の順を守ると事故が減ります。設定管理ツールでテンプレート化する場合も、最終 YAML のバックアップを残しておくとロールバックが早いです。

よくあるつまずき

ポートが使用中

YAML のポート番号を空いている値に変えるか、競合プロセスを止めます。

実行できない／形式エラー

アーキテクチャの取り違えや実行権限不足が典型です。再ダウンロードと chmod +x を確認します。

SELinux で拒否される

audit2why で原因を特定し、ルールを調整します。安易な無効化は避けましょう。

それでも原因が掴めないときはトラブルシューティング記事で DNS や購読側の問題を切り分けてください。

GUI が便利な場合

コマンドライン運用はサーバー向きですが、デスクトップではノード切り替えや診断 UI が欲しくなることもあります。Clash Verge Rev は最新 Mihomo コアを同梱しており、同じエコシステムを保ったまま視覚的に管理できます。

用途に合わせて「SSH で systemd」「ローカルはクライアント」と役割分担すると長く快適に使えます。まずは公式ビルドで体験してみてください。→ Clash を無料ダウンロードして、快適な接続体験を始める