Clashのサブスクリプション追加と接続方法。

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

サービス提供元のサブスクリプションページで、Clashまたはmihomo向けのリンクを探し、横にあるコピー用ボタンでURL全体をコピーします。URLにはアカウントに紐づく認証情報が含まれている場合があるため、公開チャットやスクリーンショットに表示しないでください。複数のクライアント形式が用意されている場合は、別形式を適当に試すのではなく、現在のクライアントに対応すると明記されたものを選びましょう。

クライアントに戻り、サイドバーの「設定」または「サブスクリプション」を開いて、「新規作成」「追加」「URLからインポート」などの項目を探します。入力欄にURLを貼り付け、設定を見分けやすい名前（例：「日常接続」）を付けて、「インポート」または「保存」をクリックします。入力欄が設定画面の上部にあり、貼り付け後にダウンロードアイコンを押すタイプのクライアントもあります。設定名はローカルでの識別用であり、サーバー上のノード情報には影響しません。

実行後、ダウンロードが終わるまで待ちます。通常は設定カードが表示されるか、一覧にサブスクリプションが追加されます。続いてその設定をクリックし、「有効化」「使用」または選択状態を示すマークで、現在の設定として有効にします。ダウンロード完了と設定の有効化は別の操作です。一覧にファイルがあっても、コアが読み込んでいるとは限りません。切り替え後に構文やフィールドのエラーが表示された場合は、次の手順に進む前にエラーを解消してください。

「プロキシ」画面を開き、プロキシグループとその中のノードが表示されていることを確認します。グループ名はサブスクリプションによって異なり、「プロキシ選択」やProxyなどの場合があります。本文と同じ名前である必要はありません。DIRECTやREJECTなどの組み込み項目しか表示されない場合は、設定画面に戻って現在の設定が選択されているかを確認し、サブスクリプションの更新結果も確認します。ノードが読み込まれていない状態でグローバルモードに切り替えても、ノードは追加されません。

インポートに失敗したら、まずURL全体が正しくコピーされているか、余計な空白や改行が入っていないか、末尾のパラメーターが抜けていないかを確認します。タイムアウトの場合は、現在のネットワークからサブスクリプションサーバーに接続できない可能性があります。解析エラーの場合は、ログインページやエラーページが返されたか、設定形式に互換性がない可能性があります。ブラウザーでURLを開けても、クライアントが読み込める設定が返されるとは限りません。詳しくはサブスクリプション更新に失敗した場合の対処法をご覧ください。提供元が不明なオンライン変換サイトにURLを渡すのは避けましょう。

サービス提供元からローカルのYAMLファイルを受け取った場合は、「ファイルからインポート」を選び、ファイルを指定して有効にします。ファイルのインポートではリモートの自動更新ができない場合があり、ノードの変更後に設定を再取得する必要があります。URL、ファイルのどちらを使った場合も、現在の設定が有効で、プロキシ画面に想定したグループが読み込まれ、未解決の設定エラーがないことを確認できれば、この手順は完了です。

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

ノードが読み込まれたことを確認したら、クライアントのホーム、プロキシ、または設定画面で「モード」を探します。初めて使う場合は「ルール」を選びましょう。英語では通常Ruleと表示されます。このモードでは設定内のルールに従い、接続ごとにDIRECT、プロキシグループなどの経路を選びます。プロキシを使う通信と通常のアクセスを分けるのに適しています。選択後は、まずサブスクリプションに含まれるルールをそのまま使い、大量のカスタムルールを追加するのは避けてください。

モードメニューの「グローバル」は、通常、コアに渡された接続をグローバルポリシーで処理する設定です。ルールが結果に影響しているか一時的に比較する際に使えます。「DIRECT」は、通常、コアに渡された接続を宛先へ直接接続します。混同しやすい点は、モードが決めるのは通信がコアに渡された後の経路であり、アプリの通信をコアに渡すことではありません。グローバルを選んでも、システムプロキシやVPNによる振り分けが設定されていないアプリは、通常どおり直接接続する場合があります。

「プロキシ」画面に戻り、設定内のルールが実際に参照しているメインのプロキシグループを開いて、ノードを選びます。「自動選択」や「フェイルオーバー」のグループがあれば、サブスクリプションで定義済みのグループを使ってもかまいません。最初のトラブル確認ではノードを1つ手動で固定すると、前後の結果を比較しやすくなります。補助的なグループでノードを選んだだけで、すべての通信に適用されると思い込まないでください。ルールによって参照するグループは異なります。

