V2Rayのサブスクリプション形式を解説：base64・ネイティブJSON・共有リンクの違いと変換

3種類の形式は同じ設定階層ではない

「サブスクリプション」はあらゆる設定ファイルの総称として扱われがちですが、厳密にはサブスクリプションは複数設定を配布する仕組み、共有リンクは単一ノードを持ち運ぶための表現、ネイティブJSONはコアが実行時に読み込む完全な設定です。共通するフィールドが含まれることはあっても、拡張子だけで同一のものと判断することはできません。

一般的なbase64サブスクリプションのレスポンスでは、まず複数のvmess、vlessなどの共有リンクを1行ずつ並べ、そのUTF-8テキスト全体をbase64エンコードします。クライアントは更新時にレスポンスをダウンロードしてテキストをデコードし、各行からノードを解析します。base64はテキストの表現方法を変えるだけで、暗号化を行うものではなく、プロトコルのフィールドを自動的に補完することもありません。

vmess共有リンク自体にも、base64のデータが含まれていることがよくあります。従来の形式では、vmess://の後にエンコードされたJSONオブジェクトを置き、アドレス、ポート、ユーザーID、トランスポート方式、TLS設定、備考などを記述します。ここでのbase64は単一ノードのオブジェクトにだけ適用され、「サブスクリプション全体を再度エンコードする」外側のbase64とは別の階層です。

vless共有リンクでは通常、URIのクエリパラメータで設定を直接表現します。サーバーアドレス、ポート、暗号化フラグ、トランスポート種別、TLSやREALITYのパラメータなどを指定できます。可読性の高いキーと値の形式に近い一方、パス、ホスト名、備考に含まれる特殊文字はURLエンコードが必要です。

base64・共有リンク・JSONを見分ける方法

形式を判断するときは、ファイル名だけでなく、デコード前後の最上位構造を確認してください。サブスクリプションAPIが.txtで終わっていてもbase64を返す場合があり、拡張子のないURLが共有リンクを1行ずつ直接返すこともあります。正しい手順は、レスポンスがテキストであることを確認し、プロトコルヘッダー、JSON構造、改行形式を調べることです。

1. まずプレーンテキストの接頭辞を確認します。vmess://またはvless://で始まる場合は、通常、単一ノードの共有リンクとして処理できます。
2. 次にJSONの最上位フィールドを確認します。inbounds、outbounds、routing、dnsが含まれている場合は、XrayまたはV2Flyコアのネイティブ設定に近い形式です。
3. デコード可能なテキストか確認します。内容の大半が英字、数字、プラス、スラッシュ、末尾のイコールで構成されている場合は、標準base64としてデコードしてみてください。その後、結果が1行ずつのリンクになっているか確認します。
4. レスポンスがWebページでラップされていないか確認します。先頭が<html、エラーメッセージ、ログインページになっている場合、取得したものはインポート可能なサブスクリプションデータではありません。

以下は、デコード後に現れる可能性がある1行ずつの構造です。例のドメインとユーザーIDはフィールドの位置を示すためだけのもので、接続には使用できません。

vless://[email protected]:443?encryption=none&security=tls&type=ws&host=edge.example.com&path=%2Fws#Example-VLESS
vmess://eyJ2IjoiMiIsInBzIjoiRXhhbXBsZS1WTWVzcyIsImFkZCI6Im5vZGUuZXhhbXBsZS5jb20iLCJwb3J0IjoiNDQzIn0=

1行目はそのまま読めるVLESS URIです。疑問符の前にユーザーID、サーバー、ポートがあり、疑問符の後にトランスポートとセキュリティのパラメータ、シャープ記号の後にノードの備考があります。2行目のVMessデータは、さらにもう一度デコードする必要があります。これは、外側のサブスクリプションエンコードと内側のノードエンコードが重なる場合があるためです。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443
          }
        ]
      }
    }
  ]
}

このJSONにはローカルのインバウンドとリモートのアウトバウンドという階層がすでに含まれているため、通常のサブスクリプションとして1行ずつ解析してはいけません。実行可能な完全設定にするには、有効なユーザーパラメータと一致するトランスポート設定も必要です。ここでは構造の見分け方だけを示しています。

