Clashの使い方ガイド

事前準備

インストール済みのクライアントと、信頼できる提供元の有効なサブスクリプションURLまたはローカル設定ファイルを用意します。まだインストールしていない場合は、クライアントのダウンロードページでOSとプロセッサのアーキテクチャに合ったファイルを選んでください。クライアントは設定を読み込んで接続を処理するもので、それ自体が利用可能なリモートプロキシサービスではありません。インストールしただけでは、プロキシ一覧にノードが表示されないことがあります。

初回の設定には10分ほど余裕を取り、サブスクリプションURLにアクセスできるネットワークで作業してください。まず、現在その端末でWebページを正常に閲覧できるか確認し、ネットワークを制御しているほかのプロキシやVPNアプリを終了します。複数のツールが同時にシステムプロキシ、ルーティング、DNSを変更すると、テスト結果の原因を特定しにくくなります。そのためにシステムのセキュリティ機能を無効にする必要はありません。今回のテストと競合する通信制御機能だけを一時停止してください。

このページでは、設定を1つ読み込み、出力先を1つ選び、通信を取り込む方法を1つ有効にして、対象リクエストを確認する最短の手順を紹介します。DNSの拡張モード、カスタムルール、ルールプロバイダーはまだ変更しません。プロトコルの違いやコアの互換性を確認したい場合は、プロトコルとコアのガイドをご覧ください。初回接続の前に変更する項目を増やしすぎないようにしましょう。

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

クライアントを起動し、「設定」またはProfiles画面を開きます。「サブスクリプションURL」「URLからインポート」などの項目を探し、URL全体を入力欄に貼り付けてから「インポート」または「ダウンロード」をクリックします。コピーする際は、チャットの引用符や改行、説明文を含めないでください。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、信頼できるクライアントにだけ貼り付け、公開の掲示板に送信しないでください。トラブル調査用のスクリーンショットにもURL全体を表示しないようにしましょう。

送信後、ダウンロードと解析が完了するまで待ちます。成功すると通常、設定名、取得元、更新日時などが表示されたカードが追加されます。インポートの成功と、設定が現在使用中であることは別です。新しい設定が自動で有効になるクライアントもあれば、カードやラジオボタン、「この設定を使用」などをクリックする必要があるものもあります。画面で選択状態を確認してからプロキシ画面を開き、想定したポリシーグループと出力先が表示されていることを確認してください。

ローカルのYAMLファイルを使う場合は、設定画面で「ファイルからインポート」を選ぶか、システムのファイル選択画面からファイルを開きます。ファイルの内容をサブスクリプションURLとして貼り付けないでください。インポート後は、同様に設定を選択して適用する必要があります。クライアントによってはファイルを専用の設定フォルダーにコピーするため、元のファイルを編集しても反映されない場合があります。再インポートが必要か、直接編集できるかは、クライアントのファイル管理方式を確認してください。

インポート結果を確認

プロキシ画面にグループが表示されていれば、少なくとも設定内容を読み込めています。ただし、リモートノードに接続できることまでは確認できていません。画面が空のままなら、設定画面に戻って選択状態を確認し、インポート時の表示やログを調べてください。ダウンロードには成功しても解析に失敗する場合、URLの応答がログインページやエラーメッセージだったり、クライアントが対応していない形式だったりする可能性があります。ファイルの拡張子だけで形式を判断したり、試しに不明な変換サイトへサブスクリプションを送信したりしないでください。

サブスクリプションの更新に失敗したら、まずURLが完全か、サービスの有効期限が切れていないか、現在のネットワークからURLにアクセスできるかを確認してください。以前の設定がまだ使える場合は、それを残し、すぐに削除して追加し直さないでください。更新には別途ネットワークリクエストが必要です。ノードに接続できても、その時点でサブスクリプションサーバーにアクセスできるとは限りません。逆に、サブスクリプションをダウンロードできても、すべてのノードが使えるとは限りません。詳しくはよくある質問をご覧ください。

リモート設定は、次回の更新時に直接編集した内容を上書きすることがあります。初回接続では元の設定を保管してください。後からルールを追加する場合は、クライアントが正式に対応しているオーバーライド、マージ、拡張機能を使いましょう。ここでは、設定画面で1つの設定が明確に選択されていること、プロキシ画面にその設定のポリシーグループが表示されていることを確認すれば十分です。両方を確認したら、プロキシモードを選びます。

2. ルールモードと出力ノードを選択

クライアントの「プロキシ」「概要」「出力モード」などの画面を開き、「ルール / グローバル / DIRECT」の切り替えを探します。初めて使う場合はルールモードを選んでください。このモードでは設定内のルールに従って、接続ごとにプロキシ、直接接続、その他の出力方法を決定します。「特定のサイトは必ずプロキシを通る」という固定リストではなく、実際の動作は現在の設定にあるルールの順序と参照先に左右されます。

