Clash Vergeを初めて開くと、サイドバーの設定、プロキシ、接続、ログ、設定項目はそれぞれ独立しているように見えます。しかし実際には明確な手順があります。まずクライアントに利用可能な設定を読み込ませ、次にプロキシグループからノードを選び、その後システムプロキシまたはTUNモードを有効にし、最後に接続画面とログで通信がmihomoカーネルに入っているか確認します。特定の画面だけを見ていると、設定が反映されていないのか、ノードが使えないのか、アプリの通信がプロキシを経由していないのか判断しにくいことがあります。

Clash Verge Revは通常、グラフィカルインターフェースで設定とカーネルの稼働状態を管理します。ルールのマッチング、プロトコル接続、DNS処理、通信の転送はmihomoが実行します。バージョンによってメニュー名、アイコンの位置、設定の分類は多少変わる場合がありますが、基本的な情報の流れは共通しています。特定のボタンの位置を覚えるより、各画面の関係を理解することが重要です。

まず画面上の通信処理の順序を理解する

1回の接続は複数の段階を経て処理されます。設定画面はノード、プロキシグループ、ルール、DNSなどの実行パラメータを提供します。プロキシ画面では、各プロキシグループで現在使用するノードを決めます。システムプロキシまたはTUNモードは、デバイスの通信をカーネルへ送ります。ルールシステムはドメイン、IP、ポート、プロセスに応じて、どのプロキシグループへ渡すかを判断します。接続画面とログ画面には、その処理結果が表示されます。

  1. 設定をインポート：サブスクリプションURLまたはローカルのYAMLファイルから設定を登録し、初回更新を完了します。
  2. 設定を有効化：設定一覧で対象の設定を選択し、現在の実行設定にします。
  3. ノードを選択：プロキシ画面を開き、主要なプロキシグループを確認して利用可能なノードを選びます。
  4. 通信を取り込む：用途に応じてシステムプロキシを有効にし、より広範囲の通信を取り込む必要がある場合はTUNモードを有効にします。
  5. 結果を確認：対象サイトへアクセスしながら、接続一覧、ルールのヒット状況、ログを確認します。

設定画面：サブスクリプションをインポートして現在の設定を確認

設定画面はProfilesとも呼ばれ、操作全体の起点になります。ここにはサブスクリプション設定、ローカル設定、必要に応じてマージやスクリプト処理の項目が保存されます。サブスクリプションURLはノードそのものではなく、設定内容を取得するための入口です。更新が成功して初めて、クライアントにノード、プロキシグループ、ルールなどのデータが読み込まれます。

サブスクリプションの状態を確認するポイント

サブスクリプション入力欄に完全なURLを貼り付けてインポートします。設定カードが表示されても、内容が必ず使えるとは限りません。名前、更新日時、更新処理が正常に完了したかも確認してください。設定の提供元が専用のユーザーエージェント、認証パラメータ、特定のネットワーク環境を要求している場合は、提供元の案内に従います。

  • 貼り付けた内容が完全なHTTPまたはHTTPS URLで、先頭と末尾に余分な空白がないことを確認します。
  • 更新後にプロキシ画面を開き、想定したノードとプロキシグループが生成されているか確認します。
  • 複数の設定がある場合は、現在選択されている印を確認し、別の設定を編集したまま別の設定を実行しないようにします。
  • サブスクリプションの内容が変わったら更新を実行し、ノード名、プロキシグループ、その他の情報が更新されているか確認します。

ローカルYAML設定が適しているケース

ローカル設定は、ルールのデバッグ、ノードの手動管理、DNSパラメータの検証に適しています。YAMLはインデントとデータ構造の影響を受けやすく、リストの階層、コロンの後の空白、フィールドの所属が解析結果を左右します。設定をインポートできても、すべてのフィールドが現在のmihomoのバージョンで受け入れられるとは限りません。解析に失敗した場合は、まずログに表示されたフィールド名と行番号を確認してください。

proxies → proxy-groups → rules
          ↑
          プロキシグループがノードを参照する
rules は最終的に通信をプロキシグループ、DIRECT、またはREJECTへ渡す

ルールは通常、上から順に評価され、先にヒットしたルールのプロキシが適用されます。広範囲を対象にするルールを上位に置くと、後続のより具体的なドメインルールが機能しなくなる場合があります。画面の設定編集機能は小規模な確認に適しています。大きく変更する場合は、まず元のファイルを保存し、部分ごとに検証してください。

