初期設定 · 4ステップ

Clashの使い方ガイド
サブスクリプションの追加と接続確認

「設定 → モード → 接続 → 確認」の順に進めます。クライアントをインストール済みで有効なサブスクリプションがあれば、初回確認は約10分で完了します。ダウンロード時間とサブスクリプションサービスの応答時間は含みません。

始める前に、端末がインターネットに接続できることを確認し、サブスクリプション提供元から発行されたClashまたはmihomo対応のサブスクリプションURLを用意してください。クライアントは設定を読み込み、接続を中継するソフトウェアです。インストールしただけでは利用可能なノードは作成されません。サブスクリプションには通常、ノード、プロキシグループ、ルーティングルールが含まれます。内容は提供元が管理しており、対応プロトコルもクライアントのコアによって異なります。

初回は設定をシンプルに保ちます。サブスクリプションは1つ、ノードは1つ、通信を取り込む方法も1つにして、結果を確認してください。DNS、TUNルート、複数のルールを同時に変更すると、問題の原因を特定しにくくなります。ほかのプロキシクライアントが接続中の場合は先に切断し、テスト後に戻せるよう元のネットワーク設定を控えておきましょう。

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

クライアントを開き、サイドバーまたは画面下部のメニューから「サブスクリプション」「設定」「設定管理」のいずれかを選びます。「新規作成」「サブスクリプションを追加」「URLからインポート」などを選び、リモートサブスクリプションを指定してください。コピーしたURLを入力欄に貼り付け、先頭や末尾に余分な空白、改行、チャットアプリが付けた句読点がないか確認します。見分けやすい名前を付けてもかまいません。名前は一覧表示用で、接続には影響しません。

必要なのは設定内容を返すサブスクリプションURLであり、サービス提供元のトップページ、ログインページ、決済ページではありません。提供元によって汎用サブスクリプション、Clash用、ほかのクライアント用に分かれている場合は、現在のコアに対応した項目を選んでください。出所の不明なオンライン変換サイトにURLを入力するのは避けましょう。URLのパラメーターにアカウントの認証情報やプラン情報が含まれる場合があります。スクリーンショットを共有する際も、URL全体を隠してください。

「保存」「インポート」「ダウンロード」などを押し、取得と読み込みが終わるまで待ちます。成功すると、作成した項目が設定一覧に表示されます。クライアントによっては、更新日時や設定名も表示されます。続いて項目の「使用」「有効化」を選ぶか、ラジオボタンで現在の設定に指定してください。一覧に表示されただけでは有効化されていません。新しい項目が現在の設定として選ばれていることを確認します。

次に「プロキシ」画面を開き、プロキシグループと選択可能なノードが表示されているか確認します。総合的な入口、自動選択、用途別のポリシーグループなど、グループが複数あるのは通常の状態です。画面が空の場合は、設定一覧に戻って有効化できているか確認し、エラーメッセージも確認してください。インポートボタンを押して反応が見えなくても、同じURLを何度も追加しないでください。区別しにくい複製が増えてしまいます。

ローカルのYAMLファイルだけを使う場合は、「ファイルをインポート」からシステムのファイル選択画面を開いて追加し、現在の設定に指定します。ローカルファイルがリモートのルールセットや別のリソースを参照していることもあります。そのため、インポートが成功しても必要なリソースの取得が完了したとは限りません。設定状態を確認し、解析エラーやリソース読み込みエラーが続いていないことを確かめてから、モードを選びましょう。

「形式エラー」「解析失敗」が表示された場合は、まずサブスクリプションの種類とコアの互換性を確認します。タイムアウトや取得失敗の場合は、通常のネットワークから再試行し、サブスクリプションの有効期限も確認してください。初回のインポートでは、高度なネットワーク設定をむやみに変更しないようにします。提供元が接続中のプロキシ経由での更新を求める場合は、別の利用可能な接続が必要です。初回に直接取得する場合とは異なる状況です。

サブスクリプションの更新は通常、既存項目のメニューから行えます。毎回作り直す必要はありません。リモート設定を更新すると、直接編集した内容が上書きされる場合があります。使い始めの段階では提供元のルールをそのまま使いましょう。カスタムルールを継続して使う場合は、プロトコルとコアの技術ガイドを読み、クライアントが対応する上書き方法を確認してください。ここでは有効化した設定名を覚えておき、次の手順に進みます。

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

クライアントのホーム画面または「プロキシ」画面に戻り、「モード」「出力モード」などの項目を探します。一般的な選択肢は「ルール」「全体」「直接接続」です。初期設定ではルールモードを選びます。接続は現在の設定内のルールを上から順に照合し、該当したルールに指定されたポリシーで処理されます。これにより、サブスクリプションのルーティング設定を確認しながら、すべてのアプリの通信を一律に変更せずに済みます。

ルールモードは「すべての通信をプロキシ経由にする」モードではありません。接続によってはプロキシグループに振り分けられ、DIRECTで直接接続されたり、REJECTで拒否されたりします。そのため、特定のサイトが直接接続されても、すぐにクライアントが動作していないと判断しないでください。接続ログを見て、どのルールに該当したか確認します。このガイドでは、ルールの具体的な順序は変更しません。

