2026年6月8日 · サブスクリプション管理 · 約12分

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

3種類の代表的なサブスクリプション形式について、構造と対応クライアントを整理。base64形式のサブスクリプション、ネイティブJSON設定、vmess://共有リンクを変換する考え方と注意点を解説します。

この記事の概要

サブスクリプションの内容確認、単一ノードの移行、インポート失敗の切り分けが必要な方に向けた記事です。読み終える頃には、エンコードの入れ物、共有リンク、コア設定という3層の構造を区別し、フィールド対応を確認しながら安全に変換できるようになります。

まずエンコード、ノード、実行設定を区別する

「V2Rayのサブスクリプション」は、厳密に統一されたファイル形式ではありません。実際には、複数行の共有リンクを返すURLを指すこともあれば、デコード済みのノード一覧、あるいはV2FlyやXrayコアがそのまま読み込めるJSON設定を指すこともあります。どれもサーバー情報を含みますが、用途と情報量はそれぞれ異なります。

base64はエンコード方式であり、プロトコルではありません。テキストを転送しやすい文字列に変換するだけで、サーバーの検証、トランスポートパラメータの補完、ルーティングルールの生成を自動で行うものではありません。一般的なサブスクリプションのレスポンスは、改行で区切られた vmess://、vless://、trojan:// リンクを内側に含み、それ全体をbase64でエンコードします。

共有リンクは1つのアウトバウンドノードを表します。通常はサーバーアドレス、ポート、ユーザー識別子、トランスポート方式、TLSパラメータ、備考などを含みます。一方、ネイティブJSONはコアの実行を前提としており、アウトバウンドだけでなく、インバウンドの待受、DNS、ログ、ルーティングルール、ポリシー設定まで含む場合があります。そのため、JSONから共有リンクへ変換すると、元の設定のうち1つのアウトバウンドしか残せないことが多く、逆方向の変換でも元のルール一式を自動的に復元することはできません。

base64サブスクリプション

おすすめ

複数のノードをまとめて配布するのに適しており、クライアントはサブスクリプションURLから定期的に更新できます。デコード後は通常、1行につき1つの共有リンクが並ぶテキストになります。

用途：日常的なサブスクリプション更新、複数ノードのグループ管理

単一の共有リンク

1つのノードをコピーして別の端末へインポートしやすく、対象ノードのアウトバウンド接続パラメータに情報が集約されています。

用途：単一ノードの移行、パラメータの項目別確認

ネイティブJSON

コア設定のツリー構造を直接表現でき、複数のインバウンド、アウトバウンド、DNS、ルーティングルールを格納できます。3形式の中で最も完全な構造です。

用途：高度なルーティング、コア設定の手動管理

結論：外側を判定してから内側を解析する

長い文字列を見ても、何度も連続してデコードしないでください。まずレスポンスがJSON、平文のリンク一覧、base64テキストのどれかを判定し、変換を1層終えるたびに有効なプロトコルヘッダーが現れたか確認します。

base64サブスクリプションの中身

典型的なサブスクリプションサービスはプレーンテキストを返します。クライアントはレスポンス前後の空白を除去して1回だけbase64デコードし、\n または \r\n で分割します。空行は無視し、空でない各行をプロトコルヘッダーに応じて対応するパーサーへ渡します。デコード結果が左中括弧で始まる場合はJSONの可能性があるため、リンク一覧として分割し続けないでください。

標準base64では、大文字・小文字の英字、数字、プラス記号、スラッシュを使用し、末尾にパディングのイコール記号が付くことがあります。URLセーフ版では、プラス記号とスラッシュがハイフンとアンダースコアに置き換わります。一部のサブスクリプションでは末尾のパディングを省略するため、パーサーは長さに応じて補完する必要がありますが、中間の文字を変更してはいけません。UTF-8のバイトオーダーマーク、レスポンス前後の案内文、HTMLのエラーページもデコード失敗の原因になります。

外側のサブスクリプションレスポンス
        ↓ base64を1回デコード
vmess://エンコード済みノード情報
vless://ユーザー識別子@edge.example:443?encryption=none&security=tls&type=ws#サンプルノード
trojan://認証情報@edge.example:443?security=tls&type=tcp#予備ノード
        ↓ 行ごとにプロトコルを判定
