V2Rayのサブスクリプション形式を解説：Base64、ネイティブJSON、共有リンクの相互変換

サブスクリプションURL・レスポンス本文・ノード設定を区別する

https://sub.example.com/list?token=demoのようなURLは、クライアントがコンテンツを取得するためのものです。URLだけでは、返される形式を判断できません。この記事に登場するドメイン、UUID、パラメーターは構造を示す例であり、接続には使えません。実際のサブスクリプションURLに含まれるトークンにはアクセス権限があるため、URLを共有するとノード一式が漏えいするおそれがあります。

従来のV2Rayサブスクリプションでは、複数の共有リンクを改行でつなぎ、テキスト全体をBase64でエンコードする形式が一般的です。エンコードせずリンク一覧を返すサービスや、クライアントのリクエストに応じて異なる内容を返すサービスもあります。そのため、ブラウザーで開いたときとクライアントで更新したときに、同じ内容が返るとは限りません。

v2rayNとv2rayNGのインポート方法

どちらのクライアントも、一般的なVMess・VLESS共有リンクや従来型のリンクサブスクリプションを管理できます。ただし、テキストを認識できても、対象コアがすべてのパラメーターに対応しているとは限りません。画面上の名称はバージョンによって異なるため、ここでは機能ごとに説明します。サブスクリプションURLを単一ノード用の入力欄に貼り付けないよう注意してください。

v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。JSONの構文が正しくても、両方のコアが含まれるセキュリティ機能や設定項目に対応しているとは限りません。特にVLESSやREALITYを組み合わせる場合は、形式を変換する前に対象コアの対応状況を確認してください。形式の変換によってプロトコルへの対応が追加されることはありません。

Base64サブスクリプションのデコード：まず外側を確認し、次に各行を見る

最初に、エラーページではなくレスポンス本文を取得できているか確認します。本文が<!DOCTYPE html>、ログイン案内、APIエラーなどで始まる場合、デコードするサブスクリプションではありません。ファイルの拡張子を変えたり、何度もインポートしたりしても、認証切れやサーバー側のエラーは解決できません。

1. レスポンス本文をローカルのテキストファイルに保存し、元の内容も残しておきます。コピー時に混入した説明文は削除し、URLをBase64の本文として扱わないでください。
2. 本文がすでにvmess://またはvless://で始まっている場合は、プレーンテキストのリンク一覧として扱い、本文全体をデコードしないでください。
3. 本文が長いエンコード文字列の場合は、外側のBase64を1回デコードし、改行で分割して空行を削除します。
4. 各行のプロトコルプレフィックスを確認します。行がvmess://で始まる場合、その後ろにVMess共有情報のエンコードが含まれることがあります。だからといって、サブスクリプション全体を何度もデコードする必要はありません。

以下のコードは、ローカルの空白ページで開いた開発者ツールのコンソールを使い、取得済みのテキストを処理するためのものです。サブスクリプションURLへのリクエストは行いません。まず関数を定義し、次にdecodeSubscription(prompt("サブスクリプションのレスポンス本文を貼り付け"))を実行します。信頼できないWebページのコンソールで、実際の認証情報を扱わないでください。

