Clashのルール・グローバル・ダイレクトの選び方：用途別の比較と切り替えのポイント

まず2つのスイッチを分けて考える：通信の取り込みとプロキシモード

Clashクライアントの「システムプロキシ」「TUNモード」と「ルール・グローバル・ダイレクト」は、同じ階層の設定ではありません。システムプロキシまたはTUNは通信をClashのコアへ取り込み、プロキシモードは、コアに入った接続をプロキシノード、DIRECTによる直接接続、REJECTによる拒否のどれに振り分けるかを決めます。プロキシモードだけを切り替えてもシステムプロキシは自動で有効にならず、TUNだけを有効にしても、すべての接続が必ずリモートノード経由になるわけではありません。

一般的な設定では、HTTPとSOCKSが共有するmixed-portに7890、コントロールインターフェースのexternal-controllerに127.0.0.1:9090が設定されている場合があります。ブラウザーで127.0.0.1:7890を明示的に使うか、OSのプロキシをこのポートに向けて初めて、リクエストがコアへ入ります。TUNを有効にすると、システムプロキシを参照しないアプリやUDP通信、一部のコマンドラインプログラムも取り込めるようになります。ポートは設定値であり、クライアントによって実際の番号が異なる場合があるため、「設定」→「ポート設定」または現在の設定ファイルを確認してください。

3つのモードが処理するのは、取り込み済みの同じ接続群

ルールモード rule：設定内のrulesを上から順に照合し、合致したルールに従ってプロキシグループ、DIRECT、またはREJECTを選択します。
グローバルモード global：通常の分流ルールをスキップし、接続をGLOBALというグローバルポリシーの入口へ渡して、そこで選択されたノードまたはプロキシグループを使用します。
ダイレクトモード direct：取り込み済みの接続から対象アドレスへ直接アクセスし、通常はリモートプロキシノードを経由しません。

ここでいう「ルールをスキップする」には注意が必要です。コアは接続の受け付け、宛先の識別、DNSなどの基本処理を引き続き行い、クライアント側でもLANバイパス、プロセス除外、ループバック防止などの処理が残る場合があります。そのためdirectはClashを終了する操作ではありません。完全に取り込みを停止したい場合は、別途システムプロキシとTUNを無効にし、必要に応じてコアも停止してください。

ルールモード：日常利用の基本設定

ルールモードは常時運用に適しています。ルールを上から順に確認し、最初に一致したルールがただちに適用され、それ以降のルールは判定されません。典型的には、LANと中国本土のサイトを直接接続し、指定ドメインや海外向け通信をプロキシグループへ送り、最後にMATCHで未分類の接続を受け止めます。

mode: rule
mixed-port: 7890

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

この例では、example.comへのアクセスは最初のルールに一致してProxyへ渡されます。.cnで終わるその他のドメインは直接接続され、まだ一致しない中国本土のIPはGEOIP,CNで処理され、最後に残ったリクエストがProxyへ入ります。ルールの順番は自由に入れ替えられません。たとえばMATCHを先頭に置くと、その下のDOMAIN-SUFFIXとGEOIPは実行される機会がなくなります。

ルールモードが適する具体的な場面

日常のブラウジング：中国本土のサービスは直接接続し、海外サービスはルールに従ってプロキシへ送ることで、不要な遠回りを減らします。
動画とダウンロードの分流：ストリーミング、ゲームプラットフォーム、大容量ファイルのダウンロードに専用のプロキシグループを設定し、用途に応じてノードを選びます。
LAN機器へのアクセス：192.168.0.0/16や10.0.0.0/8などのプライベートアドレスを直接接続にして、ルーターやNASへのアクセスがプロキシへ送られるのを防ぎます。
長時間のTUN取り込み：システム通信の種類が多い場合、ルールによってTCP、UDP、ドメイン、IPリクエストの出口を細かく制御します。

サブスクリプション設定を使う場合、ルールモードの結果は、提供されたルールセットとプロキシグループに左右されます。似た名前の2つの設定でも、GEOIP、GEOSITE、rule-providers、または大量のDOMAIN-SUFFIXを使っているなど、分流の結果が異なることがあります。特定のサイトだけ出口を誤る場合は、まず接続詳細で一致したルールとポリシーを確認し、ruleモード自体が無効だと決めつけないでください。

ルールの一致がおかしいときの確認順

「接続」ページで対象ドメインを検索し、実際に一致したルール名とアウトバウンドポリシーを確認します。
プロキシグループの現在の選択を確認します。ルールがProxyを指定していても、Proxy内部でDIRECTが選ばれていないか確認してください。
ドメインが先にIPへ解決されていないか確認します。fake-ipとredir-hostでは、コアから見える宛先情報が異なる場合があります。
ルールの順番を確認します。特にMATCH、FINAL、広範囲のDOMAIN-KEYWORD、大きな範囲を指定したIP-CIDRに注意してください。
リモートルールセットを更新したら設定を再読み込みし、ログにrule-providerのダウンロードまたは解析エラーがないことを確認します。

