初めての設定 · 4ステップ

Clashの使い方ガイド

サブスクリプションの追加、モード選択、接続と確認までを解説。まずは通信経路を確認してから、応用設定に進みましょう。

このページでは、初回設定を約10分で進める手順を紹介します。クライアントをインストール済みで、サブスクリプションを追加する方が対象です。所要時間はダウンロード、システムの許可、ネットワーク環境によって異なります。まだインストールしていない場合は、まずクライアントのダウンロードページで利用するプラットフォームを選んでください。インストール権限やアーキテクチャの選び方、プラットフォーム別の注意点は全プラットフォームガイドをご覧ください。

事前準備:設定の入手先とネットワークを確認

まず、クライアントを終了した状態で、普段アクセスできるWebサイトを開けることと、公衆Wi-Fiなどのログイン認証が済んでいることを確認します。これにより、端末のネットワーク障害とプロキシ設定の問題を切り分けやすくなります。初回設定ではほかのプロキシクライアントやVPNを一時停止し、このガイドのページを開いたままにしてください。リモートデスクトップからルーティングを変更する場合は、接続を復旧できる手段を事前に確保し、通信の取り込みを有効にした後に操作できなくなる事態を避けましょう。

信頼できる提供元から入手したClashまたはmihomo対応のサブスクリプションURL、あるいはサービス提供元のYAML設定ファイルを用意します。クライアントは設定を読み込んで接続を処理するソフトウェアであり、単体で利用可能なプロキシサービスを提供するものではありません。ノードのアドレス一覧、WebアカウントのURL、別形式のサブスクリプションは、そのまま読み込めない場合があります。対応形式をサービス提供元の案内で確認し、アカウントのパスワードを設定名の欄に入力しないでください。

サブスクリプションURLにはアカウントを識別する認証情報が含まれることが多いため、パスワードと同様に管理してください。コピーしたURLの先頭や末尾に空白、改行、チャットアプリが付加した文字列が混ざっていないか確認します。不審なオンライン変換ツールには入力せず、URL全体が写ったスクリーンショットを公開しないでください。準備ができたらクライアントのメイン画面を開き、設定管理から始めます。

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

「サブスクリプション」「設定」「Profiles」などの画面を開き、「新規」「追加」「インポート」またはプラスボタンを探します。URLから追加する方法を選び、サブスクリプションURLを入力欄に貼り付けます。名前には提供元が分かる名称を付けると便利です。URLを確認してから追加または保存し、ダウンロードと解析が終わるまで待ちます。この操作には、現在のネットワークからサブスクリプションサーバーへアクセスできる必要があります。

ローカルファイルを受け取った場合は、「ファイルからインポート」を選び、該当する .yaml または .yml ファイルを指定します。ダウンロードしたWebページの拡張子だけをYAMLに変更しないでください。拡張子が正しくても、内容が正しい形式とは限りません。ファイルの提供元に対応コアの説明があるか確認してください。解析エラーが表示された場合は、エラーに記載された行番号とフィールド名を控えて提供元に問い合わせます。エラーが出た項目を次々に削除して、無理に読み込ませるのは避けてください。

追加が成功すると、設定一覧に項目が増え、更新日時、名前、提供元などが表示されます。新しい項目が自動で有効になるクライアントもあれば、設定カードをクリックしたり、メニューから「使用」「有効化」を選んだりする必要がある場合もあります。現在選択されている設定が、追加したばかりのものか確認してください。「ダウンロード成功」と表示されただけでは、コアがその設定に切り替わったとは限りません。

次に「プロキシ」画面を開き、プロキシグループとその中のノードが表示されているか確認します。グループ名は設定の作成者によって異なり、「ノード選択」「プロキシ」など、ガイドとは違う名前の場合もあります。何も表示されない場合は設定画面に戻り、正しい項目が有効か、読み込みエラーが出ていないか確認してください。この段階ではまず設定の読み込みを解決し、グローバルモードを有効にしたりTUNを何度も切り替えたりしないでください。

サブスクリプションの更新と設定の有効化は別の操作です。更新すると、クライアントはリモートの内容を再取得します。提供元がノードを変更した後も、手動で選んだノードがローカルに残ることがあります。更新後はプロキシグループに戻り、選択が有効か確認してください。リモート設定の本文を直接編集しても、更新時に上書きされる可能性があります。継続的に使うカスタムルールは、クライアントが対応するオーバーライド機能を利用してください。詳しい設定は、基本的な接続を確認してから行いましょう。

完了の目安は、設定が有効になり、プロキシ画面に選択可能なプロキシグループが表示されていることです。両方を確認したら、モード選択に進みます。サブスクリプション、設定ファイル、プロキシグループの関係は用語集で確認できます。初回接続の前にYAMLの全項目を理解する必要はありません。

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

「概要」「プロキシ」または設定画面でモード切り替えを探します。初回は「ルール」または「Rule」を選んでください。コアは現在の設定に基づいて、接続を直接接続、プロキシ経由、拒否のいずれかに振り分けます。実際の動作は設定の内容によって異なり、クライアントが各Webサイトに適した経路をあらかじめ判断しているわけではありません。適切なルールがない場合は、最後にフォールバックルールが適用されます。

