設定・プロキシ選択・通信の取り込みを理解する
Clash Verge Revを初めて起動したら、まず確認したいのは「設定ファイルはどこから取得するか」「どのノードに通信を流すか」「アプリの通信をどうクライアントに取り込むか」の3点です。それぞれ設定画面、プロキシ画面、設定内のシステムプロキシまたはTUNモードで操作します。プロキシ画面でノードを選んだだけでは、ブラウザーがプロキシを使うとは限りません。サブスクリプションをインポートできても、その設定が有効になったとは限りません。
Clash Verge Revはデスクトップクライアントです。設定管理、システム連携、画面操作はクライアントが担い、通信の転送やルール判定は使用中のmihomoコアが実行します。トラブル時は「画面上の操作が反映されない」のか、「コアがリクエストを受け取った後に接続できない」のかを切り分けましょう。確認する場所が異なります。
| 画面 | 主な操作対象 | よく使う場面 |
|---|---|---|
| プロキシ | 動作モード、プロキシグループ、ノード選択 | 経路の切り替え、現在の出口の確認 |
| 設定 | サブスクリプションURL、ローカル設定、有効化 | サブスクリプションのインポート、ノード一覧の更新 |
| 接続 | 現在のリクエスト、マッチしたルール、プロキシチェーン | リクエストの実際の経路を確認 |
| ルール | 読み込み済みのルールと適用順 | ドメインが直接接続またはプロキシ経由になる理由を確認 |
| ログ | 動作イベントとエラー情報 | タイムアウト、名前解決、読み込みの失敗を特定 |
| 設定 | ポート、システムプロキシ、TUN、クライアントの動作 | アプリの通信を取り込む、または動作パラメーターを調整 |
以下では、各画面からできることを順に説明します。バージョンによってサイドバーの並びやボタンの位置、設定項目の分類が異なる場合があるため、操作時は画面に表示される機能名を確認してください。ポート番号も現在の設定画面で確認し、例示した値をすべての環境に共通する固定値と考えないでください。
プロキシ画面:動作モードとプロキシグループの出口を選ぶ
「プロキシ」を開いたら、まず現在の動作モードを確認し、次にプロキシグループを確認します。ルールモードでは、設定内のルールに従ってコアが使用するプロキシを選択します。グローバルモードでは通常、GLOBALグループを使って通信を処理します。ダイレクトモードでは、通常のリクエストはプロキシノードを経由しません。グローバルモードは短時間の比較テストには便利ですが、ルールの問題を長期的に調査する代わりにはなりません。
プロキシグループはサブスクリプションとは別物。単一ノードとも限らない
設定ファイルには「ノード選択」「自動選択」「ストリーミング」など、複数のプロキシグループを定義できます。グループ名は設定ファイルの作成者が決めるもので、クライアント共通の機能名ではありません。グループ内の項目はノードのほか、別のプロキシグループやDIRECTのような組み込みポリシーの場合もあります。
selectグループは、通常、手動選択に使います。画面で項目を選ぶと、そのグループを使う新しい接続に選択が反映されます。url-testグループは、設定されたテストURL、間隔、許容値をもとにノードを自動評価します。表示された数値が最も小さいノードを毎回必ず選ぶという意味ではありません。fallbackグループは、主にノードの利用可否と設定順に基づいて出口を選びます。単純に「遅延が最も小さいグループ」と捉えることはできません。
遅延の数値から分かること
ノードやプロキシグループの遅延テストを実行すると、指定されたテスト先への接続結果が表示されます。たとえば結果が180 msでも、ダウンロード速度を示すわけではなく、すべてのサイトに接続できる保証にもなりません。テスト先やノードの経路、アクセス先が異なれば結果も変わります。タイムアウトした場合はログも確認し、ノードに到達できないのか、名前解決に失敗したのか、テスト先自体が利用できないのかを切り分けてください。
設定画面:サブスクリプションをインポート・更新して有効化する
「設定」画面では、クライアントが読み込む設定の取得元を管理します。リモートサブスクリプションは通常URLからYAMLを取得し、ローカル設定はファイルから読み込みます。クライアントに必要なのは互換性のある設定ファイルであり、あらゆる形式のノード共有テキストを読み込めるわけではありません。インポートに失敗したら、まず提供元がClashまたはmihomoで使える形式を提供しているか確認してください。
初回インポートで確認する4つの手順
- 「設定」を開き、サブスクリプションURLの入力欄にURL全体を貼り付けてインポートします。紹介ページのURLをサブスクリプションURLとして入力しないでください。
- 設定カードが表示されるまで待ち、ダウンロード失敗や解析エラーの表示がないか確認します。カードが表示されても、設定が一覧に追加されたことを示すだけです。
- 該当するカードで有効化または選択の操作を行い、現在使用中の設定が切り替わったことを確認します。
- 「プロキシ」に戻り、想定したプロキシグループとノードが表示されているか確認してから、ノードを選択し接続テストを実行します。
「サブスクリプションを更新」はリモートの内容を再取得する操作、「設定を切り替える」は別の設定をコアに読み込ませる操作です。両者は異なります。更新後もノードが変わらない場合は、まず更新したカードが現在有効なものか確認し、ログで取得や読み込みの失敗がないか調べてください。
設定を編集する前に、変更が保持されるか確認する
リモートサブスクリプションから取得した内容を直接編集すると、次回の更新で変更が上書きされることがあります。ルールや項目を継続的に追加・調整する場合は、現在のバージョンがサポートするオーバーライドや拡張設定などの仕組みを使い、最終的に反映された内容を確認してください。同じ項目を複数箇所で管理すると、画面のスイッチ、サブスクリプションの原文、最終設定の内容が食い違うおそれがあります。
サブスクリプションURLにはアクセス用の認証情報が含まれることがあります。スクリーンショットの共有、問題の報告、設定ファイルの共有を行う前に、URLのクエリパラメーターに含まれるトークン、ノードのパスワード、個人用サーバーの情報を削除してください。項目名とエラー行番号を残せば調査に役立ちます。多くの画面上の問題では、サブスクリプション全体を公開する必要はありません。
接続画面:リクエストがコアに届いているか、実際の経路を確認する
「接続」画面では、「このサイトへの通信は本当にプロキシを経由しているか」を確認できます。画面を開いた状態でブラウザーから新しいリクエストを送信し、対象のドメイン名またはIPアドレス、送受信データ、画面に表示されるルールやプロキシチェーンの情報を確認します。プロセス情報の一部は、OSの権限や通信の取り込み方法によって表示されないことがあります。項目が空欄でも、リクエストに問題があるとは限りません。
リクエストの表示有無で調査方法を分ける
- 該当するリクエストが見つからない:まず、ブラウザーやアプリがシステムプロキシを使っているか、または通信がTUNで取り込まれているか確認します。対象の接続が除外されていないか、画面のフィルター条件も確認してください。
- リクエストは表示されるが、DIRECT経由になっている:マッチしたルールと現在の動作モードを確認します。ダイレクト接続のルールに一致している場合、プロキシ画面でノードを変更しても、そのリクエストの経路は変わりません。
- リクエストが表示され、想定したノードを経由している:ログで接続先、DNS、タイムアウトを確認します。同じサブスクリプションを何度もインポートし直す必要はありません。
たとえば対象リクエストのプロキシチェーンの最終結果がDIRECTで、「ノード選択」を経由する想定だった場合は、どのプロキシグループを選ぶルールに一致したか、そのグループがさらにDIRECTを指していないか確認します。接続画面には実際のリクエスト結果が表示され、プロキシ画面にはプロキシグループの現在の選択が表示されます。両方を確認してください。
接続を終了すると、既存のセッションが切断されますが、ルールは変更されません。また、接続一覧に完全な履歴が保存されるとは限らず、短時間のリクエストはすぐに終了することがあります。継続して調べる場合は、問題を再現しながらログを確認しましょう。静止した接続一覧のスクリーンショットだけに頼らないでください。
ルール画面:ルールの順序とマッチ条件を確認する
「ルール」画面では、現在コアに読み込まれているルールを確認できます。ルールモードでは通常、上から順に照合され、最初に一致したルールで使用するポリシーが決まります。確認すべきなのは条件、順序、ポリシー名です。対象ドメインが一覧にあるかどうかだけを検索しても、十分な調査にはなりません。
以下は構文の例であり、既存の設定をそのまま置き換えるためのものではありません。ノード選択は設定内にすでに存在するプロキシグループ名である必要があります。実際に適用する前に、既存ルールやルールセットとの関係も確認してください。
rules:
- DOMAIN,example.com,DIRECT
- DOMAIN-SUFFIX,example.org,ノード選択
- MATCH,ノード選択
DOMAINはドメイン名との完全一致です。例のexample.comは、すべてのサブドメインを自動的に含むわけではありません。DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。たとえばexample.orgとwww.example.orgが対象です。MATCHは他のルールに一致しなかった場合のフォールバックルールです。優先して判定するルールより後ろに配置します。
設定でRULE-SETを使っている場合は、対応するrule-providersが正常に読み込まれているかも確認してください。ルール一覧に参照が表示されても、リモートのルールセットがダウンロード済みとは限りません。ダウンロードエラーはログ画面で確認できます。ルールの変更時は、一時的な編集なのか、サブスクリプション更新後も保持される永続的なオーバーライドなのかを区別してください。
ログ画面:時刻とキーワードでトラブルの範囲を絞る
「ログ」にはコアの動作イベントが記録され、インポート失敗、アクセスのタイムアウト、DNSの問題を調べる際の主な手がかりになります。問題が起きた時刻を記録し、操作をもう一度行って、その時刻付近の対象やエラーを探してください。バックグラウンド更新や他のアプリのリクエストもログに記録されるため、警告を見つけても、それが必ず現在の問題とは限りません。
まず、エラーが発生している層を確認する
| よくあるキーワード | まず確認すること | 次に行うこと |
|---|---|---|
timeout | ノード、接続先、上流サービスのタイムアウト | 失敗したアドレスを確認し、ノードを変えて同じリクエストを再試行 |
lookup、DNS | ドメインの名前解決経路 | 名前解決に失敗したのが接続先のドメインか、ノードサーバーのドメインかを確認 |
yaml、unmarshal | 設定の構文、項目の値の型 | エラーが示す行の前後でインデントと値の型を確認 |
address already in use | 待ち受けアドレスとポートの競合 | ポートを使用中のプロセスを特定するか、競合しないポートに変更 |
ログレベルには通常、info、warning、error、debugなどがあります。画面のフィルターは表示範囲を変え、コアのログレベルは記録される情報量を変えます。コアがエラーのみを出力している場合、画面のフィルターを切り替えても、記録されなかった情報は表示されません。
詳しく調べる場合は、現在のバージョンで利用できるログレベル設定から一時的にdebugを有効にし、問題を一度再現してから通常のレベルに戻します。ログを共有するときは発生時刻、エラーメッセージ、関連する前後の情報を残し、サブスクリプションの認証情報や個人用アドレスを隠してください。「接続に失敗」とだけ切り取っても、どの層の問題か判断するのは困難です。
設定画面:システムプロキシ、TUN、ポートの役割
「設定」にあるネットワーク関連のスイッチで、通信をコアに取り込む方法を指定します。まずコアが正常に動作していることを確認し、システムプロキシとTUNのどちらを使うか決めてください。両者は「通常のノード」と「上級ノード」の違いではなく、無効になったサブスクリプションを自動で修復するものでもありません。
システムプロキシとTUNモード
- システムプロキシ:OSのプロキシ設定にプロキシアドレスを登録します。この設定に従うブラウザーやアプリに適しています。システムプロキシを参照しないアプリは、直接接続を続ける場合があります。
- TUNモード:仮想ネットワークインターフェースと対応するルートを使って通信を取り込みます。より多くのアプリの通信を処理したい場合に適しています。有効化にはサービスモードや管理者権限が必要なことがあります。必要条件はOSやインストール方法によって異なります。
- 両方を有効にする場合:併用が必要かどうかはアプリや設定によって異なります。問題が起きたら、まずどちらか一方の取り込み方式に固定して比較テストしてください。複数の条件を同時に変更しないようにしましょう。
ブラウザーは使えるのに特定のデスクトップアプリだけ接続できない場合は、まずそのアプリがシステムプロキシに対応しているか確認し、必要に応じてTUNを検討します。他のVPNや仮想ネットワークアダプターを使用している場合は、同じスイッチを何度も切り替えるのではなく、ルート、DNS、ネットワークアダプターの競合も確認してください。
混合ポートとLANからの接続
「設定」でポート関連の項目を開き、現在の混合ポートを確認します。画面に7897と表示されている場合、手動でプロキシを設定するアプリには通常、ホスト127.0.0.1、ポート7897を入力し、アプリの要件に合わせてHTTPまたはSOCKSプロキシを選びます。ここでの127.0.0.1は使用中の端末を指し、リモートノードのアドレスではありません。
混合ポートを変更した場合、手動で設定したアプリ側のポートも変更してください。他の端末から、その端末自身の127.0.0.1を使ってこのPCに接続することはできません。LANで共有するには、待ち受けアドレス、LANからの接続許可、ファイアウォールのルールも関係します。このPCだけで使うなら、ブラウザーの問題を調べるためにLAN接続を追加で許可する必要はありません。
初回利用とトラブル対処の手順
画面の使い方に慣れたら、よく行う操作を短い手順にまとめておくと便利です。一度に変更する要素を一つに絞り、同じ接続先で確認しましょう。ノード、モード、DNS、TUNを同時に切り替えるより、原因を特定しやすくなります。
- 設定画面:設定をインポートして有効化し、解析や更新のエラーがないことを確認します。
- プロキシ画面:ルールモードのまま、使用するプロキシグループの出口を選び、遅延テストを一度実行します。
- 設定画面:現在の混合ポートを確認し、利用中のアプリに合った通信の取り込み方法を有効にします。
- 接続画面:新しいリクエストを送信し、表示されることと、ルールやプロキシチェーンを確認します。
- ルール画面:実際の経路が想定と異なる場合は、マッチ条件、順序、フォールバックルールを確認します。
- ログ画面:経路が正しいのに接続できない場合は、発生時刻をもとに名前解決、接続、接続先サービスのエラーを調べます。
続けて学ぶにはクライアントの使い方ガイドをご覧ください。DNS、ルールセット、オーバーライドを調整する場合は、応用設定を参照してください。まずは一つの設定と一つの通信取り込み方式で安定して動作させてから、複雑な設定を追加すると、問題の切り分けがしやすくなります。