基本設定は約10分で完了

Clash Vergeのインストールと接続ガイド

サブスクリプションの導入、プロキシモードの選択、接続の確立、結果確認の4ステップで進めます。この記事では初回利用に必要な手順に絞り、プロトコルの違い、コアの関係、高度な選択についてはプロトコルリファレンスで確認できます。

01 サブスクリプション導入
02 モード選択
03 接続を確立
04 結果を確認

準備段階

開始前の確認:クライアント、サブスクリプションURL、システム時刻

設定を始める前に、クライアントが正常に起動できることを確認します。デスクトップ版では、起動後にコアの状態、設定への入口、またはプロキシへの入口が表示されるはずです。モバイル版の初回起動時には、システム接続の許可に関する説明が表示されることがあります。この段階ではすぐに有効にせず、サブスクリプションとポリシーを選んでから許可すると、画面を行き来せずに済みます。起動時にコアファイルが利用できない、権限が不足している、ポートが使用中などのエラーが出る場合は、先に起動問題を解決してから設定を導入してください。

サービス提供元から発行されたサブスクリプションURLを用意します。URLは通常、https://で始まる完全なリンクです。ページタイトルだけをコピーせず、URL全体をそのままコピーしてください。前後に空白や改行を残さないことも重要です。提供元によって複数の形式が用意されている場合は、Clash、Mihomo、またはClash Metaに対応すると明記された形式を選びます。通常の共有リンクとサブスクリプションURLは用途が異なります。貼り付け後に1つのノードしか生成されず、プロキシグループが表示されない場合は、完全なサブスクリプションではない可能性があります。

続いて、デバイスの日付、時刻、タイムゾーンが正しいか確認します。サブスクリプションサーバーとの安全な接続、一部プロトコルのハンドシェイク、設定の更新日時はシステム時刻に依存します。時刻が大きくずれていると、サブスクリプションの更新失敗、接続直後の切断、ログに証明書の時刻に関する警告が出るなどの症状が発生します。システムの自動時刻合わせを有効にしてからクライアントを再起動し、新しい時刻情報をコアに読み込ませてください。

次の手順へ進む前に確認すること

クライアントを起動でき、設定画面にアクセスでき、サブスクリプションURLを完全にコピーできていることを確認します。デバイスの時刻とタイムゾーンも正しく設定してください。これらの条件を整えてから導入すれば、問題がURL、設定、接続のどの段階で起きたか判断しやすくなります。

ステップ1

サブスクリプションを導入して現在の設定を有効化

クライアントの「設定」または「サブスクリプション」画面を開き、「追加」「導入」「設定を追加」などの入口を探します。デスクトップ版では通常、画面上部にURL入力欄があります。モバイル版では右上のプラスボタンを押してから、「URLから導入」や「サブスクリプション」を選ぶ場合があります。先ほどコピーした完全なURLを貼り付けてください。名前欄には、デバイスや用途で区別できる短い名前を入力できます。クライアントが自動で名前を取得する場合は、そのまま使用しても構いません。

保存、導入、またはダウンロードをクリックし、クライアントが初回読み込みを完了するまで待ちます。成功すると、設定一覧に新しい項目が表示され、更新日時、更新ボタン、または設定ファイルの状態が示されます。項目を開くと、通常はプロキシグループ名も確認できます。ただし、一覧に項目があることだけを確認して接続するのは避けてください。その設定を選択し、現在有効な設定にする必要があります。デスクトップ版では強調表示、チェックマーク、「有効」などの表示で現在の項目を示します。モバイル版では設定詳細を開いて「使用」を選ぶ場合があります。

導入後に一度手動更新を実行すると、サブスクリプションURLに現在もアクセスできるか確認でき、クライアントのキャッシュに残った古い内容の使用も避けられます。更新成功は、すべてのノードが利用可能という意味ではありません。設定ファイルを正しくダウンロードして解析できたことを示すだけです。次に「プロキシ」または「ポリシー」画面を開き、複数のプロキシグループと、各グループ内の選択肢が表示されているか確認します。画面が空、DIRECTしか表示されない、設定の解析に失敗したと表示される場合は、設定画面に戻ってエラーを確認し、システムプロキシを有効にしないでください。