グローバルモード：全通信の検証と一時的なルール回避

グローバルモードはテストに向いていますが、常用とは限りません。globalへ切り替えると通常の分流ルールは出口を決めず、接続は一律でGLOBALポリシーの入口へ入ります。GLOBALでは利用可能なノードを明示的に選ぶ必要があります。この入口でDIRECTが選択されていると、画面がグローバルモードでも、実際の接続は直接接続になる場合があります。

利用シーン	推奨モード	確認するポイント
ルールが原因でサイトを開けないか確認する	一時的にglobalへ切り替える	同じノードで直ちにアクセスが復旧するか
指定ノードの完全な出口経路を確認する	global	GLOBALで対象ノードが選択されているか
日常の国内外サイトへの混在アクセス	rule	ドメイン、GEOIP、フォールバックルール
プロキシノードが異常の原因か確認する	direct	直接接続で対象へアクセスできるか

たとえばルールモードで特定サイトがタイムアウトする場合、まず現在のノードを記録し、モードをglobalへ切り替えてGLOBALで同じノードを選びます。グローバルモードで復旧するなら、ノード自体は利用可能で、問題はルールの一致、プロキシグループの向き先、またはDNSの分流にある可能性が高いでしょう。それでも失敗する場合は、ノードの接続性、ハンドシェイクログ、UDP対応、対象サービスの制限を確認します。

グローバルモードでも、すべてのプログラムが必ずプロキシされるわけではない

globalの制御対象はClashに入った通信だけです。ブラウザーがシステムプロキシを使う場合はコアへ入りますが、一部のゲーム、仮想マシン、コンテナ、独自のネットワークスタックを使うプログラムはシステムプロキシを回避することがあります。こうしたプログラムも対象にするには、TUNが起動しているか、OSが管理者権限を付与しているか、クライアントのプロセス除外リストを確認してください。Androidでは、VpnServiceの許可が有効なままであることと、対象アプリが「アプリごとのプロキシ」から除外されていないことも確認します。

ダイレクトモード：プロキシの影響を切り分けるための設定であり、終了ボタンではない

directモードでは、Clashに入った新しい接続がローカルネットワークから対象へ直接アクセスするよう試みます。同じ端末、同じDNS環境でdirectへ切り替えた後に復旧するかを確認する、比較テストに最適です。復旧した場合は、プロキシノード、プロキシグループ、またはリモート経路に問題がある可能性があります。変わらない場合は、ローカルネットワーク、対象サービス、DNS、アプリ自体を引き続き確認します。

directにしても、ローカルネットワークから本来到達できない宛先へアクセスできるようにはなりません。通信事業者のネットワークから直接接続できないアドレスは、directでもタイムアウトします。また、directはDNS処理を停止する設定でもありません。DNSリクエストをClashのnameserverモジュールが取り込んでいる場合、プロキシモードがdirectでも、名前解決は設定済みのローカルDNSまたは暗号化DNSサーバーを経由することがあります。

直連に切り替えるとよい3つのタイミング

ローカルサービスが突然使えなくなった：プロキシ経路が社内ネットワーク、学校ネットワーク、NAS、ルーター管理画面に影響しているかを確認します。
ダウンロード速度を比較する：同じ中国本土のミラーサイトをruleとdirectでそれぞれテストし、リモート経由の遠回りで帯域が低下していないか確認します。
ノード障害を切り分ける：複数のノードで同じエラーが出る場合、directで対象サイトまたはローカルDNSが原因ではないか確認します。

directをクライアント終了の代わりに使わないでください。システムプロキシが127.0.0.1:7890を指したままの場合があり、TUN仮想インターフェースも動作し続け、接続履歴やDNSキャッシュもコアが管理します。元のネットワーク経路へ戻すには、「設定」→「システムプロキシ」を無効にし、「設定」→「TUNモード」を無効にしてから、OSのプロキシ設定が復元されていることを確認してください。

モードを切り替えても、古い接続がすぐ変わらないのはなぜか

モードの切り替えが主に影響するのは、新しく作られる接続です。確立済みのTCPセッションは通常、アプリが接続を閉じる、サーバーが切断する、またはコアが明示的に終了するまで、以前の出口を使い続けます。HTTP/2、WebSocket、QUIC、長時間接続を使うアプリでは特に顕著です。ページを再読み込みしても既存接続が再利用され、モードが変わっていないように見えることがあります。