プロキシ画面：プロキシグループ、ノード、遅延を理解する

プロキシ画面には、設定に含まれるプロキシグループと候補が表示されます。画面上部では、ルール、グローバル、ダイレクトなどの動作モードを切り替えられることが多く、中央にはプロキシグループがカードまたは一覧で表示されます。ノードをクリックする操作は、通常、そのプロキシグループの現在の選択を変更するものです。設定全体をそのノードへ切り替える操作ではありません。

画面上で見られる主なプロキシグループの違い

selectタイプはユーザーがノードまたは下位のプロキシグループを手動で選択します。url-testはテスト結果に基づいて条件に合う候補を自動選択します。fallbackは可用性を重視し、現在の候補が利用できない場合に後続の候補へ切り替えます。load-balanceは設定した方式に従って、複数の候補へ通信を振り分けます。具体的な動作は、テストURL、間隔、許容差、ハッシュ方式にも左右されます。

プロキシグループが別のプロキシグループを参照することもあります。そのため画面上では、「入口グループが自動選択グループを選び、自動選択グループがさらにノードを選ぶ」という階層になる場合があります。トラブルシューティングでは、まずルールが最終的にヒットしたグループから確認し、各階層の現在の選択を順に確認してください。特定のノードカードの色だけを見て判断することはできません。

遅延の数値をどう読み取るか

遅延テストでは通常、設定されたテストURLへアクセスし、その時点の経路における応答時間を測定します。数値が低ければ候補ノードの比較には役立ちますが、ダウンロード速度、混雑時間帯の安定性、すべての対象サイトへの接続品質を直接示すものではありません。タイムアウトは、ノードの状態、テスト先への到達性、DNS名前解決、ローカルネットワークの制限などが原因で発生します。

  • ルールモード：ルールに基づいて通信をプロキシ、ダイレクト、拒否へ振り分けます。日常利用に適しています。
  • グローバルモード：大部分の通信をグローバルプロキシグループへ渡します。ノードの基本的な接続性を短時間で確認する場合に適しています。
  • ダイレクトモード：通信を優先的に直接接続します。プロキシを有効にする前後の違いを比較する際に利用できます。

ルールモードからグローバルモードへ切り替えてアクセスが回復した場合、ノードの基本接続は利用できる可能性が高く、問題はルールマッチング、プロキシグループの選択、DNS処理にあると考えられます。グローバルモードでも失敗する場合は、ノード、ネットワーク、カーネルの状態、通信の取り込み方式を引き続き確認してください。

接続画面：リクエストがどのルールを通ったか確認する

接続画面には、現在カーネルを通過しているアクティブな接続が記録されます。主な項目は対象ホスト、対象IP、アップロード量とダウンロード量、接続時間、ネットワーク種別、ヒットしたルール、最終的な経路などです。「特定のアプリがClashに入っているか」を判断する直接的な入口になります。

対象ページを開いたら、ドメインで接続を絞り込めます。一覧に該当ドメインが表示され、プロキシグループとノードの経路が示されていれば、通信はカーネルに入っています。接続が存在するのにアクセスできない場合は、ルール、対象アドレス、経路を確認します。一覧に記録がまったくない場合は、ブラウザーのプロキシ設定、システムプロキシのスイッチ、TUNの状態、アプリがシステムプロキシを迂回していないかを優先的に確認してください。

接続経路の矢印が示すもの

一部の画面では、プロキシの選択が「メディア用プロキシ → 自動選択 → ノードA」のような経路で表示されます。これは、ルールがまず通信をメディア用プロキシグループへ渡し、そのグループが自動選択グループを参照し、最終的にノードAが外向きの接続を確立することを示します。経路を見れば、どの階層で選択が行われたかを特定できます。また、別のプロキシグループを手動で変更しても現在のアクセスが変わらない理由も説明できます。

接続を閉じると役立つ場面

多くのアプリは既存のTCP、QUIC、WebSocket接続を再利用します。ノードを切り替えても古い接続が以前の経路を維持し、テスト結果がすぐに変わらないことがあります。その場合は接続画面で関連する接続を閉じ、ページを再読み込みしてください。リアルタイム通信やダウンロード中の接続を閉じると現在の転送が中断されるため、先にタスクの状態を確認します。

