はじめに 読了目安 12分

Clashのルールモード・グローバルモード・ダイレクトモードの違いと選び方

Clashの3つのプロキシモードについて、通信経路や用途、よくある誤設定を整理。日常利用、トラブル切り分け、LANテストで選ぶべきモードを解説します。

ClashクライアントのRule、Global、Directは、通信がClashコアに入った後、どの出口を選ぶかを決めます。3つのモードを切り替えても、サブスクリプション内のノード数が変わったり、ノードのプロトコルが自動変更されたりすることはありません。変わるのは、ルールで判定するか、すべての接続を1つのプロキシグループに渡すか、接続先へ直接アクセスするかという点です。

日常利用では通常、ルールモードを選びます。グローバルモードはノードの一時的な確認やルールのマッチ漏れの切り分けに、ダイレクトモードは問題がプロキシ経路に起因するか確認するときに適しています。選ぶ前に、2つの概念を分けて考えましょう。システムプロキシやTUNモードは通信をClashへ取り込み、プロキシモードはコアに入った通信をどこから外へ出すかを決めます。

3つのモードで変わる点

ルールモード：ルールごとに判定して出口を選択

ルールモードに対応する設定値は mode: rule です。通信がコアに入ると、Clashは rules リストを上から順に確認し、ドメイン、IP、ポート、プロセス、ルールセットを判定します。最初に一致したルールで判定を停止し、そのルールが指定するプロキシグループ、プロキシノード、DIRECT、または REJECT に接続を渡します。

たとえば intranet.example にアクセスすると、ドメインサフィックスのルールによって直接接続できます。それ以外の宛先では、末尾の MATCH が通信を「ノード選択」プロキシグループへ渡します。ルールの順番は結果を直接左右するため、範囲が狭く具体的なルールを、範囲の広いルールより前に置くのが基本です。

mode: rule
mixed-port: 7890

rules:
  - DOMAIN,intranet.example,DIRECT
  - DOMAIN-SUFFIX,example.org,ノード選択
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,ノード選択

ルールモードの価値は、単に「一部のサイトをプロキシ経由にする」ことではありません。通信ごとに異なる出口を使い分けられる点にあります。LANアドレスは直接接続し、接続不要のドメインは拒否し、よく使うサービスは自動選択グループへ渡し、それ以外のリクエストは手動選択グループへ送る、といった制御が可能です。ルールセットとプロキシグループを適切に設定すれば、日常的にモードを切り替える必要はありません。

グローバルモード：ルールをスキップしてGLOBALへ一括転送

グローバルモードに対応する設定値は mode: global です。このモードでは、通常の接続は rules を1件ずつ判定せず、GLOBAL という組み込みのプロキシ入口へまとめて送られます。クライアントのグローバルプロキシ設定で具体的なノードまたはプロキシグループを選んでください。選択しない場合、以前の選択がそのまま使われることがあります。

「グローバル」とはClashコア内部のルーティング方式を指し、PC上のすべてのパケットが必ずプロキシを通るという意味ではありません。システムプロキシを使わないプログラム、TUNで捕捉されないプロトコル、クライアントの除外リストにあるプロセス、一部のLANブロードキャスト通信などは、Clashに入らない場合があります。ブラウザーがシステムプロキシを利用している場合、グローバルモードの影響を受けるのは通常、ブラウザーなどその設定に従うアプリです。

ダイレクトモード：コア通過後にローカルネットワークから直接接続

ダイレクトモードに対応する設定値は mode: direct です。通信がシステムプロキシのポートやTUNインターフェースを経由してClashに入った後でも、コアはサブスクリプションのノードを使わず、宛先へ直接接続します。プロキシ利用前後のアクセス結果を比較したいときや、LANサービス、社内ネットワーク、ローカル開発サーバーをテストするときに便利です。

ダイレクトモードはクライアントを終了した状態ではありません。システムプロキシが 127.0.0.1:7890 を指していれば、リクエストはいったんClashに届き、Clashから直接接続されます。TUNが有効なままなら、通信が仮想インターフェースを通り続けることもあります。OS本来のネットワーク経路へ完全に戻すには、システムプロキシまたはTUNも無効にし、システムのネットワーク設定が復元されたことを確認してください。

