Clashのプロキシモードはどれを選ぶ？ルール・グローバル・ダイレクトの違いを徹底解説

3つのモードが変えるのは出方向の判断

Clash Meta、つまり現在広く使われている mihomo カーネルは、ローカルのプロキシポートや TUN 仮想ネットワークインターフェースに入った接続を受け取り、接続先となる出口を決めます。ルール・グローバル・ダイレクトの3モードが変えるのは、この判断方法です。サブスクリプション内のノード数が変わるわけでも、カーネルに入っていない通信が自動的に処理対象になるわけでもありません。

ブラウザーで HTTPS サイトにアクセスする場合、接続はいったん本機の HTTP または mixed ポート（設定でよく使われる 7890 など）に入ることがあります。また、TUN モードによってシステムのネットワークスタックから引き継がれる場合もあります。カーネルは対象ドメイン、対象 IP、ポート、ネットワーク種別を認識したうえで、現在のモードに応じてプロキシノードまたはローカルネットワークを選択します。システムプロキシが有効でなく、アプリ側にも個別のプロキシ設定がなく、TUN にも引き継がれていない場合、そのアプリの接続は Clash を迂回します。この場合、モードを切り替えても通常は影響しません。

モード	カーネルに入った後の判断	代表的な用途	主な確認ポイント
ルール	上から順にルールを照合し、対応するプロキシグループまたは DIRECT に渡す	普段の閲覧、長時間の利用、サイトごとの振り分け	ルールの順序、ルールセットの状態、末尾のルール
グローバル	通常は GLOBAL プロキシグループで現在選択中の出口に渡す	一時的にルールの影響を除外、単一ノードの接続性をテスト	GLOBAL の現在の選択、LAN バイパス設定
ダイレクト	DIRECT を使い、ローカルネットワークから接続を確立する	ローカルネットワークの基準値、社内ネットワークのデバッグ、プロキシ出口の一時停止	DNS を引き続きカーネルが処理するか、接続が再確立されるか

ルールモード：マッチした順に出口を選ぶ

ルールモードは長期利用に適しています。設定ファイルの rules リストを上から順に確認し、最初にマッチしたルールが直ちに適用されます。後続のルールは処理されません。ドメインルール、IP ルール、プロセスルール、ルールセットを同時に使えるため、ルールの数より順序が重要です。

mode: rule
mixed-port: 7890
external-controller: 127.0.0.1:9090

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN,api.example.net,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,Proxy

この例では、まず指定した中国本土のドメインをダイレクト接続にし、次に1つの API ドメインを Proxy というプロキシグループに振り分けます。2つのプライベートアドレス帯は LAN へのダイレクト接続に使い、最後の MATCH で、それまでにマッチしなかった接続を受け止めます。MATCH,Proxy を1行目に置くと、残りのルールは適用されません。

ルールモードで実際に確認する3つのポイント

どのプロキシポリシーにマッチしたか。クライアントの接続画面には通常、ルール名や経路が表示されます。たとえば DOMAIN-SUFFIX → DIRECT、MATCH → Proxy などです。ノード名だけでは、ルールが正しく適用されたか判断できません。
プロキシグループで何が選択されているか。ルールが Proxy に振り分けても、最終的な出口はそのプロキシグループに左右されます。手動選択グループなら現在のノードを使い、url-test や fallback グループなら、グループ内の検査結果で決まります。
ドメインが IP に変換済みか。接続によっては対象 IP しか確認できず、ドメインルールが適用されないことがあります。DNS ハイジャック、スニッフィング、適切な TUN 設定を有効にすると、カーネルがより多くのドメイン情報を取得できますが、具体的な動作は設定とプロトコルによって異なります。

ルールモードは LAN や開発環境にも適しています。たとえば localhost、127.0.0.0/8、192.168.0.0/16、社内ネットワークのドメインを上位に置くと、社内向けのリクエストがリモートノードへ送られるのを防ぎやすくなります。デバッグ前には、企業 VPN、仮想マシンのネットワーク、コンテナのネットワークがこれらのアドレス帯と重複していないか確認してください。

普段のネット利用でルールモードを優先する理由

ローカルサービス、プリンター、NAS、ルーターの管理画面をダイレクト接続のまま利用できます。
サイトごとに異なるプロキシグループへ振り分けられ、同じノードに固定されません。
ルールセットを更新しても、アプリごとにプロキシ設定を変更する必要がありません。
接続ログにマッチしたルールが残るため、特定のドメインが誤った出口を通る原因を特定しやすくなります。

グローバルモード：通常のルールを飛ばして単一出口をテスト

グローバルモードは「すべてのデバイス通信を強制的にプロキシ経由にする」と理解されがちですが、正確ではありません。Clash カーネルに入った接続だけを処理し、通常はそれらを GLOBAL プロキシグループへ渡します。プロキシポートに入っていない接続、TUN に引き継がれていない接続、ルーティングで除外された接続は、モード名にかかわらず処理されません。