モードを決めたらプロキシグループ一覧を開き、設定で実際に使われている総合的な入口グループを探します。名前は「ノード選択」「Proxy」や提供元独自の名称などさまざまで、全クライアント共通の名前はありません。グループを開いて候補ノードを選び、選択マークが表示されることを確認してください。選択した項目が別のプロキシグループの場合は、さらに下の階層を開き、最終的に使うノードや選択方法を確認します。

「自動選択」グループでは、通常、設定内のテスト方法に基づいて候補ノードが選ばれます。手動選択グループでは、自分でノードを選びます。初回の確認を分かりやすくするため、利用できると分かっているノードを1つ選び、複数のノードを頻繁に切り替えないようにしましょう。対象の通信に関係しない用途別グループだけを変更しても、ルールが実際に参照している入口の選択は変わらない場合があります。

クライアントに遅延テスト機能があれば、一度実行して応答する候補ノードがあるか確認できます。遅延テストはノード選びの参考にすぎません。ログイン、ダウンロード、リアルタイム通信が正常に行える保証にはなりません。テスト先、ノードの負荷、ローカルネットワークによって結果も変わります。応答がない場合は、失敗したノードを控えておき、すぐにDNS設定をすべて変更しないでください。実際に使えるかどうかは、ステップ4で通信を試して確認します。

全体モードは、一時的な比較に利用できます。ルールモードで特定の接続に問題がある場合、全体モードに切り替えて対応するプロキシグループを選び、同じ接続先で結果が変わるか確認します。テスト後はルールモードに戻してください。直接接続モードでは、コアを経由する通信をそのまま外部へ接続します。どのモードを選んでも、アプリの通信がクライアントに届くとは限りません。次の手順でシステムプロキシを設定するか、モバイル端末で接続を許可する必要があります。

自動選択、フェイルオーバー、手動選択の違いが分からない場合は、サブスクリプションの初期設定をそのまま使えば問題ありません。新しいプロキシグループを作る必要はありません。関連する疑問はよくある質問、プロトコルの違い、コアの対応状況、設定の互換性はプロトコル解説で確認できます。このステップでは、モードと接続経路を明確にすることが目的です。すべての最適化を済ませる必要はありません。

ステップ3:接続を開始してプラットフォームの許可を完了

ホーム画面に戻り、コアが正常に動作していることを確認します。「起動」「実行」などのボタンが別にある場合は、まずコアを起動してから通信の取り込みを有効にしてください。コアの起動、システムプロキシの有効化、TUNの有効化はそれぞれ別の状態です。コアが動作中でもアプリのリクエストを受け取っていないことがあり、コアの停止後もシステムプロキシの設定が残る場合があります。初回接続では、トレイにアイコンがあるかだけで判断せず、それぞれの状態を確認してください。

デスクトップ:まずシステムプロキシでブラウザーを確認

設定画面またはホーム画面で「システムプロキシ」を探して有効にします。通常、この設定を有効にするとOSのプロキシ先がクライアントのローカル待ち受けポートになり、システム設定に従うブラウザーやアプリがリクエストをクライアントに送ります。まずはクライアントの既定ポートを使い、LANからのアクセスはむやみに許可しないでください。ブラウザーでテストページを開き直します。古い接続が残っている場合は、該当するタブを閉じてからアクセスしてください。

ブラウザーの拡張機能やアプリによっては、独自のプロキシ設定があり、システムプロキシより優先されることがあります。初回の確認では、個別にプロキシを設定していないブラウザーを使い、ネットワーク通信を重複して制御する拡張機能は一時停止してください。ポートが使用中と表示された場合は、ほかのプロキシクライアントが起動していないか確認します。ポートを何度も変更し、アプリ側のプロキシ設定を更新し忘れると、コアは正常でもリクエストが古いポートに送られてしまいます。

システムプロキシですべてのアプリを制御できるわけではありません。ゲーム、コマンドラインツール、独自に接続を確立するアプリなどは、システム設定を参照しない場合があります。これは通信の取り込み方法の制限であり、サブスクリプションが無効とは限りません。まずブラウザーで確認してください。そうしたアプリも制御する必要がある場合に限り、TUNを検討します。基本的な接続を確認する前に、システムプロキシ、TUN、ほかのVPNツールを同時に有効にしないでください。

モバイル:接続をタップしてVPN接続を許可

ホーム画面の接続ボタンをタップします。初回起動時に、システムからVPN構成の追加やVPN接続の許可を求められる場合があります。インストールしたクライアントからの要求であることを確認してから許可してください。端末によっては、システム認証も必要です。クライアントに戻ったら、接続状態が実行中になるまで待ち、システムにVPN状態が表示されていることを確認します。この表示はシステムの接続機能が有効になったことを示すもので、実際のアクセスで接続先ノードを確認した結果ではありません。

