サブスクリプション形式の違いを解説：Clash YAML・Base64ノードリスト・sing-box設定の相互変換

サブスクリプションURLと設定形式：取得先とレスポンス内容を区別する

サブスクリプションURLは設定を取得するための入口であり、特定のファイル形式を指すものではありません。同じHTTPS URLにアクセスしても、クライアントが受け取るのはClash YAML、Base64でエンコードされたノードリスト、sing-box JSONなどさまざまです。サービスによっては、URLのパラメーターやアカウント設定、リクエストヘッダーのUser-Agentに応じて返す内容が変わります。そのため、ブラウザーでURLを開けても、使用中のクライアントにそのままインポートできるとは限りません。

問題を切り分けるときは、リクエストが成功したか、レスポンスがどの形式か、使用するコアがそのプロトコルや項目を解釈できるかの3段階で確認します。HTTP 200はレスポンスを受け取れたことを示すだけです。ログインページや通信量の期限切れ通知、エラーJSONが返される場合もあります。こうしたレスポンスを設定パーサーに渡すと、インポート失敗、ノード数が0、項目不足などのエラーにつながります。

主な3形式に含まれる情報

形式	一般的な構造	主に含まれる情報
Clash YAML	`proxies`、`proxy-groups`、`rules`	ノード、プロキシグループ、ルール。完全な設定にはDNSやリスナー設定も含められます
Base64ノードリスト	デコードすると、共有リンクが1行ずつ並んだ形式になります	ノード接続情報。通常、DNS、ルール、TUNを含む完全な設定は含まれません
sing-box JSON	`inbounds`、`outbounds`、`route`	インバウンド、アウトバウンド、ルーティング。完全な設定にはDNSなどのモジュールも含められます

Clash YAML：完全な設定とノードプロバイダーは別物

完全なClash設定では、ノード、プロキシグループ、ルールを定義できます。以下は直結のみの構成例です。混合プロキシのポートは7890で、ローカルホストだけで待ち受けます。各項目の位置を示すサンプルであり、リモートプロキシへの接続には使えません。ローカルの別のプログラムがこのポートを使用している場合は、先にポートを変更してください。

mixed-port: 7890
allow-lan: false
mode: rule
proxies: []
proxy-groups:
  - name: 手動選択
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,手動選択

トップレベルにproxiesだけを含むYAMLもあります。これはproxy-providersにノードを提供するためのもので、完全な実行設定ではありません。メイン設定からプロバイダー名を指定し、プロキシグループで使用する必要があります。同様に、ルールプロバイダーファイルはpayloadで始まることが多く、ノードサブスクリプションとしてインポートすることはできません。

「Clash形式」でも、コアによって対応機能が異なります。mihomoはClashの設定体系を引き継ぎつつ、プロトコルや拡張項目への対応を追加しています。mihomoで読み込める設定が、オリジナル版Clashでも読み込めるとは限りません。対応状況はGUIクライアントの名前ではなく、実際に使われるコアで確認してください。

Base64：エンコード方式であり、独立したプロキシプロトコルではない

一般的なBase64サブスクリプションでは、複数行のss://、vmess://、trojan://などの共有リンク全体をエンコードします。デコードで元のテキストに戻せますが、プロキシグループやルールが自動的に追加されるわけではありません。サブスクリプションがデコード済みのURI一覧を直接返す場合もあります。また、共有リンク自体がBase64を使用していることもあるため、サブスクリプション全体のエンコードとプロトコル内部のエンコードを区別してください。

Base64には機密性がありません。デコードすると、サーバーアドレス、ポート、認証情報がそのまま見える場合があります。サブスクリプションURLに含まれるトークンと、ダウンロードした設定は認証情報として扱い、公開スクリーンショットやチャット、問い合わせチケットの添付ファイルに含めないでください。

sing-box JSON：対象バージョンに合った設定構造が必要

sing-boxでは通常JSONで設定を記述しますが、JSON形式のノード配列なら何でも完全なsing-box設定になるわけではありません。以下も直結のみの構成例です。ローカルホストの7890で待ち受け、混合インバウンドに入った接続をdirectアウトバウンドに渡します。

{
  "inbounds": [
    {
      "type": "mixed",
      "tag": "local-mixed",
      "listen": "127.0.0.1",
      "listen_port": 7890
    }
  ],
  "outbounds": [
    {
      "type": "direct",
      "tag": "direct"
    }
  ],
  "route": {
    "final": "direct"
  }
}

