ステップ1：サブスクリプションを追加して設定を有効にする
Clash Verge Revを開き、左側の「サブスクリプション」を選択します。サービス提供元の管理画面で、ClashまたはMihomo向けと明記されたサブスクリプションURLをコピーしてください。通常はURL全体を使います。ログインページや共有ページのURL、個別のプロキシプロトコルのリンクとは異なります。サブスクリプションURLにはアクセス情報が含まれる場合があります。使用するクライアント以外には貼り付けず、公開チャットやスクリーンショット、問い合わせ内容にも載せないでください。
URLを貼り付け、追加が完了するまで待つ
サブスクリプションURLの入力欄を探します。画面に追加ボタンだけが表示されている場合は、まずプラスボタンを押し、URLから追加する項目を選んでください。URL全体を貼り付けたら、先頭と末尾を確認し、コピー時に混入した空白、改行、引用符を削除してから「追加」を実行します。ダウンロードと解析が終わるまで待ちます。成功すると、サブスクリプション画面に設定カードが追加され、名前や更新、編集などの操作が表示されます。表示名はサブスクリプションの内容やクライアントによって異なるため、この記事の例と一致しなくても問題ありません。
追加後は、その設定が現在使用する設定として選ばれていることも確認します。カード、または有効化の操作をクリックし、選択中の表示が出たことを確認してください。次に「プロキシ」画面を開き、ポリシーグループが表示されるか確認します。サブスクリプション画面にカードが表示されただけでは、コアがその設定を読み込んだとは限りません。プロキシ画面が空の場合は、サブスクリプション画面に戻って選択状態を確認し、ログ画面で解析エラーや設定の読み込み失敗がないか調べます。システムプロキシの切り替えはまだ行わないでください。
ローカルファイルとサブスクリプション更新の違い
ローカルの.yamlまたは.ymlファイルを受け取った場合は、追加メニューからファイルのインポートを選び、ファイルを指定して現在の設定にします。ファイルには実行可能な完全な設定が必要です。ルール数行やDNS設定だけの断片は、完全なサブスクリプションの代わりにはなりません。ローカルファイルは通常、サービス提供元の更新に自動追従しません。新しいファイルを受け取ったら再インポートするか、クライアントが対応する方法で置き換えてください。
URLから追加できない場合は、まずサブスクリプションが有効か、アカウントの期限が切れていないか、現在のネットワークからサーバーにアクセスできるかを確認します。ログを開き、接続タイムアウト、サーバーによる拒否、YAML解析エラーを区別してください。前の2つはURLとネットワークを確認し、解析エラーの場合はログイン画面ではなく正しい形式のデータを取得しているか確認します。サブスクリプションURL全体を、信頼できない変換サイトに入力しないでください。提供元から更新前にプロキシ経由の接続を求められた場合は、すでに利用可能な接続を使います。設定前の新しいサブスクリプションだけで接続できるとは限りません。
最初の接続が確認できたら、カードの「更新」からリモートの変更を取得できます。リモートのサブスクリプションを直接編集すると、更新時に変更が上書きされる場合があります。まずは標準設定のままにし、ポート、DNS、ルールの変更は後回しにしてください。カスタム設定を継続して使う場合は、応用ガイドのローカル上書きと複数サブスクリプションの統合をご覧ください。この手順の完了条件は、設定カードが選択済みで、プロキシ画面に想定したポリシーグループが表示され、ログに設定の読み込みを妨げるエラーがないことです。
ステップ2：ルールモードとプロキシの出口を選ぶ
設定が有効になったら、クライアントの動作モード切り替えを開き、「ルール」に設定します。バージョンによってはトップ画面やプロキシ画面に切り替え項目があり、Ruleと表示される場合もあります。ルールモードでは、設定内のルールに従ってリクエストを直接接続、プロキシ経由、または拒否に振り分けます。初めて使う場合は、サブスクリプションの振り分け設定をそのまま活用できます。すべてのサイトについてプロキシの要否を自動判定するモードではなく、実際の動作は現在の設定とポリシーグループの選択によって決まります。
先にモードを選び、次にポリシーグループ内の出口を選ぶ
「プロキシ」画面で、サブスクリプション設定の主要な通信を処理するポリシーグループを探します。「プロキシ選択」「ノード選択」などの名前や、サービス提供元独自の名称が付いている場合があります。名前だけで用途を判断しないでください。グループを開き、接続先が具体的な出口なのか、自動選択やフェイルオーバーのポリシーグループなのか確認します。手動選択のグループでは候補を選び、選択中の表示を確認してください。選んだものが階層化されたグループの場合は、さらに開いて、最後に実際に利用可能な出口が選ばれていることを確認します。
クライアントに接続テスト機能がある場合は、現在のグループで一度実行し、参考情報として利用できます。テスト成功は、その時点でテスト先に到達できたことを示すだけで、すべてのサイトに接続できる保証にはなりません。テスト失敗も、テスト先が制限されているための場合があります。初回確認では利用可能と分かっている出口を選び、複数のグループを同時に変更しないようにしてください。プロキシ画面に直接接続しかない、または候補がまったくない場合は、TUNを有効にするのではなく、前の手順に戻ってサブスクリプションの内容を確認します。
ルール、グローバル、直接接続の違い
「グローバル」は通常、通信をグローバル用のポリシーグループに送りますが、グループ内で出口を正しく選ぶ必要があります。グローバルに切り替えただけで、利用可能な接続先が自動的に見つかるわけではありません。「直接接続」ではプロキシを経由せず、復旧や比較確認に使います。初めて使う場合はルールモードのままにしてください。出口が使えることを確認済みで、ルールのマッチングに問題があるかを切り分けたい場合に限り、一時的にグローバルへ切り替えて比較し、テスト後にルールモードへ戻します。
ここで設定するプロキシモードと、次の手順で設定する通信の取り込み方法は別のものです。ルールモードは「コアに届いたリクエストをどう処理するか」を決め、システムプロキシとTUNは「どのリクエストをコアに渡すか」を決めます。そのため、ルールモードを選んでも通信の取り込みを有効にしていなければ、ブラウザーは従来のネットワークを使うことがあります。逆に、TUNを有効にしてもポリシーグループの選択は不要にならず、無効なサブスクリプションも修復されません。次に進む前に、モードがルールで、メインのポリシーグループに有効な出口が選ばれていることを確認してください。
自動選択、負荷分散、ルールの優先順位、ルールセットのサブスクリプション管理は、初回接続時にすべて調べる必要はありません。現在選択しているグループと出口を控えておき、必要になったら応用設定ガイドの該当箇所を参照してください。確認前に複数の条件を一度に変更しないようにしましょう。
ステップ3：システムプロキシを有効にしてリクエストを送信する
トップ画面または「設定」画面に戻り、まずMihomoコアが停止中ではなく、エラーを繰り返していないことを確認します。次に「システムプロキシ」のスイッチを探して有効にしてください。システムプロキシは、その設定に対応したアプリをクライアントのローカル待ち受けポートに接続します。クライアントのウィンドウを開いているだけでは、スイッチは有効になりません。有効にしたら、普段使うブラウザーで新しいページを開き、クライアントで確認できるリクエストを発生させます。
初回接続では標準ポートを変更しない
ポート設定にMixed Port（例：7897）と表示されることがあります。チュートリアルの値に合わせて変更する必要はなく、現在のクライアントに設定されている値を使ってください。システムプロキシの接続先アドレスとポートは、動作中のコアが待ち受けている設定と一致している必要があります。以前ほかのプロキシツールを使っていた場合、システムに古いポートが残っていることがあります。Clash Verge Revのシステムプロキシをいったんオフにしてから再度オンにし、設定を書き直してください。別のツールのシステムプロキシも同時に有効にしないでください。
有効にした直後にブラウザーでページを開けなくなった場合は、まずシステムプロキシをオフにして、通常のネットワークに戻るか確認します。次にログを確認し、ポートの競合、コアの起動失敗、接続拒否がないか調べてください。ポートが競合している場合は、ほかのプログラムが動作中なのか、同じクライアントを複数起動しているのか確認します。ポートを手当たり次第に変更しないでください。変更すると、手動プロキシを使うアプリの接続先も合わせる必要があり、確認範囲が広がります。サブスクリプションが有効で、コアが動作し、ポートが待ち受けていることを確認してから、システムプロキシを再度有効にします。
アプリがシステムプロキシを使わない場合はTUNを検討
独自のプロキシ設定を持つアプリや、システムプロキシに従わないアプリがあります。ブラウザーでは問題ないのに特定のアプリだけ従来のネットワークを使う場合は、まずそのアプリがHTTPまたはSOCKSプロキシの個別設定に対応しているか確認してください。より広い範囲の通信を取り込む必要がある場合は、Clash TUNモードを検討します。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。サービスのインストール、管理者権限の付与、ネットワーク拡張の許可が必要な場合があり、表示される案内はOSやクライアントのバージョンによって異なります。
TUNを有効にする前に、動作を確認済みのシステムプロキシ設定を残しておきます。クライアントの案内に従ってサービスと権限の設定を済ませてからTUNを有効にし、ログを確認してください。初回の比較では通信の取り込みスイッチを一度に1つだけ変更し、複数のツール、仮想ネットワークアダプター、手動ルートを重ねないようにします。TUNで通常のネットワークに問題が起きた場合は、TUNをオフにして元の状態に戻してください。あらゆるネットワーク障害に使える修復スイッチではありません。Fake-IP、ルーティング、DNSの詳細は、応用ガイドを参照してください。
モバイル端末では、設定を追加して選択した後、「起動」または接続ボタンから通信の取り込みを開始します。Androidでは初回にシステムのVPN接続要求が表示されます。内容を確認して許可し、システム上で接続状態になったことを確認してください。iOSでは使用するクライアントの案内に従ってVPN構成を追加し、許可します。ほかのVPNに接続中の場合は、先に競合を解消してください。システムに接続中と表示されても、通信の取り込みが始まったことを示すだけです。出口に到達できるかは、次の手順で確認します。
ステップ4：通信経路と実際のアクセスを確認する
スイッチの色や「実行中」という表示だけで、設定が成功したと判断しないでください。まず、現在のルールでプロキシ経由になる想定のページを開き、次に直接接続する想定のページを開きます。ブラウザーのキャッシュだけを表示しないよう、新しいタブでページを開いて再読み込みしてください。その後「接続」画面を開き、先ほどのリクエストに対応するドメインまたは宛先を探します。適用されたルール、経由したポリシーグループ、最終的に選ばれた出口を確認してください。
アクセス結果と接続ログを照合する
ページが正常に開き、接続画面にも想定どおりのルールとポリシーの経路が表示されれば、根拠をもって動作を確認できたことになります。リクエストにDIRECTと表示される場合は、現在のルールに従って直接接続されたという意味で、必ずしも障害ではありません。そのサイトが本来どの経路を通る想定かを踏まえて判断してください。バージョンによっては、接続終了後すぐに記録が削除されます。ページを更新しながら接続画面を確認するか、クライアントの接続履歴を利用してください。一覧が一時的に空でも、すぐにクライアントを再インストールする必要はありません。
ブラウザーが読み込み中のままなのに、接続画面に該当リクエストがない場合は、システムプロキシが有効か、ブラウザー独自のプロキシ拡張機能を使っていないか、リクエストが実際に送信されたかを確認します。接続記録があり、最終的な出口が想定と異なる場合は、ステップ2に戻ってルールモードとポリシーグループの選択を確認してください。出口が正しいのに接続できない場合は、ログでタイムアウト、拒否、解析エラーを調べます。「リクエストが取り込まれたか → 経路が正しいか → 宛先に到達できるか」の順に確認すると、DNS、ポート、TUNを同時に変更するより原因を絞り込みやすくなります。
グローバルIPの出口とDNSは分けて確認する
グローバルIPの出口を確認する場合は、信頼できるIP確認サービスを使い、通信の取り込みをオフにした場合とオンにした場合を比較できます。ただし、確認ページ自体もルールによる振り分けの影響を受けます。直接接続に振り分けられた場合、通常のネットワークの出口が表示されても問題ありません。ブラウザーのプロキシ設定で分かるのは、そのブラウザーの通信経路だけで、すべてのアプリの状態を示すわけではありません。確認ページに表示された地域だけを見て、端末全体の通信が同じ方法で処理されていると判断しないでください。
Webページにアクセスできても、DNSリークの確認が済んだとは限りません。ブラウザーのセキュアDNS、OSの名前解決、クライアントのDNS、TUNによる取り込み範囲はそれぞれ異なる場合があります。初期設定では、普段使うページが正常に開き、接続記録の内容を説明できることをまず確認してください。DNSを分離する明確な要件がある場合は、応用設定ガイドのDNSとTUNの章を参照して個別にテストします。出所の分からないDNS設定をまとめてコピーし、現在のサブスクリプションに上書きしないでください。
利用を終えるときは、通常のネットワークに戻ることを確認する
動作を確認できたら、現在の設定名、モード、メインのポリシーグループ、通信の取り込み方法を記録しておくと、問題が起きたときに基準に戻せます。利用を停止する場合は、まずシステムプロキシまたはTUNをオフにしてから、必要に応じてクライアントを終了します。プロセスを強制終了すると、システムプロキシがローカルポートを指したままになることがあります。オフにした後、普段使うページに再度アクセスし、通常のネットワークに戻ったことを確認してください。接続できない場合は、ソフトウェアを何度も再インストールするのではなく、システムのネットワーク設定に手動プロキシが残っていないか確認します。
OS起動時の自動起動と、起動後にシステムプロキシを自動で有効にする設定は別です。初回の動作確認が終わってから、日常の使い方に合わせて有効にしてください。次回のOSログイン後にも簡単な確認を行います。サブスクリプション更新後に動作が変わった場合も、すべての手順をやり直す前に、現在の設定とポリシーグループを確認します。これでサブスクリプションの読み込み、出口の選択、コアへのリクエスト取り込み、実際の経路の確認が完了し、初期設定は終了です。