V2Rayのサブスクリプション形式を比較：Base64、ネイティブJSON、共有リンクの変換方法

1. サブスクリプションURL・レスポンス内容・ノード形式

「V2Rayのサブスクリプション」は、すべてのクライアントで共通して使えるファイル規格ではありません。一般にサブスクリプションとはHTTPSのURLを指し、クライアントがそこへアクセスして複数のノードを取得し、サブスクリプショングループに保存します。URLにアクセストークンが含まれる場合もあります。追加できるかどうかを決めるのは、サーバーが返す内容とクライアントが対応する解析方式です。

サブスクリプションによってはリンク一覧をそのまま返すものもあれば、リクエストのパラメーターやクライアント識別情報に応じて形式を変えるものもあります。そのため、「拡張子がJSON」「ブラウザーで文字化けして見える」といった情報だけでは対応状況を判断できません。URLの名前ではなく、実際のレスポンスを確認しましょう。ログイン画面や期限切れの案内、エラーを示すJSONが返っている場合は、再エンコードしても有効なノードにはなりません。

2. Base64サブスクリプションとVMessの二重構造

一般的なBase64サブスクリプションは、複数の共有リンクを改行でつなぎ、全体をUTF-8テキストとしてBase64エンコードしてレスポンス本文に返します。クライアントは外側のエンコードを解除してから、各行のノードを解析します。Base64テキストの先頭に vmess:// を付けるだけではいけません。リスト全体が1つのVMessノードとして扱われてしまいます。

1. レスポンス本文を取得し、HTMLページやアクセス権限エラー、空の内容ではないことを確認します。
2. 本文がプロトコルのプレフィックス付きリンクで1行ずつ並んでいれば、平文のリンク一覧として扱います。
3. 本文がBase64なら外側をデコードし、結果が認識可能な共有リンクになっているか確認します。
4. ノードを1行ずつ解析します。vmess:// の場合は、仕様に沿って内部のペイロードもデコードします。

広く使われているVMess共有形式は、vmess:// にBase64エンコードされたJSONを続けたものです。ここでのJSONは共有形式のフィールドを表しており、V2FlyやXrayの完全な設定ではありません。以下はVMessリンクをデコードしたオブジェクトの例です。v の値 2 は共有形式のバージョンを示すもので、コアのバージョンではありません。

{
  "v": "2",
  "ps": "サンプルノード",
  "add": "example.com",
  "port": "443",
  "id": "0f3a10d2-7f3b-4b58-a3f6-9a6fcbec8431",
  "aid": "0",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "example.com",
  "path": "/ws",
  "tls": "tls",
  "sni": "example.com"
}

ドメイン名、UUID、パスは構造を説明するための例であり、そのまま接続には使えません。aid: "0" は現在のVMess AEADで一般的な設定です。古い解説にあるように64へ変更しないでください。scy はVMessのコンテンツ暗号化方式、tls はトランスポートのセキュリティ設定で、同じ項目ではありません。ジェネレーターによって数値・文字列の扱いや拡張フィールドに違いがある場合もあります。

• 外側のデコードエラー：サブスクリプション全体をデコードできない、またはデコード後の内容がノード一覧ではない。
• 内側のデコードエラー：一覧を展開できても、一部のVMessペイロードが有効なJSONではない。
• 文字化け：備考の日本語が文字化けする場合、UTF-8のバイト列を文字として直接扱っていることがよくあります。

3. VLESSリンクのクエリパラメーターとトランスポート設定

一般的なVLESS共有リンクは通常のURIに近い構造です。UUIDはユーザー情報、ホストとポートはアドレス部分に入り、トランスポートやセキュリティ、パスなどはクエリパラメーターで指定します。備考は # の後ろに置きます。以下はVLESS + WebSocket + TLSのサンプルリンクです。%2Fws をデコードすると /ws になります。

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

URIパラメーターに含まれる特殊文字は、正しくエスケープする必要があります。たとえばパスに & が含まれる場合は %26 にエンコードしてください。そうしないと、次のパラメーターとの区切りとして解釈されます。IPv6のホストは角括弧で囲みます。備考に日本語が含まれる場合は、パーセントエンコードするとクライアント間で引き継ぎやすくなります。備考だけの変更は通常接続に影響しませんが、パスやSNI、Hostを変えると実際のハンドシェイクに影響します。

4. ネイティブJSONをそのままサブスクリプションとして使えない理由

ネイティブ設定はコアを動作させるためのものです。複数のインバウンドやアウトバウンドに加え、DNS、ルーティング、ログの設定を含めることもできます。以下は階層構造を説明するVMess設定の例です。ローカルのSOCKSインバウンドは 127.0.0.1:10808 で待ち受け、リモートのアウトバウンドは example.com:443 に接続します。10808は説明用のローカルポートで、サブスクリプションURLのポートではなく、すべてのクライアントで共通の値でもありません。

{
  "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": "example.com",
            "port": 443,
            "users": [
              {
                "id": "0f3a10d2-7f3b-4b58-a3f6-9a6fcbec8431",
                "alterId": 0,
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        },
        "wsSettings": {
          "path": "/ws",
          "headers": {
            "Host": "example.com"
          }
        }
      }
    }
  ]
}

