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

クライアントと有効なサブスクリプションを用意

インストール済みのクライアントを起動し、メイン画面が正常に表示されることを確認してから、サービス提供元のサブスクリプションURLを用意します。クライアントは設定を読み込んで通信を中継し、サブスクリプションはノード、プロキシグループ、ルールを提供します。ソフトウェアをインストールしただけでは、プロキシサービスは利用できません。当サイトではクライアントのダウンロード方法と設定手順を案内していますが、サブスクリプションの発行や、期限切れアカウントの復旧は行っていません。

サブスクリプションURLは通常、パラメーターを含む長いURLです。サービス提供元のアカウントページにあるコピー機能を使って取得してください。ブラウザーのアドレスバーに表示された管理画面のURLをサブスクリプションと取り違えたり、スクリーンショットやQRコード画像のリンクをコピーしたりしないでください。URL内のパラメーターはアカウント権限に関係する場合があるため、パスワードと同様に取り扱いましょう。問い合わせる際はエラー内容だけを伝えるか、スクリーンショットの機密情報を隠してください。

初期設定の前に、ほかのプロキシクライアント、ブラウザーのプロキシ拡張機能、使用中のVPNを終了してください。複数のツールが同時に通信を制御すると、ポートの競合や設定の上書きが起き、どの接続方法が使われているか分かりにくくなります。クライアントのポート、DNS、LAN設定はひとまず初期値のままにし、ネット上の設定例をいくつも適用するのは避けましょう。すでに利用中の設定がある場合は、先にエクスポートするかコピーしてバックアップしてください。

各手順には完了の目安があります。該当する状態を確認してから次へ進んでください。「サブスクリプション」「コア」「プロキシグループ」などの用語に不慣れな場合は、先に用語ガイドをご覧ください。各項目の詳しい意味は設定ガイドで確認できます。このページでは、初回接続までの流れに絞って解説します。

サブスクリプションURLを貼り付けて設定を有効化

クライアントのサイドバーから「設定」または「サブスクリプション」を開き、「URLから追加」「サブスクリプションを追加」またはプラス記号のボタンを探します。追加画面が表示されたら、種類はリモートサブスクリプションを選び、名前には識別しやすい短い名称を入力します。URL欄に先ほどコピーしたリンク全体を貼り付け、前後に空白や改行、チャットアプリが付けた句読点がないことを確認して、「追加」「ダウンロード」または「保存」をクリックします。

クライアントがサブスクリプションを取得し、設定を読み込みます。正常に完了すると、設定名や更新日時が記載された設定カードが表示されます。追加した設定が自動で有効になるクライアントもあれば、カードの「使用」「有効化」ボタンを押すか、選択状態にする必要があるものもあります。現在の設定が選択されていることを確認してから「プロキシ」画面を開き、プロキシグループが表示されるか確認してください。ファイルのダウンロードが完了しただけでは、コアがその設定に切り替わったとは限りません。

サブスクリプションの形式を尋ねられた場合は、サービス提供元が対応を明示しているClash形式またはmihomo形式を選択してください。通常のWebページ、アカウントのログインページ、ほかのクライアント専用形式では、読み込みに失敗することがあります。「設定が無効」「プロキシが見つかりません」と表示されたら、まずサービス提供元のページでサブスクリプションの種類を確認しましょう。URL全体を、よく知らないオンライン変換サイトに入力しないでください。形式が合わない場合は、サービス提供元に対応する接続方法があるか確認してください。

追加中にタイムアウトする場合は、現在のネットワークからサブスクリプションサーバーにアクセスできるか、また、まだ使えないプロキシを経由して更新する設定になっていないか確認します。「認証されていません」「リンクの有効期限が切れています」と表示された場合は、アカウントページで有効期限とURLの変更有無を確認してください。何度も更新を試しても権限の問題は解決しません。すぐにDNSを変更したり、TUNを有効にしたり、クライアントを再インストールしたりする必要はありません。

YAMLファイルをすでに保存している場合は、「ファイルからインポート」から選択できます。ただし、ローカルファイルはリモートサブスクリプションの更新が自動反映されないのが一般的です。初めて使う場合は、サービス提供元のリモートサブスクリプションを直接追加する方法がおすすめです。ファイルからのインポートとURLからのインポートは、どちらか一方で十分です。同じ内容を両方追加すると、後で古い設定を有効にしてしまうおそれがあります。

この手順の完了目安：設定一覧に新しい項目が表示され、現在の設定として選択されています。「プロキシ」画面にプロキシグループも表示されます。次はモードとポリシーを選択します。設定ファイルはまだ変更しないでください。

ルールモードと出力ポリシーを設定

「概要」「プロキシ」または「設定」画面にある動作モードの項目を開き、まず「ルール」を選択します。英語表示では通常Ruleです。ルールモードでは、設定ファイル内のルールの順序に従って接続先が決まります。一部の通信は直接接続され、ほかの通信はプロキシグループに振り分けられます。日常利用に適したモードですが、どのサイトがプロキシ経由になるかは、現在のサブスクリプションに含まれるルール次第です。クライアントがサイト名を見て自動で判断するわけではありません。

