Clashのサブスクリプション形式を比較｜YAML・Base64・URIの変換方法

内容を見分けてから、適切な方法で読み込む

サービス提供元がClashまたはmihomo向けとして明示しているサブスクリプションを優先してください。完全なYAML設定を取得した場合は、通常そのままクライアントの設定一覧に追加できます。Base64テキストや複数のプロトコルURIの場合は、クライアントがその形式の読み込みに対応しているか確認しましょう。ファイルの拡張子を変更するだけでは不十分です。「サブスクリプションをダウンロードできた」ことと「コアが設定を受け付けた」ことは別です。

まず、混同しやすい2つの要素を区別しましょう。サブスクリプションURLはデータを取得するための入口で、サブスクリプション形式はURLから実際に返されるデータの構造です。同じHTTPS URLでも、クエリパラメーターやリクエストヘッダーによって異なる内容が返ることがあります。URLが .yaml で終わっていても、レスポンスがYAMLとは限りません。拡張子がなくても、完全な設定を返すことがあります。

YAML設定：完全な設定とノード一覧を見分ける

まずトップレベルのフィールドを確認します。YAMLはデータの表現形式であり、Clash専用の形式ではありません。YAMLパーサーで読み込めても、Clashの設定構造に適合するとは限りません。また、あるコアの構造に適合していても、別のコアがすべてのプロトコルやオプションをサポートするとは限りません。

よくあるYAMLの内容を3種類に分けて確認

• 完全な設定：通常は proxies、proxy-groups、rules をまとめて設定し、リスニングポート、DNS、TUNなども指定できます。
• ノード一覧：proxies のみを含みます。互換性のあるプロキシプロバイダーで利用できますが、プロキシグループやルーティングルールまで設定済みとは限りません。
• ルール一覧：トップレベルのフィールドは payload が一般的です。rule-providers から参照するもので、ノードのサブスクリプションではなく、プロキシ一覧としても読み込めません。

以下は構造を説明するための設定例です。edge.example.com と demo-password はサンプル値であり、実際の接続には使えません。この例では、ローカルの混合ポートを 7890 に設定し、ループバックアドレスのみで待ち受け、手動選択グループですべての該当トラフィックを受け付けます。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

proxies:
  - name: DemoTLS
    type: trojan
    server: edge.example.com
    port: 443
    password: "demo-password"
    sni: edge.example.com
    udp: true

proxy-groups:
  - name: Manual
    type: select
    proxies:
      - DemoTLS
      - DIRECT

rules:
  - MATCH,Manual

ここで 443 はリモートプロキシサーバーのポート、7890 はローカルアプリがクライアントに接続するためのプロキシポートです。両者は置き換えられません。YAMLをノードURIに変換する場合は、リモートポートを保持してください。ローカルの待ち受けポート、プロキシグループ、フォールバックルールは通常、ノードリンクには含まれません。

実際に使うコアに合った設定を選ぶ

まずクライアントの「バージョン情報」やコア情報の画面でコア名を確認し、そのコアが対応するプロトコルを調べます。画面からリンクを貼り付けられても、実行中のコアがそのプロトコルに対応しているとは限りません。Clash Metaの流れをくむmihomoと、以前のClashコアでは、対応するプロトコルやフィールドに違いがあります。変換先はファイル名だけで判断しないでください。

Base64形式のサブスクリプション：デコードと変換は別

まずローカルでデコードし、結果を確認します。Base64はエンコード方式であり、プロキシプロトコルでも暗号化方式でもありません。一般的なサブスクリプションでは、複数のノードURIを1行ずつ並べたテキスト全体をエンコードします。一方、別のテキスト構造をエンコードするサービスもあるため、デコード後にそのままClashへ読み込めるとは限りません。

エンコードが2段になっている場合に注意してください。サブスクリプション全体がBase64でエンコードされているうえに、内部の vmess:// リンクでJSONがBase64エンコードされている場合があります。一部の ss:// リンクでも認証情報がエンコードされます。まずサブスクリプション全体を元に戻し、その後、各リンクを理解できるパーサーで解析してください。文字列を何度も繰り返しデコードするのは避けましょう。

Pythonを使ってローカルでエンコード内容を確認する

受け取ったエンコード済みの本文を subscription.txt として保存し、Python 3で次のコードを実行します。一般的なBase64とURLセーフな文字セットに対応し、空白を無視して末尾のパディングを補います。出力は decoded.txt に保存され、ネットワークには接続しません。入力がYAML、Webページ、通常のURIであれば、実際の形式に応じて処理してください。

