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

この記事の要点

サブスクリプションURLは更新の入口、Base64はエンコード方式、共有リンクは個々のノード情報、コアのJSONは実行環境全体を記述するものです。「ブラウザーでは開けるのに、クライアントにはインポートできない」という場合は、まず内容を見分け、v2rayNまたはv2rayNGの適切なインポート方法を選びましょう。そのうえで、変換によってルーティング、DNS、トランスポート設定が失われないか確認します。

1. サブスクリプションURL、Base64、JSONはそれぞれ別のもの

「V2Rayのサブスクリプション」は、拡張子で決まる単一の形式ではありません。一般的には、クライアントがHTTPSのURLにアクセスしてテキストを取得し、ノードを解析して自身の設定リストに登録します。URLは取得と更新に使われ、解析方法を決めるのはレスポンス本文です。そのため、URLの末尾に拡張子がない場合も、.txtが付いている場合も、それだけではインポートできるか判断できません。

サブスクリプションURLとノードリスト

単一の共有リンク

vmess://やvless://などの接頭辞でプロトコルを識別でき、通常は1つのノードの接続情報が含まれています。インポート後は単独のコピーとなるため、サブスクリプションの更新機能は引き継がれません。

適した用途：一時的にノードを移行する場合や、接続パラメーターを個別に確認する場合。

コアのネイティブJSON

インバウンド、アウトバウンド、DNS、ルーティング、ログの設定などを記述できます。特定のコア向けの設定であり、GUIクライアントのノードリストやクライアントデータのバックアップとは異なります。

適した用途：複数のアウトバウンド、特殊なルーティング、コア設定全体を維持したい場合。

Base64に暗号化の効果はありません。サブスクリプションのトークンやノードの識別情報は、長い文字列に変換されていても復元できます。サブスクリプション本文全体を公開の変換サイトに送信しないでください。また、問い合わせ用のスクリーンショットにURLのクエリパラメーターを写さないようにしましょう。

2. vmess://とvless://の構造の違い

一般的なVMess共有形式は、vmess://の後にBase64エンコードされたJSONオブジェクトが続きます。このオブジェクトにはadd、port、id、net、tlsなどのフィールドが含まれることがありますが、あくまで共有形式のノード情報です。Xrayにそのまま渡して起動できる完全な設定ではありません。

確認項目	一般的なVMess共有形式	一般的なVLESS共有形式
基本構造	プロトコル接頭辞の後にBase64 JSON	URIのユーザー情報、ホスト、ポート、クエリパラメーター
ノードの識別情報	JSON内の`id`	URIで`@`より前にあるユーザー情報
トランスポート方式	よく使われるフィールド：`net`	よく使われるクエリパラメーター：`type`
TLSとサーバー名	よく使われるフィールド：`tls`、`sni`	よく使われるパラメーター：`security`、`sni`
備考	よく使われるフィールド：`ps`	`#`以降の部分。通常はパーセントエンコードされています

VLESSリンクは通常、リンク全体をもう一度Base64デコードする形式ではありません。パラメーターにflow、fp、pbk、sidが含まれる場合もあり、それぞれフロー制御、フィンガープリント、REALITYの設定に関係します。パラメーター名や対応範囲はクライアントのバージョンによって異なるため、プロトコル接頭辞だけで、すべてのパラメーターが使えるとは判断できません。

ポート：接続先ポートが443でも、TLSが有効とは限りません。セキュリティ層の設定も確認してください。
パス：WebSocketのパスに含まれる/は%2Fと表記されることがあります。URIの規則に沿ってデコードし、パーセント記号だけを単純に削除しないでください。
ドメイン名：サーバーアドレス、TLSのSNI、WebSocketのHostは別々の項目です。サーバー側で同じ値が求められる場合に限り、同じ値を設定してください。
改行：ノードリストは通常、1行につきリンク1つです。チャットツールが挿入した改行によって、クエリパラメーターが途中で切れることがあります。

3. Base64サブスクリプションのデコードと、二段階の解析が必要な場合

レスポンス本文が「複数のVMessリンクを並べたテキスト全体をBase64エンコードしたもの」だとします。1回目のデコードでリンクが1行ずつ並んだテキストが得られます。さらに各vmess://の後にあるデータを個別にデコードすると、ノードのフィールドを確認できます。これは2種類のエンコードが重なっているケースであり、すべてのサブスクリプションで必ず2回デコードするわけではありません。

