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

サブスクリプションURL・エンコード・設定形式の違い

サブスクリプションURLはデータを取得するためのアドレス、YAMLは設定を記述するデータ形式、Base64はエンコード方式、URIノードは単一プロキシを共有するための表記です。それぞれ異なる階層の概念です。https://で始まるサブスクリプションURLが返す内容は、完全なYAMLの場合もあれば、複数行のノードリンクをBase64でエンコードしたものの場合もあります。

Clashにインポートできるかどうかは、URLの末尾に.yamlが付いているかではなく、レスポンス本文の構造をクライアントのコアが解析できるかで決まります。サービスによってはリクエストのUser-Agentに応じて異なる内容を返すため、ブラウザーで開いた結果と、クライアントがサブスクリプションを更新したときに受け取る内容が一致するとは限りません。

Clash YAML：完全な設定とノード一覧

YAMLはキーと値、インデントで構造を表します。フィールドの関係を示すため、最小限の設定例を紹介します。ローカルの混合プロキシポートは7890、プロキシサーバーのポートは8388で、用途は異なります。ドメイン名とパスワードは構文の例示用であり、接続可能なプロキシサービスを提供するものではありません。

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

proxies:
  - name: "サンプル SS"
    type: ss
    server: node.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "test"
    udp: true

proxy-groups:
  - name: "出口選択"
    type: select
    proxies:
      - "サンプル SS"
      - DIRECT

rules:
  - MATCH,出口選択

3つの主要フィールドの役割

• proxiesは、プロトコル、サーバー、ポート、認証情報などの接続パラメーターを定義します。
• proxy-groupsはノードの選択方法を定義します。例のselectでは、「サンプル SS」またはDIRECTを手動で選べます。
• rulesは接続に適用するポリシーを決めます。ここでのMATCH,出口選択は最終的なフォールバックであり、地域やドメインごとに振り分けるルールセットではありません。

proxiesだけを含むYAMLは、完全な設定ではありません。ノードプロバイダー用のデータファイルとして使う形式です。クライアントによってはそのままインポートできますが、完全なトラフィック振り分けポリシーが設定済みという意味ではありません。自動補完、設定のマージ、オーバーライドはクライアント側の機能なので、それぞれ個別に確認してください。

YAMLの解析エラーはインデントと文字列を確認

インデントにはスペースを使い、タブと混在させないでください。ノード名は、特にコロンやシャープなどの記号を含む場合、引用符で囲むのがおすすめです。パスワードも引用符で囲むと、一部の文字列が数値や真偽値として解釈されるのを防げます。変更後は構造の妥当性とコアの対応状況を両方確認してください。YAMLとして解析できても、すべてのプロキシフィールドを現在のコアで使えるとは限りません。

Base64とURI：デコードしてからプロトコルを判別

一般的なBase64サブスクリプションでは、複数のURIを改行でつなぎ、全体をエンコードします。変換するには、まずテキストに戻し、各行のプロトコルを判別します。デコードせず、プレーンテキストのURI一覧を直接返すサービスもあるため、すべてのサブスクリプションを一律にデコードするのは避けてください。

Shadowsocksの共有リンクを例に解説

以下は一般的なSIP002形式です。認証部分はBase64でエンコードされ、サーバーとポートは外側に記述されます。認証部分のYWVzLTEyOC1nY206dGVzdA==をデコードすると、aes-128-gcm:testになります。

ss://[email protected]:8388#demo

• ss://はShadowsocksプロトコルを表します。
• 認証部分は、暗号化方式aes-128-gcmとパスワードtestに対応します。
• node.example.com:8388はサーバーアドレスとサーバーポートを表します。
• #demoは表示名です。サーバーのパスワードではなく、HTTPリクエストのフラグメントとしてサブスクリプションサーバーに送信されることもありません。

旧形式のSS共有リンクでは、サーバーアドレスもエンコード部分に含まれる場合があります。プラグイン付きのリンクにはpluginパラメーターが含まれることもあります。固定の@位置だけを基準に、すべての形式を分割することはできません。Trojan、VMess、VLESSの共有形式もそれぞれ異なります。たとえば、一般的なVMess共有リンクのエンコードされた本文はJSONであり、SS形式の認証文字列ではありません。

日本語のノード名とエンコード形式の違い

