QUICKSTART / FIRST CONNECTION

Clashのサブスクリプション追加と接続設定ガイド

「サブスクリプションを追加 → プロキシモードを選択 → 接続 → 動作確認」の順に初期設定を進めます。約10分で一通りの操作を完了することを目安に、まずブラウザーの通信を確認し、その後TUNやDNSの応用設定に進みましょう。

事前準備：クライアントと対応形式のサブスクリプション

使用するOSとCPUアーキテクチャに合ったクライアントをインストールし、プロキシをオフにした状態でインターネットに接続できることを確認します。まだダウンロード前の場合は、Clashクライアントのインストーラーページでプラットフォームを選んでください。OSごとのインストール権限、サービスモード、パッケージ形式については全プラットフォーム対応のインストール・設定ガイドにまとめています。このページでは、クライアントを起動できる状態から説明します。

次に、サービス提供元から案内されたサブスクリプションURLを用意し、Clashまたはmihomo対応形式であることを確認します。購入履歴のページ、アカウントのログインURL、サブスクリプションURLはそれぞれ別のものです。サブスクリプションからは通常、プロキシ、プロキシグループ、ルールを含む設定が取得されます。ブラウザーでログインするためのページではありません。個別のノード共有リンクしかない場合は、クライアントが直接インポートに対応しているか確認してください。どのリンクでもサブスクリプション欄に貼れば自動認識されるわけではありません。

サブスクリプションURLにはアカウントへのアクセス情報が含まれることがあるため、パスワードと同様に扱ってください。公開コメントに投稿したり、URL全体が写った画像を見知らぬ相手に送ったり、安易にオンライン変換サイトへアップロードしたりしないでください。サブスクリプション変換が必要な場合は、先によくある質問のサブスクリプション解説を読み、設定の互換性とURL漏えいのリスクを確認します。作業前にほかのプロキシやVPNクライアントを一時終了し、システムプロキシ、仮想ネットワークアダプター、DNSの競合を減らしましょう。

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

クライアントのサイドバーから「サブスクリプション」または「設定」を開き、「追加」「インポート」またはプラス記号の項目を探します。「URLからインポート」と「ファイルからインポート」がある場合、サブスクリプションURLを使うならURLを選びます。サービス提供元からYAMLファイルを受け取った場合に限り、ファイルからインポートしてください。設定を見分けやすい名前で登録し、URL全体を入力欄に貼り付けます。先頭や末尾に空白や改行が混ざっていないことを確認してから、確定します。

まずインポート結果が表示されるまで待ち、すぐにすべてのスイッチを有効にする必要はありません。正常に完了すると、設定一覧に項目が追加され、最終更新の結果が表示されます。クライアントによっては、プロキシ数や更新完了の通知も表示されます。設定を開くかプロキシ画面に移動すると、設定で定義されたプロキシグループと候補が確認できるはずです。画面に何も表示されない場合は、まだ取得されていないURLを保存しただけではないか、設定画面に戻って確認してください。

インポートに失敗した場合は、今回の更新に対応するエラーメッセージを確認します。タイムアウトは、サブスクリプションサーバーに一時的に接続できないか、ネットワーク経路に問題があることを示す場合があります。401や403などの応答が返る場合は、サービス提供元にURLとアクセス権限を確認してください。解析エラーは、形式が非対応か、サーバーからログインページが返された可能性があります。これらをすべて「ノードの故障」と判断しないでください。この段階では、まだノードへの接続を試していません。エラーのキーワードを控え、ログを共有する前にURLと認証情報を隠してください。

設定が一覧に表示されたら、「使用」「有効化」などのボタンをクリックするか、現在の設定として選択します。クライアントによっては、枠線や選択マークで有効な項目を示します。複数のサブスクリプションがある場合は、追加した設定が選択されていることを確認してからプロキシ画面に移動し、グループを確認してください。ダウンロードが完了しただけでは、コアに設定が読み込まれたとは限りません。設定を変えても別の設定が使われ続けるのは、初めて使う際によくあるつまずきです。

サブスクリプションは「更新」から再取得できますが、まずは既定の更新方法を使ってください。グループを変更するためにリモート設定の本文を直接上書きすると、次回更新時に手動変更が消えることがあります。ルールの追加や項目の変更を継続して行う場合は、全プラットフォーム対応ガイドでオーバーライドとローカル設定の扱いを確認してください。グループが表示され、読み込みエラーがないことを確認したら、動作モードを選びます。

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

「プロキシ」画面を開き、「ルール／全体／直接接続」のモード切替を探します。初めて使う場合は「ルール」を選んでください。ルールモードでは、現在の設定にあるルールの順序に従って、リクエストごとに使用するポリシーが決まります。すべてのサイトが同じプロキシ接続を使うわけではありません。全体モードでは、コアに届いたリクエストを全体用ポリシーで処理し、直接接続モードではプロキシノードを経由しません。これらはコアが通信をどう処理するかを設定するもので、アプリの通信を自動的にコアへ送る機能ではありません。

