Clash Vergeの使い方

事前準備：クライアントと有効なサブスクリプション

このチュートリアルは、クライアントが正常に起動できる状態から始めます。初回起動後、コアの起動失敗、設定の読み込み失敗、ポートの競合などの表示が続いていないか確認してください。まだインストールしていない場合は、先にインストールを済ませてからこのページに戻ります。この段階ではTUNの有効化やDNSの変更、カスタムルールの追加は不要です。初期設定のままにしておくと、後で問題を切り分けやすくなります。

クライアントは設定を読み込んで通信を処理するソフトウェアであり、それ自体がプロキシサービスではありません。サービス提供元が案内するClashまたはMihomo互換のサブスクリプションURLか、現在のコアで使えるYAML設定ファイルを用意してください。アカウントのログインページや支払いページは、サブスクリプションURLとは別のものです。通常のWebページのURLをクライアントに貼り付けると、形式エラーになることがあります。

作業を始める前に、ネットワーク通信を処理しているほかのプロキシやVPNアプリを終了し、手動で設定したプロキシがあれば内容を控えておきます。サブスクリプションURLにはアカウント情報が含まれる場合があります。パスワードと同じように管理し、公開スクリーンショットやチャットグループ、オンライン変換サイトに載せないでください。トラブル対応ではエラーの種類だけを記録し、設定を共有する前にURL、認証情報、その他の個人情報を削除してください。

ステップ1：サブスクリプションを追加して設定を有効化

Clash Verge Revの左側にある「サブスクリプション」画面を開き、URLの入力欄またはリモートサブスクリプションの追加項目を探します。サービス提供元から案内されたURL全体をコピーし、前後に空白や改行、チャットアプリが付けた句読点がないことを確認してから貼り付けます。名前の入力が必要な場合は、見分けやすい名前を付けてください。名前は画面上のラベルであり、サブスクリプションの内容には影響しません。

「追加」をクリックし、設定のダウンロードと解析が終わるまで待ちます。完了すると、サブスクリプション画面に設定カードまたは登録内容が表示されます。エラー表示のままになっていないことを確認してください。次に設定をクリックして、現在使用する設定に指定します。バージョンによって、カードの選択状態で有効化する場合と、別の有効化操作がある場合があります。ダウンロードできても現在の設定に切り替えていなければ、コアは以前の内容を使い続けることがあります。

続いて「プロキシ」画面を開き、サブスクリプションで定義されたポリシーグループが表示されているか確認します。グループ名は設定によって異なるため、このチュートリアルと同じ名前を探すのではなく、用途やグループ内の選択肢を見て判断してください。グループと選択肢が表示されていれば、追加と設定の読み込みはおおむね完了です。次はアウトバウンドを選び、通信の入口を有効にする必要があります。この段階だけで接続成功と判断しないでください。

ローカルのYAMLファイルを使う場合は、サブスクリプション画面にあるローカルファイルの読み込み項目からファイルを選び、同様に現在の設定として指定します。ローカルからの読み込みは既存の設定を使う場合に便利ですが、ファイルが自動的にリモートサブスクリプションになるわけではありません。サービス提供元がノードを更新した場合は、設定を再取得するか、もともと更新に対応したリモートURLを使用してください。ファイルの拡張子を.yamlに変えただけでは、内容が変換されたことにはなりません。

追加に失敗した場合は、再試行する前にエラーの内容を確認してください。リクエストがタイムアウトした場合は、現在のネットワークからサブスクリプションサービスにアクセスできるか確認します。Webページが返る、または形式に互換性がない場合は、正しいサブスクリプションの種類をサービス提供元に確認してください。認証エラーが表示された場合は、URLの有効期限やアカウントの状態を確認します。URLへのアクセスにプロキシが必要な場合は、すでに使えるネットワーク経路で設定を取得してください。まだ接続できていない設定を使って、この前提条件を解決することはできません。

初回の追加が完了したら、設定カードにある「更新」の場所を確認しておけば十分です。自動更新を頻繁に行う設定は、今すぐ必要ありません。リモート更新ではサービス提供元が公開した内容を再取得しますが、サブスクリプションファイルに直接加えたローカル変更が保持されるとは限りません。ルールを長期的に追加する場合は、クライアントが対応するオーバーライドまたはマージ方法を使います。詳しい構成は設定リファレンスを参照してください。今回はサブスクリプション本来の設定で接続を確認します。

ステップ2：ルールモードとポリシーグループを選択

設定が有効になっていることを確認したら、「プロキシ」画面を開き、ルール、グローバル、ダイレクトの切り替え項目を探します。初めて使う場合は「ルール」を選ぶのがおすすめです。コアは設定内のルールに従って、リクエストを直接接続するか、ポリシーグループなどのアウトバウンドに振り分けます。日常利用に適したモードですが、実際の振り分け範囲は現在の設定によって異なります。モード名だけで、あらゆる用途に合ったルールが自動生成されるわけではありません。

