まずは選択：GUIクライアントか単体コアか

mihomo は Clash の設定形式に対応したプロキシコアで、Clash Meta と表記された設定やクライアントでよく使われます。コアはプロキシポートの待ち受け、ルールの判定、接続の確立を担います。一方、GUIクライアントにはサブスクリプション管理、ノード選択、システムプロキシの切り替え機能があります。コアをインストールしただけでは、トレイアイコンは表示されず、ブラウザーのプロキシ設定も変更されません。

利用環境おすすめの方法主な管理方法
GNOME、KDE などのデスクトップ環境Linux対応のGUIクライアント画面上でサブスクリプションを追加し、ルールやノードを切り替える
SSHで管理するサーバーmihomo バイナリと systemd の組み合わせYAMLを編集し、サービスログを確認する
コンテナや軽量ディストリビューションまず init システムを確認PID 1 が systemd でない場合は、環境に合ったプロセスマネージャーを使用

この記事で紹介するサービス構成は、systemd を使用する一般的な Linux ホストを対象としています。まずはローカルホストからのみ利用できる明示的プロキシを設定します。明示的プロキシとは、アプリケーションが指定ポートにリクエストを送る方式です。透過プロキシではなく、サーバー上のすべての通信を自動的に引き受けるものでもありません。

デスクトップ環境：Linuxクライアントをインストールして設定を追加

ディストリビューションとCPUアーキテクチャを確認する

ターミナルを開き、次の2つのコマンドを実行します。1つ目でディストリビューションを、2つ目でカーネルが認識しているCPUアーキテクチャを確認できます。x86_64 は通常、配布パッケージの x64 または amd64 に、aarch64 は通常 arm64 に対応します。Intel製またはAMD製のマシンだからといって、ARM版をダウンロードしないでください。

cat /etc/os-release
uname -m
  1. インストーラーページを開き、Linux向けパッケージが提供されているクライアント（Clash Verge Rev や FlClash など）を選びます。ダウンロード前に、対象のOSとアーキテクチャに対応しているか確認してください。
  2. Debian・Ubuntu系では対応するDEBパッケージを、Fedoraなどでは対応するRPMパッケージを選びます。AppImageを利用できるかどうかは、配布元が提供しているか、またFUSEなどの実行時依存関係が揃っているかによります。
  3. クライアントを起動し、サブスクリプションまたは設定の管理画面でサブスクリプションURLを追加して更新し、使う設定を選択します。メニュー名はクライアントによって「サブスクリプション」や「設定」など異なります。ノード共有用の文字列を、完全なYAMLファイルとして読み込まないでください。
  4. まずルールモードと利用可能なノードを選択してから、システムプロキシを有効にします。接続ログを確認し、リクエストが現在のクライアントに届いていることを確かめてください。

ローカルにダウンロードしたインストーラーを client.deb にリネームした場合、ファイルのあるディレクトリで sudo apt install ./client.deb を実行できます。このファイル名は利用者が任意に変更したもので、このサイトのダウンロードURLを示すものではありません。RPMパッケージも同様に client.rpm にリネームしてから、sudo dnf install ./client.rpm を実行できます。

システムプロキシとターミナルのプロキシを区別する

GNOMEデスクトップでは、「設定」→「ネットワーク」→「ネットワークプロキシ」で現在の設定を確認できます。具体的な項目の場所はデスクトップのバージョンによって多少異なります。ブラウザーはこの設定に従う場合がありますが、ターミナルのコマンドラインツールが読み込むとは限りません。まずクライアントに表示されている混合ポートを確認してください。ポートが7890なら、システム設定を何度も切り替えるのではなく、以下の curl --proxy で個別にテストできます。

デスクトップの「ログイン時に起動」とサーバーの「起動時に自動起動」は別の仕組みです。前者は通常、ユーザーがグラフィカルセッションにログインしている必要があります。後者は誰もログインしていない状態でも動作できます。SSH接続後すぐにプロキシを使いたいサーバーには、次に紹介する systemd の構成が適しています。

サーバーの準備：バイナリの配置と専用実行アカウント

まず ps -p 1 -o comm= を実行し、出力が systemd であることを確認します。次に uname -m の結果に合った mihomo の Linux バイナリを入手して展開し、ファイル名を mihomo に変更します。x86向けの配布物は、CPU命令セットの要件が異なる場合もあります。Illegal instruction が表示されたら、実行権限を追加するのではなく、ビルド要件を再確認してください。

以下のコマンドは、ターミナルの現在のディレクトリに展開済みの mihomo ファイルがあることを前提としています。まず実行権限を付与し、プログラムを実行できるか確認します。-v で実際にインストールされたバージョンが表示されるため、記録やロールバックに役立ちます。

chmod +x ./mihomo
./mihomo -v
sudo install -m 0755 ./mihomo /usr/local/bin/mihomo

sudo useradd --system --user-group \
  --home-dir /var/lib/mihomo \
  --shell /usr/sbin/nologin mihomo

sudo install -d -o root -g mihomo -m 0750 /etc/mihomo