続いて、そのグループの遅延テストまたは接続テストを実行し、結果が表示されるまで待ちます。タイムアウトしたノードは初回確認に使わず、別のノードを試してください。テスト結果は、クライアントが指定のテスト先に一度接続した結果にすぎません。遅延が短くてもすべてのサイトのダウンロードが速いとは限らず、テストに成功してもアカウントの通信、対象サイト、経路全体が正常とは限りません。テストが何度も失敗する場合は、サブスクリプションの有効期限とサービスの状態を確認し、ノードの遅延とタイムアウトについてもご覧ください。

普段使う中で、Webサイトが想定どおりプロキシを経由しない場合は、まず接続ログで適用されたルールを確認し、振り分け設定を変更するか判断しましょう。グローバルへの一時的な切り替えは原因の切り分けに役立ちますが、テスト後はルールモードに戻してください。グローバルにしても、通信を振り分けていないアプリを対象にしたり、利用できないノードを直したりはできません。ルール、プロキシグループ、ノードの違いは用語集をご覧ください。このチュートリアルでは「ルールモードと明確な出口1つ」のシンプルな構成を使います。

ここまでで、使用する設定、通信の処理モード、メインのプロキシグループで使う出口が決まりました。次は、システムまたはアプリからクライアントへ通信を渡します。現在のモードとノードを覚えておき、以降のテストではノード変更、モード切り替え、DNS設定変更を同時に行わないでください。接続が戻っても、どの変更が有効だったのか判断しにくくなります。

ステップ3：サービスを起動して通信を振り分ける

クライアントのホーム画面に戻り、コアまたはサービスの状態を確認します。起動すると自動でコアが動くクライアントもあれば、「起動」や接続ボタンを押す必要があるものもあります。実行中と表示され、ポートの競合や設定の読み込み失敗などのエラーがないことを確認してください。コアが正常に起動していない状態でシステムプロキシを有効にすると、アプリが応答のないローカルポートへ接続し、これまで開けていたサイトにもアクセスできなくなることがあります。

Windows、macOS、Linuxのデスクトップでは、初回テスト時にまず「システムプロキシ」を有効にします。この設定によってシステムのプロキシ設定が変更され、設定に従うブラウザーやアプリの通信がローカルのクライアントに渡されます。有効にしたら、ブラウザーで新しいタブを開いてテストしてください。ネットワーク設定の変更を求められた場合は、利用中のクライアントからの要求であることを確認して許可します。セキュリティ機能を無効にすることを、インストールの定番手順にしないでください。

システムプロキシですべてのソフトウェアをカバーできるわけではありません。一部のゲーム、コマンドラインツール、独自にプロキシを指定するアプリはシステム設定を無視する場合があります。ブラウザーでは有効なのに別のプログラムで変化がない場合も、ノードの不具合とは限りません。まずブラウザーで動作を確認し、その後でアプリ個別のプロキシ設定が必要か、TUNを使うか検討してください。コマンドラインのプロキシ環境変数はシステムプロキシとは別の設定です。今回のブラウザーテストのためだけに変更する必要はありません。

AndroidとiOSでは、通常「接続」をタップするとシステムVPNの許可画面が表示されます。アプリ名を確認して接続を許可し、クライアントに戻って状態を確認してください。システムのVPNアイコンが表示されても、対象サイトに接続できることまでは保証されません。端末で別のVPNを使用中の場合は、いったん切断してからテストします。仕事用プロファイル、デバイス管理ポリシー、システムの「常時接続VPN」設定などが、新しい接続を制限する場合もあります。

デスクトップアプリがシステムプロキシに従わない場合は、クライアントで「TUN」「仮想ネットワークアダプター」などの項目を探します。TUNは仮想ネットワークインターフェースを通じて通信を振り分けるため、サービスのインストール、ルーティング、追加の権限が必要になることがあります。利用中のクライアントの案内に従って許可してください。他の解説にあるネットワークアダプター名、ルート設定コマンド、DNSパラメーターを、そのまま自分の環境に適用しないでください。Linuxの権限、macOSのネットワーク許可、Windowsのサービス状態は、それぞれのプラットフォームに応じて確認します。

