Clashの使い方ガイド

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

まず、設定の提供元からサブスクリプションURLまたはローカルのYAMLファイルを入手します。クライアントは設定を読み込み、コアを起動して通信を取り込みますが、インストールしただけで利用可能なプロキシノードが使えるようになるわけではありません。サブスクリプションURLはウェブサイトのトップページとは異なり、クライアントが認識できる設定内容を返す必要があります。形式を選べる場合は、使用中のClashクライアントまたはmihomoコアに対応しているものを選んでください。ほかのソフト向けのテキストを、ファイル名だけ変更して読み込ませないでください。

クライアントを開き、「設定」または「サブスクリプション」画面に進み、「追加」「インポート」またはプラス記号の項目を探します。URLからのインポートを選び、サブスクリプションURLを入力欄にそのまま貼り付けてください。名前は端末内で識別するためのものなので、提供元が分かる短い名称で構いません。URLの前後に空白や改行、チャットアプリが付加した句読点がないか確認してから、ダウンロードまたは保存します。取り込み結果が表示されるまで待ち、設定が重複しないよう連続して送信しないでください。

ダウンロードが完了すると、通常は設定一覧に項目が追加されます。その項目をタップするか、横にある「有効化」「使用」などの操作を選び、現在の設定として適用します。取り込みと同時に自動で有効になるクライアントもあれば、ファイルを保存するだけのものもあります。「ダウンロード成功」という表示だけで判断せず、選択中の設定を示すマークを確認してください。次に「プロキシ」画面を開き、設定で定義されたプロキシグループが表示されているか確認します。設定ファイルはあるのに想定したグループが表示されない場合は、設定画面に戻り、有効な設定とエラー内容を確認してください。

ローカルファイルを使う場合は、同じ画面で「ファイルからインポート」を選択し、保存済みの .yaml または .yml ファイルを指定して開きます。ファイルのインポートは通常、ローカルにコピーを保存するもので、リモート更新の設定とは異なります。提供元がノード情報を更新した場合は、ファイルを再インポートするか、提供元のサブスクリプション機能を利用してください。設定ファイル内のノード部分だけを完全な設定として読み込ませないでください。初めて使う場合は、提供元が用意した互換性のある設定一式を使いましょう。

インポートに失敗したら、まず取得した内容を確認

ダウンロードのタイムアウト、形式エラー、読み込み失敗が起きたら、まず具体的なエラーメッセージを控えてください。プロキシを有効にしていない状態で端末がインターネットに接続できるか、サブスクリプションURLの有効期限が切れていないか、提供元のページからURLをコピーし直す必要がないかを確認します。ログインページやエラーページ、非対応形式の内容が返されていると、解析に失敗することがあります。クライアントに「プロキシ経由で更新」の設定があり、まだ接続を確立できていない場合は、現在のネットワーク環境に応じて直接更新してください。起動していないプロキシに更新処理が依存するのを避けられます。

サブスクリプションURLにはアカウントを識別する情報が含まれることがあります。アクセス情報と同じように慎重に扱ってください。トラブルの相談時も、URL全体、QRコード、設定ファイル全文を公開コメント欄に投稿しないでください。エラーを記録する場合は、エラーの種類だけを残し、スクリーンショットは情報を隠してから共有します。サブスクリプションの形式や更新について詳しくはよくある質問をご覧ください。ここではまず、接続手順を続けましょう。

更新でローカルの変更が上書きされないか確認

初回のインポートが完了したら、手動で一度「更新」を実行し、提供元から再取得できることを確認します。次回の更新で内容が置き換わる可能性があるため、ダウンロードした設定本文を大幅に編集するのは避けてください。DNS、ルール、ポートを変更する必要がある場合は、クライアントのオーバーライド機能を確認しましょう。詳しくはmihomo上級設定ガイドで解説しています。ここでは設定が有効で、プロキシグループが表示されていることを確認してから、モード選択に進みます。

ステップ2：プロキシモードとプロキシグループを選択

設定の読み込みが完了したら、クライアントのホーム画面またはプロキシ設定に戻り、モード選択を開きます。一般的な選択肢は「ルール」「グローバル」「ダイレクト」で、コア内の rule、global、directに対応します。初めて使う場合はルールモードを選び、設定に記述されたルールに接続先のポリシーを決めさせましょう。接続を確実にするために、複数の通信設定を同時に有効にする必要はありません。モードが決めるのはコアに入った後の処理方法であり、アプリの通信をコアに取り込む機能ではありません。

ルールモードでは、設定内のルールを上から順に照合し、最初に一致したルールで接続先のポリシーが決まります。たとえば、あるドメインはプロキシグループへ、別のリクエストは DIRECTへ振り分けられます。振り分け方は現在の設定によって異なり、すべてのサブスクリプションで共通ではありません。そのため、ルールモードを選んだ後も「プロキシ」または「プロキシグループ」画面を開き、ルールが使う主要なグループの接続先を確認してください。