v2rayN、v2rayNG、v2flyNGのインポートの違い

クライアントが特定のプロトコルに対応しているかどうかと、特定のテキスト形式を認識できるかどうかは別の問題です。サブスクリプションのデコードには成功しても、使用ノードのトランスポートやセキュリティ機能を現在のコアがサポートしていないため接続できない場合があります。切り分けでは、「解析に成功したか」と「コアで利用できるか」を分けて確認してください。

v2rayN 7.xの画面を例にすると、複数ノードのサブスクリプションは通常、「サブスクリプショングループ」→「サブスクリプショングループ設定」から追加します。URLを保存してメイン画面に戻り、サブスクリプションを更新します。単一の共有リンクはコピーしてから、クリップボードからサーバーをインポートする機能を使えます。インポート後は、ノード名だけでなく、アドレス、ポート、トランスポート種別、TLS、SNI、パスを確認してください。

v2rayNGはXrayコアを使用するため、このコアがサポートするVMess、VLESS、および関連するトランスポート設定のインポートに適しています。一般的な手順は、サブスクリプショングループ設定を開き、URLを追加して更新する方法です。単一リンクは、右上の追加メニューからクリップボード経由でインポートできます。v2rayNG 1.9.xでは、マイナーバージョンによってメニュー表記が多少異なる場合がありますが、サブスクリプショングループとクリップボードからのインポートは別々の入口です。

v2flyNGはV2Flyコアを使用するため、まずサーバー側でV2Fly互換と明示された設定をインポートしてください。サブスクリプションに他のコア固有のフィールドが混在している場合、リンクは読み込めても、接続時に未対応のトランスポートやセキュリティパラメータのエラーが出ることがあります。ノードの備考を変更したり未知のフィールドを削除したりしても、プロトコルの互換性は判断できません。

形式変換の可否と情報の損失

形式変換では、まず「エンコードの変換」と「プロトコルの変換」を区別する必要があります。base64をデコードして1行ずつの共有リンクに戻すだけなら、テキストを復元するだけでノードのプロトコルは変わりません。VLESSをVMessに書き換える場合は、サーバー側の認証とプロトコル実装が関係するため、リンクの接頭辞を置き換えるだけでは変換できません。

base64サブスクリプションをプレーンテキストのリンク一覧に変換する処理は、通常可逆です。UTF-8としてデコードした後、各行を保持して元の順序のままエンコードします。ただし、標準base64とURLセーフな変種では文字の扱いが異なるため、末尾のパディングを誤って削除するとデコードに失敗することがあります。

1. base64サブスクリプションを共有リンク一覧に変換：外側のテキストをデコードし、改行コードを統一して空行を削除した後、各行のプロトコルヘッダーを確認します。この処理でノードのフィールドが失われることは通常ありません。
2. 共有リンクをクライアントにインポート：クライアントが単一ノードのパラメータを解析し、対応するアウトバウンド設定をローカルで生成します。クライアント側のDNS、ルーティング、ログ設定は共有リンクには含まれません。
3. 共有リンクをネイティブJSONに変換：1つのアウトバウンドオブジェクトは生成できますが、完全な実行設定にするには、ローカルのインバウンド、DNS、ルーティング、ログ、ポリシーを追加する必要があります。
4. ネイティブJSONから共有リンクを抽出：構造が明確な単一アウトバウンドに限って利用できます。複数のアウトバウンド、負荷分散、ルーティングルール、DNSサーバー、ポリシーオブジェクトを通常の1本のリンクに完全に詰め込むことはできません。
5. VMessとVLESSの相互変換：サーバー側で両方のプロトコルの待受設定と認証パラメータが提供されている場合に限り、それぞれのリンクを生成できます。クライアント側だけで別のプロトコル設定を導き出すことはできません。

VLESS URIを変換するときは、クエリパラメータの大文字・小文字と値も維持してください。たとえばtype=ws、security=tls、sni=edge.example.com、path=%2Fwsは、それぞれトランスポート、セキュリティ層、サーバー名、パスを表します。重要なフィールドを1つでも欠落させると、ハンドシェイクに失敗したり、接続後に通信できなくなったりします。

