1. 接続前の確認：設定が有効で、コアが動作しているか

サブスクリプションを追加すると、ノードとルールがクライアントに登録されます。ただし、それだけでブラウザーがプロキシを使い始めるわけではありません。接続には、設定の有効化、ポリシーの選択、アプリの通信をコアに通す設定、リクエストが想定したノードから送信されていることの確認が必要です。どれか一つでも欠けると、「ノードの遅延は表示されるのに、Webページが開かない」といった問題が起きます。

この記事では、Clash Verge Revデスクトップ版で一般的な画面を例に説明します。ボタン名や設定項目の分類はバージョンによって多少異なるため、実際にインストールしたバージョンの画面を確認してください。Clash Verge Revは設定と画面を管理し、mihomoはプロキシ接続、DNS処理、ルール判定を実行するコアです。

  1. サイドバーの「プロファイル」を開き、追加したサブスクリプションが表示され、現在の設定として選択されていることを確認します。リストにカードが表示されているだけでは、有効になっているとは限りません。
  2. 「プロキシ」を開き、ポリシーグループとその中のノードが表示されていることを確認します。何も表示されない場合は設定を見直してください。グループ名はサブスクリプションによって異なり、「ノード選択」「プロキシ」などが使われます。
  3. 「ログ」を開き、直近の設定読み込みが成功しているか確認します。YAMLの解析エラー、ポートのリッスン失敗、コアの異常終了が繰り返される場合は、先にその問題を解決してください。
  4. 現在のプロキシのリッスンアドレスとポートを控えておきます。以下のコマンドでは 127.0.0.1:7897 を例にします。実際のポートはクライアント設定の混合ポートに合わせてください。例をそのまま使わないよう注意してください。

2. ポリシーグループ内でノードを選ぶ

「プロキシ」を開き、まず現在の動作モードを確認します。初回はRule（ルール）モードがおすすめです。設定済みのルールに応じて、リクエストはDIRECT、プロキシポリシーグループ、またはREJECTに振り分けられます。Global（グローバル）モードでは、コアに届いたリクエストがグローバルポリシーに渡されますが、すべてのアプリの通信が自動で取り込まれるわけではありません。Direct（直結）モードも、プロキシ出口の確認には適しません。

ルールで実際に参照されているポリシーグループを探す

ポリシーグループは、ルールとノードの間にある選択レイヤーです。たとえば、あるドメインへの通信が「ノード選択」グループに割り当てられていて、そのグループでDIRECTが選ばれている場合、別のグループで海外ノードを選択済みでも、その通信は直接接続されることがあります。対象サイトの通信を受け持つグループを展開し、その中から具体的なノードを選んでください。

  • select：手動選択です。初回の確認に適しています。ノードを一つ選んで固定できるため、テスト結果を比較しやすくなります。
  • url-test：ヘルスチェックの結果に応じてノードを自動選択します。テスト結果によって選択中のノードが変わることがあるため、前回表示されたノードが常に選ばれるとは限りません。
  • fallback：通常は設定順に利用可能なノードを選択します。遅延が最も小さいノードが優先されるとは限りません。

グループ内に別のポリシーグループが含まれている場合は、最終的に使われるノードが分かるまで展開してください。ノード名に含まれる国名、倍率、用途は提供元が付けた説明であり、実際の出口位置を保証するものではありません。初回のテストでは、場所や状態に問題のない一般的なノードを選び、遅延を比較しましょう。

3. 遅延を測定する：まず接続可否、次に安定性を確認

ポリシーグループまたはノードの横にある遅延テストボタンをクリックします。通常、クライアントはテスト対象のノード経由でテストURLにアクセスし、応答時間を表示します。測定範囲はコアやテストの実装によって異なります。単純なICMP pingではなく、ダウンロード速度を示すものでもありません。また、すべてのサイトにアクセスできることを保証するものではありません。

条件をそろえて3回連続でテストする

  1. ローカル回線を使い切らないよう、大容量ファイルのダウンロードや速度測定をいったん止めます。
  2. 同じグループを3回テストし、各回の間隔を5～10秒ほど空けます。候補ノードが繰り返しタイムアウトしないか確認してください。
  3. まず複数回のテストを完了できるノードを選び、そのうえで遅延を比較します。1回だけの最小値で決めないようにしましょう。