グローバルモードの主な価値は、障害を切り分けられることです。ルールモードで開けないサイトがグローバルモードに切り替えるとすぐ開くなら、ノード自体にはアクセス能力があり、原因はルールのマッチ、プロキシグループの選択、またはダイレクト接続側にある可能性が高くなります。グローバルモードでも失敗する場合は、ノードの接続性、DNS、TLS の時刻、ネットワークファイアウォール、対象サービスの状態を確認します。

グローバルモードが適する場面

単一ノードを検証する。GLOBAL グループでノードを1つ固定し、ウェブページの読み込み、TCP 接続の確立、UDP の利用要件をそれぞれテストします。テスト中に自動選択グループが出口を切り替えるのを防げます。
一時的にルールの問題を切り分ける。同じ URL でもルールモードとグローバルモードで結果が異なる場合は、接続ログに戻ってマッチしたルールの経路を確認します。
再現可能なプロキシ速度測定を行う。サーバー、ノード、測定時間帯を固定し、異なる測定ドメインが異なる出口へ振り分けられることによる誤差を抑えます。

再現可能な速度測定の記録例

まずダイレクトモードでローカルネットワークの基準値を測定し、その後グローバルモードで同じノードをテストします。あるギガビット有線ネットワークの記録では、ダイレクト接続の下りが 742 Mbps、上りが 93 Mbps、アイドル時の遅延が 8 msでした。同じプロキシノードに固定すると、下りは 186 Mbps、上りは 61 Mbps、アイドル時の遅延は 48 msでした。これらの数値は、そのネットワーク、ノード、時間帯における経路を示すだけで、他のデバイスの速度を保証するものではありません。

ファイル同期、アップデートのダウンロード、動画再生中のアプリを終了します。
ダイレクトモードで同じ測定サーバーを3回測定し、中央値を記録します。
グローバルモードに切り替え、GLOBAL グループでノードを1つ固定します。
測定ページを閉じて再度開き、新しい接続を確立してから3回測定します。
下り、上り、アイドル時の遅延、負荷時の遅延、パケット損失率を同時に記録します。

クライアントのノード一覧に表示される遅延テストは通常、指定されたテスト URL に短い HTTP リクエストを送り、到達性と往復時間を確認するものです。52 ms と表示されても、ノードが帯域を安定して使い切れるとは限らず、UDP、長時間接続、大容量ファイル転送が正常とは限りません。

ダイレクトモード：引き継ぎは維持し、出口をローカルネットワークに変更

ダイレクトモードでは、カーネルに入った接続の出方向に DIRECT を使用します。プロキシノードを経由しないネットワークの基準値を測定したり、LAN 機器へのアクセス、ローカルサービスのデバッグ、障害がリモートノードに起因するかの確認に適しています。ダイレクトはクライアントの終了を意味しません。ローカルのリスニングポート、TUN 仮想ネットワークインターフェース、接続ログ、DNS モジュールは動作を続ける場合があります。

ダイレクトモードと Clash を完全に終了する場合の違い

操作	ローカルプロキシポート	TUN による引き継ぎ	Clash DNS
ダイレクトモードへ切替	通常は引き続きリッスン	通常は現在の状態を維持	引き続き名前解決する場合がある
システムプロキシを無効化	ポートは引き続きリッスンする場合がある	必ずしも無効になるとは限らない	TUN とシステム DNS の設定による
クライアントを終了	リッスンを停止	仮想ネットワークインターフェースとルートを解除する必要がある	カーネルの DNS を停止

そのため、DNS の問題を調べる際にダイレクトモードへ切り替えるだけでは、「Clash を完全に経由しない」状態にならないことがあります。dns.enable、TUN の DNS ハイジャック、fake-ip が有効なら、名前解決がカーネルで処理される可能性があります。OS 本来のネットワークを基準にするには、システムプロキシ、TUN、DNS、ルーティングの状態を記録し、項目ごとに元へ戻してください。

社内ネットワークをデバッグする推奨手順

まずルールモードで、対象アドレスにどのルールがマッチしたか確認します。
対象が実際の社内ネットワーク帯（例：192.168.1.0/24）に属することを確認し、同名のパブリックドメインが存在しないか調べます。
ダイレクトモードに切り替え、古い接続を閉じてからサービスへ再接続します。
それでも失敗する場合は、本機のルーティングテーブル、企業 VPN、コンテナネットワーク、サービスのリッスンアドレスを確認します。
ダイレクトでは使えるのにルールモードで失敗する場合は、そのドメインまたはネットワーク帯に、上位の DIRECT ルールを追加します。

ローカル開発では、リッスンアドレスの違いにも注意が必要です。サービスが 127.0.0.1:3000 だけでリッスンしている場合、他のデバイスから LAN IP 経由でアクセスできません。これは Clash のモードが原因ではありません。サービスが 0.0.0.0:3000 でリッスンしている場合は、システムファイアウォール、LAN 分離、対象ネットワーク帯の DIRECT ルールを確認します。

モードを切り替えても既存の接続は自動的に経路変更されない

