Clashのサブスク形式まとめ:YAML・Base64とサブスク変換の正しい使い方

サブスクリンクとは何か

サブスクリンクとは、クライアントが定期的に取得するHTTP/HTTPSアドレスのことで、リクエストの返り値には複数のノード情報が含まれ、場合によっては振り分けルールも一緒に返されます。クライアントはこの内容を受け取ると、決められた形式に従ってノードリストを解析し、ローカル設定として書き込み、プロキシエンジンに渡します。サブスクを理解するうえで大事なのは、内容を2つの層に分けて考えることです。一つは「ノードをどう記述するか」、もう一つは「設定ファイル全体をどう構成するか」。前者は1本のリンクの書き方を決め、後者はサブスクファイル全体の構造を決めます。トラブル対処の際にリンク自体だけを見て、クライアントが実際にどの構造を期待しているかを見落とすケースが非常に多く、これが形式関連の障害でもっとも多い誤解です。

Clash系クライアント(Mihomoコア系のフォークを含む)がそのまま読み込めるのは構造化されたYAML設定ですが、運営元(いわゆる「機場」)や自前でサーバーを立てた人が最初に発行するのは汎用的なノード共有リンクであることが多く、両者を接続するには一段の変換が必要です。この変換の品質が、サブスクの更新のスムーズさ、ルールの完全性、ノードの網羅性を直接左右します。

主要3形式の違い

Clash YAMLネイティブ設定

これはClashクライアントが直接理解できる形式で、完全なファイルには通常proxies(ノードリスト)、proxy-groups(ポリシーグループ)、rules(振り分けルール)、さらに任意項目としてdnsやtunなどが含まれます。各ノードは辞書形式で記述され、フィールド名は固定です。例えば:

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

YAMLはインデントに非常に敏感で、スペース1つのズレだけで設定全体の解析が失敗します。クライアントは「設定が無効」とだけ表示し、どの行が原因かまでは示さないことが多く、これがサブスク変換工程でもっともミスが起きやすい部分の一つです。

汎用Base64ノードリンク

これは運営元が広く使う共有形式で、よく見る形はss://、vmess://、trojan://で始まる1行のテキストです。プロトコル名の後ろにBase64エンコードされたパラメータが続き、デコードするとサーバーアドレス、ポート、暗号化方式などのフィールドが確認できます。サブスクリンクが返す内容は、こうしたテキストを1行ずつ並べてまとめ、さらに全体をもう一度Base64エンコードしたものであることが多く、クライアントや変換ツールはまず外側のデコードを行い、その後1行ずつノードリンクを解析します。この形式の利点はクライアント間の互換性が高く、主要なツールならほぼすべて対応していることですが、欠点はポリシーグループやルール情報を含まず、ノード自体しか記述できないことです。

クライアント独自形式

一部のクライアントはYAMLをベースに独自フィールドを拡張しており、例えばグループの表示スタイル、アイコンのURL、特定のDNSの書き方などがあります。これらの拡張フィールドはClashネイティブコアにとっては無害な余剰情報ですが、Aクライアントが出力した設定をそのままBクライアントに渡すと、Bクライアントが未知のフィールドを認識できずエラーになったり、単に無視されて機能が欠落したりすることがあります。これが「同じサブスクなのにクライアントを変えたら不具合が出る」原因の一つです。

ヒント

あるサブスクリンクがどちらの形式を返しているかを判定する方法は簡単です。ブラウザで直接リンクを開いてみて、規則性のない長い文字列で明確なproxies:の記述が見当たらなければBase64、開いた瞬間に構造化されたインデント付きテキストが見えればYAMLです。

サブスク変換サービスの仕組み

サブスク変換サービスは本質的に形式の翻訳レイヤーです。まず元のサブスクアドレスにリクエストを送り、Base64などの形式のノードリストを取得し、1件ずつサーバー、ポート、プロトコル、暗号化パラメータなどをデコードします。その後、対象クライアントが読み込めるテンプレートに従ってYAML設定を再構築し、あらかじめ用意したルールセットに従ってproxy-groupsやrulesを注入することもできます。この流れは「元データの取得」「ノードフィールドの解析」「テンプレートに沿った再生成」という3ステップにまとめられます。

変換サービスを使う場合、実際にクライアントへ入力するサブスクアドレスは運営元が発行した元のリンクではなく、変換サービスが生成した新しいアドレスです。形式としては「変換サービスのドメイン+パラメータ(元のサブスクアドレス、変換先の形式、ルールテンプレートを含む)」といった形になります。クライアントがサブスクを更新するたびにこの変換アドレスにリクエストが送られ、変換サービス側がその都度元のサブスクを取得・変換して結果をクライアントに返します。つまり変換サービスは通信経路の中間ノードとして機能するため、それ自体に問題が起きるとサブスク更新も失敗します。この点はトラブル対処時によく見落とされます。