VMessリンクのJSONフィールドには、歴史的に異なる表記方法があります。ポートが文字列の場合もあれば、数値として解析される場合もあります。処理時は、フィールド名だけで機械的に連結せず、まずクライアントが受け付ける構造で出力してください。インポートには成功したのにノードパラメータが空になる場合は、リンクを再度デコードし、アドレス、ポート、ユーザーID、トランスポート種別、TLSフィールドを1つずつ照合します。

サブスクリプション変換でよくある問題

サブスクリプションの更新失敗は、必ずしも形式の問題とは限りません。ネットワークのタイムアウト、URLが返すログインページ、レスポンスの途中切れ、文字コードの誤り、クライアントのコアとの非互換などでも、似たようなメッセージが表示されます。最も効果的な切り分けは、まずダウンロードした元の内容を確認し、その後にノード解析と接続テストへ進むことです。

サブスクリプションの更新がタイムアウトする場合は、まず動作確認済みのノードに接続し、更新リクエストが現在のプロキシ経由で許可されているか確認してください。v2rayNでは、ローカルの待受ポートが使用中でないかも確認します。一般的な設定ではSOCKSポートに10808、HTTPポートに10809を使いますが、実際の値は「設定」→「パラメータ設定」に表示される現在の設定を確認してください。

• レスポンスがHTMLタグで始まる：サブスクリプションURLがログインページまたはエラーページへリダイレクトされていないか確認してください。
• base64をデコードできない：コピー時に末尾の文字が欠落していないか、レスポンスが途中で切れていないか確認してください。
• ノードのインポート後にアドレスが空になる：VMess内部のJSONフィールドが完全か確認してください。
• VLESSのインポート後にハンドシェイクが失敗する：ポート、SNI、トランスポート種別、パス、セキュリティパラメータを確認してください。
• 更新後に重複ノードが現れる：複数のサブスクリプショングループが同じデータソースを参照していないか、備考の重複除去設定を確認してください。

管理しやすいサブスクリプションと設定の移行手順を作る

安定した移行手順では、元のサブスクリプションURL、デコード後のノード一覧、クライアントのローカル設定という3種類の情報を保持します。サブスクリプションURLは今後の更新に使い、ノード一覧は解析問題の特定に役立ちます。ローカル設定には、共有リンクでは移行されないシステムプロキシ、DNS、ルーティング、ポートなどが含まれます。

クライアントやコアを変更する前に、現在利用できるノードのプロトコル、サーバーポート、トランスポート種別、セキュリティパラメータを記録し、移行先のクライアントで同じサブスクリプションをインポートします。更新後すぐに全ノードをまとめて変更せず、まずVMessまたはVLESSのノードを1つ選び、遅延テストと実接続を行って、ログにプロトコルフィールドのエラーがないことを確認してください。

1. サブスクリプションURLの所属グループ、更新方法、直近で正常に更新できた日時を記録します。
2. 既知の動作確認済みリンクを1本取り出し、プロトコル、アドレス、ポート、ユーザーID、トランスポートパラメータを確認します。
3. 移行先のクライアントで新しいサブスクリプションを追加し、既存の利用可能なグループは上書きしません。
4. 手動更新を1回実行し、更新前後のノード数を記録します。
5. ノードを1つ選んでテストし、コアのログ、DNS解決、ローカルの待受ポートを確認します。
6. 接続が正常であることを確認してから、ルーティング、自動更新、システムプロキシの設定を復元します。

v2rayNとv2rayNGの間でノードを同期するだけなら、サブスクリプションURLを保持する方法を優先し、完全なJSONを何度もエクスポートする必要はありません。複雑なドメイン分岐、複数のアウトバウンド、カスタムDNSに依存する場合は、ノード移行とルーティング移行を2段階に分け、共有リンクにすべての動作が含まれていると誤解しないようにしてください。

最終的な判断基準は、ファイルを「インポート」できるかどうかではありません。フィールドが完全に解析されているか、現在のコアが対応しているか、接続ログが正常か、ローカルプロキシとルーティングが期待どおり機能しているかが重要です。まずデータ階層を見分け、対応するインポート方法を選ぶことで、サブスクリプション変換に関する問題の大半を減らせます。