from pathlib import Path
import base64
import binascii

source = Path("subscription.txt").read_text(encoding="utf-8")
compact = "".join(source.split())
compact += "=" * (-len(compact) % 4)

try:
    raw = base64.b64decode(compact, altchars=b"-_", validate=True)
    text = raw.decode("utf-8")
except (ValueError, binascii.Error, UnicodeDecodeError) as exc:
    raise SystemExit("Base64のUTF-8テキストとしてデコードできません。元の内容を確認してください。") from exc

Path("decoded.txt").write_text(text, encoding="utf-8")
print("decoded.txt に書き込みました。内容の種類をローカルで確認してください。")

• ss://、trojan:// などが1行ずつ並んでいる場合：URIから設定へのフィールド対応を確認します。
• proxies: が見つかった場合：すでにYAMLかどうかを確認し、さらに「ノード変換」を実行しないでください。
• HTMLのログインページ、エラーメッセージ、JSON形式のエラーオブジェクトが表示された場合：まずサブスクリプションのリクエストを解決してください。変換ツールで存在しないノードデータを補うことはできません。

逆に、複数行のURIをBase64でエンコードしても、同じリンク群を別の形で包み直すだけです。rules や proxy-groups が自動生成されるわけではなく、欠けているTLS、WebSocket、認証パラメーターが補われることもありません。

URIからYAMLへ変換：接続パラメーターを項目ごとに対応させる

まず1つのノードで項目を照合してから、一括変換します。以下のTrojan URIは、先ほどのYAMLノードに対応しています。リンク内の #DemoTLS は表示名であり、認証情報ではありません。クエリパラメーターの sni はTLSサーバー名を指定します。

trojan://[email protected]:443?sni=edge.example.com#DemoTLS

このURIには、先ほどの例にある udp: true が明示されていません。そのため、URIから元の設定を完全に復元できるとは言えません。変換ツール独自のデフォルト値が使われる場合があります。実際に使う前に、サービスの機能と対象コアの要件に合わせてUDPの設定を明示的に確認してください。

プロトコルとトランスポート層を分けて処理する

• Shadowsocks：暗号化方式、パスワード、サーバー、ポートを保持します。プラグイン付きのリンクでは、プラグイン名とオプションも確認してください。ホストとパスワードだけでは接続できない場合があります。
• VMess：一般的な共有リンクでは、内部にエンコードされたJSONが含まれています。UUID、ポート、トランスポート方式、TLSなどのフィールドを解析してください。デコードした文字列全体をYAMLとして扱うことはできません。
• VLESSなどのプロトコル：対象コアと変換ツールの両方が対応しているか確認し、flow、TLS、Realityなどプロトコル固有のパラメーターを照合します。名前が似ているフィールドを機械的に置き換えないでください。
• WebSocketまたはgRPC：パス、Hostリクエストヘッダー、サービス名などのパラメーターも保持します。プロキシプロトコルが同じでも、トランスポート設定が異なると接続できない場合があります。

文字列を「コロンで分割」するだけの汎用パーサーを自作しないでください。IPv6アドレスにはコロンが含まれ、パスワードにはエスケープ文字が含まれる場合があり、ノード名に日本語が使われることもあります。URI解析ツールを使用し、各プロトコルの仕様に沿ってエンコードを処理してください。二重デコードによってパスワード中の文字列が変わるのを防げます。

YAMLからURIへ変換：失われる情報を把握する

URIは単一ノードを受け渡すための形式として扱ってください。完全なYAMLにはそれ以上の情報が含まれ、ノードリンクを書き出しても実行環境全体は引き継げません。クライアントを乗り換えてルーティング設定も維持したい場合は、URIを書き出して再インポートするのではなく、互換性のある完全な設定を優先して移行してください。

ノードと一緒に完全には移行できない4種類の設定を確認する

1. プロキシグループ：select、url-test、fallback のメンバー、プローブ先、切り替えロジックは、通常ノードURIには含まれません。
2. ルーティングルール：DOMAIN-SUFFIX、GEOIP、MATCH やルールプロバイダーへの参照は、ノードを書き出しても自動的には保持されません。
3. ローカル環境：待ち受けポート、システムプロキシ、TUN、DNS、外部コントローラーなどの設定は、新しい設定やクライアントで個別に行う必要があります。
4. 拡張パラメーター：特殊なトランスポート、証明書の処理、接続の多重化、コア固有の拡張フィールドには、統一されたURI表現がない場合や、一部のインポーターしか認識しない場合があります。

