Clashの使い方ガイド

ステップ1：サブスクリプションを追加

まず利用可能な設定をクライアントに追加してから、接続を有効にします。クライアントは設定の読み込み、出口の選択、通信の取り込みを行います。ソフトウェアをインストールしただけでは、プロキシサービスは利用できません。作業を始める前に、サービス提供元から案内されたClash対応のサブスクリプションURL、または利用可能なローカルYAML設定ファイルを用意してください。サブスクリプションURLにはアカウント情報が含まれることがあります。信頼できるクライアントにのみ保存し、公開掲示板やスクリーンショット、不審なオンライン変換サイトには貼り付けないでください。

サブスクリプションURLから設定を追加

クライアントを開き、「設定」「サブスクリプション」または「Profiles」ページに移動します。「追加」「インポート」またはプラスボタンを探し、「URLからインポート」を選んでサブスクリプションURL全体を貼り付けてください。名前欄がある場合は、「普段使い」など見分けやすい名前を付けられます。名前は端末上で識別するためのもので、サブスクリプション内のノードやルールには影響しません。保存する前にURLの前後に空白がないことを確認してください。サービス提供元のアカウント管理ページのURLを、サブスクリプションURLと取り違えないよう注意しましょう。

ダウンロードまたは保存をクリックし、設定一覧に新しい項目が表示されるまで待ちます。更新日時や設定名が表示され、解析エラーが出なければ、正常に追加できた可能性が高いです。次に、その項目または「有効化」ボタンをクリックして、現在の設定にします。インポート後にファイルを保存するだけで、自動では切り替わらないクライアントもあります。「使用中」の表示があるか、プロキシ画面に対応するプロキシグループが表示されていることを確認してください。ここでは通信の取り込みを有効にせず、設定が読み込まれたことを先に確認します。

ローカルファイルの追加とインポートエラーへの対処

.yamlまたは.ymlファイルを受け取った場合は、同じページで「ファイルをインポート」を選び、ファイル選択画面からファイルを指定して設定を有効にします。モバイルでは、OSの共有メニューからクライアントにファイルを渡せる場合もあります。利用できる方法はクライアントの仕様を確認してください。ローカルファイルは通常、リモートサブスクリプションのように自動更新されません。更新時は再インポートするか、クライアントの編集・上書き機能を使って管理します。

「形式エラー」「解析に失敗しました」と表示される場合は、サブスクリプションの出力形式がクライアント対応のClash設定か確認してください。Webページの内容、単一のプロトコルリンク、Base64形式のノード一覧ではないかも確認します。タイムアウトする場合は、現在のネットワークからサブスクリプションの配信元にアクセスできるかを調べてください。ダウンロードエラーを直そうとして、DNS、TUN、ポートを同時に変更するのは避けましょう。設定には少なくとも利用可能な出口と対応するポリシーが必要ですが、構成はサービス提供元によって異なります。拡張子だけで互換性を判断することはできません。

追加できたらプロキシ画面に戻り、プロキシグループまたは選択可能な出口が表示されていることを確認して、次の手順に進みます。サブスクリプションの更新に失敗しても、以前の設定が残るクライアントがあります。設定が表示されていても、最新の内容を取得できたとは限りません。形式の見分け方や更新設定については、サブスクリプションURLの追加方法と主な形式をご覧ください。追加後もプロキシグループが表示されない場合は、FAQのインストール・設定に関する項目を確認してください。

ステップ2：プロキシモードを選ぶ

初めて使う場合は「ルールモード」がおすすめです。ルールモードでは、現在の設定に基づいて、各接続を直接接続にするか、プロキシグループで処理するかを決めます。クライアントのホーム画面、ダッシュボード、またはプロキシ画面を開き、「モード」の選択欄で「ルール」または「Rule」を選んでください。この設定で変わるのは、通信がコアに入った後の処理方法です。ブラウザーや他のアプリの通信がクライアントに届くようになるわけではありません。通信の取り込みは次の手順で設定します。

主なモードは「ルール」「グローバル」「ダイレクト」の3種類です。グローバルモードでは、コアに届いたリクエストをグローバルポリシーで処理しますが、プロキシを経由するかどうかは、グローバルポリシーで選んだ出口によって決まります。パソコン上のすべてのアプリが通信を取り込まれるわけではありません。ダイレクトモードでは、コアに届いた接続が宛先に直接アクセスします。初期設定の段階で3つのモードを順に試す必要はありません。まずはルールモードのままにして、次の手順でルールごとの接続結果を確認しましょう。

プロキシグループで出口を選ぶ

「プロキシ」または「Proxies」ページを開き、普段の通信に使うメインのプロキシグループを探します。「プロキシ選択」「ノード選択」のほか、サービス提供元独自の名前が付いている場合もあります。グループを開いて利用可能な出口を選んでください。設定に自動選択グループがある場合は、そのまま使ってもかまいません。グループ内には個別のノードだけでなく、別のプロキシグループが含まれている場合もあります。グループ名だけで確認を終えず、現在の選択をたどって最終的な出口を確認してください。