次に、主要なプロキシ選択グループを開きます。グループ名はサブスクリプションの設定によって異なり、「ノード選択」「プロキシ」などさまざまです。すべてのクライアントに共通する固定の項目名を探す必要はありません。グループ内の候補ノードを選択してください。選んだ項目が別のグループの場合は、さらに開き、最終的に実際のノードが選ばれていることを確認します。DIRECTを誤って選ばないよう注意してください。自動選択グループは設定された測定・選択方法に従って動作するため、メンバーを直接固定できない場合があります。

クライアントに接続テスト機能があれば、候補の中から明らかに使えないものを除くため、まず一度テストしてもよいでしょう。ただし、テスト先から応答があっても、そのテスト経路で結果が得られたことを示すだけです。目的のサイトに接続できるとは限らず、数値の大小だけで使い勝手を判断することもできません。テストに成功したノードを選び、後で実際のサイトへのリクエストを確認します。すべて失敗する場合は、サブスクリプションの期限や候補の内容をステップ1で確認してから、ネットワーク環境を調べてください。

「開けるサイトと開けないサイトがある」場合は、短時間だけ全体モードに切り替え、全体用ポリシーでノードを選んで比較できます。同じサイトが全体モードでは開き、ルールモードでは開かない場合は、ルールの適用結果とグループ選択を優先して確認します。どちらのモードでも失敗する場合は、ノードや通信の取り込みを調べてください。比較が終わったらルールモードに戻し、トラブル対処のための一時設定をそのまま使い続けないようにします。

config.yaml · モード項目の例
mode: rule

上の例にはモード項目だけがあり、単独で動作する完全な設定ファイルではありません。このチュートリアルではYAMLを手動編集する必要はありません。まず画面上で選択してください。ポリシーグループ、ルール、ノードの関係がわからない場合は、用語解説を確認してから手順に戻りましょう。この時点で、有効な設定、選択したモード、利用可能なプロキシ選択項目がそろっているはずです。

ステップ3：接続を有効にしてシステムの許可を行う

PCでは、まずクライアントのコアが動作していることを確認してから「システムプロキシ」を有効にします。通常はOSのHTTP・HTTPSプロキシをローカルの待ち受けアドレスに向ける設定です。システムプロキシを参照するブラウザーやアプリのリクエストが、クライアントに送られるようになります。初回はブラウザー拡張機能、環境変数、複数のネットワークツールを同時に変更しないでください。経路をシンプルにしておけば、問題が起きたときに原因を切り分けやすくなります。

システムプロキシが有効なのにブラウザーでページをまったく読み込めない場合は、クライアントの設定にある待ち受けポートを確認し、OSのネットワークプロキシに設定されたアドレスとポートを照合します。ローカルアドレスには通常127.0.0.1を使います。ポートは現在の設定に合わせてください。チュートリアルでよく見るからといって、既存の値を7890に変更しないでください。クライアントが待ち受けを開始できていない、ポートを別のプログラムが使用している、OSの設定が以前使っていたクライアントを向いている、といった場合、リクエストは受け取り先のない場所へ送られてしまいます。

AndroidとiOSでは通常、ホーム画面の「接続」または起動ボタンをタップすると、システムからVPN設定や接続の許可を求められます。使用中のクライアントからの要求であることを確認し、システムの案内に従って許可してください。許可したらクライアントに戻り、接続中と表示されていることを確認します。システム側にもVPNの状態が表示される場合があります。ここでのVPNは、システムが通信を取り込むための仕組みです。「VPN」と表示されるすべてのアプリが、同じプロトコルやサーバーを使うわけではありません。

すでに別のVPN、社内ネットワークのトンネル、または同種のプロキシツールが動作している場合は、同時に使用できるか確認してください。モバイルOSでは複数のVPNサービスを同時に動かせないことが多く、後から起動したサービスが先に起動していたものを置き換える場合があります。職場や学校が管理するネットワークでは、管理ポリシーを無断で変更しないでください。ネットワークの利用条件を確認してからテストを続けます。接続ボタンを押してもすぐオフに戻る場合は、許可が完了しているか、バックグラウンド動作が制限されていないか、設定読み込みエラーが出ていないか確認してください。

TUNは、システムプロキシに従わないアプリの通信も幅広く取り込むための機能ですが、ブラウザーで最初の接続を確認する段階では通常必要ありません。TUNを使う場合、デスクトップクライアントからサービスのインストール、管理者権限、仮想ネットワークデバイスの許可を求められることがあります。使用中のクライアントのドキュメントに従って許可してください。システムプロキシとTUNを、必ず両方有効にする項目だと考えないでください。有効にした後、通常のネットワークにも問題が出た場合は、いったんTUNをオフにしてシステムプロキシの経路で設定が使えることを確認し、ルーティング、DNS、権限の詳細は全プラットフォーム対応ガイドで確認します。

ステップ4：通信・ルール・実際の接続先を確認

