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

操作を始める前に、インストール済みのGUIクライアントと、サービス提供者が発行したClashまたはMihomo形式のサブスクリプションURLを用意します。URLは通常、https://で始まるリンクです。クライアントはこのURLからプロキシノード、プロキシグループ、ルール、一部のDNS設定を取得します。通常のWeb用サブスクリプション、別クライアント専用リンク、単一ノードだけを含む情報は、そのまま追加できない場合があります。形式に対応していない場合は、サービス提供者の管理画面でClash、Clash Meta、またはMihomoと明記された形式を選んでください。

まだクライアントをインストールしていない場合は、ダウンロードページでOSに合ったものを選びます。WindowsとmacOSではGUI対応のデスクトップクライアント、AndroidとiOSではシステムVPNインターフェースを利用できるモバイルクライアントが一般的です。LinuxのデスクトップではGUIクライアント、サーバーやルーターではMihomoコアの単独運用が適しています。この記事はGUIクライアントを中心に扱い、サーバーの起動オプションや管理画面の構築は扱いません。

サブスクリプションURLをコピーするときは、リンク全体を保持してください。チャットアプリでは長いURLが途中で切れたり、末尾の文字が句読点として認識されたりすることがあります。サービスページのコピー機能を使い、そのままクライアントに貼り付けるのがおすすめです。URLにはアクセス情報が含まれることが多いため、アカウント情報と同じように扱い、公開フォーラムやスクリーンショット、ログ共有ページに掲載しないでください。リンクが無効になった場合は、URLを何度も編集せず、サービス提供者のページで再発行します。

クライアントを開いたら、「サブスクリプション」「設定」、またはProfiles画面に移動します。「URLから追加」「新しいサブスクリプション」など、リンク追加の入口を探し、コピーしたURLを入力欄に貼り付けます。名前にはサービス名や用途など、識別しやすい短い名前を入力できます。クライアントがサブスクリプション名を自動取得する場合は、そのままでも構いません。確認後、ダウンロード、追加、保存などのボタンを押して処理が完了するまで待ちます。

追加に成功すると、設定一覧に新しいサブスクリプション項目が表示されます。多くのクライアントでは設定名と更新日時、一部では自動更新間隔も確認できます。この時点ではまだシステムプロキシを有効にせず、まず設定を選んで現在の設定にします。続いてProxyまたはProxies画面を開くと、「ノード選択」「自動選択」「直接接続」などのプロキシグループが表示されます。ルール画面にはDOMAIN、DOMAIN-SUFFIX、GEOIP、MATCHなどのルールタイプが表示されるはずです。これらを確認できれば、設定は正しく解析されています。

追加後に空の項目しか表示されない、またはプロキシ画面にグループがない場合は、まず手動で一度更新します。それでも空の場合は、URLが完全か、サブスクリプションの期限が切れていないか、サーバーの応答がクライアントに対応したYAML設定かを確認してください。ブラウザーでURLを直接開くと、テキスト表示、ダウンロード、アクセス制限などになることがありますが、それだけでは追加結果を判断できません。最終的には、クライアントがプロキシグループとルールを解析できるかで判断します。

一部のクライアントではローカルYAMLファイルを直接追加できます。通常は「ファイルを追加」を選ぶか、ファイルを設定一覧にドラッグします。ローカルファイルではサーバーの更新を自動取得できないため、ノードやルールが変わったら再ダウンロードが必要です。初回はURLサブスクリプションを保持し、適切な自動更新間隔を設定するほうが便利です。更新頻度を高くしすぎる必要はなく、サービス提供者の推奨値に合わせてください。

設定を有効にしたら、「モード」またはMode画面を開きます。一般的な選択肢はルールモード、グローバルモード、直接接続モードです。初回設定ではルールモード、つまりRuleを選ぶことをおすすめします。設定ファイルの上から順にルールを処理し、直接接続ルールに一致した通信はDIRECT、プロキシルールに一致した通信は指定されたプロキシグループ、それまでに一致しない通信はMATCHなど末尾のルールで最終的な経路が決まります。