両方が同じプロトコルに対応していても、共有リンクのパラメーター名は実装によって異なることがあります。変換後はサーバー、ポート、認証情報、TLS名、トランスポート設定を1項目ずつ比較してください。読み込みを成功させるために認識されないパラメーターを削除しないでください。また、証明書の検証を無効にする方法を一般的な解決策として使わないでください。

自前で変換する：入口を制限し、出力テンプレートを固定する

ローカルで実行するか、自分だけがアクセスできる環境へのデプロイを優先してください。自前の変換ではYAMLを生成するだけでなく、元のサブスクリプション認証情報を保護し、リモート取得先を制限し、後から確認できる変換テンプレートを固定することも重要です。

1. 実装を選ぶ：変換ツールが元のプロトコル、対象コア、必要な拡張フィールドを明示的にサポートしているか確認します。デプロイしたバージョンとテンプレートの改訂内容を記録し、更新前に動作する出力を保存してください。
2. 待ち受け範囲を絞る：ローカルサービスは 127.0.0.1 のみで待ち受けるようにできます。たとえばローカルポート 25500 を使う場合、ポートをそのままインターネットに公開しないでください。実際のポート番号は、使用する実装の設定に従います。
3. テンプレートを固定する：テンプレート内のプロキシグループ、ルール、リモートリソースのURLを確認します。変換時にノードだけを置き換え、出所不明のテンプレートによってDNS、コントローラー、トラフィックの出口が変更されないようにしてください。
4. リモートURLを処理する：元のサブスクリプションとリモートテンプレートには許可リストを適用し、リダイレクト、レスポンスサイズ、リクエストのタイムアウトを制限します。サービスがイントラネットやクラウドインスタンスのメタデータ用アドレスにアクセスするのを防いでください。
5. ログを制限する：完全なクエリー文字列、認証ヘッダー、サブスクリプション本文を記録しないでください。ログを共有する場合は、事前にトークンを隠し、生成ファイルとキャッシュを定期的に削除します。

URLパラメーターで元のサブスクリプションを渡す場合は、元のURL全体を正しくパーセントエンコードしてください。元のURLに ?token= と &type= が含まれているとき、エンコードせずに別のURLへ埋め込むと、外側のリクエストでパラメーターが分割されることがあります。変換ツールのドキュメントで対応が確認できるローカルファイルやリクエスト本文の入力方法を優先すると、ブラウザーの履歴やアクセスログに認証情報が残る機会を減らせます。

静的な変換と継続的なサブスクリプションも区別してください。ファイルを一度ダウンロードして生成する場合、取得時点のスナップショットしか得られません。自動更新には、信頼できる更新元を維持するか、コアがサポートするプロキシプロバイダーの仕組みを設定する必要があります。リモート更新がローカルの変更を上書きするかどうかは、クライアントのマージ方法や上書き方式によって異なります。「自動更新を有効にした」という設定だけでは判断できません。

変換後の検証：構造、接続、ルーティングを順に確認

まず設定を確認してから、現在の実行設定を切り替えます。変換を一括実行する前に、元の動作するサブスクリプションを残して比較できるようにしてください。mihomoを使う場合は、生成ファイルの設定テストを実行できます。以下のコマンドに指定するファイル名は、ローカルに保存した出力ファイルです。

mihomo -t -f ./converted.yaml

テストに合格しても、そのコアの設定チェックを通過したことを示すだけで、リモートノードが利用可能とは限りません。リモートリソースを参照する設定は、ローカルファイル、ネットワーク接続、実行ディレクトリにも左右されます。テスト環境は、できるだけ実際の運用環境に合わせてください。

必要最小限の動作確認を行う

• 変換の前後でノード数と名前を確認し、除外、改名、解析エラーがないか調べます。
• 利用可能と分かっているノードを1つだけ選び、TLSとトランスポートパラメーターがそろっていることを確認してから、リスト全体に広げます。
• 例と同じ混合ポート 7890 を使う場合は、実際に待ち受けていることを確認してから、アプリをそのポートに接続します。
• 通常のWebアクセス、DNS名前解決、UDPが必要なアプリをそれぞれ確認します。Webページを一度表示できても、すべての利用場面で動作するとは限りません。

最後に変換記録を保存します。元の形式、対象コア、変換ツールとテンプレートのバージョン、手動で追加したフィールドを記録してください。サブスクリプションの更新が失敗した場合に、原因が元データ、解析処理、ローカルの実行設定のどこにあるか判断しやすくなり、オンライン変換サービスを次々に試す必要もありません。