MIHOMO / PLATFORM MANUAL

Clash Metaの全OS向け導入・設定ガイド

このページでは、OSごとに導入、サブスクリプション、通信制御、トラブル対処の手順をまとめています。導入時に手順を確認しながら進められます。初めて使う場合は、まずサブスクリプションの追加と初回接続ガイドに沿って最短の手順を完了し、その後、各OSの章で権限、DNS、バックグラウンド動作の問題を確認してください。クライアントのインストーラーはクライアントのダウンロードページから選べます。

基本の流れ：サブスクリプションを準備 → クライアントをインストール → 設定を有効化 → ポリシーを選択 → 通信を制御 → リクエストを確認。クライアントによって画面上の名称は異なる場合があります。ここでは設定、プロキシ、接続、ログなどの機能を手がかりに説明し、特定の画面のボタン名をすべてのクライアントに共通する名称として扱いません。

共通の準備：サブスクリプション、コア、設定の管理

クライアント、コア、サブスクリプションの違い

クライアントは設定管理、画面操作、権限の取得、システムとの連携を担います。mihomoコアはポートの待ち受け、ルールの判定、出力先の選択、通信の転送を担います。サブスクリプションにはノード、または設定全体が含まれます。クライアントをインストールしただけでは、利用可能なプロキシ接続は作成されません。開始前に、有効なサブスクリプションがあり、その提供元にアクセスできること、また、提供されるのが設定全体なのかノード一覧のみなのかを確認してください。

設定全体には通常、プロキシノード、プロキシグループ、ルール、DNS設定が含まれます。ノード一覧のみの場合は、クライアントの設定テンプレートで残りを補う必要があります。どちらもYAML形式で返されることがあるため、拡張子だけでは判別できません。インポート後にノードは表示されても選択できるプロキシグループがない場合は、インポート方法とテンプレートを確認してください。ノードのサーバーアドレスをすぐに変更する必要はありません。Web上のサブスクリプション管理ページは、サブスクリプションAPIのURLとは異なります。提供元がクライアント用として案内しているリンクをコピーしてください。

サブスクリプションURLにはアカウントへのアクセス権が含まれる場合があるため、機密情報として扱ってください。公開の変換サイト、スクリーンショット、質問掲示板などに貼り付けないでください。設定を共有する前に、ノードのパスワード、サブスクリプションURL、コントロールAPIのキーを削除します。漏えいが確認された場合は、提供元でURLを再発行してください。トラブル対処用のスクリーンショットには、必要なエラーの種類、設定項目名、マスキング済みのドメインだけを残してください。ログ全体を送る場合も、事前に内容を確認してください。

元に戻せるテスト環境を用意する

インストール前に、OSのバージョン、プロセッサのアーキテクチャ、現在のネットワーク、既存のプロキシやVPNソフトを記録してください。初回のテストでは、通信を制御する他のプログラムを終了し、ネットワーク経路を明確にします。組織管理下の端末では、管理ポリシーによって制限されている場合があります。より高い権限を付与して組織の要件を回避しないでください。サービスのインストール、仮想ネットワークインターフェース、ルートの変更に管理者権限が必要な場合は、その目的を確認してから実行してください。

まずデフォルトのルールモードでシステムプロキシを有効にし、ブラウザーでアクセスできることを確認してから、必要に応じてTUNを追加します。問題が起きたときに、基本的なプロキシ接続と通信制御のどちらに原因があるか切り分けやすくなります。正常に動作する設定のコピーを保存し、変更前のシステムプロキシの状態も記録してください。一度に変更する設定項目は1つにします。DNS、ルール、ルートを一度にすべて上書きすると、ログを比較するための基準が失われます。

項目	役割	確認する場所
サブスクリプション設定	ノード、プロキシグループ、ルール、テンプレートの入力	設定の更新日時とインポートログ
システムプロキシ	システム設定に従うアプリにプロキシを提供	OSのプロキシ設定と接続ログ
TUN	仮想ネットワークインターフェースとルートで通信を制御	権限、インターフェース、ルート、DNSのログ
プロキシグループ	ルールに一致した接続のノードやポリシーを選択	現在の選択内容と実際の出力先の記録

まず設定を解析できることを確認し、次に接続を確認する

以下は、mihomoが起動してローカルポートを待ち受けられるか確認するための、直接接続のみの最小診断設定です。プロキシノードは含まれず、サブスクリプションの代わりにはなりません。混合ポートはHTTPとSOCKSの両方で接続できます。LANからのアクセスを無効にすると、待ち受け範囲をローカル端末に限定できます。すでにクライアントが同じポートを使用している場合は、どちらか一方を停止するか、テスト用に別の空きポートを指定してください。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

コアの設定チェックコマンドで確認できるのは、構文や一部の参照関係に問題がないことまでです。サブスクリプション内のサーバーに接続できることまでは確認できません。GUIクライアントは実行時の設定を生成することがあるため、確認対象はコアが実際に読み込むファイルです。サブスクリプションのキャッシュとは限りません。ログにインデントや未知のフィールドに関するエラーが出た場合は、表示された設定箇所より前も確認してください。原因が直前の行にあることもあります。

mihomo -t -f config.yaml