通信経路を表で確認

比較項目 ルールモード グローバルモード ダイレクトモード
設定値 rule global direct
rulesを読み込むか 順番にマッチング 通常はスキップ 通常はスキップ
主な出口 一致したルールで決定 GLOBALで選択したノードまたはプロキシグループ ローカルネットワークのDIRECT
主な用途 日常利用と細かな振り分け 一括プロキシ、ノード確認、マッチ漏れの切り分け 比較テスト、LANアクセス、プロキシ要因の除外
よくあるリスク ルールの順番ミスや末尾ルールの不備 ローカルサービスまでプロキシに送られ、通信量が増える プロキシが必要な宛先にアクセスできない

日常利用ではどれを選ぶか

通常運用ではルールモードを優先

サブスクリプション設定に十分なルールセットが含まれている場合、ルールモードが通常もっとも適したデフォルト設定です。ローカルサイト、LAN機器、プロキシが必要な宛先をそれぞれ適切な経路へ振り分け、不要なプロキシ通信を減らせます。通信量に倍率が設定されたサブスクリプションでは、システム更新やLAN内のファイル転送までプロキシノードへ送ってしまう事態も防げます。

ルールモードを選んだら、クライアントの「プロキシ」→「モード」でRuleが選択されていることを確認し、現在のプロキシグループも確認します。グラフィカルクライアントによっては「プロキシモード」「ルーティングモード」またはModeと表示されますが、コアの値は rule です。Clash for Windows v0.20.39ではProxiesページでモードとプロキシグループを確認できます。mihomoベースのクライアントでも通常、「プロキシ」ページにRule、Global、Directの3項目があります。

一時的な切り分けではグローバルモードへ切り替える

ルールモードで特定のサイトだけ開けず、ノードの速度テストは正常な場合は、まずグローバルモードへ切り替え、GLOBALで利用可能なノードを明示的に選びます。グローバルモードでアクセスできるなら、問題はルールマッチング、プロキシグループの選択、またはルールセットの更新にある可能性が高いです。それでもアクセスできない場合は、ノード自体、DNS、システム時刻、ネットワーク接続を引き続き確認します。

  1. 現在のモードとプロキシグループを記録し、テスト後に戻し忘れないようにします。
  2. 「プロキシ」→「モード」を開き、Globalを選択します。
  3. GLOBALのプロキシ入口で、遅延テストが完了しているノードを1つ選択します。
  4. ブラウザーキャッシュの影響を避けるため、新しいシークレットウィンドウで対象をテストします。
  5. テスト後はRuleに戻し、対象ドメインで実際に一致したルールを確認します。

グローバルテストは数分以内にとどめるのが安全です。ソフトウェア更新、クラウドストレージの同期、動画再生などのバックグラウンド通信も、選択したノードへ一括で送られる可能性があります。テスト前に大容量通信を一時停止すると、対象リクエスト自体の変化を確認しやすくなります。

LANや比較テストではダイレクトモードを使う

ルーターの管理画面、NAS、プリンター、ローカル開発サービスへアクセスする場合、ダイレクトモードを使うとプロキシルーティングが問題に関与しているかをすばやく判断できます。たとえば 192.168.1.1、10.0.0.20:8080、localhost:3000 にアクセスし、Directへ切り替えて復旧したなら、元のルールがLANアドレスを誤ってプロキシグループへ渡していた可能性があります。

長期的な解決策は、常にダイレクトモードにしておくことではなく、ルールモードにLAN向けルールを追加することです。代表的なプライベートアドレス範囲は 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 です。これらを包含する広範なIPルールより前に配置し、no-resolve を追加すると、IPルールに対する不要なDNS解決を避けられます。

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,ノード選択

システムプロキシ、TUN、モード切り替えの関係

システムプロキシは設定を読み取るアプリだけを引き受ける

