Clashの使い方ガイド：
インストール・分岐設定・メンテナンス

1. 基本概念：クライアント、コア、設定

画面と処理を担う層を区別する

Clashのクライアントは通常、グラフィカルな画面とプロキシコアで構成されています。画面ではサブスクリプションの読み込み、ポリシーグループの表示、設定変更、システム権限の許可などを行います。コアはローカルポートで待ち受け、接続情報を解析し、ルールに照合して外部への接続を確立します。画面が起動していても、コアが正常に動作しているとは限りません。コアが動作していても、システムの通信がプロキシに送られているとは限りません。トラブル時はこの2つを分けて確認すると、何度も再インストールするより効率的です。

mihomoは、このエコシステムで広く使われているコアです。クライアントによって同梱するコアが異なり、変更できる項目に制限がある場合もあります。同じ設定を複数の端末で使えるかどうかは、ファイルの拡張子ではなく、プロトコル、ルールの種類、コアの機能、プラットフォームの対応状況によって決まります。別の端末へ移行する際は、サブスクリプションやポリシー構成を引き継いだうえで、ポート、ファイルパス、ネットワークインターフェース名など、端末固有の設定を確認してください。ローカル設定をすべてそのまま上書きするのは避けましょう。

通信が通過する流れ

処理の流れは4段階で考えられます。アプリがリクエストを送信し、通信がローカルのプロキシ入口に入り、コアがモードとルールに基づいて接続先を選び、最後に直接接続またはリモートプロキシ経由で目的のサーバーにアクセスします。システムプロキシとTUNが主に担うのは2段階目、ルールとポリシーグループが担うのは3段階目、ノードのプロトコルが関わるのは4段階目です。ウェブページが開かない原因はどの段階にもあり得ます。「ノードを変更する」だけではなく、通信の入口や名前解決も確認しましょう。

設定ファイルは、これらの段階の関係を定義します。proxiesはプロキシを定義し、proxy-groupsはプロキシを選択式または自動テスト式のグループにまとめ、rulesは接続をルールの順に各ポリシーへ振り分けます。サブスクリプションには設定一式が含まれる場合も、ノード情報だけの場合もあります。ノード情報のみの場合、ポリシーグループとルールを補うテンプレートが必要です。サブスクリプションを読み込めても、分岐設定が整っているとは限りません。

ノードはリモートサービスへの接続情報、ポリシーグループはノードのまとめ方です。両者を混同しないようにしましょう。Proxyという名前のポリシーグループは、特定のノードを選択したり、別のポリシーグループを参照したりできます。直結ポリシーのDIRECTは、リモートプロキシを経由せずに接続することを示します。グループ名は通常、設定の作成者が決めるため、統一された名称はありません。後の例では参照関係を説明するためにProxyを使います。実際に変更する際は、ご自身の設定に合わせてください。

ローカルポートとDNSの役割

ローカルの待ち受けポートは、アプリからコアへ接続する入口です。混合ポートでは、HTTPプロキシとSOCKSプロキシの一般的な接続を同じポートで受け付けられますが、すべてのアプリの通信を自動で取り込むわけではありません。DNSはドメイン名をIPアドレスに変換し、ドメインルールを適切なタイミングで判定できるかにも影響します。ブラウザーが独自の暗号化DNSを使い、システムが別のリゾルバーを使っていると、同じ接続先でも通信経路が異なることがあります。ログ上のドメイン名と実際の接続先をあわせて確認しましょう。

利用を始める前に、ソフトウェアとネットワークサービスの違いも理解しておきましょう。クライアントをインストールしても、使えるリモートプロキシが自動で用意されるわけではありません。利用するには、自分で保有し、使用権限のある設定が必要です。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、パスワードと同様に管理してください。スクリーンショットやログ、問い合わせ内容から情報が漏れることもあります。共有する前に完全なURL、アカウント識別情報、ノードの認証情報を削除し、問題に関係する項目とエラーだけを残しましょう。

この章のゴールは、すべての用語を暗記することではありません。現在使っているクライアントとコアは何か、設定はどこから読み込まれているか、アプリはどの入口からコアに接続するか、この3点を説明できることです。記録しておけば、システムプロキシが効かない、ルールに一致しない、サブスクリプションを更新できないといった問題が起きても、設定を次々に切り替えるのではなく、適切な箇所から確認できます。

2. クライアント選び：プラットフォームと用途から考える

継続して使えるクライアントを選ぶ

クライアント選びでは、見た目よりも、端末のOS、プロセッサーのアーキテクチャ、利用目的を優先しましょう。初めて使う場合はClash Plusを候補にし、クライアントのダウンロードページでOSに合ったインストール方法を選べます。設定の編集や接続の確認を頻繁に行う場合、または特定のコア機能が必要な場合は、ほかのクライアントと比較してください。古い記事のスクリーンショットだけを頼りに選ぶのは避けましょう。メニューが似ていても、現在のOSへの対応状況や権限の手順まで同じとは限りません。

デスクトップでは、タスクトレイ常駐、システムプロキシ、自動起動、設定の上書き、TUNなどがよく使われます。モバイルでは、システムVPNの許可、バックグラウンド動作、スリープ後の接続復帰が重要です。必要な機能を2～3個に絞り、対応クライアントの説明を確認しましょう。使う予定のない高度な機能は、選定基準にしなくてもかまいません。機能が多くても初期設定が簡単になるとは限らず、ほかのネットワークソフトとの互換性が高まるとも限りません。

