サブスクリプションURL、応答内容、単一ノードの共有リンク、コア設定の違いを把握してから、適切な方法で読み込みましょう。「サブスクリプションを認識できない」「JSONをノードとして読み込めない」「別の端末へ移行したい」といった場合に向けて、Base64の外側の構造、VMessとVLESSの項目の違い、変換時に保持できる接続情報と別途移行が必要なDNS・ルーティング設定を順に説明します。
1. 形式を見分ける:サブスクリプションURLはノード設定ではない
V2Rayのサブスクリプションは、特定のコア設定ファイル形式を指すものではありません。一般に「サブスクリプションリンク」と呼ばれるのはHTTPSのURLで、クライアントがアクセスしてテキストを取得し、ノード一覧として解析します。応答は共有リンクが1行ずつ並んだ形式の場合も、リンク一覧全体をBase64でエンコードした形式の場合もあります。URLにアクセスできても、応答が現在のクライアントで使えるとは限りません。
| 対象 | 見分け方 | 読み込み先 | 保存される内容 |
|---|---|---|---|
| サブスクリプションURL | https://で始まるサービスのURL | サブスクリプショングループの設定 | リモート更新元 |
| Base64形式のサブスクリプション本文 | デコードすると通常は複数行の共有リンクになる | サブスクリプション更新機能で解析 | 複数ノードの接続情報 |
| VMess共有リンク | vmess://とエンコードされたデータ | クリップボードから読み込み | 通常は1つのノード |
| VLESS共有リンク | vless://とユーザー情報・クエリパラメーター | クリップボードから読み込み | 通常は1つのノード |
| コアのJSON設定 | inbounds、outboundsなどの項目を含む | カスタム設定の読み込み | 接続、受信、DNS、ルーティングなどの設定 |
たとえば、https://subscription.example.com/list?token=demoはURL形式の例であり、利用可能なサブスクリプションではありません。VLESSサーバーのアドレスとして入力することも、JSON設定をサブスクリプションURL欄に貼り付けることもできません。サブスクリプションURLのトークンはアカウント権限に紐づくことが多いため、トラブルシューティングの際はドメインだけでなく、パスやクエリパラメーターも含めて隠してください。
2. Base64の構造を確認する:サブスクリプションの外側とVMessの内側
よくあるBase64形式のサブスクリプションは、2層構造になっています。外側ではリンク一覧全体をエンコードし、内側では各vmess://リンクにBase64でエンコードしたJSONが含まれる場合があります。外側をデコードして得られるのはノードリンクであり、コアが動作するための完全な設定ではありません。一方、VLESSは通常URI形式を使うため、VMessの内側をデコードする方法はそのまま使えません。
サブスクリプションの応答本文
↓ 本文全体をBase64デコード
vmess://エンコード済みノードJSON
vless://ユーザー識別子@サーバー:ポート?パラメーター#名前
↓ vmess://の後ろのデータだけをさらにデコード
VMessのノード項目:add、port、id、net、tlsなど
まず応答に含まれる実際のテキストを確認してから、デコードするか判断してください。本文がvmess://またはvless://で始まる場合は、1行ずつ並んだリンクとして扱います。HTMLタグ、ログイン案内、JSON形式のエラーが先頭にある場合は、サブスクリプションのリクエスト、認証、またはサーバーの応答に問題がある可能性が高く、何度デコードしても解決しません。
- 改行:1行に完全なリンクを1つ記載します。コピー時にリンクの途中で改行したり、複数のリンクを1行につなげたりしないでください。
- 文字:Base64URLでは、通常のBase64の
+と/の代わりに-と_を使います。出力によっては末尾の=が省略されます。 - テキスト:日本語の備考はUTF-8として復元する必要があります。バイナリデータを通常の文字として表示すると、文字化けすることがあります。
- 回数:リンク一覧を取得した時点で、外側のデコードは終了です。英数字が混在しているからといって、さらに繰り返し処理しないでください。
以下は、ローカルの空白ページでブラウザーの開発者ツールを使って実行できる、標準JavaScriptの関数です。テキストのエンコードとデコードだけを行い、ネットワークリクエストやクリップボードの自動読み取りはしません。サンプルテキストだけで往復処理を確認してください。実際のサブスクリプションを扱う際は、ブラウザー拡張機能やコンソールの記録にも注意が必要です。
function encodeUtf8Base64(text) {
const bytes = new TextEncoder().encode(text);
let binary = "";
for (const byte of bytes) binary += String.fromCharCode(byte);
return btoa(binary);
}
function decodeUtf8Base64(text) {
let value = text.trim().replace(/\s+/g, "")
.replace(/-/g, "+").replace(/_/g, "/");
if (value.length % 4 === 1) {
throw new Error("Base64 の長さが不正です。コピーした内容を確認してください");
}
value += "=".repeat((4 - value.length % 4) % 4);
const bytes = Uint8Array.from(atob(value), ch => ch.charCodeAt(0));
return new TextDecoder("utf-8", { fatal: true }).decode(bytes);
}
const sample = "サブスクリプション形式のサンプル";
console.log(decodeUtf8Base64(encodeUtf8Base64(sample)) === sample);
3. ノード項目を確認する:VMess JSONとVLESS URI
一般的なVMess共有形式では、vmess://の後ろにエンコードされたノード情報のJSONが格納されています。これはクライアント間の共有用に定められた形式であり、XrayやV2RayのコアJSON設定とは異なります。ここでのvは共有形式の識別子です。v: "2"はクライアントのバージョン番号でも、特定バージョンのコアをインストールする指定でもありません。
{
"v": "2",
"ps": "VMess-WS-TLS サンプル",
"add": "node.example.com",
"port": "443",
"id": "11111111-2222-4333-8444-555555555555",
"aid": "0",
"scy": "auto",
"net": "ws",
"type": "none",
"host": "edge.example.com",
"path": "/ws",
"tls": "tls",
"sni": "edge.example.com"
}
上記JSON全体をUTF-8でBase64にエンコードし、先頭にvmess://を付けると、この形式の共有リンクを作成できます。サンプルのドメインとユーザー識別子は説明用であり、接続には使えません。実際のノードでは、アドレス、UUID、通信方式、TLS設定をサーバー側の設定と一致させる必要があります。備考だけを置き換えても使えません。
VMess + WS + TLS
- サーバーポート
443- 通信方式の項目
net: ws- リクエストパス
/ws- HTTP Host
edge.example.com- TLS SNI
edge.example.com
HostはWebSocketリクエストに使われ、SNIはTLSハンドシェイクに使われます。例で値が同じでも、互いに置き換えられるわけではありません。
VLESS + TCP + TLS
- サーバーポート
443- 通信パラメーター
type=tcp- プロトコルパラメーター
encryption=none- 通信のセキュリティ
security=tls- TLS SNI
node.example.com
VLESSのプロトコル暗号化項目とTLSは別のレイヤーです。そのため、TLS設定を削除してよいわけではありません。
対応するVLESSの例は、ユーザー情報、アドレス、クエリパラメーター、フラグメント形式の備考を組み合わせています。空白や日本語の備考はURIのパーセントエンコードが必要です。IPv6アドレスは角括弧で囲みます。パラメーターの順序は通常意味に影響しませんが、名前や値を任意に書き換えることはできません。
vless://[email protected]:443?encryption=none&security=tls&sni=node.example.com&type=tcp#VLESS-TLS
4. v2rayNに読み込む:先にサブスクリプショングループを作成してノードを更新
リモートサブスクリプションはサブスクリプショングループに登録し、単一または複数の共有リンクはクリップボードから読み込みます。以下はv2rayNの一般的な日本語UIに沿った手順です。デスクトップ版とWPF版ではメニューの場所が異なる場合があり、更新機能がグループの右クリックメニューにあることもあります。実際のメニューに表示される機能名を確認し、ボタンの場所が違うという理由でカスタム設定の読み込みを使わないでください。
-
グループを新規作成
「サブスクリプショングループ」→「サブスクリプショングループの設定」を開き、レコードを追加します。備考を入力し、完全なHTTPSサブスクリプションURLをアドレス欄に貼り付けて保存します。
-
サブスクリプションを更新
「サブスクリプショングループ」に戻り、「すべてのサブスクリプションを更新(プロキシを使用しない)」を選択します。サブスクリプションへのアクセスに、利用可能なプロキシが必要なネットワークでは、プロキシ経由で更新する項目を選んでください。
-
ノードを確認
更新結果を確認し、対象のグループにノードが追加されたことを確かめます。ノードの編集画面を開き、プロトコル、サーバーアドレス、ポート、通信方式、TLSを確認してください。備考が同じかどうかだけで判断しないでください。
-
サーバーを選択
ノード一覧を右クリックし、「アクティブサーバーに設定」を選択します。サブスクリプションを更新しても設定が取得されるだけで、接続先が新しいノードに切り替わるわけではありません。
-
接続を確認
クライアントに用意された接続テストを実行し、ブラウザーから検証対象のサイトに実際にアクセスします。失敗した場合は、まずログでハンドシェイク、認証、名前解決のエラーを確認し、すぐに形式の変換を繰り返さないでください。
静的な共有リンクを読み込む場合は、接頭辞を含むリンク全体をコピーし、「サーバー」→「クリップボードからURLを一括インポート」を選択します。一般的なショートカットキーはCtrl+Vです。複数のリンクは1行に1つずつ並べてください。リモートURLがなくBase64形式の本文だけがある場合は、先にローカルでリンク一覧へ戻してから読み込むと、問題の切り分けが容易です。
- 再更新で上書きされます:サブスクリプションのノードはリモート側で管理されるため、手動で変更しても次回の更新で置き換わることがあります。長期保存する変更は、別のレコードとして保存してください。
- ローカルの設定値を流用しない:設定例では
127.0.0.1:10808がよく使われますが、実際の待ち受けポートは使用中のクライアント設定で確認してください。サブスクリプションノードの443から推測することはできません。 - JSONには専用の読み込み先を使用:完全なコア設定は、「サーバー」にあるカスタム設定の追加機能から読み込みます。通常のノードレコードとは編集やエクスポートの機能が異なる場合があります。
5. v2rayNGに読み込む:更新元と静的リンクを区別する
v2rayNGは、AndroidでXrayコアを使用するクライアントです。一般的な画面では、リモートサブスクリプションは右上のメニューで管理し、静的リンクはメイン画面のプラスボタンから読み込みます。どちらもノード一覧に表示されますが、サブスクリプション元が保持されるのは前者だけです。デスクトップ版からエクスポートした共有リンクをコピーしても、更新スケジュールやグループ設定は引き継がれません。
-
更新元を追加
右上の「⋮」→「サブスクリプショングループの設定」を開き、「+」をタップします。備考と完全なサブスクリプションURLを入力して保存し、メイン画面に戻ります。
-
ノードを取得
「⋮」→「サブスクリプションを更新」を開きます。バージョンによって現在のグループと全グループの更新項目がある場合は、対象のサブスクリプションを含む範囲を選び、更新結果を確認します。
-
静的リンクを読み込む
共有リンクを受け取った場合は、テキスト全体をコピーし、メイン画面の「+」→「クリップボードからインポート」をタップします。サブスクリプションページのログイン案内などを一緒にコピーしないでください。
-
起動して確認
対象のノードを選び、接続を開始して、システムのVPN許可画面で承認します。実際に接続をテストし、アプリからのアクセスも確認してください。TCP遅延が表示されるだけでは、プロキシ経由の通信が成功したとは限りません。
2台の端末へ移行:同じ更新元を登録し、各端末の設定を個別に確認
デスクトップ:v2rayN
- 元のHTTPS URLをサブスクリプショングループに保存します。
- ノードで必要なプロトコルが現在のコアに対応しているか確認します。
- システムプロキシ、DNS、ルーティングルールを個別に設定します。
Android:v2rayNG
- ノードの備考だけをコピーするのではなく、同じサブスクリプションURLを追加します。
- 更新後、重要なパラメーターとノードの接続可否を確認します。
- VPNの許可とアプリごとのプロキシ適用範囲を個別に確認します。
同じ更新元を使うと管理しやすくなりますが、取得できる一覧はアカウント、リクエスト条件、サーバー側の方針によって変わる場合があります。両端のノード一覧や設定が自動で同期されることはありません。
6. 形式を相互変換する:引き継げる情報を先に確認
共有リンクとBase64形式のリンク一覧は、通常はテキストの包み方が異なるだけです。一方、JSON設定と共有リンクは1対1で対応しません。完全な設定には、複数のアウトバウンド、直結・ブロックルール、DNS、受信待ち受け、アウトバウンドの選択ロジックが含まれることがあります。単一ノードのリンクで表せるのは、通常、特定のプロキシ接続に必要な情報だけです。設定全体のバックアップにはなりません。
元のサブスクリプションURLを保持する
おすすめ両方の端末に同じリモート更新元を登録します。URLが変わらなければ、更新元で管理されるノードの変更を引き続き受け取れます。複数端末で利用できるかは、サービス提供元のアカウント規約に従ってください。
おすすめの用途:複数端末で継続的に更新したい場合。
ノードの共有リンクをエクスポート
ノードの右クリックメニューや共有機能から、「共有URLをエクスポート」「リンクをコピー」などを選択します。移行先で読み込んだ後、各パラメーターを確認してください。これはノードの静的なスナップショットであり、サブスクリプショントークンや自動更新の設定は含まれません。
おすすめの用途:少数のノードを一時的に移行する場合や、単一ノードの接続情報を確認する場合。
完全なコアJSONを保持
カスタム設定の読み込みから移行し、コアの互換性、ローカルパス、待ち受けアドレスとポートを確認します。クライアントが実行時に生成した設定を、そのまま複数のプラットフォームで使える汎用バックアップと見なさないでください。
おすすめの用途:複数のアウトバウンド、DNS、複雑なルーティング設定を保持する場合。
リンク一覧とBase64形式のサブスクリプション本文を相互変換
- 移行先のクライアントが対応する完全な共有リンクを集め、1行に1つずつ並べます。チャット履歴に含まれる引用符、番号、説明文は取り除いてください。
- テキスト全体をUTF-8でBase64に変換すると、一般的なBase64形式のサブスクリプション本文になります。逆方向の変換では1回だけデコードし、リンクを1行ずつ復元します。
- クライアントに読み込む前に、先頭行のプロトコル接頭辞、行数、日本語の備考が正しいか確認します。エンコードできても、すべてのノードが接続できるとは限りません。
- URL経由で更新したい場合は、本文を実際に返す管理下のHTTPSサーバーも必要です。Base64テキストを作っただけでは、サブスクリプションURLは作成されません。
JSONと単一ノードリンクを相互変換
JSONからノード情報を取り出す場合は、まずoutbounds内で実際に使われているVMessまたはVLESSのアウトバウンドを特定し、使用中のコアの設定形式に従ってサーバー、ユーザー認証、streamSettingsを読み取ります。最初のアウトバウンドを選べばよいとは限りません。直結用だったり、ほかのアウトバウンドに依存するチェーン接続だったりする場合があります。XrayとV2Rayでは利用できる設定や項目が異なり、バージョンによる違いもあります。
- リンクからJSONへ:まずクライアントにリンクを読み込ませ、クライアント側で実行用の設定を生成します。これにより、単独のアウトバウンド設定だけではなく、ローカルの受信、DNS、ルーティング設定も反映されます。
- JSONからリンクへ:アウトバウンドの設定だけで表現できる場合に限り、エクスポートしてください。カスタム設定を読み込んだ場合、汎用的な単一ノード共有機能を利用できないことがあります。
- リンクに含まれない情報:受信待ち受け、ドメイン別の振り分け、DNSポリシー、ルールの優先順、アウトバウンドのチェーン接続は、通常の共有リンクでは引き継げません。
- 変換後に再確認:アドレス、ポート、UUID、通信方式、パス、Host、SNI、TLSまたはREALITYのパラメーターを比較してから、接続テストを行います。
7. 読み込みエラーを解決する:応答・解析・接続の順に確認
まず、どの段階で失敗しているかを特定してください。サブスクリプションの更新エラーはリクエストが成功していない可能性があります。「読み込めるノードが0件」と表示される場合は、テキスト形式に対応していない可能性があります。ノードが表示されてもアクセスできない場合は、接続パラメーターやプロキシの適用範囲を確認します。これらを混同すると、実際の原因を直せないままエンコードを繰り返したり、コアを切り替えたりすることになります。
| 症状 | まず確認する項目 | 対処方法 |
|---|---|---|
| 更新時に401または403が返る | サブスクリプショントークン、認証状態、アクセス条件 | サービス提供元から有効なURLを再取得し、Base64の内容は変更しない |
| 本文がHTMLで始まる | ログインページ、リダイレクトページ、リクエスト遮断ページ | 最終的な応答とサブスクリプションのURLを確認し、ページのソースをノードとして扱わない |
| Base64のデコードに失敗する | コピー時の欠落、文字の違い、パディング | 全文を確認し、Base64URLを正規化してからUTF-8でデコードする |
| 更新は成功するが、ノードが0件 | 応答が対応するリンク一覧かどうか | デコード後のプロトコル接頭辞と、サーバーの出力形式を確認する |
| ノードはあるが、ハンドシェイクに失敗する | TLS、SNI、システム時刻、通信パラメーター | ノードの各項目に戻って比較し、形式の問題と接続の問題を混同しない |
| 接続できるが、一部のアプリで利用できない | システムプロキシ、VPN、アプリごとのルール | ローカルでプロキシが適用される範囲を確認し、サブスクリプションを再エンコードしない |
サブスクリプション更新後にノード数が変わるのはなぜですか?
サーバー側でノードが変更されている場合や、クライアントが非対応または重複する項目を除外している場合があります。まず更新ログと実際の応答形式を確認し、プロトコルの対応状況と照らし合わせてください。件数が違うだけで変換時にノードが失われたと判断したり、自動管理されるサブスクリプショングループに古いノードを手動で追加し直したりしないでください。
JSONの解析に成功しても、クライアントに拒否されるのはなぜですか?
有効なJSONであることが示すのは、構文が正しいという点だけです。VMess共有用JSON、サブスクリプションAPIのJSONエラー応答、コア設定は、いずれも構文解析できても用途が異なります。設定の構造、プロトコルの対応状況、読み込み先も確認してください。コア設定はカスタム設定の読み込みから確認します。
共有リンクだけをバックアップすれば、DNSやルーティング設定も復元できますか?
通常はできません。共有リンクに保存されるのは、主にノードの接続情報です。移行前にクライアントのDNS、システムプロキシ、ルーティングモード、カスタムルールも記録してください。完全な設定は別途保存します。読み込み後は、まず単一ノードで接続を確認し、その後ルーティング設定を戻すと、ノードとルールのどちらに問題があるか切り分けやすくなります。