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

3つの形式の違い：サブスクリプションは配布用、JSONは実行用

まず「取得先」と「取得した内容」を区別しましょう。サブスクリプションURLは通常、アクセス用の認証情報を含むHTTPS URLで、クライアントがアクセスして初めてノード情報を取得します。Base64形式はよく使われるレスポンス形式であり、プロキシプロトコルではありません。また、すべてのサブスクリプションが同じ方式でエンコードされているわけでもありません。URLそのものをBase64デコードしても、通常はノード情報を取得できません。

共有リンクが主に表すのは、アドレス、ポート、認証情報、通信方式、TLSパラメーターなどのリモート接続情報です。一方、完全なJSON設定には、ローカルの待ち受け設定、DNS、ルーティングルール、複数のアウトバウンドも含められます。そのため、ノードを共有リンクとしてエクスポートできても、実行設定全体をリンクに含められるとは限りません。

Base64のデコード：外側をデコードしてからプロトコルを確認

従来のBase64形式のサブスクリプションは、2層構造として考えられます。外側でリンク一覧全体をエンコードし、内側の各行はそれぞれの共有形式に従います。外側をデコードした結果にvmess://が現れるのは正常です。すべてのリンクに同じデコード方法を適用しないでください。

• VMessでよく使われる共有形式：vmess://の後ろにはBase64エンコードされたJSONが続き、add、port、id、net、tlsなどのフィールドが含まれます。
• VLESSでよく使われる共有形式：vless://の後ろはURI形式です。認証情報、ホスト、ポートはURIの本体に、通信パラメーターはクエリ文字列に記載されます。JSON全体をBase64エンコードした形式ではありません。
• 名前と文字コード：日本語の名前を正しく扱うにはUTF-8が必要です。URI内のパーセントエンコードとBase64は別々の方式です。
• エンコード形式の違い：URLセーフな文字-、_を使ったり、末尾の=を省略したりするデータもあります。デコード前に形式を正規化してください。

以下のJavaScriptは、UTF-8文字列をローカルでエンコード・デコードする例です。ノードを入力すると、エンコード結果は44K544O8になります。これは文字列のテストであり、接続可能なノード情報ではありません。実際のサブスクリプションを扱う場合は、信頼できるローカル環境だけで作業し、トークンを含むデータをオンライン変換サービスに送信しないでください。

function decodeBase64Utf8(input) {
  let value = input.trim().replace(/\s+/g, "")
    .replace(/-/g, "+").replace(/_/g, "/");
  value = value.padEnd(Math.ceil(value.length / 4) * 4, "=");
  const bytes = Uint8Array.from(atob(value), char => char.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);
}

console.log(encodeBase64Utf8("ノード"));       // 44K544O8
console.log(decodeBase64Utf8("44K544O8"));   // ノード

デコードに成功したということは、エンコードされた内容を読み取れたにすぎません。結果がログインページ、有効期限切れの案内、その他のHTMLなら、有効なノード一覧は取得できていません。さらにエンコードしたり拡張子を変更したりしても解決しないため、サブスクリプションURLとアクセス権限を確認してください。

v2rayNへのインポート：サブスクリプションURLとクリップボードを使い分ける

ノードを後から更新する場合は、サブスクリプショングループを追加します。共有リンクを1件または複数件だけ受け取った場合は、クリップボードからインポートします。以下ではv2rayNの中国語UIのメニュー名を記載しています。デスクトップ版ではボタンの位置や、括弧・スペースなどの表記が異なる場合があるため、実際のメニューを確認してください。

1. 入力内容を見分ける

   HTTPSの取得先URLはサブスクリプショングループに登録し、vmess://やvless://で始まるデータはノードとしてインポートします。完全なJSONをサブスクリプションURL欄に貼り付けないでください。

2. グループを追加

   「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、新しいグループを追加します。メモとサブスクリプションURLを入力して保存してください。URLのクエリパラメーターとアクセストークンは省略せずに保持します。

3. サブスクリプションを更新

   「サブスクリプショングループ」メニューから「すべてのサブスクリプションを更新（プロキシを使用しない）」を選択します。直接接続で失敗し、利用可能なプロキシ接続がある場合は、「すべてのサブスクリプションを更新（プロキシを使用）」を試し、更新ログで結果を確認してください。