アーキテクチャ、設定の互換性、旧クライアント

プロセッサーのアーキテクチャとOS名は別の要素です。macOSのApple Silicon版とIntel版は、ファイル名にMacとあるだけで選ばず、対応機種を確認してください。AndroidのARM64版とARM版も、端末の仕様に合わせて選びます。ARMプロセッサー搭載のWindows端末では、アプリが明示している対応方法を確認し、すべてのデスクトップ用インストーラーがネイティブ対応だと考えないでください。ダウンロードページに記載のないアーキテクチャについて、インストーラーのURLを推測するのも避けましょう。

Clash for WindowsとClashX Metaは、すでにメンテナンスが終了した旧版です。古いガイドの確認や既存環境の移行には使えますが、アーカイブ版を継続更新される標準の選択肢として使うのはおすすめできません。Clash for Windowsから移行する場合は、新しいクライアントが既存設定を読み込めるか、上書き設定をどこに保存するか、終了時にシステムプロキシを元に戻すかを確認しましょう。移行後に旧アプリを削除し、複数のクライアントが同じポートを取り合わないようにしてください。

設定ファイルを読み込めても、すべての機能が動作するとは限りません。サブスクリプションのプロトコル、ルールプロバイダー、スクリプト、コア固有の項目が、クライアントでサポートされていない場合があります。Surfboardなどのアプリも、明示的に対応している設定形式を使う必要があります。読み込みエラーが出たら、項目名と行番号を確認し、非対応の設定を何度も読み込ませるのはやめましょう。必要なら、認証情報を不明な変換サービスに渡すのではなく、設定の提供元に対応形式を問い合わせてください。

移行に備えて必要事項を記録する

クライアントを切り替える前に、現在のサブスクリプション名、モード、ポリシーグループの選択内容、手動プロキシを使うアプリを記録しておきましょう。追加したルールがサブスクリプションファイルに直接書かれているのか、クライアントの上書き機能で管理されているのかも確認します。リモートのサブスクリプションファイルは更新時に置き換わることがあります。適切な場所に保存したローカル設定だけが、移行時に引き継ぎやすくなります。記録は端末内に保管し、完全なサブスクリプションURLを公開メモやスクリーンショットに載せないでください。

iOS版Clash Plusは、ダウンロードページからApp Storeにアクセスできます。製品の公式サイトはclashplus.ioです。モバイルOSでは通常、VPN構成を通じて通信を取り込みます。これはデスクトップのシステムプロキシのオン／オフと一対一で対応するものではありません。複数のプラットフォームを扱うガイドを読むときは、操作の目的を理解して手順を読み替えましょう。スマートフォンでデスクトップ専用の混合ポートのメニューを探したり、デスクトップでモバイル特有のバックグラウンド権限の手順をそのまま試したりする必要はありません。

この段階では、メインで使うクライアントを1つ、代替手段を1つ決めれば十分です。常駐プロキシを複数同時に試すのは避けましょう。メインのクライアントでインストールと読み込みを済ませ、通常のネットワークに戻せることを確認してから、ほかのクライアントとの違いを調べます。選定理由は、端末に対応している、設定との互換性がある、必要な機能が揃っている、問題時にログと終了方法を確認できる、といった点で説明できることが大切です。名称や画面の色だけで選ばないようにしましょう。

3. インストール確認：元に戻せる実行環境を整える

インストール前に競合要因を整理する

インストールする前に、ほかのプロキシクライアント、ゲーム用ネットワーク高速化ソフト、システムネットワークを変更する可能性のあるツールを終了してください。手動プロキシ、企業VPN、特殊なDNS設定があるかも記録しておきます。ウィンドウを閉じるだけでなく、バックグラウンドプロセスも終了させましょう。複数のソフトが同時にルートやプロキシ設定を変更すると、各画面では正常に見えても、実際の通信が別の入口に送られることがあります。作業前のネットワーク設定をスクリーンショットに残せば、テスト後に元の環境へ戻しやすくなります。

ダウンロードページでOSとアーキテクチャに合うパッケージを選び、クライアントのインストール手順を確認してください。インストーラー版、ポータブル版、圧縮ファイル版では、データの保存場所が異なる場合があります。ポータブル版でも、すべてのデータがプログラムのフォルダーに保存されるとは限りません。初回起動前に設定フォルダーへの書き込みが可能か確認し、読み取り専用の場所や制限の厳しいシステムディレクトリへの配置は避けましょう。サービスのインストールが必要な場合、その目的はネットワーク権限を使えるようにすることであり、リモートプロキシの認証情報を追加することではありません。

プラットフォームに応じた権限を許可する

Windowsでは初回起動時に、メイン画面とタスクトレイから操作できることを確認してから、コアの起動状態をチェックしてください。ファイアウォールの警告には実際の使用範囲に合わせて対応し、安易にすべてのネットワークアクセスを許可しないようにしましょう。端末内だけで使う場合は、LAN向けの待ち受けを有効にする必要はありません。TUNに必要なサービスや管理者権限の設定は、通常の接続を確認してから行うと、初回の失敗がインストールによるものか高度な通信制御によるものか判断しやすくなります。