たとえば、ノードAが3回とも86、92、89ミリ秒だった一方、ノードBが45ミリ秒、タイムアウト、410ミリ秒だった場合、初回接続ではAを選ぶのが適切です。数値は結果の見方を示す例であり、この記事での実測値ではありません。短時間の利用可否を見るうえでは、1回の低遅延より安定性が重要です。

timeoutが出たら、まず何のテストに失敗したかを切り分ける

timeoutは、今回のテストが制限時間内に完了しなかったことを示します。サブスクリプションが無効になったとは限りません。テスト先の名前解決失敗、ノードへの接続不可、テストサイト側のアクセス拒否などでも同様の結果になります。すべてのノードが同時にタイムアウトする場合は、何十ものノードを次々に切り替えるのではなく、まずローカルネットワーク、サブスクリプションの有効期限、ログを確認してください。

設定でテスト先に https://www.gstatic.com/generate_204 を使っている場合、想定される応答はHTTP 204です。リクエストは成功していますが、レスポンス本文はありません。このURLに接続できるかどうかは判断材料の一つにすぎません。遅延に問題がなくても、次の手順で実際の対象サイトを確認してください。

4. システムプロキシを有効にしてブラウザーの通信をコアに通す

ノードを選んだら「設定」を開き、「システムプロキシ」を有効にします。設定画面がカテゴリ別に分かれている場合、システムプロキシは通常ネットワーク関連の項目にあります。「LAN内接続を許可」はシステムプロキシのスイッチではありません。他のデバイスからこのPCのプロキシポートに接続するための設定で、初回のローカル接続には必要ありません。

システムプロキシを有効にすると、OSのプロキシ設定がローカルのリッスンポートを指すようになります。Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」、macOSでは「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」で確認できます。アドレスとポートがクライアントの実際のリッスン設定と一致しているか確認してください。

  • ChromeやEdgeなどのブラウザーは通常、システムプロキシを使います。ただし、ブラウザー拡張機能、起動オプション、企業ポリシーによって動作が上書きされることがあります。
  • Firefoxではプロキシを個別に設定できます。システム設定に従わない場合は、「設定」→「一般」→「ネットワーク設定」を開き、「システムのプロキシ設定を利用する」を選択してください。
  • コマンドラインツールや一部のゲームは、システムプロキシを参照しないことがあります。ブラウザーで接続できても、すべてのプログラムの通信が取り込まれているとは限りません。

5. 接続画面でルールとノードを確認する

クライアントの「接続」画面を開いたまま、ブラウザーから新しいリクエストを送信します。読み込み済みの静的ページを眺めるだけでは確認できません。元のタブを閉じて再アクセスするか、新しいシークレットウィンドウを使うと、キャッシュや既存接続の影響を減らせます。シークレットウィンドウにしてもプロキシ設定は変わりません。

接続一覧で対象ドメインを絞り込み、接続の詳細を開きます。画面上の項目名は「ルール」「マッチしたルール」「チェーン」「プロキシチェーン」など、バージョンによって異なることがあります。次の3項目を確認してください。

確認項目 確認する内容 確認できること
接続先 ドメインまたは接続先IPが、直前に送信したリクエストと一致する バックグラウンドの更新リクエストを今回のテストと取り違えないため
マッチしたルール 例：DOMAIN-SUFFIX、GEOSITE、MATCH 現在の設定でこのポリシーが選ばれた理由
プロキシ経路 ポリシーグループと最終ノード、またはDIRECT、REJECT 今回のリクエストがプロキシ経由、直接接続、拒否のどれかを判定する

中国本土のサイトがDIRECTにマッチしても、必ずしも問題ではありません。一部の通信を直接接続するのは、ルールによる振り分けとして正常な場合があります。ただし、プロキシ経由で確認するはずのサイトがDIRECTになっている場合は、システムプロキシを再度オンにするだけでなく、マッチしたルールとポリシーグループの選択を確認してください。

接続画面に新しい記録がまったく表示されない場合は、ブラウザーが本当にローカルプロキシを使っているか、一覧にフィルターが設定されているかを確認します。短時間で終了する接続はすぐ消えることがあるため、接続画面を先に開いてから対象ページを再読み込みし、ログもあわせて確認してください。一覧が一時的に空だからといって、ノードが使えないと判断しないようにしましょう。

6. 出口IPを比較して、プロキシ経由を結果で確認する

