Clashのサブスクリプション形式を解説：Base64のノードリンク、YAML設定、相互変換

サブスクリプションURL、ノードリンク、設定ファイル

同じ「サブスクリプション」でも、実際に提供される内容はさまざまです。HTTPS URLの場合もあれば、ss://で始まるノードリンクが数行並んでいる場合や、proxies:を含むYAMLファイルの場合もあります。Clashにインポートできるかどうかは、リンクの長さや拡張子ではなく、クライアントが取得したレスポンスの内容と、現在のコアがその項目を解釈できるかで決まります。

サブスクリプションURLはコンテンツ取得の入口、サブスクリプション形式は返されるデータ構造、プロキシプロトコルはノードとサーバー間の通信方式です。この3つは混同できません。ファイル名をnodes.txtからconfig.yamlに変えても形式は変わらず、テキストをBase64でエンコードしてもクライアントが新しいプロトコルに対応するわけではありません。

• サブスクリプションURL：通常はアカウントトークンを含むHTTPS URLで、定期的な更新に使われます。返される内容はサーバー側で決まります。
• ノード共有リンク：ノードをプロトコル固有のURIで表します。例：ss://、vmess://、trojan://。プロトコルによって項目のエンコード方法は異なります。
• 完全な設定ファイル：ノードのほか、プロキシグループ、ルール、DNS、待ち受けポート、外部リソースなどを定義できます。

Base64サブスクリプション：エンコードされたノードリンクの集合

一般的な汎用サブスクリプションでは、複数のノード共有リンクを1行ずつ並べ、テキスト全体をBase64でエンコードします。デコードするとURIの一覧が得られますが、Clashにそのまま読み込める完全な設定ファイルではありません。エンコードされていないリンク一覧や、JSONなど別の形式を返すサービスもあります。「長い英数字の文字列に見える」だけで形式を判断しないでください。

Base64に暗号化の効果はない

たとえばaGVsbG8=をデコードするとhelloになります。Base64はバイト列をテキストで扱いやすい形式に変換するもので、鍵は必要ありません。サブスクリプションに含まれるパスワード、UUID、サーバーアドレスは、エンコードされていても内容を入手した人が復元できる可能性があります。

標準Base64では、英字、数字、+、/が使われ、末尾に=が付くことがあります。URLセーフ形式では-や_を使い、実装によってはパディングを省略します。デコードに失敗しても、形式の違いや改行処理が原因の可能性があるため、すぐにサブスクリプションが無効だと判断しないでください。

外側をデコードした後、個々のリンクも解析が必要

従来のvmess://共有リンクでは、JSONをBase64のペイロードに含めることがよくあります。一方、ss://には独自のユーザー情報のエンコード方法やプラグインパラメーターの規約があります。サブスクリプション全体のデコードと、個々のプロトコルリンクの解析は別の処理です。同じ「デコード」ボタンを繰り返し押しても、プロトコルの解析にはなりません。

ClashのYAML：ノード、プロキシグループ、ルールの組み合わせ

YAMLはデータ表現形式のひとつで、Clash専用ではありません。設定として使えるのは、現在のコアが求める構造を満たしたYAMLだけです。構文が正しくても、一般的な文書の内容であればClashの設定としてインポートできません。

構造を理解するための設定例

以下の例では混合ポート7890を使い、DIRECTポリシーのみを設定しています。リモートプロキシノードは含まれていないため、プロキシサービスの動作確認には使えません。リスト、インデント、プロキシグループの参照、フォールバックルールの関係を示す例です。7890はこの例での値であり、すべてのクライアントが同じポートを使うわけではありません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: "出口選択"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口選択

YAMLのインデントにはスペースを使い、階層を表すためにTabを使わないでください。#やコロンなどの特殊文字を含むパスワードは、引用符で囲むことをおすすめします。ノード名も統一してください。上の例でルールの対象を存在しない「プロキシ出口」に変更すると、インデントが正しくても設定検証に失敗する可能性があります。

完全な設定ファイルとノードプロバイダー用リソースも区別が必要です。一般的なYAML形式のノードリソースはトップレベルにproxies:だけを持ち、proxy-providersから参照する用途に適していますが、振り分けルールまで設定された完全な設定ファイルではありません。プロキシグループを自動補完するクライアントもあれば、そうでないものもあります。どのクライアントでも同じようにインポートできるとは限りません。

形式の互換性とコアの互換性は別々に確認

Clashクライアントは画面、サブスクリプション管理、システム連携を担い、コアは接続、解析、ルールの実行を担います。Clash Metaはその後mihomoの名称で開発が続いていますが、「Clash設定に対応」とあっても、世代の異なるコアが同じ項目をすべてサポートするとは限りません。

たとえばVLESS、Hysteria2、TUICなどのノードを含む設定では、対象コアとそのバージョンが対応しているか確認が必要です。YAMLに変換しても、旧バージョンのClashコアに該当プロトコルの実装が追加されるわけではありません。プロトコル名に対応していても、Reality、トランスポート層、TLSのパラメーターにバージョン要件がある場合があります。

1. まず入力形式を確認：インポート機能が受け付けるのはサブスクリプションURL、完全な設定ファイル、それとも単一のノード共有リンクですか？「クリップボードからインポート」がすべてのURIに対応しているとは限りません。
2. 次にコアの種類を確認：アプリ名だけで判断せず、クライアントの「バージョン情報」やコア管理画面で、実際に動作しているコアを確認してください。
3. 最後に項目を確認：設定検証で表示されたエラー全文を記録し、ノードの種類、通信パラメーター、リソース参照のどこに問題があるか特定します。クライアントを何度も再インストールする必要はありません。