Clashでよく使われるHTTP、SOCKS、mixedの待受ポートは 7890 ですが、実際の値は設定ファイルとクライアントのホーム画面を確認してください。システムプロキシを有効にすると、Windowsのシステム設定にプロキシアドレスが登録されます。ブラウザーや一部のデスクトップアプリはこの設定を読み取り、Clashへリクエストを送ります。一方、一部のゲーム、コマンドラインツール、独自のネットワークスタックを持つアプリは無視することがあります。

そのため、Globalへ切り替えても、システムプロキシを無視するアプリが突然Clashを経由するわけではありません。Windows 11の「設定」→「ネットワークとインターネット」→「プロキシ」でプロキシの状態を確認するか、クライアントの接続ログを確認してください。テスト対象のアプリがConnectionsまたは「接続」ページに表示されない場合、問題は通信がコアに入る前に発生しており、Rule、Global、Directの選択とは直接関係ありません。

TUNモードは取り込み範囲を広げるが、ルーティングモードの代わりにはならない

TUNモードは仮想インターフェースとシステムルートを使って、より多くの通信を捕捉します。システムプロキシに対応しないアプリにも適しています。TUNで捕捉された通信も、現在のルーティングモードを通ります。Ruleはルールを確認し、Globalはグローバルプロキシ入口へ送り、Directはローカルネットワークから直接接続します。TUNが解決するのは「どうやってコアへ入れるか」であり、3つのモードが決めるのは「入った後にどう出るか」です。

mihomoの設定では、TUNに関する代表的なフィールドとして enable、stack、auto-route、strict-route があります。これらは仮想インターフェースとシステムルートに影響しますが、mode の代わりにはなりません。切り分けでは一度に1つの変数だけを変更します。まずTUNの状態を変えずにモードを切り替え、次にモードを固定してTUNをテストすると、結果を解釈しやすくなります。

DNSによってテスト結果が矛盾して見えることもある

モード切り替えが主に決めるのは接続の出口であり、DNSの問い合わせ経路は dns セクション、システムDNS、プロキシ実装、キャッシュの影響も受けます。ルールモードでは開けず、グローバルモードでは開ける場合、原因はドメインルールだけとは限らず、出口の違いによって異なる名前解決結果が返っている可能性もあります。テスト時は対象アプリをいったん終了して再起動し、必要に応じてシステムのDNSキャッシュを消去したうえで、クライアントログのドメイン、宛先IP、適用されたプロキシ設定を確認します。

fake-ipを使うと、アプリには 198.18.0.0/16 の範囲にあるマッピングアドレスが表示されることがあります。これはClashのドメインマッピング機能によるもので、Webサイトの実サーバーがそのアドレス範囲にあるという意味ではありません。ルールの一致を判断するときは、アプリに表示された宛先IPだけで結論を出さず、接続詳細のHost、Rule、Chainsを確認してください。

よくある誤用と修正方法

誤用1：グローバルモードを高速化モードだと思う

Globalにしても、ノードの遅延が自動的に下がったり、帯域幅が増えたりすることはありません。単にルールによる振り分けをスキップし、接続を選択した出口へまとめて送るだけです。グローバルモードでサイトが速くなった場合、ルールモードで別のプロキシグループが選ばれていたか、ルールセットによって不適切なノードへ送られていた可能性があります。接続詳細を確認し、Globalで問題を隠すのではなく、ルールまたはプロキシグループを修正するのが正しい対応です。

誤用2：ダイレクトモードにすればクライアントが終了したと思う

Directの状態でも、待受ポート、システムプロキシ、TUNインターフェース、DNSモジュールは動作し続ける可能性があります。「クライアントを完全に経由しない」ネットワーク状態をテストするには、TUNを無効にし、システムプロキシを無効にしてからクライアントを終了し、Windowsのプロキシ設定で手動プロキシが無効になっていることを確認してください。Directへの切り替えだけで再現できるのはプロキシ出口のテストであり、クライアント完全終了時の状態ではありません。

誤用3：グローバルモードでGLOBALのノード選択を忘れる

