まずはメイン画面を把握:画面操作とコアの動作は分けて考える

Clash Verge Revはデスクトップ用の管理画面です。プロキシ接続、DNS、ルールの処理を実際に行うのはMihomoコアです。ウィンドウが開いていても、確認できるのはGUIが起動したことだけです。通信できるかどうかは、設定が読み込まれているか、通信の入口がトラフィックを取り込んでいるか、対象の接続でどの出力経路が選ばれたかによって変わります。

サイドバーのプロキシ、サブスクリプション、接続、ログ、設定はそれぞれ役割が異なります。バージョンによって並び順やアイコン、ボタンの位置が変わる場合があります。この記事では各機能ページの操作を説明し、特定のアイコン位置を固定の基準とはしません。

ページ主な用途操作後に確認すること
プロキシモード、プロキシグループ、ノードの選択新しい接続で実際に使われるプロキシ経路
サブスクリプション設定の読み込み・更新・有効化現在の設定を示す表示と読み込みログ
接続リクエスト、ルール、通信量の確認接続先ドメイン、ルール、出力経路
ログコアの動作状況とエラーの確認エラーが発生した時刻と具体的な原因
設定システムプロキシ、TUN、ポートの設定アプリの通信がコアに取り込まれているか

プロキシページ:モード、プロキシグループ、遅延テスト

ルール・グローバル・ダイレクトモードの違い

プロキシページでモードを切り替えると、コアが出力先を選ぶ方法が変わります。通常はルールモードから使い始め、接続ページでルールの適用結果を確認します。モード名が示すのはコアに入った後の処理方法であり、すべてのアプリの通信を自動的にコアへ取り込む機能ではありません。

  • ルールモード:設定されたルールを上から順に照合し、最初に一致したルールのポリシーを適用します。ダイレクト接続とプロキシ経由の通信を同時に使うこともできます。
  • グローバルモード:コアに取り込まれた通信をグローバルポリシーで処理します。一時的な比較や切り分けに便利です。利用可能な出力先を対応するポリシーグループで選ぶ必要があります。
  • ダイレクトモード:コアに取り込まれた通信を接続先へ直接つなぎます。システムプロキシやTUNを無効にする設定ではありません。

プロキシグループはノードそのものではなく、グループの選択が実際の利用を意味するとは限らない

プロキシグループにはノードのほか、別のプロキシグループを含めることもできます。手動選択型のグループは通常 select、自動遅延テスト型は url-test、障害時に切り替えるグループは fallback です。自動グループで一時的な手動選択ができるか、いつ経路を再選択するかは、グループの種類と設定によって異なります。

手動選択型グループでノードをクリックすると、そのグループの選択先が変わります。リクエストが DIRECT や別のプロキシグループに振り分けられている場合、現在のグループで新しいノードが選択表示になっていても、そのリクエストには影響しません。切り分ける際は「適用ルール → ポリシーグループ → 実際のノード」の順に確認します。

遅延テスト・検索・展開ボタンの使い方

  • 遅延テスト:テスト用アドレスへ通信し、ミリ秒単位の値またはタイムアウトを表示します。ダウンロード速度を測るものではなく、数値が低くても動画配信サービスに接続できるとは限りません。
  • 検索・絞り込み:ノード名を探しやすくする機能です。ルールや現在の選択先は自動で変更されません。
  • 展開・折りたたみ:一覧の表示範囲を切り替える機能です。グループ内のノードは無効になりません。

たとえば同じテストでノードAが 85 ms、ノードBが 160 ms と表示された場合、そのテスト先とネットワーク環境ではAの応答時間が短かったことを示すだけです。数値は説明用の例であり、本サイトによる実測値ではありません。一括テストは接続を追加で発生させるため、ノードが多い場合に何度も繰り返す必要はありません。

サブスクリプションページ:読み込み・有効化・更新・ローカル上書き

設定を読み込んだら、現在有効な項目も確認する

「サブスクリプション」ページを開き、プロバイダーから提供されたClash対応サブスクリプションURLを入力欄に貼り付けて読み込みます。入力するのはクライアントが読み込める設定URLであり、アカウントページのURLではありません。サブスクリプションURLには通常アクセス情報が含まれるため、スクリーンショットや公開ログ、質問投稿に全体を載せないでください。

  1. 読み込み後、設定カードが表示され、名前や更新日時などの情報が確認できるか見ます。
  2. 使用する設定を選び、現在有効であることを示す表示が出ているか確認します。初回読み込み時に自動で有効になるかどうかは、画面の状態で判断してください。
  3. プロキシページに切り替え、想定したプロキシグループとノードが表示されているか確認します。
  4. 解析エラーが表示された場合はログページで具体的なエラーを記録します。何度も有効化してエラー表示を見えにくくしないでください。