Clash for Androidの一般的な画面では、リモート設定は通常「設定」→「＋」→「URLからインポート」から追加します。インポート後は設定を選択し、サービスを起動してください。他のクライアントでは同様の機能が「設定」や「サブスクリプション」にある場合があります。ボタン名はバージョンによって異なるため、現在の画面を確認してください。ノードリンクが1つだけの場合、「設定URL」欄に貼り付ければインポートできるとは限りません。

サブスクリプション変換：ノードを解析して目的の設定を生成

サブスクリプション変換は、Base64テキストの拡張子を変えるだけの処理ではありません。一般に変換ツールは、まず元データを取得し、各ノードを判別・解析して内部表現を作成したうえで、目的の形式に合わせたノード項目を生成します。出力先が完全なClash設定の場合は、ルールのテンプレート適用、プロキシグループの作成、DNSの設定、自動速度テストの追加などを行うこともあります。

変換できる内容と、失われる可能性がある内容

• 通常は変換可能：対象コアが対応していれば、サーバーアドレス、ポート、パスワードまたはUUID、明確に対応関係のあるTLSや通信パラメーター。
• 維持できない場合がある：出力形式が対応しないプラグイン設定、プロトコル固有のパラメーター、クライアント独自の拡張、出所が不明確な証明書設定。
• 再設計が必要：ルール、DNS、プロキシグループの階層構造、テスト用ポリシー。ノードリンクだけでは、これらの設定を復元するための情報が不足していることがほとんどです。

逆に、完全なYAMLを汎用ノードリンクに出力すると、多くの場合、残るのはノード情報だけです。元の振り分けルール、DNS、プロキシグループの選択ロジックが、各URIに自動で含まれることはありません。そのため「YAML → リンク一覧 → YAML」と変換しても元の設定に戻る保証はなく、この往復変換をバックアップとして使うことはできません。

オンライン変換サービスに渡す認証情報に注意

サブスクリプションURLをオンライン変換サービスに渡すと、通常そのサービスは元のサブスクリプションにアクセスする必要があり、URL内のトークンや返されるノードの認証情報を扱える状態になります。ブラウザーと変換ページ間の通信がHTTPSで保護されていても、サーバー側によるデータの読み取りは防げません。

まずはサービス提供元が用意するClashまたはmihomo専用サブスクリプションを使ってください。変換が必要な場合は、仕組みを理解しているツールを選び、可能であればローカル環境で処理します。変換結果を共有する前に、完全なURLも確認してください。元のサブスクリプションがクエリパラメーターに含まれている場合があります。誤送信した場合は、サービス提供元の管理画面でサブスクリプショントークンを再発行し、ノードの認証情報も変更すべきか確認してください。

インポートに失敗したら、レスポンス・解析・接続の順に確認

「サブスクリプションのインポート成功」と「ノードへの接続成功」は別の段階です。調査中は元の設定を保管し、DNS、ルール、ポート、TUNを同時に変更しないでください。一度に1か所だけ変更すれば、問題の原因を特定しやすくなります。

HTTP 200はリクエストに対してレスポンスがあったことを示すだけで、本文が設定ファイルである保証はありません。Content-Typeも参考情報にすぎません。ブラウザーでは開けてもクライアントで取得できない場合、リダイレクト、証明書の信頼設定、リクエストヘッダー、ネットワーク経路の違いが原因の可能性もあります。ブラウザーのセッションCookieを汎用的な解決策として使わず、調査のために証明書検証を無効にしないでください。

更新後に使えなくなったら、変更の保存先を確認

リモート設定の更新では、通常、内容が再ダウンロードされます。ダウンロードしたファイルを直接編集すると、次回の更新で変更が上書きされる可能性があります。個人用ルールを追加する場合は、クライアントが明示的にサポートする上書き、マージ、拡張機能を使い、適用順も確認してください。これらはクライアント固有の機能で、メニューや構文は共通ではありません。

プロキシグループが、名前を変更またはフィルタリングされたノードを参照していないか、外部ノードリソースの更新に成功しているかも確認してください。リモート設定を取得できても、参照先のリソースをすべて取得できたとは限りません。

インポート前のチェックリスト

1. Clashまたはmihomo専用サブスクリプションがある：まずはそのままインポートし、現在のコアに対応しているか確認して、変換を挟まないようにします。
2. 汎用Base64サブスクリプションしかない：クライアントにノード解析や変換機能が組み込まれているか確認し、なければ適切な変換ツールを選びます。
3. 共有リンクが1つだけある：そのプロトコルに対応するノードインポート機能を探してください。完全な設定が必要な場合は、プロキシグループとルールも追加します。
4. YAMLファイルを受け取った：まず完全な設定ファイルかノードリソースかを判別し、構文、参照関係、コアの対応状況を確認します。
5. 使用中の設定を切り替える：現在使えるバージョンを残し、新しい設定の検証に成功してから切り替えます。ノード数、プロキシグループ、ルールの動作も確認してください。

形式の確認で分かるのは「データを読み取れるか」、コアの互換性で分かるのは「プロトコルを実行できるか」です。さらに接続ログを確認すれば「サービスに到達できるか」を調べられます。この3段階を分けて確認すれば、サブスクリプション変換、クライアント設定、ネットワーク障害の間で無駄な試行錯誤を避けやすくなります。初回起動の手順は当サイトの使い方ガイド、プロトコルや設定項目はプロトコルリファレンスをご覧ください。