Clashのサブスクリプション追加・接続設定ガイド
このガイドでは、サブスクリプションを追加 → プロキシモードを選択 → 接続を有効化 → 動作を確認という手順で進めます。クライアントと利用可能なサブスクリプションがあれば、初回設定と確認に約10分を見込んでください。インストールやサブスクリプションに問題がある場合は、先に該当箇所を解決してから次へ進みます。複雑なルールやネットワークスタックの設定には踏み込まず、再現しやすく、あとから原因を確認しやすい基本設定を目指します。
事前準備:クライアントとサブスクリプションの入手元を確認
Clashエコシステムのクライアントは、設定を読み込み、プロキシコアを実行するための画面を提供します。インストールしただけでは、利用可能なプロキシ回線が使えるとは限りません。先に、信頼できる提供元から入手した、使用中のクライアントに対応するサブスクリプションURLまたは設定ファイルを用意してください。サブスクリプションURLにはアクセス用の認証情報が含まれることが多いため、アカウントのパスワードと同じように管理し、公開コメントや質問用のスクリーンショット、不審なオンライン変換サイトに貼り付けないでください。
まず、プロキシを有効にしていない状態で、デバイスが現在のネットワークに正常に接続できることを確認します。Web認証が必要な公衆ネットワークでは、先に認証を済ませてください。ネットワーク自体が使えないと、サブスクリプションの更新やノードへの接続も失敗することがあります。続いて、システムの通信を制御しているほかのプロキシやVPNツールを終了し、複数のクライアントが同時にシステム設定を変更しないようにします。既存の設定がある場合は、今回の作業前にバックアップしておくと安心です。手順に合わせて過去の設定をすべて削除する必要はありません。
このページでは、クライアントに設定済みの基本項目をそのまま使い、DNSの変更、TUNの有効化、ルールの作成は求めません。見慣れない用語は用語集で確認できます。インストール、オーバーライド、継続的な管理の全体像を知りたい場合は、利用ガイドをご覧ください。初回接続では一度に変更する項目をひとつに絞ると、複数の詳細設定を同時に有効にするより原因を特定しやすくなります。
ステップ1:サブスクリプションを追加して設定を有効にする
Clash Verge Revを開き、左側の「サブスクリプション」を選択します。サブスクリプションURLの入力欄に、サービス提供元から受け取ったURLをすべて貼り付け、「インポート」または追加にあたるボタンをクリックしてください。バージョンによってボタンの位置は異なる場合がありますが、操作するのはノード名ではなく、リモートのサブスクリプションURLです。提供元が複数の形式を用意している場合は、Clashまたはmihomo対応と明記された形式を選び、通常のWebページのURLを設定用URLとして使わないでください。
貼り付けたら、URLがチャットアプリなどで途中までしかコピーされていないか、末尾に空白・改行・句読点が付いていないか確認します。以下はURLの形式を示すだけで、実際の接続には使用できません。実際のURLは利用中のサービス管理画面からコピーしてください。例の一部を書き換えてアクセスしようとしないでください。
https://example.com/sub?token=xxxx
インポートに成功すると、通常はサブスクリプション一覧に設定カードが追加され、名前や更新情報が表示されます。カードを選択し、現在使用する設定として有効にしてください。一覧に追加しただけでは、実行中の設定が自動で切り替わらないことがあります。続いて「プロキシ」画面を開き、プロキシグループと選択可能なノードが表示されているか確認します。一覧が古いままなら、サブスクリプション画面に戻って選択中の項目を確認してから更新してください。同じURLを繰り返し追加して、見分けにくい設定を増やさないようにしましょう。
ローカルの .yaml または .yml ファイルを受け取った場合は、クライアントのファイルインポート機能で選択してから有効にします。ファイルのインポートとリモートサブスクリプションは更新方法が異なり、ローカルファイルは通常、提供元から変更を自動取得しません。設定ファイルにはノードのパスワードが含まれる場合もあります。バックアップや送信の際は共有先を限定してください。編集する前に元のファイルを保存しておけば、変更を取り消せます。
ダウンロード失敗、解析失敗、または一覧が空になる場合は、まずどの段階で失敗したかを切り分けます。ダウンロード失敗ではURL、ネットワーク、サブスクリプションの状態を確認します。解析失敗は、形式が非対応であるか、設定データではなくログインページやエラーメッセージがサーバーから返された可能性があります。ファイル名が表示されただけでインポート成功と判断したり、設定の構文エラーを直すためにプロキシモードを何度も切り替えたりしないでください。まず提供元から対応形式のURLを取得し直し、それ以外のケースはよくある質問のインストール・設定・トラブル対処をご覧ください。
この手順の完了条件:現在のサブスクリプションが有効で、「プロキシ」画面に想定したプロキシグループとノードが表示されていること。確認できたら、接続をどのように振り分けるか決めます。
ステップ2:ルールモードとプロキシグループを選ぶ
「プロキシ」画面を開き、「ルール/全般/直結」のモード切り替えを見つけます。初回は「ルール」を選んでください。ルールモードでは、現在の設定にあるルールの順序に従って接続先が決まります。リクエストによっては直接接続し、別のリクエストは指定されたプロキシグループを経由します。日常利用に適しており、このあとルールが適用されているか確認する際にも便利です。モードを切り替えても、サブスクリプションに不足している内容が補われたり、提供元のノードの状態が変わったりすることはありません。
モードを選んだら、画面に表示されるプロキシグループを確認します。グループ名はサブスクリプションの内容によって異なり、「PROXY」、日本語の名前、その他の独自名称などがあります。ガイドと同じ名前である必要はありません。設定で主に使用する選択グループを見つけ、展開してノードをひとつ選びます。グループの中に別のグループがある場合は、実際に選択する階層まで確認してください。未設定の中間グループで止まらないようにします。クライアントに接続テスト機能があれば、ノード選びの参考にできます。ただし、テスト結果は特定の接続先に対するもので、後述の実アクセス確認に代わるものではありません。
サブスクリプションによっては、自動テストグループが初期選択されています。その場合、無理に手動ノードへ変更する必要はありません。候補があることと、DIRECT または REJECT が選択されていないことを確認してください。前者は直結、後者は接続拒否を意味します。用途別に複数のグループが設定されている場合は、初回は共通のプロキシグループとテストするサービスのグループだけを確認し、ほかはそのままにしておきます。変更を増やしすぎると、原因を追いにくくなります。
| モード | 通信の処理方法 | 今回の設定での推奨 |
|---|---|---|
| ルール | コアに届いた接続を、設定されたルールに従って振り分けます。 | 初回設定と日常利用の基本として使用します。 |
| 全般 | コアに届いた接続を、すべて同じ全般ポリシーで処理します。 | ルールとの比較が必要な場合に限り、一時的に使用します。 |
| 直結 | コアに届いた接続を、プロキシを経由せず処理します。 | プロキシノードの出口確認には使用できません。 |
全般モードにしても、デバイス上のすべてのアプリが自動的に制御されるわけではありません。モードはコアに届いた通信の処理方法を決めるもので、システムプロキシやTUNは通信をコアに届けるための仕組みです。そのため、通信を取り込む入口を有効にしていなければ、全般モードに切り替えてもブラウザーのリクエストが表示されないことがあります。ルールモードでは失敗し、全般モードでは成功する場合は、ルールやプロキシグループを確認する手がかりになります。切り分け後は、必要なルールモードに戻してください。
この手順の完了条件:ルールモードが選択され、対象のプロキシグループでノードまたは自動ポリシーが明確に選ばれていること。次に、確認したいアプリの通信をクライアントに送ります。
ステップ3:プロキシの入口を有効にして接続する
デスクトップでは「設定」またはホーム画面のクイック設定を開き、「システムプロキシ」を有効にします。Clash Verge RevがOSにローカルプロキシの入口を設定すると、システムプロキシ設定に従うブラウザーやアプリが利用できるようになります。クライアントとコアを起動したままにして、テストするブラウザーのページを開き直してください。ウィンドウを閉じてもクライアントがタスクトレイに残っていれば接続が維持される場合がありますが、プログラムを終了した場合はローカルプロキシが応答し続けるとは限りません。
初回設定ではシステムプロキシだけを使い、TUNモードは同時に有効にしないでください。システムプロキシなら、ブラウザーなど一般的なアプリで先に動作を確認でき、仮想ネットワークアダプター、権限、ルーティングによる影響を減らせます。システム設定に従わないアプリがあっても、サブスクリプションが無効とは限りません。基本的な接続を確認してから、アプリの要件に応じてTUNを使うか判断してください。サービスモード、仮想インターフェース、権限について詳しくは、利用ガイドを順にご覧ください。
システムプロキシを有効にしてもすぐオフに戻る場合や、ポートの競合が表示される場合は、ほかのプロキシクライアントが起動していないか確認します。複数のツールにシステムプロキシを同時に制御させたり、内容を把握していないシステムサービスを削除したりしないでください。ローカルで正常に待ち受けていることを確認して初めて、システム側の入口が機能します。クライアントの設定画面に表示されているポートを確認してください。初期値はクライアントや設定によって異なるため、スクリーンショットの数字をそのまま使わず、現在の値を参照します。
アプリごとにプロキシを手動設定する場合、ホストには通常、ローカルループバックアドレスを指定し、ポートにはクライアントに表示されているHTTPポートまたは混合ポートを入力します。以下はローカルの入口設定の例です。ポートはクライアントの値と一致させてください。初回はシステムプロキシを使えばよく、ブラウザーに個別のプロキシ設定を重ねる必要はありません。
ホスト:127.0.0.1
ポート:クライアント設定に表示されたHTTPポートまたは混合ポート
種類:アプリが対応するプロキシプロトコルを選択
スマホ版では通常、デスクトップのようなシステムプロキシ設定を探すのではなく、クライアントのホーム画面で「起動」または「接続」をタップします。初回起動時に、VPN構成の追加やVPN接続の許可を求める画面が表示されることがあります。アプリ名がインストールしたクライアントと一致することを確認してから許可してください。VPNの表示はOSの通信を制御する経路が確立したことを示すもので、リモートノードが利用可能であることを意味しません。許可後も実際にアクセスできるか確認が必要です。
スマホでほかのVPNが動作している場合は、先に切断してから現在のクライアントに戻り、再接続してください。接続後すぐにバックグラウンド動作、DNS、複雑なルーティング設定を変更せず、まずアプリを前面に表示した状態でテストします。会社や学校の管理下にあるデバイスでは、プロキシ設定やVPN権限が制限されている場合があります。デバイスの管理ルールに従って対応してください。スイッチを繰り返し操作しても、ポリシーによる制限は解消できません。
この手順の完了条件:デスクトップではシステムプロキシが有効なまま、スマホではシステム接続が確立済みと表示され、クライアントに起動エラーがないこと。この状態は通信の入口が準備できたことを示すだけです。次に、通信が想定した出口へ実際に送られているかを確認します。
ステップ4:アクセス結果とルールの適用を確認する
ブラウザーに戻り、新しいページを開いて、現在の設定でプロキシ経由になるはずのサイトにアクセスします。続けて、直結になるはずのサイトにもアクセスしてください。設定に合わせて、普段使うサイトを選びましょう。ページが開くかどうかだけで、すべての接続が正しいと判断しないでください。ブラウザーのキャッシュ、既存の長時間接続、サイト側の状態も確認結果に影響します。テスト時はページを再読み込みし、必要に応じて古いタブを閉じて開き直して、異常が出た対象を記録します。
同時にクライアントの「接続」画面を開き、フィルター欄にアクセスしたドメインを入力して、該当する接続が表示されるか確認します。クライアントによっては、詳細に適用ルール、プロキシチェーン、使用したポリシーグループが表示されます。そのドメインがプロキシ経由になる設定なら、記録に想定したプロキシグループとノードが表示されているはずです。DIRECT が適用されている場合は、すぐにプロキシ設定の不具合と決めつけず、設定上それが意図された動作か確認してください。接続時間が短いと記録がすぐ消えることがあるため、ページを更新しながら確認するとよいでしょう。
出口IPアドレスの確認は補助情報として使えますが、それだけを判断材料にしないでください。ルールモードでは接続先ごとに出口が異なるため、IP確認ページにローカルネットワークの出口が表示されても、そのページが直結に設定されているだけの場合があります。より確実に確認するには、対象ドメイン、適用ルール、実際のポリシー、アクセス結果を合わせて見ます。Webページに表示された出口IPだけでは、DNS漏えいの有無も判断できません。個別のテストが必要な場合は、基本接続の確認後によくある質問のDNSに関する説明をご覧ください。接続を確認する前に名前解決の設定を変更するのは避けましょう。
ブラウザーのリクエストがまったく見つからない場合は、ステップ3に戻り、システムプロキシが有効か、ブラウザーで独自のプロキシ拡張機能を使っていないか、アプリがシステム設定に従うかを確認します。接続は表示されるのにタイムアウトする場合は、ステップ2のノード選択を見直し、利用可能と分かっている別の候補に切り替えて試します。すべてのノードで認証エラーや接続エラーが起きる場合は、ステップ1に戻ってサブスクリプションを更新し、サービスの状態を確認してください。TUN、DNS、全般モードを次々に切り替えて対処しようとしないでください。
ログを確認する場合は、まず失敗した時刻を記録してから「ログ」を開き、その前後の記録を探します。「アクセスできない」という結果だけを見るより、設定の読み込みエラー、リモート接続の失敗、ドメイン名の解決失敗を区別すると原因を特定しやすくなります。他の人に相談する際は、クライアント名、OS、失敗した手順、機密情報を伏せたエラー内容を共有してください。サブスクリプションURL、ノードのパスワード、認証情報を含む設定ファイルは公開しないでください。ログレベルを常に最も詳細な設定にする必要はありません。原因を特定したら、通常の設定に戻します。
一時的に全般モードへ切り替えるとサイトにアクセスでき、ルールモードでは失敗する場合、原因はルールの照合か、ルールから参照されるプロキシグループにある可能性が高いです。まずルールモードに戻し、接続の詳細を確認してください。特定のサイトを一時的に使えるようにするために、振り分け設定全体を長期的に変更しないようにしましょう。ルールの詳細な優先順位、オーバーライドの永続化、Fake-IPの応用については、この入門ガイドの範囲外です。詳しくは利用ガイドをご覧ください。
最後に、終了時の操作も確認してください。デスクトップでは、使用を終える前にシステムプロキシをオフにしてからクライアントを終了します。スマホではクライアントの切断ボタンで接続を終了してください。プログラムが異常終了したあとブラウザーで突然アクセスできなくなった場合は、OSのネットワーク設定にローカルプロキシの入口が残っていないか確認します。自動起動の設定は、基本的な接続が安定してから行い、実際に再起動して確認してください。自動起動の成功とプロキシ接続の正常動作は別のものです。