グローバルモードでは、制御可能な通信の大部分を1つの共通ポリシーに渡します。プロキシ経路自体が確立できるかを短時間確認するには便利ですが、ルールによる振り分けの検証には向きません。直接接続モードは一時的にプロキシを迂回するためのものです。問題の切り分けでは比較のため一時的に切り替えても構いませんが、通常はルールモードに戻してください。そうしないと、設定内の地域、ドメイン、アプリごとの振り分けルールが設計どおりに動作しません。

ルールモードを選んだら、「プロキシ」「プロキシグループ」、またはProxies画面を開きます。通常は、具体的なノードを手動選択したり自動テストを実行したりするグループと、ルールから参照されて前者へ転送するグループの2種類があります。まず主要なプロキシ通信を担当する選択グループを見つけ、現在利用できる項目を選びます。すべてのグループを1つずつ変更する必要はありません。まずは「ノード選択」「プロキシ」「Proxy」などを含む名前、またはサービス提供者が指定するメインポリシーグループを設定し、ストリーミング、地域、アプリ専用グループは初回接続後に調整します。

プロキシグループのDIRECTは、プロキシ経路を通さず対象へ直接接続することを示します。REJECTはリクエストを拒否し、具体的なノード名は対応するプロキシへ通信を渡します。自動選択やURL-Test系のポリシーは、設定に従ってテストを実行し結果を選びますが、テスト先や実行タイミングはクライアントによって異なります。初回設定ではメインポリシーグループが利用不能や未選択になっていないことだけ確認し、手動テストを何度も実行する必要はありません。

どのルールが特定のポリシーに一致するか、プロキシグループがどのように入れ子になるかは、サブスクリプションの設定内容によって決まります。この記事ではルールファイルを変更しません。中国本土と海外の通信の振り分け、ルールセット、プロキシグループの種類をカスタマイズする場合は、高度な設定ガイドで続けて操作してください。まずはサブスクリプション本来の構成を維持すると、初回接続時の変数を減らせます。

クライアントのホームまたは設定画面に戻り、コアが実行中であることを確認します。起動時にコアも自動起動するクライアントがある一方、「起動」「接続」または電源ボタン型のアイコンを押す必要があるクライアントもあります。コアが正常に起動すると、現在の設定名が表示され、システムプロキシ、VPN、TUNのスイッチを操作できるようになります。起動直後に失敗する場合は、まずクライアントのログを確認します。設定構文エラー、待ち受けポートの競合、システム権限不足などがよくある原因です。

WindowsとmacOSのGUIクライアントでは、初回接続に「システムプロキシ」を使うのが一般的です。スイッチを有効にすると、OSのHTTPおよびHTTPSプロキシがローカルの待ち受けポートを指し、システムプロキシ設定に従うブラウザーやアプリの通信がClashへ渡されます。経路が分かりやすく、初回確認に適しています。補助プログラムやシステム権限を求められた場合は、システムの確認ダイアログで許可してください。完了後、システムのネットワーク設定にクライアント管理のプロキシアドレスが表示されているか確認します。

AndroidとiOSのクライアントは通常、システムVPNインターフェースを使います。接続を押すと、システムにVPN設定または接続許可が表示されるので、確認してください。通常はステータスバーにVPNマークが表示されます。この許可はクライアントがローカルネットワークトンネルを作ることを認めるもので、ポリシー選択が正しいことを意味しません。現在のサブスクリプションとルールモードは引き続き有効にしてください。Androidでアプリ切り替え後に接続が頻繁に停止する場合は、バックグラウンド実行と省電力設定を確認します。詳しい対処手順はヘルプセンターで確認できます。

Linuxのデスクトップ環境では、クライアントとデスクトップシステムによって対応が異なります。システムプロキシと連携できるクライアントなら、対応するスイッチを直接有効にします。ローカルポートだけを起動する場合は、デスクトップのネットワーク設定または対象アプリに、クライアントが表示するHTTP、SOCKS、mixed-portのアドレスを入力します。コマンドラインプログラムはデスクトップのプロキシ設定を読み取らないことがあるため、対応状況に応じて環境変数を設定してください。初回確認では、まずシステムプロキシに対応したブラウザーを使い、基本経路を確認してから個別のコマンドラインアプリを設定するのがおすすめです。