ログ画面：設定・DNS・接続エラーを切り分ける

ログ画面には、カーネルの起動、設定の読み込み、DNSクエリ、ルールマッチング、外向き接続の確立などのイベントが表示されます。初回接続に失敗したときは、Webページのエラー表示だけを見るよりログの方が多くの情報を得られます。ログレベルは日常的に読める範囲に保ち、問題を1回再現して時刻を記録したうえで、その前後の情報を確認することをおすすめします。

よくあるログメッセージの確認ポイント

  • 設定の解析エラー：YAMLのインデント、フィールド名の綴り、データ型、現在のカーネルがそのフィールドに対応しているかを確認します。
  • DNSクエリのタイムアウト：nameserver、ネットワークへの到達性、DNSハイジャック設定、ドメイン解決モードを確認します。
  • 接続拒否：対象ポートまたはノードのサービスが接続を受け付けていないか、中間ネットワークのポリシーが原因の可能性があります。
  • 接続タイムアウト：ノードアドレスの名前解決、サーバーへの到達性、転送パラメータ、ローカルファイアウォールのポリシーを確認します。
  • プロキシまたはノードが見つからない：設定内の参照名の不一致、サブスクリプション内容の欠落、マージ結果が原因であることが多いです。

ログのwarningは注意が必要な異常や互換性に関する通知を示し、errorは通常その操作が失敗したことを示します。ただし、最終的には前後の文脈と合わせて判断してください。たとえば予備DNSへの問い合わせがタイムアウトしても、別のリゾルバーが正常に応答する場合があります。1行だけを抜き出すと、その後の結果を見落としやすくなります。トラブルシューティングでは、エラーの前後を数行残し、直前に実行したアクセスに対応するログか確認します。

ログにはドメイン、ノードアドレス、ローカルネットワーク情報が含まれる場合があります。スクリーンショットやテキストを共有する前に、問題に関係する部分だけを整理し、サブスクリプションURL、認証パラメータ、個人を特定できるネットワーク情報を削除してください。サブスクリプションURLには通常アクセス用の認証情報が含まれるため、そのまま公開するのは避けます。

設定画面：システムプロキシ、TUN、カーネルの状態

設定画面では、クライアントの動作、スタートアップ、システムプロキシ、TUN、カーネル、ネットワークパラメータを管理します。初めて使う場合に特に重要なのは、システムプロキシとTUNモードの違いです。どちらも通信をカーネルへ渡しますが、対象範囲と必要なシステム権限が異なります。

システムプロキシはブラウザーや一般的なデスクトップアプリ向け

システムプロキシを有効にすると、Clash VergeはOSのHTTPやHTTPSなどのプロキシアドレスをローカルの待受ポートへ向けます。システムプロキシ設定に従うブラウザーやアプリは、リクエストをカーネルへ送信します。一部のアプリは独自のプロキシ設定を使い、コマンドラインプログラムでは環境変数の設定が別途必要な場合があります。そのためシステムプロキシを有効にした後も、接続画面で対象プログラムの通信が実際に入っているか確認してください。

TUNモードはより広範囲の通信を取り込む場合に適している

TUNモードは仮想ネットワークインターフェースを通してIP通信を処理し、システムプロキシを参照しないプログラムも広くカバーできます。UDPや透過的な通信の取り込みが必要な場面でも使われます。仮想NIC、ルーティング、DNS設定に関わるため、有効化にはシステム権限が必要になる場合があります。端末で別のVPN、仮想NICツール、ネットワークフィルター、企業ネットワーク用コンポーネントを同時に使っている場合は、ルートやインターフェースの競合に注意してください。

システムプロキシとTUNは、設定を増やせば増やすほど効果が高くなるものではありません。日常的なブラウザーアクセスなら、まずシステムプロキシで最小限の経路を構築して確認します。アプリがシステムプロキシを迂回する、ゲームでUDPが必要、透過プロキシが必要といった場合に、TUNを試してください。モードを切り替えた後は、接続一覧とDNSの挙動を再確認します。

カーネルとインターフェースのバージョンは分けて確認する