macOSではアプリの指示に従い、初回起動とシステム権限の許可を済ませてください。ネットワーク拡張機能、補助サービス、キーチェーンに関する確認が表示された場合は、インストール中のアプリからの要求であることを確かめてから操作しましょう。出所が不明な要求を安易に許可してはいけません。「破損しているため開けません」と表示されたり、拡張機能を有効にできなかったりする場合は、ダウンロード元、OSとの互換性、システム設定に表示されるブロック情報を確認してください。システム全体のセキュリティ機能を無効にするのは避けましょう。詳しい権限設定はmacOSのインストールと権限設定をご覧ください。

AndroidとiOSでは、初回接続時にシステムVPNの権限を求められることが一般的です。すでに別のVPNを使っている場合は、置き換えや一時停止が起きないか確認してください。Androidで画面ロック後に接続が切れる場合は、バッテリー最適化とバックグラウンド動作の制限を確認し、最初からすべての権限を許可するのは避けましょう。Linuxでは、ディストリビューションに合ったパッケージ形式を選び、クライアントの説明に従ってデスクトップの依存関係やサービスをインストールしてください。画面が起動しても、権限を扱うサービスが正常に動いているとは限りません。

ローカルの入口を確認してから自動起動を設定する

設定画面を開き、実際に待ち受けているアドレスとポートを確認して記録しましょう。ガイドで使われるポート番号はあくまで例で、ほかのプロセスに使われていたり、クライアント側で変更されていたりする場合があります。ポートが競合すると、コアの起動失敗や、アドレスが使用中というログが見られることがあります。まず旧クライアントを終了し、競合しているプロセスを確認してください。ポートを次々と適当に変えるのは避けましょう。ブラウザー、ターミナル、システムプロキシの設定が、使えなくなった入口を参照し続ける可能性があります。

# Windows PowerShell：ポートの待ち受け状態を確認
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux：ポートを待ち受けているプロセスを確認
lsof -nP -iTCP:7890 -sTCP:LISTEN

上記のコマンドは診断用であり、プロキシを自動起動するものではありません。何も表示されない場合は、まだ待ち受けが始まっていないだけかもしれません。コマンドが見つからない場合は、該当ツールがシステムにインストールされていない可能性があります。プロセスが見つかったら、終了する前にどのプログラムか確認してください。正体の分からないシステムサービスを強制終了しないようにしましょう。待ち受けアドレスがローカルループバックの場合、ほかの端末から接続できないのは正常な初期設定です。「ネットワークの修復」のために、安易に外部向けのアドレスへ変更しないでください。

最後に、設定を元に戻せるかテストしましょう。複雑な設定を読み込まず、クライアントが正常に終了でき、終了後も元の直接接続でネットワークを使えることを確認します。次に再起動し、コアのログと待ち受けポートが一致しているか確認してください。この簡単な手順で、システムプロキシの設定残り、権限サービスの異常、ポート競合を早めに見つけられます。この基本環境を保ち、次の章ではサブスクリプションだけを追加しましょう。DNS、TUN、LAN共有を同時に変更するのは避けてください。

4. サブスクリプションの読み込み：取得・解析・有効化を区別する

読み込み方法を選び、データの種類を確認する

サブスクリプションは、クライアントが定期的に設定を取得する方法のひとつです。「設定」「サブスクリプション」「Profiles」などの項目から追加できます。提供元からURL全体をコピーし、「URLから追加」を選んで、識別しやすい名前を付けてダウンロードしてください。URLのクエリパラメーターに認証情報が含まれる場合があります。末尾の文字の抜けや、余分な空白・改行があるとリクエストに失敗します。サブスクリプションURLを検索エンジンや公開のオンライン検査サービスに入力しないでください。

ローカルファイルからの読み込みは、YAML形式の設定一式をすでに持っている場合に適しています。取得した内容が設定本文なのか、ログインページ、説明文、圧縮ファイルなのかを確認しましょう。サブスクリプションのリクエストが成功しても、アカウントのログインページが返されていることがあります。ダウンロード成功と解析成功は、別々に確認する必要があります。書式エラーが表示されたら、ファイルの冒頭とエラー行付近の構造を確認してください。内容を共有する前に認証情報を必ず削除し、トラブル対処を理由に設定全体を公開しないようにしましょう。

YAMLではインデントで階層を表し、通常はタブではなくスペースを使います。コロンの後には適切な区切りが必要で、リスト項目のインデントは揃えてください。編集時は元の文字コードと構造を保ち、日本語の句読点を構文の一部として使わないようにしましょう。特殊文字を含む文字列はYAMLの規則に従って引用符で囲めますが、すべての項目を機械的に引用符で囲む必要はありません。エラー行はパーサーが問題を見つけた位置を示すだけで、実際には直前の行でインデントや引用符が欠けていることもあります。

読み込み後にアクティブな設定を選ぶ

設定一覧に表示されたというだけでは、クライアントに保存されたことしか分かりません。「有効化」「使用」または対応するアクティブ表示を選び、コアが再読み込みされるまで待ってから、プロキシ画面でポリシーグループを確認してください。以前のグループ名が表示されたままなら、ダウンロードしただけで設定を切り替えていない可能性があります。設定の再作成や削除をすぐに行うより、アクティブな設定名、更新時刻、読み込みエラーを確認しましょう。複数の設定を保存する場合は、用途が分かる名前を付けて誤選択を防いでください。

