Clashの使い方ガイド

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

始める前に、クライアントが正常に起動することと、サブスクリプションの有効期限が切れていないことを確認してください。Clashクライアントは設定を読み込み、通信を処理するソフトウェアです。クライアントをインストールしただけでは、プロキシノードは用意されません。サブスクリプションURLは通常、サービス提供元から案内されます。アカウントを識別できる情報が含まれる場合があるため、機密情報として扱ってください。URL全体を公開の掲示板に投稿したり、信頼できないオンライン変換サービスに入力したりしないでください。

Clash Verge Revでの追加手順

Clash Verge Revを開き、サイドバーから「サブスクリプション」画面に移動します。バージョンによっては「設定」と表示される場合があります。サブスクリプションURLの入力欄に、サービス提供元がClashまたはmihomo対応と案内しているURLを貼り付け、「追加」をクリックします。新しい設定の作成画面が表示された場合は、リモート設定を選び、見分けやすい短い名前を付けてください。名前はローカルで管理するためのもので、サブスクリプションの内容には影響しません。確定後はダウンロードが完了するまで待ち、同じURLを続けて何度も追加しないでください。

追加が完了すると、一覧に設定カードまたは設定の記録が表示されます。その項目をクリックし、現在使用中になっていることを確認してから「プロキシ」画面を開き、プロキシグループと選択可能なノードが表示されているか確認してください。追加後に自動で有効になるクライアントもあれば、ファイルを保存するだけのものもあります。そのため、「一覧にサブスクリプションがあること」と「コアがそのサブスクリプションを使用中であること」は、それぞれ確認が必要です。新旧の設定内容が異なる場合は、切り替え後にプロキシ画面にも変化が表示されるはずです。

AndroidとiOSのクライアントでは、通常「サブスクリプション」または「設定」画面の追加ボタンから操作を始めます。URLから追加する方法を選び、URLを貼り付けて保存したら、設定一覧に戻って有効にしてください。システムの共有メニューからURLをクライアントに渡せる場合もありますが、最後にクライアントへ戻り、現在の設定を確認する必要があります。QRコードから追加するときは、サービス提供元が発行したものか確認してください。読み取った結果が通常のウェブページだった場合、利用可能な設定が取得できたとは限りません。

ローカルファイルと初回更新

YAMLファイルを受け取った場合は、「ファイルからインポート」や「ローカル設定」からファイルを選び、サブスクリプションURLの欄にファイルの内容を貼り付けないでください。ローカルファイルを更新できるかどうかは、ファイルの内容とクライアントの仕組みによって異なります。リモートのサブスクリプションのように更新できるとは限りません。設定ファイルに含まれるノード、プロキシグループ、ルールにはそれぞれ役割があります。初回は変更せず、そのまま使ってください。それぞれの関係を知りたい場合は用語解説を確認できます。この段階でファイルを手作業で書き換える必要はありません。

追加に失敗したら、まずURLが欠けていないか確認してください。特に、チャットアプリからコピーしたときに空白や改行が混ざっていないか注意します。次に、クライアントのエラーメッセージを確認します。ダウンロード失敗は、内容を取得できていない状態です。解析失敗は、取得した内容を現在の設定形式として読み込めなかったことを示します。ログインページやエラーページ、ほかのクライアント専用の形式が返されると、解析に失敗することがあります。ルールを何度も変更するのではなく、サービス提供元にサブスクリプションの種類を確認してください。プロキシ画面にプロキシグループが表示されてから、モードを選びます。

ステップ2：モードと出站ノードを選択

設定を有効にしたら、クライアントのホーム画面、プロキシ画面、または設定画面で「出站モード」を探します。通常は「ルール」「グローバル」「直接接続」の3種類があり、初回接続ではルールモードを選択してください。設定内のルールに基づいて、各接続の送信先となるプロキシグループや直接接続が決まります。このモードが制御するのは、通信がコアに入った後の処理方法です。ブラウザーなどのアプリからコアへ通信を送る設定ではありません。後者はステップ3で説明します。

次に「プロキシ」画面を開き、メインの出站プロキシグループを探します。名前はサブスクリプションの設定によって異なり、「ノード選択」「プロキシ」などと表示されることがあります。必ずしもPROXYという名前ではありません。プロキシグループを開き、現在利用できるノードをクリックして、選択マークが移動したことを確認してください。グループ内に別のプロキシグループが表示される場合は、現在選択されている項目をたどり、最終的な出站先が具体的なノードなのか、直接接続なのかを確認します。