Clash は通常、接続の確立時に出方向を決定します。すでに存在する TCP 接続は、ルールモードからグローバルモードへ切り替えても別のノードへ移行しません。WebSocket、SSH、動画ストリーム、クラウドストレージの同期、HTTP/2 の長時間接続では特に顕著です。画面に新しいモードが表示されても、新しく作られる接続だけが新しいロジックで処理されます。

新しいモードをテスト結果に反映させる

ウェブページを更新する前に対象のタブを閉じ、必要ならブラウザーを完全に終了して再起動します。
クライアントの接続画面で古い接続を終了します。SSH をテストする場合はセッションを再確立します。
アプリの接続プールが解放されるまで待つか、バックグラウンドで常駐するアプリを再起動します。
ノードを切り替えたら DNS クエリを再実行し、古い名前解決結果と新しい出口を混同しないようにします。
UDP アプリをテストする場合はセッションを再起動します。一部のアプリはマッピングを長時間再利用するためです。

一般的な GUI クライアントでは、モードの入口は通常「プロキシ」→「モード」にあり、「ルール」「グローバル」「ダイレクト」を選択できます。クライアントによっては「設定」→「Clash 設定」→「実行モード」に配置され、トレイメニューに同名の項目がある場合もあります。メニュー名はクライアントのバージョンによって変わりますが、カーネルに対応する値は rule、global、direct です。

mihomo の外部コントローラー（例：127.0.0.1:9090）を有効にしている場合、管理画面からコントロール API を通じてモードを変更できます。リクエストボディの値も小文字の英語を使います。

PUT /configs
Content-Type: application/json

{"mode":"rule"}

外部コントローラーは信頼できるインターフェースだけでリッスンさせ、アクセス認証情報を設定してください。変更後は実行中の設定を再読み込みし、接続ログで新しいリクエストを作成して、実際のモードとマッチした経路が一致することを確認します。設定ファイルを手動編集した場合は、再読み込みも実行してください。ディスク上のファイルを書き換えるだけでは、実行中のカーネルが直ちに新しい値を使うとは限りません。

利用場面に応じてモードを選ぶ

普段の閲覧と長時間のバックグラウンド利用

ルールモードを選びます。まず LAN、よく使うダイレクト接続のサービス、プロキシサービスがそれぞれ想定したルールにマッチすることを確認し、その後プロキシグループでノードを切り替えます。ルールモードなら通信ログを確認しやすく、すべての接続が同じリモート出口に集中するのも防げます。

特定のウェブサイトが突然開けない

ルールモードのまま接続ログを確認し、マッチしたルールとプロキシグループを記録します。その後、グローバルモードに切り替え、同じノードで接続を再確立します。グローバルで使えるならルールを見直し、グローバルでも使えないならノード、DNS、対象サービスを確認します。テスト後はルールモードに戻してください。

ローカルネットワークとノードの性能を比較する

まずダイレクトモードでローカルの基準値を3回測定し、次にグローバルモードでノードを固定して3回測定します。測定サーバー、デバイスの接続方式、時間帯はそろえてください。ルールモードで複数の測定ドメインを直接比較すると、異なるルールやプロキシグループに振り分けられる可能性があります。

NAS、ルーター、開発サービスへアクセスする

まずルールモードで LAN 用の DIRECT ルールを試します。一時的にダイレクトへ切り替えると、プロキシ出口が障害に関係しているか確認できますが、恒久的には社内ドメインとネットワーク帯のルールを整備してください。TUN のルートと企業 VPN が競合する場合は、ルーティングの除外設定も調整する必要があります。ダイレクトモードにするだけではルーティングテーブルは修復できません。

リモートプロキシを停止しつつクライアントの状態を確認する

ダイレクトモードを選ぶと、接続ログとローカルの引き継ぎ構成を維持したまま、リクエストの挙動を比較できます。OS 本来のネットワーク状態に戻すことが目的なら、システムプロキシと TUN も無効にし、DNS、デフォルトルート、仮想ネットワークインターフェースが復元されていることを確認します。

実行できるモード別トラブル対処チェックリスト

アプリの通信がシステムプロキシ、手動プロキシ、または TUN 経由で Clash に入っていることを確認します。
現在の実行モードを記録し、モードとプロキシグループ名を混同しないようにします。
接続画面で対象ドメイン、対象 IP、マッチしたルール、実際の経路を確認します。
ルールモードで問題が起きたら、同じノードを固定したグローバルモードで比較します。
ローカルの基準値が必要な場合はダイレクトモードに切り替え、DNS が引き続きカーネルで処理される可能性に注意します。
切り替えるたびに古い接続を終了し、ページを開き直すかテストアプリを再起動します。
原因の特定が終わったらルールモードに戻り、ルールの順序、ルールセット、プロキシグループの選択を修正します。

3つのモードに共通する速度の優劣はありません。ルールモードの結果はマッチしたルールとプロキシグループ、グローバルモードの結果は GLOBAL で選んだノード、ダイレクトモードの結果はローカル ISP の経路に左右されます。モードを選ぶ前に、テスト対象がルールの判断、リモートノード、ローカルネットワークのどれかを明確にしましょう。3つを分けて記録して初めて、接続ログから再現可能な結論を得られます。