初期設定 · 4つの手順
Clashのサブスクリプション設定と接続方法
設定の読み込みから実際のアクセス確認まで、順番に進めて接続します。初めて設定する場合は、まずルールモードを使い、DNS、ポート、TUNの設定は同時に変更しないでください。
作業を始める前に、信頼できる提供元のサブスクリプションURL、またはローカルのYAML設定ファイルを用意してください。クライアントをインストールしただけでは実行環境が整うだけで、プロキシサービスは利用できません。設定に必要なサーバーアドレス、認証情報、ルールは、設定の提供元から入手してください。サーバー情報しかなく、設定ファイル一式がない場合は、初心者から上級者までのガイドで設定方法を確認してください。個別のパラメーターをサブスクリプションURL欄に貼り付けないでください。
このガイドでは、まず接続できる状態にするまでを扱います。設定は一度に1つだけ変更し、各手順で結果を確認してください。途中で問題が起きても、設定が読み込まれていないのか、出力先が利用できないのか、アプリの通信がクライアントに届いていないのかを切り分けやすくなります。
1. サブスクリプションを追加して設定を有効化
クライアントを開き、「設定」「サブスクリプション」「Profiles」などの画面に進みます。「追加」「インポート」またはプラスボタンを探してください。設定の提供元から完全なURLを受け取った場合は、リモート設定を選ぶか、URLから読み込みます。YAMLファイルを保存済みの場合は、ファイルから読み込みます。どちらの場合も、最後に現在のクライアントで解析できる設定が必要です。URLをローカルファイルの内容として保存しないでください。
URLを貼り付けて、ダウンロードと解析を待つ
リモート設定のURL欄にサブスクリプションURL全体を貼り付け、見分けやすい名前を付けてから、「インポート」「ダウンロード」「保存」などをタップします。名前は設定を区別するためのもので、サーバー情報は変わりません。URLをコピーするときは前後の空白を取り除き、チャットの説明文や引用符、改行を一緒に貼り付けないでください。URL内のクエリパラメーターも変更・削除しないでください。
送信後、クライアントの取得処理が終わるまで待ちます。成功すると、通常は設定一覧に新しい項目が表示され、更新日時や設定の詳細、更新操作を確認できます。サブスクリプションによっては、クライアントが指定形式で内容を取得する必要があります。形式エラーが表示された場合は、ファイルの拡張子を何度も変更するのではなく、提供元に現在のクライアントとコアへの対応状況を確認してください。ブラウザーでURLを開けても、有効なClash設定が返されるとは限りません。
リモートからのダウンロードに失敗した場合は、まずプロキシを無効にしたまま、現在のネットワークからサブスクリプションサービスにアクセスできるか確認します。クライアントによっては、サブスクリプション更新の通信に独立したプロキシ設定があり、ブラウザーでアクセスできるかどうかだけでは判断できません。表示されたステータスコードやエラー文を記録し、サブスクリプションの追加に関するトラブルを確認してください。ダウンロードのために証明書の検証を無効にしたり、個人用のサブスクリプションURLを不明な変換サイトに送信したりしないでください。
現在の設定に切り替え、プロキシグループを確認
設定を追加したら、新しい項目またはその横にある「有効化」「使用」などのボタンをタップし、現在の設定として選択します。インポート後に自動選択されるクライアントもあれば、一覧に保存されるだけのクライアントもあります。一覧の行が増えたかだけでなく、現在選択中のマークも確認してください。次に「プロキシ」画面を開き、設定で定義されたプロキシグループと選択可能な出力先が表示されるか確認します。
ローカルファイルを読み込む場合は、システムのファイル選択画面でYAMLファイルを選び、解析が終わったら同じ手順で有効化します。ローカルから読み込んだファイルは、通常、リモートサービスの更新に自動では追従しません。新しいファイルを受け取った場合は、再度読み込むか、クライアントの機能で置き換えてください。元のファイルを保存しておくと、後からルールを変更した際に戻せます。
ここまでで確認できたのは、設定が読み込まれたことだけです。プロキシが利用できることはまだ確認できていません。プロキシ画面が空、読み込み時にフィールドエラーが出る、または別の設定が現在選択されている場合は、先にその問題を解決してください。プロキシグループが正常に表示されたら、次の手順でモードを選びます。
2. ルールモードとプロキシの出力先を選択
クライアントのホーム画面または「プロキシ」画面に戻り、「モード」「実行モード」「Mode」などの項目を探します。初期設定ではルールモード(Rule)を選択してください。このモードでは、現在の設定にあるルールに従って、接続をDIRECT、プロキシグループ、または拒否のいずれかに振り分けます。ルールが自動生成されるわけではなく、すべてのサイトが同じプロキシ出口を使うわけでもありません。
先にモードを選び、その後でプロキシグループを設定
ルールモードに切り替えたら、プロキシ一覧を開き、プロキシ通信に使うプロキシグループを探します。「Proxy」「ノード選択」など、名前は提供元の設定によって異なります。グループを開き、利用可能だと分かっている出力先を選んでください。グループ内に別のグループが入れ子になっている場合は、最終的にどの項目が選択されているか、下の階層まで確認します。プロキシを選んだつもりでも、実際の出力先がDIRECTになっていることがあります。
手動選択のグループでは出力先を直接指定できます。自動選択やフォールバックのグループは、設定された検出・切り替えロジックに従います。項目をタップしても選択状態を固定できない場合は、まずグループの種類を確認してください。クライアントの不具合とは限りません。初回接続では、設定にあるグループ構成をそのまま使いましょう。急いで名前を変更したり、重複して見えるグループを削除したりしないでください。ルールがグループ名を参照している場合があります。
クライアントに接続テスト機能があれば、プロキシグループを選択した後に実行すると、明らかに到達できない候補を除外できます。ただし、テスト結果が示すのは指定されたテスト先への1回のリクエストだけです。すべてのアプリからアクセスできることや、実際のダウンロード速度を保証するものではありません。まずこのページ後半のブラウザーアクセスと接続履歴を確認し、全体の動作を判断してください。
ルール・グローバル・DIRECTの違い
「グローバル(Global)」では、通常、コアに届いた接続をすべてグローバルグループに渡します。ルールが問題かどうかを一時的に比較する場合に便利です。切り替え後は、グローバルグループの出力先も確認してください。DIRECTが選択されていれば、通信は想定どおりプロキシを経由しません。比較が終わったらルールモードに戻し、一時的な確認用設定を普段の設定として使わないようにしてください。
「DIRECT」は、コアに届いた接続をプロキシを経由せずに宛先へ接続します。プロキシの出力先を確認する用途には適しません。また、グローバルモードが決めるのは、コアが受け取った接続の処理方法だけです。システム上のすべてのアプリの通信が自動的にコアへ届くわけではありません。どのアプリの通信がコアに届くかは、次の手順で有効にするシステムプロキシやVPNの取り込み方法によって決まります。
ここで、現在のモードがルールであること、対象のプロキシグループに明確な出力先が選ばれていることを確認します。モードとプロキシグループの詳しい説明は、プロキシモードとプロキシグループの解説を参照してください。初回の設定ではルールファイルを変更せず、接続を有効にする手順へ進みます。
3. コアを起動して通信を取り込む
ホーム画面またはステータス画面に戻り、コアが起動しているか確認します。デスクトップクライアントには、起動時にコアも自動で起動するものと、「起動」や「接続」をタップする必要があるものがあります。設定エラー、起動失敗、待ち受けポートの競合が表示された場合は、まずエラーに対処してください。システムプロキシを有効にするだけでは解決しません。停止中のローカルサービスをシステムプロキシに指定すると、ブラウザーがネットワークに接続できなくなることがあります。
デスクトップ:まずシステムプロキシを使う
Windows、macOS、またはシステムプロキシに対応するLinuxクライアントで、「システムプロキシ」のスイッチを探して有効にします。ネットワーク設定を変更する許可をシステムから求められた場合は、起動したクライアントからの要求であることを確認し、画面の案内に従って許可してください。有効にすると、システムプロキシ設定に従うブラウザーやアプリの通信が、ローカルのプロキシポートに送られます。
初期設定ではTUNを同時に有効にする必要はありません。まずシステムプロキシでブラウザーの接続をテストすると、設定する項目が少なく、元に戻すのも簡単です。Linuxでは、デスクトップ環境やアプリによってシステムプロキシへの対応状況が異なります。クライアントに切り替えスイッチがない場合や、ブラウザーが独自のプロキシ設定を使う場合は、そのクライアントの説明に従ってアプリ側のプロキシ設定を確認してください。他のガイドにあるポート番号をそのまま使わず、現在のクライアントに設定されている待ち受けポートを確認します。関連する項目はポート設定を参照してください。
ブラウザーにプロキシ切り替え拡張機能を入れている場合は、いったん無効にするか、システム設定に従う状態にしてください。システム設定が書き換えられるのを避けるため、ほかのプロキシクライアントや使用中のVPNも一時的に終了します。初回の接続テストで複数の通信取り込みツールを同時に使うと、リクエストがどのサービスを経由したのか分かりにくくなります。
モバイル:VPN接続を許可
AndroidまたはiOSのクライアントで、ホーム画面の「接続」または起動ボタンをタップします。初回接続時には、通常、システムからVPN設定または接続の確認が表示されるので、案内に従って許可してください。iOSでは、デバイスによる認証が必要な場合もあります。ここでいうVPNは、システムが提供する通信取り込み機能です。サブスクリプションが利用可能だと確認されたわけではありません。
クライアントに戻り、ステータスが「接続済み」または「実行中」になっていることを確認します。システムのネットワーク状態も見て、VPNが確立されているか確認してください。Androidではメーカーによってステータスバーのアイコンが異なるため、アイコンだけで判断しないでください。システムですでに別のVPN接続を使っている場合は、置き換えが発生するか確認してから続けます。初回テスト中はクライアントを前面で起動したままにし、バックグラウンド制限による切断と設定の問題を混同しないようにしてください。
許可を拒否した場合は、クライアントに戻って接続を再試行し、システム設定でそのアプリのVPN作成が許可されているか確認します。影響が分からないまま、ほかのアプリのネットワーク設定を削除しないでください。許可を繰り返し求められる、または起動に失敗する場合は、OSのバージョンと表示されたメッセージを記録し、接続トラブルの対処法を確認してください。
この手順の完了後は、クライアントを起動したままにし、デスクトップではシステムプロキシ、モバイルではVPNを有効にしておきます。クライアントを終了したり、DNS設定を変更したりする前に、次の手順で実際のリクエストが接続できるか確認します。
4. アクセス結果とルールの適用を確認
新しいブラウザーウィンドウまたはタブを開き、現在の設定でプロキシ経由になる想定で、サービスが正常に動作しているサイトにアクセスします。使い慣れたサイトを選べば十分です。テストのためにアカウントへログインしたり、機密情報を入力したりする必要はありません。ブラウザーが古いページを再利用している場合は、そのページを閉じて開き直してください。キャッシュや既存の長時間接続があると、前後の結果を比較しにくくなることがあります。
アクセスしながら接続履歴を確認
クライアントの「接続」「Connections」またはリクエスト履歴を開き、ブラウザーで対象ページを再読み込みします。直前のリクエストに対応するドメインを探し、適用されたルール、渡されたプロキシグループ、最終的な出力先を確認してください。画面に一部の情報しか表示されない場合は、接続の詳細を開くか、ログも確認します。ページが表示されるのは最初の確認結果です。接続履歴の経路も想定どおりなら、通信の振り分けも正しく行われています。
続けて、設定上DIRECTになる想定のサイトにアクセスし、同じ方法で履歴を確認します。2つのアクセスでそれぞれ想定どおりのプロキシ出力先とDIRECTが表示されれば、少なくともこの2つのテスト対象はルールモードで設定どおりに処理されています。DIRECTのリクエストもクライアントの履歴に表示されることがあります。リクエストはコアに届いており、最終的にコアが宛先へ直接接続したためです。
1つのサイトが開けるかどうかだけで、すべてのルールが正常だと判断しないでください。また、一度の出口IP確認を、すべてのアプリの通信が取り込まれている証拠と考えないでください。出口IPの確認で分かるのは、そのリクエストの経路だけです。アプリやドメイン、接続方式によって適用されるルールは異なる場合があります。初期設定では、普段使うブラウザーと実際に利用する場面を1つ確認してから、テスト対象を少しずつ増やしてください。
問題が起きたら経路を切り分け、複数の設定を同時に変更しない
接続先にアクセスできず、対応する接続履歴もまったく表示されない場合は、まずシステムプロキシまたはVPNが有効か、ブラウザーがシステム設定を迂回していないか、コアが動作中か確認します。この段階では通信の入口を調べ、すぐにルールセットを変更しないでください。履歴があるのに最終的な出力先が想定と異なる場合は、手順2に戻り、モード、プロキシグループ、現在有効な設定を確認します。
接続履歴で想定どおりのプロキシを経由しているのにリクエストが失敗する場合は、「ログ」画面を開き、アクセスした時刻のエラーを探します。timeoutは通常、接続処理のどこかが制限時間内に完了しなかったことを示します。名前解決の失敗は、接続先のドメインとサーバーのドメインを分けて確認する必要があります。こうした表示だけで、どちら側に問題があるかは判断できません。同じプロキシグループ内で利用可能だと分かっている別の出力先に切り替え、ほかの設定は変えずに同じ接続先へ再度アクセスしてください。
詳しい情報が必要な場合に限り、ログレベルを一時的に上げ、テスト後は通常のレベルに戻します。問い合わせの際は、クライアント名、OSのバージョン、再現手順、発生時刻、認証情報を伏せたエラー内容を添えてください。サブスクリプションURL全体や認証情報は公開しないでください。より詳しいトラブルの切り分けは接続とアクセスに関する問題を、ログの読み方はよくあるエラーの意味と調査方法を参照してください。
正常な状態を保存し、終了後のネットワークも確認
アクセスと通信の振り分けが想定どおりになったら、現在の設定名、選択したプロキシグループ、通信の取り込み方法を記録し、元の設定ファイルもバックアップします。普段の利用では、サブスクリプションを更新した後にプロキシグループの選択を簡単に確認してください。提供元がグループを変更したり出力先を削除したりすると、以前の選択が使えなくなる場合があります。自動起動、バックグラウンド実行、定期更新は、基本的な接続が安定してから1つずつ設定してください。
デスクトップでは、使用を終えるときにまずシステムプロキシを無効にし、その後クライアントを終了して、通常のWebページにアクセスできることを確認します。多くのクライアントは終了時にプロキシ設定を元に戻しますが、プロセスを強制終了すると設定が残ることがあります。終了後にネットワークへ接続できない場合は、システムプロキシが停止中のローカルサービスを参照していないか確認してください。モバイルではクライアントから接続を切断し、システムVPNも終了したことを確認します。
これで、サブスクリプションの読み込み、モードの選択、通信の取り込み、アクセス確認まで一通り完了です。振り分けをカスタマイズしたり、対象アプリを増やしたりする場合は、初心者から上級者までの完全ガイドを参照してください。今回正常に動作した設定を基準として保存し、変更するたびに最後の手順を繰り返して確認しましょう。