設定によっては、動画サービス、コードホスティング、チャットアプリ用のプロキシグループが個別に用意されています。メインのグループでノードを選んでも、こうしたグループの設定は上書きされません。初回の確認では、テストするウェブサイトに対応するグループを確認すれば十分です。対応関係がわからない場合は、先に接続して、後から「接続」ログで実際の経路を調べることもできます。ノード名だけを見て特定のサイトに使われると判断せず、ルールとプロキシグループの参照関係を確認してください。

Clashのノード遅延テスト

プロキシグループの横にあるテストボタン、またはクライアントの「遅延テスト」を選び、今回のテスト結果が表示されるまで待ちます。テスト結果は、クライアントからその出站先を使ってテスト用アドレスにアクセスした状況を示します。具体的な意味はクライアントやテスト方法によって異なります。ダウンロード速度を示すものではなく、すべてのウェブサイトにアクセスできる保証にもなりません。タイムアウトした場合は、同じグループ内の別のノードを選んで再度試してください。数値が一度低かっただけで、すべてのアプリに適したノードだと判断しないようにしましょう。

テスト後に、選択中の項目をもう一度確認してください。テストボタンは接続性を調べるだけで、手動選択のプロキシグループでは現在のノードを自動で切り替えない場合があります。自動選択のグループは、それぞれの設定に従って切り替わります。初回は、確認したいページを継続して開けるかを基準に、利用可能なノードをひとつ選んでおきましょう。頻繁なテストでトラブルシューティングを中断しないようにしてください。選択グループ、自動選択、フォールバックの違いについては、後でプロキシグループの応用ガイドを確認できます。

比較のためにClashのグローバルモードを使う場合は、切り替えた後にグローバル設定で現在選択されている出站先も確認してください。グローバルモードにしても、端末のすべての通信が自動で取り込まれるわけではなく、使えないノードが修復されるわけでもありません。テストが終わったらルールモードに戻し、その後の確認で元の設定と異なる経路を使わないようにしてください。3つのモードの詳しい説明は出站モードの解説をご覧ください。

ステップ3：接続と通信の取り込みを有効化

設定と出站先が決まったら、実際にアプリがクライアントを使うようにします。デスクトップでは確認しやすいシステムプロキシを使い、モバイル端末ではVPN接続の手順に従ってください。ほかのプロキシツールやVPNも動作している場合は、もう一方の接続を先に切り、テスト条件をひとつに絞ります。通信の取り込み方法は一度にひとつだけ変更してください。問題が起きたときに、どの手順で変化したのかを特定しやすくなります。

デスクトップのシステムプロキシ設定

Clash Verge Revの設定画面で「システムプロキシ」を有効にし、続いてOSのネットワーク設定にあるプロキシ画面を開いて、状態が変わったことを確認します。通常、クライアントはシステムプロキシの接続先をローカルの待ち受けアドレスと現在のポートに設定します。クライアントに表示されている値を使ってください。ガイドでよく使われているポートが7890だからといって、端末のポートを無理に変更する必要はありません。カスタム設定やほかのソフトウェアでは、異なるポートが使われる場合があります。

システムプロキシを使用するブラウザーは、通常、新しい接続からこの経路を使います。ブラウザーに独自のプロキシ拡張機能が入っていないか、ブラウザー自身の設定で別のプロキシが指定されていないか確認してください。Firefoxなどでは、独自のネットワーク設定が使われる場合があります。システムプロキシを使う設定にするか、クライアントの実際の待ち受け情報を設定してください。変更した後は新しいウィンドウを開いてアクセスし、既存の接続を使い回さないようにします。コマンドラインや一部のアプリはシステムプロキシを参照しないため、初回の接続確認では、それらだけを成功・失敗の判断材料にしないでください。

macOSでは、システムのネットワーク設定を変更すると、権限の確認が表示される場合があります。サービスや補助コンポーネントのインストールが必要なクライアントでは、追加の許可を求められることもあります。表示されたアプリ名を確認してから許可し、クライアントに戻ってスイッチが有効のままか確認してください。Linuxでデスクトップのネットワーク設定に変更が反映されない場合は、アプリ内でプロキシを明示的に設定して確認できます。元の値を記録せずに、システムのネットワーク設定を何度も変更しないでください。

モバイル端末での接続とVPN許可

AndroidとiOSでは、クライアントのホーム画面に戻り、接続スイッチをタップします。初回接続時は、システムのVPN設定または接続の許可を求められることがあります。許可したら、クライアントに接続済みと表示されるまで待ち、システム側にもVPNの状態が表示されるか確認してください。この状態で確認できるのは、システムがクライアントに必要な通信経路を確立したことです。リモートノードへのアクセスまで確認できたわけではないため、ステップ4も実施してください。