手動選択グループで、提供元が用意した現在利用可能なノードをタップするか、設定済みの自動選択グループを選びます。グループ名は設定によって異なり、「プロキシ」「ノード選択」などさまざまです。特定の名前を探す必要はありません。グループ内に別のグループが表示される場合は、その下の選択先まで確認してください。上位グループの接続先がダイレクトなら、使われていない別のグループ内でノードを切り替えても、そのリクエストの実際の出口は変わりません。

クライアントに疎通テスト機能があれば、ノード選びの参考として一度実行できます。テストの成功は、その条件で接続できたことを示すだけで、すべてのウェブサイトやプロトコルが使えるとは限りません。テスト先の影響でタイムアウトする場合もあります。まず基本的なアクセスができるノードを1つ選び、最終的な動作はステップ4で実際のリクエストを確認してください。テスト結果や数値だけで判断しないようにしましょう。

グローバルモードは比較用。通信の取り込み設定の代わりにはならない

ルールモードで特定のサイトに接続できない場合は、一時的にグローバルモードへ切り替え、グローバルポリシーで実際に選ばれているノードを確認してから、もう一度アクセスします。グローバルモードでは接続でき、ルールモードでは失敗する場合は、DNSをすぐに変更するのではなく、適用ルールとプロキシグループを確認してください。テスト後はルールモードに戻し、本来なら直接アクセスできる通信までプロキシ経由にならないようにします。

グローバルモードにしても、端末のすべての通信がプロキシ経由になるわけではありません。システムプロキシに従わないアプリは、引き続きコアを経由せず通信する場合があります。より広い範囲の通信を取り込む必要がある場合に、TUNを検討してください。ダイレクトモードもクライアントの終了を意味するものではなく、システムプロキシやVPNによる通信の取り込みが有効なままの場合があります。この違いを理解したら、ルールモードと選択したポリシーを維持し、次はアプリのリクエストをコアに取り込む設定を行います。ルールやグループの種類については、プロキシグループの設定をご覧ください。

ステップ3：システムプロキシまたはモバイルVPNを有効化

クライアントに設定の読み込みエラーがなく、ホーム画面でコアの起動中が確認できること、または接続ボタンから起動できることを確認します。設定の有効化、コアの起動、通信の取り込みはそれぞれ別の段階です。設定があってもコアが起動していなければリクエストを処理できず、コアが動いていても通信が取り込まれていなければ、ブラウザーは従来のネットワーク経由でアクセスする場合があります。この段階では、システムプロキシ、TUN、別のVPNを同時に有効にせず、通信を取り込む方法を1つに絞って結果を確認しましょう。

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

Windows、macOS、Linuxのクライアントで「システムプロキシ」のスイッチを探して有効にします。システムの許可を求められた場合は、端末の案内に従って許可し、スイッチが有効のままになっているか確認してください。通常、ブラウザーにノードのサーバーアドレスを入力する必要はありません。システムプロキシの接続先はローカルのコア待ち受けポートで、コアが設定に従ってリモートの出口を選びます。

システム設定を確認する場合は、使用中のアドレスとポートがクライアントの設定と一致しているかを見ます。一般的なローカルアドレスは 127.0.0.1です。本サイトの例では混合ポートとして mixed-port: 7890を使用していますが、クライアントによってポートは異なるため、現在有効な設定を確認してください。ブラウザーにプロキシ拡張機能が入っている場合は、古いポートへの接続が優先されないよう、まずブラウザーがシステムプロキシを使う設定にします。初回の操作では、LAN接続の許可を有効にする必要はありません。

ポートが使用中と表示される場合やコアの起動に失敗する場合は、システムプロキシを何度も切り替えるだけでは解決しません。同じポートを使用している可能性のある別のプロキシクライアントを終了してから、再度起動してください。待ち受けポートを変更する場合は、システムプロキシ側のポートも合わせて変更します。Linuxのデスクトップ環境やアプリによっては、システムプロキシへの対応状況が異なります。ブラウザーでは使えてもターミナルのプログラムで使えないからといって、必ずしもコアの障害とは限りません。ここでは、システムプロキシに対応したブラウザーで動作を確認しましょう。

モバイル：VPNの許可と接続状態を確認

AndroidまたはiOSのクライアントで、ホーム画面の「接続」または起動ボタンをタップします。初回にVPN設定の追加やVPN接続の確立を求めるダイアログが表示されたら、現在使っているクライアントからの要求であることを確認し、画面の案内に従って許可してください。端末のロック解除が必要な場合もあります。クライアントに戻って接続状態が更新されるのを待ち、システム側のVPN状態も確認します。許可しただけでは通信の取り込みが認められた段階なので、ノードが使えるかは実際のリクエストで確認してください。

