Clash複数サブスクの管理と切替方法

なぜClashで複数サブスクを管理するのか

Clashを長く安定して使うなら、ひとつのプロキシサービスだけに依存しない構成を考えておくと安心です。サブスクリプションにはそれぞれ利用できるノード、通信経路、更新期限、対応プロトコルの違いがあります。あるサービスがメンテナンス中になったり、特定のネットワークからアクセスしにくくなったりしても、別のサブスクへ切り替えられれば、作業や閲覧を完全に止めずに済みます。

ただし、サブスクを無計画に追加すると、同じ名前のノードが大量に並び、どの設定が有効なのか分かりにくくなります。更新に失敗した古いプロファイルが残ったままになる、使っていないサービスへ定期的にアクセスし続ける、プロキシグループの参照先が意図せず変わる、といった問題も起こります。重要なのは、追加することではなく、名前、更新間隔、優先順位、切替方法を最初に整理することです。

Clash Verge、Clash Verge Rev、Clash for Windows、Clash for Android、Mihomo系クライアントでは画面の名称が少し異なりますが、基本的な考え方は共通しています。まず各サブスクをプロファイルとして登録し、次に利用するプロファイルを選び、最後にプロキシグループで手動または自動の出口を指定します。

追加前にサブスク情報を整理する

登録作業を始める前に、契約しているサービスを一覧にしておくと、後のトラブルシューティングが簡単になります。プロバイダの管理画面から取得したURLは、単なるノードURLや汎用リンクではなく、使用中のClashクライアントが読み込める形式であることを確認してください。多くの場合、管理画面には「Clash用」「Clash Meta用」「YAML設定」などの選択肢があります。

登録前に次の項目を確認してください。

サービス名：例として「メイン回線」「予備回線」「短期テスト」のように、用途が分かる名前を付ける。
更新期限：月額、通信量、契約終了日を記録し、期限切れのURLを残さない。
対応形式：Clash、Clash Meta、Mihomoのどのコアを対象にした設定か確認する。
通信量とノード数：大量のノードを含むサブスクは、更新や速度測定に時間がかかる場合がある。
認証情報：URLに含まれるトークンは契約情報そのものなので、公開チャットやスクリーンショットに載せない。

サブスクリプションURLは、たとえばhttps://example.com/sub?token=xxxxxxxxのような形をしています。URL末尾の文字列を削ったり、メッセージアプリからコピーした際に改行を混ぜたりすると、取得エラーの原因になります。登録用のURLを表計算ソフトやメモアプリに保存する場合も、アクセス権限を設定し、他人が閲覧できない場所に保管してください。

サブスクを追加し、分かりやすい名前を付ける

Clash Verge RevやMihomo系クライアントでは、通常「プロファイル」または「Profiles」画面からサブスクを追加します。Clash for Androidでは「設定」「プロファイル」「サブスクリプション」などの名称になっている場合があります。画面を開いたら、URL入力欄にリンクを貼り付け、取得または追加ボタンを押します。正常に読み込めれば、設定ファイルとノード一覧が表示されます。

プロファイル画面を開き、サブスクリプション追加欄を選択します。
プロバイダからコピーしたClash用URLを貼り付けます。
取得後に表示されたプロファイルの名前を、用途が分かる名称へ変更します。
内容を確認してから、そのプロファイルを一度有効化します。
プロキシ画面でノードとプロキシグループが作成されているか確認します。

名前には「Provider-A」「Provider-B」のような事業者名だけでなく、「メイン」「予備」「海外作業用」などの役割も加えると便利です。たとえば「Provider-A｜メイン」「Provider-B｜予備」のようにすると、障害発生時にも迷いません。更新日時が画面に表示されるクライアントでは、最後に成功した時刻も確認してください。

注意

サブスクURLを他人に転送しないでください。URLを知っている人は、契約中のノード情報や通信量を利用できる可能性があります。URLが流出した疑いがある場合は、プロバイダの管理画面でトークンを再発行し、古いURLをClashから削除してください。

自動更新を設定する方法