設定一式には通常、ノードとポリシーグループが含まれます。まず主要なグループを開き、選択できる接続先が含まれていることを確認してから、使用権限のあるノードを選んでテストしましょう。ノード名が表示されても、サービスが使えるとは限りません。認証情報の期限切れ、リモートサーバーへの接続不能、プロトコルの非互換などは、接続確立時に初めて分かることがあります。レイテンシーテストの失敗を、すべてのネットワーク通信の失敗と同一視しないでください。テスト先やテスト方法は、実際のサービス利用時とは異なる場合があります。

サブスクリプションの更新とクライアントの更新は別の作業です。前者ではノード、ルール、ポリシーの構成が変わり、後者ではアプリやコアの機能が変わります。リモート設定の更新でファイルを上書きすることがあるため、長期的に使うルールはクライアントの上書き、マージ、ローカル拡張機能に保存しましょう。まずマージの順序を確認し、少しずつテストしてください。配列全体を置き換える仕組みもあれば、先頭や末尾に追加する仕組みもあります。名称が似ていても動作が同じとは限りません。

更新失敗の原因を切り分ける

更新に失敗したら、まずリクエストが完了しないのか、サーバーに拒否されるのか、内容を解析できないのかを区別しましょう。タイムアウトの場合は、現在のネットワーク、ドメインの名前解決、更新にプロキシが必要かを確認します。アクセス拒否ならURLの欠落、アカウントの状態、提供元の案内を確認してください。解析エラーでは、返された内容とコアの対応範囲を調べます。どんなエラーもノードの障害と決めつけないでください。サブスクリプションのダウンロードには、別の通信経路が使われている場合があります。

初回の読み込みにプロキシ経由のダウンロードが必要な場合は、提供元が許可しているローカル設定の読み込み方法を使い、まず基本接続を確立してから更新経路をテストできます。データの取り扱いが分からない変換サイトに、ダウンロードの問題を解決するためだけにサブスクリプションを渡すのは避けましょう。サブスクリプションプロバイダーやルールプロバイダーが別のファイルを取得する場合もあります。メインの設定が読み込まれても、これらのリソースが利用可能か確認してください。特に初回起動時やオフラインから復帰した際は注意が必要です。

この章を終えると、設定一覧から現在有効な項目を確認し、プロキシ画面で主要なポリシーグループを見つけ、更新失敗がダウンロード段階か解析段階か説明できるようになります。最後に正常動作した設定をローカルに保存し、独自の変更箇所も記録してください。次の章では既存のポリシーでモードを検証し、すぐにルールを拡張するのは避けましょう。アクセス結果が変わったとき、モード変更によるものか、サブスクリプション更新によるものか判断しやすくなります。

5. プロキシモード：入口と接続先を分けて確認する

ルール、グローバル、直結モードの役割

プロキシモードは、コアに入った接続の接続先をどう決めるかを制御します。ルールモードは設定内のルールに順番に照合するため、日常的な通信の振り分けに向いています。グローバルモードでは、コアが取り込んだ通信をグローバルポリシーで処理します。直結モードでは、取り込んだ通信をそのまま接続先へ送ります。いずれも、通信がすでにコアに入っていることが前提です。システムプロキシ、手動プロキシ、TUNで取り込まれていないアプリは、グローバルモードに切り替えただけでは経路が変わりません。

初回の確認では、まずルールモードを選び、主要なポリシーグループで利用可能なノードが選ばれているか確認します。次に、プロキシが必要な接続先と通常は直結する接続先をそれぞれ開いてみましょう。1つのウェブサイトだけを試して、ネットワーク全体が正常と誤認しないためです。失敗した場合は、短時間だけグローバルモードに切り替えて比較します。グローバルモードでは使えるのにルールモードで失敗するなら、クライアントを再インストールする前に、ルールの照合結果とポリシーグループの参照先を確認してください。

グローバルモードにしても、すべての端末の通信がプロキシ経由になるわけではありません。また、DNSリクエストも同じ接続先を使うとは限りません。グローバルモードが変更するのは、コアに取り込まれた接続のポリシー選択だけです。クライアントによっては、グローバル用の選択と普段使うProxyポリシーグループが別になっています。切り替え後に、グローバルポリシーがどの接続先を指定しているか確認してください。テストが終わったら元のモードに戻し、実際の用途に合った振り分けができるか再確認しましょう。

システムプロキシは入口であり、モードではない

システムプロキシの切り替えは、OSからアプリに提供されるプロキシ情報を変更します。ブラウザーは通常この設定に従いますが、ゲーム、一部の更新プログラム、ターミナルツール、独自のネットワーク機能を持つアプリは従わない場合があります。アプリが直結していても、必ずしもルールの誤りとは限りません。ローカルのプロキシポートに接続していない可能性があります。まず接続一覧で、該当アプリのプロセスと接続先を探してください。記録がなければ入口を確認し、接続に影響しないルールを変更し続けないようにしましょう。

ローカルのHTTPプロキシを単独でテストする場合は、次のコマンドを使えます。ポート番号は例なので、クライアントで実際に待ち受けている混合ポートまたはHTTPプロキシポートに置き換えてください。コマンドで入口を明示するため、ターミナルがシステムプロキシを読み込むかどうかには左右されません。テストに成功しても、そのリクエストが指定した入口を通ったことが分かるだけです。ブラウザーやほかのプロトコル、すべての接続先で同じ経路が使われる証明にはなりません。

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