次に「プロキシ」または「プロキシグループ」画面を開き、主なプロキシグループを展開します。グループ名はサブスクリプションの作成者が決めるため、「プロキシ選択」「ノード選択」など、チュートリアルと異なる場合があります。同じ名前を探す必要はありません。手動選択に対応しているグループでは、サービス提供元が利用可能と案内しているノードを一つ選びます。自動選択グループの場合は、初期設定のままで構いません。グループが別のグループを参照している場合は、最終的にどの出口が選択されているか確認してください。

初回接続では、プロキシを使う主要なグループにDIRECTを選ばないよう注意してください。DIRECTは対象へ直接接続する設定であり、リモートノード経由を意味しません。REJECTは接続を拒否します。ノードの接続テストは明らかな不具合を見つけるのに役立ちますが、テスト先に接続できたからといって、すべてのサイトにアクセスできるとは限りません。まず選択を一つに決め、実際のWebページで確認しましょう。頻繁に切り替える必要はありません。

「グローバル」またはGlobalでは、コアに入った通信をすべてグローバルポリシーに送るため、短時間の比較テストに適しています。ただし、パソコン上のすべてのアプリが自動的にクライアントを経由するわけではなく、サブスクリプションの期限切れやノードの障害も解消しません。「ダイレクト」またはDirectでは、コアに入った通信がリモートのプロキシノードを経由しません。動作モードと、次の手順で設定するシステムプロキシやTUNは別の要素です。前者は通信の振り分け方、後者は通信をコアに取り込む方法を決めます。

以下は、この手順で扱う基本項目の例です。名称を確認するためのもので、サブスクリプションの置き換えには使えません。実際のサブスクリプションにはプロキシ、プロキシグループ、ルールなども含まれます。この数行だけでは、利用可能なプロキシサービスになりません。ルールを調整する場合はルール構文のリファレンスを、モードとプロキシグループの違いを確認する場合は用語ガイドをご覧ください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

この手順の完了目安：動作モードがRuleに設定され、主要なプロキシグループでノードまたは自動選択ポリシーが指定されています。次は通信の入口を有効にし、アプリの通信をクライアントに取り込みます。

プロキシの入口を有効にしてコアの起動を確認

デスクトップでは、クライアントの概要またはログを開き、コアが起動していて、設定の読み込み失敗やポート競合が発生していないことを確認します。ウィンドウが表示されていても、コアが動作しているとは限りません。起動エラーが表示された場合は、プロキシを有効にする前に解消してください。混合ポートの初期値は7890が一般的ですが、実際の値はクライアントの表示を確認してください。この数字に合わせるためだけに、ほかのポート設定まで変更しないでください。

コアの起動を確認したら、設定画面で「システムプロキシ」を有効にします。システムプロキシに対応したアプリに、ローカルのプロキシポートへリクエストを送るよう指定する設定です。クライアントを起動したまま、ブラウザーに新しいタブを開いてテストの準備をしましょう。ブラウザーに独自のプロキシ設定を行う拡張機能がある場合は、先に無効にしてください。拡張機能に残った古い接続先がシステム設定を上書きし、ブラウザーとほかのアプリで動作が異なることがあります。

AndroidとiOSでは通常、クライアントのホーム画面にある接続ボタンから起動します。初回接続時に、システムからVPN接続の追加または確立を許可するか確認されます。要求元のアプリを確認して許可し、クライアントに戻って接続状態を確認してください。ここでいうVPNは、システムが提供する通信制御の入口です。システム設定で別のVPNを手動登録するという意味ではありません。端末がほかのVPNに接続中の場合は、先に切断してからクライアントを起動してください。

システムプロキシ、TUN、ブラウザーの手動プロキシを同時に有効にしないでください。デスクトップでは、まずシステムプロキシでブラウザーの接続を確認します。システムプロキシに従わないアプリも通信させる必要がある場合に限り、TUNを検討してください。TUNは仮想ネットワークインターフェースを使って通信を取り込みます。クライアントによっては、サービスモード、管理者権限、追加のシステム許可が必要です。試す場合は、現在の設定を記録してから、クライアントの説明に従ってTUNだけを切り替え、手順04の確認をやり直してください。

システムプロキシを有効にした後、すべてのページが開かなくなった場合は、まずシステムプロキシを無効にし、元のネットワークが復旧するか確認します。復旧する場合は、設定を追加するのではなく、クライアントの接続入口、コア、ノードを確認してください。復旧しない場合は、ブラウザーの手動プロキシ、ほかのVPN、システムのネットワーク設定が残っていないか確認します。通常の終了時は、先にプロキシの入口を無効にしてからクライアントを終了してください。プロセスを強制終了すると、停止したポートを参照するシステムプロキシ設定が残ることがあります。

