サブスクリプション「変換」とは何か

いわゆる「空港」やプロバイダから渡されるのは、多くの場合 購読 URL（サブスクリプションリンク）です。これをそのまま Clash 系クライアントに取り込むと、コアが定期取得して proxies 一覧を更新します。一方で、リンク先が 単一フォーマット（例：元が Shadowsocks 中心、別ツール向けの一覧など）だったり、利用したいクライアントが Clash Meta（mihomo） 前提の拡張記法を使いたかったりすると、途中で 変換サービスやローカル変換を挟む選択肢が出てきます。

変換とは、ざっくり言えば「購読ボディを、あなたのコアが解釈しやすい YAML／プロキシ定義に整える工程」です。公開されているオンライン変換は手軽ですが、リンクに認証トークンが含まれる場合は第三者サーバに渡すリスクを理解したうえで使い分けるのが前提です。可能なら GUI クライアントの「サブスク URL をそのまま保存」か、自前ホストの変換ツール、あるいは proxy-providers だけで完結する構成を優先すると安全側に寄せやすいです。

変換やプロバイダ設定が必要になる典型理由

まずよくあるのが形式の不一致です。購読先が返すのが Universal な一覧でも、クライアント側の取り込み実装やコアのバージョンによっては一部プロトコルが読めないことがあります。次に、一覧に広告用・テスト用のノードが混ざっていて、手元のルール設計と相性が悪いケースです。こうしたとき、変換側のテンプレートやフィルタで「使う名前のパターンだけ残す」「特定地域だけ残す」といった前処理が有効になります。

また、mihomo では proxy-providers とルールセットを組み合わせて構成をモジュール化しやすいです。購読そのものはプロバイダに任せ、自分の rules と proxy-groups だけを Git 管理する、という運用では「変換」というよりプロバイダの更新間隔・パス・ヘッダの設計が主戦場になります。YAML の基礎は別稿の YAML 解説も参照してください。

購読 URL をクライアントに登録するときの実務ポイントを整理します。まず URL はそのまま漏らさないことが重要です。リンクにはユーザー識別子やトークンが含まれることが多く、これが第三者に渡るとアカウントの乗っ取りに直結します。掲示板やチャットに貼る・スクリーンショットに写す、は避けてください。

取り込み後は更新間隔に注意します。proxy-providers では interval でポーリング周期を決められます。短すぎると空港側や CDN のレート制限に触れやすく、長すぎるとノード増減に追従が遅れます。最初はクライアント既定や数時間おき程度から始め、遅延や取得失敗が出たらログで原因を見ます。機内モードや企業ネットでは HTTPS 取得が失敗することもあるため、失敗時のリトライやオフライン時の挙動も頭に置いておくと安心です。

ヒント

同じ購読を複数端末で使う場合、端末ごとに別 URL を発行できるサービスなら端末別 URLに分けると、どこで漏れたか追跡しやすくなります。また取得は常に HTTPS に限定し、中間者改ざんのリスクを下げます。

ノード選別のベストプラクティス：filter・除外・並び

一覧に数十～数百ノードあると、select グループのプルダウンが実用に耐えません。ここで効くのが proxy-providers の filter です。正規表現で名前にマッチするものだけを残せます。例えば地域タグが名前に含まれる購読なら、利用したいリージョンのパターンだけを残し、それ以外を捨てるイメージです。逆に「除外したい接頭辞だけ弾く」場合は、クライアント機能やテンプレートによっては exclude-filter 相当の表現が使えることもあります（実装はコアと GUI のバージョンに依存します）。

名前の付け方がバラバラな購読では、一度取り込んでから手元でリネーム規則を揃えるより、まず filter で粗く削り、残った集合に対して url-test や fallback を当てる方が運用が楽です。url-test は計測 URL（多くは軽量な 204 応答）に対する遅延で勝者を選びます。interval と tolerance を調整し、頻繁な切り替えでストリームが途切れないようバランスを取ります。

# Conceptual example — adjust keys to your core / GUI version
proxy-providers:
  airport:
    type: http
    url: "https://example.com/subscription-token"
    interval: 3600
    path: ./providers/airport.yaml
    health-check:
      enable: true
      interval: 600
      url: http://www.gstatic.com/generate_204

proxy-groups:
  - name: AUTO
    type: url-test
    use:
      - airport
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

実際のキー名は mihomo / クライアントのバージョンで差があるため、手元のドキュメントに合わせてください。重要なのは「購読本体」と「選別・健康チェック」を分けて考えることです。

ルールとグループ設計：選んだノードを無駄にしない

ノードを絞ったあとも、ルール側で別のプロキシグループに流すと意味が半減します。rules の並びは上から評価されるので、国内ドメインや LAN を先に DIRECT へ、残りを MATCH で自動選択グループへ、といった骨格を先に固定します。動画・ゲーム・仕事用でグループを分けたい場合は、select を複数用意し、それぞれに同じ proxy-providers を参照させて filter だけ変える、という切り口もあります。

サブスク更新直後にだけ遅い・切れる場合は、一覧の並び替えやサーバ側メンテが原因のことが多いです。変換サービスを挟みすぎて遅延が増えている場合は、中継を減らすか、自前変換に切り替えて比較するとよいでしょう。

セキュリティとプライバシー：共有リンクをどう扱うか

変換サービスを使う場合、購読 URL がそのサービスのログに残る可能性があります。ポリシーと信頼性を確認できない場合は、ローカル完結や公式クライアントのネイティブ取り込みを検討してください。また、不明なスクリプトで購読を「クリーニング」するツールは、悪意ある挿入のリスクもあるため、出所の明確なものだけを使うのが安全です。

オープンソースの Clash コミュニティはドキュメントや Issue が豊富ですが、インストール済みクライアントの入手は一貫して当サイトのダウンロードページを主な入口にすると、配布物の追跡がしやすくなります。ソースコードの参照や議論は GitHub でも可能ですが、パッケージの取得経路は分けて考えると混乱が減ります。

よくあるつまずき

  • 取り込みは成功するがノードがゼロ：filter が厳しすぎないか、購読が空や期限切れでないかを確認します。
  • 遅延だけ極端に悪い：計測 URL への経路問題のほか、url-test の interval が短すぎてサーバに負荷をかけていないかも見ます。
  • 名前はあるが接続できない：ローカル時刻のずれ、DNS、ファイアウォール、TUN とプロキシの二重適用など、ルール以前の層を疑います。

詳細な切り分けはログレベルを一時的に上げ、どのプロキシに落ちているかを追うのが早道です。

まとめ

サブスクリプション変換は「見た目のフォーマット合わせ」だけでなく、運用に耐えるノード集合をどう作るかが本質です。空港リンクの取り込みでは更新間隔と URL の取り扱い、選別では proxy-providers の filter と url-test のパラメータ、ルールでは優先順位とグループ設計がセットになります。これらを一度通しで決めると、サブスク更新のたびに手作業でノードをいじる時間を大きく減らせます。

他のトピックはブログ一覧から辿れます。クライアントを入れ替えたり複数端末で揃えたりする場合も、まずはダウンロードページで OS に合ったパッケージを選ぶと手順が単純になり、設定の検証に集中できます。→ 無料で Clash をダウンロードし、サブスク運用を整える