開始前の準備：クライアントのインストールとサブスクリプションの用意

インストール済みで起動できるクライアントと、サービス提供元から案内されたClashまたはmihomo形式のサブスクリプションURLを用意します。クライアントは設定を読み込み、カーネルを実行してリクエストを取り込みます。ソフトをインストールしただけでは、利用可能なノードは作成されません。サブスクリプションの用途をアカウントページ、購入履歴、または提供元の案内で確認してからURLをクライアントに追加してください。通常のWebページURL、アカウントのログインページ、個別ノードの共有リンクは、そのまま完全な設定としてインポートできるとは限りません。

Linuxでは、まず下のコマンドを実行してCPUアーキテクチャを確認できます。出力がx86_64なら通常はamd64またはx64、aarch64なら通常はarm64に該当します。インストールパッケージはディストリビューションにも合わせてください。Debian系やUbuntu系ではDEB、FedoraなどではRPMが一般的です。対応アーキテクチャはダウンロードページに掲載されたファイルを確認し、拡張子だけで判断しないでください。GUIクライアントはディストリビューションのパッケージ管理ツールでインストールし、アプリケーションメニューから起動します。

uname -m

初回設定では、ほかのプロキシクライアントのシステムプロキシや透過プロキシ機能をオフにし、ローカルポートの競合やデスクトップのプロキシ設定の書き換えを防ぎます。現在のネットワークのゲートウェイやDNS設定は維持し、ルーターも同時に変更しないでください。ここでは、ルールモード、接続先を1つに固定、システムプロキシという最短の確認手順を使います。現在のネットワークで通常のWebページも開けない場合は、まず基本的なインターネット接続を復旧してからインポートしてください。

手順1：サブスクリプションを追加して設定を有効にする

Clash Verge Revを開き、サイドバーから「サブスクリプション」または「設定」ページに移動します。サブスクリプションURLの入力欄に提供元から案内された完全なURLを貼り付け、「インポート」をクリックします。URLにクエリパラメーターが含まれる場合は省略せず、コピー時にチャットの引用符、改行、末尾の句読点を含めないでください。インポートが完了するまで待ち、同じ設定が複数作成されないよう連続してクリックしないでください。

インポートが成功すると、通常は設定名や更新メニューを含む設定カードが表示されます。カードをクリックするか、メニューから有効化して現在の設定にします。選択状態の表示はバージョンによって異なり、枠線、チェックマーク、現在の設定を示すメッセージなどがあります。ファイルのダウンロード成功だけでは不十分です。この設定が実際に使用中であることを確認してください。続いて「プロキシ」ページを開き、ポリシーグループと選択可能なノードが表示されていることを確認します。

提供元からローカルのYAMLファイルを受け取った場合は、設定ページのファイルインポート機能で選択し、有効化してください。ファイルにはクライアントが読み込める形式の設定が必要です。通常のテキストファイルの名前をconfig.yamlに変えても、ノードが自動で作られるわけではありません。リモートのサブスクリプションは設定カードから更新できることが多い一方、ローカルファイルには更新元が含まれない場合があります。それぞれの管理方法を区別してください。

インポートに失敗したら、まずエラーの種類を確認します。ダウンロードのタイムアウトは、クライアントがまだ内容を取得できていない状態です。形式エラーや解析エラーは、取得した内容を設定として読み込めないことを示します。アカウントの無効を示すメッセージが出た場合は、提供元のページで状態を確認してください。ブラウザーでサブスクリプションのURLにアクセスできるか確認しても構いませんが、URLを公開オンライン変換サービスに貼り付けたり、応答内容を公開したりしないでください。問い合わせる際はエラーの種類だけを伝え、URL、アカウント情報、ノードの認証情報を隠してください。

この手順の完了条件は、現在の設定が選択され、「プロキシ」ページに設定で定義されたポリシーグループとノードが表示されていることです。設定カードがあるのに一覧が空の場合は、設定が本当に有効になっているか、サブスクリプションにProviderの内容しか含まれていないかを確認してください。Providerの参照関係は設定レベルの問題です。詳しくは設定ファイルリファレンスを確認してください。一覧が空のままシステムプロキシを何度も切り替える必要はありません。

手順2：ルールモードとプロキシノードを選ぶ

設定を有効にしたら、ホーム画面または「プロキシ」ページで動作モードを探し、まず「ルール」またはRuleを選びます。ルールモードでは、現在の設定に従ってカーネルに入ったリクエストの接続方法（直接接続、プロキシ、その他のアクション）が決まります。各リクエストに適用されたルールを後で確認できるため、最初の設定に適しています。すべてのリクエストを1つの接続先に送る必要はありません。

次に、プロキシの接続先を決めるポリシーグループを探します。グループ名はサブスクリプション設定によって異なり、「プロキシ選択」「Proxy」などさまざまです。決まった名前のボタンがあるわけではありません。グループをクリックして候補を表示し、まず接続先が明確なノードを選びます。候補自体が別のポリシーグループなら、さらに展開して具体的なノード、または想定どおりの自動選択グループに到達することを確認してください。DIRECTは直接接続を意味し、プロキシノードではありません。