この例は前述のYAMLとは別々にテストし、同時に起動してポートを競合させないでください。実際のサブスクリプションには、TLS、DNS、ルーティングルール、セレクターなどが含まれることが多く、それぞれ対応バージョンが異なります。変換先は単に「JSON」と指定するのではなく、クライアントで使用するsing-boxのバージョンに合わせてください。

サブスクリプション変換の流れ：解析・マッピング・補完

変換ツールは通常、まず元データを読み込み、内部のノード形式に解析してから、変換先の設定形式で出力します。ノードリストにないプロキシグループ、ルール、DNS、リスナー設定などは、変換テンプレートで補われることがあります。そのため、変換結果はサブスクリプションの内容だけでなく、選択したテンプレートや変換ツールが対応するプロトコルのバージョンにも左右されます。

元の形式を判別する。完全な設定、ノードプロバイダー、プレーンテキストのURI一覧、またはBase64を先にデコードする必要があるデータのどれかを確認します。
プロトコルのパラメーターを解析する。サーバー、ポート、認証、トランスポート層、TLS、プロトコル固有のオプションを抽出します。
変換先の項目に割り当てる。ノードをClashのproxiesまたはsing-boxのoutboundsに書き込み、名前の参照関係も処理します。
実行可能な構成を生成する。テンプレートに基づいてプロキシグループ、ルーティング、DNSを作成し、最後に変換先のコアで設定を検証します。

たとえば、Clashノードのserverとportは、sing-boxでは通常serverとserver_portに対応します。ただし、キー名を置き換えるだけでは変換できません。プロキシグループの参照、TLSオブジェクト、トランスポート設定、ルールアクションの構造がそれぞれ異なります。

形式変換で失われやすい項目と動作上の違い

ノードをインポートできても、接続情報が完全とは限らない

サーバーとポートが正しいことは出発点にすぎません。TLSのサーバー名、証明書の検証設定、ALPNに加え、WebSocketのパスやHostヘッダーもハンドシェイクに影響します。Realityの公開鍵とshort ID、プロトコル固有のUDPオプションも、変換ツールが明示的に対応している必要があります。認識できない項目が黙って削除されると、設定の構文チェックには通っても接続できないことがあります。

認証とエンコード：パスワードやユーザー名に含まれる特殊文字は、URIのパーセントエンコードが必要な場合があります。重複してデコードすると元の値が変わることがあります。
トランスポート層：WebSocketやgRPCなどのトランスポート設定は、ノードの種類だけでなく各項目を個別にマッピングする必要があります。
TLS：サーバー名と検証ポリシーを維持してください。証明書エラーが出た場合は原因を調べ、検証を無効にする方法を一般的な変換対策として使わないでください。
UDP：ノードのプロトコル、サーバー側、使用するコアがそれぞれ対応している必要があります。形式を変換してもUDP対応が追加されるわけではありません。

ルール、DNS、TUNは名前だけで機械的に置き換えられない

Clashのproxy-groupsとsing-boxのセレクターやURLテスト用アウトバウンドは、完全に同じものではありません。どちらも「自動選択」が可能でも、テストURL、間隔、切り替え動作が異なる場合があります。ノード名を変更したら、プロキシグループやルール内の参照もすべて更新してください。更新しないと、アウトバウンドが見つからない、またはプロキシグループが空になることがあります。

Clashのrulesやルールプロバイダーを、sing-boxのルーティングルールやルールセットにそのまま貼り付けることもできません。ルールの順序、ドメイン照合の意味、最終的なフォールバック先を確認してください。DNSのFake-IP範囲、ドメインフィルター、名前解決に使うアウトバウンドも実際の通信に影響します。ノード数だけを比較しても、こうした違いは分かりません。

TUNはノードの属性というより、実行環境の設定です。macOSの仮想ネットワークインターフェースの許可、ルーティングの引き継ぎ、クライアントのサービスコンポーネントは、使用するクライアントが管理します。完全な設定から変換したTUN項目が構文上正しくても、Macクライアントでの許可が済んでいるとは限りません。まずローカルのプロキシリスナーが使えることを確認し、その後クライアントの手順に従ってTUNを有効にしてください。

Macでのインポートと動作確認の手順

使用するコアを確認してからサブスクリプション形式を選ぶ

