サブスクリプション管理は「リンクを貼る」作業では終わらない

多くのユーザーにとって Clash への入り口は、プロバイダーから渡されたサブスクリプション URLをクライアントに貼り付けることです。しかし実運用では、ノードの入れ替え、計測 URL の変更、プロトコル追加、一時的な配信障害などが日常的に起きます。つまりサブスクは生きたデータソースであり、取得の仕方と更新の頻度、失敗時の挙動まで含めて設計しておくと、突然「すべてタイムアウト」になったときに復旧が早くなります。

本記事では、Mihomo（旧 Clash.Meta）系コアで一般的な proxy-providers を軸に、自動更新・形式変換・マルチノードの切り替えの三つをつなげて説明します。GUI クライアントは内部で同じ概念をラップしていることが多いので、YAML の構造が分かるとトラブル時のログ読みにも直結します。

proxy-providers の基本：URL・保存先・更新間隔をセットで決める

proxy-providers は、リモートまたはローカルのプロキシ一覧を定期的に取り込み、proxies セクションに相当するノード集合を動的に供給します。最低限そろえたい要素は次のとおりです。

  • type：http で配布 URL を取るのが一般的。オフライン検証なら file も有効です。
  • url：プロバイダーが発行したサブスクリプションの実体。トークン付き URL は他人と共有しない前提で保管してください。
  • path：取得結果をキャッシュするローカルパス。再取得に失敗したときの「最後の成功版」として効きます。
  • interval：秒単位の更新間隔。短すぎると配信元と自分の回線の双方に負荷が出ます。

設定イメージ（値は例示）です。

proxy-providers:
  my-nodes:
    type: http
    url: "https://example.com/subscribe?token=YOUR_TOKEN"
    path: ./providers/my-nodes.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - my-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300

proxies: []

health-check を有効にすると、一覧上の遅延や死活が可視化されやすくなります。計測先 URL は、利用中のノードから到達できる軽量なエンドポイントを選ぶのがコツです。ブロックされる URL だと全ノードが誤って「遅い」と判定されることがあります。

自動更新を調整する：間隔・手動更新・失敗時の見え方

更新間隔は「常に最新が正義」ではありません。プロバイダー側の推奨値（あれば）を尊重し、なければ半日〜一日（43200〜86400 秒）程度から始め、遅延や取得失敗が気になるときだけ短くするのが無難です。短い間隔にしすぎると、一時的な DNS 不調や CDN の揺らぎのたびにプロファイル全体の再パースが走り、GUI ではチラつきや再接続が増えたように感じられることがあります。

GUI では「プロファイル更新」「サブスク更新」ボタンがこれに相当します。コア側がキャッシュを持っているため、手動更新で直近の成功状態に戻せることも多いです。更新ログに HTTP ステータスや TLS エラーが出ていないかを一度確認すると、次に同じ症状が出たときの切り分けが速くなります。

ⓘ 運用のコツ
サブスクリプション URL はクエリに認証トークンが載ることが多く、スクリーンショットや共有メモにそのまま写すと漏洩リスクが高いです。チーム運用なら、URL 本体は秘密管理し、設定リポジトリには file プロバイダやローカル生成に寄せると安全です。

サブスクリプション変換：なぜ必要になり、何に注意すべきか

プロバイダーが配るのが SS のみリスト、Surge 形式、あるいは古いカスタム形式で、Mihomo がそのままでは読めないケースがあります。そのときに使われるのが「サブスクコンバータ」です。ここで押さえたいのは技術的な互換性とセキュリティの両方です。

  • 互換性：変換後の YAML が、利用中のコアバージョンでサポートされるプロトコル・オプションかを確認します。名前だけ Clash でも、実体は別フォーク向け拡張だけ、ということは珍しくありません。
  • セキュリティ：Web 上の変換サービスに生のサブスク URL やトークン付きリンクを貼ると、第三者にノード情報が渡るリスクがあります。可能ならローカル CLI や自ホスト、信頼できるオープンソースツールを選び、ブラウザ経由の匿名サービスは最終手段として割り切るのがよいです。
  • メンテナンス：変換は一度きりではなく、プロバイダーがフィールドを変えたタイミングで壊れます。長期運用なら、最終的にプロバイダーのネイティブ Clash 形式へ寄せるか、変換パイプラインを自分で再現できるようにしておくと安心です。

