V2Rayのサブスクリプション形式を解説：Base64・JSON・共有リンクの変換方法

1. サブスクリプションURL・応答内容・プロトコルを区別する

一般にサブスクリプションリンクとは、HTTPSでデータを取得するためのURLです。クライアントがURLにアクセスし、サーバー一覧や設定テキストを取得して解析します。URLにアクセストークンが含まれることもありますが、URL自体がVMessやVLESSのプロトコルというわけではありません。末尾の文字列だけで応答形式を判断することもできません。同じURLでも、リクエストのパラメーターやクライアントの識別情報によって異なる内容が返る場合があります。

よくあるサーバー一覧は、vmess://やvless://で始まる共有リンクを複数並べたものです。1行に1つずつ記載したリストは、そのまま返すことも、全体をBase64でエンコードすることもできます。一方、JSON形式で応答するケースもあります。ただし、JSONとして解析できることは構文が正しいというだけで、クライアントがサーバー一覧として扱うのか、完全な設定として扱うのかは別の問題です。

2. Base64は表現方法を変えるだけで、プロトコルの機能は変わらない

Base64はバイト列を扱いやすいテキストに変換する方式であり、データを秘匿するものではありません。日本語を含む文字列は、まずUTF-8のバイト列に変換してからBase64にエンコードします。元に戻すときは、先にバイト列を復元し、その後UTF-8としてデコードします。日本語を含む文字列に対してブラウザーのbtoa()を直接実行すると、エラーになったり誤った結果になったりすることがあります。

標準Base64では+や/が使われ、末尾に=が付くことがあります。URLセーフ形式では前者が-と_に置き換わり、パディングが省略されることもあります。こうした違いに対応するクライアントもありますが、空白や欠落、余分な引用符まで自動で修正されるとは限りません。

• 外側のデコード：サブスクリプションの応答全体をデコードすると、通常は複数行の共有リンクになります。
• 内側のデコード：従来形式のVMess共有リンクは、vmess://の後にもBase64データがあり、デコードすると単一ノードのJSONになります。
• ここで止める：完全なURIの一覧、または構造が明確なJSONが確認できたら、まず内容を判別します。何度もデコードを繰り返す必要はありません。
• 失敗の兆候：応答がHTMLのログイン画面、エラーメッセージ、認証画面から始まる場合は、変換を続けるのではなく、まずサブスクリプションへのアクセスを確認してください。

3. VMess共有リンクのJSONとネイティブ設定は別の形式

従来形式のVMess共有リンクは通常、「vmess://にBase64エンコードしたJSONを続ける」形式です。以下は形式を説明するための例であり、接続可能なサーバー情報でも、コアで実行できる設定でもありません。ドメインには予約済みの例示用ドメインを使い、ポート443はTLSの例として記載しています。

{
  "v": "2",
  "ps": "形式の例",
  "add": "example.invalid",
  "port": "443",
  "id": "123e4567-e89b-42d3-a456-426614174000",
  "aid": "0",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "example.invalid",
  "path": "/edge",
  "tls": "tls",
  "sni": "example.invalid"
}

ここでのvは共有リンク形式の識別子で、クライアントのバージョンではありません。psはメモ、add、port、idはそれぞれアドレス、ポート、ユーザー識別情報に対応します。netは通信方式を表し、この例ではhostとpathがWebSocket用、sniがTLSのサーバー名に使われます。それぞれ役割が異なるため、値が同じでも同じフィールドとはみなせません。

ネイティブJSONには複数のアウトバウンドが定義され、ルーティングルールによって出口が選択される場合があります。そのうち1つのノードだけを書き出しても、DNS、振り分けルール、インバウンドの待ち受けアドレス、アウトバウンド間の経路などは通常引き継がれません。そのため「ネイティブJSONから共有リンクへの変換」は、接続情報の抽出にすぎず、完全な設定を可逆的に圧縮するものではありません。

4. ローカルで形式を変換する：まずテキストを処理し、次に設定の意味を確認

「共有リンク一覧をBase64に変換する」「Base64から一覧を復元する」といった処理は、ローカルで完結するエンコード操作です。以下のJavaScriptはテキスト処理関数を定義するだけで、ネットワークへのリクエストは行いません。自分で用意したローカルの空白ページで開発者ツールを使って実行してください。見知らぬサイトのコンソールに実際のサブスクリプション内容を貼り付けたり、提供元不明の変換スクリプトを実行したりしないでください。

function encodeUtf8Base64(text) {
  const bytes = new TextEncoder().encode(text);
  const binary = Array.from(bytes, byte =>
    String.fromCharCode(byte)
  ).join("");
  return btoa(binary);
}