更新・編集・削除で何が変わるか

更新するとリモートの設定を再取得し、有効化すると選択した設定をコアに適用します。別々の操作です。更新後に自動で再読み込みする設定もありますが、現在有効な項目の表示とログを確認し、新しい内容が反映されたことを確かめてください。

設定カードのメニューには、更新、情報の編集、ファイルの編集、ファイルの場所を開く、削除などが表示される場合があります。名前や更新間隔の編集は通常、管理情報を変更します。ファイルの編集ではローカルのYAMLを直接変更する可能性があります。削除するとローカルの設定記録が取り除かれますが、プロバイダーのアカウントやサブスクリプション契約が解約されるわけではありません。

ローカルルールを残したい場合は、挿入位置とマージ方法を先に確認します。ルールは順番が重要です。独自ルールをフォールバックの MATCH より後に追加しても、通常は期待どおりに機能しません。Mergeで配列が処理される方法も「すべての項目が自動で追加される」と決めつけないでください。設定方法は応用ガイドも参照してください。

接続ページ:ルールとプロキシ経路で通信先を確認する

接続ページには、コアが検知した接続が表示されます。主な項目は接続先ホスト、接続先IP、送信元アドレス、ネットワーク種別、ルール、プロキシ経路、アップロード・ダウンロード量、接続時間です。プロセス情報の一部はOSの権限やプロセス識別の条件に依存するため、プロセス名が表示されなくても接続に異常があるとは限りません。

4つの項目でWebリクエストを特定する

  1. ホスト・接続先:アクセスしたばかりのドメインを検索します。ドメイン名はリクエスト情報、DNSマッピング、スニッフィングなどから取得されます。IPアドレスだけが表示される記録もあります。
  2. ルール:想定したドメインルールやIPルール、または最終ルールの MATCH に一致したか確認します。
  3. プロキシ経路:プロキシページの選択色だけで判断せず、通過したポリシーグループと最終ノードを確認します。
  4. 通信量と時間:通信が継続しているか確認します。接続が存在していてもダウンロード量が増えない場合、接続先が正常に応答している証拠にはなりません。

アップロード量とダウンロード量は通常、接続中の累積値です。リアルタイム速度が別に表示される場合もあるため、単位を確認してください。KB/s は速度、MB は累積データ量です。Webページはメインのサイト、画像用ドメイン、API用ドメインなどへ同時に接続します。1つのリクエストがプロキシ経由でも、ページ内のすべてのリソースが同じ経路を通るとは限りません。

個別の接続を閉じる・すべての接続を閉じる

接続を閉じると現在のセッションが切断されますが、接続先ドメインが恒久的にブロックされるわけではありません。アプリがすぐに再接続することもあります。ノードを切り替えても、既存のTCP長時間接続は通常、自動で移行しません。関連する接続だけを閉じてページを再読み込みし、新しいノードが使われるか確認できます。

「すべての接続を閉じる」はセッションを再確立する必要があるテストに便利ですが、ファイル転送、会議、リモート端末が切断されることがあります。日常の切り分けでは、まず検索で対象を絞り、該当する接続だけを閉じると影響を抑えられます。

ログページ:ログレベル・エラー内容・再現手順

ログページではコアの動作イベントを確認できます。アプリのログやログフォルダーを開く項目が別に用意されている場合もあります。GUIの起動失敗とネットワーク接続の失敗は分けて調べ、すべてをノードの問題として扱わないでください。

まずはinfo、必要なときだけ一時的にdebug

主なログレベルは info、warning、error、debug です。通常はまず info で接続や動作の情報を確認し、情報が足りない場合に限り、一時的に debug を有効にします。debugでは出力が増えるため、ドメイン名やアドレスなどのプライバシー情報が含まれる可能性も高くなります。

