プロキシモードと通信の取り込みを区別する
Clashの3つのプロキシモードが決めるのは、コアに届いた接続の出口です。ルールモードはルールに従って振り分け、グローバルモードは全体に適用するポリシーを使い、DIRECTモードは宛先へ直接接続します。端末の通信を取り込む方法が3種類あるわけでも、速度を3段階で切り替える機能でもありません。
システムプロキシ、アプリ内プロキシ、TUNは、接続をコアに送る役割を担います。たとえばブラウザーでHTTPプロキシとして 127.0.0.1:7890 を指定すると、該当するリクエストはこの待ち受けポートに届きます。システムプロキシを使わないアプリは、そのまま独自にインターネットへ接続することがあります。グローバルモードにしても、この状態が自動で変わるわけではありません。
3つのモードで通信経路を比較
| モードと設定値 | 出口の選び方 | 適した用途 |
|---|---|---|
ルールモード rule |
rulesを上から順に照合し、最初に一致したルールの宛先を使用 |
普段のブラウジング、通信の振り分け、ドメインごとのポリシー選択 |
グローバルモード global |
組み込みのGLOBALプロキシグループで選択した出口を使用 |
ルールの影響を一時的に除外してノードの接続性を比較 |
DIRECTモード direct |
プロキシノードを経由せず、コアから宛先へ直接接続 | ローカルネットワークとの比較、プロキシ出口の切り分け、LANへの接続確認 |
ここでいう「DIRECT」はコアの処理中に直接接続するという意味で、クライアントを終了するわけではありません。DNS、待ち受けポート、有効になっている通信の取り込み機能は引き続き接続に関わる場合があります。また、どのモードもノード情報を補完したり、サブスクリプションを修復したり、サーバー側の設定を変更したりする機能ではありません。
ルールモード：順番に照合してからプロキシグループへ
ルールモードは常用に適しています。コアはrulesを上から確認し、最初に一致したルールで指定された宛先を使います。宛先にはDIRECT、REJECT、個別のプロキシノード、設定済みのプロキシグループを指定できます。
ルールの宛先とプロキシグループの選択は別の段階
たとえば、あるドメインのルールが「ノード選択」を指定している場合、コアはまず接続の宛先を「ノード選択」と判断し、その後、グループの種類と現在の状態に応じて実際の出口を決めます。手動選択グループは現在選ばれている項目を使い、自動テストグループは設定に従って選択します。ルールがグループに一致しても、必ずリモートノードへ転送されるとは限りません。グループ内でDIRECTが選択されていれば、最終的には直接接続します。
以下はルールの順序を理解するための設定例であり、サブスクリプション全体ではありません。「ノード選択」は既存のproxy-groupsにある名前と完全に一致させてください。また、ほかのルールをこのルールより前に置く必要がないか確認してください。
mode: rule
rules:
- DOMAIN-SUFFIX,home.arpa,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- MATCH,ノード選択DOMAIN-SUFFIXはドメインのサフィックスで照合します。コアが該当するドメイン情報を取得できる必要があり、IPアドレスだけの接続がすべてドメインルールに一致するとは限りません。IP-CIDRは宛先IPの範囲で照合します。ここに示す3つの範囲は、一般的なプライベートIPv4アドレスをカバーします。no-resolveは、このIPルールのために追加のドメイン名前解決を行わない指定です。宛先IPがすでに分かっている接続は引き続き照合できます。MATCHは最後の受け皿となるルールです。優先して適用するルールの後に置いてください。先頭に置くと、後続の通常ルールが照合されなくなります。
Webサイトの出口が想定と異なるときの確認項目
接続の詳細を開き、宛先のドメインまたはIP、マッチしたルール、プロキシグループの経路、最終的なノードを順に確認します。接続がMATCHに一致している場合、それより前のルールでは処理されていません。正しいプロキシグループに一致しているのにノードが違う場合は、同種のルールを追加するのではなく、グループ内の選択を見直してください。さらに設定する場合は、上級マニュアルのプロキシグループ解説を参照してください。
グローバルモード：GLOBALで一時的にルール振り分けを回避
グローバルモードでは、コアに届いた接続をGLOBALプロキシグループに渡し、通常のrules一覧による出口の振り分けを行いません。クライアントの画面には通常、グローバル用ポリシーの選択項目があります。名称や場所はクライアントのバージョンによって異なります。
globalに切り替えたら、GLOBALで現在何が選択されているかも確認してください。個別のノードやプロキシグループのほか、DIRECTが選ばれている場合もあります。「グローバルモード」と表示されているだけでは、実際の出口は分かりません。普段ルールモードで使う「ノード選択」が、グローバルモードでも選択されているとは限りません。
グローバルモードでルールの問題とノードの問題を切り分ける
- ルールモードで開けない同じURLを記録し、接続の詳細からマッチしたルールを確認します。
- グローバルモードに切り替え、
GLOBALでテストするノードを明示的に選択します。 - そのURLに対応する既存の接続を閉じてから、リクエストをやり直し、新しい接続記録を確認します。
- グローバルでは使えてルールモードでは使えない場合は、ルールの照合結果とプロキシグループの選択を優先して確認します。どちらでも使えない場合は、ノード、DNS、通信の取り込み経路を確認してください。
- テスト後はルールモードに戻し、普段使うプロキシグループが選択されていることを確認します。
DIRECTモード：ローカルネットワークを切り分ける。Clashの終了とは別
DIRECTモードでは、プロキシノードを中継せず、コアから宛先へ直接接続します。「同じリクエストがリモートプロキシを経由しなくても成功するか」という具体的な確認に使えます。たとえばルーターの管理画面を開けない場合、DIRECTモードに切り替えて接続を作り直し、開けるようになるか確認できます。
ただし、DIRECTモードは「通常のネットワーク接続」を完全に再現するものではありません。TUNが有効なら、該当する接続が仮想ネットワークアダプターを通る場合があります。mihomo DNSやFake-IPが有効なら、名前解決やアドレス変換も引き続きコアが処理する場合があります。アプリが完全にコアを迂回する状態をテストするには、関連する通信の取り込み経路を無効にする必要があります。
原因を混同しないよう、2段階で比較する
- 1段階目：システムプロキシまたはTUNの設定は変えず、DIRECTモードに切り替えます。主にプロキシノードや出口の選択が原因かどうかを比較します。
- 2段階目：クライアントの設定からシステムプロキシとTUNを無効にし、ブラウザーに別のプロキシ設定がないか確認します。主にコアによる通信の取り込み、DNS、アプリ内プロキシが関係しているかを比較します。
1段階目で失敗し、2段階目では正常だったとしても、「ローカルネットワークに問題がある」とは言い切れません。DNS設定、仮想ネットワークアダプターのルート、プロキシの待ち受けポート、ファイアウォールを引き続き確認してください。反対に、DIRECTでは失敗してプロキシ経由では成功する場合も、ローカルネットワークから宛先サービスまでの経路が異なる可能性があり、ルールモードに問題があるとは限りません。
モードの切り替え場所と設定フィールド
デスクトップクライアントでは、メイン画面の「プロキシモード」やタスクトレイメニューの「ルール／グローバル／DIRECT」から切り替えるのが一般的です。スマートフォン版では、ホーム画面のモード選択やサイドメニューにある場合があります。クライアントごとに画面構成は異なるため、特定のクライアントのメニュー手順をすべてのClashクライアント共通のものとして扱わないでください。
確認時は、実際に選択されているモードとコアの稼働状態を基準にします。YAMLを直接編集する場合、モードの設定項目はトップレベルに置き、dns、tun、proxy-groupsの中には入れません。
# トップレベルの項目。指定できる値は rule、global、direct
mode: ruleファイルを変更した後は、通常、設定を再読み込みする必要があります。クライアントによっては、画面上の設定、オーバーライド設定、実行時の状態が最終的な設定に統合されます。そのため、「ファイルにはruleと書かれている」状態と「コアがruleを使用中」の状態が一致しないことがあります。サブスクリプション更新後は、ローカルの変更が残っているかも確認してください。
ポートとモードは別々の設定
mixed-port: 7890は、7890番ポートでHTTPとSOCKSをまとめて受け付ける設定です。modeとは別の項目です。ブラウザーが古い7890番ポートに接続している一方、実際の待ち受けが7891番に変更されている場合、モードを切り替えてもポートの不一致は解決しません。アプリまたはシステムプロキシのアドレスとポートも合わせて変更してください。
利用シーンに合わせて選び、モードの切り替えを繰り返さない
普段のブラウジング：ルールモード
日本国内のサービス、LAN上の端末、プロキシが必要なサイトを併用する場合は、ルールモードが適しています。まずルールの順序とプロキシグループの対応関係を整理し、接続記録を確認しながら必要なルールを追加してください。1つのサイトのために、コアに届くすべての通信を常時同じリモート出口へ送る必要はありません。
ノードの一時テスト：グローバルモード
ルールの影響を除外したい場合は、グローバルモードにしてテスト対象のノードを選択します。対象URL、通信の取り込み方法、DNSの条件はできるだけ固定し、変更する要素を1つに絞ってください。ノードの遅延テストに成功しても、その時点でテスト対象に接続できたことを示すだけで、ブラウザーでアクセスする別のドメインも必ず使えるとは限りません。
ルーター、NAS、ローカルサービスの確認：DIRECTで比較してからルールモードに戻す
192.168.1.1やローカルの開発サービスにアクセスするときは、短時間の比較にDIRECTモードを使えます。グローバルプロキシの出口が原因だと分かった場合、通常はルールモードに戻し、実際に使うLANのアドレス範囲にDIRECTルールを設定するのが長期的な対処です。TUNのルート除外は別レイヤーの設定なので、ルール内のDIRECTと混同しないでください。
プライベートアドレスをすべてアクセス可能なリソースと見なすのは避けてください。社内VPN、リモートワーク用ネットワーク、ローカルネットワークで同じアドレス範囲が使われている場合があります。その場合は汎用の設定例をそのまま使うのではなく、ルーティングテーブルと社内ネットワークの要件を踏まえて出口を決めてください。
切り替えても変化がない：既存の接続、DNS、通信の取り込み範囲を確認
- まず接続記録を確認します。該当する新しい接続がない場合は、アプリがシステムプロキシを使っているか、通信がTUNに取り込まれているかを確認してください。システムプロキシでは、すべてのアプリやUDP通信を処理できるとは限りません。
- 次に実際の出口を確認します。現在のモード、マッチしたルール、プロキシグループの経路を確認してください。グローバルモードでは
GLOBALを、ルールモードでは一致した宛先グループを確認します。 - 接続を作り直してテストします。実行中のダウンロード、長時間接続、ブラウザーの接続プールは、モードを切り替えても新しい設定に移行しない場合があります。クライアントで該当する接続を閉じてから再アクセスしてください。必要に応じてブラウザーを完全に終了し、再起動します。
- DNSを個別に確認します。ドメインの名前解決に失敗しても、ルールが誤っているとは限りません。DNSクエリが正常か、解決結果が想定どおりかを確認してください。モードを切り替えても、アプリのキャッシュが消去されたり、DNSの上流が変更されたりするとは限りません。
- 最後に実行中の設定を確認します。サブスクリプションが正常に読み込まれているか、オーバーライドが適用されているか、画面上のモード設定がYAMLの設定を上書きしていないかを確認してください。
モード選択の要点は、比較する条件を1つずつに絞ることです。普段はルールに通信の行き先を決めさせ、トラブル時はグローバルモードでプロキシ出口を固定し、DIRECTモードと比較します。切り替えのたびに新しい接続の経路を確認するほうが、複数の設定を何度も切り替えるより原因を特定しやすくなります。システムプロキシやTUNの初期設定については、使い方ガイドのプロキシモード解説をご覧ください。