YAMLのインデントには半角スペースを使い、タブと混在させないでください。ルールで指定するポリシー名は、定義済みのプロキシグループ名またはノード名と一致させます。大文字・小文字や空白も一致している必要があります。リモートルールセット、プロキシプロバイダー、地理データベースを使用する場合は、それらをダウンロードできることも必要です。設定全体を読み込めても、依存リソースが利用できなければ正常に動作しないことがあります。トラブル対処では、設定の解析、リソースの読み込み、リクエストの転送を別々の段階として確認してください。

Windows：インストール、システムプロキシ、サービスの権限

インストーラーを選び、初回起動する

WindowsクライアントのダウンロードページからClash Plusを選択できます。他の候補はClash Verge Rev、FlClash、Clash Nyanpasuです。Clash for Windowsは開発が終了しています。アーカイブ版は旧環境の確認には使えますが、新規導入の標準としてはおすすめできません。まずシステム情報でプロセッサとシステムの種類を確認し、ダウンロードページに記載されたアーキテクチャとシステム要件を照合してください。他のプラットフォーム向けのインストーラーを互換性のあるものとして使わないでください。

インストール後は通常の方法でクライアントを起動してください。最初から画面全体を管理者として実行する必要はありません。サービスコンポーネントのインストールが必要な場合は、クライアントのサービス管理画面から実行し、システムの許可を確認してください。制限付きアカウントでサービスをインストールできない場合でも、まずシステムプロキシで基本的な接続を確認できます。サービスのインストール失敗とサブスクリプションの利用不可は別の問題です。サブスクリプションを何度も再インポートしても解決しません。

システムのセキュリティ警告で起動がブロックされた場合は、ダウンロード元、ファイルのプロパティ、組織のセキュリティポリシーを確認してから対応を判断してください。クライアントを起動するために、システムのセキュリティ機能を長期間無効にしないでください。インストール先、設定フォルダー、コアの実行フォルダーはそれぞれ異なります。古い設定を移行する際はクライアントのインポート機能を使い、古いコアやキャッシュのフォルダーを新しいインストール先に丸ごと上書きしないでください。

サブスクリプションを追加し、使用するポリシーを選ぶ

設定管理画面を開き、リモートサブスクリプションを追加して完全なURLを貼り付け、保存します。ダウンロードが完了したら、その設定を現在の設定として選び、プロキシ画面にプロキシグループが表示されるか確認してください。サブスクリプションにリダイレクトや特定のアクセス条件が必要な場合、失敗ログの原因はYAMLではなくネットワークの可能性があります。まず応答内容を確認し、ログインページを設定ファイルと誤認してインポートしないでください。

主要なプロキシグループで利用可能なノードを選び、クライアントの接続確認または遅延テストを実行します。テストに成功しても、テスト用のリクエストが完了したことを示すだけで、すべてのWebサイト、UDP、端末の通信が制御されているとは限りません。自動選択グループは後から出力先を切り替えることもあります。トラブル対処中はノードを1つに固定し、同じ宛先への結果を確認してから自動選択に戻してください。複数の条件を同時に変えないようにします。

ルールモードを有効にしてシステムプロキシをオンにし、Windowsのネットワークプロキシ設定でアドレスとポートがクライアントと一致するか確認してください。混合ポート、コントロールAPIのポート、サブスクリプションURLは別のものです。システムプロキシの設定は通常、現在のユーザーに適用されます。他のユーザーのセッション、システムサービス、一部の独立したアプリは従わない場合があります。そのため、ブラウザーが使えても、端末全体の通信がコアを経由しているとは限りません。

コマンドラインとTUNを分けて確認する

ターミナルのツールは環境変数を参照する場合もあれば、プロキシの明示的な指定が必要な場合もあります。以下のコマンドは、このリクエストに限ってローカルプロキシを指定します。ポート番号は実際の設定と一致させてください。まずプロキシの接続先を確認し、その後でターミナルに環境変数を設定するか判断します。環境変数を継続的に設定する前に、ツールが対応する変数名の大文字・小文字、プロキシのプロトコル、例外リストを確認してください。クライアント終了後も、ターミナルが古いポートへ接続しようとする事態を避けられます。

curl.exe --proxy http://127.0.0.1:7890 -I https://example.com

システムプロキシを参照しないプログラムの通信も制御する必要がある場合は、クライアントのTUNモードを有効にします。まずサービスが正常に動作していることを確認し、仮想ネットワークインターフェースの作成を許可して、インターフェースやルートのエラーがコアのログにないか確認してください。自動ルートを使う場合は、社内ネットワーク、LANプリンター、他のVPNへのアクセスに特に注意してください。競合が起きたら、除外ルートや通信の制御範囲を調整します。ネットワーク高速化ツールをさらに有効にして対処しないでください。

TUNを有効にしても接続できない場合は、TUNをオフにしてシステムプロキシで再確認してください。その直後にブラウザーが使えるようになった場合は、仮想インターフェース、デフォルトルート、DNS、他のVPNを重点的に確認します。どちらの方法でも失敗する場合は、ノードと設定に戻って確認してください。スリープからの復帰後やネットワーク切り替え後に問題が発生した場合も、この方法で比較します。まずインターフェースの状態を確認してから、コアやサービスの再起動を検討してください。