接続状態は確認の出発点にすぎません。最後は実際のリクエストを確認しましょう。まず、通常のネットワークでもアクセスできるサイトをブラウザーで開き、元の通信に問題がないことを確認します。次に新しいタブを開き、プロキシ経由で接続したいサイトへアクセスしてください。以前開いていたページや既存の長時間接続の影響を避けるには、新しいプライベートウィンドウを使うか、ページを完全に再読み込みします。サイトが開いたら、クライアントの「接続」または「ログ」画面で結果を確認してください。スイッチの色だけで成功と判断しないようにします。

接続一覧で対象ドメインを検索し、直前に発生したリクエストの適用ルール、使用したポリシーグループ、最終的なノードを確認します。プロキシ経由のはずのリクエストがDIRECTと表示される場合は、ステップ2に戻ってモードとグループを確認してください。リクエストがまったく見つからない場合は、ブラウザーがシステムプロキシを参照しているか、プロキシ拡張機能が設定を上書きしていないか、現在のタブが以前の接続を再利用していないか確認します。接続一覧には通信中のリクエストだけが表示される場合があります。ページの読み込み後に項目が消えても、必ずしも異常ではありません。再読み込みと同時に確認できます。

信頼できる接続元IPの確認サービスを使い、プロキシをオフにしたときとオンにしたときの結果を比較します。ルールモードでは、確認サイト自体が直接接続になる場合もあるため、「IPが変わらない」だけでプロキシの失敗とは判断できません。該当リクエストのログと照らし合わせてください。明確に比較したい場合は、選択済みのノードを使って短時間だけ全体モードで再確認し、その後ルールモードに戻します。接続元IPの変化が示すのは、このリクエストの経路が変わったことだけです。端末上のすべてのアプリの通信が取り込まれているとは限りません。

「コアがプロキシ通信できるか」と「ブラウザーの通信が取り込まれているか」をより正確に切り分けるには、PCのターミナルからローカルHTTPプロキシへ明示的にリクエストを送る方法があります。以下のコマンドは、現在のHTTPまたはmixed待ち受けポートが7890の場合に限り使用できます。異なる場合は、先にポート番号を置き換えてください。例示のドメインはHTTP応答のテスト用であり、特定地域からの接続可否を確認するものではありません。

ターミナル · プロキシを指定したリクエスト
curl -I --proxy http://127.0.0.1:7890 https://example.com

Windowsのターミナルでcurlが別のコマンドとして認識される場合は、curl.exeを使用してください。HTTP応答があれば、指定したローカルプロキシを通じて応答を取得できています。ただし、最終的に直接接続されたかノード経由かは、ログも確認する必要があります。接続拒否の場合は、ポートとコアの動作状態を確認します。長時間タイムアウトする場合は、ノードと接続先サイトまでの経路を調べてください。このテストでシステムプロキシの設定が変わることはなく、ブラウザーのテストの代わりにもなりません。それぞれ別の経路として考えてください。

最後に、名前解決の状態も確認します。サイトを開けても、DNS通信が想定どおり取り込まれているとは限りません。また、DNSチェックページに表示されるリゾルバーの所在地だけで、情報漏えいと断定することはできません。初めて使うときは、まず動作する設定を維持してください。ドメインを解決できない、一部のサイトだけ異常がある、またはClashのDNSリークを確認したい場合は、症状に応じてよくある質問を確認してください。DNS項目やネットワークスタックの用語は用語解説で調べられます。リクエストがコアに届いていると確認できる前に、DNSの設定を一度にすべて変更しないでください。

完了後：設定を記録して安全に終了

目的のサイトにアクセスでき、接続ログのポリシーが想定どおりで、通常のネットワークにも問題がなければ初期設定は完了です。現在の設定名、動作モード、プロキシグループを記録しておけば十分です。サブスクリプションURL全体が写った画像を保存する必要はありません。次に、普段使うアプリを一つずつテストします。ブラウザーでは成功して特定のアプリだけ失敗する場合は、サブスクリプション全体をすぐに変更するのではなく、まずそのアプリがプロキシに対応しているか確認してください。

使用を終えるときは、PCではシステムプロキシをオフにするか、クライアントの通常の終了操作で設定を戻してからプロセスを終了します。スマホでは切断ボタンをタップし、システムのVPN状態も終了したことを確認してください。クライアントが異常終了してブラウザーでページを開けなくなった場合は、システムプロキシが停止中のクライアントのローカルポートを参照したままになっていないか確認します。再インストールを繰り返すより、まず通常のネットワーク設定に戻すほうが確実です。設定ファイルをすべて削除する必要もありません。

以後のトラブル対処も、同じ順序で確認します。サブスクリプションが正常に読み込まれているか、モードとポリシーグループが正しいか、アプリのリクエストがコアに届いているか、適用ルールと接続先が想定どおりかを調べてください。変更する項目は一度に一つにし、その都度テストしてから次の手順に進みます。各プラットフォームへのインストール、TUN、長期的な設定上書きについては全プラットフォーム対応ガイドを参照してください。具体的なエラーはよくある質問で検索できます。まず再現性のある接続経路を確保し、その後で設定を追加しましょう。