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

サブスクリプションを追加して現在の設定に指定する

クライアントを開いたら、まず「サブスクリプション」「設定」または Profiles ページを探します。入力欄がページ上部にあるクライアントもあれば、「新規作成」「URLから追加」またはプラスボタンを先に押す必要があるクライアントもあります。サブスクリプションサービス提供元から渡された完全なURLを入力欄に貼り付けます。管理画面のURL、プラン名、個別ノードの文字列をサブスクリプションURLとして使わないでください。余分な空白や改行がないことを確認し、「追加」「ダウンロード」または「登録」をクリックします。

通常、クライアントはサブスクリプションURLへアクセスし、新しい設定項目を生成します。この時点では接続を急いで有効にせず、項目名、更新日時、クライアントのステータスを確認します。ネットワークエラー、形式エラー、設定の解析失敗が表示された場合、追加処理は完了していません。プロキシモードを切り替えても解決しません。URLをコピーし直し、ブラウザーでサービスページにアクセスできるか、サブスクリプションが有効か確認してください。認証の期限切れ、内容が空、サーバー側の異常については、サブスクリプションサービス提供元へ問い合わせます。

設定項目が表示されたら、その項目をクリックするか横の有効化ボタンを使い、現在の設定に指定します。多くのクライアントでは複数の設定を保存できますが、コアが実行するのは同時に選択された1つの設定だけです。リストに追加しただけで選択していないことは、「追加済みなのにプロキシページにポリシーグループがない」主な原因です。選択後、「プロキシ」または Proxies ページを開き、サブスクリプションで定義されたポリシーグループと選択肢が表示されれば、設定はコアに読み込まれています。次の手順へ進めます。

追加完了時に確認できる状態

最初に確認すべき結果は、ウェブページへアクセスできることではありません。クライアント内に選択可能な設定項目が表示され、設定の詳細にポリシーグループがあり、解析エラーが継続していないことです。追加後に新しい設定へ自動で切り替わるクライアントもあれば、以前のローカル設定を維持するクライアントもあるため、現在の項目を手動で確認します。サブスクリプション更新後にポリシー名が大きく変わった場合も、古い設定キャッシュを使い続けないよう現在の選択を再確認してください。

この段階で解決するのは「設定をどこから取得するか」と「コアがどの設定を読み込むか」です。各リクエストの出口や、ブラウザー・システム通信をクライアントへ渡す方法はまだ決まっていません。設定が選択されていることを確認したら、次にプロキシモードを選び、リクエストをルールごとに判定するのか、1つのポリシーへまとめて渡すのかをコアに指定します。

ルールモードまたはグローバルモードを選択する

クライアントの「モード」「プロキシモード」または Mode 設定を開きます。一般的な選択肢はルールモード、グローバルモード、ダイレクトモードです。初回設定ではルールモードを推奨します。ルールモードは設定ファイルのルールを上から確認し、最初に一致したルールで判定を止め、指定された DIRECT、REJECT、またはポリシーグループへリクエストを送ります。ドメインやアドレスごとに異なる経路を使えるため、多くのサブスクリプション設定が想定する動作でもあります。

ルールモードを選択したら、「プロキシ」またはポリシーグループのページを開きます。ここに表示される名称は現在の設定によって決まり、サブスクリプションごとに大きく異なる場合があります。主要なプロキシ選択用のポリシーグループを見つけ、その中から具体的な選択肢または設定が提供する自動選択を指定します。PROXYを、クライアントに必ず存在する固定ボタンだと考えないでください。YAMLの例では、通常はポリシーグループ名にすぎず、設定内のproxy-groupsで定義されている必要があります。実際の画面では現在の設定に表示されるグループ名を確認してください。

グローバルモードは、クライアントが取り込める通信をまとめてグローバルポリシーへ渡します。短時間の比較テストに適しています。たとえばルールモードでウェブサイトに接続できず、グローバルモードで接続できる場合、問題はサブスクリプション全体ではなく、ルール判定、ポリシーグループの選択、DNS経路にある可能性が高くなります。比較後はルールモードへ戻し、ログで適用ルールを確認します。グローバルモードを常用すると、設定本来の振り分けを迂回し、どのルールが結果を生んだかも特定できません。

ダイレクトモードは通常、取り込まれたリクエストを直接宛先へ接続します。クライアントの取り込み自体がアプリに影響しているか確認する用途に使えますが、「クライアントを停止する」と同じ意味ではありません。システムプロキシやTUNが有効なままだと、通信はいったんコアへ入り、ダイレクトポリシーで送信されることがあります。取り込みを完全に停止する場合は、次の手順で該当するシステムプロキシ、VPN、TUNを無効にしてください。モードだけを変更しても停止にはなりません。

ポリシーグループが空、すべての選択肢が無効、またはモード切り替え直後に設定エラーが出る場合は、システムプロキシを有効にせず最初の手順へ戻り、現在の設定を確認します。モードとポリシーを正常に選択できて初めて、設定側の準備が完了します。次に端末やアプリの通信をクライアントへ渡します。

システムプロキシを有効にして接続を確立する

クライアントのホーム画面または設定画面に戻り、「システムプロキシ」「システムプロキシとして設定」など、同じ意味のスイッチを探して有効にします。デスクトップOSのシステムプロキシはOSのプロキシ設定へ反映され、その設定に従うブラウザーやアプリがクライアントの待ち受けポートへリクエストを送るようになります。有効化に成功すると、クライアントに有効状態が表示されます。システムのネットワーク設定を開き、HTTP、HTTPS、SOCKSのプロキシ項目がクライアントによって管理されているか確認することもできます。