終了、更新、システムプロキシの設定残り

Windowsでは、ウィンドウの閉じるボタンを押してもトレイに最小化されるだけの場合があり、コアが停止したとは限りません。アンインストールやクライアントの切り替え前に、システムプロキシとTUNをオフにし、トレイから正常に終了してください。異常終了後もブラウザーがローカルプロキシに接続しようとする場合は、システムプロキシ設定が残っていないか確認します。元の状態に戻してからクライアントを起動してください。ソフトを終了した後にインターネットへ接続できないからといって、サブスクリプションの無効化が原因だと決めつけないでください。

更新前にカスタムルールとオーバーライド設定をエクスポートし、更新後に現在の設定、プロキシグループの選択、サービスの状態を確認してください。古いサービスがポートを使用中の場合や、移動済みのコアのパスを参照している場合があります。ポートが競合したら、タスクマネージャーまたはクライアントのログで使用元を確認し、想定したインスタンスだけを残してください。ブラウザーやターミナルに関する詳しい切り分けは、システムプロキシが反映されない場合の対処法をご覧ください。

macOS：アーキテクチャ、ネットワークサービス、バックグラウンドコンポーネント

プロセッサに合ったクライアントをインストールする

macOSのダウンロードページからClash Plusを選ぶのがおすすめです。使用スタイルに応じてClash Verge RevやFlClashも選べます。ClashX Metaは開発が終了しています。アーカイブ版と継続してメンテナンスされているクライアントは分けて検討してください。「このMacについて」でApple SiliconかIntelかを確認し、対応するインストーラーを選びます。互換レイヤーで動作しても、バックグラウンドコンポーネントや仮想ネットワークインターフェースの依存関係が現在のOSに対応しているとは限りません。

ディスクイメージ形式のインストーラーの場合は、マウント後にアプリをアプリケーションフォルダーへ移動し、そのフォルダーから起動してください。イメージ内から長期間実行しないでください。起動前にダウンロード元を確認し、システムのセキュリティ警告が表示された場合は、システムが案内するアプリの起動手順に従ってください。セキュリティチェック全体を無効にするコマンドは使わないでください。古いクライアントがインストール済みの場合は、まず正常に終了し、複数のメニューバーアプリが同時にプロキシ設定を変更しないようにします。

クライアントがヘルパーツール、バックグラウンドサービス、ネットワーク権限を要求した場合は、要求元のアプリと現在の操作が一致するか確認してください。一部の機能では特権ヘルパーがルートを設定しますが、通常のプロキシ画面を継続的に高い権限で実行する必要はありません。許可されなかった場合は、クライアントのサービス状態やシステム設定の関連項目を確認してください。権限の診断の代わりに、接続ボタンを何度も押さないでください。

サブスクリプションの追加とネットワークサービスの確認

設定画面でサブスクリプションを追加し、解析が終わったら現在の設定として選択します。続いてプロキシ画面で主要なプロキシグループを確認し、まずノードを1つに固定してリクエストをテストしてください。他のクライアントから設定を移行する場合は、相対パス、ルールセットのキャッシュ、プロバイダーファイルを特に確認します。以前のクライアントがダウンロード済みのファイルは、インポート時に引き継がれない場合があります。新しいクライアントで依存リソースを再取得する必要があることもあります。

システムプロキシを有効にしたら、現在使用中のネットワークサービスを確認してください。macOSにはWi-Fi、Ethernet、その他のインターフェースの設定を同時に保存できます。クライアントが変更したサービスが、実際にインターネットへ接続しているインターフェースと異なる場合があります。ドックや有線LANアダプターの接続、ネットワークロケーションの切り替え後は、メニューバーのアイコンだけで判断せず、設定を再確認してください。システムプロキシのアドレスはローカルの待ち受けポートを指定し、コントロールAPIのアドレスを指定しないでください。

まず次の読み取り専用コマンドで、システムに設定されているプロキシを確認し、明示的なプロキシ指定によるリクエストと比較できます。出力にプロキシ情報があっても、アプリが必ずその設定に従うとは限りません。ブラウザー拡張、アプリ独自の設定、ターミナルの環境変数が別の経路を作ることがあります。トラブル対処ではシステム設定とアプリ設定を分けて記録し、一方だけ変更してすべてのプログラムにすぐ反映されると考えないでください。

scutil --proxy
curl --proxy http://127.0.0.1:7890 -I https://example.com

TUNと他のネットワーク拡張機能の違い

システムプロキシを参照しないアプリの通信を制御する必要がある場合は、TUNを有効にし、クライアントのバックグラウンドコンポーネントが正常にインストールされていることを確認してください。インストールと権限の取得方法はクライアントごとに異なるため、現在の案内に従ってください。起動後はインターフェースとルートに関するログを確認し、画面上のスイッチだけが変わった状態ではないことを確かめます。社内VPN、ネットワークフィルターツール、別のプロキシクライアントを同時に使用する場合は、それぞれが制御するルートの範囲を確認してください。