DIRECTは直接接続、REJECTは接続拒否を意味し、どちらもプロキシノードではありません。プロキシが必要なグループでこのどちらかを選んでいると、出口が切り替わらなかったり、ページに接続できなかったりする場合があります。すべてのプロキシグループを同じノードに変更する必要はありません。サービスごとにグループが分けられている設定では、元の構成を保つほうが使いやすく、問題の切り分けにも役立ちます。今回の動作確認で実際に使われるグループだけを変更してください。

クライアントに接続テスト機能がある場合は、メインのプロキシグループで一度テストし、出口から応答があるか確認できます。結果が示すのは指定されたテスト先との接続状況です。すべてのWebサイトにアクセスできることや、実際のダウンロード速度を保証するものではありません。すべて失敗する場合は、ノードが読み込まれているか、サービスのアカウントが有効か、端末の時刻が正しいかを確認してから、ネットワークを調べてください。速度測定を繰り返しても、接続の問題は解決しません。

ここまでで、モードがルールになっていることと、メインのプロキシグループで出口が選択されていることを確認できたはずです。設定を変えずに、次は通信を取り込みます。自動選択、フェイルオーバー、ロードバランシングの違いを知りたい場合は、後でプロキシグループの項目リファレンスをご覧ください。初回接続のために、プロキシグループを自作したりルールを並べ替えたりする必要はありません。

ステップ3：接続を有効にする

アプリの通信がクライアントに届いて初めて、ルールモードで処理できるようになります。デスクトップのシステムプロキシやTUN、モバイルのVPN接続許可は、それぞれ異なる通信の取り込み方法です。「ルール」「グローバル」「ダイレクト」の3つの動作モードとは分けて考えてください。初回は、現在のプラットフォームで最も簡単な方法を1つ使い、接続を確認してから対象範囲を広げましょう。作業前に、同じ通信を取り込む可能性がある他のプロキシやVPNツールを終了すると、ルーティングやシステム設定の競合を避けやすくなります。

デスクトップ：まずシステムプロキシを使う

WindowsやmacOSなどのデスクトップクライアントで、ホーム画面または設定を開き、「システムプロキシ」を有効にします。コアが起動していて、使用する設定も有効になっている必要があります。先に「起動」をクリックしてからシステムプロキシを有効にするクライアントもあります。システムプロキシを有効にするとOSのプロキシ設定が変更され、その設定に従うアプリが端末上の待ち受けポートに接続します。初回の確認には、システムプロキシに従うブラウザーを使いましょう。ゲームやコマンドラインツール、独自のプロキシ設定を使うアプリで、いきなり動作を判断しないでください。

ブラウザーにプロキシ切り替え拡張機能が入っている場合は、システム設定を上書きしていないか確認してください。手動でプロキシを設定したアプリも、独自の設定を使い続けることがあります。ブラウザーごとにポートを入力し直す必要はありません。まずはテストに使うブラウザーをシステムプロキシに従わせます。通常、クライアントを起動したままなら、ブラウザーで新しく発生したリクエストがコアに届きます。ウィンドウを最小化しても通常は動作しますが、クライアントを終了すると接続が切れる場合があります。バックグラウンドサービスの仕組みはクライアントによって異なります。

システムプロキシに従わないアプリも対象にする場合に限り、TUNの使用を検討してください。TUNを有効にすると、サービスのインストールや仮想ネットワークアダプターの作成、管理者権限の許可を求められる場合があります。信頼できるクライアントの案内に従ってください。システムプロキシとTUNを同時に有効にした場合の動作は、クライアントによって異なります。初回の問題切り分けでは、クライアントの説明に従って通信の取り込み方法を1つに決めてください。LAN内のリソースに接続できなくなった場合は、動作確認済みのシステムプロキシ方式に戻します。ルーティングやDNSの設定をまとめて変更するのは避けてください。

モバイル：OSの接続許可を確認

AndroidまたはiOSのクライアントで設定を有効にし、プロキシグループを選んだら、ホーム画面に戻って「接続」または起動ボタンをタップします。初回接続時には通常、VPN設定の追加やVPN接続を許可する確認画面がOSに表示されます。現在使用しているクライアントからの要求だと確認してから許可してください。要求を拒否すると、設定を追加済みでもOSから通信が渡されません。許可した後、クライアントに戻って「接続済み」または「実行中」と表示されているか確認します。

OSにVPNアイコンが表示されていれば、通信を取り込む経路は確立しています。ただし、プロキシ出口が利用できることまで保証するものではありません。アプリごとに通信を取り込んだり、対象外にしたりできるクライアントでは、テストに使うブラウザーが対象に含まれているか確認してください。省電力設定によって、しばらくするとクライアントが停止することもあります。初回確認ではアプリを通常どおり起動しておき、接続できることを確認してから、必要なバックグラウンド動作をOSの設定で許可してください。