スイッチをオンにしてもすぐオフになる場合は、システムが接続を拒否していないか、別のVPNがまだ接続中ではないか確認してください。Androidでは、常時接続VPN、アプリごとの通信設定、バッテリー管理も確認し、ほかのアプリによる接続制限を避けます。iOSでは、システム設定を開き、現在のVPN設定が使用中のクライアントのものか確認してください。接続の許可が完了する前にスイッチを連続してすばやくタップすると、何度も接続と切断が繰り返されて状態がわかりにくくなるため、避けてください。

TUNに切り替えるタイミング

ブラウザーはルールどおりにアクセスできるのに、システムプロキシに従わないアプリだけが直接接続する場合は、TUNの利用を検討してください。設定でTUNモードを有効にし、クライアントの案内に従ってサービスをインストールするか、管理者権限を許可します。初回はクライアントのデフォルトのstackを維持し、機能を確認してください。DNS、ルート、プロトコルスタックを同時に変更しないでください。仮想ネットワークアダプターの作成、ルートの設定、アプリの除外状況も結果に影響するため、スイッチの色だけで通信を取り込めたと判断することはできません。

TUNを有効にした後、端末全体でインターネットに接続できなくなった場合は、まずTUNを無効にして、先ほど動作を確認したシステムプロキシに戻してください。通信が復旧したらログを調べ、すべての設定をすぐにリセットしないでください。TUN、Fake-IP、DNSの組み合わせは後から調整する項目です。初回接続の段階で設定する必要はありません。関連する仕組みは通信の取り込みとDNSの用語解説から確認できます。

ステップ4：接続が機能しているか確認

クライアントの「接続」画面を開いたまま、ブラウザーで新しいウィンドウを作成し、普段利用している表示内容が安定したHTTPSページにアクセスします。クライアントに該当するドメインまたは宛先の接続ログが表示されるか確認し、その接続に適用されたルールと出站経路を確認してください。クライアントによっては、記録の詳細を開かないと項目が表示されません。短時間で終了する接続は、先にログ画面を開いてから対象ページを再読み込みすると確認しやすくなります。

ページが正常に表示され、接続ログに想定したプロキシグループとそのノードが記録されていれば、今回のリクエストはコアに届き、その経路で処理されています。次に、直接接続されるはずのページにもアクセスし、ログにDIRECTと表示されるか確認してください。ルールモードでは、一部のリクエストが直接接続されるのは正常であり、プロキシが無効という意味ではありません。バイパス設定を使う場合、直接接続された通信の一部がコアのログに表示されないこともあるため、実際の通信取り込み設定を踏まえて判断してください。

信頼できるIPアドレス確認ページを使って、出口を調べる方法もあります。ただし、まずその確認ページ自体に適用されるルールを確認してください。表示されるのは、そのリクエストで確認できた出口アドレスであり、すべてのアプリやドメインが同じ経路を使うとは限りません。ブラウザーのキャッシュ、接続の再利用、アドレスファミリーの違いによって結果が異なる場合もあります。ページの表示結果と接続ログを照らし合わせ、タスクトレイのアイコンやVPNマークだけで判断しないでください。

失敗した場合は同じ順序で確認

テストしたリクエストがクライアントにまったく表示されない場合は、ステップ3に戻り、システムプロキシ、ブラウザー独自のプロキシ設定、またはモバイル端末のVPN状態を確認します。ログはあるものの、プロキシを通るはずの通信がDIRECTになっている場合は、ノードを変更する前にルールとプロキシグループの選択を確認してください。ログでプロキシノードを経由しているのに接続がタイムアウトする場合は、同じプロキシグループ内の別のノードで比較します。この3つはそれぞれ、通信の取り込み、振り分け、出站先への接続性に関する問題です。複数のスイッチを同時に変更するより、問題を切り分けて確認するほうが原因を特定しやすくなります。

ログに解析関連のエラーが表示された場合は、元の設定を残したまま、直接接続で名前解決や普段使うページへのアクセスができるか確認します。そのうえで、特定のドメインだけに問題が起きるか調べてください。インターネットからコピーしたDNS設定全体でサブスクリプションを上書きしたり、システムDNS、クライアントのDNS、ブラウザーの暗号化DNSを一度に変更したりしないでください。問題を報告するときは、クライアント名、OS、再現手順、エラーメッセージを記録します。ログを共有する前に、サブスクリプションURL、アカウント識別情報などの機密情報を削除してください。

接続を確認できたら、現在使用している設定、モード、プロキシグループの選択を覚えておきましょう。サブスクリプションを更新して変化があった場合は、まず同じ設定を引き続き使用しているか、プロキシグループの選択が維持されているか確認してください。使用を終えるときは、クライアントからシステムプロキシまたはVPN接続を無効にしてからアプリを終了します。アプリ終了後にブラウザーがインターネットへ接続できなくなった場合は、システムのネットワーク設定にローカルを指す手動プロキシが残っていないか確認してください。