サブスクリプション形式を詳しく解説：base64、ネイティブ JSON、共有リンクの違いと相互変換

3種類の形式は、それぞれ解決する課題が異なる

「サブスクリプション」は広い意味で使われがちですが、実際の内容は3つの階層に分かれます。base64統合サブスクリプションは複数の共有リンクをまとめたもの、VMessまたはVLESS共有リンクは通常1つの出力ノードだけを記述したもの、ネイティブJSONはインバウンド、アウトバウンド、DNS、ログ、ルーティング規則を含む完全な実行設定です。まず階層を見極めてからインポート方法を選ぶほうが、ボタンを何度も試すより確実です。

ブラウザーでサブスクリプションURLを開いたとき、長い英字や数字と少数のイコール記号が表示されても、内容が壊れているとは限りません。テキスト全体をbase64エンコードした結果の可能性があります。デコード後、各行が vmess:// または vless:// で始まっていれば、一般的な統合サブスクリプションです。ここでのエンコードはテキストを包むためのもので、暗号化ではなく、ノードのパラメーター自体も変わりません。

base64 統合サブスクリプションの内部構造

一般的な統合サブスクリプションの元のレスポンスは、base64テキストです。デコードすると通常はUTF-8テキストになり、各行に1つの共有リンクが置かれます。改行コードはLFまたはCRLFの場合があります。クライアントは更新時にURLへアクセスし、テキストをデコードしてから、プロトコルヘッダーに基づいて各行を解析します。認識できない行は通常スキップされるため、「更新は成功したのにノード数が0」という場合は、デコード後のプロトコルが現在のクライアントに対応していないか、サーバーがログインページや案内ページなどサブスクリプション以外の内容を返している可能性があります。

dmxlc3M6Ly9mNDdhZDQ4YS1hZWMxLTQwZTQtYTgzOC0wNjE2N2VhZDc4OTVA
ZXhhbXBsZS5pbnZhbGlkOjQ0Mz9lbmNyeXB0aW9uPW5vbmUmc2VjdXJpdHk9
dGxzJnR5cGU9d3MmcGF0aD0lMkZhcGkjVExTLVdTLUV4YW1wbGU=

上記は形式の例にすぎません。base64かどうかを判断するには、まず文字が主に A-Z、a-z、0-9、プラス、スラッシュ、イコールの範囲に収まっているか確認し、その後デコードします。文字の見た目だけでは有効性を判断できません。通常のランダムなテキストでも同じ範囲に入ることがあるためです。より確実なのは、デコード結果が読めるテキストか、各行に対応プロトコルのヘッダーがあるかを確認する方法です。

VMess共有リンク自体にもbase64エンコードが含まれることが多く、内部には通常、アドレス、ポート、ユーザー識別子、トランスポート方式、TLSパラメーターを記述したJSONオブジェクトがあります。そのため、VMess統合サブスクリプションでは、まず単一ノードのJSONをエンコードして vmess:// リンクを生成し、複数のリンクを連結してから全体をエンコードする場合があります。調査時は階層ごとに処理し、サブスクリプション全体を単一のVMessノードとして直接デコードしないでください。

VMess と VLESS の共有リンクはノードをどう表現するか

共有リンクの目的は、クライアントが1つのアウトバウンドノードを再構築できるようにすることです。VMessはプロトコルヘッダーの後にbase64エンコードされたJSONが続く形式が一般的です。VLESSは標準URIに近く、ユーザー識別子はユーザー情報部分、サーバーアドレスとポートはホスト部分、トランスポート・セキュリティ・フロー制御のパラメーターはクエリ文字列、ハッシュ以降のテキストはノード名として扱われます。どちらのリンクにも接続に必要な機密情報が含まれる可能性があるため、公開ページや公開ログに貼り付けないでください。

1. プロトコルヘッダーを読み取り、VMess用とVLESS用のどちらのパーサーを使うか決めます。
2. サーバーのドメイン、ポート、ユーザー識別子を取り出し、ポートが1〜65535の整数か確認します。
3. TCP、WebSocket、gRPCなどのトランスポート方式を読み取り、方式に応じてパスまたはサービス名を解析します。
4. TLS、サーバー名、アプリケーション層プロトコルのパラメーターを読み取り、アドレスとポートだけを移行しないようにします。
5. ノード名をデコードし、パーセントエンコードを処理してからサーバー一覧に表示します。

VLESS URI の構造例

以下の例では、解析できない予約ドメインを使用しています。重要なのは各フィールドの位置です。security=tls はトランスポートのセキュリティ設定、type=ws はWebSocket、path はリクエストパス、sni はTLSハンドシェイクで使用するサーバー名を表します。パラメーター名の大文字・小文字を区別するかどうかは、クライアントの実装に従ってください。不明なフィールドを手作業で書き換えることはおすすめしません。

vless://[email protected]:443?encryption=none&security=tls&sni=edge.example.invalid&type=ws&path=%2Fproxy#TLS-WS-Example

