入門 読了時間：約9分

Clashのルール・グローバル・ダイレクトモードを比較｜用途別の選び方

Clashのrule・global・directモードを実例で比較。通信の振り分け方や適した用途、切り替え後の確認方法を解説します。

3つのモードが決めるのは通信の出口。通信がコアに入るかどうかではありません

Clashのプロキシモードは、通信がコアに入った後の処理方法です。ruleはルールに従ってポリシーを選び、globalは組み込みのグローバルポリシーGLOBALを使い、directは直接接続します。Clash Metaからmihomoへ移行した後も、この3つの基本モードで使う設定値は変わりません。

ここでは2つの役割を区別する必要があります。システムプロキシ、アプリのプロキシ設定、TUNは、接続をコアに送るためのものです。一方、プロキシモードは、受け取った接続の経路を決めます。つまり「グローバルモード」にしても、パソコン上のすべてのアプリが自動的にプロキシ経由になるわけではありません。システムプロキシを無視し、TUNでも捕捉されないアプリは、グローバルモードに切り替えてもノードを経由しません。

設定値画面での一般的な表示名新しい接続の出口の選び方主な用途
ruleルール、Ruleルールを上から順に照合し、該当したポリシーを適用普段の通信振り分け、LAN内通信の直接接続
globalグローバル、GlobalGLOBALで現在選択されている出口を使用一時的に出口を統一、ルールの切り分け
directダイレクト、Directプロキシノードを経由せず、接続先へ直接接続ローカルネットワークのテスト、プロキシ転送の一時停止

ルールモード：上から順に照合し、最初に一致したルールを適用

mode: ruleは、設定に従って通信を振り分けるモードです。よく使われるルールには、ドメインのサフィックス、宛先IPの範囲、最後に適用するフォールバックポリシーがあります。通常、ルールは上から順に評価され、最初に一致したルールで接続のポリシーが決まります。後続のルールで出口が再選択されることはありません。

シンプルで分かりやすい振り分け設定例

以下は設定の一例です。組み込みのDIRECTポリシーのみを使って構文を確認するためのもので、プロキシノードを自動で追加するものではありません。

mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

実際のサブスクリプションにProxyという名前のプロキシグループがある場合は、最後の行をMATCH,Proxyに変更できます。名前は大文字・小文字も含め、設定内のプロキシグループと完全に一致させてください。対応するグループを作らずにルールだけ追加すると、設定の読み込み時にポリシーが存在しないというエラーが発生することがあります。

プロキシグループに一致しても、プロキシノードが選択されているとは限らない

ルールが指定するのはポリシーです。ポリシーにはノード、選択グループ、自動遅延測定グループ、DIRECTなどがあります。たとえば、ルールがProxyに一致していても、その選択グループでDIRECTが選ばれていれば、実際の接続は直接接続になります。原因を調べる際は、「どのルールに一致したか」と「ポリシーグループで最終的に何が選ばれているか」の両方を確認してください。ルール名だけでは判断できません。

グローバルモード：GLOBALを使うが、通信の捕捉範囲は変わらない

mode: globalでは、コアに入った通常の接続に組み込みの選択ポリシーGLOBALを使い、通常のrulesリストによる振り分けは行いません。切り替え後は、クライアントのプロキシ選択画面でGLOBALを開き、想定したノードまたはポリシーが選ばれていることも確認してください。

クライアントによっては、この項目が「グローバル」や「グローバル選択」と表示されます。メニュー名はクライアントごとに異なるため、現在のモードがglobalで、グローバルポリシーの選択先が明確であることを確認してください。GLOBALの接続先がDIRECTのままなら、グローバルモードでもプロキシ経由にはなりません。

一時的な比較テストに便利

  1. ルールモードで特定のサイトに接続できない場合は、まず一致したルールとポリシーを記録します。
  2. グローバルモードに切り替え、利用可能と確認済みのノードを選びます。
  3. 対象サイトの既存の接続を終了し、リクエストをもう一度送信します。
  4. 新しい接続で問題が解消した場合は、ルールの順序、ドメインの適用範囲、元のポリシーグループの選択を確認します。

この結果から分かるのは、2回のテストで異なる経路が使われたということだけで、「ルールファイルが壊れている」とは限りません。使用ノードの違い、DNSの応答変化、既存接続が残っていたことなども結果に影響します。比較時はノード、宛先アドレス、通信の捕捉方法をできるだけそろえ、モードだけを変更してください。

ダイレクトモード：ノードを使わないが、クライアントは停止しない

mode: directは、コアに入った接続をプロキシノード経由にせず、宛先へ直接接続するモードです。システムプロキシ、TUN仮想NIC、コアのDNSサービスは有効なままの場合があります。そのため、「ダイレクトモード」と「クライアントを終了して通信の捕捉を停止する」ことは、同じテスト条件ではありません。

たとえば、ブラウザーが引き続き127.0.0.1:7890へリクエストを送り、コアが受け取ってから宛先へ直接接続する場合も、ローカルのプロキシ入口を経由しています。7890はよくある設定例にすぎません。実際のポートは、稼働中の設定にあるmixed-portまたはportを確認してください。

ダイレクトモードで比較できる問題

ダイレクトモードにしても、すべてのサイトに接続できるとは限りません。また、DNSが自動的にプロバイダーのサーバーへ切り替わるわけでもありません。名前解決には、現在の設定に応じて暗号化DNS、指定リゾルバー、その他のDNSルールが使われることがあります。名前解決の問題を調べる場合は、モード切り替えをDNSのリセットとして扱わず、dns設定を個別に確認してください。

