サブスクリプション(Subscription)は、Clash を使ううえで最も一般的で手間の少ない方法です。ほとんどの人はノードを1件ずつ手入力せず、プロバイダーから受け取ったサブスクリプション URL をクライアントにインポートし、あとは自動処理に任せます。本記事では、サブスクリプションの仕組みからインポート手順、自動更新の設定、よくある問題の切り分けまで、一度に整理します。
サブスクリプション URL とは?
サブスクリプション URL は本質的に URL です。クライアントがアクセスすると、ノードを一括取得でき、場合によってはルールやポリシーグループも含まれます。通常、ノードプロバイダーが提供するか、自前構築後に管理パネルで生成されます。形式は次のようなものです:
https://example.com/subscribe?token=あなた専用の認証情報
ここで繰り返し強調しますが、URL 内の token はアカウント認証情報と同等です。取得した人があなたの通信量を使えます。スクリーンショットで公開したり、グループに投稿したり、公共プラットフォームにアップロードしたりしないでください。なお、当サイトは使い方のみを解説し、サブスクリプションやノードは一切提供しません。
手動追加よりサブスクリプションが優れている点
- 手間が少ない:1本の URL で数十のノードを取得。1件ずつ入力不要;
- 自動更新:プロバイダーがサーバーを入れ替えたり新ノードを追加しても、自動同期;
- ミスが少ない:サーバーアドレス、ポート、パスワードを手で写す際の入力ミスを回避。
ステップ1:サブスクリプションをインポート
デスクトップでよく使われる Clash Verge Rev を例にします(他のクライアントも流れはほぼ同じ):
- サブスクリプション URL をコピー;
- クライアントを開き、「サブスクリプション / 設定(Profiles)」ページへ;
- URL を入力欄に貼り付け、「インポート / Import」をクリック;
- ダウンロード完了を待ち、その設定を選択して現在有効な設定にする。
インポート成功後、「プロキシ / ポリシーグループ」ページに、選択可能なノードやポリシーグループが並びます。モバイル(ClashMeta for Android など)もほぼ同じです。設定ページで「+」を押し、「URL からインポート」を選んで URL を貼り付けます。
ステップ2:自動更新を有効にする
ノードは変動するため、手動更新は面倒です。自動更新の有効化を強くおすすめします:
- その設定の項目で「更新間隔 / Update Interval」を探す;
24時間は汎用的で安定した値です;- 必要に応じて「更新」ボタンでいつでも手動同期も可能です。
更新はノードなどの内容を置き換えるだけで、すでに選んだ現在のノード設定には影響しません。安心して有効にできます。
応用:ローカル設定ファイルのインポート
既存の config.yaml を受け取った場合も、直接インポートできます。proxy-providers でサブスクリプションを「ノードプロバイダー」として取り込み、「サブスクリプションノード」と「カスタムルール」を分離管理することもできます:
mixed-port: 7890 mode: rule proxy-providers: my-sub: type: http url: "https://example.com/subscribe?token=xxx" interval: 86400 # 自動更新間隔(秒) path: ./providers/my-sub.yaml
ここで interval: 86400 は24時間(86400秒)ごとに自動更新することを意味します。カスタム設定を長期保守したい上級者向けの方法です。
更新に失敗したら?
サブスクリプション更新の失敗は、初心者が最もよく遭遇する問題の一つです。原因はだいたい次のいずれかです:
- URL 自体が開けない:まずブラウザでサブスクリプション URL に直接アクセスし、内容が返るか確認。文字化けやテキストの羅列は正常。404 やタイムアウトなら URL に問題;
- 先にプロキシが必要:サブスクリプション URL 自体が国外にある場合、先にプロキシに接続してから更新する、という順序です;
- 認証情報の期限切れやリセット:プロバイダーに問い合わせ、サブスクリプションの期限、通信量の残量、token のリセット有無を確認;
- ローカル時刻のずれ:システム時刻の大きなずれは接続異常の原因になり得ます。時刻を確認・校正してください。
複数サブスクリプションの管理
複数のサブスクリプションを持っている人も多いでしょう。「1設定 = 1サブスクリプション」で管理するのが最も明快です。クライアントの設定リストに複数の Profile を残し、必要なものに切り替え、互いに干渉させません。異なるソースのサブスクリプションを1つの設定に無理に詰め込むのは非推奨です。1本に問題が出たときの切り分けが非常に困難になり、ノード名の重複やルールの競合も起きやすくなります。
複数サブスクリプションのノードをまとめて使いたい場合は、前述の proxy-providers 方式がおすすめです。各サブスクリプションを独立した「ノードプロバイダー」として取り込み、ポリシーグループで統合管理します。すべてのノードを集中制御でき、あるサブスクリプションが失効したときもどれが原因かすぐ特定でき、保守がすっきりします。
サブスクリプションを安全に使うためのヒント
- 公共ネットワークや他人のデバイスにサブスクリプション URL を長期保存しない;
- 通信量使用量を定期的に確認。異常な急増は認証情報漏洩のサインであることが多い;
- URL 漏洩が疑われる場合、プロバイダーの管理画面ですぐにサブスクリプション URL をリセット;
- インポート前に URL の出所を確認し、出所不明の「無料サブスクリプション」は極力避ける。
まとめ
サブスクリプションをインポート → 自動更新を有効化 → ノードを選んで利用、の3ステップで Clash を動かせます。サブスクリプションは「ノード保守」の面倒を自動化し、あなたは利用に集中できます。設定ファイルの各セクションの意味をさらに理解したい場合は、ドキュメント · 設定ファイルの構造 を読み進めてください。ルールの書き方については、本ブログのルール振り分け詳解もご覧ください。
最後にもう一点:サブスクリプションはノードを「取得し自動維持する」だけで、ノードの速度や安定性そのものは変えません。インポート後の体験が悪い場合、問題は多くの場合ノードや回線側にあり、サブスクリプション手順自体ではありません。インポート・更新・切り分けの一連の流れに慣れれば、プロバイダーやクライアントを変えても、裏側の考え方は同じなので、どんどん早くセットアップできるようになります。