導入に失敗した場合は、まずエラーが出たタイミングで切り分けます。更新直後にURLが無効と表示された場合は、サブスクリプションURLをコピーし直し、前後の空白を確認します。しばらく待ってからタイムアウトになる場合は、現在のネットワークからURLにアクセスできるか確認してください。ダウンロード後に形式エラーが出る場合は、サブスクリプション形式が現在のコアに対応していない可能性があります。形式の判別、空の内容、更新失敗については、よくある質問のインストールと設定で詳しく確認できます。ここでは設定構文の説明は省略します。

この手順の完了条件

設定一覧に新しいサブスクリプションがあり、手動更新が完了し、その設定が有効になっていることを確認します。プロキシ画面にプロキシグループと選択肢が表示されていれば完了です。これらを確認してから、モードとノードを選択します。

ステップ2

ルールモードと主要なプロキシグループを選択

「プロキシ」画面を開き、まずモード選択欄を探します。一般的なモードにはルール、グローバル、ダイレクトがあります。初回設定では「ルール」モードがおすすめです。現在の設定に含まれるルールに従って、各接続をプロキシ経由にするか直接接続にするか判断するため、日常利用でサイトごとに手動切り替えする必要がありません。グローバルモードは大半の接続を同じプロキシポリシーに送るため、特定ノードの接続確認に適しています。ダイレクトモードは比較テストや、一時的にプロキシ処理を回避する場合に使います。

モードを選んだら、画面に表示された主要なプロキシグループを確認します。グループ名はサブスクリプション設定によって異なり、「ノード選択」「プロキシ」「自動選択」などと表示される場合があります。主な出口を選ぶグループを開き、具体的なノード、または設定が提供する自動速度測定やフォールバックポリシーを選択します。初回接続では明確なノードを直接選ぶと、切り替えのタイミングに影響されず原因を追いやすくなります。動作確認後、必要に応じて自動選択へ変更してください。

ストリーミング、メッセージング、ソフトウェア更新、直接接続サービス向けのプロキシグループが表示されることもあります。これらのグループは主要ポリシーを参照したり、それぞれ異なる出口を選択したりします。初回設定では項目ごとに変更せず、サブスクリプションの初期値を維持してください。複数のグループを早い段階で変更すると接続経路を追いにくくなります。ブラウザーは使えるのに特定アプリが使えない場合、どのグループにマッチしたのか判断しづらくなります。まず初期ルールをそのまま動かし、必要に応じて項目ごとに調整するのが安定した手順です。

クライアントによっては遅延テストボタンが表示されます。テスト結果が示すのはクライアントからテスト先へのリクエスト状況であり、すべてのサイトやアプリが正常に使えることを意味しません。最終確認の材料として単独で使うこともできません。すべての項目がタイムアウトになる場合は、速度テストを何度も実行せず、具体的なノードに切り替えて接続手順を完了し、実際のアクセスとログで判断してください。url-testfallbackload-balanceの動作はそれぞれ異なります。長期的な選定が必要な場合はプロトコルとコアの技術リファレンスを参照してください。

RULE

ルールモード

設定したルールに基づいて接続経路を振り分けます。日常利用の標準モードに適しており、このガイドでも後続手順に使用します。

GLOBAL

グローバルモード

主要な接続を選択したポリシーに統一します。短時間のノード比較に適していますが、アプリの要件を把握しないまま長期間固定することはおすすめしません。

DIRECT

ダイレクトモード

接続をプロキシポリシーに通しません。オン・オフ前後の比較テストに利用し、通信がクライアントに入っているか確認できます。

この手順の完了条件

クライアントがルールモードになっており、主要なプロキシグループで具体的なノードまたは明確な自動選択ポリシーが選ばれ、その他の細分化されたグループは初期値のままになっていることを確認します。次にコアを起動し、システム通信をクライアントに渡します。

ステップ3

コアを起動してシステムプロキシ接続を確立

クライアントのホーム画面または「設定」画面に戻り、コアが実行中であることを確認します。Clash Verge Revなどのデスクトップクライアントでは、ウィンドウ下部、サイドバーの状態欄、トレイメニューなどにコアの状態が表示されます。設定を切り替えた直後はコアが一時的に再読み込みされることがあります。状態が戻るまで待ってからシステムプロキシを有効にしてください。ログに設定の読み込み完了やプロキシポートのリッスン開始などが表示されれば、通常はコアが現在の設定を読み込めています。

