V2Rayのサブスクリプション形式を解説：Base64リスト・JSON設定・vmess://リンクの変換

サブスクリプションURL・ノードリスト・JSON設定の違い

「V2Rayのサブスクリプション」は、単一のファイル形式を指す言葉ではありません。HTTPSのURLから返されるのは、Base64でエンコードされた共有リンクのリスト、プレーンテキストのリスト、完全なJSON、あるいはログインページの場合もあります。拡張子やURLに「subscribe」が含まれるかどうかでは内容を判断できません。クライアントが処理するのは、サーバーから返されたレスポンス本文です。

一般的なBase64形式のサブスクリプションは、2層構造になっています。まずリスト全体をエンコードし、デコードすると各行に共有リンクが並びます。その中に従来形式のJSONを使ったvmess://がある場合、プロトコル接頭辞の後に続くペイロードもBase64でエンコードされています。2つのエンコードは対象が異なるため、サブスクリプション全体を単一のVMessノードとして解析することはできません。

v2rayN・v2rayNGで使うインポート方法

まず内容に合ったインポート方法を選び、その後で変換を検討しましょう。HTTPSのサブスクリプションURLをクリップボードからノードとして読み込んだり、完全なJSONをサブスクリプションURL欄に入力したりしても、通常は期待どおりに処理されません。以下では一般的な日本語UIの名称を使っています。バージョンによってメニュー名が異なる場合があるため、項目名だけでなく機能を確認してください。

どちらのクライアントも、一般的な従来形式のJSON VMess共有リンクと、共有リンクリスト形式のサブスクリプションを処理できます。コアネイティブの完全なJSON設定は、カスタム設定のインポート方法を使ってください。「VMessに対応」とあっても、あらゆるJSON形式のサブスクリプションを使えるとは限りません。コア固有の項目を含む設定では、クライアントのバージョンと使用するコアの両方を確認する必要があります。

v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。画面だけが異なる、同一の設定解釈エンジンではありません。Xray専用の設定をv2flyNGで使う場合は、ファイル名を変更するだけでなく、プロトコルと各項目への対応状況を確認してください。v2rayNでは、その設定が実際にどのコアで実行されるかを確認する必要があります。

ローカルでデコード：まずリストを確認し、次にvmess://のペイロードを確認

以下のJavaScriptは、ローカルのブラウザーの開発者ツールでテキストを確認するためのものです。ネットワークリクエストは発生しません。コードを読んでから、ネットワークに接続していない空のページのコンソールで実行してください。関数が受け取るのは、すでにローカルにコピーした本文です。サブスクリプションのダウンロードは行いません。見知らぬWebサイトのコンソールで認証情報を処理しないでください。

function decodeBase64Utf8(input) {
  let text = input.trim().replace(/\s+/g, "");
  text = text.replace(/-/g, "+").replace(/_/g, "/");
  if (text.length % 4 === 1) {
    throw new Error("Base64の長さが不正です");
  }
  text = text.padEnd(Math.ceil(text.length / 4) * 4, "=");
  const bytes = Uint8Array.from(atob(text), ch => ch.charCodeAt(0));
  return new TextDecoder("utf-8", { fatal: true }).decode(bytes);
}

function encodeBase64Utf8(text) {
  const bytes = new TextEncoder().encode(text);
  let binary = "";
  for (const byte of bytes) binary += String.fromCharCode(byte);
  return btoa(binary);
}

function decodeVmessJson(uri) {
  const text = uri.trim();
  if (!text.startsWith("vmess://")) {
    throw new Error("VMess共有リンクではありません");
  }
  return JSON.parse(decodeBase64Utf8(text.slice(8)));
}

// ローカルのサンプルだけで自己テストし、サブスクリプションの認証情報は使用しません。
console.log(decodeBase64Utf8(encodeBase64Utf8("ノードのサンプル")));

1. レスポンスを確認：本文にvmess://などのプロトコル接頭辞が行ごとに並んでいる場合は、そのまま行単位で処理し、全体をデコードしないでください。先頭がHTMLタグやログイン案内の場合は、まずサブスクリプションのリクエストに関する問題を解決します。
2. 外側をデコード：Base64形式だと確認できたリスト本文にdecodeBase64Utf8を適用し、split(/\r?\n/)で行に分割して空行を除外します。
3. 共有リンクをデコード：従来形式のJSON VMessリンクをdecodeVmessJsonに渡します。add、port、idなどの項目を含むオブジェクトが返る想定です。
4. むやみに再試行しない：デコード結果がJSONでない場合は、共有形式の違いを確認してください。同じプロトコル接頭辞を使う過去の実装が、すべてこの記事で説明するJSONペイロードの仕様に従っているとは限りません。