次にポリシーグループの一覧を開き、主なプロキシ通信に使うグループを選びます。グループ名は設定の作成者が決めるため、「プロキシ選択」「ノード選択」などの名前が付いていることもあります。完全に一致する名前を探す必要はありません。グループを開き、中にノードが並んでいるか、別のポリシーグループがあるかを確認します。手動選択グループでは、利用できると分かっているノードを選び、その項目に選択マークが付いていることを確認してください。DIRECTが選ばれている場合、該当する接続は宛先に直接アクセスします。

自動選択やフォールバックを使うグループでは、設定に基づいてクライアントがノードをテストして切り替えることがあり、手動選択グループのようにノードを固定できない場合があります。グループ名に「自動」とあっても、すべてのアプリが自動的に通信を取り込まれるわけではありません。ポリシーグループが決めるのは、コアに渡された接続の出力先です。OSがアプリの通信をクライアントに渡すかどうかは、次の手順で設定します。見慣れないグループ構成は、用語ガイドのポリシーグループと出力の説明を確認してください。

3つのモードの使い分け

グローバルモードでは通常、そのモードの制御対象となる接続をグローバルポリシーに渡します。動作を一時的に比較する際に便利ですが、切り替えた後もグローバルポリシーグループでどの出力先が選ばれているか確認してください。システムプロキシやTUNで取り込まれていないアプリの通信まで、自動的にクライアントに入るわけではありません。また、端末の全データが必ずリモートノードを経由するという意味でもありません。DIRECTモードでは通常モードの制御対象となる接続を宛先へ直接送るため、直接接続の復旧やプロキシ経路の調査には使えますが、リモートプロキシの動作確認には適しません。

クライアントに遅延テスト機能がある場合は、現在のグループでテストを実行し、結果が出てからノードを選びます。テスト結果が示すのは、ノードから指定テスト先への接続状況であり、あらゆるWebサイトの通信速度ではありません。タイムアウトの原因は、テスト先、認証情報、ネットワーク環境にある場合もあります。初期設定では、テストが完了し実際の目的のサイトにも接続できる出力先を選べば十分です。最小の数値を追求する必要はありません。

設定後はルールモードのままにし、現在選択されているメインポリシーグループを覚えておきます。その後でシステムによる通信の取り込みを有効にすると、問題が起きた際に「出力先の選択ミス」と「アプリの通信がコアに届いていない」のどちらかを切り分けやすくなります。モード変更、サブスクリプション更新、ノード設定の変更を同時に行わないでください。どの変更が結果に影響したのか判断しにくくなります。

3. 接続を開始してシステムの許可を設定

デスクトップでは、クライアントにコアの実行状態が表示されているかを確認します。「起動」「コアを実行」などの独立したボタンがあれば、先にコアを起動してから「システムプロキシ」を有効にしてください。コアが自動で起動するクライアントでは、起動失敗の表示がないことを確認します。次に、システムプロキシに従うブラウザーでテストします。システムプロキシはアプリにローカルプロキシのアドレスを提供するもので、すべてのアプリやプロトコルがその設定を使うとは限りません。

Windowsでは、システムのプロキシ設定を開き、クライアントによって有効化されていることを確認できます。初回はポートを手動で変更しないでください。macOSではネットワークプロキシの変更許可が求められる場合があるため、システムの案内に従います。Linuxのデスクトップ環境やアプリでは、プロキシ設定への対応状況が異なります。ブラウザーでアクセスできても、コマンドラインツールがプロキシを使っていないからといって、すぐにクライアントの故障とは判断できません。まずブラウザーで確認し、環境変数や専用プロキシ設定が必要なプログラムは個別に対応してください。

AndroidまたはiOSでは通常、メイン画面の「接続」または起動スイッチをタップします。初回にシステムからVPN接続の確立やVPN構成の追加を求められたら、要求元がインストールしたクライアントであることを確認し、案内に従って許可してください。ここで使うVPNインターフェースは、モバイルOSが通信を受け渡す仕組みです。クライアントが使うリモートプロトコルも、従来のVPN方式であるという意味ではありません。許可後にクライアントへ戻り、接続状態が安定してから次へ進みます。

TUNモードを使うタイミング

対象アプリがシステムプロキシに従わない場合や、より多くの種類の通信を取り込む必要がある場合は、TUNモードを検討します。仮想ネットワークインターフェースを通じて通信を取り込むため、ルーティングやDNSの設定が関わることがあります。デスクトップではサービスコンポーネントのインストール、権限の昇格、ネットワーク拡張の許可が必要になる場合もあります。クライアントのドキュメントに従って設定し、不明な提供元のドライバーはインストールしないでください。初回テストで必要がなければ、システムプロキシから始めると確認項目を減らせます。

クライアントによってはシステムプロキシとTUNを同時に有効にできますが、特定の組み合わせを推奨するものもあります。このページの初回確認では、主な通信取り込み方法を1つだけ選び、結果を確認してから必要に応じて調整してください。モバイルではアプリごとのプロキシ、除外リスト、アプリ別VPNの設定にも注意が必要です。テストするブラウザーが除外されていると、その通信は想定した経路でコアに届きません。全体のスイッチだけでなく、テスト対象のアプリが取り込み対象に含まれていることも確認してください。