切り替え後の確認方法：設定・接続・出口を分けて確認

YAMLのmodeを書き換えても、稼働中のコアに新しい値が適用されたとは限りません。クライアントによっては画面上の状態や上書き設定がサブスクリプションの値より優先されます。また、サブスクリプションの更新で手動変更が置き換わることもあります。クライアントに現在表示されている稼働モードと、新しい接続の記録を基準にしてください。

ウェブページが開くかどうかだけで判断せず、決まった手順で確認

  1. 変更前の状態を記録。モード、選択中のノード、システムプロキシやTUNの状態を記録し、元に戻せる設定を残します。
  2. 変更する項目は1つだけ。DNS、ノード、ルールは同時に変更せず、まずモードだけを切り替えます。グローバルモードで出口を選ぶ場合は、選択した項目も記録します。
  3. 新しい接続を作成。テストするアプリの既存接続を終了します。必要であれば、クライアントの接続パネルから該当する接続を切断してください。既存のTCP接続は通常、新しい出口へ自動的に切り替わりません。
  4. 接続の詳細を確認。「接続」または「Connections」画面で、対象のドメイン、宛先IP、一致したルール、ポリシーの経路を確認します。表示される項目はクライアントによって異なります。
  5. 出口を確認。信頼できる出口IP確認サービスを利用し、結果をダイレクト接続時の基準と比較します。出口IPが同じでも設定が無効とは限りません。異なる経路が同じグローバルIPを共有していることもあります。

curlでテスト経路を固定する

現在の設定でmixed-port: 7890が有効だと仮定すると、ローカルプロキシを明示して、ブラウザー拡張機能やシステムプロキシ設定の影響を抑えられます。

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

1つ目のコマンドは、指定したローカルHTTPプロキシの入口を経由し、現在のモードに従って出口が決まります。「リモートノードを強制的に使う」コマンドではありません。2つ目はcurlに明示したプロキシを使いませんが、TUNが引き続き通信を捕捉していれば、リクエストがコアに入る可能性があります。そのため、クライアントを迂回する基準テストとは言い切れません。Windows PowerShellでcurlのエイリアスによる違いがある場合は、curl.exeを使ってください。

例にある接続タイムアウト10秒、合計タイムアウト20秒はテストの上限であり、速度の基準ではありません。コマンドでHTTPステータスが返っても、想定した出口が使われた証明にはなりません。最終的にはコアの接続記録も確認してください。接続先がHEADリクエストに対応していない場合は、通常のGETリクエストに切り替えて再確認します。

用途に応じて選ぶ：普段の振り分け、一時的な切り分け、ダイレクト接続の基準

利用シーンまず試すモードあわせて確認すること
イントラネットと外部サービスを併用する日常のアクセスルールモードローカルネットワークの範囲、ドメインルール、フォールバックポリシーが適切か
特定のドメインが誤って振り分けられている疑いがある一時的にグローバルモードへ切り替えて比較GLOBALの選択先、既存接続が終了しているか
一時的にプロキシノードを使いたくないダイレクトモードDNSと通信の捕捉は引き続き動作する場合がある
特定のアプリが接続パネルにまったく表示されないまず通信の捕捉方法を確認アプリのプロキシ設定、システムプロキシへの対応、TUNのルーティング
クライアントを経由しないローカルネットワークをテストしたい通信の捕捉を無効にしてテストシステムプロキシ、TUN、アプリの手動プロキシ設定がすべて元に戻っていること

普段使いでは、まずルールモードを選び、どの接続を直接つなぎ、どの接続をプロキシグループへ送るかを明確にします。グローバルモードは、一時的に出口を統一したい場合やルールと比較したい場合に便利です。ダイレクトモードは、ノードを一時的に使わない場合や、テストの基準を作る場合に適しています。3つのモードに決まった速度の順位はありません。実際の速度や接続結果は、出口、ノードの品質、接続先サービス、ローカルネットワークによって変わります。

よくある誤解：モードを切り替えても解決しない問題

グローバルモードなら接続できるのに、ルールモードでは接続できません。ずっとグローバルモードにしておくべきですか？

すぐにそう判断する必要はありません。まずルールモードで失敗した接続がどのルールに一致したかを確認し、対応するグループで利用可能なノードが選ばれているか調べます。ドメインに関連する接続先が複数ある場合、メインのドメインだけを設定しても、ログイン、静的リソース、APIへのリクエストを処理できないことがあります。接続記録を見ながら必要なルールを追加すれば、すべての振り分けを恒常的に迂回するより、イントラネットへのアクセスも維持しやすくなります。

ダイレクトモードに切り替えても、ログが増え続けるのはなぜですか？

ダイレクトモードでもコアは停止しません。システムプロキシやTUNが引き続き通信をコアへ送っている限り、接続記録は表示されます。リモートノードを使っているかどうかは、クライアントの通信量表示ではなく、最終的なポリシーと出口で判断してください。

グローバルモードなら、すべてのUDP通信をプロキシできますか？

いいえ。UDPがコアに入るかどうかは通信の捕捉方法によって異なり、転送できるかどうかは入口、選択したノードのプロトコル、その設定にも左右されます。ブラウザー向けのHTTPシステムプロキシを設定しただけでは、ゲームや音声通話アプリのUDP通信まで捕捉されるとは限りません。モードをglobalに変えても、欠けている経路が補われるわけではありません。

詳細な設定は使い方ガイドをご覧ください。mode、rules、ポート、DNSの設定項目を確認する場合は、設定リファレンスを参照してください。確認の順序は、まず通信がコアに入っているか、次にポリシーの選択、最後に実際の出口です。

Clashのダウンロード