続いて、通常のプロキシ通信を処理するポリシーグループを開きます。手動選択グループではノードを選んでアウトバウンドに指定できます。自動選択グループは設定されたチェック方法に基づいて選択結果を管理します。まずはサブスクリプションの初期設定を使い、手動指定が必要な場合だけ利用可能な項目を選んでください。グループの中に別のグループがある場合は、さらにその選択内容を確認します。プロキシグループを選んだつもりでも、最終的なアウトバウンドがダイレクトになっていることがあります。

ポリシーグループの接続テストを使うと、候補が設定されたテスト先にアクセスできるかを簡単に確認できます。テストに失敗しても、すべての通信が使えないとは限りません。成功しても、あらゆるサイトが開ける保証にはなりません。テスト結果は、特定の宛先に対するその時点のネットワーク状況を示すものです。すべてのノードを何度も測定する必要はありません。候補を一つ選んだら、ブラウザーから実際にアクセスして確認するほうが有益です。

「グローバル」モードでは、コアに入った通常のリクエストが一律にグローバルポリシーグループへ送られます。振り分けの問題を調べるときに一時的に使えますが、グローバルグループで何が選択されているかも確認してください。「ダイレクト」モードでは、コアに入った通信が接続先へ直接つながるため、プロキシ接続の成功を示すものではありません。モードを切り替えても、すべてのアプリが自動的にコアへ接続されるわけではありません。通信の入口は、次の手順で設定するシステムプロキシまたはTUNによって決まります。

ポリシーグループの名前や選択肢の意味が分からない場合は、ルールモードのまま現在の選択を記録し、ルール、DNS、グループの種類を同時に変更しないでください。グローバルモードで一時的にテストする必要がある場合は、テスト後にルールモードへ戻してから再度アクセスを確認します。ルールの優先順位、入れ子のポリシーグループ、カスタム振り分けについては設定リファレンスのルール構文を参照してください。モード選択でよくある疑問はトラブル対処で確認できます。

ステップ3：システムプロキシを有効にして接続

使用する設定とポリシーグループが決まったら、「設定」画面を開き、「システムプロキシ」を有効にします。通常はOSのプロキシアドレスをローカルクライアントの待ち受けポートに向け、システムプロキシに従うアプリからのリクエストをコアへ送ります。デスクトップでは、初回接続に必要な主なスイッチはこれです。チュートリアルを完了するために、すべてのネットワーク機能を有効にする必要はありません。

有効にする前に、コアが正常に動作していることを確認してください。ログに待ち受けポートの競合が表示された場合は、同じポートを使っているほかのプログラムを終了するか、クライアントの設定でポートを変更してから、システムプロキシを再度有効にします。画面に7897などの混合プロキシポートが表示される場合もありますが、実際の値は現在の設定によります。クライアントが別のポートで待ち受けているのに、OSのネットワーク設定へチュートリアル記載の番号だけを手動入力しないでください。

スイッチを有効にしたら、システムプロキシに従うブラウザーを開き、新しいタブからテスト対象のサイトにアクセスします。すでに開いているページは以前の接続を使い続ける場合があるため、新しいリクエストで確認するほうが確実です。ブラウザーにプロキシを個別に制御する拡張機能がある場合は、システム設定を上書きしていないか確認してください。独自のネットワーク処理やプロキシ設定を持つアプリもあり、システムプロキシを有効にしただけでは接続されません。

対象のアプリがシステムプロキシに従わない場合や、より広い範囲のアプリ通信を処理する必要がある場合は、TUNモードを検討します。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、サービスコンポーネントや高い権限が必要になることがあります。クライアントの案内に従って許可を与えてから有効にしてください。OSにネットワーク権限や仮想ネットワークアダプターの確認が表示された場合は、操作元がインストールしたクライアントであることを確認します。権限を付与しないままスイッチを何度も切り替えても、通常は解決しません。

初回の確認では、まずシステムプロキシだけを使い、ブラウザーで安定してアクセスできることを確認してからTUNを個別にテストしてください。一度に変更する要素を一つに絞れます。TUNの実際の対象範囲は、ルーティング、除外設定、DNS、ほかのVPNの影響も受けます。有効にすればすべてのアプリが必ずプロキシを経由するわけではありません。ネットワークに接続できないときに、TUN、LAN接続、複数のDNS設定を一度に有効にしないでください。設定を増やすほど原因を特定しにくくなります。