このパソコンだけで使う場合、「LAN内の接続を許可」を有効にする必要はありません。外部から制御できるアドレスを外部公開用に変更する必要もありません。これらは初期設定のままにしておくと、不要なネットワーク公開を抑えられます。TUN、ルーティング、DNSの詳しい関係は、後で設定ガイドをご覧ください。まずはブラウザーの接続を確認しましょう。

この手順の完了目安：デスクトップではコアが起動し、システムプロキシが有効になっています。モバイルではシステムから接続を許可されています。ステータスボタンで分かるのは入口が起動したことまでです。実際に通信できるかは次の手順で確認します。

Webページ、ルール、接続先を確認

まず、普段から開けるWebページにアクセスし、基本的なネットワークが正常なことを確認します。次に、プロキシ経由でのアクセスが必要だと分かっているページを開いてください。新しいタブで表示し、再読み込みして、ブラウザーのキャッシュに残った古い内容を接続成功と誤認しないようにします。一つのサイトが開かなくても、設定ミスとは限りません。サイト側の障害、アカウント制限、接続元へのアクセス制限なども考えられるため、クライアントのログと合わせて判断しましょう。

対象ページを開いたまま、クライアントの「接続」または「ログ」画面で該当ドメインの記録を探します。まずリクエストが記録されているか確認し、次に適用されたルール、使われたプロキシグループ、最終的な接続先がノードかDIRECTかを確認してください。表示される階層はクライアントによって異なります。グループ名しか見えない場合は詳細を開きましょう。対象のリクエストが記録されていれば、その通信がコアに入ったことが分かります。想定どおりの接続先になっていれば、通信の振り分けも機能しています。

対象ページが開かず、該当する接続記録もまったくない場合は、まず通信の入口を確認します。デスクトップではシステムプロキシが有効か、ブラウザー独自のプロキシ設定がないか確認してください。モバイルでは、システムの接続がほかのVPNに置き換わっていないか確認します。ログレベルが低すぎる場合や、接続記録が一時停止されている場合もリクエストが表示されません。記録を通常の状態に戻してから再度テストしてください。リストに何も表示されないだけで、ノードが使えないと決めつけないようにしましょう。

記録はあるものの接続先がDIRECTで、プロキシが必要なページにアクセスできない場合は、ルールモードになっているか、対象グループでダイレクトポリシーが選ばれていないか確認します。一時的にグローバルモードへ切り替え、利用可能なノードを明示的に選んで再テストすることもできます。グローバルでは接続でき、ルールモードでは失敗する場合、ルールまたはグループの選択が主な確認ポイントです。テスト後はルールモードに戻してください。一時的な比較設定を、あらゆる問題に対する恒久的な解決策にしないようにしましょう。

記録にプロキシノードが表示されるのにタイムアウトが続く場合は、まず利用可能と分かっている別のノードに切り替え、サブスクリプションのアカウント状態を確認します。一部のドメインだけで名前解決に関するエラーが起きる場合に、DNSを調べましょう。原因が分からないままポート、DNS、TUNを同時に変更しないでください。復旧しても、どの変更が効いたのか分からなくなります。設定は一つずつ変更し、同じアクセス方法で再テストして、元に戻す方法も記録してください。

信頼できるIPアドレス確認サイトを開き、プロキシの有効・無効による結果の違いを見ることも、補足情報として役立ちます。ルールモードでは、確認サイトと対象サイトで異なるポリシーが使われる場合があります。そのため、IP確認の結果だけで、すべての通信が同じ出口を通っているとは判断できません。対象サイトに対応する接続記録を優先して確認し、チャットやスクリーンショットで出口IP全体を公開するのは避けてください。

この手順の完了目安：普段使うページが開き、対象ページにもアクセスでき、該当する接続記録に想定した出力ポリシーが表示されています。これで初期設定は完了です。まずは現在の設定でしばらく使い、応用機能は一つずつ試すことをおすすめします。

動作する設定を保存して、以後の更新に備える

現在有効な設定名、動作モード、主なポリシーの選択内容を記録しておきましょう。クライアントにバックアップ機能がある場合は、正常に動作する設定を保存してください。リモートサブスクリプションの更新で、ローカルで直接編集した内容が上書きされることがあります。長期的に調整する場合は、クライアントのオーバーライドやマージの仕組みを先に確認し、一時的な変更だけをサブスクリプションのファイルに残さないようにしましょう。更新後に問題が起きた場合は、設定が有効なままか、プロキシグループの選択が変わっていないか確認してください。

引き続き原因を調べる場合は、接続済みなのにWebページが開かない場合のチェックリストを読み、基本的な項目から順に確認してください。YAML、DNS、プロキシグループの項目を詳しく知りたい場合は、設定ファイルの総合リファレンスをご覧ください。問い合わせる際は、OS、クライアント名、どの手順で止まったか、具体的なエラーを伝えましょう。サブスクリプションURLやアカウント情報は隠してください。「接続できない」とだけ伝えるより、原因を特定しやすくなります。