V2Rayのサブスク形式を徹底解説：Base64・ネイティブJSON・共有リンクの変換方法

サブスク・共有リンク・実行設定をまず区別する

「サブスク」とは通常、定期的にリクエストできるアドレスを指します。クライアントがそのアドレスへアクセスすると、サーバーが複数のノード情報を返し、クライアントがローカルデータベースへ保存します。サブスクURL自体はノードではなく、継続的に更新されるデータの入口に近いものです。同じURLでも、今日は8ノード、次回の更新では10ノードを返すことがあります。

「共有リンク」は単一ノードを表します。一般的には vmess:// または vless:// で始まり、サーバーアドレス、ポート、ユーザー識別子、トランスポート方式、TLSパラメータなどを含みます。複数の共有リンクを1行ずつ並べ、まとめてエンコードすればサブスク応答にできますが、個々のリンク自体に自動更新機能はありません。

「ネイティブJSON」は通常、V2RayまたはXrayコアが読み込める実行設定です。inbounds、outbounds、routing、dnsなどのオブジェクトを含み、リモートノードだけでなく、ローカルの待受ポート、トラフィックの入口、ルーティング動作まで記述します。完全な実行設定を通常のサブスクとして読み込んでも、クライアントがノード一覧だけを抽出できるとは限りません。

Base64サブスクの見分け方とデコード方法

従来のV2Rayサブスク応答では、複数の共有リンクを改行で連結し、UTF-8テキスト全体をBase64エンコードすることがよくあります。ブラウザーでサブスクURLを直接開くと、英字、数字、プラス、スラッシュ、イコールで構成された長い文字列が表示される場合があります。外側をデコードして初めて、vmess:// または vless:// のリンクが1行ずつ現れます。

判定時に、文字列が「Base64らしい」かどうかだけを見てはいけません。通常のテキスト、圧縮データ、一部のURLセーフエンコードも似た見た目になることがあります。確実な方法は、まずレスポンスのContent-Typeと先頭数文字を確認してからデコードすることです。デコード結果は有効なUTF-8テキストで、空でない各行に識別可能なプロトコルプレフィックスがあるはずです。デコード後もエンコード済みの文字列が残る場合は、無闇に続けてデコードせず、二重エンコードを確認してください。

外側をデコードした後の典型的な構造

vmess://エンコード済みの単一ノードデータ
vless://ユーザー識別子@node-a.example:443?encryption=none&security=tls&type=ws&path=%2Fedge#A-WS
vless://ユーザー識別子@node-b.example:443?encryption=none&security=reality&type=tcp&flow=xtls-rprx-vision#B-TCP

上記は構造を示すための例であり、接続可能な認証情報は含みません。実際に解析する際は改行で分割し、UnixのLFとWindowsのCRLFの両方に対応してください。空行は無視できますが、行頭と行末の空白は先に削除します。サーバーのレスポンス末尾に改行がなくても、最後のリンクを必ず解析してください。

Base64には標準アルファベットとURLセーフアルファベットがあります。標準形式ではプラスとスラッシュを使い、URLセーフ形式ではハイフンとアンダースコアを使います。末尾のイコールによるパディングが省略されることもあります。一般的なクライアントは通常こうした違いに対応しますが、手作業ではまずアルファベットを統一し、長さを補正してください。エンコード長を4で割った余りが2ならイコールを2つ、3なら1つ追加します。余りが1の場合は、通常テキストが途中で切れています。

• HTTPステータスは成功レスポンスである必要があります。ログインページやエラーページへリダイレクトされた場合、HTMLをサブスク内容として扱わないでください。
• デコード結果はUTF-8として読み取ってください。ノード名に日本語が含まれる場合、文字コードを誤ると名前が文字化けします。
• 1行には共有リンクを1つだけ記載します。リンクの途中に手動で改行を入れないでください。
• サブスク更新後にノード数が12から0になった場合は、まず元のグループを保存し、レスポンス内容が空でないか確認してください。
• サブスクURLは慎重に保管すべきデータです。公開Webページや管理できない変換サービスへ貼り付けないでください。

VMess・VLESS共有リンクのフィールドの違い

VMessとVLESSでは共有リンクのエンコード方式が異なります。一般的なVMessリンクでは、vmess:// の後にBase64エンコードされたJSONを置きます。オブジェクトには add、port、id、net、path、host、tls、sniなどのフィールドが含まれることがあります。一部の旧形式には v、ps、aidもあり、一般的な設定バージョン値は2、現在の構成での aid は通常0です。

VLESS共有リンクは標準URIに近い形式です。ユーザー識別子はユーザー名部分、サーバーアドレスとポートはホスト部分、トランスポートとセキュリティのパラメータはクエリ文字列、ノード名はハッシュ記号以降のフラグメントに入ります。たとえば type=ws はWebSocket、security=tls はTLSを示し、path=%2Fedge はデコードすると /edge になります。パラメータの順序は通常意味に影響しませんが、名前と値は正しくURLエンコードする必要があります。