ここでは、対話型ログインには使わない専用のシステムアカウントを作成します。すでに mihomo アカウントがある場合は、まず id mihomo でアカウントとグループを確認し、作成手順を飛ばしてください。専用アカウントを使うと、設定ファイルの読み取り権限と実行データ用ディレクトリを管理しやすくなります。この構成では、サービス全体を root で実行する必要はありません。

  • /usr/local/bin/mihomo：コアの実行ファイルを配置します。
  • /etc/mihomo/config.yaml：管理者が保守する設定ファイルを配置します。
  • /var/lib/mihomo：実行データを保存します。後述の systemd ユニットが作成し、アクセス権を設定します。

最小構成のYAMLで設定とポートを確認する

YAMLはインデントで項目を構成するテキスト形式です。インデントにはスペースを使い、タブは使わないでください。まず次の最小構成で起動の基準を作ります。ローカルホストの7890番ポートだけで待ち受け、HTTPプロキシとSOCKS5接続を受け付けます。すべてのリクエストは直接接続され、プロキシノードは含まれません。

sudo tee /etc/mihomo/config.yaml > /dev/null <<'YAML'
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

rules:
  - MATCH,DIRECT
YAML

sudo chown root:mihomo /etc/mihomo/config.yaml
sudo chmod 0640 /etc/mihomo/config.yaml

sudo -u mihomo /usr/local/bin/mihomo \
  -t -d /tmp -f /etc/mihomo/config.yaml

実際にトラフィックを振り分けるには、信頼できる提供元の完全な mihomo 設定に置き換えてください。完全な設定には通常、proxies、proxy-groups、rules が含まれ、ルールで参照するポリシーグループ名も定義されている必要があります。ノード一覧だけの provider ファイル、Base64形式のノード文字列、サブスクリプションページは、-f にそのまま渡せる完全な設定ではありません。

設定を置き換えた後も、ローカルホストのみで待ち受ける安全な構成を維持し、設定チェックを再度実行してください。サブスクリプションURLにはアクセストークンが含まれる場合があり、設定ファイルにはノードの認証情報が含まれることもあります。公開ログやスクリーンショット、シェル履歴に貼り付けないでください。実際の設定で相対パスを使う場合、このサービスのデータディレクトリは /var/lib/mihomo です。ルールファイルやproviderファイルを読み取れることも確認してください。

systemd サービスを作成して自動起動を設定する

systemd のサービスユニットでは、プロセスの起動方法、実行アカウント、失敗時の処理を定義します。次の内容を /etc/systemd/system/mihomo.service に保存してください。このユニットは通常のプロキシポート向けで、TUNの設定やネットワーク管理権限の付与は行いません。

sudo tee /etc/systemd/system/mihomo.service > /dev/null <<'UNIT'
[Unit]
Description=mihomo local proxy service
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=mihomo
Group=mihomo
StateDirectory=mihomo
StateDirectoryMode=0750
ExecStartPre=/usr/local/bin/mihomo -t -d /var/lib/mihomo -f /etc/mihomo/config.yaml
ExecStart=/usr/local/bin/mihomo -d /var/lib/mihomo -f /etc/mihomo/config.yaml
Restart=on-failure
RestartSec=5s
UMask=0077
NoNewPrivileges=true
PrivateTmp=true
ProtectHome=true
ProtectSystem=strict

[Install]
WantedBy=multi-user.target
UNIT

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
systemctl status mihomo --no-pager
systemctl is-enabled mihomo

active (running) と表示されていれば、プロセスは実行中です。is-enabled の出力が enabled なら、自動起動に設定されています。両方を個別に確認してください。自動起動が設定済みでも、設定エラーによって起動に失敗する場合があります。

StateDirectory=mihomo は書き込み可能なデータディレクトリを作成します。ProtectSystem=strict はその他のファイルシステムへの書き込みを制限し、ProtectHome=true はユーザーのホームディレクトリへのアクセスを制限します。そのため、設定から /home 内のサブスクリプションファイルを参照しないでください。追加のファイルが必要な場合は、適切なデータディレクトリに配置し、所有者と権限を確認してください。

network-online.target は、ネットワーク接続が確立してから起動する順序を表します。ただし、効果はディストリビューションで対応するネットワーク待機サービスが有効になっているかどうかにも左右され、サブスクリプションサーバーへの接続を保証するものではありません。外部からルールをダウンロードする設定では、ログを確認してネットワーク待機の問題か、リモートリソースの停止かを切り分けてください。

設定を変更した後の手順

sudo -u mihomo /usr/local/bin/mihomo \
  -t -d /var/lib/mihomo -f /etc/mihomo/config.yaml
sudo systemctl restart mihomo
sudo journalctl -u mihomo -n 80 --no-pager

最初の設定チェックに成功してから、サービスを再起動してください。YAMLを変更した場合は daemon-reload は不要ですが、サービスユニットを変更した場合は必要です。この例では ExecReload を定義していないため、再起動の代わりに systemctl reload mihomo を実行しないでください。再起動すると既存のプロキシ接続が切れるため、大容量ダウンロード中やリモート作業中は避けましょう。