LANへのアクセスに問題がある場合は、まず対象がローカルネットワーク内にあるか、リクエストが実際にどのルールに一致したかを確認してください。システムプロキシの除外リストが影響するのは、その設定を参照するプログラムだけです。TUNのルート除外やコアのルールを代替するものではありません。社内ドメインやプライベートIPアドレスには、必要なDNS設定と直接接続の経路を残してください。プライベートアドレスへのアクセス不具合をすべてノードの障害と見なさないでください。

画面を閉じた後の復帰、スリープからの復帰、Wi-Fiから有線ネットワークへの切り替え後は、古い接続が以前のネットワーク経路にひも付いたままの場合があります。まず対象へのリクエストを新しく発行し、新しい接続ログが記録されるか確認してください。必要に応じてクライアントを再接続するかコアを再起動しますが、設定をすべて削除しないでください。以前から開いているページだけが失敗し、新しい接続は正常な場合は、サブスクリプションよりも接続の再利用やネットワーク切り替えに原因がある可能性が高いです。

ターミナルの環境変数とアンインストール後の復元

ターミナルのプロキシ環境変数が影響するのは、該当するプロセスとその子プロセスです。システム全体の設定が自動で変わるわけではありません。既存の変数の用途がわからない場合は、シェルの設定を上書きしないでください。長期間設定する場合は、解除方法も用意し、社内ネットワーク向けの適切な例外を設定します。GUIから起動したアプリがターミナルの環境変数を引き継ぐとも限りません。ターミナルとブラウザーは別々に動作を確認してください。

アンインストール前に、システムプロキシ、TUN、ログイン時の起動設定をオフにしてから、クライアントの案内に従ってヘルパーサービスを削除してください。アプリをゴミ箱に移動するだけでは、バックグラウンドコンポーネントや古いプロキシ設定が残る場合があります。新しいクライアントに移行した後は、アクティビティモニタに古いコアが残っていないか確認し、現在のポート、設定、実際の出力先を確認してください。2つの通信制御方式の仕組みは、TUNとシステムプロキシの仕組みを段階別に比較をご覧ください。

Android：VPNの許可、アプリごとの通信制御、バックグラウンド動作

インストール前にアーキテクチャと設定の互換性を確認する

AndroidのダウンロードページからはClash Plusを選ぶのがおすすめです。他の候補にはClash Meta for Android、FlClash、Surfboardがあります。端末のアーキテクチャとクライアントの最低システム要件を確認してから、対応するパッケージをインストールしてください。アプリのインストール許可は、今回必要なブラウザーやファイルマネージャーに限定し、完了後は元の設定に戻せます。企業管理下の端末では、アプリのインストールポリシーにも従ってください。

同じプロキシエコシステムのクライアントでも、設定形式が完全に共通とは限りません。Clash Plus、Clash Meta for Android、FlClashの対応範囲は、それぞれの実装に従います。Surfboardは異なる設定体系を使うため、任意のmihomo設定全体をそのままインポートしても、すべてのルールが有効になるわけではありません。サブスクリプションの提供元が複数の形式に対応している場合は、使用するクライアントに明確に対応した形式を選んでください。

古いアプリから移行する場合は、残しておきたいカスタム設定をエクスポートしてから、新しいアプリをインストールしてください。Androidでは通常、パッケージ名の異なるアプリを上書きインストールできません。古いアプリをアンインストールすると、アプリ専用の設定やキャッシュが削除されることもあります。サブスクリプションがクリップボードに残っていることだけに頼らず、信頼できる場所にインポート情報を保存してください。新しいクライアントで設定を読み込めることを確認してから、古い環境を削除します。

サブスクリプションを追加してVPNに接続する

設定一覧を開き、リモートサブスクリプションを追加してダウンロード完了を待ち、その設定を有効な設定として選択します。起動する前にプロキシグループが表示されるか、ノードのテストが成功するか確認してください。初回起動時には、通常、システムのVPN許可ダイアログが表示されます。許可するとアプリがローカルの通信制御用トンネルを作成できるようになりますが、リモートノードの安全性をシステムが確認するわけではありません。また、すべてのアプリのリクエストがプロキシ経由になるとも限りません。

Androidでは通常、同じユーザー領域で同時に有効にできるVPNサービスは1つです。他のVPN、ファイアウォール、ローカルVPNを使うフィルターツールがクライアントと競合すると、接続が置き換わる、起動直後に切断される、特定のアプリだけネットワークに接続できなくなることがあります。テスト中は競合するプログラムを停止し、通信を制御する入口を1つにしてください。仕事用プロファイルと個人用プロファイルでは制限が異なる場合があるため、実際に使っているプロファイルをそれぞれ確認してください。

モバイル端末のVPNによる通信制御と、デスクトップOSのシステムプロキシは別の設定です。通常、Wi-Fi設定でプロキシを手動入力する必要はありません。端末内のプロキシを重ねて設定すると、経路の切り分けが難しくなる場合があります。システムにVPN接続済みと表示されても、トンネルサービスが存在することを示すだけです。接続ログでリクエストに一致したルール、プロキシグループ、実際の出力先を確認してください。

アプリごとの通信制御では、まずリストの意味を確認する