Windows、macOS、多くのLinuxデスクトップ環境では、次に「システムプロキシ」を有効にします。このスイッチにより、システムのHTTPおよびHTTPSプロキシがクライアントのローカル待受ポートを指すようになり、システムプロキシに従うブラウザーやアプリの接続がクライアントへ送られます。有効にした後、クライアントをすぐ終了しないでください。システムプロキシは接続をローカルプロセスへ渡すだけなので、クライアントを閉じるとローカルポートが待ち受けなくなり、アプリが一時的に接続できなくなる場合があります。終了する場合は、先にシステムプロキシを無効にしてからクライアントを終了してください。

AndroidとiOSでは通常、メイン画面の接続ボタンをタップします。システムにネットワーク接続の許可ダイアログが表示されるので、確認するとステータスバーに接続アイコンが現れ、クライアントのボタンも接続済みの状態に変わります。これらのプラットフォームには「システムプロキシ」という独立したスイッチがない場合もありますが、順序は同じです。クライアントが設定とポリシーを読み込み、その後システムの許可を通じてアプリ通信を受け取ります。ほかの同種のネットワーク接続サービスが有効な場合は、先に既存の接続を切断してください。モバイルOSでは通常、この種の接続を同時に1つしか使用できません。

Linuxでは、デスクトップ環境やアプリがシステムプロキシ設定を読み取るかどうかにも注意が必要です。一般的なGUIデスクトップはクライアントが自動設定できますが、一部のターミナルプログラム、コンテナプロセス、独立したネットワークツールはデスクトップのプロキシに従わず、個別にプロキシアドレスを指定する必要があります。初回確認では通常のブラウザーを使い、アプリ独自のプロキシ機構とクライアント接続の問題を混同しないようにします。ポート設定、環境変数、透過プロキシについては、よくある質問プロトコルリファレンスで詳しく確認できます。

システムプロキシを有効にしてクライアントがすぐにエラーを表示した場合は、まずログの末尾数行を確認します。ポート使用中は、別のプログラムが同じポートを待ち受けている状態です。競合するプログラムを終了するか、クライアント設定でポートを変更します。権限エラーは、システムプロキシの書き込み権限、サービスモード、ネットワーク拡張の許可に関係している可能性があります。設定の読み込みエラーが出た場合は、最初の手順に戻って有効な設定を選び直してください。サブスクリプション、モード、ポート、ノードを一度に変更せず、毎回1項目だけ変更して再テストすると、原因を追いやすくなります。

この手順の完了条件

コアが実行中で、デスクトップ版ではシステムプロキシが有効、またはモバイル版ではシステム接続の許可が完了していることを確認します。クライアントに設定エラーやポートエラーが継続して表示されていなければ、ほかの設定を変更せず、直接確認手順へ進みます。

ステップ4

ブラウザー、接続履歴、ログで結果を確認

接続が確立したら、ブラウザーのウィンドウを完全に閉じて開き直し、普段利用するページにアクセスします。開き直すことで、古い接続、キャッシュされたページ、既存セッションによる誤判定を減らせます。ページが読み込まれることは第一段階の結果です。さらにクライアントの「接続」画面に戻り、ページ更新時に新しいドメイン、宛先、使用ポリシーが表示されるか確認します。表示されれば、ブラウザーのリクエストがクライアントに入り、ルール処理されています。

次に、新しい接続に対応するポリシー経路を確認します。ルールモードでは、ドメインによってDIRECT、主要プロキシグループ、設定内の別ポリシーなどが表示されます。これはルールによる振り分けとして正常です。すべての接続が同じノードになる必要はありません。確認すべきなのは、対象サイトの主要リクエストが想定したポリシーにマッチしているか、接続が繰り返し失敗していないかです。接続一覧にブラウザーの新しい記録がまったくない場合は、システムプロキシの状態、ブラウザー独自のプロキシ設定、アプリがシステムプロキシを回避していないかを優先的に確認します。