VMessとVLESSは、プロトコル名を置き換えるだけでは相互変換できません。認証モデルとパラメーターの構成が異なり、VLESSの flow などにはVMessへ直接対応する項目がありません。サーバー側が両方のインバウンド設定を提供している場合に限り、接続可能な共有リンクをそれぞれ生成できます。URIを書き換えるだけで、サーバーに別のプロトコル対応が追加されるわけではありません。

ネイティブ JSON とクライアントサブスクリプションの関係

ネイティブJSONはV2RayまたはXrayカーネル向けで、トップレベルには log、dns、inbounds、outbounds、routing などのフィールドがよく使われます。共有リンクから対応付けられるのは、多くの場合、特定の outbounds 項目だけです。JSONにドメイン、IP、ポート、インバウンドのタグに基づくルーティング規則が含まれていても、単一ノードのリンクに書き出すと元の動作は維持できません。

最小構成はサブスクリプションとは限らない

以下のJSONでは、ローカルSOCKSインバウンドとVLESSアウトバウンドを1つずつ定義しています。アウトバウンド部分を共有リンクに変換しても、待受アドレス 127.0.0.1、ポート 10808、ルーティング動作はリンクには入りません。移行先のクライアントは、自身のデフォルト値または既存の設定でこれらを補います。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.invalid",
            "port": 443,
            "users": [
              {
                "id": "f47ad48a-aec1-40e4-a838-06167ead7895",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    }
  ]
}

• inbounds は、ローカルのプログラムがトラフィックをどのようにカーネルへ渡すかを決めます。
• outbounds は、トラフィックがどのリモートプロトコルを経由するか、または直接接続で外へ出るかを決めます。
• routing は、ドメイン、IP、ポート、タグに基づいてアウトバウンドを選択します。
• dns は名前解決の方法を決めますが、ノードの共有パラメーターになるわけではありません。

クライアントが書き出したJSONには、プログラムが生成したタグ、統計ポリシー、特定カーネル向けのフィールドが含まれることもあります。別のクライアントへインポートする前に、移行先が採用するカーネルとバージョンでそれらのフィールドを認識できるか確認してください。v2rayNGはXrayカーネル、v2flyNGはv2flyカーネルを使用します。基本的なVMess、VLESS、一般的なトランスポートには共通部分がありますが、新しいフィールドや拡張機能まで完全に一致すると考えないでください。

インポート、変換、更新の実際の手順

日常利用では、手動でデコードして1件ずつインポートするより、クライアントにサブスクリプションURLを直接読み込ませる方法を優先してください。直接登録なら更新経路を維持でき、サーバー側でノード名、アドレス、ポートが変更されても、クライアントは一覧を再取得できます。手動変換は、内容の確認、少数ノードの移行、特定レコードの解析失敗の原因調査に適しています。

メニューの文言はクライアントのバージョンによって変わることがありますが、操作の流れはほぼ同じです。まずサブスクリプションURLを保存し、手動で更新してからノードを選択し、接続を開始します。テストでは「起動済み」と表示されるかだけでなく、コアログ、実際の遅延、目的のWebページへのアクセス結果も確認してください。遅延テストに失敗しても、ノードが完全に利用できないとは限りません。テスト先に到達できない、またはDNS解決に問題がある可能性もあります。

変換時に保持すべきフィールドと安全上の境界

信頼できる変換では、文字列の検索置換ではなく、まず構造化オブジェクトとして解析し、対象形式に合わせて再シリアライズします。少なくともプロトコル、サーバーアドレス、ポート、ユーザー識別子、トランスポート方式、TLSの状態、サーバー名、パスまたはサービス名、フロー制御パラメーター、ノード名を保持してください。接続に必要なフィールドが1つでも欠けると、「インポートはできるが接続できない」設定になる可能性があります。

1. 元の内容を管理されたローカル環境へコピーし、サブスクリプションレスポンス、共有リンク、完全なJSONのどれかを判定する。
2. デコードしてフィールドオブジェクトとして解析し、ポート、ユーザー識別子、必須パラメーターの型を確認する。
3. 対象クライアントとカーネルの機能に基づいて表現可能なフィールドを選別し、対応付けられない項目を記録する。
4. 対象形式を生成した後、もう一度解析し、アドレス、ポート、セキュリティ層、トランスポート層が一致しているか比較する。
5. クライアント内に独立したテストグループを作成し、まだ利用できる元のサブスクリプションを上書きしない。
6. 接続後にコアログを確認し、DNS、TCP、必要なUDPのケースを個別に検証する。

サブスクリプションURLと共有リンクには、アクセス認証情報が直接含まれている場合があります。スクリーンショットで問題を共有する際は、完全なサブスクリプションURL、ユーザー識別子、認証フィールドを隠してください。ログを共有する場合は、エラー種別、時刻、必要なネットワーク状態だけを残します。サブスクリプションURLが公開記録に入ってしまった場合は、サービス提供者の管理画面でサブスクリプション認証情報を変更し、クライアントから古いURLを削除して完全更新を1回実行してください。