画面に遅延テストのボタンがあれば、応答しない候補を絞り込む目安として使えます。ただし、テスト結果はWebサイトにアクセスできることを保証しません。テスト先、ノードのプロトコル、対象サイトが異なれば、実際の結果も変わります。初回のトラブルシューティングでは接続先を1つに固定し、後述のリクエスト確認まで進めてください。ノード、モード、DNSを同時に変更すると、原因を特定しにくくなります。

ルール・グローバル・直接接続の違い

「グローバル」またはGlobalでは、カーネルに入った通信にグローバルポリシーグループが適用されます。特定のWebサイトへの接続がルール選択の影響を受けているか、短時間で切り分けたい場合に使えます。切り替えた後は、グローバルポリシーグループで選択されている接続先も確認してください。ルールモードの接続先と同じとは限りません。「直接接続」またはDirectでは、カーネルに入ったリクエストを直接接続させ、比較確認などに一時的に使います。グローバルモードでもすべてのアプリが自動的に対象になるわけではなく、カーネルに入っていない通信はモードを切り替えても取り込まれません。

モードの選択と通信を取り込む方法は別の設定です。ここではルールモードのままにし、選択したポリシーグループと接続先を控えてください。次の手順でシステムプロキシを使い、ブラウザーのリクエストをカーネルに送ります。ポリシーグループ、ルールの適用、DIRECTの意味が分からない場合は用語集を確認してください。ルールの構文全体は設定リファレンスを参照できます。初回接続時にルールを1つずつ書き換える必要はありません。

手順3：システムプロキシを有効にして接続する

クライアントのホーム画面または設定画面に戻り、カーネルが実行中であることを確認してから、「混合ポート」またはMixed Portを探します。以降のコマンドでは7890を例に使いますが、実際のポート番号はクライアントの表示に従ってください。混合ポートはHTTPとSOCKSのプロキシ接続を受け付けます。ブラウザーやターミナルからこの入口にリクエストを送ることで、カーネルが選択済みのモードに従って処理できます。

クライアントの「システムプロキシ」をオンにします。Linuxのデスクトップ環境では、通常、デスクトップセッションのプロキシ設定が変更されますが、各アプリがその設定に従うかどうかはアプリの実装によります。システム設定のネットワークプロキシ画面を開き、アドレスが127.0.0.1、ポートがクライアントと同じ値であることを確認してください。ブラウザーでプロキシ拡張機能を個別に設定している場合は、システムプロキシを使うか、同じアドレスとポートを明示して、古いクライアントを参照し続けないようにします。

ここでブラウザーの新しいタブを開き、テスト対象のWebサイトにアクセスします。古い接続が長時間維持される場合は、該当するタブを閉じて開き直し、必要ならブラウザーも再起動してください。クライアントのシステムプロキシをオンにしたことは、デスクトップ設定の変更が要求されたことを示すだけで、すべてのアプリがプロキシを使っているとは限りません。次の手順では、スイッチの色ではなく、ローカルポートの待ち受けと実際のリクエストを確認します。

ターミナルではコマンドごとにプロキシを指定する

ターミナルのプログラムは通常、デスクトップのシステムプロキシを自動では読み取りません。初回確認ではcurl --proxyで接続先を明示すればよく、すぐにシェルの起動ファイルを変更する必要はありません。この方法なら今回のコマンドだけに適用され、直接接続の結果とも比較しやすくなります。クライアントの混合ポートが7890以外の場合は、下のコマンドのポート番号を置き換えてください。curlがインストールされていない場合は、ディストリビューションのパッケージ管理ツールでインストールしてから実行します。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  -I https://example.com/

初回接続ではTUNを有効にしない

TUNは仮想ネットワークデバイスを使って通信を取り込み、システムプロキシに従わないアプリに適しています。一方で、権限、ルーティング、DNSの設定も必要になります。初回はTUNをオフのままにし、ブラウザーとプロキシを明示したコマンドで接続を確認してから、必要かどうかを判断してください。Clash Verge RevのTUNには通常、対応するサービスと権限が必要です。クライアントに用意されたサービスのインストールまたは権限付与機能を使い、機能を有効にするためだけにGUIクライアントをrootで常時実行しないでください。

後からTUNを有効にする必要がある場合は、先にほかのVPNや透過プロキシをオフにし、クライアントのサービスが正常であることを確認してから有効にして再テストします。コンテナー、リモートデスクトップ、サーバーではネットワーク経路が異なる場合があります。特に、リモートセッションからデフォルトルートを変更しないでください。tun.stack、DNSのハイジャック、ルートの除外設定については設定リファレンスを参照してください。今回の最短接続手順では必須ではありません。