接続記録を見て状況を判断する

リクエストを調べるときは、送信元アプリ、ドメイン名またはアドレス、適用されたルール、ポリシーグループ、最終的なノードの順に記録しましょう。DIRECTになった場合は設定どおりか確認します。正しいポリシーが適用されているのに失敗する場合は、ノードへの接続と名前解決を調べてください。接続一覧では短い接続がまとめられたり、すぐに消えたりすることがあります。ログを開いてから再現すると確認しやすくなります。タスクトレイの色や単一のスイッチだけで実際の出口を判断しないでください。サービスが起動中であることしか示していない場合もあります。

モードを切り替えても、すでに確立した長時間接続がすぐ移行するとは限りません。ブラウザーの接続再利用、チャットアプリの常時接続、動画ストリームなどは、以前の経路を使い続けることがあります。比較テストでは新しい接続を作り、必要なら該当アプリを終了して起動し直してください。クライアントに接続を切る機能がある場合は、転送中の処理も中断される可能性に注意しましょう。モードを何度も切り替えながら同じ古い接続を観察すると、結果が矛盾することがあります。

この章では、コアの待ち受け、アプリからコアへの接続、モード、外部への接続の順に確認する手順を身につけましょう。直結モードはソフトウェアを終了する代わりにはなりません。システムプロキシの入口が残る場合があります。テスト終了時はクライアントの手順で通信制御を解除し、システム設定が元に戻ったことを確認してください。「接続済みなのにウェブページが開かない」場合は、サブスクリプション、ポート、システムプロキシの確認リストに沿って調べましょう。

6. ルール分岐：順序、ポリシーグループ、ローカル上書き

まず説明できるルールから始める

ルールは通常、上から順に照合され、最初に一致したルールのポリシーが適用されます。内容だけでなく順序も重要です。個別の例外は広い範囲を対象とするルールより前に置き、最後にフォールバックルールを配置しましょう。追加するだけで位置を確認しないと、ルールがまったく機能しないことがあります。MATCHを先に置くと、後続のルールで期待する振り分けができません。学習時はまず数個のルールが対象とする範囲を理解し、大規模なルールセットを加えるのはその後にしましょう。そうすれば、問題発生時に適用理由を説明しやすくなります。

DOMAINは指定したドメインに一致し、DOMAIN-SUFFIXはそのドメインとサブドメインに一致します。DOMAIN-KEYWORDはドメイン名に含まれるキーワードで判定します。キーワードルールは範囲が広く、関係のないサービスまで同じポリシーに含める可能性があります。IP-CIDRはIPアドレスの範囲を対象とし、GEOIPは地理データベースに依存します。その判定はサービスの実際の運営地域と一致するとは限りません。ドメインルールとIPアドレスルールでは参照する情報が異なるため、互いに置き換えるのではなく、実際の接続記録に応じて選んでください。

# 既存の設定にマージする；Proxyはすでに存在するポリシーグループを指定
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-SUFFIX,google.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

この例はルール部分のみで、リモートノードを含まないため、単独ではプロキシ接続を確立できません。no-resolveは、ドメイン名を使った接続の照合のために、このアドレスルールが名前解決を積極的に要求しないという意味です。DNSを全体的に無効化する設定ではありません。LANへの直結では、実際のネットワーク範囲とTUNのルートも確認してください。プライベートIP範囲を1つ指定しただけで、すべての内部ネットワークをカバーできるとは限りません。企業ネットワークでは独自のアドレス範囲が使われることもあるため、実際のネットワーク構成に従いましょう。

ポリシーグループでルールとノードを切り離す

ルールがポリシーグループを参照する仕組みにすると、ルールを変更せずにノードを切り替えられます。手動選択型はユーザーが接続先を選び、自動テスト型は設定されたテスト結果に基づいて選択し、フェイルオーバー型は順番に利用可能なメンバーを探します。それぞれ用途が異なります。テストレイテンシーが低くてもダウンロード速度が高いとは限らず、テスト先に接続できても実際のサービスのドメインに接続できるとは限りません。目的に合わせて選び、すべてのグループを同じ種類に変更するのは避けましょう。

グループ名を変更する場合は、ルール、ほかのポリシーグループ、上書き設定にある参照先も確認してください。名前が一致しないと読み込みに失敗したり、意図した参照が無効になったりします。まず動作する設定を複製し、1つのポリシーグループでメンバーの選択を試してから、変更範囲を広げましょう。グループ同士の参照が循環しないようにすることも重要です。循環依存のエラーが表示されたら、参照経路を順に確認し、エラーに出てきた項目を手当たり次第に削除して回避しないでください。

更新を保ちやすいカスタマイズ方法

長期間使う独自設定には、クライアントがサポートする上書き機能やマージ機能を優先しましょう。追加ルールがサブスクリプション内のルールより前に置かれるか後に置かれるかを確認してから、判定しやすいルールを1つ追加します。マージでrules配列全体が置き換わると、既存の振り分けがすべて失われることがあります。末尾にしか追加されない場合は、追加したルールがMATCHの後に配置される可能性があります。編集画面の断片だけでなく、保存前にマージ後の全体を確認してください。

