Clash Verge Revの画面ガイド｜プロキシ・プロファイル・ログの使い方

まず押さえたい、画面・設定・mihomoコアの違い

Clash Verge Revは、サブスクリプションの読み込みや設定管理、接続状況の表示を行うデスクトップクライアントです。実際にプロキシ接続やDNS、ルール判定を処理するのはmihomoです。画面にノードが表示されていても、アプリの通信がコアに届いているとは限りません。システムプロキシを有効にしても、すべての接続がリモートノードを経由するわけではありません。この2点を押さえると、各画面の役割を理解しやすくなります。

この記事では、Clash Verge Rev 2.xでよく見られる日本語画面を基準に説明します。細かな表示やボタンの位置は、バージョン、ウィンドウ幅、OSによって異なる場合があります。実際にインストールされているバージョンの表示を確認してください。以下では「プロキシ → プロファイル → 接続 → ルール → ログ → 設定」の順に各画面の役割を見ていきます。サイドバーの並び順は異なる場合があります。

画面	主な操作	確認できること
プロキシ	ポリシーの選択、遅延テスト、モード切り替え	現在のポリシーグループで、どのノードが使われている？
プロファイル	サブスクリプション設定の追加・更新・有効化	ノードやルールはどこから読み込まれている？
接続	通信リクエスト、ポリシー経路、転送量の確認	この通信は実際にどの経路を通った？
ルール	読み込まれているルールの確認	どの条件でこのポリシーが選ばれる？
ログ	コアの動作状況やエラーの確認	リクエストはどの段階で失敗した？
設定	システムプロキシ、TUN、待ち受けポートの管理	アプリの通信はどのようにコアへ届く？

プロキシ画面：ポリシーグループとノードを選び、遅延を確認

ノードとポリシーグループは別の階層

「プロキシ」を開くと、すべての通信で共通のノード一覧ではなく、複数のポリシーグループが表示されるのが一般的です。ポリシーグループはルールから参照される出口の選択肢で、ノードだけでなく別のポリシーグループを含むこともあります。サブスクリプションの作成者が「ノード選択」「自動選択」「ストリーミング」などの名前を付ける場合があります。これらは設定に由来する名称で、クライアント共通の固定項目ではありません。

使いたいポリシーグループを見つけ、候補を展開します。
グループの種類がselectなら、ノードまたはサブグループを選び、選択状態が変わったことを確認します。
グループ内の遅延テストを実行し、候補の結果が表示されるまで待ちます。テストを何度も連続して実行しないでください。
新しくWebページにアクセスし、「接続」画面でポリシー経路を確認します。ノードのカード表示だけで判断しないでください。

url-testは測定結果に応じて出口を自動選択し、fallbackは設定順に利用可能な出口を探します。load-balanceは設定された方式に従って接続を振り分けます。動作は設定内容によって異なるため、すべてのグループを特定ノードに固定された手動選択リストと考えないでください。

ルール・グローバル・ダイレクトの3つのモード

ルールモード（Rule）：現在のルールセットに基づいて出口を決定します。通常の利用で直結とプロキシを使い分ける場合は、まずこのモードを使います。
グローバルモード（Global）：コアに届いた接続は通常、GLOBALポリシーに渡されます。トラブルシューティングでは、このポリシーで実際に選択されている出口も確認してください。
ダイレクトモード（Direct）：コアに届いた接続を直接接続します。通常は比較テストに使います。

モードの選択欄は、バージョンによってプロキシ画面の上部やグローバルのショートカット領域にあります。どこから切り替える場合でも、モード自体がアプリの通信をコアへ送るわけではありません。アプリがシステムプロキシを使わず、TUNにも取り込まれていない場合、グローバルモードに切り替えてもプロキシ経由になったとは判断できません。

プロファイル画面：サブスクリプションの追加・更新・有効化

「プロファイル」では、コアが使う設定の取得元を管理します。リモートのサブスクリプションには通常、ノード、ポリシーグループ、ルール、関連パラメーターが含まれます。ローカルプロファイルは端末上のファイルから読み込みます。インポートが成功しても、設定内容を保存できたことを示すだけです。その後、そのプロファイルが有効になっており、コアが正常に読み込んだことも確認してください。

初回インポートの手順

「プロファイル」を開き、サブスクリプションURLの入力欄にサービス提供元から受け取ったURL全体を貼り付けて、インポートします。URLに認証情報が含まれる場合があるため、公開の掲示板などに投稿しないでください。
プロファイルのカードが表示されたら、名前と更新日時を確認します。インポートに失敗した場合は、まずエラーメッセージを確認してください。サブスクリプションURLをノードのアドレスとして手入力してはいけません。
そのカードを現在のプロファイルとして選択し、有効状態になっていることを確認します。選択中の表示はバージョンによって異なります。
「プロキシ」に戻り、ポリシーグループとノードが表示されていることを確認します。内容が古いままなら、プロファイル画面で別のカードが有効になっていないか確認してください。