端末で別の通常のVPN接続を使っている場合は、現在のクライアントを起動する前に切断し、システムが接続を切り替えたことで判断が難しくならないようにします。Androidクライアントでアプリごとのプロキシ設定や除外リストを使っている場合は、テストするブラウザーが通信の取り込み対象になっているかも確認してください。初回はクライアントの初期設定のままでテストし、接続を確認してから対象を絞り込みます。リストの意味を理解しないまま、複数のアプリを除外しないでください。

ここまでの操作が終わったらクライアントを起動したままにし、ブラウザーで新しいタブを開きます。クライアントのホーム画面に「接続済み」と表示されているかだけで判断しないでください。この段階でできたのは通信経路の確立です。リクエストがどのルールと出口を通ったかは、次のステップで確認します。

ステップ4：接続ログで通信ルールを確認

設定上、直接アクセスする想定のサイトと、プロキシ経由でアクセスする想定のサイトを1つずつ用意します。ブラウザーの新しいタブからアクセスし、クライアントの「接続」「アクティブな接続」またはログ画面を開いてください。対象のドメインやアドレスが表示されているか、適用ルール、ポリシーの経路、最終的な出口を確認します。クライアントによって表示項目は異なりますが、ブラウザーのアクセスとコアの処理記録を対応づけることが目的です。

サイトが開き、対応する接続を確認できたら、想定したポリシーが使われているかも確認します。記録が DIRECTなら、その接続にダイレクトが選ばれたという意味で、クライアントが動作していないわけではありません。プロキシグループが表示されている場合は、上位グループ名だけで判断せず、展開するか詳細を確認して最終ノードを調べてください。プロキシルールをテストするときは、そのルールに一致するドメインを選びます。どのウェブページでも開けるというだけでは、プロキシ出口が使われた証拠になりません。

次に、直接アクセスする想定のサイトも開き、ルールモードで両方のリクエストが適切に処理されるか確認します。出口IPの確認サイトは補助的な情報にとどめてください。そのサイト自体がダイレクトのルールに一致する場合があり、ブラウザーのキャッシュや既存の接続も確認の妨げになります。ノードを切り替えた直後は新しいリクエストを作成し、必要であれば対象のアクティブな接続だけを切断して再試行します。確認のために閲覧履歴全体を書き出したり、接続一覧を公開したりしないでください。

結果が想定と異なる場合は、通信経路に沿って確認

ブラウザーからリクエストを送っているのに、クライアントに該当する接続がまったく表示されない場合は、まず通信の取り込みを確認します。システムプロキシが有効か、アドレスとポートが一致しているか、ブラウザー拡張機能が設定を上書きしていないか、モバイルでブラウザーが除外されていないかを調べてください。接続一覧がアクティブな接続だけを表示するクライアントでは、短いリクエストがすぐに消えることがあります。ログも併せて確認しましょう。リクエストがコアに届いていない段階では、ノードやルールを変更しても通常は解決しません。

接続は表示されているのにポリシーが違う場合は、ステップ2に戻り、モード、上位グループの選択、適用ルールを確認します。想定したノードに接続されているのに失敗する場合は、同じ設定内の別の利用可能なノードを試し、エラー内容を比較してください。ドメイン名の解決失敗など、DNSに関係する兆候がある場合にDNSを確認します。モード、ノード、DNS、TUNを同時に変更しないでください。一度に変更する条件を1つに絞り、同じ接続先へ再アクセスすると、どの変更が影響したか判断できます。

ブラウザーではルールに従ってアクセスできるのに、特定のアプリだけ失敗する場合は、そのアプリがシステムプロキシに対応しているか、独自のプロキシ設定を使っているか、通信の取り込み対象になっているかを確認します。初回接続の段階でDNSやFake-IPの仕組みをすべて把握する必要はありません。関連が疑われる問題が起きたら、Fake-IPの設定をご覧ください。ほかの症状と対処方法はよくある質問にまとめています。発生しているエラーに合わせて確認してください。

使用を終了して元のネットワークに戻す

動作確認が終わり、使用を終了する場合は、デスクトップではクライアントのシステムプロキシを無効にしてからクライアントを終了します。モバイルではクライアントの接続を切り、システムのVPNが終了したことを確認してください。プロセスだけを終了して、ローカルポートを指すシステムプロキシを残すと、ブラウザーが待ち受けを停止したサービスへ接続しようとする場合があります。終了後にウェブサイトを開けなくなったら、まずシステムのネットワーク設定でプロキシの状態を確認し、事前に控えた設定に戻してください。組織管理端末では、管理者の指示に従ってください。

次回起動時は、「現在の設定 → ルールモードとポリシー → 通信の取り込み設定 → 実際のリクエスト」の順に確認すれば十分です。サブスクリプションを更新した後も、グループ名や振り分けルールが変更されていることがあるため、簡単に動作確認しましょう。これで設定のインポートから接続ログの確認まで、一通りの手順は完了です。ルールセット、ローカルオーバーライド、外部コントローラーが必要になったら、上級設定ガイドで個別に設定してください。初回からすべての機能を有効にする必要はありません。