ルールプロバイダーを使うと、多数のルールを別のリソースにまとめ、RULE-SETで参照できます。利用前に形式、動作の種類、更新方法を確認してください。ドメインの一覧とルール一式は、自由に入れ替えられません。リソースの取得に失敗しても、メインの設定は読み込まれることがありますが、振り分け結果が変わる可能性があります。ログでリソースの状態とキャッシュを確認し、プロバイダーの準備ができていないのか、個別ルールに問題があるのかを切り分けましょう。

実際にトラブルを調べる際は、接続先を1つに決め、ドメインが記録されているか、どのルールとポリシーが適用されたかを確認します。IPアドレスしか記録されない場合は、アプリがアドレスに直接接続している、名前解決のキャッシュがある、通信の取り込み方法が異なる、といった可能性を考えましょう。ルールが正しくてもサービスに問題がある場合は、別のドメイン、配信ネットワークのアドレス、ログイン用の接続先も必要かもしれません。1つのアプリを直すために、すべての通信をすぐグローバルモードにするのではなく、例外の範囲を絞り、変更理由を記録してください。

この章を終えると、ある接続が現在のルールに一致した理由と、ポリシーグループの変更によってどの接続先が影響を受けるかを説明できるようになります。ルール変更の前後を保存し、再読み込み後に新しい接続で動作を確認しましょう。期待と異なる場合は、まずその変更を元に戻してから、次の層を調べます。小さく変更することで、サブスクリプション更新、DNS変更、ルールのテストが同じトラブルに混ざるのを防げます。

7. TUNモード：通信の取り込み範囲、権限、DNS

TUNが必要になるケース

TUNは仮想ネットワークインターフェースとルートを使って通信をコアに送ります。システムプロキシに従わないアプリを扱う場合や、より多くの通信をまとめて制御する場合に役立ちます。システムプロキシとの主な違いは通信を取り込む場所であり、「より高速」「より高度」ということではありません。実際に取り込まれる範囲は、ルートからの除外、アプリの除外、プロトコルの対応、プラットフォームの制限にも左右されます。TUNを有効にしても、すべてのパケットが同じリモート接続先を使うとは限りません。

始める前に、サブスクリプション、ルール、通常のプロキシ入口が使えることを確認しておきましょう。現在の設定を保存し、ほかのVPNを終了したうえで、リモートワーク、仮想マシン、コンテナのネットワークが特殊なルートを必要としているか確認してください。リモート接続で管理している端末では、デフォルトルートの変更により管理接続が切れることがあります。事前にローカルで操作する手段や復旧手順を用意してください。TUNのトラブル対処は基本のプロキシ接続が使えることを前提とし、使えないサブスクリプションの問題を覆い隠すために使うものではありません。

項目を1つずつ有効にする

クライアントの指示に従い、権限を扱うサービスをインストールするか、システムの許可を完了します。有効にした後は、仮想インターフェース、ルート、コアのログを確認してください。システムプロキシを自動で調整するクライアントもあれば、両方の併用を許可するクライアントもあります。動作はクライアントの説明に従いましょう。比較テストでは、まず通信を取り込む方法を1つに絞り、対象アプリの接続記録が出るか確認してから、もう一方の入口も残すか判断してください。すべてのネットワーク機能を安易に同時に有効にしないようにしましょう。

# mihomoの設定例。既存設定とクライアントの管理方法に合わせてください
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

この例では、自動ルートが通信を取り込む経路を追加し、インターフェースの自動検出が外向きのネットワークインターフェースを特定し、DNSハイジャックの設定が対象のDNS通信を受け取ります。実際に使える項目や動作は、コアとOSによって異なります。クライアントにTUNの設定画面がある場合は、設定ファイルとの上書き競合を避けるため、画面から管理することを優先しましょう。この設定例だけをコピーしても、DNSサービス一式が揃うわけではなく、すべてのプラットフォームで同じネットワークスタックが使われるとも限りません。

DNSはドメイン名の分岐方法を左右する

DNSはTUNを使う際に重要な要素です。Fake-IPモードでは、ドメイン名を仮想アドレスに対応付け、後続の接続でコアが元のドメインを特定できるようにします。通常の実IPアドレスによる名前解決では、接続先のアドレスが直接返されます。両者には異なる互換性の制約があり、1回ウェブページを開いたときの速度だけで優劣を判断できません。実アドレスが必要なデバイス検出、内部サービス、アプリでは例外設定が必要になる場合があります。変更前に、原因が名前解決モードなのか、ルールやルートなのか確認しましょう。

fake-ip-filterには、仮想アドレスを返さないドメインを指定します。ただし、あらゆるプロキシ除外を設定する汎用リストではありません。実アドレスが返された後も、接続はルール判定の対象です。フィルターにドメインを追加しても、自動的に直結になるとは限りません。サービスを直結したい場合は、ルールとルートも確認してください。アドレスの対応付けについては、Fake-IPモードと仮想アドレスプールで詳しく解説しています。内容を確認したうえで、例外は必要最小限にとどめましょう。

