入門ガイド 読了時間：約9分

Clashのルール・グローバル・DIRECTモードの違いと選び方

Clashのルール・グローバル・DIRECTモードの仕組みと使い分けを解説。切り替え後に接続できないときの確認ポイントも紹介します。

3つのモードの違い：接続先を決める機能であり、通信を取り込む範囲は決めない

普段、ローカルサービスとプロキシ経由でアクセスするサイトの両方を使うなら、まずはルールモードがおすすめです。ノードを検証するために一時的に振り分けルールを無視したい場合はグローバルモード、ローカルネットワークへの直接接続を比較したい場合はDIRECTモードを使います。この3つが決めるのは「Clashに渡された接続をどう処理するか」であり、「どのアプリの通信をClashに取り込むか」ではありません。

Clash系クライアントの画面には、Rule、Global、Direct、またはそれぞれに対応する日本語表記が使われています。Clash Metaは後継のmihomoという名称になりましたが、多くのクライアントではこの3つのモードが引き続き使われています。ルールの機能はコアによって異なる場合がありますが、「通信を取り込むこと」と「接続先を選ぶこと」は分けて考えましょう。

モード 取り込んだ接続の処理方法 主な用途 誤解しやすい点
ルール Rule ルールを上から順に照合し、DIRECT、拒否、またはポリシーグループに振り分けます。 ローカルサービスとプロキシ経由の通信を振り分ける、日常的な利用。 ノードを選択しても、すべてのサイトがそのノードを経由するとは限りません。
グローバル Global 通常の振り分けルールは使わず、GLOBALポリシーに接続先の選択を任せます。 ノードの一時的なテストや、ルールの誤判定の切り分け。 GLOBALでDIRECTを選ぶこともできます。また、すべてのアプリの通信を取り込む機能ではありません。
DIRECTモード 取り込んだ接続を、コアから接続先へ直接接続します。 ローカルネットワークとの比較や、プロキシノードを一時的に使わない場合。 コア、待ち受けポート、DNS機能は動作し続ける場合があります。

ルールモード：ルールを順に照合してポリシーグループへ

ルールモードでは、設定されたルールを上から順に照合します。通常のルールに一致すると、指定されたアクションに従って処理されます。接続先にはDIRECT、REJECT、または実際に定義されたポリシーグループを指定できます。ポリシーグループでは、使用するノードや下位のポリシーを選択します。接続の原因を調べるときは、どのルールに一致したか、そのルールが指定するグループで最終的に何が選ばれたかの2点を確認してください。

ルールは数より順序が重要

以下はルール部分の例であり、そのままインポートできる完全なサブスクリプションではありません。「ノード選択」は、現在の設定に定義済みのポリシーグループ名に置き換えてください。例の名前を残したまま対応するポリシーグループがない場合、設定の読み込みに失敗することがあります。

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,ノード選択
  • DOMAIN-SUFFIX,example.comは、そのドメインとサブドメインに一致します。この指定だけでは、文字列を一部に含む任意のドメインにも一致するとは限りません。
  • 192.168.0.0/16と10.0.0.0/8は、よく使われるプライベートアドレス範囲です。この例は、ローカルアドレスの範囲をすべて網羅しているわけではありません。
  • no-resolveは、このIPルールのためだけにドメイン名を積極的に解決しない指定です。接続先がすでにIPアドレスであれば、引き続き照合できます。
  • MATCHは最後に適用されるフォールバックルールです。前のほうに置くと、それ以降のルールが照合されなくなります。

日常使いに向いていますが、振り分けルールの管理が必要です

たとえば、LAN上のストレージには直接接続し、特定の外部サイトはプロキシグループに振り分け、残りの通信はフォールバックグループに送る、といった設定ができます。ただし、Webサイトのログイン、画像、動画で異なるドメインが使われることがあります。メインページが正しく振り分けられても、すべてのリクエストが同じ経路を通るとは限りません。

「ページは開くのに画像が表示されない」場合は、失敗したリクエストのドメインと一致したルールを確認しましょう。すべての通信をプロキシ経由に変更して、そのまま使い続けるのは避けてください。また、ブラウザーのアドレス欄に表示されたメインドメインだけを見てルールを追加するのも適切ではありません。ルールの配布元、サブスクリプションの更新状況、コアの対応範囲もあわせて確認してください。

グローバルモード：ノードの検証向け。すべての端末をプロキシ経由にする機能ではありません