Clash Verge Revは管理インターフェースで、mihomoはプロキシ処理を実行するカーネルです。設定画面では通常、カーネルの稼働状態や関連するバージョン情報を確認できます。インターフェースが正常に開いていても、カーネルの起動に失敗すると、プロキシポート、ルール、接続画面は正常に動作しません。すべてのノードが同時に異常になり、接続一覧が空で、ログにも正常な起動情報がない場合は、まずカーネルの状態を確認してください。

初回接続に失敗したときの画面確認手順

トラブルシューティングの目的は、ノード、DNS、ルール、TUNを一度に変更することではなく、原因の範囲を段階的に絞り込むことです。各手順で変更する変数を1つに限定し、接続画面またはログで結果を確認すれば、どの調整が実際に効果をもたらしたか判断できます。

  1. 設定画面を確認：サブスクリプションの更新が完了し、対象設定が選択され、更新日時が想定どおりであることを確認します。
  2. プロキシ画面を確認：状態が明確なノードを1つ選び、主要なプロキシグループで遅延テストを実行し、プロキシの経路が最終的にそのノードを指していることを確認します。
  3. 一時的な検証モード：グローバルモードで基本的な接続性をテストします。アクセスが回復したら、ルールモードに戻ってヒットしたルールを確認します。
  4. 通信の取り込みを確認：まずシステムプロキシを有効にしてテストページへアクセスします。接続一覧に記録がない場合は、アプリのプロキシ設定を確認するか、TUNが必要か検討します。
  5. 接続記録を確認：対象ドメイン、ヒットしたルール、プロキシグループ、最終ノードを確認し、ノードを切り替えた後は古い接続を閉じて再テストします。
  6. ログを読む：テスト時刻の前後からDNS、timeout、refused、parseなどの情報を探し、文脈と合わせてどの処理段階のものか判断します。
  7. 最小構成に戻す：追加スクリプト、複雑な上書き、実験的なDNS設定を一時停止し、基本設定でコア経路を確認してから1項目ずつ戻します。

よくある3つの現象を切り分ける

Webページは開けないが、接続一覧には記録がある：通信はすでにカーネルに入っています。ヒットしたルール、ノード経路、DNSの結果、ログのエラーを確認してください。DIRECTと表示される場合は、ルールが対象ドメインをダイレクト接続にしていないか確認します。プロキシノードと表示される場合は、ノードと対象サイト間の接続を確認します。

ブラウザーは使えるが、特定のアプリだけ使えない：ブラウザーはシステムプロキシに従っていても、そのアプリはダイレクト接続、独自プロキシ、特殊なネットワークスタックを使っている可能性があります。まず接続画面にそのアプリのリクエストが表示されるか確認し、その後アプリのプロキシ設定を行うかTUNモードを試します。

ノードテストは正常だが、実際のアクセスがタイムアウトする：遅延テストの接続先と実際の対象は異なり、ルール、DNS、転送プロトコル、古い接続の再利用も関係します。関連する接続を閉じ、対象ドメインのプロキシ経路を確認し、同じ時刻のログを読む方が、遅延テストを繰り返すより効果的です。

日常利用で重点的に確認する画面

設定が安定した後は、すべての項目を頻繁に調整する必要はありません。サブスクリプションを更新したら設定画面を確認し、地域や経路を変更するときはプロキシ画面を開きます。アクセス結果に異常がある場合は接続画面とログを優先して確認し、OSの更新、カーネルの更新、ネットワーク環境の変化後にTUN、システムプロキシ、サービスの状態を確認してください。

ルールモードでは、ノードの選択先は通常、少数の主要なプロキシグループに集約されています。各グループが一般的なプロキシ、ストリーミング、インスタントメッセージ、その他の用途のどれを担当しているか記録しておくと、必要な入口をすぐに見つけられます。設定をサブスクリプション提供元が管理している場合、グループ名が変わる可能性があるため、更新後に階層と現在の選択を再確認してください。

画面を使いこなす鍵は、すべての機能を1つずつクリックすることではありません。各画面が答える問いを理解することです。設定画面は「何を読み込んだか」、プロキシ画面は「何を選択しているか」、接続画面は「通信が実際にどこを通ったか」、ログ画面は「処理中に何が起きたか」、設定画面は「通信がどのようにカーネルへ入るか」を示します。この5つの問いで、初回インストール、サブスクリプションのインポート、接続のトラブルシューティングの大部分を確認できます。