DNSハイジャックを有効にしても、あらゆる名前解決を捕捉できるわけではありません。アプリ独自の暗号化DNSは、通常のHTTPSなどを通じて送信されることがあり、ポート53の通信を取り込んだだけでは、アプリのDNSリクエストもコアに届いたとは判断できません。ドメインルールの挙動が一致しない場合は、ブラウザーのセキュアDNS、アプリ内の名前解決、システムのキャッシュを確認しましょう。システムDNS、コアのリゾルバー、ブラウザー設定を同時に変更せず、1か所ずつ変更して新しい接続で試してください。

ネットワークの切り替えもテストしましょう。有線から無線へ、Wi-Fiからモバイル通信へ切り替えたときや、スリープから復帰したときに、使用する外向きインターフェースが変わることがあります。通常のプロキシは使えるのにTUNで失敗する場合は、デフォルトのインターフェース、残ったルート、権限サービス、DNSの取り込みを確認してから、クライアントを再起動するか判断してください。より詳しい比較はTUNとシステムプロキシの通信取り込み範囲の比較をご覧ください。この章のゴールは、必要な通信が取り込まれ、内部ネットワークも使え、無効化後に元のネットワークへ戻せることです。

8. 日常メンテナンス：更新、速度テスト、トラブル記録

設定の更新とアプリの更新を分ける

安定して使えるようになったら、変更点を管理することがメンテナンスの中心です。サブスクリプション、クライアント、コア、OSの更新を一度に行わないでください。現在有効な設定、モード、ポリシーの選択内容を記録してから、更新を1つずつ適用し、その都度テストします。問題が起きたとき、どの操作が影響したのか特定しやすくなります。「昨日は使えたが今日は使えない」という記録だけでは、リモートサービス側とローカル環境のどちらが変わったのか判断できません。

サブスクリプションを更新する前に、ローカルのルールが置き換わらない場所に保存されていることを確認し、利用可能な設定を1つ残しておきましょう。更新後は、ポリシーグループの名前、メンバー、主要なルールに変更がないか確認してください。以前選択していたノードが削除されている場合もあります。クライアントを更新する際は、機能や互換性の説明を読み、設定フォルダー、権限サービス、コアのパラメーターが変更されていないか確認しましょう。新旧のプログラムを同時に動かすと、画面を表示しているプロセスと実際に待ち受けているプロセスが別になることがあります。

速度テストで分かるのは限られたことだけ

Clashのノード速度テストは、通常、指定されたテスト先への1回のリクエストの応答を測定します。継続的なダウンロード速度と同じではなく、すべてのウェブサイトでの使い心地を示すものでもありません。テスト失敗の原因は、テスト先自体、名前解決の経路、リクエストのタイムアウト設定にある可能性があります。ノードを比較する場合は条件を揃え、同じテスト先に近い時間帯で接続して結果を見たうえで、実際の用途でも確認してください。何度もテストを更新するとリクエストが増え、一時的な変動を長期的な品質の差と誤認しやすくなります。

自動テスト型のポリシーグループも、テスト先や間隔の影響を受けます。間隔が短すぎると選択が頻繁に変わる一方、長時間の接続は切り替えのたびにすぐ移行するとは限りません。接続先の安定性が重要な用途では、利用可能な接続先を手動で固定するほうが適している場合があります。接続を維持することが重要なら、適切なフェイルオーバーを設定しましょう。レイテンシーの数値1つで、動画、会議、大容量ファイルの転送に向いていると判断しないでください。それぞれの用途で重視される指標は異なります。

通信経路に沿ってトラブルの情報を記録する

問題が起きたら、まずプロキシを使わない基本のネットワーク接続が正常か確認し、サブスクリプション、コアの待ち受け、システムの入口、ルールの判定、DNSの順に調べましょう。再現性のある接続先を1つと具体的な発生時刻を記録し、十数個のアプリを同時に試して結果を混在させないでください。ログは通常の詳細度から始め、必要な場合だけ一時的に詳細度を上げます。調査後は元に戻し、ログの肥大化や不要なアクセス記録の蓄積を防ぎましょう。

接続拒否と接続タイムアウトは意味が異なります。接続拒否では、ローカルポートが待ち受けていない、リモートサービスが拒否している、ファイアウォールが明示的に拒否している、といった状況が考えられます。タイムアウトでは、パケットロス、ルート、接続先への到達不能、名前解決の待ち時間などが関係している可能性があります。エラーメッセージは手がかりであり、結論ではありません。発生箇所とあわせて判断しましょう。ローカル入口で拒否されているなら、リモートノードを変更しても通常は解決しません。ルールが正しく適用された後にリモート接続のハンドシェイクが失敗しているなら、システムプロキシを切り替えても認証の問題は直りません。

問い合わせ用の情報をまとめる際は、クライアント名とOS名、利用モード、再現手順、接続先の種類、認証情報を伏せたエラーを残してください。サブスクリプションURL、ノードアドレスに含まれるアカウント情報、パスワード、個人を特定できる情報は削除します。ログにはアクセスしたドメインが含まれ、スクリーンショットのQRコードが認証情報と同じ役割を持つ場合もあります。サブスクリプションを公開してしまった場合は、投稿を削除するだけでは複製済みの情報のリスクは消えません。提供元で関連するアクセス認証情報を再設定してください。