ノード1、ノード2、ノード3

内容が本当にサブスクリプションかどうかを、文字がbase64の文字集合に合っているかだけで判断してはいけません。短い英字や数字列、通常のテキストでも偶然条件を満たすことがあります。より確実なのは、デコード後のUTF-8テキストに対応プロトコルのヘッダーが含まれているか、期待どおりの構造を持つJSONが得られるかを確認する方法です。サーバーのレスポンスステータスも確認してください。たとえばHTTP 200なら解析に進み、301や302はクライアントの方針に従ってリダイレクトを処理し、401や403なら通常はURLの認証情報またはアクセス条件が変わっています。

よくあるレスポンスの特徴

VMessとVLESSの共有リンクにおけるフィールドの違い

vmess:// では、ノードのJSONオブジェクト全体をエンコードし、プロトコルヘッダーの後ろに置く形式が一般的です。デコード後のオブジェクトには、バージョン、備考、サーバーアドレス、ポート、ユーザー識別子、トランスポート方式、偽装タイプ、パス、TLS、SNIなどのフィールドが含まれます。歴史的な実装ではフィールド名が短く、たとえば add はアドレス、port はポート、id はユーザー識別子を表します。

vless:// は標準URLに近い形式です。ユーザー識別子はユーザー名の位置、ホストとポートはauthority部分、トランスポートとセキュリティのパラメータはクエリ文字列、備考はハッシュ記号の後ろに置かれます。解析時はまずURLのパーセントデコードを行い、クエリパラメータと備考を区別する必要があります。443 ポートはTLS接続でよく使われ、80 ポートはTLSを有効にしていないHTTPまたはWebSocketの入口でよく使われますが、ポート番号だけでセキュリティ層の有効・無効を判断することはできません。

接続情報 VMessの代表的なフィールド VLESS URL内の位置 変換時の注意点
サーバーアドレス add ホスト部分 ドメイン名とIPv6アドレスでは記法が異なります。IPv6では角括弧の意味を維持してください。
ポート port ホストの後ろにあるポート 1〜65535の整数に変換する必要があります
ユーザー識別子 id ユーザー名部分 既存の値だけをコピーし、備考やサーバーアドレスから推測してはいけません
トランスポート方式 net type パラメータ WebSocket、TCP、gRPCでは追加フィールドがそれぞれ異なります
パスまたはサービス名 path path または serviceName スラッシュ、スペース、特殊文字は正しくエンコードする必要があります
サーバー名 sni sni パラメータ 接続先アドレスと同じとは限りません
備考 ps ハッシュ記号の後ろにあるfragment 表示名だけに影響し、接続の確立には使われません

VMessリンクでは、生成元によってブール値が文字列になったり、ポートが数値または文字列になったりします。変換ツールはまず型を正規化し、その後に出力形式へ変換してください。VLESSリンクでは、重複したクエリパラメータ、パラメータの大文字・小文字、パーセントエンコードも処理する必要があります。未知のパラメータは黙って破棄せず、拡張フィールドに元のまま保持するのが安全です。

結論：プロトコル名が同じでもパラメータが同じとは限らない

変換時は少なくとも、アドレス、ポート、ユーザー識別子、トランスポート方式、セキュリティ層、SNI、パスの7項目を確認してください。最初の3項目だけをコピーすると、インポートはできても接続できないノードになりがちです。

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

コアJSONは完全な実行設定です。一般的なデスクトップ設定では、ループバックアドレスでポート 10808 を待ち受けるローカルインバウンドを定義し、1つ以上のアウトバウンドを設定します。ルーティングはドメイン、IP、インバウンドタグなどに基づいてアウトバウンドを選び、DNS設定は名前解決の方法を決めます。共有リンクにはこの関係全体を表すだけの情報量がないため、クライアントは通常、自身のデフォルトインバウンドとルーティングテンプレートを使用します。

次の構造はフィールド階層のみを示したもので、説明文を含むまま接続に使える設定ではありません。同じアウトバウンドノードでも、ネイティブJSONでは outbounds に組み込む必要があり、ローカルプロキシのポートは inbounds に置かれます。この2つを混同しないでください。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "edge.example",
            "port": 443,
            "users": [
              {
                "id": "サービス提供元から割り当てられたユーザー識別子",
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/gateway"
        }
      }
    }
  ]
}