ルールモードに切り替えたら、設定内のメインプロキシグループを開きます。具体的なノードが表示される場合は、利用実績があり、接続先のサービスに適したものを選びます。「自動選択」「フェイルオーバー」などのグループが表示される場合は、そのグループを選び、設定内のテストや切り替え機能に接続先を任せることもできます。グループ名に地域名が含まれていても、接続先の所在地がその地域だとは限りません。最後に実際の接続を確認してください。

「遅延テスト」や「接続テスト」がある場合は、初期確認として実行できます。結果が表示されれば、指定された条件でテスト先が応答したことを示します。タイムアウトした場合は、ノードやネットワークを引き続き確認してください。テスト値はダウンロード速度ではなく、すべてのWebサイトへアクセスできることを保証するものでもありません。サービスによって接続元やプロトコルが制限されるため、テストに成功した後も実際の目的のページを開いて確認しましょう。

「グローバル」モードでは、コアに取り込まれた接続をすべてグローバルポリシーに渡します。振り分けルールに問題があるかを短時間で比較するのに便利です。「直結」モードでは通常、コアに取り込まれた接続が宛先に直接アクセスします。モードが示すのはコアによる接続の処理方法であり、接続を取り込む方法ではありません。グローバルモードを選んでも、システムプロキシなどを有効にしていないアプリは、コアを経由せず通信する場合があります。

切り分けのためにグローバルモードを使う場合は、グローバルポリシーで DIRECT ではなく具体的なノードが選ばれていることも確認してください。比較が終わったらルールモードに戻し、本来直結するサービスまでプロキシ経由にしないようにします。初回設定では、ルールの並べ替えやDNSの変更はおすすめしません。まず追加した設定の初期状態で接続を確認すると、変化する要因を絞れます。

完了の目安は、モードが「ルール」と表示され、利用するプロキシグループでノードまたは有効な自動選択グループが選ばれていることです。これでクライアントは接続を処理できる状態ですが、ブラウザーの通信がまだコアに取り込まれていない可能性があります。次はプロキシ画面の確認だけで終わらせず、通信の取り込みを有効にします。

ステップ3:システムプロキシまたはTUNを有効化

まず概要画面に戻り、コアが起動していることを確認します。クライアントに「起動」「接続」やコアのスイッチが別にある場合は、先に起動してから通信の取り込みを設定してください。設定の解析に失敗してコアが動いていない状態でシステムプロキシを有効にすると、ブラウザーが待ち受けていないローカルポートを参照し、すべてのページが開けなくなることがあります。プロキシのスイッチより先に起動状態を確認しましょう。

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

WindowsまたはmacOSのデスクトップクライアントで「システムプロキシ」を探し、有効にします。通常、OSのプロキシ設定がローカルのコアを参照するようになり、システムプロキシに従うブラウザーやアプリがその経路を使います。有効にしたらブラウザーで新しいタブを開くか、起動したままのアプリを再起動し、新しい設定で接続させてください。既存の長時間接続はすぐに切り替わらない場合があります。

アプリ独自のプロキシ設定がある場合は、システム設定よりそちらが優先されることがあります。システムプロキシを利用しないアプリもあります。それだけでノードに問題があると判断しないでください。Linuxのデスクトップ環境ではシステムプロキシの対応状況も異なり、現在のデスクトップセッションにしか設定できないクライアントや、別途設定が必要なターミナルアプリもあります。まずシステムプロキシに対応したブラウザーで通信できる状態を確認してから、ほかのアプリを設定しましょう。

モバイル:システムのVPN接続を許可

AndroidまたはiOSのクライアントで設定とノードを選び、「接続」をタップします。システムからVPN設定の追加やVPN接続の許可を求められたら、現在のクライアントからの要求であることを確認して、画面の案内に従って許可してください。端末によってはロック解除やパスコードの入力が必要です。接続後、システム設定やステータス領域にVPNの状態が表示されますが、アイコンはOSのバージョンによって異なります。

ここでのVPNインターフェースは、クライアントが端末の通信を取り込むためのシステム機能です。接続しただけで設定内の振り分けルールを経由しなくなるわけではありません。接続後も実際のアクセスとルールの適用を確認してください。ほかのVPNが動作中の場合は、いったん切断してからテストします。業務用端末では管理ポリシーによってVPN設定が制限されることもあります。システムに拒否された場合は端末の権限を確認し、同じサブスクリプションを何度も追加しないでください。

TUN:必要な場合に有効化

ブラウザーは正常に動作するのに、特定のアプリの接続記録が見つからない場合にTUNモードを検討します。「TUN」「仮想NIC」または通信の取り込みに関する設定を探し、クライアントの案内に従ってサービスのインストール、管理者権限の許可、ネットワーク拡張の承認を行います。TUNはルーティング層で条件に合う通信を取り込めますが、その範囲はルート、除外設定、DNSによって異なります。すべての通信が必ずプロキシ経由になるわけではありません。

