Clash サブスク形式の違い:YAML 設定・Base64 リンクと相互変換方法

サブスク形式が複数存在する理由

Clash が当初対応していたのは 1 種類のみでした。ノード情報(proxies)、ポリシーグループ(proxy-groups)、振り分けルール(rules)を丸ごと含む完全な YAML 設定ファイルです。このファイルはノード一覧であると同時に動作仕様書でもあり、クライアントはダウンロード後そのまま読み込んで動かせます。

しかしノード提供元は必ずしも完全なルールセットを維持したいわけではありません。多くのサブスク事業者はノード情報のみを配布し、ルール構築はユーザーやクライアント側のプリセットに委ねる傾向があります。そこから生まれたのが、より軽量な 2 つの形式――Base64 エンコードのノードリストと、共通共有リンク集合です。3 つの形式はそれぞれ用途が異なり、絶対的な優劣はありませんが、混同するとフィールド欠落やクライアントが読み取れないといった問題が起きやすくなります。

完全な YAML 設定:フィールド構造と適した用途

YAML 形式のサブスクは、実質そのまま動かせる config.yaml です。mihomo(Clash Meta カーネル)は既存フィールドに多くの新構文を追加していますが、トップレベルの構造はほぼ共通です。

mixed-port: 7890
mode: rule
log-level: info
dns:
  enable: true
  nameserver:
    - 223.5.5.5
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,google.com,自動選択
  - GEOIP,CN,DIRECT
  - MATCH,自動選択

この形式のメリットは「そのまま使える」ことです。ルール・ポリシーグループ・DNS 設定はすべて配信元が管理し、ユーザーは取り込むだけで追加設定が不要です。デメリットも明確で、クライアント側で複数のサブスクを統合したり、既存ルールに独自の振り分けを追加したい場合、単純な結合ではなくフィールド単位のマージが必要になり、扱いがやや面倒になります。

また mihomo カーネルで追加されたフィールド(smart ポリシーグループタイプ、sniffer ドメインスニッフィング設定など)は、無印 Clash カーネルではそのまま無視されるかエラーになるため、YAML サブスクを取り込む前にクライアントがどのカーネルを使っているか確認しておくとよいでしょう。

Base64 ノードリストと共通共有リンクの違い

サブスクリンクの返す内容が読める YAML ではなく、規則性のない長い文字列であれば、Base64 エンコードされたノードリストである可能性が高いです。この形式は 1 行ごとに 1 ノードを表し、フォーマットは通常 プロトコル://エンコードされた接続パラメータ で、よく使われるプロトコル接頭辞には ss://、vmess://、trojan://、ssr:// などがあり、サブスク全体としてこれらの行をまとめてさらに Base64 エンコードします。

ss://[email protected]:443#hk-01
vmess://eyJ2IjoiMiIsInBzIjoic2ctMDIi...
trojan://[email protected]:443?sni=example.net#sg-02

この形式は「ノードが何であるか」しか記述せず、振り分けルールやポリシーグループの情報は含まれません。クライアントのサブスク解析部が各行をノードオブジェクトに復元し、クライアントローカルまたはサブスク変換サービスが提供するルールテンプレートを適用します。メリットは汎用性の高さで、プロキシプロトコルに対応するクライアントであれば(Clash に限らず)ほぼすべて解析できます。デメリットは変換ツールがないと機能しないことです。この種のリンクを自動変換に対応していない Clash クライアントにそのまま貼り付けても、Clash 自体は YAML しか認識しないため、ほとんど何も読み込まれません。

いわゆる「共通共有リンク集合」とは、実は上記の Base64 ノードリストの別名にすぎず、機場(海外プロキシ)サービス事業者の「サブスクリンク」ページによく見られ、純粋な YAML サブスクと URL レベルでは区別がつかないことが多く、内容を確認するしかありません。

クライアント移行時:相互変換の方法とツール選び

クライアントやデバイスを切り替える際、最も多い要望は Base64 ノードリストを完全な YAML 設定に変換すること、あるいは逆に YAML 内のノード情報を抽出して他のソフトで使うことです。よくある方法は 3 つあります。

1. クライアント側の自動変換:多くの Clash クライアント(mihomo カーネル対応版を含む)は、サブスク追加時に Base64 ノードリストを自動識別し、内部で YAML 構造に変換してデフォルトのルールテンプレートを適用します。ユーザーが手動で処理する必要がなく、最も手軽な方法です。
2. サブスク変換サービス:元のサブスクリンクとルールテンプレートを一緒に変換サービスへ送信し、サーバー側でノード取得・ルール適用・完全な YAML の組み立てを行い、新しいサブスクアドレスを返してもらいます。カスタムポリシーグループが必要な場合や、複数のサブスクソースを統合したい場合に適しています。
3. ローカルスクリプトによる変換:ノード数が少なく、ルールを完全に自分で管理したいユーザーは、Base64 の内容を手動でデコードし、復元したノードパラメータを 1 つずつ YAML の proxies フィールドに入力し、ルールとポリシーグループも自分で作成する方法もあります。最も手間がかかりますが、いかなる第三者サービスにも依存しません。

どの方法を選ぶかは、サブスクの提供元が安定しているか、ルールを頻繁に調整する必要があるかによります。一時的にクライアントを切り替えてテストするだけなら、クライアント側の自動識別を優先しましょう。長期的にクライアント間で共通利用できるサブスクを維持したいなら、サブスク変換サービスの方が手間が省けます。

変換時によくあるフィールド欠落と回避方法

形式の相互変換で最も問題が起きやすいのは、ノード自体が接続できないことよりも、「一見どうでもよさそうな」フィールドが変換ツールに黒黒無視されてしまうことです。以下のようなフィールドは特に相互変換で消えやすいので注意しましょう。

• TLS 関連パラメータ:skip-cert-verify、sni、alpn など。簡易版の変換ツールの一部はこれらのフィールドをデフォルトで解析しないため、元は正常だったノードが変換後にハンドシェイクに失敗することがあります。
• トランスポート層の拡張設定:VMess/Trojan ノードによく付随する ws-opts、grpc-opts などのトランスポート設定は、変換ツールが最も基本的なプロトコルテンプレートのみで解析する場合、この部分がまるごと無視されます。
• ポリシーグループの参照関係:元のサブスクのルールが特定のカスタムポリシーグループ名を参照していた場合、変換後にノード名やグループ名が変わると、ルールが対応するグループにマッチせず、すべてデフォルトポリシーに落ちてしまいます。
• DNS・TUN 関連設定:純粋なノードリスト自体にはこれらのフィールドが含まれないため、変換サービスが補完する際は独自のデフォルトテンプレートを使うことになり、ユーザーが元々使っていた DNS ポリシーと一致しない場合があります。変換後に手動で確認が必要です。

また、サブスク変換サービスごとにプロトコルへの対応度が異なり、特に新しめのプロトコルや難読化パラメータは要注意です。変換後に生成された YAML ファイルを開いて、ノード数が合っているかだけでなく、いくつかのノードのフィールドが完全かどうかも抜き取り確認することをお勧めします。

3 つの形式の比較まとめ

総じて言えば、サブスクの内容がどの種類に該当するかを見極め、それに合った取り込み・変換方法を選べば、「サブスク取り込み後にノードが表示されない」「ルールが効かない」といった問題の多くは事前に回避できます。形式の相互変換は難解なものではなく、要はフィールドが完全に保持されているかを確認することが核心です。