サブスクリプションの更新と切り替えは別の操作

更新は同じ取得元から設定を再取得する操作です。有効化は、選んだ設定を現在の実行環境で使う操作です。サブスクリプションのカードが2枚ある場合、一方を更新しても、そのカードが現在のプロファイルになるとは限りません。ノード数、プランの通信量、利用期限などの情報が変わるかどうかは、サブスクリプションサービスが該当データを提供しているかによります。クライアントがこれらの情報を独自に生成することはありません。

ルールを調整する際は、変更対象がリモートの元ファイル、ローカル設定、またはクライアントのマージ・スクリプト処理のどれなのかを確認してください。リモート設定のコピーを直接編集すると、次回更新時に上書きされることがあります。マージ機能を使う場合は、最終的に実行される設定に意図した内容が反映されているか確認します。YAMLのインデント、フィールドの型、ポリシーグループ名が正しいことも必要です。エディターで保存できたというだけでは、コアが設定を受け付けたとは判断できません。

接続画面：通信の実際の出口を確認

「接続」には、コアに届いた通信の記録が表示されます。振り分け結果を確認するのに最適な画面です。主な項目は、接続先ホスト、宛先アドレス、ネットワーク種別、送受信量、適用ルール、ポリシー経路などです。プロセス名が表示されるかどうかは、OSの権限、通信の取り込み方法、コアの設定によって異なります。プロセス名がないだけで、接続に問題があるとは限りません。

新しいリクエストで動作を確認

「接続」画面を開いたまま、ブラウザーで新しいタブを開いて目的のWebページにアクセスします。ほかのアプリによるバックグラウンド通信は、できるだけ減らしてください。
ドメイン名で記録を絞り込みます。IPアドレスしか表示されない場合は、リクエスト時刻と宛先アドレスを照らし合わせて特定します。
接続の詳細を開き、適用ルール、ポリシーグループ、最終的に選ばれたノードを記録します。ポリシー経路が複数階層になる場合もあるため、最初のグループ名だけで判断しないでください。
DIRECTと表示されたら、ルール画面で理由を確認します。想定したノードを経由している場合は、Webページの応答や外部IP確認サービスも使って検証してください。

ノードを切り替えても、既存のTCP長時間接続やHTTP/2セッションは以前の出口を使い続ける場合があります。テストでは新しいリクエストを発行してください。必要に応じて該当する接続を閉じてから、もう一度アクセスします。接続画面から閉じると、そのセッションは切断されます。ダウンロード、オンライン会議、リモート端末などが中断される可能性があるため、対象を確認してから操作してください。

接続画面に目的の記録が表示されない場合は、ノードが使えないと判断する前に、通信がコアへ届いているか確認してください。ブラウザーに独自のプロキシ設定がある場合や、アプリがシステムプロキシを使わない場合があります。逆に、ページがキャッシュから表示され、新しいリクエストが発生していないこともあります。

ルール画面：マッチ条件、順序、最終ポリシーを確認

「ルール」には、現在の実行設定で読み込まれているルールが表示されます。主な種類は、完全一致ドメインのDOMAIN、ドメインサフィックスのDOMAIN-SUFFIX、IP範囲のIP-CIDR、ルールセット参照のRULE-SET、末尾のフォールバックとなるMATCHです。通常のルールは上から順に評価されるため、先に一致したルールが最終結果を左右します。

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

この例では、example.comとそのサブドメインへの通信を直接接続し、それ以外を「ノード選択」に渡します。ルールの順序を説明するための例であり、完全な設定の代わりには使えません。2行目で参照するポリシーグループが実際に存在し、名前も完全に一致している必要があります。

ルール画面と接続画面を照らし合わせる

ルール画面で定義を確認：条件、順序、参照先のポリシーを確認します。
接続画面で結果を確認：個々のリクエストが適用されたルールと、最終的に経由したノードを確認します。
プロファイル画面で設定元を変更：継続的な調整が必要な場合は、実際に有効な設定やマージルールの入口を探します。

画面に宛先IPしか表示されず、ドメイン名を取得できない場合、ドメインルールが想定どおりに適用されないことがあります。DNSの処理方法、アプリが独自に名前解決しているか、ドメイン嗅探が有効かを確認してください。ルール画面にルールが表示されていても、各リクエストにそのルールの判定に必要な情報があるとは限りません。

ログ画面：時刻を手掛かりにエラーの発生段階を特定

「ログ」では、実行中のイベントやエラーの前後関係を確認できます。遅延ランキングを見る画面ではありません。主なログレベルはinfo、warning、error、debugです。通常は必要な情報だけを記録し、調査中に限って一時的に詳細度を上げ、再現後は元に戻します。ログが増えすぎると確認しづらくなり、通信の詳細が漏れるおそれもあります。

状況を再現してから、エラー前後のログを確認