グローバルモードでは、取り込んだ通常の通信がGLOBALポリシーで処理されます。切り替えたら、クライアントのプロキシまたはポリシーグループの画面を開き、GLOBALで現在選択されている接続先を確認してください。画面によってはグループが非表示になっていたり、グローバル用の選択欄が別に表示されたりします。実際の接続詳細に表示される接続先を確認しましょう。

グローバルモードにしても、必ずリモートノードを経由するとは限りません。GLOBALでDIRECTが選ばれていれば、接続は直接行われます。GLOBALが別のポリシーグループを指定している場合は、そのグループで最終的に何が選ばれているかも確認が必要です。ルールモードでよく使う「ノード選択」グループが、GLOBALと連動しているとも限りません。

グローバルモードでノードの問題とルールの問題を切り分ける

  1. ルールモードで失敗したリクエストのドメイン、一致したルール、接続先ノードを記録します。
  2. グローバルモードに切り替え、GLOBALでテスト対象と同じノードを選びます。
  3. 該当する既存の接続を終了してから、リクエストを再実行します。接続が再利用されているページだけを見て判断しないでください。
  4. グローバルでは使えてルールモードでは使えない場合、振り分けルール、接続先のポリシーグループ、DNSの違いを優先して確認します。どちらでも失敗する場合は、ノードとローカル側の通信取り込み経路を確認してください。

この比較は原因を絞り込むためのものであり、最終的な結論ではありません。リモートサービスのレート制限、DNSキャッシュ、接続の再利用、テスト時刻の違いなどが結果に影響することがあります。できるだけ同じネットワーク、同じ接続先、同じノードを使い、モードだけを変更して比較してください。

DIRECTモード：ネットワークの比較向け。クライアントを終了する機能ではありません

DIRECTモードでは、コアに取り込まれた通信は通常、一般的なルールでプロキシノードを選ばず、接続先へ直接アクセスします。「今回の失敗はプロキシノードが原因か」を調べるのに役立ちます。たとえば、同じリソースがDIRECTでは使えるのに特定のプロキシノードでは失敗する場合、そのノードの接続状況や、接続先サイトによる接続元の制限を確認できます。

ただし、DIRECTモードに切り替えても、システムプロキシがローカルの待ち受けポートを指したままの場合や、TUN仮想NICが動作し続ける場合があります。クライアントのDNS待ち受け、キャッシュ、関連する名前解決経路も停止するとは限りません。そのため、DIRECTモードはプロキシノードを使わない比較には使えますが、クライアントを終了した状態のネットワークを完全に再現するものではありません。

  • 一時的にノードを経由せず接続したい：DIRECTモードに切り替え、接続詳細の接続先がDIRECTになっていることを確認します。
  • クライアントを完全に経由しない状態をテストしたい：まずシステムプロキシとTUNを無効にし、必要に応じてクライアントを終了します。システムに手動プロキシ設定が残っていないことも確認してください。
  • 終了後、どのWebページも開けない：システムのプロキシ設定が127.0.0.1のプロキシポートを指したままなのに、対応する待ち受けが停止していないか確認してください。

DIRECTモードでも、すべての接続先にアクセスできるわけではありません。接続先への到達性は、ローカルネットワーク、ルーティング、DNS、サーバー側のポリシーにも左右されます。特定のサイトに直接接続できないからといって、それだけでクライアントの設定ミスとは断定できません。

システムプロキシとTUN：コアに取り込む接続を決める

システムプロキシは、OSのプロキシ設定を通じて、その設定に従うアプリのリクエストをローカルのHTTPまたはSOCKSポートに送ります。ブラウザーはシステムプロキシに対応していることが多い一方、コマンドラインツール、ゲーム、一部の独立したアプリは独自のネットワーク設定を使う場合があります。TUNは仮想NICとルーティングを使って対象の通信を取り込みますが、範囲はルート、除外設定、権限、コアの設定によって異なります。

まず待ち受けポートを確認し、通信の取り込み経路をテスト

以下のコマンドでは、クライアントのHTTPまたは混合ポートが7890であることを前提としています。これは説明用の例であり、すべてのクライアントのデフォルト値ではありません。実行前にクライアントのポート設定を確認してください。Windowsではcurl.exe、macOSとLinuxでは通常curlを使います。

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つ目のコマンドはローカルのプロキシポートを明示的に経由し、2つ目はcurlでアプリケーション層のプロキシを使わずにリクエストします。TUNが有効な場合、2つ目の通信も仮想NICに取り込まれる可能性があるため、クライアントを完全に経由しないテストとは言えません。接続パネルも確認し、どちらのリクエストがコアに取り込まれたか、最終的な接続先がどこかを調べてください。

