サブスクリプションURLは設定の取得・更新に使い、Base64はデータのエンコード方式、共有リンクは個々のノード、完全なJSONはコアの動作設定を表します。「コピーしたのにインポートできない」ときや、別の端末へ移行するときは、まず内容から形式を見分け、適切な方法で読み込みましょう。変換時に失われやすい通信方式、TLS、ルーティング、DNSの設定も確認します。
サブスクリプションURL・レスポンス本文・ノードリンクを区別する
「V2Rayサブスクリプション」は特定のファイル拡張子を指すものではありません。一般的なサブスクリプションURLはトークン付きのHTTPS URLで、クライアントがそのURLにアクセスすると複数のノードを取得できます。レスポンス本文は、共有リンクが1行ずつ並んだ形式の場合もあれば、リンク全体をBase64でエンコードしたテキストの場合もあります。URLはデータを取得する入口で、本文が解析対象です。両者を混同して貼り付けないようにしましょう。
| データの種類 | 見分けるポイント | 一般的な内容 | インポート先 |
|---|---|---|---|
| サブスクリプションURL | アクセストークンが含まれることのあるHTTPS URL | リモート更新の入口 | サブスクリプショングループの設定 |
| Base64サブスクリプション本文 | エンコードされたテキスト。デコードすると複数行のプロトコルリンクが現れることが多い | 複数ノードの接続情報 | サブスクリプションの解析処理。手動で扱う場合は先にデコード |
| 共有リンク | vmess://、vless://、trojan:// | 単一ノードと一部の接続パラメーター | クリップボードからインポート |
| 完全なコア設定JSON | inbounds、outboundsなどのフィールドを含む | インバウンド、アウトバウンド、任意のルーティングやDNS設定 | カスタム設定の読み込み |
「波括弧で始まる」ことだけを根拠に、完全な設定ファイルだと判断しないでください。VMessでよく使われる共有形式の一つは、デコードするとJSONになりますが、通常はadd、port、id、netなどのノード情報だけが含まれ、コア設定全体の階層構造はありません。また、サブスクリプションAPIが管理サービス独自のJSONを返す場合もあり、そのままXrayで実行することはできません。
3つの形式の選び方:更新にはサブスクリプション、単一ノードにはリンク
サブスクリプションURLとノード一覧
おすすめノード情報を提供元が管理する場合の日常利用に適しています。クライアントにURLを登録しておけば、ノード情報を再取得できます。Base64はよく使われるレスポンスのエンコード方式にすぎず、対応プロトコルを決めるものではありません。
こんな場合に:複数端末で使う、ノードの接続先が変わる可能性がある、継続的に更新したい
単一の共有リンク
コピーやQRコードでの共有、一時的な端末移行に便利です。インポート後は通常、端末内のノード情報として保存されるため、提供元が設定を変更しても自動では同期されません。
こんな場合に:特定のノードを調べる、一時的に移行する、パラメーターを個別に比較する
完全なJSON設定
ローカルの待ち受けポート、アウトバウンドの選択、ルールを明示できますが、対象のコアとそのバージョンに依存します。実行用の設定であり、クライアントをまたいで使える汎用バックアップ形式ではありません。
こんな場合に:カスタムインバウンド、複雑なルーティング、特定のコア設定を維持したい
結論:継続的な更新が必要かどうかで選ぶ
提供元の更新を反映したい場合は、両方の端末にサブスクリプションURLを登録します。単一ノードだけを移行するなら、共有リンクをエクスポートしましょう。一度エクスポートしたノード一覧を、自動更新されるサブスクリプションと混同しないでください。
Base64に秘匿性はありません。サブスクリプションURLのトークンや共有リンク内のUUID・パスワードは、アクセス認証情報として扱ってください。スクリーンショット、ログ、クリップボードの同期から漏れる可能性があります。問題を調べる際はフィールド名だけを残し、実際の認証情報をオンライン変換サイトに渡さないようにしましょう。
Base64と共有リンク:デコード後はフィールドも確認
一般的なBase64サブスクリプションでは、複数の共有リンクを改行でつなぎ、そのテキスト全体をエンコードします。これはvmess://の後ろにあるBase64とは別の階層です。前者はノード一覧をまとめ、後者は一般的なVMess共有形式の一つで単一ノードのJSONを格納します。外側をデコードしたら、まず先頭のプロトコルを確認し、内容全体を何度もデコードしないでください。
- コピー時に混ざった前後の空白を取り除き、元のテキストもバックアップしておきます。
- 先頭がすでにプロトコルのプレフィックスなら、リンクとして解析し、全体をデコードする必要はありません。
- エンコードされた本文なら一度だけデコードし、複数行のプロトコルリンクになるか確認します。
- HTMLのログインページやエラーメッセージが表示される場合は、エンコードを「修復」し続けるのではなく、サブスクリプションの取得元を確認してください。
以下は予約済みのサンプルドメインを使ったVLESSリンクです。フィールドの説明用で、接続できるノードではありません。ポートは443、通信方式はTCP、セキュリティ層はTLSで、フラグメント部分は表示用のメモです。
vless://[email protected]:443?encryption=none&security=tls&type=tcp&sni=example.net#format-demo
encryption=noneはVLESSプロトコルのパラメーターであり、TLSを無効にする指定ではありません。セキュリティ層はsecurity=tlsで指定します。実際のノードがWebSocketを使う場合は、type=ws、パス、Hostも維持してください。REALITYを使う場合は、公開鍵、Short ID、サーバー名、フィンガープリントなどを確認します。パラメーターが認識されるかは、クライアントのインポーターと選択したコアによって異なります。
v2rayN・v2rayNGでのインポートとエクスポート
バージョンによってメニュー名が多少異なる場合があります。ここでは一般的なメニュー名を使って説明します。操作前に、手元のデータがサブスクリプションURL、共有リンク、完全な設定ファイルのどれかを確認してください。リモートURLを通常のサーバー一覧に追加する誤操作を防げます。デスクトップ版では使用中のコアも確認しましょう。Android版のv2rayNGはXrayコアを使用しますが、だからといってあらゆる形式が自動変換できるわけではありません。
操作手順:データの種類に応じて読み込み先を選ぶ
デスクトップ版:v2rayN
- サブスクリプションURL:「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、グループを追加してURLを入力します。保存後、「現在のサブスクリプションを更新」を実行してください。
- 共有リンク:リンク全体をコピーし、メイン画面で「クリップボードからURLを一括インポート」を選びます。一般的なショートカットキーはCtrl+Vです。
- ノードのエクスポート:通常のノードを選択し、右クリックメニューから共有、またはURLをクリップボードにエクスポートする項目を選びます。出力されたプレフィックスも確認してください。
- 完全なJSON:「カスタム設定サーバーを追加」の項目からファイルを選択します。ファイルの本文をサブスクリプションURL欄に貼り付けないでください。
Android版:v2rayNG
- サブスクリプションURL:メニューから「サブスクリプショングループ設定」を開き、グループを追加してURLを保存します。メイン画面に戻り、「サブスクリプションを更新」を実行してください。
- 共有リンク:右上の「+」→「クリップボードからインポート」を選びます。QRコードの場合は、対応するスキャン機能を使ってください。
- ノードのエクスポート:ノード項目の共有機能から、クリップボードへのコピーまたはQRコードを選びます。バージョンによっては、項目を長押しする必要があります。
- 完全なJSON:「+」メニューから設定ファイルのインポート機能を選びます。カスタム設定項目の共有方法は、通常のノードとは異なります。
同じサブスクリプションURLを両方のクライアントで使えますが、各ノードが使えるかどうかは、それぞれのパーサー、コアのバージョン、ネットワーク環境によって異なります。
インポート後は、まずノードを1つ編集し、アドレス、ポート、UUIDまたはパスワードを確認してから、通信方式とTLSの設定を照合します。ノードを選択してサービスを起動し、接続テストとコアのログを確認してください。インポーターにノード名が表示されても、テキストが認識されたというだけで、リモート認証、証明書、通信パラメーターがすべて正しいとは限りません。
- サブスクリプションとの紐付けを維持:手動でコピーしたノードには、元のサブスクリプショングループとの更新関係が引き継がれないことがほとんどです。
- 重複インポートを防ぐ:まず新しいグループで動作を確認し、問題がないとわかってから古い項目を整理します。同じ名前の項目が複数並ぶと混乱しやすくなります。
- ローカル設定は別途保存:システムプロキシ、TUN、アプリごとのプロキシ、自作ルーティングは、単一のノードリンクでは移行できません。
完全なJSONを共有リンク1つにまとめられない理由
共有リンクが主に表すのは「特定のアウトバウンドへの接続方法」です。一方、完全な設定は「ローカルでどの通信を受け取り、ドメイン名をどう解決し、どのアウトバウンドから送信するか」も記述します。1つのJSONファイルに複数のアウトバウンドやドメイン別の振り分けルールが含まれる場合、それらすべてを表現できる単一のリンクはありません。JSONをそのままBase64にエンコードしてvmess://を付けても、有効なVMess共有リンクにはなりません。
以下はXray形式の学習用設定です。ローカルの127.0.0.1:10808でSOCKSポートを待ち受けます。サンプルドメインとサンプルUUIDを使用しているため、実際の接続には使えません。ノードリンクにはない、完全な設定特有の階層構造を示すものです。V2Rayやその他のコアで使える汎用設定テンプレートでもありません。
{
"log": {
"loglevel": "warning"
},
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
}
],
"outbounds": [
{
"tag": "proxy",
"protocol": "vless",
"settings": {
"vnext": [
{
"address": "example.net",
"port": 443,
"users": [
{
"id": "c2a183e4-5f61-4b8b-91ea-7a820ae42f61",
"encryption": "none"
}
]
}
]
},
"streamSettings": {
"network": "tcp",
"security": "tls",
"tlsSettings": {
"serverName": "example.net"
}
}
},
{
"tag": "direct",
"protocol": "freedom"
}
],
"routing": {
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
}
}
この例のリモート接続フィールドは、前述のVLESSリンクに対応します。ただし、ローカルのSOCKSポートやプライベートIPアドレスへの直接接続ルールは、リンクには含まれません。また、例のgeoip:privateを使うには、実行環境に対応するルールデータが必要です。完全な設定を移行するときは、コアの構文、必要なデータファイル、ポートの使用状況をあわせて確認してください。
| 変換の方向 | 通常維持できる項目 | 別途対応が必要な項目 |
|---|---|---|
| リンク一覧 → Base64本文 | 元のリンクテキストと並び順 | エンコードしてもサブスクリプションの更新URLは作成されない |
| 共有リンク → クライアントのノード | インポーターが対応するプロトコルと接続フィールド | 未対応のパラメーターは無視される場合がある |
| クライアントのノード → 共有リンク | 出力先のリンク形式で表現できるパラメーター | ローカルのルーティング、DNS、TUN設定 |
| 完全なJSON → 共有リンク | 認識できるアウトバウンドの設定項目 | その他のアウトバウンド、インバウンド、ルール、コア拡張フィールド |
相互変換に失敗したら、形式を何度も変えるのではなく症状から確認
サブスクリプションURLをコピーしたのに「有効な設定がありません」と表示されるのはなぜ?
まず「クリップボードからインポート」を誤って使っていないか確認します。HTTPSのサブスクリプションURLは「サブスクリプショングループ設定」のURL欄に入力して保存し、更新してください。それでも失敗する場合は、ログインページやトークンの期限切れ、ネットワークタイムアウトが返されていないか確認しましょう。Webページの本文をノード一覧として扱うことはできません。
Base64をデコードしたのに、まだエンコードされた文字列があるのはなぜ?
まずプレフィックスを確認します。デコード結果がvmess://で始まる場合、後ろのエンコード部分は単一ノードのJSONである可能性があり、正常な形式です。vless://が得られた場合は、URIパラメーターとして解析します。複数のリンクを含むテキスト全体を、むやみに再デコードしないでください。
インポートできたのに接続できない。変換ツールで何が抜けた?
元データと照合し、リモートポート、TLSのサーバー名、WebSocketのパスとHost、REALITYに必要なパラメーターを確認します。サービスをいったん停止してから再起動し、新しいログを確認してください。ローカルポートが使用中と表示された場合は、設定例の10808など、実際の待ち受けポートを調べます。そのためにリモートポートの443を変更しないでください。
端末を替えたらノードはあるのに、ルーティングルールが消えたのはなぜ?
ノードの共有では、アプリ全体の設定は同期されません。元の端末でルーティング、DNS、システムプロキシ、アプリごとのプロキシをそれぞれ記録し、移行先で復元してください。完全なJSONを移行する場合は、移行先が同系統のコアと互換性のあるバージョンを使用していることも確認します。ファイルの拡張子が同じというだけでは判断できません。
最後に、小規模なテストを行います。まずノードを1つ移行し、各フィールドが一致していること、サービスが起動すること、接続先に到達できることを確認してから、残りをまとめて処理してください。サブスクリプションの更新で設定が上書きされる場合に備え、手動で変更したノードは先にバックアップします。変換後も元のファイルを保管しておけば、未知のフィールドが失われたときに元へ戻せます。ルーティングやDNSの設定を詳しく知りたい場合は、サイトの設定ガイド(応用編)をご覧ください。