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

v2rayN、v2rayNG、v2flyNGでサーバーを追加する際、受け取る内容はhttps://で始まるサブスクリプションURLの場合もあれば、構造が分かりにくいbase64テキストの場合もあります。また、vmess://やvless://で始まる単一ノードの共有リンクのこともあります。いずれも接続情報を含められますが、更新方法、移植性、インポート手順はそれぞれ異なります。

まず、サブスクリプションURL・エンコード済み本文・共有リンクを見分ける

「サブスクリプションリンク」は広い意味で使われがちな呼び方です。厳密には、サブスクリプションURLは繰り返しリクエストできるネットワーク上の入口で、クライアントがアクセスして初めてノード一覧を取得します。base64は、サーバーがノード一覧を返す際によく使うエンコード形式です。一方、共有リンクは通常1つのノードだけを表します。ネイティブJSONは完全な設定ファイルや構造化APIレスポンスに近く、必ずしも更新可能なサブスクリプションではありません。

最も早い見分け方は先頭の文字です。https://で始まりパスが長い文字列は、通常リモートのサブスクリプションURLです。英字・数字・プラス・スラッシュ・アンダースコアが連続する長い文字列は、base64またはURLセーフbase64の可能性があります。vmess://やvless://で始まるものはプロトコル共有リンクです。左中括弧で始まり、対になったフィールド名を含むものは通常JSONです。

base64サブスクリプション本文の復号と確認方法

base64はエンコード方式であり、暗号化プロトコルではありません。元のバイト列をテキスト転送に適した文字へ変換するため、読みにくい長い文字列が見えても、内容が秘匿化されているとは限りません。一般的なV2Rayサブスクリプションでは、複数の共有リンクを改行で区切ってから、全体をbase64エンコードします。復号すると、1行につき1つのvmess://またはvless://アドレスになることが多いです。

標準base64で使われる文字は、英大文字・英小文字・数字、+、/、末尾のパディング文字=などです。URLセーフ版では+が-に、/が_に置き換わり、末尾のパディングが省略される場合もあります。クライアントは通常どちらにも対応しますが、手動で確認する際は文字とパディングを元に戻してください。

1. 現在の内容がサーバーから返された本文であり、https://で始まるリモートURLのままではないことを確認します。
2. コピー時に混入した空白や先頭・末尾の改行を取り除きます。ただし、本文内部に含まれる有効な文字は削除しないでください。
3. URLセーフbase64の-と_を標準形式の文字へ戻し、長さが4の倍数になるよう補完します。
4. 復号後、各行に明確なプロトコルヘッダーがあるか、ノード名が文字化けしていないか、ポートが1～65535の範囲にあるかを確認します。
5. 復号結果がまだbase64の文字列の場合は、VMess共有リンク内部の2層目のエンコードかどうかを確認してください。無条件に繰り返し復号してはいけません。

以下のブラウザーコンソールコードは、このデバイス上のテキストだけを処理します。実行すると入力欄が表示され、復号結果がコンソールに出力されます。サブスクリプション本文にはサーバーアドレス、ユーザーID、通信パラメータが含まれることが多いため、実データを不明なオンライン変換サイトへ送信しないでください。

const encoded = prompt("base64サブスクリプション本文を貼り付け").trim();
const normalized = encoded.replace(/-/g, "+").replace(/_/g, "/");
const padded = normalized.padEnd(
  Math.ceil(normalized.length / 4) * 4,
  "="
);
const bytes = Uint8Array.from(
  atob(padded),
  character => character.charCodeAt(0)
);
console.log(new TextDecoder().decode(bytes));

ネイティブJSON設定に含まれる主要フィールド

V2RayまたはXrayコアが使用するネイティブJSONは、サーバーアドレスだけでなく設定ツリー全体を表します。実行可能な設定には通常、少なくともローカルのインバウンドinboundsとリモートのアウトバウンドoutboundsが必要です。必要に応じてrouting、dns、log、ポリシー関連のフィールドも加わります。サブスクリプションサービスが返すカスタムJSONのノード配列は、まったく異なるフィールド名を使う場合があります。クライアントが明確に対応している必要があり、JSONだからといってそのままコア設定としてインポートできるわけではありません。

