初期設定の所要時間:約10分

Clash 使い方ガイド:サブスクリプション導入から接続確認まで

クライアントを準備し、サブスクリプションを導入し、プロキシモードを選び、ノードへ接続したうえで、ブラウザーの通信が想定どおりプロキシを経由していることを確認します。

mihomo系クライアントに対応 4ステップで初回接続 Windows · macOS · Android · iOS · Linux
開始前の準備

クライアント、サブスクリプションURL、システム時刻

まず3つの基本条件を確認すると、後から設定画面に戻る手間を減らせます。このセクションでは初回接続に必要な内容だけを扱い、複雑なルール、DNS、TUNパラメーター、設定の上書きについては上級設定ガイドで詳しく説明します。

クライアントが正常に起動することを確認

クライアントをまだインストールしていない場合は、まずダウンロードページでOSに合ったGUIクライアントを選びます。WindowsとmacOSではインストール後にメインウィンドウが開くことを確認してください。AndroidとiOSでは初回起動時にVPN権限の説明が表示されることがありますが、すぐに接続する必要はありません。Linuxデスクトップでは、設定ディレクトリの読み取りとシステムプロキシ設定の作成権限を確認します。

起動後は画面が正常に表示されているか確認します。設定、プロキシ、設定などの主要な項目が見えていれば次へ進めます。初回起動時にファイアウォールのアクセス許可が表示されたら、実際のネットワーク環境に応じて必要な通信を許可してください。システムがクライアントの起動を阻止している場合は、同じサブスクリプションを繰り返し導入するのではなく、先にシステム権限を解決します。

A

完全なサブスクリプションURLを用意

サブスクリプションURLは各サービス提供者が発行します。コピーする際は、プロトコルの先頭から末尾のパラメーターまで、内容全体を含めてください。Webページで途中までしか表示されない部分だけをコピーしてはいけません。

B

システムの日付と時刻を調整

システム時刻のずれが大きいと、安全な接続の確立に影響することがあります。OSの自動時刻設定と自動タイムゾーン設定を有効にしてから、クライアントを再起動してください。

C

重複するプロキシを一時停止

別のプロキシツールが動作している場合は、先に終了するか、そのシステムプロキシを無効にしてください。2つのプログラムが同時にシステムプロキシを変更したり、同じ待ち受けポートを使用したりするのを防げます。

ステップ1

ClashのサブスクリプションURLを導入

クライアントを開いたら、「サブスクリプション」「設定」「Profiles」「設定ファイル」のいずれかのページを探します。デスクトップクライアントでは通常、左側のナビゲーションにあります。モバイル版ではホーム画面の設定エリアに配置されていることが多いです。ページを開いたら、URLから新規作成、サブスクリプション追加、リモート設定の導入などを選びます。今回はオンラインのサブスクリプションURLを用意しているため、ローカルファイルの導入は選択しません。

URL全体をアドレス入力欄に貼り付けます。クライアントによっては設定名の入力も求められます。サービス名や用途など、見分けやすい短い名前を付けると便利です。この名前はローカルの一覧表示だけに使われ、サブスクリプションの内容は変わりません。URLを確認したら、ダウンロード、導入、保存、更新のいずれかを実行します。クライアントがリモート設定を取得し、含まれているプロキシノード、ポリシーグループ、ルール、DNS設定をローカル設定として保存します。

導入が完了すると、通常は設定一覧に新しい項目が追加され、最終更新日時が表示されます。ここで見落としやすい操作があります。追加された設定をクリックして、現在の設定として選択してください。クライアントによっては選択項目の横にチェックマーク、強調色、「現在」などの表示が出ます。別のクライアントでは有効化ボタンを押す必要があります。現在の設定が読み込まれて初めて、ポリシーグループとノード一覧がこのサブスクリプションに基づいて生成されます。

この手順の完了を確認する方法