まず元の内容を確認してください。すでにvmess://またはvless://で始まるリンクが1行ずつ並んでいる場合、全体をデコードする必要はありません。
Base64らしい文字列であれば、1回デコードしてリンクの一覧になるか確認します。
デコード後にHTMLタグ、ログイン画面、エラーメッセージが表示された場合は、取得方法を見直し、形式の変換は中止してください。
JSONが得られた場合は、フィールドの構造を確認してください。JSON配列、コア設定、APIのレスポンスは、構文が正しいというだけで互いに置き換えられるものではありません。

以下は、テキストをオフラインで処理するネイティブJavaScript関数です。エンコードとデコードのみを行い、ネットワークリクエストは送信しません。一般的なBase64URLの文字に対応し、中国語の備考もUTF-8で処理します。信頼できるローカル環境で使用し、内容を見知らぬページのコンソールに貼り付けないでください。

function decodeBase64Text(source) {
  const normalized = source.trim()
    .replace(/\s+/g, "")
    .replace(/-/g, "+")
    .replace(/_/g, "/");
  const padded = normalized.padEnd(
    Math.ceil(normalized.length / 4) * 4, "="
  );
  const bytes = Uint8Array.from(
    atob(padded), char => char.charCodeAt(0)
  );
  return new TextDecoder("utf-8", { fatal: true }).decode(bytes);
}

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

見分け方：デコード結果を確認してからインポート方法を選ぶ

結果が共有リンクの一覧なら、ノードリストとして扱います。inbounds、outboundsなどの実行設定フィールドが含まれている場合は、コア設定の構造をさらに確認してください。何度エンコードし直しても、エラーレスポンスは修復できず、不足しているプロトコルパラメーターも補えません。

4. v2rayNとv2rayNGのインポート方法

GUIクライアントでは通常、「サーバーノード」「サブスクリプショングループ」「カスタム完全設定」を分けて管理します。通常のノード用インポーターは共有リンクを認識し、サブスクリプション設定には更新URLを保存します。完全なJSONはカスタム設定から読み込みます。この3種類の内容をすべてサブスクリプションURL欄に貼り付けないでください。

インポート方法：内容に合わせてデスクトップ版・Android版の入口を選ぶ

デスクトップ版：v2rayN

共有リンクを1つまたは複数コピーし、「サーバー」→「クリップボードからURLを一括インポート」を選択します。
サブスクリプションURLは、「サブスクリプショングループ」→「サブスクリプショングループの設定」で追加し、サブスクリプションを更新します。
完全なJSONは、「サーバー」メニューにあるカスタム設定用サーバーの項目から読み込み、設定に合ったコアを選択します。

Android版：v2rayNG

共有リンクをインポートするには、右上の「+」→「クリップボードからインポート」をタップします。
サブスクリプションURLは、サイドメニューの「サブスクリプショングループの設定」でグループとURLを追加します。リストに戻り、「サブスクリプションを更新」を実行します。
完全なJSONは、「+」メニューにあるカスタム設定のインポート項目から読み込みます。通常のノードリンクとしてインポートしないでください。

ここでは一般的な画面上の名称を示しています。バージョンによって多少異なる場合があるため、現在のメニューにあるクリップボード、サブスクリプショングループ、カスタム設定の各機能を基準にしてください。

v2rayNGはXrayコアを使用し、v2flyNGはV2Flyコアを使用します。あるJSONがv2rayNGで動作しても、v2flyNGに移せばそのまま動作するとは限りません。特にREALITY、特定のトランスポート設定、コア固有のフィールドを使う場合は、移行先のコアが対応しているか先に確認してください。

5. 3種類の形式を変換する方法と、引き継げない情報

共有リンクとBase64サブスクリプションの変換では、通常、外側の形式だけが変わります。複数のリンクを改行でつなぎ、UTF-8でBase64エンコードすれば、よく使われる静的なサブスクリプション本文を作成できます。ただし、本文だけでは更新可能なサブスクリプションサービスにはなりません。クライアントが内容を取得するためのURLと、内容を継続的に管理する仕組みも必要です。

変換方向	変換方法	主な制限
Base64サブスクリプション → 共有リンク	全体を1回デコードし、リンクと改行をそのまま保持する	本文から元のサブスクリプショントークン、更新間隔、APIレスポンスヘッダーは復元できない
共有リンク → Base64本文	1行にリンクを1つ置き、UTF-8でエンコードしてから全体をBase64に変換する	静的な内容は元のサブスクリプションに合わせて自動更新されない
共有リンク → コアJSON	プロトコル、セキュリティ層、トランスポートのパラメーターを解析し、対応するアウトバウンドを生成する	実行環境としてインバウンド、ルーティング、DNSなどの設定も必要
完全なJSON → 共有リンク	表現可能なリモートアウトバウンドを1つ選び、パラメーターを個別に対応付ける	複数アウトバウンドの連携、ルールベースのルーティング、DNSポリシー全体は通常保持できない