ノード名にはパーセントエンコードが使われることがあります。たとえばURIフラグメントの%E9%A6%99%E6%B8%AFは「香港」を表します。パーセントデコードとBase64デコードは別の処理であり、実行する順序はプロトコルによって異なります。Base64にはURLセーフ文字の-や_が使われたり、末尾の=が省略されたりすることもあります。イコール記号がないだけでリンクが壊れていると判断せず、こうした形式に対応したパーサーを使ってください。

サブスクリプション変換：解析・マッピング・生成ルール

コンバーターは通常、元のサブスクリプションを取得してノードを内部データ構造に解析し、最後に出力先の形式へ変換します。完全なClash設定を生成する際は、テンプレートを適用してプロキシグループ、DNS、ルールを追加することもあります。つまり「Base64をYAMLに変換する」とは、テキストの外側だけを入れ替えるのではなく、フィールドのマッピングと設定の生成を行うことです。

1. 元データを取得：HTTPステータスと本文を確認し、ログインページ、期限切れの通知、レート制限ページ、CAPTCHAページを除外します。
2. 入力形式を判別：完全なYAML、プロバイダー用YAML、プレーンテキストのURI一覧、エンコード済みサブスクリプションを区別します。
3. ノードを解析：プロトコル、アドレス、ポート、認証情報のほか、TLSやトランスポートなどのパラメーターを抽出します。
4. 出力先を選択：実際のコアが対応するフィールドを出力します。クライアント名にClashが含まれているかだけで判断してはいけません。
5. テンプレートを適用：プロキシグループとルールを生成し、ノード名とグループ名の参照関係を確認します。

よく使う変換パラメーターの見方

以下では、一般的なsubconverter形式のAPIを例にします。パラメーターは業界共通の標準ではなく、実装やバージョンによってデフォルト値が異なる場合があります。利用前に、導入するサービスのドキュメントを確認してください。

ローカルに変換サービスを導入し、127.0.0.1:25500で待ち受けていることを前提に、パラメーターを入れ子でエンコードする方法を示します。このアドレスはAPIの説明用であり、クライアントのインストール時に変換サービスが自動で用意されるわけではありません。

http://127.0.0.1:25500/sub?target=clash&url=https%3A%2F%2Fsubscription.example.com%2Ffeed%3Ftoken%3Ddemo&list=false&emoji=false&udp=true

内側のアドレスはもともとhttps://subscription.example.com/feed?token=demoです。元アドレスに&type=allがある場合、アンパサンドも%26にエンコードしてください。そうしないと、変換サービス側のパラメーターとして扱われます。外側のURL全体をさらにエンコードし、サブスクリプションURLとしてそのまま使わないでください。

相互変換の限界：ノードは出力できても、振り分け設定は維持できない場合がある

URIが通常表すのは単一のノードです。一方、完全なYAMLにはルール、プロキシグループ、DNS、TUN、ノードプロバイダーの定義も含められます。完全なYAMLをURI一覧に変換すると、こうした全体設定は通常表現できません。その後URIからYAMLに戻しても、新しいテンプレートで生成された設定になるため、元の設定を完全に復元できるわけではありません。

新しいプロトコルにはコアとコンバーターの両方が対応している必要がある

Clashのオリジナル版、Clash Meta、mihomoでは、対応するプロトコルやフィールドの範囲が異なります。たとえばHysteria2の場合、元のノードが存在していても、旧コア向けの変換先で設定を維持できるとは限りません。変換ツールが入力プロトコルを認識できること、出力側が対応フィールドを表現できること、実行するコアがそのフィールドを読み込んで利用できることの3つが必要です。

• TLSパラメーター：SNI、証明書の検証設定、ALPNを確認してください。インポートを通すためだけに証明書の検証を安易に無効にしてはいけません。
• トランスポートパラメーター：WebSocketのパスとリクエストヘッダーを維持してください。パスを失うと、ノードは正常に表示されてもハンドシェイクに失敗することがあります。
• 拡張機能：多重化、フィンガープリント、Realityなどの設定は項目ごとに確認してください。同じ名前のフィールドが、すべてのコアで同じ意味を持つとは限りません。
• 名前の参照：名前を変更した場合は、プロキシグループ側の参照も合わせて更新する必要があります。ノード名が重複すると、検証に失敗したり、意図しないノードが選ばれたりすることがあります。

元のサービスが現在のmihomoコアに合ったYAMLを提供しているなら、まずはその形式を直接使うのがおすすめです。入力形式に互換性がない場合、テンプレートを一元管理したい場合、複数のソースをまとめたい場合に限って変換を挟めば、フィールドが失われる機会を減らせます。

変換後の確認：インポート成功から実際の接続まで