自動更新は、ノードの追加やサーバー変更を手動で確認する手間を減らします。一方で、短すぎる更新間隔はプロバイダのサーバーに負荷をかけ、アクセス制限や一時的な取得失敗につながることがあります。一般的な個人利用では、数時間ごとに更新する必要はなく、12時間から24時間程度を基準に考えるとよいでしょう。

プロファイルの編集画面に「更新間隔」「自動更新」「Update interval」などの項目がある場合は、契約内容と利用頻度に合わせて設定します。毎日使うメインサブスクは24時間、予備サブスクは48時間または手動更新にするなど、役割ごとに分けると無駄な通信を抑えられます。通信量制限のあるサービスでは、更新回数が利用量に影響するかどうかも確認してください。

用途	推奨の更新方法	確認するポイント
毎日使うメイン	12〜24時間ごと	更新後も同じプロキシグループを参照しているか
障害時の予備	24〜48時間ごと	期限切れやノード数の変化がないか
短期契約・検証用	手動更新	不要になったらプロファイルを削除する

自動更新に失敗した場合は、すぐにURLを削除して再登録するのではなく、まずログの内容を確認してください。HTTP 403や429ならアクセス制限、タイムアウトならDNSやネットワーク、TLSエラーなら証明書や時刻設定が関係している可能性があります。ブラウザでURLを開いてファイルが返るかを確認する方法もありますが、ブラウザの履歴やダウンロード履歴にトークン付きURLが残る点には注意が必要です。

ヒント

更新直後に設定を自動で有効化する機能がある場合は、最初からオンにせず、まず取得結果を確認してください。プロバイダ側の一時的なエラーページをYAMLとして保存すると、現在の正常な設定が壊れることがあります。自動更新後も前回の設定へ戻せるよう、動作確認が済むまではバックアップを残しておきましょう。

複数サブスクをプロキシグループで切り替える

複数のプロファイルを登録しただけでは、すぐに便利なフェイルオーバー構成になるわけではありません。多くのClash設定では、現在有効なプロファイル内のプロキシグループだけが利用されます。別サブスクのノードを同じグループにまとめたい場合は、設定ファイルのプロキシ定義やグループ構成を確認し、Mihomo対応のクライアントで上書き設定を使う方法を検討します。

最も扱いやすいのは、メイン出口、予備出口、用途別グループを分ける構成です。メイン出口には普段使うサブスクのノード、予備出口には別サービスのノードを入れます。速度や応答性を自動評価したい場合はurl-test、複数の候補を順番に試したい場合はfallback、自分で選択したい場合はselectを使います。クライアントやコアによって対応状況が異なるため、設定を変更した後は必ず構文チェックを行ってください。

proxy-groups:
  - name: MAIN
    type: select
    proxies:
      - Provider-A
      - Provider-B
      - DIRECT

  - name: AUTO-BACKUP
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - Provider-A
      - Provider-B

上の例は考え方を示すもので、実際のプロキシ名は読み込んだ設定に合わせて変更します。プロバイダによっては「自動選択」「Global」「Proxy」などのグループ名を使います。ルールが参照するグループ名と、設定ファイル側のグループ名が一致しないと、設定は読み込めても通信が意図しない出口へ流れることがあります。

select：利用者が画面上で明示的に出口を選ぶ。動作を把握しやすい。
url-test：候補へ定期的に接続し、応答の速いノードを選ぶ。速度だけで実利用品質を判断しない。
fallback：先頭の候補が失敗したとき、次の候補へ切り替える。障害対策に向いている。
load-balance：複数候補へ分散する。サービス側のセッション管理と相性を確認する。

切替テストとセキュリティ確認

設定が完成したら、通常時だけでなくメインサブスクが使えない状況も想定してテストします。まずメイン出口を選び、ブラウザ、必要な業務アプリ、DNS確認サイトなどを使って接続を確認します。その後、メインノードを手動で停止するか、一時的に予備出口へ切り替え、同じサービスが利用できるか確認します。

Clashのログで、通信が想定したプロキシグループを通っているか確認する。
IPアドレスや地域判定が、選択した出口と一致しているか確認する。
DNSリクエストがOSやブラウザの別経路へ漏れていないか確認する。
メインを戻したとき、ルールやアプリの接続が正常に復帰するか確認する。
更新失敗時に、直前の正常なプロファイルへ戻せるか確認する。