設定ページを離れ、「プロキシ」「Proxies」またはポリシーグループのページを開きます。自動選択、ノード選択、フェイルオーバーなどのポリシーグループが表示され、展開すると選択可能なノードも見えるなら、設定はカーネルに読み込まれています。ページが空のままなら、システムプロキシを有効にする必要はありません。アクティブな設定がなければ、クライアントは通信の送り先を判断できないためです。サブスクリプション更新の詳しい問題については、よくある質問のインストール・設定カテゴリも参照してください。

ノードとポリシーグループが表示されても、すぐに一つずつ切り替える必要はありません。次にプロキシモードを決めます。モードによってルールが適用されるかどうかが決まり、後の確認で何を観察すべきかも変わります。

ステップ2

ルールモードを選択

設定を読み込んだら、設定ページまたはプロキシページにある「モード」を開きます。一般的な選択肢はルール、グローバル、直接接続です。初回はルールモードがおすすめです。このモードでは現在の設定にあるルールを上から順に照合します。直接接続ルールに一致したリクエストは直接接続し、プロキシルールに一致したリクエストはポリシーグループへ渡します。その他の通信は設定末尾のデフォルトルールで処理されます。ローカルネットワークへのアクセスを保ちながら、プロキシが必要な接続だけを選択したノードへ送れます。

グローバルモードでは、取り込み可能な通信の大部分を1つのプロキシポリシーに集約します。ルールの照合が原因かどうかを一時的に判断するには便利ですが、設定を理解しないままのデフォルトには向きません。直接接続モードは通常プロキシを経由せず、プロキシ効果を一時停止したり、ローカルネットワークを切り分けたりする際に使います。モードの切り替えはシステムプロキシのスイッチの代わりにはなりません。モードは「取り込んだ通信をどう処理するか」を決め、システムプロキシやTUNは「通信をどうClashへ入れるか」を決めます。両者は異なる階層の設定です。

ルールモードを選択したら、プロキシページに戻ります。複数のポリシーグループが表示され、それぞれが異なる判断を担当しています。名称はサブスクリプション設定によって決まり、ノード選択、自動選択、ストリーミングなど用途はさまざまです。初回接続では、デフォルトのプロキシ出口を担当する主要なポリシーグループを探します。通常は一覧の上部にあり、複数のノードまたは自動選択の子ポリシーが含まれています。

RULE

ルールモード

ドメイン、IP、ルールセット、設定の順序に基づいて接続先を決めます。日常のデフォルトに適しており、このガイドでも以降はこのモードを使用します。

GLOBAL

グローバルモード

取り込み可能なリクエストを指定したプロキシポリシーにまとめて送ります。短時間の比較テストに使えますが、使用後は想定しているモードに戻してください。

DIRECT

直接接続モード

通信を宛先へ直接アクセスさせます。プロキシ経路を一時停止したり、ローカルネットワークの結果と比較したりするためのモードで、クライアントを終了するわけではありません。

デフォルトのDNSとルール設定を維持

初回接続では、Fake-IP、ドメインスニッフィング、ルールセットの取得元、DNS待ち受けアドレス、TUNルートを同時に変更しないことをおすすめします。一度に多くのパラメーターを変えると、障害の原因を特定しにくくなります。まずはサブスクリプション設定のデフォルト値で接続と確認を行い、基本経路が使えることを確認してから必要に応じて個別に調整してください。Fake-IP、DNS分流、ルールの優先順位については上級設定で確認できます。

ルールモードが決まれば、通信の処理経路も明確になります。次は主要なポリシーグループで利用可能なノードを1つ選び、現在のシステムに適した通信の取り込み方法を有効にするだけです。

ステップ3

ノードを選択して接続

プロキシまたはポリシーグループページを開き、デフォルトの出口を担当する主要なポリシーグループを表示します。具体的なノードと「自動選択」「フェイルオーバー」などの子ポリシーが混在している場合、初回は具体的なノードを直接選ぶと、実際にどの経路を使っているか確認しやすくなります。確認が終わったら、設定の設計に合わせて自動ポリシーへ切り替えてください。