この例では settings.vnext にVMessサーバーのパラメーターを、streamSettings にトランスポートとセキュリティのパラメーターを設定します。VLESSはプロトコル設定の構造が異なるため、protocol を vmess から vless に変えるだけでは使えません。XrayとV2Flyの設定構文には共通部分もありますが、拡張機能やフィールドの変更は異なります。JSONの構文が正しくても、対象のコアで動作するとは限りません。

5. v2rayN・v2rayNG・v2flyNGのインポート対応範囲

クライアントはサブスクリプションの解析やノード管理を行い、実際の接続はコアが処理します。v2rayNは設定に応じて対応コアを利用するデスクトップクライアントです。v2rayNGはXrayコアを使うAndroidクライアント、v2flyNGはV2Flyコアを使うAndroidクライアントです。3つともVMessリンクを解析できるからといって、VLESSやREALITY、完全なJSON設定にも同じように対応しているとは限りません。

以下では、v2rayN 7.xの中国語UIで一般的なメニューを例に説明します。マイナーバージョンによってメニュー名が変わる場合があります。手元にあるのがサブスクリプションURLかノードのテキストかを先に見分けてから、対応するメニューを選ぶほうが、同じインポートボタンを何度も試すより効率的です。

1. 入力形式を見分ける

   HTTPSのサブスクリプションURLはサブスクリプショングループから追加します。vmess:// または vless:// で始まるテキストはノードとしてインポートします。inbounds、outbounds を含むJSONは、まず完全な設定として扱ってください。

2. サブスクリプションを追加

   「サブスクリプショングループ」→「サブスクリプショングループの設定」でグループを追加し、名前とサブスクリプションURLを入力します。保存後、「サブスクリプショングループ」から更新します。ネットワークの接続状況に応じて、プロキシ経由またはプロキシを使わない更新方法を選んでください。

3. 単一ノードをインポート

   リンク全体をコピーし、「サーバー」→「クリップボードから一括URLインポート」で読み込みます。複数のリンクは1行ずつ並べます。v2rayNGでは、メイン画面の「+」→「クリップボードからインポート」から同様に操作できます。

4. フィールドを確認

   ノードの編集画面を開き、サーバー、接続先ポート443、UUID、トランスポート、パス、Host、SNIを確認します。REALITYノードではノード名だけでなく、公開鍵、short ID、フィンガープリント、Flowも確認してください。

5. 接続を確認

   ノードを選んでテストし、ログを確認します。未対応のプロトコルやフィールドが表示される場合はコアを確認してください。アドレスや証明書、ハンドシェイクのエラーならノード設定を見直します。最後に必要なシステムプロキシまたはTUNモードを有効にします。

6. 形式の変換方法：更新を続けるか、スナップショットを書き出すか

共有リンクからBase64サブスクリプションへの変換は、リンクを並べてエンコードするだけです。Base64サブスクリプションから共有リンクへの変換は、デコードして行ごとに分けます。どちらも外側の形式を変えるだけで、VMessがVLESSに変わるわけでも、サーバーのパラメーターが自動で補われるわけでもありません。サブスクリプション提供元がノードを変更しても、ローカルに書き出したファイルには反映されません。

ローカルでのエンコード例：まずUTF-8のバイト列を扱う

以下は、一般的なBase64の処理を理解するための、ネイティブJavaScriptによるローカルエンコード・デコード関数です。ネットワークへのリクエスト、ノードの解析、ネイティブ設定の生成は行いません。入力には、有効であることを確認済みのリンク一覧を使ってください。運用中のサブスクリプションを、見知らぬWebサイトのコンソールに貼り付けないでください。

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

function decodeList(encoded) {
  let normalized = encoded.trim()
    .replace(/\s+/g, "")
    .replace(/-/g, "+")
    .replace(/_/g, "/");
  normalized += "=".repeat((4 - normalized.length % 4) % 4);
  const binary = atob(normalized);
  const bytes = Uint8Array.from(binary, char =>
    char.charCodeAt(0)
  );
  return new TextDecoder("utf-8", { fatal: true }).decode(bytes);
}

• エンコード前にノードを改行でつなぎ、URI同士が連結しないようにします。
• デコード関数は、一般的なURLセーフ文字への置換とパディングの欠落に対応します。不正な内容の場合はエラーになります。
• デコード結果が単一のJSONオブジェクトなら、それが共有用のペイロードか完全な設定かを確認してください。ノード一覧としてそのままインポートしてはいけません。
• ローカルのテキストを更新可能なサブスクリプションにするには、アクセス可能なサーバーを構築してアクセス権を管理する必要があります。エンコードだけではサブスクリプションURLは作成されません。

7. 形式変換とサブスクリプションの追加でよくある質問

最後に、次の3段階で確認します。まず取得したレスポンスの内容、次にクライアントが解析できるか、最後にコアが接続できるかを確認してください。クライアントのバージョン、使用中のコア、ノードのトランスポート、エラーログを記録しておくと、Base64の再エンコードを繰り返すより原因を特定しやすくなります。基本設定はクイックスタート、プロトコルやセキュリティ関連の項目はプロトコル詳解をご覧ください。