変換後にノード名が衝突したり、同じ実サーバーに別名で重複登録されたりすると、url-test の結果がブレます。名前の正規化や重複排除は、サブスク品質の一部だと考えてよいです。

マルチノードの切り替え：select・url-test・fallback の役割分担

ノードが数十〜数百あるとき、「毎回手で選ぶ」だけでは運用が破綻しがちです。現場で使いやすい組み合わせは次のようなイメージです。

  • select：用途別の「入口」を人間が決めるとき。例：動画用・仕事用・ゲーム用の三枚看板を用意し、内部で別の url-test グループを指す。
  • url-test：レイテンシ勝ち。ブラウジングのデフォルト出口や、自動で速いノードに寄せたいとき。計測 URL と interval は環境に合わせて調整。
  • fallback：可用性優先。上位が死んだら順に試す。常に一つは生きている出口を作りたいときに有効です。

ルール側で DOMAIN-SUFFIX や RULE-SET からこれらのグループ名を参照する方法は、ルール分流の実践記事で述べたポリシー設計と直結します。サブスクが増えても、ルールが指す先は常に「意味のあるポリシー名」に固定し、実ノードの増減はプロバイダー側に閉じ込めるとメンテナンスが楽です。

複数サブスクリプションを併用するときの落とし穴

安価なバックアップ用サブスクや、用途限定の小規模リストを併用するとき、単純に二つの proxy-providers を同じ url-test に突っ込むと、ノード数が膨らみすぎて計測コストだけが増えることがあります。おすすめは、プロバイダー単位で中間グループを挟むことです。例：「A 社プールの最速」「B 社プールの最速」をそれぞれ url-test で作り、上位の select で用途別に選ぶ。こうすると、片方のプロバイダーが全滅しても影響範囲が説明しやすくなります。

また、同じ表示名のノードが複数プロバイダーから流れ込むと、ログ上の識別が難しくなります。可能ならプロバイダー側の改名機能や、ローカルでのプレフィックス付与（上級者向け）を検討してください。

更新や切替がおかしいときのチェックリスト

  • 取得エラー：URL の失効、トークン再発行、プロバイダー側メンテ。ブラウザで開けるか、別回線で試せるか。
  • パースエラー：変換ミス・文字コード・混入した HTML エラーページ。キャッシュ path の中身をテキストエディタで確認。
  • 遅延だけ異常：health-check / url-test の計測 URL がブロックされていないか。IPv6 経路が別ルートに逃げていないか。
  • ルールと矛盾：意図したポリシーに流れているか。MATCH や広すぎる DOMAIN ルールに飲まれていないか。

DNS や TUN と組み合わせたときの挙動は、設定ドキュメントの DNS・モード説明とあわせて読むと、サブスクは正常でも接続だけ失敗するケースを切り分けやすくなります。

まとめ：サブスクは「入力」ではなく「データパイプライン」として扱う

サブスクリプション管理の要点は、単に URL を貼ることではなく、取得・検証・障害時のフォールバック・ルール側との接続までを一つの流れとして設計することです。更新間隔と health-check を適切に置き、変換はセキュリティと再現性を優先し、ノード選択は select と url-test の階層で人間の判断コストを下げる。この三つがそろうと、ノード数が増えても設定は「読める地図」のまま保てます。

GUI クライアントではこれらが画面操作に置き換わりますが、背後の考え方は同じです。ビルド済みパッケージを使う場合も、プロファイルのバックアップとログの見方が身についていると復旧が早くなります。総合的に見て、ルールの柔らかさとサブスク運用の組み合わせのわかりやすさは、Clash 系ツールの強みのひとつだと言えます。

クライアントの入手とインストールは、配布と更新履歴が整理されたページから行うのが確実です。→ Clash クライアントを無料ダウンロードし、サブスクリプション運用を始める