Clashのサブスク形式を比較：Base64ノードリンク・YAML・sing-box JSONの相互変換

サブスク形式：ノード一覧と完全な設定ファイルを区別する

「サブスクリプションURL」はコンテンツを取得するための入口であり、ファイル形式そのものではありません。同じURLでも、リクエストパラメーターやヘッダー、サーバー側の設定によって返される内容が異なる場合があります。Clashクライアントに読み込めるかどうかは、URLの末尾が.yamlかではなく、実際の応答内容で判断してください。

よくある入力形式には、1行ごとに並んだノード共有リンク、リンク一覧全体をBase64でエンコードしたテキスト、ノードやルーティングを含む完全な設定ファイルがあります。Base64はエンコード方式であり、暗号化でもプロキシプロトコルでもありません。デコード方法を知っていればサーバーアドレスや認証情報を復元できるため、エンコード済みのサブスクも厳重に管理してください。

コンテンツの種類	よくある構造	通常含まれる内容	これだけでは判断できないこと
ノードリンク一覧	`ss://`、`vmess://`、`vless://`など。1行につき1件	ノードのアドレス、認証情報、一部の通信パラメーター	プロキシグループ、DNS、ルールが設定済みであること
Base64サブスク	一覧全体をエンコードしたテキスト	通常はデコード後のノードリンク一覧と同じ内容	特定のクライアントがすべてのプロトコルを認識できること
Clash YAML	`proxies`、`proxy-groups`、`rules`	ノード、プロキシグループ、ルール、任意のDNS設定など	Clash系のすべてのコアが全フィールドに対応していること
sing-box JSON	`inbounds`、`outbounds`、`route`	インバウンド、アウトバウンド、ルーティング、任意のDNS設定など	Clash YAMLとすべてのフィールドが一対一で対応すること

コンテンツの見分け方：応答を確認してからBase64をデコード

ログインページやエラーページでないか確認する

サブスクをローカルにダウンロードしたら、まずテキストエディターで冒頭を確認してください。<!DOCTYPE html>やログインフォーム、アクセス制限の案内が表示される場合、取得したのは設定ファイルではなくWebページです。HTTPステータスが200でも内容が正しいとは限りません。サブスクの期限切れ、リクエストのブロック、アカウント認証の要求などによってHTMLが返されることがあります。

アカウント管理ページで、利用するクライアントに対応した入口からサブスクを取得したか確認し、有効期限もチェックしてください。
リダイレクト後の実際の応答内容を確認し、エラーページを変換ツールに渡さないようにしてください。
proxies:やJSONオブジェクトがすでに含まれている場合は、構造から用途を判断し、Base64を重ねてデコードしないでください。
内容が実際にエンコードされたテキストの場合に限り、ローカルでデコードしてください。トークンを含む内容を公開オンラインデコーダーに貼り付けないでください。

ローカルでデコードする例

以下の例ではPython 3の標準ライブラリを使い、ローカルのsubscription.txtを読み込みます。一般的な標準およびURLセーフBase64の文字セットに対応し、末尾のパディングも補います。処理するのはエンコード層のみで、ノードプロトコルの解析は行いません。個人用のターミナルで実行してください。出力にパスワードが含まれることがあるため、問い合わせや公開ログには載せないでください。

from pathlib import Path
import base64

raw = Path("subscription.txt").read_text(encoding="utf-8").strip()
compact = "".join(raw.split())
compact += "=" * (-len(compact) % 4)
decoded = base64.b64decode(compact, altchars=b"-_", validate=True)
print(decoded.decode("utf-8"))

デコードに失敗しても、必ずしもサブスクが壊れているとは限りません。もともとエンコードされていない可能性もあります。UTF-8のテキストを取得できたら、次に1行ごとのノードリンクかどうかを確認してください。一覧全体をデコードできても、各リンクの内部まで再度まとめてデコードする必要はありません。たとえばShadowsocksのユーザー情報や一部のVMess共有形式にはそれぞれ固有のエンコード規則があり、プロトコルパーサーで個別に処理します。

変換の仕組み：ノードを解析して、変換先の設定を生成する

サブスク変換は、YAMLのコロンをJSONの波括弧に置き換えるだけの処理ではありません。一般的な変換ツールは、まず入力形式を解析してプロトコル、アドレス、ポート、認証情報、通信パラメーターを抽出し、内部のノードモデルを作成してから、変換先のコアが対応するフィールドを出力します。プロキシグループ、ルール、DNS、インバウンドは、別のテンプレートで補うことがよくあります。

そのため、「変換成功」は出力が生成されたことを示すだけで、ノードプロトコルが使えることや、元の設定の動作がすべて維持されたことを意味しません。完全なYAMLからノードリンクを書き出す場合、ノード以外のプロキシグループ、ルールプロバイダー、DNSルーティング、TUN設定などは通常リンクに含められません。そのリンクからJSONを生成しても、失われた情報が自動で復元されることはありません。