この手順が完了したら、コアが起動していること、システムプロキシが有効になっていること、またはモバイルで接続状態が正常であることを確認します。待ち受けに失敗したと表示される場合は、ポートの競合を確認してください。許可画面が表示されない場合は、クライアントに必要なシステム権限があるか、別のVPN接続が有効になっていないかを確認します。さらに問題がある場合はトラブル対処FAQをご覧ください。システムプロキシと仮想ネットワークアダプターの違いは、TUNモードとシステムプロキシの比較で解説しています。

ステップ4：接続を確認する

スイッチの状態だけでなく、実際のリクエストと接続ログで動作を確認します。クライアントを起動したまま、ブラウザーの新しいタブで普段アクセスできるページを開き、基本的なネットワーク接続を確認してください。次に、現在のルールでプロキシ経由になるはずのページにもアクセスします。キャッシュや既存の接続が以前の経路を使い続けることがあるため、読み込み済みのタブではなく、新しいリクエストで確認しましょう。モードや出口を切り替えた後は、必要に応じて古いタブを閉じ、ページを開き直してください。

ルール、プロキシグループ、最終出口を確認する

クライアントの「接続」「Connections」またはリクエストログを開いてから、ブラウザーに戻り、対象ページを再読み込みします。対象ドメインの新しいログを探し、適用されたルール、使われたプロキシグループ、最終出口を確認してください。表示される項目の詳しさはクライアントによって異なりますが、少なくともリクエストがコアに届いたか、直接接続か選択したプロキシ経由かは確認できるはずです。ホーム画面の状態表示から推測するのではなく、今発生させた実際のリクエストを確認しましょう。

ルールモードでは一部のリクエストが直接接続されるため、通常のWebページを開けることや、ログにDIRECTと表示されることだけでは、プロキシが機能していないとは判断できません。まず対象の通信が設定上プロキシ経由になるはずか確認し、実際の結果と照らし合わせてください。外部から見える出口を確認する場合は、信頼できる出口確認サービスを利用し、そのアクセスがプロキシグループに振り分けられたこともクライアントで確認します。確認ページ自体がルールで直接接続に設定されている場合、ローカルネットワークの出口が表示されるのは正常です。

動作確認が完了した状態とは、対象ページが正常に表示され、対応するリクエストがクライアントに記録され、想定したポリシーが適用されて、最終出口が選択したノードと一致していることです。ブラウザーでは動作確認できたのに一部のアプリだけ変化しない場合は、すべてのノードをすぐに変更せず、通信の取り込み対象を確認してください。コマンドラインのプログラム、独自のネットワークスタックを使うアプリ、専用プロキシを設定したプログラムは、個別の設定や適切なTUN方式が必要な場合があります。

通信が止まる位置から問題を切り分ける

対象ページを再読み込みしても接続ログがまったく表示されない場合は、システムプロキシが有効か、ブラウザーがOSの設定を上書きしていないか、モバイルの接続が維持されているかを確認してください。接続一覧にフィルターが設定されていないか、接続終了後に一覧から削除されていないかも確認し、必要に応じてログを参照します。リクエストがコアに届いていないと確認できた場合に限り、通信の取り込み方法を調べてください。この段階ではノードのプロトコル項目を変更しないでください。

ログはあるのに接続がタイムアウトする場合は、最終出口が先ほど選んだノードになっているか確認し、同じグループ内の別の利用可能な出口を試します。特定のドメインだけ失敗する場合は、ログを見て、名前解決エラー、ルールの誤判定、接続先サービスの障害を切り分けてください。すべての接続先で失敗する場合は、サービスの有効期限、ノードの状態、現在のネットワークを確認します。変更は一度に1項目だけにして、リクエストを再送して結果を比較しましょう。どの変更が効果を与えたか判断しやすくなります。

初回の動作確認が済んだら、ルールモードと動作を確認した通信の取り込み方法を維持し、サブスクリプションの更新間隔などは後から設定できます。クライアントを終了する前に、デスクトップではシステムプロキシを無効にするか、終了時にOSの設定が正しく復元されることを確認してください。確認を怠ると、待ち受けが停止したローカルポートにアプリが接続し続けることがあります。モバイルではクライアントから切断し、OSの接続状態も終了していることを確認します。次回の起動時は通常、設定の有効性と使用するプロキシグループを確認して、再接続するだけです。

動作確認が完了しない場合は、クライアント名、OS、通信の取り込み方法、エラーが発生した手順を記録し、よくある質問とトラブル対処で該当する状況を探してください。ログを共有する前に、サブスクリプションURL、アカウント情報、ノードの認証情報を隠してください。mixed-port、DNS、カスタムルールの変更が必要な場合は、設定ファイルリファレンスをご覧ください。初回接続のために、読み込み可能な設定ファイル全体を置き換える必要はありません。