有効にした直後にインターネットへ接続できなくなった場合は、直前に有効化した通信取り込みを無効にし、元の接続が戻ることを確認してから、ログで起動エラー、ポートの競合、権限エラーを調べます。確認の代わりに再起動や権限許可を繰り返さないでください。デスクトップのウィンドウを閉じただけの場合、プログラムがタスクトレイやメニューバーで動作しているかも確認します。ウィンドウを閉じてもプロキシが停止するとは限りません。クライアントは動作させたまま、実際のリクエストで接続経路を確認してください。

4. ルールの適用とプロキシの出口を確認

まずクライアントの「接続」画面を開き、ブラウザーで新しいタブを作って、プロキシ経由になる想定のサイトへアクセスします。キャッシュ済みページを見るだけでなく、新しいページリクエストを発生させてください。クライアントに戻り、該当するドメインまたは宛先アドレスの接続記録を探して、適用ルール、ポリシーグループ、最終的な出力先を確認します。表示される項目はクライアントによって異なり、ポリシーの経路全体を見るには接続の詳細を開く必要がある場合もあります。

ページが開くこと、接続がコアに届くこと、想定した出力先が使われることを合わせて確認してください。記録にDIRECTと表示され、設定でもその宛先が直接接続に指定されているなら、ルールは正常に動作しており、プロキシの故障ではありません。プロキシを使う想定なのに直接接続のルールが適用された場合は、すぐにDNSを切り替えるのではなく、読み込み中の設定とルールの順序を確認してください。ルールは上から順に評価され、先に一致したルールが後続のルールより優先されます。

信頼できる出口IP確認サービスも参考になりますが、確認ページ自体もルールの制御対象です。表示される出口IPが示すのは、その確認リクエストの経路だけであり、端末上のすべてのアプリが同じ経路を使うとは限りません。モバイル回線、IPv4とIPv6、複数の出口アドレスによって結果が異なることもあります。アドレスが変わったかだけを見るより、確認結果とクライアントの接続記録を照らし合わせてください。結果を共有する際は、個人のネットワーク情報を公開しないよう注意しましょう。

接続経路をたどって問題を特定

Webページには結果が表示されるのに接続画面で該当するリクエストが見つからない場合は、ページを再読み込みし、表示対象がアクティブな接続か履歴かを確認します。短時間の接続はすでに終了していたり、ブラウザーがキャッシュを再利用していたりする場合があります。表示範囲を確認しても記録がない場合は、システムプロキシ、ブラウザー独自のプロキシ、TUNの取り込み範囲、ほかに動作中のネットワークツールを確認してください。この場合に優先して調べるのは、アプリからコアまでの経路であり、リモートノードの速度ではありません。

接続記録があり、最終出力先も正しいのにサイトが読み込めない場合は、そのリクエストに対応するエラーをログで確認します。認証エラー、接続タイムアウト、名前解決エラーでは対処方法が異なります。同じグループ内でノードを1つだけ変更し、同じサイトに再アクセスして比較することもできます。すべてのノードで失敗する場合は、サブスクリプションの状態、ネットワーク環境、エラーの種類を確認してください。複数の設定を同時に変更したり、1つのサイトにアクセスできないだけで設定全体が使えないと判断したりしないでください。

ルールモードで一部のサイトに問題がある場合は、一時的にグローバルモードへ切り替え、同じノードを明示的に選んで同じリクエストを試します。グローバルモードで正常なら、優先して確認するのはルールとポリシーの参照先です。どちらのモードでも失敗する場合は、ノードまたは通信の取り込み経路を調べてください。これは原因を絞るための比較方法です。テスト後は、通常使う予定のルールモードに戻してください。プロトコルの対応状況、DNSの仕組み、コアの違いについてはプロトコルガイドを、操作上のよくあるミスについてはFAQをご覧ください。

最後に、設定上で直接接続する想定の宛先にもアクセスし、出力先を確認します。これにより、プロキシ接続が使えることと、すべてのリクエストが誤って同じ経路に送られていないことの両方を確認できます。完了後は、現在使えている設定とポリシーグループの選択を保管し、以後の変更を比較する基準にしてください。

設定後の更新と終了

初回接続が完了したら、設定画面でサブスクリプションの更新設定を確認できます。更新頻度は提供元の推奨に従いましょう。頻繁に更新しても接続が安定するわけではありません。ネットワークの切り替え、設定の更新、クライアントのアップグレード後は、メインポリシーグループと対象リクエストを再確認すれば十分です。許可の手順を毎回すべて繰り返す必要はありません。長期的に保持するローカル変更は、クライアントが対応するオーバーライド機能に記録し、復元用のコピーを保存してください。

使用を終了する際は、デスクトップでは先にシステムプロキシまたはTUNを無効にしてからクライアントを終了します。モバイルでは切断をタップし、システム上の接続も終了したことを確認してください。プログラムが異常終了してブラウザーからインターネットへ接続できない場合は、ネットワーク設定をすべてリセットする前に、停止済みのローカルプロキシがシステムに設定されたままではないか確認します。正しい手順で終了すれば、次回接続時の環境の違いを減らせます。