ルールテンプレートを選ぶ際はバージョンの整合性に注意してください。古いバージョンのClash向けに書かれたテンプレートには、新しいコアでは廃止・改名されたフィールドが含まれている場合があり、読み込み後にポリシーグループの表示がおかしくなってもエラー自体は出ないため、サブスク自体の問題と誤解されやすいです。

変換失敗のよくある原因と対処

サブスク変換の失敗は大きく4つの原因に分類できます。発生頻度の高い順に挙げます。

元のサブスクアドレス自体にアクセスできない。変換サービスは元データを取得できて初めて変換が行えます。運営元のリンクが期限切れ、通信制限、あるいは特定地域のネットワークからしかアクセスできない状態になっていると、この段階で変換が失敗し、エラーは形式の問題ではなく「サブスクを取得できません」と表示されることが多いです。
ノードのプロトコルが変換サービス側で未対応。比較的新しいプロトコルに変換サービスのテンプレートがまだ対応していない場合、解析時にそのノードがスキップされ、変換後のノード数が元のサブスクより明らかに少なくなります。
ルールテンプレートと対象コアのバージョンが噛み合わない。テンプレートに新しいコアでしか使えないフィールドが記述されている場合、古いバージョンのクライアントはエラーを出すか該当フィールドを無視し、ポリシーグループや振り分けルールの動作がおかしくなります。
特殊文字のエスケープ処理の不備。ノード名(備考)にコロンや引用符などYAMLの特殊文字が含まれている場合、変換処理で正しくエスケープされないと生成ファイルの構文が壊れ、以降のすべてのフィールド解析が失敗します。

対処する際は次の順に確認するのがおすすめです。まず元のサブスクアドレスに直接アクセスして正常に開けるか確認し、次に変換後のノード数と運営元の管理画面上のノード数が一致しているか比較し、最後に生成されたYAMLにインデントの乱れや未エスケープの特殊文字がないか確認します。ほとんどの問題はこの3ステップ以内で該当箇所を特定できます。

注意

複数の変換サービスを連結して使う(A変換サービスの出力アドレスをさらにB変換サービスに渡す)のは避けてください。段数が増えるほど中間リクエストが失敗するリスクが高まり、どの段階で問題が起きたのか特定するのも難しくなります。

クライアント間でのサブスク移行手順

Clashクライアントを乗り換える際、同じサブスクアドレスをそのまま使い回せることが多いです。主要クライアントは標準的なYAML構造に対応しているためですが、独自フィールドやデフォルトのポリシーグループ名の違いには注意が必要です。以下の手順で進めることをおすすめします。

まず新しいクライアントに単独でサブスクを追加し、旧クライアントの設定はすぐに削除せず、比較・切り戻し用として残しておきます。
追加後に手動でサブスク更新を実行し、ノード数が元のクライアントと一致しているか確認します。
ポリシーグループのページを開き、グループとルールセットが正常に読み込まれているかを確認します。特に自動速度測定グループが正しくノードを選べているかに注意してください。
一部のカスタムルールが失われている場合、旧クライアント側で手動追加したローカルルールである可能性が高く、これらはサブスクに含まれず同期されないため、新クライアントで改めて設定し直す必要があります。
問題がないことを確認できたら、旧クライアントのシステムプロキシまたはTUNモードをオフにし、2つのクライアントが同時にネットワーク出口を奪い合って競合するのを防ぎます。

サブスクが変換サービス経由で生成されたものであれば、移行時には前のクライアントで生成された変換結果をそのまま流用するより、元の運営元のサブスクアドレスから変換処理をもう一度やり直して新しいアドレスを発行するほうがおすすめです。そうすることで、新クライアントのバージョンに適合したルールテンプレートを確実に反映できます。

形式	可読性	ルール有無	典型的な発行元
Clash YAML	構造化・人が直接読める	ポリシーグループとルールを含められる	変換サービスによる生成・手書き設定
汎用Base64ノードリンク	デコードして確認する必要あり	ルールなし・ノード情報のみ	運営元の元サブスク
クライアント独自形式	構造化・拡張フィールドあり	ルールとUI拡張を含む	特定クライアントの書き出しファイル

まとめ

サブスクの形式にまつわる問題は煩雑に見えますが、分解すると「ノード自体をどうエンコードするか」「設定全体をどう構成するか」「間に変換サービスの処理を挟んでいるか」の3点に絞られます。サブスクが読み込めない、あるいは移行後に動作がおかしいときは、まずどの段階に問題があるのかを見極め、本記事の確認順に従って一つずつ検証すれば、ほとんどの形式関連の障害は数分以内に特定・解決できます。