TUNを有効にしてネットワーク全体に問題が起きたら、まずTUNをオフにし、通常の直接接続が戻るか確認します。DNSやルート設定をさらに追加しないでください。仮想ネットワークアダプター、権限、DNSの振り分けを詳しく確認する場合は、全プラットフォーム向けガイドの該当セクションをご覧ください。この手順の完了時には、デスクトップのシステムプロキシ、または正しく許可されたVPN／TUNなど、通信の振り分け方法が明確に1つ選ばれている状態にします。

ステップ4：通信経路を確認して元の状態に戻す

接続ボタンが有効になっても、アイコンの色だけで判断しないでください。ブラウザーで新しいタブを開き、プロキシ経由でアクセスしたいことが明確で、サイト自体も正常に動作しているWebサイトにアクセスします。読み込み済みのページ、オフラインキャッシュ、既存の接続をテスト結果と取り違えないよう、新しいリクエストを使いましょう。続いてクライアントに戻り、「接続」またはConnections画面で、アクセスしたドメインを探します。

該当する接続を開き、対象ドメイン、適用ルール、プロキシグループ、最終的な出口を確認します。表示される項目はクライアントによって異なり、プロキシ経路全体が表示される場合もあれば、最終ノードだけが表示される場合もあります。選択したプロキシノードが最終出口として記録され、Webページも正常に読み込まれるなら、そのリクエストの振り分けとプロキシ経路はおおむね正常です。DIRECTと表示された場合はルールを確認してください。想定どおりの直接接続の場合もあれば、想定と異なる振り分けの場合もあります。

Webページは開くのに接続一覧で該当するリクエストが見つからない場合は、フィルターが有効になっていないか、一覧が更新停止中でないか、特定のプロセスだけに絞っていないかを確認し、もう一度アクセスします。それでも記録がない場合は、ステップ3に戻り、アプリがシステムプロキシに従っているか、VPN／TUNが実際に接続されているかを確認してください。ページにアクセスできたことだけでプロキシが有効と判断するのは避けましょう。対象サイトには直接接続できる可能性もあります。

続いて、DIRECTになる想定のよく使うWebサイトにもアクセスし、同様に接続ログを確認します。ルールモードでは、2つのサイトが異なる出口を使うのは正常です。出口IP確認サイトを補助的に使う場合は、その確認リクエスト自体がプロキシ経由か直接接続かを確認してください。表示されたIPが示すのはそのリクエストの結果であり、端末内のすべてのアプリが同じ出口を使っていることの証明にはなりません。結果のスクリーンショットを共有する場合は、自分のIPアドレス、サブスクリプション情報、アカウント情報を隠してください。

「ログはプロキシ経由なのにWebページが開かない」場合は、対象サイトを変え、次にノードを変えます。一度に変更するのは1つだけにしてください。複数のサイトで失敗し、ノードテストもタイムアウトする場合は、まずノードとサービスの状態を確認します。1つのサイトだけ失敗する場合は、そのサイトの制限、ノードの出口、ルールが原因かもしれません。ページは表示されるのに一部のリソースが読み込めないときは、グローバルモードを何度も切り替えるより、失敗したリソースの接続ログを確認する方が役立ちます。詳しくはよくある質問から症状に合った項目をご覧ください。

アクセスのテストが終わったら、接続を終了した後の状態も確認します。デスクトップではシステムプロキシまたはTUNをオフにし、モバイルでは接続を切断してから、通常のWebサイトにアクセスできることを確認してください。デスクトップでは、システムプロキシを元に戻さずにクライアントを強制終了しないでください。終了後にブラウザーが接続できない場合は、システムのネットワーク設定にローカルクライアントを指す手動プロキシが残っていないか確認します。元に戻すときは、今回クライアントが変更した項目だけを修正し、会社や学校で必要なプロキシ設定を誤って削除しないようにしてください。

最後に、利用できる設定名、通信の振り分け方法、現在選択しているプロキシグループを記録しておきます。トラブルが起きたら、動作確認済みの状態に戻しやすくなります。サブスクリプション更新後に動作が変わった場合も、まず現在の設定とグループ内の選択がリセットされていないか確認してください。自動更新、DNS、ルールセット、各プラットフォームのバックグラウンド実行権限などを設定する場合は、全プラットフォーム向けガイドの設定に関するよくある質問をご覧ください。初回接続の段階ですべての詳細設定を変更する必要はありません。