まずルールモードを選び、通信がカーネルに届いているか確認する
普段使いでは、まずルールモード(Rule)を選びます。サブスクリプションが有効で、対象のプロキシグループでノードが選択されていることを確認してから、テストしたいサイトにアクセスしてください。特定のサイトだけに問題がある場合は、一時的にグローバルモードへ切り替えて比較できます。現在のネットワークから対象サイトへ直接アクセスできるか確認するには、DIRECTモードに切り替えます。設定は一度に一つだけ変更すると、結果を判断しやすくなります。
3つのモードで切り替わるのは、ClashまたはClash Meta(mihomo)カーネルに届いた接続の出力方法です。どのアプリの通信を取り込むかを決めるものではありません。システムプロキシ、アプリ内プロキシ、TUNが通信をカーネルへ送り、ルール・グローバル・DIRECTが受け取った通信を処理します。この2つの設定レイヤーは分けて考えましょう。
| モード | カーネルに届いた後の処理 | 用途 | まず確認すること |
|---|---|---|---|
| ルール Rule | ルールを上から順に照合し、該当する出力先またはプロキシグループへ振り分ける | 普段の通信振り分け、DIRECT接続とプロキシ接続の使い分け | 一致したルールと、プロキシグループで実際に選択されている項目 |
| グローバル Global | 通常は内蔵のGLOBALプロキシグループへ送る | ルール漏れの一時的な切り分け、出口を統一したテスト | GLOBALで最終的に選択されている出力先 |
| DIRECT | カーネルから接続先へ直接接続する | ローカルネットワークとの比較、プロキシノードの影響の切り分け | ローカルDNSとネットワーク到達性 |
3つの通信経路:入口は同じ、出力先の決め方が異なる
以下の図は、すでに取り込まれている同じアプリの接続を例にしています。「プロキシ選択」は説明用のプロキシグループ名で、すべてのサブスクリプションに共通する固定名ではありません。実際の設定では「ノード選択」「自動選択」など、別の名前が使われることもあります。
ルールモード:上から順に確認し、最初に一致したルールを適用
アプリの接続
↓ システムプロキシ / アプリ内プロキシ / TUN
Clashまたはmihomoカーネル
↓ rulesを上から順に確認
├─ DIRECTルールに一致 → DIRECT → 接続先サービス
├─ プロキシルールに一致 → プロキシ選択 → 現在のノード → 接続先サービス
├─ 拒否ルールに一致 → REJECT → 接続終了
└─ MATCHのフォールバックに到達 → 指定されたポリシー → 接続先サービス
ルールは「より具体的なものが自動的に優先される」わけではなく、通常は上から順に確認され、最初に一致したものが適用されます。対象範囲の広いルールを先頭に置くと、後続の詳細なドメインルールが適用されないことがあります。サブスクリプションのルールセットも、rulesリスト内で参照される位置を確認しましょう。
グローバルモード:通常のルール振り分けを回避
アプリの接続
↓ 通信を取り込み済み
Clashまたはmihomoカーネル
↓ Globalモード
GLOBALプロキシグループ
↓ 現在選択中のノード、または別の出力先
接続先サービス
グローバルモードに切り替えたら、プロキシ画面でGLOBALの選択先も確認してください。グローバルモードは「最速ノードを自動選択する」機能ではなく、必ずプロキシノードから接続するとも限りません。GLOBALでDIRECTが選択されている場合や、選択中の別のプロキシグループが最終的にDIRECTを指している場合、接続は直接出力されます。クライアントによっては、このグループがローカライズされた名前で表示されます。
DIRECTモード:カーネルを経由し、プロキシノードを使わず接続
アプリの接続
↓ 通信を取り込み済み
Clashまたはmihomoカーネル
↓ Directモード
DIRECT
↓ このデバイスで利用できるネットワーク出口
接続先サービス
DIRECTモードはクライアントの終了やTUNの無効化を意味しません。カーネルが引き続き接続やDNSリクエストを処理し、出力先だけが直接接続になる場合があります。そのため、DIRECTで接続できたとしても、現在の通信取り込み・名前解決環境で直接アクセスできたことを示すにすぎません。それだけで、システムプロキシやDNS、ルーティングがクライアント起動前の状態に戻ったとは判断できません。
ルールとプロキシグループの連携:最小構成の例
以下はマッチング順序を説明するためのYAML断片であり、完全なサブスクリプションの代わりにはなりません。「プロキシ選択」は、あらかじめproxy-groupsで定義しておく必要があります。example.comとそのサブドメインは記述例であり、特定のサービスにプロキシが必須という意味ではありません。
mode: rule
mixed-port: 7890
rules:
- DOMAIN-SUFFIX,example.com,プロキシ選択
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- MATCH,プロキシ選択
mode: ruleは、既定でルールに従って通信を処理する設定です。クライアント画面での実行中の切り替えによって、この値が上書きされる場合があります。設定の再読み込み後にどう動作するかは、クライアントがモードの上書きを保存するかどうかによります。mixed-port: 7890は、同じポートでHTTPとSOCKS5のプロキシ接続を受け付けます。7890は例であり、すべてのクライアントで固定されているポートではありません。DOMAIN-SUFFIXは、指定したドメインとそのサブドメインに一致します。一致すると「プロキシ選択」に渡され、実際に使用するノードはそのプロキシグループで決まります。IP-CIDRは、接続先のIPアドレスが指定したネットワーク範囲に含まれるかを判定します。ここでは一般的なプライベートネットワークを2つ例示していますが、LAN通信をDIRECTにするルールの完全な一覧ではありません。no-resolveは、このIPルールとの照合だけを目的にドメインを積極的に名前解決するのを避けます。接続全体でDNSが不要になるという意味ではありません。MATCHは最後のフォールバックとして使います。前の方に置くと、後続のルールが照合されなくなります。
グローバルモードまたはDIRECTモードに切り替えると、通常は標準のrulesリストを1つずつ照合して出力先を決める動作ではなくなります。そのため、「ルールにLAN向けのDIRECT設定がある」からといって、「グローバルモードでも同じルールでDIRECTになる」とは限りません。ローカルプリンター、ルーターの管理画面、社内ネットワークのサービスを使う場合は、普段からルールモードにしておくと、通信を明確に制御できます。
グローバルへ一時的に切り替える場合と、ルールに戻す場合
特定のサイトだけ開けない:グローバルモードで比較する
- クライアントの「プロキシモード」欄で、現在「ルール」が選択されていることを確認します。クライアントによっては、トレイメニューの「プロキシモード」から切り替えます。項目名は実際の画面に従ってください。
- 「接続」ページを開き、対象サイトに一度アクセスして、接続先ドメイン、マッチしたルール、最終的なポリシーチェーンを記録します。
- モードを「グローバル」に切り替え、GLOBALで利用可能と確認済みのノードを選びます。変更する条件を増やさないよう、できるだけルールモードで使っていたノードと同じものを選んでください。
- 対象サイトの既存の接続を閉じてから、もう一度アクセスします。必要に応じて、そのドメインに対応する接続だけを切断してください。すぐにすべてのアプリの接続を切る必要はありません。
- グローバルでは正常でルールでは問題が起きる場合は、ルールモードに戻し、ドメインが誤ってDIRECTに一致していないか、ルールセットが不足していないか、フォールバック先が別のプロキシグループになっていないかを確認します。
この比較だけで原因を断定することはできません。同じノードを使っていても、モードごとのDNS動作など設定の影響を受ける場合があります。切り替え前後で名前解決の結果が異なる場合は、ルールだけが原因と決めつけず、DNSも含めて調べてください。
出口を統一してテストする:短時間ならグローバルモード
プロキシノードの出口位置を確認したり、特定のサービスにそのノード経由でアクセスできるかテストしたりする場合は、グローバルモードを使うとルールによる振り分けの影響を抑えやすくなります。ただし、その間は取り込み済みの他のアプリも同じ出口を使う場合があります。OSの更新やクラウドストレージの同期も対象になることがあります。通信量に応じて課金されるサブスクリプションでは、バックグラウンドのダウンロードにも注意してください。
普段のブラウジングとローカルサービスにはルールモード
テストが終わったらルールモードに戻し、普段使うプロキシグループが選択されていることを確認します。プロキシが必要なドメインにはプロキシを使い、ローカルから直接アクセスできるサービスにはDIRECTを使うことで、不要な経由を減らせます。グローバルモードはルールモードより「高機能」なのではなく、通常のルール選択を省略するモードです。短期間の比較テストに適しています。
システムプロキシ・TUN・DNS:モード切り替えだけでは解決しない問題
アプリの通信がカーネルに届いていなければ、グローバルモードでも取り込めない
デスクトップクライアントで「システムプロキシ」を有効にすると、システム設定を参照するアプリもあれば、独自のネットワーク設定を使うアプリもあります。コマンドラインプログラムでは、環境変数に依存することもあります。ローカルのmixed-portが7890であることを確認したうえで、次のコマンドでプロキシの入口を明示すると、システムプロキシ設定による不確実性を減らせます。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/
Windows PowerShellでシステム標準のcurlを明示的に実行する場合は、先頭をcurl.exeにしてください。実行時はクライアントの接続ログも確認します。リクエストが記録されていれば、そのプロキシ入口を通ったことが分かります。ただし、HTTPレスポンスが返っただけではリモートノードを経由した証拠にならないため、最終的なポリシーチェーンも確認してください。コマンド内の10秒は接続タイムアウト、20秒は全体の制限時間であり、遅延の測定値ではありません。
TUNは仮想ネットワークインターフェースとルーティングを使って、より多くのIP通信を取り込みます。ただし、対象範囲はルート、除外設定、権限、実装によって異なります。TUNを有効にしても、ノードがUDPに対応するとは限らず、ノード自体に接続できない問題も解決しません。システムプロキシに従わないアプリの通信を取り込みたい場合は、クライアントのガイドに沿ってTUNの権限とルーティング設定を確認してください。
モードを切り替えてもDNSの状態はリセットされない
Fake-IPを使っている場合、カーネルがドメイン名との対応付けに使う仮想アドレスをアプリに返し、その対応関係から実際のドメインを識別することがあります。これは、通信が実際にインターネット上の宛先へ送られたという意味ではありません。DNSの上流サーバー、Fake-IPのフィルター、アプリ独自の暗号化DNS、端末のキャッシュが、切り分け結果に影響する場合があります。
グローバルモードに切り替えても接続できないからといって、DNS、TUN、サブスクリプションを一度に変更しないでください。まず接続が記録されているかを確認し、次にドメイン名とポリシーチェーンを確認してから、名前解決やノード接続のエラーを調べます。複数のレイヤーを一度に変更すると、再現できていた問題が偶発的なものになり、原因を特定しにくくなります。
切り替えても変化がない場合:接続ログを順に確認
| 症状 | 優先して確認する項目 | 確認・対処方法 |
|---|---|---|
| グローバルに切り替えても出口が変わらない | 既存の接続が再利用されている、またはGLOBALでDIRECTが選択されている | GLOBALの選択先を確認し、対象の接続を切断してからリクエストを再実行する |
| ブラウザーは使えるが、ゲームは使えない | ゲームがシステムプロキシを使っていない、または必要なUDP通信に対応していない | まずゲームの通信がカーネルに届いているかを確認し、次にTUNとノードの対応状況を確認する |
| ルールモードでは失敗するが、グローバルでは正常 | マッチしたルールと最終的な出力先が一致していない | 同じノードで比較し、ルールの順序、ルールセット、フォールバック先を確認する |
| DIRECTでは接続できるが、グローバルでは失敗する | 選択中のノードが使えない、または接続先がその出口を拒否している | ハンドシェイクまたはタイムアウトのエラーを確認し、利用可能な別のノードで再テストする |
| 3つのモードすべてで失敗する | プロキシ入口のポート、DNS、ネットワーク、または接続先サービスに問題がある | まずローカルのプロキシ入口と接続ログを確認し、その後、レイヤーごとに調べる |
モードの切り替えは通常、その後に新しく確立する接続に影響します。既存のTCP長時間接続やQUICセッションがすぐに別経路へ切り替わるとは限りません。ページを再読み込みしても接続が再利用されることがあります。ログに古いポリシーが表示される場合は、対象の接続を閉じてからリクエストをやり直してください。進行中のダウンロード、会議、リモート接続が切れる可能性があるため、操作前に影響範囲を確認しましょう。
最後に次の3点を確認します。接続はカーネルに届いているか、最終的にどの出力先を通ったか、新しい接続が意図したモードを使っているか。この3点が分かれば、ルールの修正、通信の取り込み方法の調整、ノードの変更のどれが必要か判断できます。普段はルールモードを使い、トラブルの切り分けに限ってグローバルやDIRECTへ一時的に切り替えるほうが、クライアントを何度も再インストールするより原因を特定しやすくなります。