アプリごとの通信制御を有効にする前に、一覧が選択したアプリだけをプロキシするのか、選択したアプリを除外するのか確認してください。同じ項目を選んでも、モードによって結果が逆になることがあります。まずブラウザーを1つ選んでテストし、開いているページを閉じて新しい接続を行い、ログを確認します。一覧を変更した後、設定を適用するためにVPNの再作成が必要なクライアントもあります。チェックマークだけを見て、システムが制御する範囲が更新されたと判断しないでください。

アプリの一覧はどの通信をクライアントに渡すかを決め、ルールは渡された通信にどのポリシーを適用するかを決めます。この2つは互いに代用できません。除外されたアプリの通信は通常、コアのルール判定を通りません。一方、対象に含まれたアプリでも、ルールが直接接続を指定すれば宛先に直結します。アプリの通信がプロキシを経由しているか確認するには、対象アプリの一覧、マッチしたルール、最終的な出力先をあわせて確認してください。メイン画面の接続ボタンだけでは判断できません。

バックグラウンド動作、バッテリー、ネットワーク切り替えの対処

画面を表示しているときは正常でも、ロック後に接続が切れる場合は、バックグラウンド動作、バッテリー使用、自動起動がシステムに制限されていないか確認してください。端末メーカーの設定で、必要なバックグラウンド権限をクライアントに許可します。バッテリー消費が増える可能性も理解しておいてください。バックグラウンド通知はサービスの動作状態を確認するのに役立つため、通知を隠すためにシステム要件を損なわないでください。端末の再起動後は、画面が復元しただけでなく、クライアントが実際に再接続したか確認してください。

Wi-Fiからモバイルネットワークに切り替えると、古い接続が切れ、アプリがリクエストを再発行する必要が生じることがあります。モバイルデータの使用許可と、新しいネットワークから現在のノードに接続できるか確認し、VPNが有効なままか調べてください。常時接続VPNやVPN未経由の接続をブロックする設定が有効な場合、クライアントの切断時にシステムポリシーによってネットワークが遮断されることがあります。これは保護のための動作です。想定に合わせて設定してください。

サブスクリプションの更新に失敗した場合は、まず端末の日時、サブスクリプションの有効性、現在のネットワーク、ストレージの空き容量を確認します。更新だけが失敗し、既存のノードでは接続できるかも確認してください。特定のアプリだけに問題がある場合は、アプリの通信制御対象、独自DNS、UDPの利用、アプリ自身のキャッシュを調べます。クライアントのデータをすべて消去しないでください。対処後にアプリを再起動して新しい接続を作り、変更が古いセッションではなく新しいリクエストに反映されたことを確認します。

iOS：App Storeからのインストール、設定の追加、VPN接続の確認

クライアントをインストールし、サブスクリプションの形式を確認する

iPhoneとiPadにはClash Plusがおすすめです。当サイトのiOSクライアントページで案内を確認するか、Clash PlusのApp Storeページを直接開いてください。クライアントの公式サイトはclashplus.ioです。インストール前に、App Storeに記載されたOSの互換性、機能、権限を確認してください。デスクトップ版のメニュー操作をモバイル版にそのまま当てはめないでください。

iOSの通信制御には、システムが提供するネットワーク拡張機能を使います。デスクトップ版mihomoの実行ファイルをインストールするわけではありません。ルール、サブスクリプション形式、拡張フィールドの対応範囲はクライアントの実装によって異なります。デスクトップで読み込める設定でも、すべての項目がiPhoneで同じように機能するとは限りません。移行前に、必要なノードプロトコル、ルールの種類、DNS機能が対応しているか確認してください。

サブスクリプションの提供元がクライアント専用リンクを用意している場合は、対応するリンクを優先してください。管理ページ、QRコード、共有ボタンしかない場合は、リンク先が設定内容なのかアカウントページなのかを確認します。QRコードはURLを伝える手段であり、設定形式を自動変換するものではありません。インポート後は設定一覧、プロキシグループ、ノードの内容を確認してください。新しい設定名が1つ表示されただけで、インポートが完全に成功したと判断しないでください。

リモートサブスクリプションとローカルファイルを分けて管理する

リモートサブスクリプションは通常、設定画面でリンクを追加します。保存後にダウンロードと解析を待ち、現在の設定として選択してください。ローカルファイルはクライアントのファイルインポート機能か、OSの共有機能から開きます。ファイルのインポートは、その時点の内容のコピーです。後から更新される関係が維持されるとは限りません。ノードを継続して更新する必要がある場合は、同名ファイルを繰り返しインポートするのではなく、クライアントにリモートの取得元が登録されていることを確認してください。

ファイルアプリでは見えるのにインポートできない場合は、内容が実際に設定テキストなのか、クラウドからのダウンロードが完了しているか、クライアントがその形式に対応しているか確認してください。メールの添付ファイルやWebからのダウンロードでは、圧縮ファイル、エラーページ、別形式の文書が保存される場合があります。拡張子を変更するだけでは解決できません。サブスクリプションの提供元から正しい内容を取得し直し、インポート時のエラーメッセージを確認してください。

インポート後は、まずプロキシグループでノードを1つ選んでテストし、その後に接続を開始します。自動選択グループのテスト先と実際の通信先は異なることがあります。テストに成功しても特定のアプリだけ失敗する場合は、ノードを次々に切り替えず、そのアプリの接続ログとルールを確認してください。ノードを手動で固定すると安定した比較ができます。確認後は、日常使用に適したポリシーに戻してください。