よくある変換方向とその制約

Base64 → Clash YAML：デコードしてリンクを解析し、proxiesを生成したうえで、必要なプロキシグループとルールを追加します。
Clash YAML → Base64：通常は共有リンクで表現できるノードだけを書き出し、リンク一覧をエンコードします。設定のバックアップにはなりません。
Clash YAML → sing-box JSON：ノードのフィールドを対応付け、ルーティングとDNSは対象バージョンに合わせて再構成する必要があります。
sing-box JSON → Clash YAML：アウトバウンドの種類やルールのアクションに対応する実装があるか確認してください。独自のルーティングロジックは手作業で再構築するしかない場合があります。

オリジナルのClashとClash Meta（現mihomo）では、対応する機能が異なります。新しいプロトコルを使う設定では、そのプロトコルに対応したコアを変換先に選んでください。拡張子を.yamlに変えても、旧バージョンのコアにVLESS、Realityなどの新機能が追加されるわけではありません。GUIクライアントに同梱されているコアのバージョンも異なる場合があるため、実際に動作中のバージョンを確認してください。

フィールドの対応関係：Shadowsocksノードで比較

以下の2つの設定は、同じShadowsocksのサンプルアウトバウンドを表しています。サーバーポートは8388、ローカルの混合プロキシポートは7890です。ドメインには予約済みの.invalidを使い、パスワードはサンプル値です。各フィールドの理解用であり、そのままインターネットには接続できません。どちらの設定もTUNやシステムプロキシは有効にしていません。

mihomo YAML：ノード、プロキシグループ、フォールバックルール

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

proxies:
  - name: サンプルノード
    type: ss
    server: node.example.invalid
    port: 8388
    cipher: aes-128-gcm
    password: "demo-only-password"

proxy-groups:
  - name: 出口選択
    type: select
    proxies:
      - サンプルノード
      - DIRECT

rules:
  - MATCH,出口選択

sing-box JSON：インバウンド、アウトバウンド、最終ルート

{
  "log": {
    "level": "info"
  },
  "inbounds": [
    {
      "type": "mixed",
      "tag": "mixed-in",
      "listen": "127.0.0.1",
      "listen_port": 7890
    }
  ],
  "outbounds": [
    {
      "type": "shadowsocks",
      "tag": "サンプルノード",
      "server": "node.example.invalid",
      "server_port": 8388,
      "method": "aes-128-gcm",
      "password": "demo-only-password"
    },
    {
      "type": "direct",
      "tag": "ダイレクト"
    },
    {
      "type": "selector",
      "tag": "出口選択",
      "outbounds": ["サンプルノード", "ダイレクト"],
      "default": "サンプルノード"
    }
  ],
  "route": {
    "final": "出口選択"
  }
}

ここではcipherがmethodに対応し、ノードのサーバーポートを表すportはserver_portに対応します。ノード名は参照先となるtagに変わります。このJSONの例では、Clash組み込みのDIRECTを明示的なdirectアウトバウンドで表しています。実際の設定では、使用するsing-boxのバージョンで検証してください。特にDNS、TUN、ルーティングアクションなど、仕様が更新され続けている項目に注意が必要です。

2つのプログラムが同じ端末の7890リッスンポートを同時に使用することはできません。比較テストでは一方を停止するか、もう一方の設定を7891に変更し、テストツールのプロキシアドレスも合わせて変更してください。そうしないと、「ポートが使用中」というエラーをサブスク変換の失敗と誤認しやすくなります。

変換パラメーター：変換先、フィルター、テンプレートを個別に確認

変換サービスのパラメーターに統一規格はありません。subconverterベースの環境では、target、url、include、exclude、configなどを受け付ける場合がありますが、名前が同じでも意味まで一致するとは限りません。運営元の説明を確認し、他のサービスの変換URLをそのまま流用しないでください。

パラメーターの種類	確認するポイント	よくある結果
変換先の種類	使用するmihomoまたはsing-boxのバージョンに明確に対応しているか	変換先を誤ると、非対応のプロトコルやフィールドが削除される
入力するサブスクURL	ネストされたURLをAPIの仕様どおりにエンコードしているか	元URL内の`&`が外側のパラメーター区切りとして扱われる
ノードの絞り込み	包含・除外条件に正規表現を使うか	絞り込み後のノード数がゼロになり、プロキシグループの参照先がなくなる
設定テンプレート	DNS、ルール、グループ名、リッスンポートを上書きするか	ノードは変わらなくても、通信経路や名前解決の動作が変わる
名前の変更と並べ替え	名前の重複を避け、参照先も合わせて更新するか	ノード名の重複や参照先の欠落により、設定の読み込みに失敗する

ネストされたURLは、空白だけを勘で置き換えるのではなく、URLエンコードツールに1つのパラメーター値として渡してください。生成結果全体を何度もエンコードするのも避けましょう。元URLの%がさらに%25へ変わることがあります。変換ツールが空の一覧を返す場合は、まず絞り込み条件を一時的に外し、変換先との互換性を確認してください。