インポートに成功したからといって、設定の解析がすべての段階で完了したとは限りません。元の設定を残し、変換後の内容は別ファイルに保存してから、以下の順番で確認してください。一度に置き換えて復旧手段を失うのを防げます。

1. ノード数を確認：元のサブスクリプションに12個のノードがあるのに、出力が8個しかない場合は、そのまま使い始めず、フィルター条件、プロトコルの対応状況、解析ログを確認してください。
2. 重要なフィールドを確認：ノードを最低1つ選び、サーバー、ポート、プロトコル、認証情報、TLSパラメーターを照合します。名前が一致するだけでは不十分です。
3. コアの設定を確認：mihomoのコマンドラインプログラムをインストールしている場合は、以下のテストコマンドを実行できます。実行ファイル名とパスは、ローカルのインストール環境に合わせてください。
4. プロキシグループを確認：グループ内に対象ノードがあること、最終ルールが実在するポリシーを参照していることを確認します。テンプレートによってDIRECTに意図せず書き換えられていないかも確認してください。
5. 実際の接続を確認：まずノードをテストし、次に接続一覧で対象ドメイン、適用されたルール、最終的な通信経路を確認してください。1回の遅延テストだけで、すべてのWebサイトやUDPアプリが使えると判断することはできません。

mihomo -t -f converted.yaml

このコマンドは設定をテストするもので、リモートサーバーに必ず接続できることを証明するものではありません。設定が外部プロバイダーやルールリソースを参照している場合、テスト中にそれらの読み込みが発生することもあります。未対応フィールドのエラーが出た場合は、まずコアの対応状況を確認してください。不明なプロキシ名が表示された場合は、プロキシグループやルールの参照先を確認します。YAMLの解析エラーなら、インデント、引用符、リストの構造を見直してください。

「インポートできるのに接続できない」場合の切り分け

• すべてのノードが同時に失敗する場合：まずネットワーク、サブスクリプションの期限、変換結果全体に誤ったテンプレートが適用されていないかを確認します。
• 特定のプロトコルだけ失敗する場合：そのプロトコルのコア対応状況、トランスポートパラメーター、コンバーターのバージョンを優先して確認します。
• ノードテストは成功するのにWebページが開けない場合：適用ルール、DNSの名前解決、アプリがプロキシ経由で通信しているかを確認します。
• ブラウザーでは使えるのにゲームで失敗する場合：UDP、アプリのプロキシ方式、TUNによる通信の取り込みを確認してください。サブスクリプションのエンコード方式を変えるだけでは解決できません。

サブスクリプションのプライバシー・更新URL・よくある質問

一度変換したら、ノードは自動で更新されますか？

ローカルのYAMLファイルをインポートした場合、通常はインポート時点のスナップショットが読み込まれるだけで、元のサブスクリプションから新しいノードを自動取得することはありません。変換後のリモートURLをインポートした場合、クライアントが更新時にそのURLへ再度アクセスします。元のサブスクリプションから最新データを取得できるかどうかは、変換サービスのキャッシュ設定にも左右されます。元のURL、出力形式、テンプレート設定を記録しておけば、元データが更新されていないのか、変換キャッシュがまだ更新されていないのかを後から切り分けやすくなります。

ブラウザーで開くと文字化けした長い文字列が表示されるのはなぜですか？

本文の大半が英数字と少数のエンコード記号で構成されている場合、Base64の可能性があります。ローカルでデコードして内容を確認してください。本文がHTMLタグで始まる場合や、ログイン、利用上限、アクセス制限の案内が表示される場合は、有効なノード設定ではありません。エラーページを変換にかけ続けないでください。また、HTTP 200だけを根拠にサブスクリプションが有効だと判断しないでください。

トラブルシューティングのためにサブスクリプションURLを他人に送ってもよいですか？

URLをそのまま送るのはおすすめしません。認証情報を削除したプロトコル名、エラーメッセージ、設定の一部を共有してください。トークンを公開してしまった場合は、サーバー側でサブスクリプションURLを再発行してください。ローカルの履歴を削除しただけでは、古いトークンは無効になりません。再発行後は、クライアントや変換サービスに保存された元URLも更新してください。

実際の選択手順は3段階にまとめられます。まずレスポンス本文の形式を判別し、次に対象のコアを確認し、最後に変換後のフィールドと接続結果を確かめます。エンコードはテキストの表現、変換は形式のマッピング、ルールテンプレートは通信先の決定に関わります。この3つを分けて考えると、トラブルの切り分けがしやすくなります。