Clashのサブスクリプション形式解説:YAML・Base64・汎用形式の相互変換とは

サブスクリプションリンクの正体とは

サブスクリプションリンクとは、クライアントが定期的にリクエストするHTTP(S)アドレスであり、実際の設定データはサーバー側が返す内容そのものです。事業者やパネルによって返される内容の形式はさまざまで、代表的なものはClash専用のYAML構造、Base64エンコードでまとめられた汎用ノードリスト、一部クライアント独自のJSONやプレーンテキスト形式の3種類です。クライアントはサブスクリプションを取得した後、まず返された内容の種類を判定し、それぞれの解析規則に従ってノード情報や振り分けルールをローカル設定に書き込みます。この判定・解析の段階で失敗すると、「インポートはできたのに使えない」という状態になりがちです。

形式の判定はリンクの拡張子だけでは行えません。多くのサブスクリプションアドレスには .yaml のような目印が付いていないため、実際に判定材料となるのはレスポンスヘッダーの Content-Type とレスポンス本文の実際の内容です。クライアントの解析処理は通常、まずYAMLとして解析を試み、失敗した場合にBase64デコードを試みます。両方とも一致しなければ形式エラーとして扱われます。同じサブスクリプションでもクライアントによって挙動が異なるのは、解析の優先順位や対応範囲がクライアントごとに違うためです。

YAML形式:Clashネイティブの設定構造

ClashおよびClash Meta(mihomoコア)がネイティブに認識する設定はYAMLテキストで、トップレベルには通常 proxies(ノードリスト)、proxy-groups(ポリシーグループ)、rules(振り分けルール)などのフィールドが含まれます。この形式の利点は情報が完結していて可読性が高いことで、ポリシーグループのグループ分けロジックやルールのマッチング順序がテキスト上にそのまま反映されるため、上級者は設定ファイルを直接開いて部分的に編集できます。

proxies:
  - name: "hk-01"
    type: ss
    server: example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: "自動選択"
    type: url-test
    proxies: ["hk-01"]
    url: "http://www.gstatic.com/generate_204"
    interval: 300

rules:
  - DOMAIN-SUFFIX,github.com,自動選択
  - MATCH,DIRECT

注意すべき点として、YAMLはインデントとコロン後の空白に非常に敏感で、手動編集の際に空白が1つ多かったりコロンが1つ抜けているだけでも設定全体の解析に失敗します。サブスクリプション提供元がYAML直リンクを提供している場合、通常はユーザーが手を加える必要はなく、クライアントが全体を取得してローカル設定に上書き・統合します。手動でノードを追加したりルールを組み立てたりする場合にのみ、構文の細部に注意が必要です。

Base64と汎用サブスクリプション形式の互換ロジック

Base64形式が広く使われるようになったのは、初期のクライアントやオンライン共有のシーンに対応するためです。サーバー側は各ノード情報を プロトコル://パラメータ という形式のリンク(ss://、vmess://、trojan:// などで始まる)にまとめ、それらのリンクを1行ずつ並べたうえで全体をBase64エンコードし、改行のない1つの文字列として出力します。クライアントは取得後まずBase64デコードを行い、1行1ノードのテキストに復元してから各行のプロトコル種別とパラメータを解析し、最終的に内部で使えるノードリストを生成します。

この形式の利点は互換性の高さです。ほぼすべての主要クライアント(Clash系に限らず)がこのエンコード規則を認識できるため、同じサブスクリプションを複数のソフトに読み込ませることができ、パネル側が複数のクライアントに同時対応する場面に向いています。一方で限界も明確です。Base64の汎用形式にはポリシーグループや振り分けルールといった構造化情報が含まれないため、クライアントはノードを取得した後、自前のデフォルトのグループ分けロジックで処理するしかなく、ルールの細かさはYAMLネイティブのサブスクリプションに比べて劣ります。一部のクライアントでは汎用形式をインポートすると、ルール集合はローカルに事前登録された静的テンプレートのままで、サブスクリプションの更新はノードの入れ替えのみで振り分けロジックは変わりません。

形式変換が必要になる場面

ほとんどの場合、ユーザーが手動で変換する必要はなく、サブスクリプションリンクをクライアントのサブスクリプション管理画面に貼り付けるだけで、クライアントが自動的に形式を判定して解析を完了します。実際に変換が必要になるのは、主に次のようなケースです。

• パネルが提供するのはBase64の汎用サブスクリプションのみだが、Clashでカスタムの振り分けルールや多層のポリシーグループを使いたい場合。この場合、ノード情報をYAML構造に変換し、rules フィールドを追加する必要があります。
• 手元にすでにバラバラのプロトコルリンク(ss://、vmess:// など)がある場合、クライアントが認識できる1本のサブスクリプションアドレスにまとめることで、一括管理や自動更新が可能になります。
• 他のクライアントからClash系クライアントに移行する場合、元のサブスクリプションが独自形式であれば、これまでのグループ分けの習慣を保つためにYAMLへの変換が必要です。

変換の基本原理はさほど複雑ではありません。まず元のサブスクリプションを解析し、構造化されたノードパラメータ(サーバーアドレス、ポート、暗号化方式、パスワードや鍵など)を復元し、それを目的の形式の構文に合わせて再構築します。YAML形式を目的とする場合はさらにポリシーグループとルールを生成する必要がありますが、この部分は通常、変換スクリプトが事前定義済みのテンプレートに従って埋め込むものであり、元のサブスクリプションから「抽出」しているわけではありません。汎用形式自体にこれらの情報が含まれていないためです。

変換サービスを自前で構築する際の注意点

スキルと必要性のあるユーザーは、オープンソースのサブスクリプション変換サービスを自分で構築し、Base64の汎用サブスクリプションをカスタムルール付きのYAML設定に変換して、新しいサブスクリプションリンクをクライアントに提供することもできます。変換サービスを自前で構築する際に留意すべき点がいくつかあります。

1. ルールテンプレートは必要に応じて保守する。変換サービスが生成するポリシーグループや振り分けルールはローカルのテンプレートファイルに基づいています。テンプレートが古くなると、新しく追加されたドメイン分類がヒットしなくなるため、定期的な更新・保守が必要です。
2. 変換処理へのアクセス権限を管理する。変換サービスは通常、元のサブスクリプション内容を経由するため、公開アクセス可能なアドレスに設置する場合はアクセスキーを設定するか、アクセス元を制限し、サブスクリプション情報が無関係な第三者に取得されないようにすることをおすすめします。
3. 出力するサブスクリプションの更新頻度を元のサブスクリプションに合わせる。変換サービスは一般に受動的なトリガーまたは定期取得で元のサブスクリプションを取得し、新しいリンクを生成します。定期実行の間隔を長く設定しすぎると、クライアントが取得するノード情報がパネル側の実際の変化より遅れてしまいます。
4. プロトコルフィールドの解析を網羅的に行う。Shadowsocks、VMess、Trojan、Hysteriaなどプロトコルごとにパラメータ構造の差が大きいため、変換スクリプトが一般的なフィールドしかカバーしていないと、プラグインパラメータや特殊なトランスポート層設定を持つノードで解析エラーが起きやすくなります。

一般のユーザーであれば、クライアント自体がすでにサブスクリプション形式を正常に認識できている場合、追加で変換工程を導入する必要はありません。変換はどちらかというとパネル運営者や特定のルール要件を持つ上級ユーザーが使う手段であり、日常的な利用ではまずクライアントとサブスクリプション形式がそもそも互換性を持っているかを確認し、それから変換の必要性を検討するのがよいでしょう。