手順4：ポート、リクエスト、ルールの適用を確認する

確認は3段階で行います。まずカーネルがポートを待ち受けていること、次にプロキシ経由のリクエストに応答があること、最後にブラウザーが想定した経路を実際に使っていることを確認します。それぞれの確認は代わりにはなりません。ポートが開いているのはローカルの入口が有効というだけで、Webサイトが表示されても直接接続の結果かもしれません。コマンドの出力とクライアントの接続記録を照合し、設定が反映されているか確認してください。

まずローカルポートを確認する

Linuxのターミナルで下のコマンドを実行します。ポート番号が異なる場合は検索条件を変更してください。正常なら、LISTENと該当するアドレス、ポートを含む行が表示されます。何も表示されない場合は、クライアントに戻ってカーネルが起動しているか、別のポートを使っていないかを確認し、起動ログのエラーも確認してください。この時点ではリクエストがノード選択まで到達していないため、ノードを先に変更しないでください。

ss -lnt 'sport = :7890'

ポートが使用中と表示された場合は、古いクライアントや別のmihomoプロセスが実行中か確認してください。見覚えのないプロセスをむやみに終了しないでください。古いクライアントだと確認できた場合は終了するか、現在のクライアントで未使用のポートに変更します。変更後はブラウザー設定とテストコマンドの両方を更新し、ポート番号を一致させてください。通常、初回のローカル利用でLANからの接続を許可する必要はありません。

次にプロキシを明示したリクエストを確認する

前の手順で示したcurlコマンドを実行し、HTTPレスポンスヘッダーが返るか確認します。HTTPプロキシ経由でHTTPSにアクセスする場合、まずトンネル確立の応答が表示され、その後に対象サイトの応答が返ることがあります。トンネルの確立だけでは、対象ページが返されたとは判断できません。対象サイトが403などを返した場合は拒否応答を受け取った状態であり、すぐにポート障害と判断しないでください。証明書エラーではシステム時刻、証明書環境、具体的なエラー内容を確認します。問題を隠すために証明書検証を無効にしないでください。

ここでのexample.comはテスト方法を示すための例です。応答が返っても、すべてのサイトにアクセスできることや、リクエストがリモートノードを経由したことを意味しません。次に実際にアクセスしたいサイトのアドレスに置き換え、クライアントの「接続」またはログ画面を開きます。該当するドメインを探して、適用されたルール、ポリシーグループ、最終的な接続先を確認してください。DIRECTと表示される場合、そのリクエストはカーネルによって直接接続が選択されています。

最後にブラウザーとターミナルの違いを確認する

プロキシを明示したcurlでは対象サイトから応答があるのにブラウザーで失敗する場合は、ブラウザーがシステムプロキシに従っているか、プロキシ拡張機能が設定を上書きしていないか、古いタブが以前の接続を再利用していないかを確認してください。反対にブラウザーではアクセスできるのに通常のターミナルコマンドが失敗する場合は、サブスクリプションを再インポートするのではなく、まずターミナルの環境変数を確認します。アプリによって通信を取り込む入口は異なります。テストでは同じサイトを使ってください。

ポートが正常でもプロキシを明示したリクエストがタイムアウトする場合は、同じポリシーグループ内で別のノードに変更して再テストし、接続失敗や名前解決エラーがログにないか確認してください。一部のサイトだけ利用できない場合は、ルールとDNSを確認します。「ポート → プロキシ設定 → DNS → ルール → ノード」の順に調べ、複数の条件を一度に変更しないでください。詳しい切り分け手順はトラブルシューティングを参照してください。

終了方法、更新、次回の起動

一時的に利用を停止する場合は、クライアントでシステムプロキシをオフにします。TUNを有効にしている場合は、先にTUNもオフにしてから終了してください。プロセスを直接終了すると、デスクトップのプロキシ設定がローカルポートを参照したまま残り、クライアントを終了した後にブラウザーでWebページを開けなくなることがあります。その場合はシステムのネットワークプロキシ画面で元の設定に戻し、ネットワークを確認してください。すぐにクライアントを再インストールする必要はありません。

次回起動したら、現在の設定とポリシーグループの選択が保持されているか確認し、必要な通信の取り込み方法を有効にします。サブスクリプションは設定カードの更新メニューから更新できます。更新後にノード名が変わった場合は、ポリシーグループの選択を確認し直してください。サブスクリプションの自動更新とクライアントのソフトウェア更新は別の操作です。前者は設定の取得元を更新し、後者はアプリケーションを更新します。一方をもう一方の完了と見なさないでください。

これで日常利用の基本手順は完了です。YAMLの項目、Provider、オーバーライド、マージについては設定ファイルリファレンスを、画面に出てくる用語を確認したい場合は用語集を参照してください。動作している設定を比較用に残し、変更は一度に1項目に絞って、同じサイトで再テストすると、その後の原因特定が容易になります。

Clash Verge Revの使い方サブスクリプションの追加と接続確認