現在の時刻、有効なプロファイル、選択中のノード、システムプロキシとTUNのどちらを使っているかを記録します。
「ログ」を開き、目的のWebページを再読み込みするなど、失敗した操作を1回だけ再現します。
同じ時刻の記録を見つけ、前後の行も合わせて読みます。最後のtimeoutだけを切り取って判断しないでください。
設定の読み込み、ローカル待ち受け、DNS、リモート接続、プロトコルのハンドシェイクのどの段階かを切り分け、該当箇所だけを調整します。

ログの手掛かり	まず確認すること	この情報だけでは判断できないこと
`address already in use`	ローカルの待ち受けポートがほかのプログラムに使用されていないか	これだけでサブスクリプションの期限切れとは判断できない
`lookup`・名前解決エラー	エラーが出たドメイン、DNSの上流サーバー、サーバーへの到達性	この単語だけで、すべてのノードが使えないとは判断できない
`i/o timeout`	タイムアウトがDNS、接続開始、読み込みのどの段階で発生したか	認証情報の誤りとは限らない
`connection refused`	宛先アドレス、ポート、サービスの待ち受け状態	ルールを変更すれば直るとは限らない

同じ種類のエラーでも原因は複数考えられます。たとえば、リモート接続のタイムアウトは、ノードの経路に到達できない場合も、ローカルネットワークで通信が遮断されている場合もあります。DNS、ポート、モードを次々に変更するより、別のノードや別のネットワークで1項目ずつ比較するほうが原因を絞り込みやすくなります。ログを共有する場合は、エラーの種類と発生順を残し、サブスクリプションURL、認証情報、不要なアクセス先ドメインは削除してください。

設定画面：システムプロキシ、TUN、ポートの役割

「設定」で特に混同しやすいのが、システムプロキシとTUNです。システムプロキシはOSの設定にプロキシアドレスを書き込み、その設定に従うアプリで利用されます。TUNは仮想ネットワークインターフェースを作り、ルーティングやDNSの設定と組み合わせて通信を取り込みます。対象範囲は実際の設定によって異なります。両者は「通常ノード」と「高速ノード」の違いではなく、リモートサーバーの回線品質を自動的に向上させるものでもありません。

システムプロキシの確認手順

「設定」を開き、「システムプロキシ」のスイッチを探します。待ち受けポートは通常、同じ画面のポート欄またはClashパラメーター欄で確認できます。バージョンによっては「設定」→「Clash設定」にあります。画面の構成が変わっている場合は、現在の項目名を確認してください。他のクライアントのメニュー名をそのまま探す必要はありません。

たとえば、この端末の混合ポートが実際に7897に設定されている場合、プロキシを手動設定するアプリでは127.0.0.1:7897を指定します。別のポートが設定されていれば、その値を使ってください。7890も7897も、すべての環境で共通の固定値ではありません。混合ポートはHTTPとSOCKSのプロキシ接続を受け付けますが、アプリ側では対応しているプロトコルを選ぶ必要があります。

TUNとサービスの権限

TUNを有効にする際、サービスのインストールや起動、管理者権限の許可が求められることがあります。まず画面の案内に従ってサービスを設定し、その後スイッチの状態とログを確認してください。仮想ネットワークアダプター、ルート、DNSの設定に失敗している場合、ボタンがオンになっているだけでは通信を取り込めているとは限りません。社内VPN、ほかのプロキシソフト、セキュリティソフトがルーティングに影響することもあります。調査を始める前に、元のネットワーク設定を記録してください。

インポートから接続確認までの一連の手順

プロファイル画面：サブスクリプションをインポートして該当の設定を有効にし、読み込みエラーがないことを確認します。
プロキシ画面：ルールモードを選び、手動選択のポリシーグループでノードを選択して遅延をテストします。
設定画面：システムプロキシを有効にし、ローカルの待ち受けポートを確認します。そのほかのネットワーク設定は変更せずに進めます。
接続画面：目的のWebページにアクセスし、新しい接続に適用されたルールと最終的な出口を確認します。
ルール画面：出口が想定と異なる場合は、該当ルールと、その前に一致したルールを確認します。
ログ画面：接続に失敗した場合は、時刻を手掛かりにエラーを特定し、該当する段階だけを調べます。

各画面のつながりを押さえておきましょう。プロファイルがノードとルールを定義し、プロキシ画面でポリシーの選択を行い、設定画面で通信をコアへ届ける方法を決めます。接続画面で実際の結果を確認し、ルール画面で振り分け条件を調べ、ログで失敗の原因を追います。「ノードはあるのに通信できない」「ノードを切り替えても出口が変わらない」「特定のサイトが直結のまま」といった問題も、この流れに沿って順番に確認できます。

初回インストールやプラットフォームの選び方は入門ガイドをご覧ください。DNS、ポート、システムプロキシに関する問題はよくある質問で確認できます。ポリシーグループ、コア、ルールセットなどの用語がわからない場合は、設定を変更する前に用語集をご覧ください。