ネイティブJSONからVMess共有リンクを生成する場合は、まず対象のアウトバウンドを選び、settings.vnext からサーバーとユーザー情報を読み取り、最後に streamSettings をトランスポートの各フィールドへ対応付けます。1つのアウトバウンドに複数のサーバーまたはユーザーが含まれる場合は、複数のリンクへ展開する必要があります。JSONへ逆変換する場合、クライアント側でローカルインバウンド、ログ、ルーティングのデフォルト値も補う必要があります。

変換で失われやすい情報

サブスクリプションを共有リンクへ変換する手順

信頼できる変換では、テキストを何度も試行的にデコードせず、層ごとに処理します。まず元のレスポンスを保存し、Content-Typeと文字コードを記録してから外側を判定します。解析後はノードの共通フィールドモデルを作成し、最後に出力形式ごとの変換器でVMess、VLESSリンク、コアJSONを生成します。取得、デコード、フィールド解析、出力のどの段階でエラーが起きたかを特定しやすくなります。

  1. レスポンスを確認する

    リクエストがHTTP 200を返し、ログインページやエラーページではないことを確認します。改行、JSONの開始記号、認識可能なプロトコルヘッダーが含まれているかも記録してください。

  2. 外側をデコードする

    内容がエンコード済みサブスクリプションの特徴を示す場合に限り、base64を1回だけデコードします。標準文字セットとURLセーフ文字セットの両方に対応し、結果はUTF-8として読み取ります。

  3. ノードを分割する

    CRLFまたはLFで行に分け、空白行を削除します。各行を vmess://、vless://、trojan:// に応じて対応するパーサーへ振り分けます。

  4. フィールドを正規化する

    ポートを整数へ変換し、トランスポート名を統一します。アドレス、ユーザー識別子、TLS、SNI、パス、備考を個別に保存し、未知のフィールドは別途保持します。

  5. インポートして検証する

    v2rayNで「設定」→「パラメータ設定」→「Core タイプ」を開き、選択したコアが対象プロトコルに対応していることを確認します。その後、新しいグループへインポートしてコアのログを確認します。

検証では「インポート成功」だけを見てはいけません。成功表示は、クライアントが構文を受け入れたことを意味するだけです。ノード詳細のサーバー、ポート、トランスポートパラメータを確認し、起動後のログでDNS失敗、TLS名の不一致、パスエラー、ポート競合がないか確認してください。ローカルポートに 10808 を使う場合は、別のプロセスが同じ待受ポートを使用していないことも確認します。

自動化に適したチェック項目

  1. サブスクリプションのレスポンスサイズが妥当か。空のレスポンスなら解析を直ちに停止する。
  2. デコード結果が有効なUTF-8か。異常なバイトが別の文字コードに由来していないか。
  3. 各ノードのポートが1〜65535の範囲にあるか。
  4. TLSを有効にした場合、SNIまたは対応するサーバー名が保持されているか。
  5. WebSocketのパスがスラッシュで始まっているか。クエリパラメータが二重にエンコードされていないか。
  6. ノードの備考がURLデコードされているか。同時に、備考が接続フィールドを上書きしていないか。

v2rayN、v2rayNG、v2flyNGにインポートする

v2rayNはデスクトップ環境でサブスクリプショングループを管理するのに適しています。サブスクリプションURLを追加して更新すると、クライアントがノード一覧を取得・解析します。単一の共有リンクだけを持っている場合は、クリップボードからインポートする入口を利用できます。バージョンによってメニューの表記は多少異なりますが、サブスクリプショングループを作成し、グループを更新し、最後にノードを選択してシステムプロキシを有効にするという順序は変わりません。

v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。どちらも一般的なVMessサブスクリプションや共有リンクを処理できますが、特定のプロトコル拡張が使えるかどうかはコアの対応状況によって決まります。リンクを解析できても起動時に未知のトランスポートやセキュリティタイプが表示される場合は、base64の内容を変更し続けるのではなく、必要なコア機能を確認してください。

サブスクリプションURLを貼り付けてもノードが表示されない？