AndroidとiOSのクライアントは通常、システムVPNインターフェースを通じて通信を取り込みます。初回起動時にVPN構成または接続許可が表示され、確認後はステータスバーにシステムVPNの表示が出ることがあります。この許可はクライアントがローカルネットワーク経路を作成することを認めるもので、サブスクリプションサービスとクライアントが同じ提供元であることを意味しません。許可を拒否すると、設定とポリシーはクライアント内で表示されても、他のアプリの通信はコアへ入りません。

macOSでは、クライアントによってシステムプロキシ、VPN構成、ネットワーク拡張を使います。Windowsクライアントでも、TUNを有効にすると管理者権限を求められる場合があります。まずブラウザーだけを確認するなら、システムプロキシを優先してください。影響範囲を観察しやすく、問題発生時にも無効化しやすいためです。ターミナル、ゲーム、仮想マシン、自前のネットワークスタックを使うアプリはシステムプロキシを無視することがあるため、その場合にTUNを検討します。初回からすべての取り込み方式を同時に有効にしないでください。

取り込みを有効にする前に、ポリシーグループで利用可能な選択肢が指定されていることも確認します。クライアントがポリシーテストに対応していれば、提供されている接続確認を1回実行できます。ただし結果が示すのはテスト対象へのリクエスト状況だけで、実際のアプリによる確認の代わりにはなりません。その後はクライアントを起動したまま、新しいブラウザーウィンドウで次の手順へ進みます。接続前後にサブスクリプション、モード、DNS、TUNを同時に変更しないでください。一度に1つだけ変更すれば、差が生じた原因を特定できます。

ここまでの接続経路は、アプリがシステムプロキシを読み取るかVPN/TUNへ入り、通信がクライアントの待ち受け入口へ到達し、コアが現在の設定を読み込んで選択したモードで処理し、最終的にダイレクト、拒否、またはプロキシポリシーへ送る流れです。次はアプリの動作とクライアントログの両面からこの経路を確認します。ホーム画面のスイッチが点灯しているだけでは不十分です。

プロキシとルールが有効か確認する

まず、これまで開いていないウェブページを新しいタブで開きます。新しいリクエストを使うと、ブラウザーキャッシュ、既存の接続、DNSキャッシュによる判断への影響を減らせます。ページの読み込みと同時にクライアントのログまたは接続記録を開き、アクセスしたドメインを検索します。ドメイン、適用ルール、最終ポリシーが確認できて初めて、リクエストがコアへ入ったと判断できます。システムプロキシが有効なだけでは、特定のアプリがその設定を使った証拠にはなりません。

ログの結果はルールの想定と一致するはずです。たとえばダイレクトルールに一致した場合はDIRECT、拒否ルールならREJECT、ポリシーグループならグループ名と最終選択が表示されます。ルールモードは上から順に判定し、最初に一致した時点で停止します。そのため、後ろのルールがより具体的に見えても、先に一致したルールを上書きしません。経路が想定と異なる場合は、まず適用ルールを記録し、その後でルール順序やポリシーグループを確認します。ノードを何度も切り替えてルールの問題を隠さないでください。

ブラウザーの確認後、実際に使うアプリもテストします。ブラウザーは正常なのにターミナルコマンドが失敗する場合、両者が異なるプロキシ入口を使っていることが一般的です。ターミナルではHTTP_PROXY、HTTPS_PROXY、ALL_PROXY環境変数の個別設定が必要な場合や、TUNによる取り込みが必要な場合があります。アプリ独自のプロキシ設定がシステムプロキシを上書きすることもあるため、「プロキシを使用しない」、固定ポート、古いアドレスが選ばれていないか確認します。ブラウザーとターミナルを分けて確認する詳しい方法はヘルプセンターを参照し、基本手順で多くの項目を同時に変更しないようにしてください。

ログにテスト対象のドメインがまったく現れない場合は、通信の入口から確認します。デスクトップではシステムプロキシが有効で、ポートがクライアントの待ち受けポートと一致しているか確認します。モバイルではシステムVPNが別のVPNアプリに置き換えられていないか確認し、TUNでは権限とルートの作成に成功しているか確認します。ログにドメインはあるのにリクエストが失敗する場合は、最終ポリシー、接続エラー、DNS結果を確認します。前者は「アプリがクライアントに入っていない」問題、後者は「クライアントには入ったが、出口または名前解決で失敗した」問題であり、対処方法が異なります。

同じ設定とテストURLを維持したまま、ルールモードからグローバルモードへ一時的に切り替え、同じ利用可能なポリシーを選んで比較することもできます。グローバルモードでは成功し、ルールモードで失敗する場合は、ルール適用とDNSを重点的に確認します。両方で失敗する場合は、ポリシーの有効性、サブスクリプションの状態、ローカルネットワークを確認します。ブラウザーは成功して他のアプリが失敗する場合は、アプリのプロキシ設定と取り込み範囲を確認します。テスト後はルールモードへ戻し、テスト状態を常用設定にしないでください。

失敗したら層ごとに前の手順へ戻る

トラブル対処では、このガイドの順序に沿って前の手順へ戻ります。ログにリクエストがない場合は接続手順へ戻り、システムプロキシ、VPN、TUNを確認します。ログにリクエストはあるのに適切なポリシーがない場合はモード手順へ戻り、ポリシーグループとルールを確認します。プロキシページにポリシーグループがない場合は追加手順へ戻り、現在の設定と解析状態を確認します。一度に1つの層だけを確認するほうが、クライアントを削除して再インストールするより有効な手がかりを残せます。