以下は、フィールド階層を理解するためのVLESSとWebSocketの例です。例のドメインはドキュメント用で、outbounds内のプロトコルパラメータとstreamSettings内の通信パラメータの役割分担に注目してください。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "edge.example.net",
            "port": 443,
            "users": [
              {
                "id": "d342d11e-d424-4583-b36e-524ab1f0afa4",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "wsSettings": {
          "path": "/gateway"
        },
        "tlsSettings": {
          "serverName": "edge.example.net"
        }
      }
    }
  ]
}

• addressにはホスト名だけを記述し、WebSocketのパスはwsSettings.pathに分けて記述します。
• VLESSのユーザー項目にあるencryptionは通常noneとし、通信層でTLSを有効にするかどうかはstreamSettings.securityで決まります。
• ローカルのSOCKSインバウンドは127.0.0.1で待ち受けます。これはローカル接続だけを受け付ける設定です。LANで共有する場合は、待ち受けアドレスとアクセス制御を別途検討してください。
• 完全な設定には、直接接続やブロックなど複数のアウトバウンドが含まれ、tagとルーティングルールで関連付けられることもあります。

VMessとVLESSの共有リンクにおける内部構造の違い

VMess共有リンクは、vmess://の後にbase64文字列が続く形式が一般的です。復号すると、通常はJSONオブジェクトになり、アドレス、ポート、ユーザーID、通信方式、TLSの状態、WebSocketパス、ノード名などが含まれます。これは単一ノードの共有用データであり、ローカルインバウンド、DNS、ルーティングなどを通常含まないため、コアが直接実行する完全な設定とは異なります。

VLESS共有リンクは標準URIに近い形式です。ユーザーIDは@の前、サーバーとポートはその後に置かれ、通信方式、セキュリティ層、サーバー名、パスなどのパラメータはクエリ文字列に記述されます。ノード名は#の後に置かれます。簡略化した構造は次のように表せます。

vless://[email protected]:443?encryption=none&security=tls&sni=edge.example.net&type=ws&path=%2Fgateway#Example-WS

d342d11e-d424-4583-b36e-524ab1f0afa4

ユーザーID。インポート時は文字とハイフンを完全に保持します。

edge.example.net:443

サーバーアドレスとポート。ポートの前には半角コロンを使用します。

security=tls

通信セキュリティ層のパラメータ。プロトコルフィールド自体が変わることを意味しません。

type=ws

WebSocket通信を使用します。サーバー側の設定と一致させる必要があります。

path=%2Fgateway

URLエンコードされたパス。復号すると/gatewayになります。

#Example-WS

クライアントに表示する名前で、サーバー認証には使用されません。

3種類の形式をパラメータを失わずに相互変換する方法

最も一般的な変換は「サブスクリプション本文から共有リンク一覧への変換」です。リモートレスポンスがbase64なら、まずUTF-8で復号し、改行で分割します。各行は通常、そのままインポートできる共有リンクです。逆方向では、複数の共有リンクを改行で連結し、全体をbase64エンコードします。この処理で変わるのは包装形式だけで、静的テキストにリモート更新機能が加わるわけではありません。

「共有リンクからネイティブJSON」への変換では、フィールドの対応付けが必要です。VLESSを例にすると、URIのユーザーIDはsettings.vnext[].users[].idへ、ホストとポートはaddressとportへ入ります。クエリパラメータのtypeはstreamSettings.networkに対応し、securityは通信セキュリティ層、sniとパスはそれぞれの通信設定に入ります。その後、ローカルインバウンドと必要なアウトバウンドを補って、実行可能な設定にします。