クライアントの「バージョン情報」またはコア情報の画面で、コアの名称とバージョンを確認します。クライアントとコアのバージョンは分けて記録してください。画面の操作手順は実際に使うクライアントで確認します。
サービスのサブスクリプション管理画面で対応する形式を選びます。mihomo搭載クライアントでは、Clash Metaまたはmihomoと明記された項目を優先してください。
クライアントのサブスクリプションまたは設定画面でリモートURLを追加し、更新を実行してから、インポートした設定を選択します。メニュー名はクライアントによって異なります。
更新ログと設定チェックの結果を確認します。ノード数、失敗した項目、エラーの行番号を記録し、変換が必要か判断してください。

ファイル拡張子ではなく、使用するコアで設定を検証する

Macに対応するコマンドライン版のコアがインストールされている場合は、ターミナルで次のチェックを実行できます。コマンドは、現在のディレクトリにあるファイル名がconfig.yamlとconfig.jsonで、実行ファイルがPATHに追加されていることを前提としています。GUIクライアントに検証機能がある場合は、それを使っても構いません。検証のためだけにコアのファイルを置き換える必要はありません。

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

検証に成功しても、対象のコアが設定を受け付けたことを示すだけで、リモートノードへの接続、アカウントの有効性、ルールの妥当性までは保証されません。検証に失敗したら元の設定を保管し、最初に表示された具体的なエラーから修正してください。ノード、DNS、ルールを同時に変更すると、比較できなくなるため避けましょう。

クライアントに表示される実際の混合ポートが7890の場合、次のコマンドでHTTPプロキシを明示して、ローカルのリスナーとHTTPSアクセスを確認できます。このコマンドは、ターミナルがmacOSのシステムプロキシ設定を読み込んでいるかどうかに依存しません。

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com

テスト中はクライアントの接続ログも確認し、適用されたルールと最終的なアウトバウンドを確かめてください。HTTPレスポンスが返っても、必ずリモートノードを経由したとは限りません。DIRECTに一致した場合、通信は直結です。このコマンドではプロキシを明示しているため、TUNがターミナルの通信を引き継いでいるかどうかも確認できません。

よくあるインポートエラーと変換後のチェックリスト

「解析に失敗しました」「インポート後にノードが表示されない」

まず、レスポンスがHTMLのログインページやエラーメッセージではないか確認し、次に設定の階層を確認します。完全な設定用の入口にpayloadだけのルールファイルを渡す場合や、ノードプロバイダー用の入口に完全な設定を渡す場合は、インポートに失敗することがあります。YAMLではインデントを確認し、タブを使わないでください。JSONでは末尾のカンマや文字列の引用符を確認します。YAMLのテキストを.jsonにリネームして再インポートしないでください。

「ノード数は合っているのに、一部のノードに接続できない」

接続に失敗するノードを1つ選び、変換前後のプロトコル、ポート、TLS、トランスポート項目を比較します。特定のプロトコルだけでエラーが出る場合は、使用するコアと変換ツールがそのプロトコルに対応しているか確認してください。すべてのノードで同時に失敗する場合は、アカウントの状態、ローカルネットワーク、システム時刻、DNSを確認し、原因を形式だけに限定しないようにしましょう。

「手動で直しても、次回の更新で元に戻る」

リモートサブスクリプションを更新すると、設定が再生成または上書きされることがあります。ルール、プロキシグループ、DNSの変更を継続して使うには、クライアントが対応するオーバーライド、マージ、拡張機能を使うか、管理可能な変換テンプレートで設定してください。変更前にマージの順序と配列の処理方法を確認しましょう。独自ルールが最終フォールバックルールの後ろに追加され、適用されなくなることがあります。

元のサブスクリプションURLとレスポンスを保管し、変換後のファイルは別名で保存して、いつでも元に戻せるようにします。
ノード数、名前、プロキシグループからの参照を確認し、意図したフィルターと予期しない欠落を区別します。
リスナーのアドレス、実際のポート、LANからのアクセス設定、コントロールAPIの設定を確認します。
通常のHTTPS通信、必要なUDP通信、プロキシ経由と直結のルールをそれぞれ確認します。
サブスクリプションを1回更新し、独自設定が引き続き有効か確認します。

形式選びで重要なのは、「元の内容、変換ツール、変換先のコア」の3つを一致させることです。完全なClash YAMLと完全なsing-box JSONには実行ルールを含められますが、Base64ノードリストに含まれるのは通常、接続情報だけです。形式を変換するときは、ノードのマッピングとルールの再構築を別々に確認し、その後でmacOSのシステムプロキシやTUNによる通信の引き継ぎを設定してください。