変換は単なるプレフィックス変更ではない

VMessとVLESSは異なるプロトコルであり、vmess:// を vless:// に直接書き換えることはできません。サーバーアドレス、ポート、トランスポート層が同じでも、サーバー側に対応するプロトコルのインバウンドが存在し、ユーザー認証方式も一致している必要があります。「相互変換」とは、より正確には、サーバーが変換先のプロトコルにも対応していることを前提に、共通の接続パラメータを別のリンク構造へ割り当てることです。

トランスポートのフィールドは意味に沿って対応付ける必要があります。たとえばVMess JSONの net=ws はVLESSの type=ws に対応させられ、path=/edge はURLエンコードしたクエリパラメータに変換します。ただし、Realityに必要な公開鍵、ショートID、フィンガープリント、Flowは、従来のVMess + TLSリンクには存在しません。変換ツールがこれらを自動生成することはできません。

ネイティブJSONと共有リンクを相互に整理する方法

ネイティブJSONから共有リンクを抽出する場合、まず outbounds の中からプロトコルがVMessまたはVLESSのアウトバウンドを特定し、サーバー、ポート、ユーザーの各フィールドを読み取ります。続いて streamSettings を確認します。ここで network がトランスポートタイプ、security がTLSまたはRealityを決め、WebSocket、gRPC、TCPの具体的な設定は対応する子オブジェクトにあります。

共有リンクからJSONを生成し直す場合、復元できるのは通常、リモートのアウトバウンドとそのトランスポートパラメータだけです。ローカルのSOCKSポート、HTTPポート、DNSサーバー、ログレベル、完全なルーティングルールまでは提供できません。そのため、共有リンクをJSONへ変換した後は、クライアントまたは設定ジェネレーターでローカル部分を補う必要があります。一般的なローカル構成はSOCKS待受 127.0.0.1:10808、HTTP待受 127.0.0.1:10809 ですが、実際のポートは使用中のクライアント設定に従ってください。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example",
            "port": 443,
            "users": [
              {
                "id": "サンプル値は非表示",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    }
  ]
}

このJSONは階層を説明するためだけのものです。実際の設定にはノードに一致する streamSettings が必要で、さらに直通用とブロック用のアウトバウンドが必要になる場合があります。トランスポート設定がない構成をそのまま読み込み、サーバーが実際にはWebSocket + TLSを使っていると、コアは不一致のデフォルトトランスポートで接続を試みます。ログには通常、接続終了やハンドシェイク失敗だけが記録されます。

完全な設定から単一ノードリンクをエクスポートする場合、ルーティング情報を表現できない問題にも直面します。ドメイン分岐、GeoIP、GeoSite、プロセスルール、DNSクエリポリシーは実行設定に属し、単一ノードURIのフィールドではありません。正しい方法は、ノードとルーティングを分けて移行することです。ノードは共有リンクで読み込み、ルールはクライアントのバックアップ・インポート機能または手動設定で復元します。

1. JSONのトップレベルに outbounds があるか確認し、対象アウトバウンドのプロトコル名を確認する。
2. サーバーアドレス、ポート、ユーザーパラメータを読み取り、サンプルや期限切れの記録をコピーしない。
3. streamSettings からトランスポート、セキュリティレイヤー、SNI、パス、サービス名を抽出する。
4. 対象プロトコルに合わせて共有リンクを生成し、パス、ノード名、クエリパラメータをURLエンコードする。
5. クライアントへ読み込んだ後、詳細画面でポート、トランスポート、TLS、SNI、ユーザー識別子を項目ごとに確認する。
6. まず単一ノードをテストし、その後サブスク応答へ一括追加する。誤ったパラメータがグループ全体に広がるのを防げる。

3つのクライアントの読み込み範囲と具体的な操作

v2rayNはデスクトップクライアントで、サブスクグループ、単一ノードリンク、カスタム設定を管理できます。7.xシリーズの画面を例にすると、サブスクURLは「サブスクグループ」→「サブスクグループ設定」から追加します。新しいグループを作成してURLを入力・保存し、「サブスクグループ」→「すべてのサブスクを更新」を実行してください。クリップボードに複数の共有リンクがある場合は、「サーバー」→「クリップボードから一括URLをインポート」を利用できます。

v2rayNGはXrayコアで一般的なVMess・VLESSノードを処理します。Androidでサブスクを追加する場合は、左上のメニューから「サブスクグループ設定」を開き、右上の追加ボタンでURLを保存してから、メイン画面で更新を実行します。単一または複数の共有リンクは、いったんクリップボードへコピーし、右上の「+」から「クリップボードからインポート」を選択できます。小さなバージョン差で表示文言が異なる場合がありますが、入口はサブスクグループと追加ボタン周辺にあります。