リクエストを検証する：待ち受け、HTTPプロキシ、SOCKS5

「プロセスの稼働 → ポートの待ち受け → アプリからのリクエスト → ルールの適用」の順に確認します。まず7890番ポートを確認してください。待ち受けアドレスは 127.0.0.1:7890 であるべきで、パブリックインターフェースではありません。

sudo ss -lntp 'sport = :7890'

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -I https://example.com

curl --proxy socks5h://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -I https://example.com

ここでの10秒は接続タイムアウトの上限、20秒はリクエスト全体の制限時間であり、性能測定の結果ではありません。socks5h では宛先ドメインの名前解決をプロキシ側に任せます。socks5 では通常 curl がローカルで名前解決するため、DNSの問題を調べる際の判断が変わります。

最小構成でリクエストに成功しても、確認できるのはローカルのプロキシ経路と直接接続の出口が使えることだけです。実際の設定に置き換えた後は、ログでルールとポリシーグループの選択を確認し、トラフィックが DIRECT に一致していないことを確かめてください。HTTPステータスコードが表示されただけでは、リモートノード経由で通信した証拠にはなりません。

現在のターミナルだけでプロキシを使う

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

curl -I --max-time 20 https://example.com

unset http_proxy https_proxy no_proxy

https_proxy の値に http:// を指定しても、クライアントがHTTPプロキシ経由でCONNECTトンネルを確立するという意味であり、宛先のHTTPS通信を平文にするわけではありません。環境変数の影響を受けるのは、それらを読み込むプログラムだけです。すでに起動している systemd サービスは、現在のターミナルの設定を自動的に引き継ぎません。ここでは小文字の変数を使い、一部のツールで大文字の HTTP_PROXY が特別扱いされる問題も避けています。

よくあるトラブルと運用上の注意

起動に失敗する、または再起動を繰り返す

  • 203/EXEC が表示される場合：ExecStart のパス、ファイルの実行権限、バイナリのアーキテクチャを確認してください。展開前の圧縮ファイルを実行パスに置かないでください。
  • address already in use が表示される場合：ss で7890番ポートを使用中のプロセスを特定します。よくある原因は、別のGUIクライアントや古いコアです。
  • permission denied が表示される場合：設定ファイルのグループが mihomo になっているか、パス上の各ディレクトリにアクセスできるか確認してください。機密情報を含む設定を、すべてのユーザーが読めるように変更しないでください。
  • YAMLの解析エラーが表示される場合：インデント、コロン、リストの階層を確認してください。特に、Webページからコピーした際にタブが混入していないか注意しましょう。-t によるチェックを通してから起動してください。
  • 起動回数の制限に達した場合：まず原因を修正してから、sudo systemctl reset-failed mihomo と sudo systemctl start mihomo を実行してください。何度も再起動するだけでは解決しません。

サブスクリプション更新、管理API、TUN

単体コアには、GUIクライアントの「サブスクリプション更新」機能はありません。完全なリモート設定を使う場合は、取得と置き換えの方法を別途用意してください。更新時は一度一時ファイルにダウンロードし、権限を制限して構文をチェックしてから、現在の設定と置き換えます。設定内の proxy-providers は指定した更新間隔でノード一覧を更新できますが、メイン設定全体が更新されるわけではありません。

この例では external-controller を有効にしていないため、管理APIは提供されません。管理画面が必要な場合は、ループバックでの待ち受け、アクセスキー、SSHトンネルを計画し、管理ポートをインターネットに直接公開しないでください。allow-lan: false とローカルホストでの待ち受けを組み合わせているため、ほかのLAN内端末からこのサーバーを直接プロキシとして利用することもできません。

TUNは仮想ネットワークインターフェースで通信を取り込む方式で、/dev/net/tun、ルーティング、DNS、ネットワーク権限も関係します。この記事の一般ユーザー向けアカウントとハードニング済みユニットは、TUN用の構成ではありません。enable: true を1行追加するだけで完了するものではありません。SSHで管理するサーバーでは特に、管理接続用の直接通信経路を確保してから、透過的に通信を取り込む構成を検討してください。

アップデートとサービスの停止

アップデート前に mihomo -v の結果を記録し、現在のバイナリと設定をバックアップしてください。サービスを停止してからバイナリを置き換え、新しいファイルのアーキテクチャ、バージョン、設定との互換性を確認します。最後に起動し、ポートとリクエストを再確認してください。サービスを停止して自動起動を無効にするには、次のコマンドを実行します。設定と実行データは削除されません。

sudo systemctl disable --now mihomo

最終確認では、設定チェックの成功、サービスの稼働状態、想定どおりの待ち受けアドレス、実際のアプリ通信へのルール適用の4点を確認してください。デスクトップ環境では設定の選択とシステムプロキシ、サーバー環境ではアカウント権限、サービスログ、再現可能な起動手順を重点的に確認します。