VPNの許可とシステムが通信を制御する範囲を理解する

初回起動時に、システムがVPN設定の追加と端末認証を求める場合があります。許可する前に、要求元がインストールしたばかりのクライアントであることを確認してください。許可の完了と接続の成功は別の段階です。システムに他のVPN設定がある場合は、現在どれが有効か確認してください。接続ボタンがオンになった後も、実際にリクエストを送信して、クライアントに接続が記録されるか確認する必要があります。

iOSでは、デスクトップのシステムプロキシと同じ操作をしないでください。明確なLANプロキシのテスト中でない限り、Wi-Fiの手動プロキシ設定を追加で変更する必要はありません。ルールモードでは、リクエストごとに直接接続かプロキシかを選択できます。VPNアイコンが表示されても、すべての宛先が同じプロキシノードを使うとは限りません。アプリ独自のネットワーク処理によって、ログで確認できるドメインやプロトコルが変わることもあります。

システム管理ポリシーが適用された端末では、アプリごとのVPN、管理対象ネットワーク、アクセス制限が設定されている場合があります。一般の個人向けクライアントで、これらのポリシーを上書きすることはできません。仕事用アプリだけ異なる経路を使う場合は、まず端末の管理範囲を確認してから、管理担当者に相談してください。プロキシ動作を統一しようとして組織の設定を削除すると、仕事用アカウントやコンプライアンスに影響する可能性があります。

ロック解除後の復帰とアプリごとのトラブル

ロック解除後にアプリへ戻ったら、ネットワークが復帰するのを待ってから新しいリクエストを送信してください。古い接続がタイムアウトしても、ネットワーク拡張機能が終了したとは限りません。メイン画面が常に前面で動作し続ける必要もありません。Wi-Fiとモバイルネットワークを頻繁に切り替える場合は、問題が起きたときのネットワークの種類、現在のポリシー、VPNの状態を記録し、条件を分けて再確認してください。一度に変更する条件を1つにすれば、ネットワークの切り替え問題をサブスクリプションのエラーと誤認しにくくなります。

ブラウザーや特定のアプリだけに問題がある場合は、古い接続が残っていないか、独自の名前解決を使っていないか、特別な直接接続ルールに一致していないか確認します。まず対象のアプリを通常の方法で終了して再起動し、新しい接続を確認してください。すべてのシステムネットワーク設定のリセットを最初に行わないでください。他のネットワーク情報まで影響を受ける一方、リモートノード、ルールの参照先、設定形式のエラーは解決しない場合があります。

クライアントの更新や削除の前に、サブスクリプションの取得元とカスタムルールを保存してください。端末のバックアップから復元した後も、現在の設定とVPNの許可を確認します。キャッシュ、サブスクリプション、システム権限が同じ状態に戻るとは限りません。入手からインポートまでの詳しい手順は、iPhone版クライアントの入手と設定のインポート手順をご覧ください。設定が反映されたかどうかは、実際の接続ログと対象へのアクセス結果で確認してください。

Linux：デスクトップクライアントとmihomoサービスの導入

デスクトップとサーバーのどちらで使うか決める

デスクトップ環境ではLinuxのダウンロードページからClash Verge RevまたはFlClashを選び、ディストリビューションとダウンロードページに対応する形式でインストールできます。サーバー、ルーター、プロセスを細かく管理する環境では、mihomoコアを使用できます。バイナリを選ぶ際は、プロセッサのアーキテクチャ、ディストリビューションの環境、必要な命令セットを確認してください。ファイルを展開できても、現在の端末で使えるとは限りません。

デスクトップクライアントでサブスクリプションを追加し、設定やポリシーを選択する手順は、他のデスクトップOSとほぼ同じです。ただし、システムプロキシの設定はデスクトップ環境に依存します。ブラウザー、ターミナル、コンテナ、バックグラウンドサービスが参照する設定は異なる場合があります。デスクトップのプロキシスイッチがシステム全体のルートを統一するわけではありません。初回テストではプロキシを明示してリクエストし、その後、アプリの環境変数、デスクトッププロキシ、TUNのどれを使うか決めてください。

ネイティブコアを導入する場合は、まず展開して、信頼できるバイナリに実行権限を付与し、想定した場所に配置します。ここでは実行ファイルが/usr/local/bin/mihomoにインストールされ、設定ファイルは現在のユーザーのホームディレクトリにあるものとします。最初は一般ユーザーで基本的なプロキシを起動し、いきなりroot権限を使わないでください。設定ファイルと参照先のローカルルールファイルは実行ユーザーが読み取れる必要があります。キャッシュを書き込むディレクトリには書き込み権限も必要です。

mkdir -p ~/.config/mihomo
/usr/local/bin/mihomo -t -d ~/.config/mihomo
/usr/local/bin/mihomo -d ~/.config/mihomo

サブスクリプションの内容をshellコマンドとして実行しない