ログのキーワードよくある意味優先して確認する項目
timeout特定の処理がタイムアウト前後のログからDNS・接続開始・ハンドシェイクのどこで起きたか判断する
connection refused接続先ポートが接続を拒否接続先アドレス、ポート、サービスの状態
address already in use待ち受けアドレスまたはポートが使用中クライアントの多重起動とポート設定
yaml または解析エラー設定の構文またはフィールド構造に問題があるエラー行、インデント、上書き後の設定

一時停止・クリア・コピーの用途

スクロールや表示の一時停止は通常ログの表示だけに影響し、プロキシサービスを停止するものではありません。クリアボタンは一般に現在の表示を消すためのもので、ディスク上のログが削除されたとは限りません。コピーやエクスポートの前に、サブスクリプションURL、トークン、アカウント情報、公開に適さないネットワークアドレスを伏せてください。

  1. 現在時刻を記録し、表示領域をクリアするか最新のログまで移動します。
  2. 失敗したページを1回更新するなど、障害を1回だけ再現します。
  3. 最後の1行だけでなく、障害の前後約10~20秒の関連ログを残します。
  4. 実行モード、プロキシグループの選択、TUNの有効・無効も併せて記録し、関連を確認できるようにします。

設定ページ:システムプロキシ・TUN・ポートの役割

システムプロキシとTUNは別々の通信入口

「設定」→「システムプロキシ」の順に開いてスイッチを確認するか、使用中のバージョンにあるショートカットを使います。システムプロキシを有効にすると、OSのプロキシ設定に従うアプリがローカルのプロキシポートへ接続します。この設定を無視するアプリでは、個別の設定か、用途に合ったTUNによる取り込みが必要です。

「設定」→「TUNモード」の順に開き、スイッチと関連項目を確認します。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、通常はサービスモードまたは適切なシステム権限が必要です。有効化に失敗した場合は、スイッチを何度も押すのではなく、サービス、権限、ログを確認してください。複数のVPNやTUNツールを同時に動かすと、ルーティングやDNSが競合することがあります。

ローカルポートとノードサーバーのポートを混同しない

ポート項目は通常、「設定」内のポートまたはポート設定のセクションにあります。名称は使用中のバージョンによって異なります。mixed-port はローカルのHTTP/SOCKS共用入口であり、リモートノードのポートではありません。以下は各フィールドの意味を示すもので、そのまま読み込める完全な設定ではありません。

mixed-port: 7897
allow-lan: false
mode: rule
log-level: info

実際の混合ポートが 7897 の場合、アプリを手動設定するときは、ローカルアドレスに 127.0.0.1、ポートに 7897 を指定できます。すべての環境でこのポートが使われているとは限らないため、実際の設定を確認してください。ポートがすでに使われている場合は競合を解消し、手動設定しているアプリも合わせて変更します。

「LAN内からの接続を許可」は、ほかのデバイスからこのPCのプロキシ入口に接続できるようにする設定です。このPCのブラウザーがプロキシを利用できるかどうかとは別の話です。有効にする前に、待ち受けアドレス、ファイアウォール、認証を確認してください。プロキシポートやコントロールインターフェースを信頼できないネットワークに直接公開しないでください。

画面から最小限の動作確認を行う

初回設定や変更後は、複数のスイッチを同時に変えるより、手順を決めて確認すると原因を特定しやすくなります。以下では必要な設定だけを順に変更します。「起動しているのにWebページを開けない」場合に適した手順です。

  1. サブスクリプションページ:設定の読み込みが成功し、現在有効になっていることを確認します。ログに設定読み込みエラーがないことも確認してください。
  2. プロキシページ:ルールモードを使用し、対象のリクエストで使う手動選択型プロキシグループからノードを選び、遅延テストを1回実行します。
  3. 設定ページ:まずアプリの通信入口を確認します。ブラウザーでは最初にシステムプロキシで動作を確認し、通信を取り込む必要がある場合にTUNを設定します。
  4. 接続ページ:対象のWebページを開き、新しい接続を探して、適用ルールと最終ノードを確認します。
  5. ログページ:失敗した場合は同じ時刻のエラーを確認し、関連する設定を1つだけ変更して再テストします。

画面の見方は、「サブスクリプションページ=何を読み込んだか」「プロキシページ=どう経路を選ぶか」「接続ページ=実際にどの経路を通ったか」「ログページ=どの段階で失敗したか」と整理できます。初回インストールからサブスクリプションの設定まで詳しく知りたい場合は、クイックスタートをご覧ください。