まずクライアントログでHTTPステータスを確認します。200が返っている場合は、デコード結果にプロトコルヘッダーが行単位で並んでいるか確認してください。JSONオブジェクトが返っている場合は、対応するインポート方法を使用します。

なぜ1回デコードしても文字化けする？

テキストがURLセーフbase64か確認し、末尾のイコール記号を補完してください。それでも失敗する場合は、案内文、UTF-8のバイトオーダーマーク、HTMLエラー内容がレスポンスに混入していないか確認します。

ノードのインポートは成功したのに接続できない？

ポート、トランスポート方式、TLS、SNI、パスを1項目ずつ確認し、コアのログも確認してください。WebSocketのパスのスラッシュが1つ足りない、またはSNIが欠落しているだけでも、数秒以内にハンドシェイクが失敗することがあります。

サブスクリプションを更新すると手動の備考は上書きされる？

多くのクライアントは、サブスクリプションの内容に基づいてグループを再構築するため、手動で変更した名前が置き換えられることがあります。長期的に残したいノードは独立したグループへコピーし、元のサブスクリプションとの関係を記録しておきましょう。

ネイティブJSONをサブスクリプション欄へ直接インポートできる？

通常はできません。サブスクリプション欄はURLまたはノード一覧を想定しています。コアJSONはクライアントが提供するカスタム設定の入口から読み込み、インバウンドポート、ルーティング、DNS設定を別途確認してください。

v2rayNでコアの選択を確認する場合は、「設定」→「パラメータ設定」→「Core タイプ」を開いて現在の設定を確認できます。サブスクリプション更新後に一覧が変わらない場合は、まず正しいグループを更新しているか確認し、その後ログのタイムスタンプを確認します。モバイル端末でインポートする前には、クリップボードの内容が完全か確認してください。長いリンクがチャットツールで途中切れになると、末尾の備考は残っているように見えても、途中のクエリパラメータが欠落していることがあります。

インポート後に行う4つの検証

変換の限界とメンテナンスのすすめ

サブスクリプション変換の目的は、接続パラメータの一致を保つことであり、見た目だけ似たリンクを作ることではありません。ツールが認識できないフィールドは、削除して出力を続けるより、元のデータを保持して明確に通知する方が信頼できます。特にトランスポート層の拡張やセキュリティパラメータは、欠落しても構文上正しいリンクを生成できてしまいますが、接続結果はすでに異なります。

サブスクリプションURLは通常、更新の入口として機能します。一度取得したノードを静的な共有リンクとして書き出しても、そのリンクが後からサーバー、ポート、ユーザー情報の変更を自動取得することはありません。長期利用では元のサブスクリプショングループを残し、静的リンクは一時的な移行やパラメータ分析に使うのが適しています。

ネイティブJSONは、検証済みのルーティングやインバウンド設定の保存に適しています。変更前に、現在のローカル待受ポート、システムプロキシの状態、コアの種類、設定ファイルの出所を記録してください。問題が起きたら、まずこれらの基本項目を復元してからノードのフィールドを確認すると、システムプロキシの問題をサブスクリプション形式の問題と取り違えずに済みます。

目的 推奨する入力 推奨する出力 必ず確認する項目
複数ノードを定期的に更新する サブスクリプションURL クライアントのサブスクリプショングループ 更新状態、グループの所属、プロトコル対応
1つのノードを移行する 単一の共有リンク 新規ノード TLS、SNI、パス、備考
高度なルーティングを管理する ネイティブJSON 独立したコア設定 インバウンドポート、DNS、ルーティングタグ
サブスクリプションの内容を分析する 元のレスポンス デコード後の読み取り専用コピー 1層だけデコードし、接続情報を公開しない

最も安全な運用方法は、未変更のサブスクリプションレスポンス、正規化したノードフィールド、最終的にインポートするファイルの3つを保存することです。3つを分けておけば、接続異常がどの変換段階で起きたかを追跡できます。一般的な利用では、まずクライアントにサブスクリプション管理を任せましょう。手動でエンコードやJSONの対応付けを行うのは、移行、デバッグ、カスタムルーティングの構築が必要な場合に限るのが適切です。

V2Rayクライアントをダウンロード Windows、macOS、Android、Linux