クライアントには通常、遅延テストのボタンがあります。テストを実行して結果が返るノードは、少なくともテスト先への接続を完了できています。タイムアウトするノードは、初回確認には向きません。遅延値は特定のテスト先に対するその時点の応答状況を示すだけで、すべてのWebサイトでの実速度を意味しません。安定して結果が返るノードを1つ選べば十分で、最小値を求めて何度もテストする必要はありません。

ノードを選択したら、クライアントのホームまたは設定ページに戻り、「システムプロキシ」を有効にします。デスクトップOSのブラウザーやシステムプロキシに従うアプリは、通常ここからClashのローカル待ち受けポートを経由します。Windowsではファイアウォール権限の確認が表示されることがあり、macOSではシステム設定の変更確認を求められることがあります。OSの案内に従って許可した後、スイッチが有効なままか確認してください。すぐに無効へ戻してはいけません。

モバイル端末の接続方法

AndroidとiOSのクライアントは通常、システムVPNインターフェースを通じて通信を取り込みます。開始、接続、メインスイッチのいずれかをタップすると、システムにVPN構成の許可画面が表示されます。許可するとステータスバーにVPNアイコンが現れ、クライアントにも接続済みと表示されます。このVPNインターフェースは端末の通信をローカルのプロキシカーネルへ渡す役割を担い、各リクエストの処理は現在のClash設定にあるモード、ルール、ポリシーグループで決まります。

TUNモードを検討するタイミング

デスクトップ版でシステムプロキシだけを有効にすると、通常はブラウザーを利用できます。ただし、一部のゲーム、コマンドラインツール、システムプロキシを読み取らないアプリは直接接続のままになることがあります。このような明確な必要性がある場合に、TUNモードを検討してください。TUNはより低いレイヤーで通信を取り込むため、初回の有効化時に管理者権限、ネットワーク拡張機能の許可、仮想ネットワークアダプターのインストールが必要になる場合があります。基本的なブラウザー確認が終わるまでは複数の取り込みスイッチを同時に有効にせず、リクエストがどの経路を通ったか分からなくなるのを避けてください。

クライアントが接続を受信しているか確認

取り込みを有効にしたら、新しいブラウザータブで一般的なWebページを開き、同時にクライアントの接続またはログページを確認します。通常はドメイン、宛先アドレス、適用ルール、使用ポリシーなどの記録が表示されます。ログが継続して追加されるなら、ブラウザーのリクエストはカーネルに入っています。新しい記録がまったくない場合は、システムプロキシが有効になっていない、ブラウザーが独自のプロキシ設定を使っている、別のネットワークツールが通信を取り込んでいる可能性があります。

ここまでで接続経路は確立していますが、「スイッチがオン」と表示されるだけでは出口が変わった証拠になりません。最後に外部の出口情報とクライアント内部の記録を同時に確認します。

ステップ4

プロキシが有効か確認

確認は比較可能な基準から始めます。接続前の出口情報を記録していない場合は、システムプロキシを無効にするか、モバイル端末の接続を切断します。普段使うIP確認ページを開き、現在のネットワークの出口地域と通信事業者を記録してからClashを再び有効にし、同じページを更新してください。出口情報が変わり、選択したノードの想定地域と一致すれば、ブラウザーの通信はプロキシポリシーを経由しています。

IP確認ページだけでは不十分です。クライアントの接続記録に戻り、直前に発生したリクエストを探します。想定したルールに一致し、現在選択しているポリシーまたはノードから送信されていることを確認してください。ルールモードでは、すべてのWebサイトで同じ出口になるとは限りません。ローカルサイト、LANアドレス、設定で直接接続に指定されたドメインは、ローカルネットワークを使い続けることがあります。これはルールによる振り分けとして正常です。確認時はプロキシ経由を想定する対象を選び、ルールの記録と合わせて判断してください。