function decodeUtf8Base64(input) {
  let text = input.trim()
    .replace(/\s+/g, "")
    .replace(/-/g, "+")
    .replace(/_/g, "/");

  if (!/^[A-Za-z0-9+/]*={0,2}$/.test(text)) {
    throw new Error("想定したBase64テキストではありません");
  }

  if (text.length % 4 === 1) {
    throw new Error("長さが不正です。コピーが完全か確認してください");
  }

  text += "=".repeat((4 - text.length % 4) % 4);
  const binary = atob(text);
  const bytes = Uint8Array.from(binary, char =>
    char.charCodeAt(0)
  );
  return new TextDecoder("utf-8", { fatal: true }).decode(bytes);
}

function packShareList(links) {
  return encodeUtf8Base64(links.join("\n"));
}

function makeClassicVmessLink(shareObject) {
  return "vmess://" + encodeUtf8Base64(JSON.stringify(shareObject));
}

// UTF-8の往復変換だけを確認し、実際のサブスクリプション認証情報は使わない。
const sample = "日本語のメモ\n2行目";
console.assert(
  decodeUtf8Base64(encodeUtf8Base64(sample)) === sample
);

1. リストを復元：応答テキストにdecodeUtf8Base64()を実行し、出力が本当に1行ずつの共有リンクになっているか確認します。この関数はプロトコルの判定や、破損した内容の修復は行いません。
2. リストをエンコード：完全なURIを1つずつ配列に入れ、packShareList()に渡します。各項目の区切りは改行です。複数のURIを区切りなしで連結してはいけません。
3. VMessリンクを生成：入力オブジェクトが従来形式のVMess共有フィールドに合致する場合に限り、makeClassicVmessLink()を使います。任意のネイティブ設定から正しいノードを自動生成する関数ではありません。
4. 結果を確認：まずクライアントにテスト用の項目として読み込み、アドレス、ポート、UUID、通信方式、TLS、サーバー名を1つずつ照合してから接続を試してください。

ネイティブ設定を共有リンクに変換するには、意味を理解したうえで変換する仕組みが必要です。書き出すアウトバウンドを選び、プロトコルと通信方式を判別してフィールドを対応付け、変換先の共有形式ですべてのパラメーターを表現できるか確認します。表現できないフィールドがあれば変換を中止するか、欠落項目を記録してください。無言で削除して変換成功とみなしてはいけません。

5. 3種類のクライアントで適切な読み込み方法を選ぶ

まず用途に合わせて選びます。継続的に更新するサーバー一覧にはサブスクリプション、単一ノードの一時的な移行には共有リンク、DNS、ルーティング、アウトバウンドを細かく制御する場合はネイティブJSONが適しています。クライアントの画面は読み込みや管理を担い、コアはプロトコルを実行します。それぞれの対応範囲を確認してください。

v2rayNはデスクトップ向け、v2rayNGはXrayコアを使うAndroidクライアント、v2flyNGはv2flyコアを使うAndroidクライアントです。VMess共有リンクは広く使われる交換形式ですが、通信方式や拡張パラメーターへの対応はバージョンによって異なります。特にXray向けの拡張設定が、v2flyコアでもそのまま動くとは限りません。

1. 元の設定を残す

   現在使えている項目と元の応答内容を先に保存してください。トラブル調査には独立したサブスクリプショングループを使い、サーバーをすべて削除するのは避けましょう。

2. デスクトップでサブスクリプションを追加

   v2rayNでは一般に「サブスクリプショングループ」→「サブスクリプショングループの設定」→「追加」の順に進み、メモとURLを入力して保存します。その後、「サブスクリプショングループ」メニューから更新します。プラットフォームやバージョンによって画面やボタンの表記が多少異なる場合があります。

3. Androidでサブスクリプションを追加

   v2rayNGでは通常、右上のメニュー「⋮」→「サブスクリプショングループの設定」→「+」の順に進みます。保存後、メイン画面に戻り、「⋮」→「サブスクリプションを更新」で項目を取得します。サブスクリプションURLをサーバーアドレス欄に入力しないでください。

4. 単一リンクで比較する

   v2rayNでは「サーバー」メニューからクリップボード経由の読み込みを選びます。v2rayNGでは通常、メイン画面の「+」→「クリップボードからインポート」を使います。同じ共有リンクを試すと、サブスクリプションの取得障害とノードの解析障害を切り分けられます。

5. コアの対応状況を確認

   v2flyNGでは、サブスクリプション設定またはクリップボードからの読み込み機能を使い、該当パラメーターがv2flyでサポートされているか確認します。ネイティブJSONは、そのバージョンで提供されているカスタム設定機能から読み込みます。サブスクリプションURLの欄に直接貼り付けてはいけません。

6. 読み込みに失敗したら、取得・解析・実行の段階ごとに確認

更新完了の表示から分かるのは、更新処理が最後まで進んだことだけです。すべての項目が正常に解析されたとは限りません。反対に、項目が一覧に表示されても、通信方式やTLSのパラメーターが正しいとは限りません。エラーが起きた段階を特定するほうが、エンコード方式を何度も変えるより効果的です。