3段階目はログの確認です。正常にアクセスできている場合、ログには操作した時刻に対応する新しい記録が継続して表示され、同じエラーだけが繰り返されることはありません。ドメイン解決に失敗している場合は、現在のネットワーク、DNS設定、設定内の名前解決項目を確認します。接続がタイムアウトする場合は、主要プロキシグループで別のノードに切り替えて再試行します。接続拒否やローカルポートが利用できないという表示が出た場合は、接続手順に戻ってコアとポートを確認してください。ログの項目が多くても、初回設定では時刻、接続先、使用ポリシー、エラー原因に注目すれば十分です。コア情報を最初から1行ずつ読み解く必要はありません。

最後に、接続を無効にして比較します。ブラウザーのページはそのままにし、システムプロキシを無効にするかモバイル版の接続を切断してからページを更新し、クライアントの接続一覧を確認します。この状態では、そのブラウザーによる新しいプロキシ接続は表示されないはずです。再度有効にして更新すると、接続履歴が復元されます。この前後比較は、ページ上のアドレスだけを見るよりも信頼性が高く、アプリ通信がローカルクライアントに入っているかを直接確認できます。確認後はルールモードに戻し、必要なポリシー選択を維持してください。

ページにはアクセスできるのに、特定のストアアプリ、ターミナルプログラム、ゲームに接続履歴がない場合は、サブスクリプション導入ではなく、そのアプリがシステムプロキシに従うかどうかが原因であることが多いです。Windowsのストアアプリではループバックアクセス制限、ターミナルプログラムでは環境変数の個別設定、ブラウザー拡張ではシステム設定の上書きが関係する場合があります。アプリの種類ごとの切り分けはトラブルシューティングで確認してください。動作確認済みのサブスクリプション設定を削除してやり直す必要はありません。

A

ページの応答

ブラウザーを開き直して正常にアクセスでき、古いページキャッシュによる誤判定を除外できる。

B

接続履歴

クライアントにアクセス時刻に対応する新しい接続が表示され、実際にマッチしたポリシーを確認できる。

C

ログの状態

同じエラーがログに繰り返し出続けず、ノードを切り替えた後に結果を再確認できる。

D

無効化して比較

接続を無効にするとプロキシ履歴が追加されず、再度有効にすると履歴が復元される。

設定を完了

接続が安定してから自動更新と起動動作を設定

4つの手順で確認を終えたら、サブスクリプション詳細に戻って自動更新間隔を設定できます。更新頻度はサービス提供元の推奨値に従ってください。頻繁に更新しても接続品質は改善せず、リクエスト制限を受ける可能性があります。手動更新の入口は残し、プロキシグループの内容が変わったときやノード一覧が同期されないときに1回実行すれば十分です。更新後に現在のノードがなくなった場合は、主要プロキシグループを開いて利用可能な項目を選び直します。

デスクトップ版では、使用習慣に応じてOS起動時の自動起動、サイレント起動、システムプロキシの自動設定を有効にするか決められます。まずしばらく通常運用し、クライアントの終了、スリープからの復帰、ネットワーク切り替え後の動作を確認してから自動化項目を有効にするのがおすすめです。特に「起動時にクライアントを実行」と「起動後にシステムプロキシを自動的に有効化」は区別してください。前者はプログラムを起動するだけですが、後者はシステムの接続経路を変更します。公共Wi-Fi、職場のネットワーク、頻繁に環境を切り替えるデバイスでは、手動で有効にするほうが現在の状態を判断しやすくなります。

モバイルデバイスでWi-Fiからモバイルデータ通信へ切り替えた後は、クライアントが接続を維持しているか確認し、接続履歴ももう一度確認します。システムの省電力設定によってバックグラウンド動作が制限され、画面ロック後しばらくすると接続の再確立が必要になる場合があります。この問題にはプロトコル、バッテリー、システムのバックグラウンド制限が関係するため、基本ガイドでは詳しく扱いません。異なるプロトコルの接続特性、リソース使用量、モバイル版での挙動を比較する場合は、プロトコルとコアの技術リファレンスを参照してください。

デバイスに合ったClash Vergeクライアントを選択

まだインストールしていない場合や別のプラットフォーム版へ変更する場合は、ダウンロードページでOSとプロセッサアーキテクチャを確認してください。インストールパッケージの準備ができたら、このガイドのステップ1に戻って設定を始められます。