JSONを変換するとき、サーバー、ポート、識別情報だけを抜き出せばよいわけではありません。たとえばWebSocketとTLSを使う場合は、トランスポートの種類、パス、Host、TLSの有効・無効、SNIを確認します。VLESSとREALITYを組み合わせる場合は、公開鍵、ショートID、関連するフロー制御パラメーターも確認が必要です。項目が1つでも欠けると、クライアント上では「インポート成功」と表示されても接続に失敗することがあります。

まず入力形式を確認：共有形式のVMess JSONと、コアのoutbounds内にあるオブジェクトは、同じフィールド構成ではありません。
次に変換対象を選択：完全設定にリモートアウトバウンドが複数ある場合は、どれをエクスポートするか明確にします。directやblockのアウトバウンドをノードとして扱わないでください。
項目ごとに照合：移行先のクライアントにインポートした後、編集画面を開き、セキュリティ層、トランスポートのパス、プロトコル固有のフィールドを確認します。
最後に動作確認：まずコアが起動することを確認してから、リクエストをテストします。ノードが使えても、元の設定のルーティング動作が復元されたとは限りません。

移行のポイント：ルーティングを維持するなら、完全設定を優先して保持

サーバーリストの移行だけが目的なら、共有リンクを使えます。元のDNSやルーティング動作を再現したい場合は、完全なJSONを保持し、移行先のコアで互換性を確認してください。共有リンクを設定全体のバックアップとして扱わないでください。

6. サブスクリプションと変換に関するよくある質問

ブラウザーではサブスクリプションを開けるのに、クライアントにはノードが表示されないのはなぜですか？

まず、レスポンスが本当にリンク一覧、またはそのBase64形式か確認してください。ブラウザーではログイン状態が使われていても、クライアントが受け取るのはログインページということがあります。サーバーがリクエスト情報に応じて異なる内容を返す場合もあります。サブスクリプショングループのURLが正しいか確認し、サービス提供元が案内する形式が対象クライアントに対応しているか確かめてください。

デコード後に日本語の備考が文字化けしました。そのままインポートできますか？

UTF-8でデコードし、atob()の結果をそのまま日本語文字列として扱わないでください。備考だけが壊れている場合、接続情報には問題がない可能性もありますが、元の内容を再確認してください。パスやクエリパラメーターも壊れている場合はインポートを中止し、誤った設定で接続を試さないでください。

完全なJSONの構文は正しいのに、起動に失敗するのはなぜですか？

JSONの構文チェックで確認できるのは、引用符やカンマなどの構造だけです。次にコアのログでエラーが示すフィールドのパスを確認し、移行先のコアが対応していないフィールド、実行に必要な設定の不足、ローカルのリッスンポートの競合がないか調べてください。起動エラーをBase64の再エンコードで解決しようとしないでください。

サブスクリプションを共有リンクに変換したら、ノードが自動更新されなくなったのはなぜですか？

クリップボードからのインポートでは通常、現在のノードのコピーが作成されるだけで、取得元のサブスクリプションURLは引き継がれません。継続して更新するには、「サブスクリプショングループの設定」に元のサブスクリプションURLを保存し、そのグループから更新してください。グループ内のノードを手動で編集する場合は、次回の更新で変更が上書きされる可能性も考慮しましょう。

形式を変換すれば、古いコアでも新しいパラメーターを使えるようになりますか？

いいえ。変換で変えられるのは表現方法だけで、コアの機能が増えるわけではありません。クライアントとコアの実際のバージョンを確認し、移行先が対象のプロトコル、セキュリティ層、トランスポート方式に対応しているか調べてください。不明なフィールドがある場合は、互換性のあるバージョンに更新するか、サービス提供元から互換設定を入手しましょう。重要なパラメーターを安易に削除しないでください。

実際の作業手順は、取得した内容を確認し、適切なインポート方法を選び、プロトコルのパラメーターとコアのログを確認する、という流れにできます。「取得失敗」「形式の不一致」「接続設定の誤り」を分けて対処すると、エンコード方式を次々に変えるよりも問題を特定しやすくなります。