ネイティブコアには、GUIクライアントのようなサブスクリプション管理画面はありません。設定全体は作業ディレクトリのconfig.yamlとして保存してください。ノード一覧しかない場合は、プロキシグループ、ルール、その他の必須設定を自分で補うか、クライアントで管理します。信頼できる方法でダウンロードしたら、内容と構文を確認してください。リモートから返された内容をそのままshellに渡して実行したり、機密性の高いサブスクリプションURLをコマンド履歴に残したりしないでください。

自動更新は、一時ファイルをダウンロードして成功を確認してから置き換える手順にし、前回の正常な設定を残してください。コアのチェックに合格した後、管理された方法で再読み込みまたは再起動します。リモートの応答を稼働中のファイルに直接上書きすると、ネットワークエラーの際にエラーページが設定ファイルとして保存される場合があります。リモートのノードプロバイダーを使う場合は、プロバイダー名、キャッシュのパス、更新間隔、参照するプロキシグループが一致しているかも確認してください。

起動後はまずログを確認し、ローカルの混合ポートにリクエストを送信してください。LAN内の他の端末にもプロキシを使わせる場合に限り、待ち受けアドレス、ファイアウォール、アクセス制御を調整してください。接続入口やコントロールAPIをすべてのネットワークに公開しないでください。特にリモートサーバーでは、ループバックインターフェース、LANアドレス、グローバルIPアドレスを区別してください。テストに便利な設定を長期間公開したままにしないようにします。

ユーザーサービスでプロセスを管理する

systemdのユーザーサービスに対応するディストリビューションでは、親ディレクトリを作成してから、以下を~/.config/systemd/user/mihomo.serviceに保存できます。これは前述のインストール先と一般的なプロキシ待ち受けを前提としており、TUN用の追加権限は付与しません。サービスの役割はコアの実行に限定します。サブスクリプションの更新や権限の設定は別途設計し、すべての保守処理を起動コマンドに埋め込まないでください。

[Unit]
Description=Mihomo user proxy

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

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now mihomo.service
systemctl --user status mihomo.service
journalctl --user -u mihomo.service -n 80 --no-pager

ユーザーサービスは通常ユーザーセッションに合わせて動作します。ログアウト後も動き続けるかどうかは、システムのユーザー管理設定によって異なります。常時稼働が必要なサーバーでは、導入ポリシーに応じたシステムサービスまたはユーザー常駐の方式を選んでください。サービスを有効にしただけで、起動時から永久に動作すると考えないでください。設定を変更した後は、チェックしてから再起動し、サービスの状態と直近のログを確認します。起動コマンドでエラーが出なかったことだけを導入成功の根拠にしないでください。

TUN、DNS、コンテナの注意点

LinuxでTUNを使うには、利用可能な仮想ネットワークデバイスと、適切なネットワーク管理権限が必要です。一般ユーザーのサービスに、これらの権限が自動的に与えられるわけではありません。有効にする前に、クライアントやサービスがどのように権限を取得し、ルートを書き込み、終了時に元の状態へ戻すのか確認してください。以下は一般的な設定項目の例であり、動作中の設定に追加する必要があります。ノードは含まれず、ホスト側の権限準備の代わりにもならないため、設定ファイル全体を置き換える目的では使わないでください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

DNSを確認する際は、システムのリゾルバー、コアのDNS、アプリ独自の暗号化DNSを区別してください。systemd-resolvedを使う端末では、ローカルのスタブリゾルバーと待ち受けアドレスの競合にも注意が必要です。コンテナは独立したネットワーク名前空間を持ち、コンテナ内のループバックアドレスはホスト側と同じではありません。ホストのプロキシが使えても、コンテナでは別途、接続経路、プロキシ環境変数、ルートを設定する必要がある場合があります。

サービスの停止や設定のロールバック後は、関連するルート、名前解決の設定、環境変数が想定した状態に戻っているか確認してください。接続に問題がある場合は、まず明示的なプロキシとTUNの結果を比較し、その後でインターフェースとファイアウォールを確認します。ルールをすべて消去することから始めないでください。リモートで保守する際は独立した管理用接続を残し、ルート変更で現在のセッションが切断され、ログの確認やロールバックができなくなる事態を避けてください。

設定に関するよくある質問：リクエストの経路から原因を探す

サブスクリプションの更新失敗と設定の読み込み失敗

まず、ダウンロードの失敗、応答内容の誤り、設定の解析失敗を区別してください。ダウンロード失敗では、ネットワーク、URL、アカウントの状態、証明書、端末の日時を確認します。ダウンロードできてもWebページが返る場合は、URLがサブスクリプションAPIのものか確認してください。解析に失敗する場合は、YAMLの該当箇所、フィールドの型、コアとの互換性を確認します。エラーの種類ごとに対処方法は異なります。更新ボタンを何度押しても、足りない設定項目は補われません。

現在の設定で接続できるのに更新だけ失敗する場合は、動作中の状態を保ったまま、サブスクリプションの取得経路を個別に調べてください。サブスクリプションのドメインは直接接続が必要な場合も、現在のネットワークで制限されている場合もあります。まだ読み込みに成功していないプロキシグループを更新に使い、循環依存させないでください。更新時に使うプロキシを変更する前に、元の設定を記録します。更新に成功したら、ローカルルールやプロキシグループの選択が上書きされていないか確認してください。