切り替え後は3～10秒待ってから、もう一度リクエストを送ることをおすすめします。それでも変化がない場合は、クライアントの「接続」ページで該当接続を閉じるか、対象アプリを完全に終了して再起動してください。ブラウザーでテストする場合、新しいプライベートウィンドウを開くだけでは不十分なことがあります。ブラウザーのプロセスが接続プールを共有する場合があるため、ブラウザーを完全に終了してから再起動したほうが確実です。

DNSキャッシュも比較結果に影響する

アプリ、OS、ClashコアはいずれもDNSの結果を保存する場合があります。Windowsではターミナルでipconfig /flushdnsを実行してシステムDNSキャッシュを削除できます。macOSはバージョンによって更新方法が異なるため、まず対象アプリとClashコアを再起動するほうが確実です。fake-ipを使用している場合、198.18.0.0/16のアドレスはコアによるマッピング結果であり、サイトの実サーバーがそのネットワークにあることを示すものではありません。

同じサイトをテストするときは、モード、プロキシグループのノード、一致したルール、対象ドメイン、接続プロトコル、所要時間を同時に記録します。たとえばruleでDIRECTに一致して42 ms、globalで対象ノード経由となり186 msだった、という比較なら意味があります。ウェブページを体感だけで判断すると、キャッシュ、接続の再利用、CDNノードの変化に左右されやすくなります。

クライアントでの切り替え方法と、設定ファイルの保存について

グラフィカルクライアントによって入口の名称は少し異なります。一般的には、サイドバーの「プロキシ」または「Proxies」ページ上部にある「ルール / グローバル / ダイレクト」から切り替えます。「設定」→「実行モード」に配置されている場合もあります。切り替え後は接続ページに戻って新しいリクエストを送り、modeと実際のアウトバウンドが一致しているか確認してください。トレイメニューに対応しているクライアントなら、トレイの「プロキシモード」サブメニューからすばやく変更できます。

mihomoまたはClash互換設定では、modeフィールドで設定読み込み時のデフォルトモードを指定できます：

mode: rule

通常、選択できる値はrule、global、directです。クライアントによっては実行時の選択を独自の設定データベースに保存し、次回起動時に設定ファイルのmodeを上書きします。そのためYAMLを手動編集した後は、クライアントの再読み込み時に変更が保持されるか確認してください。サブスクリプションの更新で現在の設定が置き換わることもあるため、長期的なカスタマイズをサブスクリプション生成ファイルだけに直接書き込むのは避けましょう。

コントロールインターフェースでmihomoのモードを切り替える

external-controllerを有効にした環境では、REST APIから実行設定を変更できます。次の例では、コントロールアドレスがローカルの127.0.0.1:9090だけで待ち受け、secretが設定されていないものとします：

curl -X PATCH http://127.0.0.1:9090/configs \
  -H "Content-Type: application/json" \
  -d '{"mode":"rule"}'

ruleをglobalまたはdirectに変更すれば切り替えられます。secretを設定している場合は、Authorization: Bearer シークレットの内容というリクエストヘッダーを使用してください。コントロールインターフェースをインターネットへ直接公開してはいけません。LANから管理する場合も、待ち受けアドレス、ファイアウォールの接続元、認証用シークレットを同時に制限してください。

再現性のあるモード切り分け手順

モード切り替えの最も有効な使い方は、無作為に何度もクリックすることではなく、条件をそろえた比較テストを行うことです。同じネットワーク、同じ対象、同じノードを維持し、次の順番で確認すると、原因をすばやく絞り込めます。

システムプロキシまたはTUNが有効で、接続一覧に対象リクエストが表示されることを確認します。
ruleで新しい接続を開始し、一致したルール、プロキシグループ、具体的なノードを記録します。
globalへ切り替え、GLOBALで先ほどと同じノードを選び、古い接続を閉じて再試行します。
directへ切り替え、もう一度古い接続を閉じて、ローカルネットワークからの直接接続結果をテストします。
3回分のログで、DNS結果、接続プロトコル、ハンドシェイクエラー、所要時間を比較します。
テスト終了後はruleへ戻し、プロキシグループの選択とTUNの状態が普段の設定に戻っていることを確認します。

Ruleの結果	Globalの結果	Directの結果	優先して確認する項目
失敗	成功	失敗	ルールの一致とプロキシグループの向き先
失敗	失敗	成功	プロキシノード、プロトコル、リモート経路
成功	成功	失敗	通常のプロキシ到達性に該当
すべて失敗	すべて失敗	すべて失敗	通信の取り込み、DNS、ローカルネットワーク、または対象サービス

最終的な選び方はシンプルです。日常利用はrule、特定ノードの検証や複雑なルールの一時的な回避にはglobal、ローカルネットワークとプロキシ経路のどちらが接続に影響しているかを確認するにはdirectを使います。切り替え後は必ずGLOBALで選ばれている具体的なノードを確認し、古い接続を閉じてください。システムプロキシとTUNは独立したスイッチとして扱えば、3つのモードを混同せずに判断できます。