4. リンクをインポート

   共有リンクをインポートするには、テキスト全体をコピーしてから「サーバー」→「クリップボードから一括URLをインポート」を開きます。複数のリンクは1行ずつ並べます。一般的なデスクトップUIでは、Ctrl+Vでもクリップボードからインポートできます。

5. パラメーターを確認

   インポートしたノードの編集画面を開き、アドレス、ポート、通信プロトコル、TLS設定を確認します。インポートできても接続できるとは限りません。続けてコアのログを確認し、未対応フィールドやハンドシェイクの失敗がないか調べてください。

Android版でも、サブスクリプションと共有リンクのインポート方法を使い分ける必要があります。v2rayNGはXrayコアを、v2flyNGはv2flyコアを使用します。同じリンク一覧を読み込めても、すべての通信パラメーターに両方のクライアントが対応しているとは限りません。特にVLESSとREALITYの組み合わせでは、Base64の外側を何度も変更するのではなく、対象クライアントとコアの対応状況を先に確認してください。

共有リンクとJSON設定：変換できる情報と失われる情報

共有リンクからJSONへの変換は、テキストを大括弧で囲むことではなく、フィールドを対応付ける処理です。クライアントがリンクを読み取り、ノード情報を作成して、選択したコア向けの実行設定を生成します。逆にエクスポートする場合、通常は特定のアウトバウンドに対応する接続パラメーターしか取り出せず、DNS、ルーティング、ローカルの待ち受け設定を含む構成全体を自動で持ち出すことはできません。

以下は構造を示すための設定例です。127.0.0.1:10808で待ち受けるSOCKSインバウンドと、直接接続するアウトバウンドのみを含み、リモートのプロキシサーバーは含まれていません。プロキシノードとしてインポートしないでください。完全なJSON設定には、VMessまたはVLESSのリンクに変換できるオブジェクトが含まれない場合もあることを示しています。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

設定全体を読み込む必要がある場合は、v2rayNの「サーバー」→「カスタム設定サーバーを追加」のような専用メニューを使い、画面に従って設定ファイルと対応するコアを選択してください。カスタム設定の待ち受けポートが既存のインスタンスと競合する場合があります。ログにアドレス使用中と表示されたら、ノードの認証情報を変更するのではなく、競合するインスタンスを停止するかポートを変更してください。

リンク一覧をサブスクリプション本文に再エンコード

共有リンクを複数件エクスポート済みなら、「1行に1リンク」の形式でテキストを作成し、UTF-8のテキスト全体をBase64エンコードできます。従来のサブスクリプション本文は作成できますが、自動更新できるサブスクリプションURLが生成されるわけではありません。作成した本文を返すには、信頼できるHTTPSサーバーが別途必要です。

1. 各リンクのプロトコルプレフィックス、クエリパラメーター、メモを残してください。TLSや通信関連のフィールドが重複して見えても、手動で削除しないでください。
2. 各リンクを改行コード\nでつなぎます。箇条書き記号、引用符、JSON配列の括弧、表の区切り文字は加えないでください。
3. テキスト全体を一度だけエンコードします。各共有リンクを個別にエンコードしてからつなぎ、認識できない一覧を作らないでください。
4. ローカルで一度デコードし、各行が元のテキストどおりに復元されることを確認してから、対象クライアントでインポートを試します。成功メッセージだけでなく、ノード数と重要なフィールドも確認してください。

完全なJSONからリンクを一括抽出する場合は、複数のアウトバウンド、タグ参照、通信フィールドのマッピングも処理する必要があります。対象の共有形式で表せないフィールドは、別途記録してください。変換ツールがリンクを出力しても、一部のシリアライズが完了したというだけで、元の設定と同じ動作になる保証はありません。

インポートできないときの対処：まず内容を確認し、次にコアを確認

トラブルシューティングは順番に進めます。まずサブスクリプションのリクエストで有効な本文を取得できるか確認し、次に共有リンクを解析できるか、最後に実行コアと接続パラメーターを確認します。「ダウンロード失敗」「形式未対応」「接続失敗」を分けて記録すれば、誤った段階で変換を繰り返さずに済みます。