ルールセットや地理データベースのエラーが発生した場合は、すべてのルールを削除するのではなく、参照名、ダウンロード先、関連ログを確認してください。GEOIPはIPアドレスのデータに依存し、GEOSITEはドメインデータまたは対応する設定機能に依存します。リソースが見つからない問題と、ルールの適用結果が期待と異なる問題は別です。リソースの更新後は、対象への新しい接続を作り、実際に一致したルールを確認してください。既存の接続は、新しいルールを確認するための確実なサンプルにはなりません。

ルールの順序、ポリシーの参照、DNS

ルールは上から順番に照合され、最初に一致した項目のポリシーが使われます。個別のドメインルールは、より広範なルールより前に置き、最後にフォールバックルールを置いてください。以下の例では、PROXYがproxy-groupsで定義済みである必要があり、GEOIPには利用可能なデータベースも必要です。これはルールの例であり、接続可能な設定全体ではありません。サブスクリプション内の名称が異なる場合は、参照先もあわせて変更してください。エラーを無視してそのまま貼り付けないでください。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

ルールモード、グローバルモード、直接接続モードでは、ポリシーの評価経路が変わります。トラブル対処の際は現在のモードを確認してください。グローバルモードのままrulesを変更しても反映されません。自動テストグループ、フェイルオーバーグループ、手動選択グループでは、判断条件が異なります。グループ名だけで実際の動作が決まるわけではありません。中国国内・海外の振り分けルールの詳しい書き方は、mihomoルールによる通信の振り分け実践ガイドをご覧ください。

fake-ipは合成アドレスとマッピング情報を使ってドメイン名を関連付けます。テスト用のネットワーク範囲のアドレスが表示されても、すぐにDNS汚染と判断する必要はありません。アプリが古いマッピングをキャッシュしている、コアを経由せずに名前解決している、独自の暗号化DNSを使っている場合は、ルールから確認できる情報が変わることがあります。まず名前解決の経路を確認し、クライアントの方法で関連キャッシュを更新してください。根本原因を隠すためにすべてのドメインをフィルターリストへ追加すると、ドメインによる振り分けの仕組みがわかりにくくなる場合があります。

ノードのテストは成功するのに接続先へアクセスできない

遅延テストでは特定の宛先とプロトコルを使用します。成功しても、そのテストが完了したことを示すだけです。対象のWebサイトで制限されている、別のポートやUDPが必要、接続元の地域条件があるといった可能性があります。まずノードを1つに固定し、ブラウザーまたはコマンドラインから同じ宛先へアクセスしてログを確認してください。失敗したリクエストがコアに届いているか、どのルールに一致し、最終的にどの出力先が選ばれたかを比べる方が、テスト先を何度も変更するより有効です。

ブラウザーは使えるのにターミナルだけ失敗する場合は、プロキシを明示して確認します。ターミナルは使えるのにブラウザーが失敗する場合は、ブラウザー拡張、独自プロキシ、キャッシュを確認してください。すべてのアプリで失敗する場合は、コアの待ち受け、ノードへの接続、DNSを確認します。TUNだけが失敗する場合は、権限、インターフェース、ルートを優先して確認してください。初回の確認手順は、ノードの選び方とプロキシ接続の確認方法をご覧ください。

症状	まず確認すること	次の手順
接続ログがない	アプリのプロキシ設定とシステムが制御する範囲	プロキシを明示したリクエストと比較する
ログに直接接続と表示される	動作モードと最初に一致したルール	ルールの順序とポリシーの参照先を確認する
プロキシ経由の接続が失敗する	ノード、プロトコル、リモート側のエラー	ノードを固定して同じ宛先をテストする
TUNだけが失敗する	権限、仮想インターフェース、DNS、ルート	TUNをオフにし、システムプロキシと比較する

有効な診断情報と元に戻す手段を残す

サブスクリプション更新後にカスタムルールが消えるのはなぜですか？

リモート設定は更新時に全体が置き換わることがあります。長期的に使うルールは、クライアントが対応するオーバーライドまたはマージ機能に移し、最終的に生成された設定で順序を確認してください。編集画面だけを確認しないでください。実際に有効なのは、コアが現在読み込んでいる設定です。変更前に正常な設定のコピーを保存し、1つのルールを戻すためにサブスクリプション全体を失わないようにしてください。

TUNを有効にした後も、システムプロキシを使う必要がありますか？

通信を制御する範囲とクライアントの実装によります。両方を必ず同時に有効にする必要はありません。まずシステムプロキシとTUNを個別にテストしてから、組み合わせて使うか判断してください。両方を使う場合は通信がループしないこと、LANや管理用接続にアクセスできることを確認します。ブラウザーのプロキシだけが必要なら、まずはよりシンプルな方式を使うとよいでしょう。

問題を記録する際は、OS、クライアント名、有効な設定、通信制御方式、失敗した宛先、発生までの手順を残し、直近の変更も記載してください。必要な場合だけログレベルを一時的に上げ、再現後に元へ戻します。機密情報を含むログを長期間保存しないでください。再インストールしても、リモートのサブスクリプション、接続先サービス、誤ったルールは通常修復されません。まずリクエストの経路に沿って原因を絞り込み、変更の効果を確認してから新しい設定の基準として保存してください。