モバイルでの接続手順はデスクトップと異なります。設定とポリシーグループを選んだら、アプリのホーム画面で接続を開始し、OSのVPN設定への許可を承認してから、アプリに戻って接続状態を確認してください。許可を拒否した場合は、サブスクリプションを何度も追加し直すのではなく、OSの権限とVPN設定を確認します。システムプロキシが効かない、TUNの権限付与に失敗する、特定のアプリだけ通信できないといった詳しい対処はトラブル対処を参照してください。このページでは、開始したリクエストの確認を続けます。

ステップ4：ルールの適用とアクセス結果を確認

まず実際にアクセスして、基本的な接続を確認します。現在のルールでプロキシ経由になるサイトを開き、次に直接接続する想定のサイトを開いて、どちらも正常に表示されるか確認してください。対象サイトが現在の設定でどの経路を通る想定なのか把握しておきましょう。どちらも開けたとしても、予定どおりに振り分けられたか分からない場合があります。クライアントのアイコンの色やスイッチの表示だけで確認を終えないでください。

クライアントの「接続」画面に戻り、Webページへ再アクセスしながら、該当するドメインや接続先を探します。接続の詳細を開ける場合は、適用されたルール、経由したポリシーグループ、最終的に使われたアウトバウンドを確認してください。接続一覧には現在のアクティブな通信しか表示されず、短いリクエストは終了後に消える場合があります。先に接続画面を開いてから対象ページを再読み込みしてください。ページのキャッシュが使われると、更新しても新しいリクエストが発生しないことがあります。

接続履歴にダイレクトと表示された場合、まずルールの想定と一致しているか確認します。ルールモードでは、サイトによっては直接接続が正常な結果であり、システムプロキシの不具合とは限りません。本来プロキシ経由になる接続がダイレクトになっている場合は、ルールとポリシーグループの選択を見直してください。ブラウザーからリクエストが続いているのに関連する接続がまったく表示されない場合は、ほかのプログラムがシステムプロキシを上書きしていないか、ブラウザーに個別の設定がないか、リクエストが実際にクライアントを経由しているかを優先して確認します。

出口IPの確認は補足情報として使えますが、それだけで判断することはできません。確認サイト自体もルールによって振り分けられ、表示されたアドレスが示すのはそのリクエストの出口だけです。ほかのサイト、IPv6のリクエスト、取り込まれていないアプリは別の経路を通ることがあります。対象ページへのアクセス結果、対応する接続履歴、実際のアウトバウンドをあわせて確認するほうが確実です。IP確認ページのスクリーンショットだけで、端末のすべての通信が取り込まれていることを証明することはできません。

テストに失敗した場合は、順番に戻って確認します。まず現在のサブスクリプションとポリシーグループ、次にシステムプロキシとコアの状態、最後に該当リクエスト前後のログを確認してください。エラーが発生した時刻、対象ドメイン、短いエラーメッセージを記録すると、接続タイムアウト、名前解決の失敗、認証エラー、ルール選択の問題を切り分けやすくなります。変更は一度に一つだけ行い、その都度リクエストを再送します。ブラウザーに証明書の警告が表示された場合は、機密情報を入力せずに原因を調べてください。警告を無視して確認を進めないでください。

確認が終わったら、日常利用に適したルールモードを維持し、テスト済みのポリシーグループを選んだ状態にします。OS起動時の自動起動やサイレント起動は、アプリの起動方法に関する設定であり、ログインのたびにシステムプロキシが期待どおりの状態になるとは限りません。有効にした場合は実際に再起動して確認してください。クライアントを終了するときは、システムプロキシがオフになったことを確認します。異常終了後にブラウザーが通信できなくなった場合は、OSのネットワーク設定にローカルプロキシの指定が残っていないか確認してください。

次のステップ：設定の更新と変更内容の保持

サービス提供元がノードやルールを変更した場合は、「サブスクリプション」画面から現在のリモート設定を手動で更新できます。更新後は、以前選択したポリシーグループを再確認してください。ノード名が変わると、以前の選択が無効になる場合があります。更新に失敗しても既存の設定が使えるなら、現在の動作状態を保ち、サブスクリプションサービスの状況を確認してから対処してください。設定全体をすぐに削除して最初からやり直す必要はありません。

ドメインの振り分けを継続的に追加したり、DNSを調整したり、ローカルルールを管理したりする場合は、まず設定リファレンスを読み、サービス提供元の設定、クライアントが生成する項目、ローカルのオーバーライドを区別してください。通信がときどき切れる、特定のアプリだけアクセスできないといった場合は、症状に応じてトラブル対処を確認します。今回動作を確認した基本設定を比較の基準として残しておくと、高度な設定をいくつも同時に試すより、変化の原因を特定しやすくなります。