v2flyNGはv2flyコアを使用し、VMessおよびV2Rayコア互換設定を中心とする環境に適しています。サブスクとクリップボードからのインポート手順は、Androidで一般的なレイアウトに近いものです。ただし、対応するプロトコル範囲はコアの機能に左右されます。別のコアだけが実装しているセキュリティ方式やトランスポート構成を含むサブスクでは、リンクを解析して表示できても、実行時に失敗する場合があります。

読み込み後に必ず確認する6項目

• アドレスとポート：ポートは有効な整数である必要があります。TLSの入口には443がよく使われますが、それを理由に他のポートを自動変更してはいけません。
• ユーザー識別子：前後に空白がないか確認し、チャットツールの改行による欠落を防ぎます。
• トランスポート方式：TCP、WebSocket、gRPCはサーバー側と一致している必要があります。
• パスまたはサービス名：WebSocketのパスは通常スラッシュで始まります。gRPCはサービス名を使うため、無理にスラッシュを付けないでください。
• セキュリティパラメータ：TLS、Reality、SNI、フィンガープリント、Flowを項目ごとに対応させます。リンクのプレフィックスだけを見て判断してはいけません。
• ローカルプロキシポート：v2rayNで「設定」→「パラメータ設定」を開き、ローカルのSOCKSポートとHTTPポートが他のプログラムに使用されていないか確認します。

変換失敗・サブスク空・文字化けのトラブル対応

変換に失敗するのは、通常、サブスク応答の取得、外側のコンテナのデコード、単一ノードの解析という3段階のいずれかです。トラブル対応ではこの順番で確認し、最初からプロトコルパラメータを変更しないでください。サブスクのリクエストがすでにエラーページを返している場合、その後のBase64デコードやノードの読み込みで有効な結果は得られません。

まず、HTTPステータス、レスポンスのバイト数、デコード後の空でない行数という3つの具体的な数値を記録します。たとえばステータスが正常、レスポンスが18KB、デコード後が24行なら、サブスク取得と外側のデコードはほぼ完了しています。クライアントに20ノードしか表示されない場合は、残り4行のプロトコルプレフィックスやフィールド形式を確認してください。

ログでフィールド階層のエラーを特定する

ノードを起動できても接続を確立できない場合は、まずクライアントコアのログを確認します。DNS解決の失敗は、ドメインまたはDNS設定を示すことが多く、接続タイムアウトはアドレス、ポート、ネットワーク経路の問題である可能性が高いです。TLSハンドシェイクの失敗では、SNI、システム時刻、セキュリティレイヤーを重点的に確認します。起動時に設定フィールドのエラーが直接表示される場合は、JSONの階層または現在のコアがそのフィールドを認識できるかを確認してください。

ローカルポートの競合も「正しく読み込めたのに使えない」原因になります。たとえばSOCKSポートが10808で、別のインスタンスが同じポートをすでに待ち受けていると、コアを起動できない場合があります。v2rayNでは「設定」→「パラメータ設定」でポートを確認し、重複起動しているインスタンスを終了してください。Androidでは、現在の接続をいったん停止してから対象設定を再起動します。

安全な移行と長期的な管理のポイント

サブスクURLにはノード一覧へアクセスできる権限が含まれる場合があるため、機密設定として扱ってください。保存にはクライアントのサブスクグループを使い、スクリーンショット、公開ドキュメント、チャット履歴に完全なURLを表示しないでください。デバイス間で移行する場合は、優先的にクライアント自身の設定エクスポート機能を使い、完了後に一時ファイルを削除します。

実際のサブスクをオンライン変換ページで処理しないでください。Base64はエンコードであり、機密性を提供しません。元のテキストを読み取れるサービスは、含まれるノードパラメータも取得できます。構造を確認する必要がある場合は、ローカルにコピーを作成し、ユーザー識別子とサブスクのクエリパラメータを削除してから形式を分析してください。

長期的な管理では、「ノードの取得元」と「ローカルのポリシー」を分けてください。サブスクはノード更新を担当し、クライアントはシステムプロキシ、TUN、DNS、ルーティング分岐を担当します。こうすればサブスク一覧が変わっても、ローカルの直通ドメイン、ブロックルール、待受ポートがノードと一緒に誤って上書きされることはありません。

1. 取得元ごとに独立したサブスクグループを作成し、すべてのノードを追跡できない1つのリストに統合しない。
2. 更新前にノード数を記録し、更新後に追加、削除、名前の変更を比較する。
3. 検証済みで使用できるノードのコピーを1つ残し、サブスクの一時的な障害で全設定が使えなくなるのを防ぐ。
4. 変換するたびに、少なくともVMessノード1つとVLESSノード1つを抽出確認し、トランスポートのフィールドを照合する。
5. クライアントをアップグレードした後は、サブスク更新、ノード起動、ローカルポートを先に検証してから自動更新スケジュールを戻す。