Globalへ切り替えた後は、GLOBALが現在どこを指しているかも確認する必要があります。自動選択のプロキシグループを指している場合、最終ノードはヘルスチェックによって変わる可能性があります。無効なノードを指していれば、コアに入るすべての通常通信に影響します。切り分けでは、遅延テストの結果があり、最近利用できた具体的なノードを選び、ノード名とテスト日時を記録してください。

誤用4：YAMLを編集したのに再読み込みせずモードだけ切り替える

mode、rules、プロキシグループを手動で変更しても、クライアントの実行中設定が自動更新されるとは限りません。「設定」→「再読み込み」またはクライアントのReloadに相当する入口を使ってください。YAMLではスペースで階層を表します。Tab、コロンの欠落、リストのインデント不一致は、読み込み失敗の原因になります。

mode: rule

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ノード選択
  - MATCH,ノード選択

症状別にモードの切り分けを行う

サイトがグローバルモードでだけアクセスできる

  • 接続ページで対象ドメインを見つけ、一致したルールとプロキシチェーンを記録します。
  • ルールモードで DIRECT、誤った地域のプロキシグループ、または無効なノードに振り分けられていないか確認します。
  • サブスクリプションとルールセットを手動で更新し、設定を再読み込みします。
  • 対象ドメイン用のより具体的なルールを追加し、広範なルールより前に配置します。
  • Ruleに戻して再テストし、Globalに依存せずアクセスできることを確認します。

ダイレクトモードは正常だが、ルールモードとグローバルモードでは異常がある

通常は、ローカルネットワークから対象へ直接到達できる一方、現在のプロキシノードまたはプロキシ経路に問題があることを示します。まずノードの遅延テストを実行し、同じ地域の別ノードへ切り替えます。遅延テストで確認できるのはテスト先への到達性だけで、対象サービスが利用できるとは限りません。接続ログでタイムアウト、接続拒否、TLSハンドシェイク失敗がないかも確認してください。

複数のノードで異常が出る場合は、サブスクリプションの有効期限、システム時刻の正確さ、セキュリティソフトによるクライアントプロセスの遮断を確認します。Windowsの時刻が数分ずれると、TLS証明書の検証に失敗することがあります。「設定」→「時刻と言語」→「日付と時刻」で時刻の自動設定を有効にし、「今すぐ同期」を実行してください。

3つのモードすべてでアクセスできない

まず通信がClashに入っているか確認します。接続一覧に対象リクエストがまったく表示されない場合は、システムプロキシ、TUN、アプリ独自のプロキシ設定、待受ポートを確認してください。リクエストが見えているのに3つのモードすべてで失敗する場合は、DNS、対象サーバーの状態、ローカルファイアウォール、基本的なネットワーク接続を確認します。いったんクライアントを終了して直接アクセスし、明確な比較結果を作る方法もあります。

モード選択の早見表

  • 通常のWeb閲覧、業務利用、長時間のバックグラウンド通信：Ruleを選び、ルールセットに日常の振り分けを任せます。
  • 対象ドメインが誤ったルールに一致した疑いがある：短時間だけGlobalを選び、アクセス結果を比較してからルールを修正します。
  • サブスクリプションの特定ノードで対象通信を処理できるか確認する：Globalを選び、GLOBALでそのノードを指定します。
  • ルーター、NAS、ローカル開発サービスへアクセスする：まずDirectで比較し、その後LAN向けの直接接続ルールを追加します。
  • 障害がプロキシ出口に起因するか判断する：取り込み方式を変えず、Rule、Global、Directを順番に比較します。
  • OS本来のネットワークをテストする：TUNとシステムプロキシを無効にしてからクライアントを終了します。Directへ切り替えるだけでは不十分です。

安定した使い方は、Ruleをデフォルトにし、GlobalとDirectを診断用に使うことです。テストのたびに変更する条件は1つだけにし、現在のノード、一致したルール、取り込み方式、結果を記録してから元の設定へ戻します。こうすればルールの問題をすばやく特定でき、システムプロキシ、TUN、DNS、プロキシモードを混同せずに判断できます。

クライアントをダウンロード