接続経路にノードが表示されたら、IP確認サービスにアクセスしてパブリック出口アドレスを記録します。まずシステムプロキシをオフにし、TUNも無効になっていることを確認して、もう一度検索した結果を直接接続時の基準にします。その後システムプロキシを戻し、新しいページで再度確認します。比較には同じ確認サービスを使い、データベースによる地域表示の違いを避けてください。

IP確認サイトへの通信もルールの対象です。サイトへのリクエストがDIRECTに振り分けられた場合、ローカルの出口が表示されても想定どおりであり、他のサイトがプロキシを通っていない証拠にはなりません。IP確認リクエストの接続記録も確認してください。IPの登録地域は参考情報です。アドレスが変わったか、接続経路が対象ノードを示しているかのほうが重要です。

明示的なプロキシ指定でブラウザー設定の問題を切り分ける

ブラウザーの結果が分かりにくい場合は、次の2つのコマンドでIPv4の出口を比較できます。WindowsのPowerShellでは実行ファイルを呼び出すため curl.exe を使い、macOSとLinuxでは curl を使います。例のポート 7897 は、クライアントの実際の混合ポートに置き換えてください。

# Windows：curlのプロキシ設定を使わずに直接接続の基準を確認
curl.exe -4 --noproxy "*" --max-time 15 https://api.ipify.org

# Windows：ローカルHTTPプロキシを明示して接続
curl.exe -4 --proxy http://127.0.0.1:7897 --noproxy "" --max-time 15 https://api.ipify.org
# macOS / Linux
curl -4 --noproxy "*" --max-time 15 https://api.ipify.org
curl -4 --proxy http://127.0.0.1:7897 --noproxy "" --max-time 15 https://api.ipify.org

--max-time 15は1回のリクエストの合計時間を15秒に設定します。-4を付けると、2回の比較でIPv4を使うため、IPv4とIPv6のアドレス差をプロキシの効果と誤認するのを防げます。プロキシ指定コマンドの空の--noproxyは、環境変数などに設定されたプロキシ除外リストを無効にします。ただし、明示的にプロキシを指定しても、コアのルーティングモードとルールは適用されます。すべての接続先が選択中のノードを経由するわけではありません。

直接接続時の基準を確認するには、TUNと他のVPNもオフにする必要があります。--noproxyで回避できるのはcurlのプロキシ設定だけで、システムレベルの通信取り込みは回避できません。コマンドで127.0.0.1に接続できない場合は、リッスンポートとコアの動作状態を先に確認してください。明示的なプロキシ指定では成功し、ブラウザーでは失敗する場合は、ブラウザーの設定や拡張機能を重点的に確認しましょう。

7. 初回接続の確認と、その後のTUNテスト

信頼できる接続確認には、相互に対応する3つの証拠が必要です。ノードテストが完了すること、対象リクエストの接続経路が想定したノードを示すこと、出口IPの結果がその経路と一致することです。「Webページが開く」「遅延表示が緑色になる」だけでは、十分な確認とはいえません。

  • 遅延は正常なのにWebページが開かない：システムプロキシ、実際のリッスンポート、接続画面で対象ドメインにマッチしたルールを確認します。
  • Webページは開くのに出口が変わらない：まずIP確認リクエストがDIRECTに振り分けられていないかを確認し、次にブラウザーがプロキシを回避していないか確認します。
  • 出口は変わったのに特定のサイトに接続できない：そのサイトへの接続記録とログを確認し、ノードの出口制限、DNSの結果、サイト側のアクセス制御を検討してください。
  • ブラウザーでは成功するのに他のアプリでは失敗する：そのアプリがシステムプロキシに対応しているか確認します。必要に応じてTUNによる通信の取り込みを検討してください。

TUNモードは仮想ネットワークインターフェースを使って、より多くのIP通信を取り込みます。システムプロキシを参照しないアプリに適していますが、システムプロキシとは別の機能です。有効にする際はサービスモードや管理者権限が必要な場合があり、他のVPNのルートと競合することもあります。成功した設定とノードはそのままにして、通信の取り込み方法だけを切り替え、対象アプリの接続経路を改めて確認してください。

最後に、現在の設定名、ポリシーグループの選択、混合ポートを記録しておくと、次回との比較に役立ちます。サポートを求める場合は、クライアントとOSのバージョン、個人情報を除いたエラーログ、接続結果を共有してください。サブスクリプションURL、ノードのパスワード、アクセストークンは公開しないでください。ここまで確認できれば、「リクエストがコアに入り、想定どおりプロキシノードから送信された」と判断できます。