使わなくなった設定、古いルール、テスト用のシステムプロキシは定期的に整理します。バックアップには、利用可能な設定とローカル変更の説明を残しておきましょう。クライアント終了後にシステムネットワークが復旧しているか、スリープや再起動の後に正しい設定が有効かも確認してください。同じような問題が起きたら、まず自分の変更記録を確認してから、当サイトの使い方ガイドやトラブル対処記事を参照しましょう。この章の目的は頻繁に設定をいじることではなく、少ない記録で復旧手順を明確にすることです。

9. 応用へのステップ：使える設定から説明できる設定へ

実験用の設定と確認方法を用意する

8章までを終えたら、応用設定ではパラメーターを増やす前に、現在の動作を説明することから始めましょう。動作中の設定を複製して実験用にし、変更の目的、予想する結果、元に戻す方法を毎回記録します。テストでは変更する項目を1つに絞り、同じ接続先に新しい接続を作り、適用されたルールと最終的な接続先を記録してください。変更前後の違いを説明できて初めて、その項目を理解したと言えます。たまたま一度動いた結果だけで判断しないようにしましょう。

最初の段階では、設定の構造を整理しましょう。リモートのサブスクリプション、ローカルルール、ポリシーグループの選択、端末固有の設定を分けて管理します。クライアントが生成する項目、リモート設定に由来する項目、上書きで追加する項目を確認してください。最終的な設定がどのようにマージされるか分からない場合は、複雑なスクリプトを導入する前に、クライアントのマージ順序を学びましょう。設定が大きくなるほど、ファイルを短くすることより、項目の出所を明確にすることが重要です。

DNSとプロバイダーを依存関係に沿って学ぶ

次の段階ではDNSを詳しく学べます。基本のリゾルバー、プロキシ用ドメインの名前解決、接続先ドメインの名前解決がそれぞれどの処理で使われるか理解してから、nameserver、fallback、適用条件を調べましょう。暗号化DNSのアドレスを複数並べただけで信頼性が上がるとは限りません。リゾルバーのドメイン自体に先行する名前解決が必要なことがあり、アクセス経路が確立していないプロキシに依存する場合もあります。依存関係が循環すると、設定が整っているように見えても起動時に処理が進まなくなることがあります。

各項目の詳しい説明は、DNSのnameserver、fallback、ハイジャック設定の解説をご覧ください。fallbackの役割や判定方法は、設定とコアの実装によって異なります。メインのリゾルバーが失敗した後だけ使われる予備リストと機械的に解釈しないでください。再現性のあるドメインテストを用意し、名前解決の結果、ルール判定、接続状態を確認しましょう。返されたアドレスだけで結論を出さないようにしてください。

第3段階では、プロキシプロバイダーとルールプロバイダーを導入します。更新頻度の高いリソースをメイン設定から分離できますが、ダウンロード、キャッシュ、起動時の依存関係も増えます。リソースの配布元、形式、保存先、更新間隔をそれぞれ確認し、初回のダウンロードに失敗した場合に利用できるキャッシュがあるか調べてください。端末によってパスの権限は異なります。デスクトップで使える相対パスが、モバイル端末やサービス環境ではクライアントによる再管理を必要とすることがあります。

サーバー、ルーター、制御インターフェースの境界

第4段階になってから、サーバーやルーターでMihomoコアを動かすことを検討しましょう。こうした環境では、デスクトップの画面が権限、サービス起動、システムの復旧を代行してくれません。設定パス、実行ユーザー、ログ、ルートを自分で管理する必要があります。まず端末上の明示的なプロキシ接続を確認し、その後でLANの入口とファイアウォールの範囲を設計してください。デフォルトゲートウェイをいきなり置き換えないようにしましょう。ルーターではプロセッサーのアーキテクチャ、メモリ、システムコンポーネントも関わるため、圧縮ファイルの名前だけで適合性を判断できません。

制御インターフェースは状態の確認やコアの管理に使うもので、通常のプロキシ入口ではありません。リモートからアクセスする場合は、待ち受け範囲を制限して認証を設定し、ファイアウォールと保護された管理経路も利用しましょう。制御インターフェースを公共ネットワークに直接公開したり、認証情報を公開設定リポジトリに保存したりしないでください。LANでプロキシを共有する場合も、利用者とアクセス範囲を明確にする必要があります。LAN接続を許可する設定だけで、アクセス制御が自動的に整うわけではありません。

企業内ネットワーク、アプリごとのルール、複数のネットワーク出口、IPv6に対応する場合は、まず期待する経路を書き出しましょう。どの通信をコアに送り、どの通信を直結のままにするか、名前解決をどこで行うか、プロキシを切断した後にどうなるべきかを整理します。IPv6ではアドレス、名前解決、ルートをあわせて考える必要があります。設定項目を1つ有効にしただけで完全に対応したと判断しないでください。組織のネットワークポリシーや管理対象端末を扱う場合は、事前に許可を得て、既存のアクセス制限をプロキシ設定で回避しないようにしましょう。

最終的には、構成を説明できる自分用の設定を整えましょう。ポリシーグループの用途が明確で、例外ごとに理由があり、バックグラウンドサービスの停止方法が分かり、更新に失敗した場合の復旧手段がある状態を目指します。初回接続の手順はクイックスタートガイドで確認でき、端末を変える場合はクライアントのダウンロードページに戻れます。理解できない設定例を長期間コピーし続けるより、少数の分かりやすいルールと安定した手順にまとめるほうが管理しやすく、次にネットワークの問題が起きたときも原因の層を特定しやすくなります。