初期設定 · 4ステップ
Clash入門ガイド.
サブスクリプションを追加 → プロキシモードを選択 → 接続 → 動作確認。
ここでは、インストール済みのLinuxデスクトップクライアントを使い、初回接続に必要な設定を順に進めます。信頼できる提供元のサブスクリプションURLを用意し、4つの手順に沿って操作すれば、基本設定は通常10分ほどで完了します。サブスクリプションの取得、システム権限の許可、ネットワークのトラブルシューティングにかかる時間は含みません。クライアントをまだインストールしていない場合は、先にLinux版のダウンロードからインストール形式を選び、完了後に戻って続けてください。
このページでは初回接続を使える状態にするところまでを扱い、設定ファイルの編集は行いません。プロトコルの互換性、カーネルの種類、選び方についてはプロトコルとカーネルの技術ガイドをご覧ください。
ステップ1：サブスクリプションを追加して有効化
サブスクリプションURLは、クライアントが設定を取得するためのもので、ブラウザーで開く一般的なWebページではありません。ノード、ポリシーグループ、ルーティングルールが含まれる場合もあれば、ノード情報だけの場合もあります。初めて使うときは、現在のクライアントと互換性のある完全なClashまたはmihomo設定のサブスクリプションを用意してください。クライアント自体に利用可能なプロキシサービスは付属していないため、インストール後に利用権限のある設定を別途用意する必要があります。
リモートサブスクリプションを追加して設定を取得する
クライアントを開き、サイドバーまたは画面下部から「サブスクリプション」「設定」「Profiles」などを探します。リモート設定の追加を選択してください。画面に「ローカルファイル」と「リモートURL」の選択肢がある場合は、リモートURLを選びます。コピーしたサブスクリプションURLを入力欄に貼り付け、「普段使い」など見分けやすい名前を付けてから、インポート、ダウンロード、または保存を選択します。画面によっては、先に項目を保存してから横にある更新ボタンを押す必要があります。操作後、ダウンロード中の表示のままではなく、設定名が表示されていることを確認してください。
貼り付ける前に、URLの前後に空白や改行、チャットアプリが付け加えた説明文が含まれていないか確認します。サブスクリプションURLには個人用のアクセス情報が含まれることがあります。URL全体を公開の掲示板に投稿したり、よく知らないオンライン変換サイトに渡したりしないでください。取得に失敗したら、まず画面に表示されたエラーを確認します。ネットワークのタイムアウト、認証失敗、設定形式のエラーはそれぞれ原因が異なるため、同じ更新ボタンを繰り返し押しても解決しないことがあります。
設定を選択してプロキシ画面を確認する
インポートに成功しても、設定が有効になったとは限りません。追加した設定名、選択マーク、または「使用」ボタンをクリックし、現在の設定として適用します。選択中の枠や使用中の表示、適用完了の通知などが目印です。次に「プロキシ」画面を開き、ポリシーグループとノード名が表示されているか確認してください。古い設定の内容が表示されたままなら、設定一覧に戻って選択状態を確認し、手動で適用する操作が必要かどうかも確認します。
ローカル設定ファイルしかない場合は、「ファイルからインポート」を選び、該当するYAMLファイルを読み込みます。その後、同じように選択して適用してください。拡張子だけでは内容の互換性は保証されません。また、ノードだけが記載されたファイルにルーティングルールが含まれているとは限りません。必要な項目がない、または解析できないというエラーが表示されたら、設定の提供元に形式を確認してください。エラーを消すために、内容のわからない設定項目を削除しないでください。
初回接続の前は、更新間隔をデフォルトのままにしておき、動作確認後に調整できます。リモート更新によって、サブスクリプションファイルに直接加えた変更が上書きされることがあります。ルールを今後も維持したい場合は、更新のたびに編集し直すのではなく、クライアントのオーバーライド機能を確認してください。サブスクリプションが開けない、更新後に設定が変わったなどの問題は、サブスクリプション関連のよくある質問をご覧ください。
ステップ2：モードとノードを選択
設定を読み込んだら、クライアントのモード選択を探します。一般的な選択肢は「ルール」「グローバル」「直接接続」で、Rule、Global、Directと表示される場合もあります。モードによって通信の出口を選ぶルールが決まりますが、システムプロキシやTUNのオン／オフとは別の設定です。まず通信の振り分け方式を決め、次の手順でアプリの通信をクライアントに取り込みます。問題が起きたとき、どの層で動作していないか切り分けやすくなります。
初めて使う場合はルールモードを選択
「ルール」を選ぶと、コアが設定内のルールを上から順に照合し、直接接続するか、ポリシーグループに渡すか、その他の方法で処理するかを決定します。普段使いに適したモードですが、現在の設定に適切なルールが含まれていることが前提です。ルールモードでも、すべてのサイトがプロキシ経由になるわけではなく、すべてのローカル通信が直接接続されるとも限りません。実際の判定結果は接続ログで確認してください。
「グローバル」は通常、コアに取り込まれた通信をグローバルポリシーグループに渡すため、短時間の比較テストに使えます。ただし、クライアントに取り込まれていないアプリの通信を自動で処理するものではありません。「直接接続」は、コアに取り込まれた通常の通信を宛先へ直接送ります。クライアントを終了したり、システムプロキシを解除したりすることとは別です。初期設定では3つのモードを何度も切り替えず、ルールモードのままノードと接続設定を確認してください。
ルールから実際に参照されるポリシーグループを開く
プロキシ画面で、設定に含まれるメインのポリシーグループを探します。名前は設定の作成者によって異なり、「プロキシ選択」「PROXY」などの場合があります。手順に合わせるために名前を変更する必要はありません。グループ内のノードを1つ選択し、現在の選択として表示されることを確認してください。グループが別のポリシーグループを含む場合はさらに開き、直接接続を誤って選ぶのではなく、最終的に実際のノードが選択されていることを確認します。
設定によっては、Web、メディア、その他のアプリ向けに複数のグループが用意されています。初回はグループ構成を変えず、使用するメインのグループだけを調整してください。特定のサイトが専用グループに振り分けられた場合は、そのグループの選択も確認します。自動選択グループは設定されたテスト方法に基づいてノードを選び、手動選択グループはユーザーが選んだノードを維持します。問題の切り分けをしやすくするため、初回テストでは手動選択グループでノードを固定し、動作確認後に自動切り替えを検討してください。
ノードの遅延テスト：まず接続可否、次に数値を確認
プロキシ画面で速度テスト、遅延テスト、または更新アイコンを探し、テストを1回実行します。多くの遅延テストは、ノード経由でテスト用の宛先にアクセスし、リクエストにかかった時間を表示するもので、ダウンロード帯域の測定ではありません。タイムアウトは今回のテストに失敗したことを示しますが、テスト先や名前解決、一時的なネットワーク状態が原因の可能性もあります。遅延が短くても、すべてのサイトへ快適にアクセスできるとは限りません。
まず応答のあったノードを1つ選び、実際のWebページで確認します。閲覧しながらノードを次々とまとめてテストしたり、数ミリ秒の差だけを理由に頻繁に切り替えたりしないでください。すべてのノードがタイムアウトする場合は、最初の手順に戻り、設定が正しく適用されているか、サブスクリプションが有効かを確認したうえで、トラブルシューティングを参照してください。プロトコル名とmihomoの対応範囲の違いはカーネル技術ガイドで確認できます。この手順ではプロトコルの設定変更は不要です。
ステップ3：接続とシステムプロキシを有効にする
現在の設定、ルールモード、選択したノードがそろったら、アプリの通信をクライアントに取り込みます。まずホーム画面の動作状態を確認してください。起動ボタンが別にある場合はコアを起動します。クライアントを開いた時点ですでに動作していれば、再度起動する必要はありません。設定の読み込み失敗やポートの競合など、明確なエラーがある場合は先に対処してください。ウィンドウが開いているだけでコアが正常だと判断しないようにしましょう。
デスクトップではまずシステムプロキシを有効にする
設定画面、ホーム画面のクイック設定、またはシステムトレイのメニューから「システムプロキシ」を探して有効にします。クライアントは、デスクトップ環境またはOSのプロキシ設定をローカルの待ち受けアドレスに変更します。有効にした後、ブラウザーを開き直すか、新しいリクエストを送信してください。既存の長時間接続は以前の経路を使い続ける場合があるため、開きっぱなしのページだけで設定の効果を判断しないでください。
Linuxでは、デスクトップ環境やアプリによってシステムプロキシの読み取り方法が異なります。GNOMEやKDEでは、それぞれのシステム設定からプロキシを確認できますが、一部のターミナルアプリ、独立してパッケージ化されたアプリ、独自にネットワークを管理するプログラムは自動で従わないことがあります。ブラウザーにプロキシ拡張機能が入っている場合、拡張機能がシステム設定を上書きすることもあります。初回テストではシステムプロキシを使うブラウザーを選び、プロキシ拡張機能を一時的に無効にして、設定が競合しないようにしてください。
WindowsやmacOSでも、まずシステムプロキシで基本的な動作を確認します。別のプロキシクライアントやVPNを起動している場合は、不要な方を終了し、複数のツールが設定を取り合わないようにしてください。別のウィンドウを最小化しただけでは、サービスが停止しないことがあります。待ち受けポート、DNS、複数のネットワーク設定を同時に変更せず、一度に1つだけ変更して結果を確認してください。
モバイルではシステムのVPN接続を許可する
AndroidやiOSのクライアントは通常、ホーム画面の接続ボタンからシステムVPNトンネルを確立します。初回のタップ時にVPN設定の追加や接続の許可を求められたら、要求元のアプリを確認してから許可してください。ここでいうVPNは、システムに通信を取り込む仕組みであり、サブスクリプションの設定が自動的に正しくなるという意味ではありません。許可後も、選択した設定とノードを確認し、システムに接続状態が表示されているか確認してください。
Androidでは、バックグラウンドの省電力機能によって画面消灯後にクライアントが一時停止することがあります。まずアプリを前面に表示した状態で4つ目の手順を行い、基本的な接続を確認してから、必要に応じてバックグラウンド実行を許可してください。端末が別のVPNに接続中の場合、現在の接続を切り替えるよう求められることがあります。仕事用または学校用のネットワークがそのVPNを必要としていないか確認してから判断してください。
TUNモード：必要な場合にのみ有効化
ブラウザーは正常に動作する一方、対象アプリがシステムプロキシを使わない場合は、TUNを検討できます。仮想ネットワークインターフェースを通じて、より多くの通信を取り込みますが、対象範囲はルーティング、除外設定、クライアントの実装によって異なります。すべてのアプリを動作させる万能スイッチではありません。デスクトップクライアントによっては、補助サービスのインストールや管理者権限の許可が必要です。Linuxでは仮想インターフェース、ルーティング、権限も関係するため、あるクライアントの許可手順を他のクライアントにそのまま適用しないでください。
現在のクライアントに用意されているサービスのインストールまたは権限付与の手順だけを使い、システムの警告を読んでから許可してください。有効化に失敗した場合は、ログで具体的な権限またはインターフェースのエラーを確認します。見知らぬページから管理者権限で実行するコマンドをコピーしないでください。初回接続がシステムプロキシで動作するなら、TUNは無効のままで構いません。TUNが既存のVPN、コンテナネットワーク、ローカル開発環境と競合した場合は、まずTUNを無効にして復旧し、該当する現象をトラブルシューティングの項目で確認してください。
ステップ4：通信とルーティング結果を確認する
接続ボタンが点灯していても、動作の一部が開始したことしかわかりません。実際のリクエストで通信経路を確認してください。普段使っていて、現在のネットワークからアクセスできるWebページをブラウザーで開き、設定上プロキシが必要な宛先も試します。キャッシュの影響を減らすには、新しいプライベートウィンドウを開くか、ページを再読み込みしてください。古いタブの内容だけを見て判断したり、ページの読み込みが一時的に遅いだけでノードが原因だと決めつけたりしないでください。
ステータスアイコンだけでなく接続ログを確認する
クライアントの「接続」画面に戻り、リクエストを送信しながら新しいログを確認します。アクセスしたドメインを探し、適用ルール、ポリシーグループ、実際の出口までの経路を確認してください。ルールモードでは、一部のリクエストが直接接続と表示されても問題ありません。プロキシが必要なリクエストは、想定したポリシーグループを経由し、最終的に先ほど選択したノードを使う必要があります。グループ名は最終的な出口を示すとは限らないため、必要に応じてポリシーチェーンを展開して確認してください。
接続画面に記録がない場合は、まずブラウザーが新しいリクエストを送信したか確認します。次に、システムプロキシが有効か、ブラウザーがシステム設定を参照しているか、プロキシ拡張機能が通信を処理していないかを確認してください。クライアントによっては現在のアクティブな接続しか表示せず、短いリクエストはすぐに消えることがあります。ページの再読み込みと同時にログを確認してください。記録はあるのにリクエストが失敗する場合は、ノードとログを確認します。先にシステムプロキシのポートを変更する必要はありません。
記録が想定と異なるポリシーグループを示している場合は、2つ目の手順に戻り、そのグループを調整してください。ホーム画面で目立つメインのグループだけを切り替えても解決しないことがあります。対象が直接接続のルールに一致しているのにプロキシを使う想定だった場合は、設定の作成者が意図したルールを確認してください。初めて使う段階で、条件の広いルールを追加するのはおすすめしません。ルールの順序や条件の選び方は、現在の設定と照らし合わせながら技術ガイドで確認できます。
失敗したら層ごとに確認し、変更は1つずつ
「設定の適用 → コアの動作 → アプリの接続 → ポリシーの選択 → 宛先からの応答」の順に確認します。ポリシーグループがない場合はサブスクリプションに戻ります。コアにエラーがある場合は、まず起動時のメッセージを確認してください。リクエストがクライアントに届かない場合は、システムプロキシまたはアプリの設定を確認します。リクエストが届いているのに接続できない場合は、応答のある別のノードと比較してください。特定のサイトだけで問題が起きるなら、接続先のサービス側が原因の可能性もあります。それだけを理由に設定全体をリセットしないでください。
ログはエラーの種類を確認するのに役立ちますが、最初から詳細ログを有効にして長時間動かす必要はありません。人に相談するときは、OS、クライアント名、接続方法に加え、「すべてのアプリで失敗する」のか「特定のアプリだけ失敗する」のかを伝えてください。スクリーンショットを共有する前に、サブスクリプションURL、ノードのアドレス、認証情報、個人のアクセス履歴を隠します。WindowsのMicrosoft Storeアプリだけが接続できない場合は、UWPループバックに関する説明を確認してください。特定アプリの接続問題を、すべてのノードが使えない問題と混同しないようにしましょう。
動作確認後に、普段使いに便利な機能を有効にする
Webページが開き、接続ログも想定どおりであることを確認してから、必要に応じてOS起動時の自動起動、サブスクリプションの自動更新、トレイでの常駐を有効にします。ウィンドウを閉じたときにアプリが終了するのか、トレイに格納されるのかを先に確認し、接続が停止したと誤解しないようにしてください。サブスクリプションの更新でポリシーグループ名が変わった場合は、既定の選択も再確認します。更新のたびに同じ出口が維持されるとは限りません。
設定完了後の状態を説明できるようにしておきましょう。使用中の設定、モード、システムプロキシとTUNのどちらで通信を取り込んでいるか、主要なポリシーグループで何を選択しているかの4点を確認します。把握できていれば、ネットワークの切り替えやトラブルの際に状況を追いやすくなります。クライアントを比較する場合はクライアント比較をご覧ください。サブスクリプションの更新やアプリの不具合など個別の問題はよくある質問で確認できます。普段使いのために技術文書を最初から最後まで読む必要はありません。