atobが返すのはバイト列に対応する文字列であり、UTF-8のデコードまで行うわけではありません。TextDecoderを省略すると、ノード名などの日本語が文字化けすることがあります。日本語を直接btoaに渡すと、エラーになる場合もあります。また、Base64URLの-と_は、標準Base64の+と/とは区別が必要です。サブスクリプションURL自体にこれらの置換を適用しないでください。

vmess://とJSON設定の項目の対応関係

以下は説明用の従来形式VMess共有ペイロードです。ドメイン名とUUIDは構造の説明にのみ使用しており、接続可能なサービスを示すものではありません。vは共有形式のバージョンで、コアのバージョンではありません。aidはalterIdを表します。現行のVMess AEAD設定では通常0ですが、移行時はサーバー側の指定に従ってください。

{
  "v": "2",
  "ps": "サンプル VMess WS TLS",
  "add": "node.example.com",
  "port": "443",
  "id": "8a7e4f30-5b91-4f8e-9e42-2c6d1b0a73f5",
  "aid": "0",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "node.example.com",
  "path": "/gateway",
  "tls": "tls",
  "sni": "node.example.com"
}

以下の完全なサンプルでは、一般的なvnext構造を使い、ローカルSOCKSインバウンド1つとVMessアウトバウンド1つだけを示しています。クライアントにインポートしたときにインバウンド設定が維持されるかどうかは、カスタム設定の実行方式によって異なります。実行前に、使用中のコアがこの項目構造に対応しているかも確認してください。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "8a7e4f30-5b91-4f8e-9e42-2c6d1b0a73f5",
                "alterId": 0,
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "serverName": "node.example.com",
          "allowInsecure": false
        },
        "wsSettings": {
          "path": "/gateway",
          "headers": {
            "Host": "node.example.com"
          }
        }
      }
    }
  ]
}

再エンコードと逆変換：失われる情報に注意

従来形式のJSON VMessペイロードから共有リンクを作るには、JSONをUTF-8でエンコードし、プロトコル接頭辞を付けます。複数のリンクを改行で連結して全体をエンコードすると、一般的なBase64形式のリスト本文になります。以下のコードは前述のエンコード関数に続けて使用します。入力は説明用のサンプルです。

const sample = {
  v: "2",
  ps: "サンプル VMess WS TLS",
  add: "node.example.com",
  port: "443",
  id: "8a7e4f30-5b91-4f8e-9e42-2c6d1b0a73f5",
  aid: "0",
  scy: "auto",
  net: "ws",
  type: "none",
  host: "node.example.com",
  path: "/gateway",
  tls: "tls",
  sni: "node.example.com"
};

const share = "vmess://" + encodeBase64Utf8(JSON.stringify(sample));
const links = [share];
const subscriptionBody = encodeBase64Utf8(links.join("\n"));

console.log(share);
console.log(subscriptionBody);

リスト本文を生成しても、サブスクリプションサービスができるわけではありません。クライアントからアクセスできるURLに内容を置き、適切なアクセス制御を設定して初めて、更新可能なリモートの入口になります。端末間の移行だけであれば、クライアントから共有リンクをエクスポートして使えばよく、別途ファイルを公開する必要はありません。

• 完全な設定を単一ノードに変換すると、関連情報が失われます：DNS、ルーティングルール、ローカルの待ち受けポート、複数のアウトバウンドの関連付けやアウトバウンドチェーンは、一般的なVMess共有リンク1つでは完全に表現できません。
• JSONに複数のアウトバウンド候補が含まれることがあります：protocolとtagで対象のVMessアウトバウンドを特定してください。配列の先頭が共有したいノードだと決めつけないでください。
• 拡張トランスポートの設定をすべて保持できるとは限りません：追加のTLS設定やトランスポートパラメーターがある場合は、受信側が対応する共有項目を確認してください。エクスポート後、一時的にインポートして項目を1つずつ照合しましょう。
• プロトコルの変更はエンコード変換ではありません：接頭辞をVLESSやTrojanに書き換えても、VMessが別のノードに変わるわけではありません。サーバー側が対応するプロトコルと認証情報を提供している必要があります。

インポート失敗・ノード数が0・日本語の文字化けを解決する

確実に移行するには、元のサブスクリプション本文、デコード後のノード項目、インポート後のクライアント設定の3つを保存して比較できるようにします。検証ではまず1つのノードで接続を確認し、その後リスト全体に進みます。JSON設定のDNSやルーティングを移行する場合は、高度な設定を参考に項目を確認してください。項目の意味がわからない場合は、複数の変換ツールを試す前に用語集を確認すると、違いを見つけやすくなります。