初回の確認では、システムプロキシをオフにしてTUNだけをテストすると、どちらの経路が有効になっているか判断しやすくなります。これは切り分けのための方法であり、すべてのクライアントで両方の同時利用が禁止されているわけではありません。有効にした後、ローカルネットワーク、プリンター、ほかのVPNに影響が出た場合は、まずTUNをオフにして元の状態に戻してください。権限、仮想NIC、ルートの競合については、プラットフォームに応じた全プラットフォームのインストール・設定ガイドをご覧ください。

完了の目安は、コアが起動し、選んだ通信の取り込み方法が有効で、未処理の許可要求が残っていないことです。クライアントに「接続済み」と表示されても、特定のWebサイトにアクセスできるとは限りません。設定はそのままにして、最後の接続確認へ進みましょう。

ステップ4:アクセスとルールの適用を確認

まず、普段から直接アクセスできるWebサイトを開き、基本的なネットワークが利用できることを確認します。次に新しいタブを開き、現在の設定でプロキシ経由になるはずのサイトにアクセスします。タイトルが表示されるだけではなく、ページ全体が読み込まれることを確認してください。キャッシュ済みのページだけで判断せず、必要に応じて再読み込みするか新しいブラウザーウィンドウを開き、その際にクライアントに新しい接続が記録されるか確認します。

クライアントで「接続」「Connections」またはリアルタイムログの画面を開き、アクセスしたドメインで絞り込みます。接続の詳細には、宛先のドメインまたはIPアドレス、適用されたルール、プロキシグループ、最終的なノードが表示されることがあります。項目名はクライアントによって異なります。重要なのは、通信がコアに取り込まれ、プロキシ経路が想定どおりであることです。DIRECTと表示されても必ずしも問題ではありません。まずその宛先が本来直結する想定かどうか確認してください。

接続の詳細でプロキシ経由になっていることを確認できた場合は、信頼できる接続元IPアドレス確認サイトを補助的に利用できます。表示されるのは、そのサイトへのアクセスに使われた接続元であり、端末上のすべてのアプリが同じ経路を使っていることを示すものではありません。また、DNSの処理が想定どおりであることを単独で証明するものでもありません。確認サイトへの接続が直結になる設定もあるため、表示された地域名だけで判断せず、ドメインのルール記録と合わせて確認してください。

問題が起きたら通信経路に沿って確認

クライアントに対象の接続が表示されない場合は、まずシステムプロキシまたはTUNが実際に有効か確認します。次に、アプリ独自のプロキシ設定や以前の接続が再利用されていないか確認してください。対象アプリを終了して開き直し、再度試します。コアに通信が入っていない状態では、ノードを変更しても解決しません。先に通信の取り込み経路を確認しましょう。

接続記録はあるものの、想定と異なるプロキシ経路になっている場合は、選択中の設定とプロキシグループが想定どおりか見直してください。ルールは上から順に照合されるため、後のルールより前に一致することがあります。短時間だけグローバルモードに切り替えて比較する方法もあります。グローバルモードではアクセスでき、ルールモードではできない場合、ルールや関連するDNSの動作を確認する必要があります。ただし、それだけでは原因のルールを特定できません。

想定したノードが使われているのにタイムアウトする場合は、利用できることが確認済みの別のノードに切り替え、サービスの有効期限や利用制限も確認します。ドメインの名前解決でエラーが出る場合は、エラー内容を控え、基本ネットワークと設定内のDNSサーバーにアクセスできるか確認してください。ノード変更、DNSの変更、クライアントの再インストール、TUNの有効化を同時に行わないでください。毎回1つだけ変更し、同じアクセスを再テストすると結果を比較できます。

問題の調査に必要な情報を共有する場合は、クライアント名、OS、通信の取り込み方法、対象で発生したエラー、操作手順を記録してください。スクリーンショットを共有する前に、サブスクリプションURL全体、ノードのパスワード、アカウント情報、ローカル制御インターフェースの認証情報を隠してください。ログにはアクセス先のドメインや端末のパスが含まれることもあるため、共有前に内容を確認しましょう。専門用語の意味が分からない場合は、用語集でDNS、fake-ip、プロキシグループ、TUNを確認できます。

設定完了後の確認と終了

直結する想定のサイトとプロキシ経由の想定サイトの両方にアクセスでき、接続記録も想定どおりなら、初回設定は完了です。有効にした設定、モード、通信の取り込み方法を記録しておくと、更新や変更の後に動作する状態へ戻しやすくなります。サブスクリプションの自動更新、起動時の自動実行、細かなアプリ別の振り分けを設定する場合は、次に全プラットフォームガイドを確認してください。初回接続ですべてを有効にする必要はありません。

使い終わったら、クライアントでシステムプロキシをオフにするか、VPNまたはTUNを切断してから終了します。通常は終了時に関連設定が元に戻りますが、プログラムが異常終了するとシステムプロキシが残ることがあります。終了後にブラウザーでアクセスできない場合は、まずシステムネットワーク設定の手動プロキシがローカルを参照したままになっていないか確認してください。TUNを使っていた場合は、クライアントのサービスと仮想NICが想定どおり停止しているか確認します。基本のネットワーク接続を復旧してから、再接続するか判断してください。