1. まず元の内容をバックアップし、リモートURL、レスポンス本文、単一ノードのリンクを区別します。
2. 保持が必要な項目を列挙します：プロトコル、サーバー、ポート、ユーザーID、通信方式、セキュリティ層、サーバー名、パス、備考。
3. 復号または構造変換が終わったら、フィールドを項目ごとに比較します。ノード名が表示されたかどうかだけで判断しないでください。
4. まず1つのノードをインポートしてログと接続を確認し、その後で残りのノードをまとめて処理します。
5. クライアントのサブスクリプション記録に元のhttps://アドレスが保存されていることを確認し、手動更新を1回実行します。

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

v2rayN 7.xのサブスクリプション入口は通常、「サブスクリプショングループ」→「サブスクリプショングループ設定」にあります。新しいグループを追加する際にリモートURLを入力し、保存後、「サブスクリプショングループ」→「すべてのサブスクリプションを更新」でノードを取得します。単一ノードの共有リンクは、いったんクリップボードにコピーしてから、サーバーインポート関連の入口を使用します。小さなバージョン差でメニュー名が多少変わる場合がありますが、「サブスクリプショングループ」と「サーバーインポート」は別々の手順です。

接続後もシステムアプリに通信がない場合は、「設定」→「パラメータ設定」でローカルポートを確認します。一般的にはSOCKSポート10808、HTTPポート10809を使用しますが、実際の値は現在の設定画面を優先してください。他のプログラムがポートを使用していると、コアのログに待ち受け失敗が表示されることがあります。その場合は空いているポートへ変更し、ブラウザーやシステムのプロキシ設定も合わせて変更します。

• v2rayN：デスクトップでのサブスクリプショングループ、ノードの一括管理、カスタムルーティングに適しています。インポート後はサブスクリプションを更新し、アクティブなサーバーを選択してから、システムプロキシモードを設定します。
• v2rayNG：Android版ではXrayコアを使用し、VMess・VLESS共有リンクやリモートサブスクリプションのインポートに適しています。更新後は、選択中のノードがまだ存在することを確認してください。
• v2flyNG：Android版ではv2flyコアを使用し、VMessなど互換性のある設定を中心とした環境に適しています。拡張パラメータを使う場合は、まずコアが該当フィールドを認識できるか確認してください。

サブスクリプション管理とトラブルシューティングの基本手順

形式の問題とネットワークの問題は混同されがちです。サブスクリプションのリクエストタイムアウトは「内容の取得」段階、base64の文字異常やJSONフィールドのエラーは「内容の解析」段階、ノード接続のタイムアウトは「設定の使用」段階で発生します。段階ごとにログを確認すれば、ネットワークに接続できない状態で形式を何度も変更したり、パラメータの誤りなのにローカルプロキシポートを無闇に変えたりすることを避けられます。

リモートサブスクリプションURL、最後に成功した更新時刻、クライアントのバージョンを記録しておくことをおすすめします。ノードに異常がある場合は、まず手動更新を行い、明らかに利用可能なノードを1つテストし、最後にコアのログを確認します。v2rayNではサブスクリプショングループの状態とログパネルを同時に確認できます。Android版では、更新後に現在の設定が切り替わったり削除されたりしていないか確認してください。

1. 取得段階：サブスクリプションのドメイン、HTTPS接続、レスポンスのステータスを確認し、クライアントが実際に本文を受信したことを確認します。
2. 解析段階：本文がbase64、JSON、共有リンク一覧のどれに当たるかを判定し、改行、パディング、文字エンコードを確認します。
3. インポート段階：クライアントにノードが追加されたか、ノード数とグループ名が想定どおりかを確認します。
4. 接続段階：アドレス、ポート、ユーザーID、通信方式、セキュリティ層、サーバー名、パスを確認します。
5. プロキシ段階：アクティブなサーバー、システムプロキシモード、10808や10809などのローカルポートが正常に待ち受けているかを確認します。
6. ルーティング段階：接続は正常なのに特定ドメインの動作だけが異常な場合は、routing.rulesの順序とアウトバウンドタグを確認します。