ほかのVPN接続があると表示された場合は、使用中の同種ツールを先に切断してから、クライアントを再起動してください。モバイルOSや端末管理ポリシーによって、同時に接続できる数が制限されている場合があります。複数の接続スイッチを同時にオンにしても、問題の解決にはなりません。バックグラウンドに移るとすぐ切断される場合は、まずアプリを前面に出した状態でアクセスを確認します。その後、OSのバッテリー管理やバックグラウンド実行制限を確認してください。最初から省電力設定をすべて変更する必要はありません。

TUN:基本的な接続を確認してから有効化

TUNが必要な場合は、クライアントの設定から該当項目を探し、案内に従ってサービスをインストールするか、管理者権限を付与するか、ネットワーク拡張機能を許可します。必要な操作はプラットフォームごとに異なります。「常に管理者として実行」がすべてのクライアントで必要なわけではありません。TUNは仮想ネットワークアダプター、ルーティング、DNSの制御に関わります。詳しくはプロトコルとコアの技術ガイドを参照してください。今回、システムプロキシまたはモバイルの既定の接続方式だけを使っても、初期設定の手順は完了できます。

ステップ4:接続とルールの動作を確認

現在の設定でプロキシ経由になるはずのWebページを開き、クライアントの「接続」「アクティブな接続」「ログ」画面を表示します。ページを再読み込みし、アクセスしたドメインに関する記録を探してください。ログの既定表示が警告のみの場合は、一時的に情報レベルへ切り替えてから再試行し、確認後に元へ戻します。画面の名称はクライアントによって異なりますが、今回のリクエストがクライアントで処理された証拠を探す点は同じです。

まずリクエストの記録があるかを確認します。該当する記録がまったくない場合は、ノードをすぐ変更するのではなく、ステップ3に戻ってシステムプロキシ、モバイルの接続状態、アプリ独自のプロキシ設定を確認してください。既存の長時間接続は切り替え前の経路を使い続けることがあります。古いタブを閉じるかテスト用アプリを再起動して、新しいリクエストを送ってください。モードを切り替えて一度再読み込みするだけでは、既存接続の影響を除けない場合があります。

記録があれば、次に適用されたルールと最終ポリシーを確認します。プロキシ経由になる想定のドメインは、設定内のいずれかのルールに一致し、先ほど選んだプロキシグループに送られるはずです。最終的なノードもステップ2で選んだものと一致するか確認します。直接接続が想定されるリクエストにDIRECTと表示されるのは正常です。拒否ポリシーが表示された場合は、設定内のブロックルールに一致していないか確認してください。ネットワークのタイムアウトとは別の問題です。

次に、直接接続になる想定のサイトも試し、正常に開けることと出力ポリシーを確認します。両方を確認することで、クライアントが通信を中継できるかだけでなく、ルールによる振り分けが想定どおりかも判断できます。接続元IPアドレスを調べるWebページを1つ見るだけでは、そのページへのリクエストの出口しか分かりません。ほかのアプリ、すべてのドメイン、すべてのプロトコルが同じ経路を使っている証明にはなりません。

記録が想定どおりのプロキシグループに届いているのにページが開けない場合は、同じグループ内で別の候補ノードを選び、同じテストを繰り返してください。ほかの設定を変えなければ、特定のノードに問題があるか判断しやすくなります。すべての候補で失敗する場合は、サブスクリプションの有効性、ローカルネットワークの状態、接続タイムアウトやプロトコル非対応のログを確認します。ネットワーク、モード、DNS、ノードを次々に切り替えてから、どれが解決につながったか推測するのは避けてください。

全体モードではアクセスできるのに、ルールモードで想定どおりにならない場合は、一時的にログを比較し、適用されたルール、現在の設定、ルールの対象、プロキシグループの選択を確認します。ブラウザーは正常で特定のアプリだけ問題がある場合は、そのアプリがシステムプロキシに従うか、追加の通信取り込みが必要かを確認してください。サブスクリプションの取得失敗、DNSの異常、LANアクセス、スリープ復帰後の切断などは、よくある質問とトラブルシューティングを参照してください。初期設定ですべてを個別に調整する必要はありません。

確認が終わったらルールモードに戻し、利用できると確認したプロキシグループの選択を維持します。一時的に変更したログレベルも元に戻してください。OS起動時に自動起動する場合は、「クライアントを起動」と「起動後に接続」の意味をそれぞれ確認します。通常、別々の設定です。次回の再起動後も動作状態を確認してください。クライアントのウィンドウが開いているだけで、通信の取り込みも復旧したと判断しないようにします。

使用を終えるときは、デスクトップではシステムプロキシを無効にするか、クライアントを正常に終了します。モバイルでは切断ボタンで接続を終了してください。クライアントの異常終了後にネットワークへ接続できない場合は、サブスクリプションを削除する前に、システムにローカルプロキシの設定が残っていないか、別のVPN接続がないか確認します。動作確認済みの設定は残しておきましょう。問題が起きた場合は、「設定、モード、通信の取り込み、リクエスト記録」の順に、この4ステップで原因を確認できます。