TUNモードは、システムプロキシに従わない通信もより多く取り込めますが、仮想NIC、ルーティング、DNS、管理者権限が関係します。初回接続でシステムプロキシと複数の取り込み方式を同時に有効にする必要はありません。まずはプラットフォーム標準の接続方法で確認し、特定のアプリがプロキシに入らない、UDP通信を取り込みたい、システムプロキシだけでは不足するといった場合に、高度な設定のTUN章を参考に調整してください。問題がノード、ルール設定、システムによる通信の取り込みのどこにあるかを切り分けやすくなります。

クライアントのボタンの色だけで接続結果を判断しないでください。ブラウザーで、普段正常に開けるサイトを先に開き、次に現在の設定でプロキシポリシーへ渡るはずのサイトを開きます。ページが読み込まれたら、すぐにクライアントの「接続」「ログ」、またはConnections画面に戻ります。ここにブラウザーが発行したドメインのリクエストが表示され、適用されたルール、プロキシグループ、最終的な経路を確認できるはずです。

確認すべきなのはリクエスト数ではなく、「対象ドメインが想定したポリシーに入ったか」です。たとえば、設定で直接接続とされたドメインはDIRECT、プロキシ指定のドメインはメインプロキシポリシーまたは選択したノードとして表示されます。すべてのリクエストがDIRECTなら、現在のモードが直接接続になっていないか確認します。すべてが同じノードに入るなら、グローバルモードを誤って使っていないか確認します。接続画面に新しい記録がまったくない場合は、ブラウザーがシステムプロキシを使っていない、モバイルVPNが確立していない、またはブラウザー独自のプロキシ設定が有効になっている可能性があります。

システムネットワークの状態も補助的な確認に使えますが、1つのIP確認サイトだけに頼らないでください。ルールモードではドメインごとに異なる出口を使えるため、あるサイトに直接接続のアドレスが表示されても、すべてのプロキシが無効とは限りません。ブラウザーのリクエスト、クライアントの接続履歴、ルール適用結果をまとめて照合するほうが確実です。DNSの動作を確認する場合は、クライアントログにドメイン解決リクエストがあるか確認します。Fake-IPを使用している場合は通常のDNSモードとアドレスの見え方が異なります。詳しくは高度な設定ガイドのFake-IP章を参照してください。

確認が終わったらブラウザーを終了して再起動し、新しいプロセスでもシステムプロキシを読み取れるかもう一度テストします。その後クライアントも再起動し、現在のサブスクリプション、モード、プロキシ選択が保存されているか確認してください。システムプロキシの状態まで記憶するクライアントもあれば、コアだけを復元してシステムプロキシは自動変更しないクライアントもあります。これは実装上の違いです。利用中のクライアントの復元動作を把握しておけば、「再起動後に使えない」場合に、コアの起動不足かシステム側の取り込み不足かをすぐ判断できます。

トラブルシューティングでは、サブスクリプション、モード、DNS、TUN、システムプロキシを一度に変更しないでください。1回に1つの層だけを確認すれば、どの変更が結果に影響したか分かります。サブスクリプションの解析から始め、ポリシー、コア、システムによる取り込みの順に確認し、最後に特定のサイトやアプリを調べるのがおすすめです。以下の順序は前述の設定手順に対応しています。

以上の4ステップで、Clashの基本経路を確認できます。サブスクリプションが設定を提供し、ルールモードが経路を決め、システムプロキシまたはVPNがリクエストを取り込み、接続履歴が結果を検証します。サブスクリプション更新の失敗、ポート競合、UWPループバック、モバイルのバックグラウンド停止、DNS異常などは、症状に応じてヘルプセンターを確認してください。プロキシグループ、ルールセット、DNS、TUN、ローカルオーバーライドを変更する場合は、高度な設定ガイドを参照します。