コマンドでHTTPレスポンスを受け取れても、動画、ゲームのUDP通信、システム全体のプロキシ接続が正常だとは証明できません。HTTPプロキシのテストとUDP通信の取り込みは別の問題です。後者は、接続方法、ノードのプロトコル、サーバー側の対応にも左右されます。

モード切り替え後に接続できないときは、5つの項目を順番に確認

1. 現在の設定と最終的な接続先を確認

まず、どのサブスクリプションまたはローカル設定が有効かを確認し、モードとポリシーグループを見ます。サブスクリプションの更新でルールやグループ名が変わることがあります。画面で以前選択したノードが、現在の接続でも使われているとは限りません。ルールモードでは一致したルール、グローバルモードではGLOBAL、DIRECTモードではDIRECTを確認してください。

2. 既存の接続を終了してから再テスト

モードの切り替えは通常、新しく確立する接続に反映されます。既存のTCP接続や一部のUDPセッションは、切り替え前の経路を使い続けることがあります。ブラウザーのHTTP/2やHTTP/3では接続が再利用されるため、この現象が目立つ場合があります。クライアントの接続パネルから対象の接続を終了し、ページを開き直してください。すべての接続を終了するとダウンロードや会議なども中断されるため、作業内容を事前に保存しましょう。

3. DNSと通信の接続先を分けて確認

名前解決に失敗している場合、グローバルモードに切り替えても解決するとは限りません。ログにDNSタイムアウト、接続先の名前解決エラー、fake-ip関連の異常がないか確認してください。mihomoでは、DNSの上流サーバー、名前解決のポリシー、ルールに従うかどうかは実際の設定によって異なります。「グローバルモードならすべてのDNSがノードを経由する」とは限りません。変更前に設定をバックアップし、DNS、ノード、モードを同時に変更しないでください。

4. システムプロキシ、TUN、ほかのネットワークツールを確認

プロキシを明示したテストは成功するのに、ブラウザーからの接続が記録されない場合は、ブラウザー独自のプロキシ設定を優先して確認してください。TUNを有効にしてから失敗する場合は、実行権限、ルートの除外設定、ほかのVPNとの競合を調べます。判断への影響を避けるため、テストする通信の取り込み経路は一度に1つだけにし、システムプロキシと複数の仮想NICを併用しないでください。

5. レイテンシだけでなく、同じ条件で記録して比較

ノードのレイテンシテストは通常、特定のアドレスへの単発の測定であり、接続先サイトでの実効速度を示すものではありません。同じネットワークで、3回のリクエストについてモード、ノード、接続先のドメイン、結果、エラー内容を記録すると比較しやすくなります。たとえば「ルールモードでDIRECTに一致しタイムアウト。グローバルモードでノードAを選択し、HTTP 200を受信」のように記録すれば、「ノードの表示は80 ms」だけより原因を特定しやすくなります。数値は記録方法の例であり、このサイトで測定した結果ではありません。

普段はルールモード、グローバルとDIRECTは比較に活用

  • 仕事、Web閲覧、LAN機器を併用する：ルールモードを優先し、プライベートアドレスやよく使うサービスに実際に一致したルールを確認します。
  • 振り分けミスが疑われる：一時的にグローバルモードへ切り替え、テストするノードを明示的に選びます。既存の接続を終了してから、同じ接続先で比較してください。
  • ノードまたはリモート回線の問題が疑われる：DIRECTモードと比較します。クライアントを経由しない状態を基準にする場合は、システムプロキシとTUNも無効にしてください。
  • 特定のアプリだけで問題が起きる：まず、そのアプリの通信がコアに取り込まれているか確認します。通信の取り込み方法を調べず、3つのモードを何度も切り替えるだけでは解決しません。

原因を切り分けるには、通信がコアに取り込まれているか、現在のモードがどう処理しているか、最終的な接続先が想定どおりかの順に確認します。この3点を把握してから、ルールやノードを調整してください。インストールや設定のインポート方法はClashの使い方ガイドを、ルールの各項目はプロトコルリファレンスをご覧ください。

Clash をダウンロード