自動切替は便利ですが、常に最速のノードや最も安定したノードを選ぶとは限りません。HTTPの疎通確認が成功していても、動画、WebSocket、オンライン会議、ファイル転送などの実際の用途では品質が異なることがあります。自動選択を使う場合でも、重要な作業の前に固定ノードへ切り替えられるようにしておくと安心です。

セキュリティ上の注意

サブスクを複数登録すると、設定ファイルやノード情報の保存先も増えます。設定ファイルをクラウド同期フォルダへ置く場合は共有範囲を確認し、ログにアクセストークンや接続先URLが出力されていないか確認してください。また、出所が不明な設定ファイルをそのまま読み込まず、外部のリモートルールやスクリプトが何を参照しているかを確認することも重要です。

更新や切替がうまくいかないとき

複数サブスク構成で接続できない場合、問題を「サブスク取得」「設定読み込み」「ノード接続」「ルール適用」の四つに分けると原因を見つけやすくなります。取得そのものに失敗しているならURL、DNS、TLS、認証期限を確認します。取得は成功しているのにノードが表示されない場合は、Clashコアがプロトコルに対応しているか、設定の形式が適切かを確認します。

更新ボタンが反応しない：URLの空白、ネットワーク接続、アプリの権限、プロバイダ側の障害を確認する。
更新後にノードが消えた：エラーページや空の設定が保存されていないか、前回のプロファイルへ戻して比較する。
予備へ切り替わらない：グループのプロキシ名、ルールの参照先、fallbackのテストURLを確認する。
一部のアプリだけ使えない：システムプロキシ、TUN、アプリ独自のプロキシ設定、QUICやIPv6の挙動を切り分ける。
切替後も古い地域が表示される：ブラウザキャッシュ、Cookie、DNSキャッシュ、アプリ内セッションを確認する。

設定を大きく書き換える前に、現在動作しているYAMLをコピーして保存してください。変更は一項目ずつ行い、変更後にClashの構文エラー、ログ、実際のWebアクセスを確認します。原因不明のまま複数の設定を同時に変えると、どの変更が改善や悪化を招いたのか分からなくなります。

よくある質問

サブスクはいくつ登録できますか？

技術的には複数登録できますが、数が多いほど設定管理、更新通信、ノード一覧の整理が難しくなります。まずは普段使いのメインと、障害時に使う予備の二つから始め、必要性を確認しながら増やすのがおすすめです。

自動切替と手動切替はどちらがよいですか？

通常のWeb閲覧では自動切替が便利ですが、ログイン状態や地域判定を維持したいサービスでは手動切替の方が安定することがあります。重要な作業では固定ノードを使い、障害時だけ予備へ切り替える運用が安全です。

自動更新に失敗したら再登録すべきですか？

すぐに再登録する必要はありません。まずURLの有効期限、プロバイダの障害、HTTPステータス、TLSエラー、ネットワーク経路を確認してください。再登録する場合も、正常な旧プロファイルを削除せず、取得結果を確認してから整理します。

複数のサブスクを使うと安全性は下がりますか？

登録数そのものより、提供元、設定ファイル、トークンの管理が重要です。信頼できるサービスだけを使い、URLを公開せず、不要なリモートルールやスクリプトを確認し、Clashクライアントとコアを最新の安定版へ更新してください。

複数契約の管理を他のプロキシアプリで行う場合、サービスごとに設定形式や更新方法が異なり、障害時の切替を手作業で繰り返さなければならないことがあります。ノード名の整理やルールの再登録が必要になり、複数端末で同じ構成を維持しにくい点も負担になります。

Clashなら、サブスクリプションをプロファイルとして分け、更新間隔を個別に調整し、selectやfallbackなどのプロキシグループで出口を整理できます。ログで通信経路を確認しながら手動切替と自動切替を使い分けられるため、メイン回線と予備回線を一つの画面で管理したい人に適しています。複数サブスクを安全かつ見通しよく運用したい方は、Clashを無料でダウンロードして試してみてください。

Clashで複数契約を管理する方法｜自動更新と切替設定