function decodeSubscription(input) {
  const raw = String(input ?? "").trim();
  if (!raw) throw new Error("本文が空です");
  if (/^(vmess|vless):\/\//i.test(raw)) return raw;

  let encoded = raw.replace(/\s/g, "")
    .replace(/-/g, "+").replace(/_/g, "/");
  if (!/^[A-Za-z0-9+/]*={0,2}$/.test(encoded)) {
    throw new Error("内容がBase64の文字規則に一致しません");
  }
  encoded = encoded.replace(/=+$/, "");
  if (encoded.length % 4 === 1) {
    throw new Error("エンコード長が不正です。すべてコピーできているか確認してください");
  }
  encoded += "=".repeat((4 - encoded.length % 4) % 4);
  const bytes = Uint8Array.from(atob(encoded), c => c.charCodeAt(0));
  return new TextDecoder("utf-8", { fatal: true }).decode(bytes);
}

共有リンクをBase64に変換：改行でつないでからエンコード

プレーンテキストのリンク一覧を従来型のBase64サブスクリプション本文にする手順は、「1行に1つのリンク → UTF-8バイト列 → Base64」です。生成されるのは静的な本文であり、更新可能なサブスクリプションサービスが自動で作られるわけではありません。結果をローカルファイルに保存しても、クライアントがアクセスできるサブスクリプションURLができたことにはなりません。

const link = "vless://[email protected]:443?encryption=none&security=tls&type=tcp&sni=node.example.com#Example-TLS";

function encodeSubscription(links) {
  const text = links.map(item => item.trim()).filter(Boolean).join("\n");
  const bytes = new TextEncoder().encode(text);
  let binary = "";
  for (const byte of bytes) binary += String.fromCharCode(byte);
  return btoa(binary);
}

const encoded = encodeSubscription([link]);
console.log(encoded);
console.log(decodeSubscription(encoded) === link);

日本語の備考もエンコード対象になるため、日本語を含む文字列にそのままbtoaを使うのは避けてください。先にTextEncoderでUTF-8バイト列へ変換すれば、扱える文字の範囲を超えるエラーを防げます。最後の往復比較でtrueが返れば、例のテキストがエンコード処理で変化していないことを確認できます。ノードに接続できるかどうかを検証するものではありません。

上記の数値はプロトコルのエンコード規則と設定例であり、速度測定の結果でも、すべてのクライアントバージョンの既定値でもありません。Base64は圧縮ではありません。末尾のパディングを除くと、エンコード後の長さは元のバイト数の約4/3、つまり約3分の1増えます。

共有リンクとネイティブJSON：項目の対応付けだけでは完全に移行できない

先ほどのVLESSリンクを例にすると、ホストとポートはアウトバウンドのサーバー設定、UUIDはユーザー設定に入り、security=tlsはTLS、sniはTLSのサーバー名に対応します。以下はXray形式の単一アウトバウンドオブジェクトであり、そのまま実行できる完全な設定ファイルではありません。完全な設定のoutbounds配列に追加する必要があります。

{
  "tag": "proxy",
  "protocol": "vless",
  "settings": {
    "vnext": [
      {
        "address": "node.example.com",
        "port": 443,
        "users": [
          {
            "id": "11111111-1111-4111-8111-111111111111",
            "encryption": "none"
          }
        ]
      }
    ]
  },
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "node.example.com"
    }
  }
}

実行可能な設定にするには、ローカルのインバウンド、アウトバウンドの選択、必要なルーティング設定も指定します。たとえば、ローカルのSOCKSリスナーが127.0.0.1:10808の場合、それを使うアプリにも同じアドレスとポートを設定します。リモート側の443をローカルのプロキシポートに設定してはいけません。両者は通信経路の別々の端にあります。

VMessでは、vmess://の後ろに共有オブジェクトをBase64エンコードして付ける形式が一般的です。オブジェクトのadd、port、id、net、pathなどは共有リンク用の項目であり、コアのネイティブ設定におけるトップレベル項目ではありません。デコードしたオブジェクトをそのまま実行設定として保存すると、構造が合わず失敗することがほとんどです。

変換後の確認：更新成功と接続成功を分けて確認する

サブスクリプションの更新成功は、クライアントが内容の一部または全部を取得・解析できたことを示すだけで、すべてのノードが使えるという意味ではありません。元のサブスクリプショングループを残し、変換結果は別のテスト用グループにインポートしましょう。まず1つのノードを確認してから、まとめて処理します。手動でエクスポートした静的リンクには、元のサブスクリプションの更新設定は引き継がれません。

1. レコードを確認：変換前後のノード数を比較し、空行、重複レコード、非対応プロトコルのスキップがないか確認します。
2. 項目を確認：ノードの編集画面で、アドレス、ポート、UUID、トランスポート、パス、SNI、セキュリティ方式を確認します。備考が同じかどうかだけで判断しないでください。
3. 動作を確認：テストするノードを選び、コアのログを確認します。設定の解析エラー、認証失敗、接続タイムアウトは、それぞれ分けて対処してください。
4. アプリの接続先を確認：システムプロキシまたはアプリのプロキシが、実際のローカルリスナーポートを参照していることを確認します。次に、テストリクエストが想定したアウトバウンドへ送られるよう、ルーティングを確認します。