続けて2つの基本ケースをテストします。まず直接接続を想定する普段使いのページを開き、正常に読み込めることを確認します。次にプロキシ経由を想定するページを開き、アクセスできることと、クライアントの記録にプロキシポリシーが表示されることを確認します。両方のリクエストがルールどおり処理されて初めて、「サブスクリプション設定、プロキシモード、ノード選択、通信の取り込み」の4つが一連の経路として機能したと判断できます。

外部結果

出口情報が想定どおり

接続前後の結果を比較でき、プロキシ対象の出口地域が現在のノードと一致しています。更新時に接続タイムアウトや証明書時刻エラーが継続して発生していません。

内部記録

リクエストが正しいポリシーに一致

接続ページまたはログページでテストリクエストを確認でき、対応するルール、ポリシーグループ、実際のノードが表示されます。常に直接接続と表示される状態ではありません。

ブラウザーの確認後に他のアプリをテスト

ブラウザーの確認に成功したなら、クライアント、設定、基本的なプロキシ経路は利用可能です。ここで初めて、通信が必要なデスクトップアプリ、ターミナルコマンド、モバイルアプリを開きます。特定のアプリだけ動作しない場合は、そのアプリがシステムプロキシに従うか、独自DNSを使うか、TUNが必要か、アプリ側のネットワークキャッシュが残っているかに絞って確認できます。この段階でサブスクリプションを再導入したり、ルールを大幅に変更したりしないでください。確認済みの基準状態が崩れてしまいます。

すべての確認が終わったら、主要なポリシーグループを自動選択ポリシーに切り替えるか、先ほど確認した具体的なノードをそのまま使います。サブスクリプションを更新すると、ノードが追加、削除、改名されることがあります。以前の選択肢が無効になった場合は、ポリシーグループを開いて選び直してください。これで初回接続の基本手順は完了です。

初回トラブル対処

接続が有効にならない場合は経路の順に確認

確認の順序は設定の順序に合わせます。毎回1つの条件だけを変更し、変更後に再テストしてください。複数の変更が互いに影響して原因が隠れるのを防げます。

  1. 現在の設定が選択されているか確認

    設定ページに戻って選択マークを確認し、手動更新を1回実行します。設定の期限切れ、ダウンロード失敗、導入しただけで有効化していない状態では、ポリシーグループが空になったり、古い内容が使われ続けたりします。

  2. ノード自体が接続できるか確認

    主要なポリシーグループで、テストを完了できる別のノードに切り替えます。すべてのノードがタイムアウトする場合は、ローカルネットワーク、システム時刻、サブスクリプションの状態を先に確認し、プロキシモードだけを何度も切り替えないでください。

  3. 通信がクライアントに入っているか確認

    システムプロキシまたはモバイル端末の接続を有効にした後、ログを確認します。Webページにアクセスしても新しい記録がない場合は、ブラウザー独自のプロキシ、システムプロキシの状態、他のネットワークツールを確認してください。

  4. ローカル待ち受けポートが利用できるか確認

    起動ログに address already in use と表示される場合、通常は設定内の待ち受けポートが別のプロセスに使用されています。競合するプログラムを終了するか待ち受けポートを変更した後、設定を再読み込みしてください。

  5. 確認済みのシンプルな経路に戻す

    DNS、TUN、ルールを変更して問題が起きた場合は、まずルールモードとシステムプロキシの基本構成に戻します。基本経路が復旧してから、高度な機能を1つずつ有効にしてください。

完了状態

再現可能な基本設定を1つ残す

ルールモード、利用可能なノード1つ、システムプロキシが安定して動作しているときは、まずこの設定を覚えておきます。その後DNS、TUN、カスタムルールを調整して問題が起きても、すぐにこの基本状態へ戻して、どの変更が接続に影響したか判断できます。

プラットフォームやクライアントを変更する場合は、まずダウンロードページで対応するOSを選びます。画面上の名称は変わることがありますが、サブスクリプション、モード、ポリシー、通信の取り込み、確認という操作の流れは変わりません。