変換後の確認：構文を検証してから実際の動作をテスト

手順1：対象コアで設定を検証する

JSONとして構文が正しくても、sing-boxの設定として正しいとは限りません。YAMLを解析できても、コアがそのフィールドに対応しているとは限りません。対応するコマンドラインプログラムがインストールされた環境で、以下の検証を実行してください。実行ファイル名やパスは実際のインストール環境に合わせます。

mihomo -t -f converted.yaml
sing-box check -c converted.json

未対応フィールド、アウトバウンドの不足、存在しないプロキシグループへの参照などのエラーを解消してから、プロキシを起動してください。GUIクライアントが設定をマージまたは上書きする場合は、クライアントが最終的に生成する実行時設定も確認します。インポートしたファイルが検証に通っても、上書き後に有効とは限りません。

手順2：失われやすい接続パラメーターを1つずつ確認する

認証情報とポート：サーバーのドメイン、ポート、パスワードまたはUUIDを確認してください。ローカルの7890をサーバーポートと取り違えないようにします。
TLS：有効かどうか、サーバー名、証明書の検証を確認してください。SNIやサーバー名の対応付けの誤りを、証明書検証の無効化でごまかさないでください。
トランスポート層：WebSocketのパス、Hostヘッダー、gRPCのサービス名などを個別に確認してください。プロトコル名だけ残しても不十分です。
Realityとフィンガープリント：公開鍵、Short ID、サーバー名、クライアントのフィンガープリントが変換先でサポートされ、正しく出力されているか確認してください。
UDP：プロトコル、ノードのサーバー、変換先の設定が必要なUDP通信に対応しているか確認してください。Webページを一度表示できても、UDPが使えるとは限りません。

手順3：ルーティングとDNSを確認する

Clashのrulesは上から順に評価され、最後のMATCHは一般的なフォールバックです。sing-boxのルーティングルール、アクション、route.finalは独自の構造を持つため、行ごとにコピーすることはできません。ルールの転送先が存在するか、プロキシサーバーのドメイン解決がまだ確立していないプロキシに依存していないかを確認し、名前解決と接続が互いに待ち続ける状態を避けてください。

DNSのfake-ip、ドメイン解決ポリシー、ルールセットの形式、ダウンロード先もそのまま移植できるとは限りません。Clashのrule-providersとsing-boxのルールセットは同じファイル形式ではありません。テキスト形式のリストを読み込めても、バイナリ形式のルールセットをそのまま共用できるとは限りません。TUNはインターフェース、ルーティング、システム権限にも関わるため、ノードリンクだけでは完全に表現できません。

よくある質問：インポート、更新、形式の選び方

変換後にノードは表示されるのに、接続できないのはなぜ？

まず、サンプル用ドメインや期限切れのサブスク、ポートの競合が原因でないか確認し、次にログでエラーが発生している層を特定してください。ドメイン解決に失敗する場合はDNS、TCP接続に失敗する場合はアドレス・ポート・ローカルネットワーク、TLSハンドシェイクに失敗する場合はシステム時刻・サーバー名・証明書を確認します。Base64とYAMLを何度も切り替えても、こうした接続層の問題は通常解決しません。

サブスクの更新後にローカルの変更が消えるのはなぜ？

リモート設定を更新すると、ダウンロードした内容が置き換わるのが一般的です。DNS、ルール、プロキシグループなど、継続して使いたい変更には、クライアントが対応する独立したオーバーライドやマージ機能を使い、サブスク更新後も適用されることを確認してください。変換で生成した静的ファイルも自動更新されません。継続して同期するには、再取得できる元の入口と、繰り返し実行できる変換手順が必要です。

どの形式を選べばよい？

mihomoのみを使う場合：提供元がmihomo対応と明記しているYAMLを優先し、完全な設定かノードプロバイダーかを確認してください。
sing-boxのみを使う場合：使用中のコアのバージョンに対応したJSONを選び、他の完全な設定を経由した変換を繰り返さないようにしてください。
複数のコアでノードを共用する場合：信頼できる同一のノードソースを保ち、無理に1つのメイン設定を共有せず、コアごとにルールとDNSのテンプレートを用意してください。
Base64のリンク一覧しかない場合：信頼できる環境でデコードと変換を行い、入力・出力ノード数とスキップされたプロトコルを記録してから、読み込みテストを実施してください。

信頼できる変換結果には、ノードのパラメーターが欠落していないこと、変換先の設定がコアの検証を通ること、実際の通信が想定したルールに従うことの3つが必要です。元のサブスク入口と直前に使えた設定を保存しておくと、テンプレートやコアを更新した後の差分をすばやく特定できます。フィールドの意味はYAMLハンドブック、基本概念は用語クイックリファレンスも参照してください。