V2Rayの複数デバイス設定同期の方法：サブスクリプションURL・QRコード・設定エクスポートを比較

ノード同期とクライアント設定の同期を分けて考える

「複数デバイスの設定同期」には、通常まったく異なる2種類のデータが含まれます。1つ目はサーバーノードで、アドレス、ポート、ユーザー識別子、VMessまたはVLESSのプロトコルパラメータ、TLS、REALITY、トランスポート方式、偽装用フィールドなどです。2つ目はクライアント側の設定で、システムプロキシ、ルーティングモード、DNS、ログレベル、LANリスニング、アプリごとのプロキシ、自動更新間隔などが該当します。サブスクリプションURLで扱えるのは主に前者で、後者の一部まで引き継げるのは設定エクスポートです。

「ノード一覧が同じ」だからといって、「動作も完全に同じ」とは限りません。たとえばデスクトップ版のv2rayNでは、ローカルのSOCKSポートに10808、HTTPポートに10809を使うことがあります。一方、Android版のv2rayNGは通常、システムVPNインターフェースで通信を処理します。画面上にローカルSOCKSポートが用意されていても、Windowsのシステムプロキシとは適用範囲が異なります。デスクトップのポート番号をAndroidへそのまま移しても、同じ通信処理を再現できるわけではありません。

方法1：同じサブスクリプションでノード一覧をそろえる

サブスクリプションURLは、複数デバイスの管理コストを最も抑えやすい方法です。サーバー側で複数の共有設定を1つのURLにまとめ、クライアントが定期的に取得してノードを解析します。パソコンのv2rayNとAndroidのv2rayNGに同じURLを保存できますが、更新、使用するノードの選択、ルーティング、システムプロキシの状態は端末ごとに個別管理されます。

v2rayNでは、「サブスクリプショングループ」→「サブスクリプショングループ設定」からサブスクリプションを追加し、名前と完全なURLを入力します。保存後、「すべてのサブスクリプションを更新（プロキシを使用しない）」を実行します。現在のネットワークからサブスクリプションURLへ直接アクセスできない場合は、利用可能なノードに接続してから、プロキシ経由で更新します。バージョンによってメニュー名は多少異なりますが、グループを作成してから手動でノードを更新する流れは同じです。

v2rayNGでは、左上のメニューから「サブスクリプショングループ設定」を開き、右上の追加ボタンをタップしてメモとサブスクリプションURLを入力します。保存後、メイン画面の右上メニューから「サブスクリプションを更新」を実行します。完了後にノード数が変化することを確認してください。0件のままなら、URLが改行で途切れていないか、サブスクリプショングループが有効か、そのURLへ現在のネットワークからアクセスできるかを確認します。

自動更新の間隔を短くしすぎる必要はありません。ノードの変更が少ない場合は24時間ごとの更新がおすすめです。サーバー側の変更をすぐ反映したいときだけ手動更新します。60個のノード、1回のサブスクリプション応答が約80 KBの場合、2台のデバイスが毎日1回更新しても、1か月のデータ量は5 MB未満です。重視すべきなのは通信量ではなく、更新に失敗したとき古いノードが残るか、手動追加したノードが誤って削除されないかです。

方法2：少数のノードをQRコードで移行する

QRコードは「今使っているノードを隣のデバイスへ渡す」用途に適しており、長期的な同期には向きません。v2rayNで選択したサーバーのQRコードを生成し、v2rayNGで読み取ってインポートできます。QRコードに含まれるのは通常、プロトコル、サーバーアドレス、ポート、トランスポートパラメータなどを含む共有URLで、サブスクリプションによる自動更新機能はありません。

実際の操作では、まずv2rayNのサーバー一覧から対象ノードを選び、QRコードを表示します。Android側ではv2rayNGを開き、右上の追加メニューから「QRコードをスキャン」を選択します。読み取り後すぐに接続せず、設定を展開して、アドレス、ポート、ユーザー識別子、トランスポート方式、TLSのセキュリティ方式、SNIまたはserverNameなどを項目ごとに確認してください。

1. 数量を管理：一度に1つずつ移行し、インポート後すぐに「仕事用回線-QR-0627」のようなメモへ変更します。サブスクリプション内の同名ノードとの混同を防げます。
2. プロトコルを確認：VMessとVLESSでは、認証情報の項目と暗号化の意味が異なります。サーバーアドレスが同じかどうかだけで判断しないでください。
3. トランスポートを確認：WebSocketではパスとHost、gRPCではserviceNameを確認します。REALITYではserverName、publicKey、shortIdも確認してください。
4. 接続をテスト：まず接続テストを行い、その後ウェブページを開いてDNSとルーティングを確認します。クライアントに表示される遅延値だけで判断しないでください。

QRコードには容量の制限があるため、複雑なJSON設定、長い証明書情報、多数のルールを含む完全な設定の直接エンコードには向きません。読み取りに成功しても、クライアントが共有URLの標準フィールドだけを認識し、元のクライアントにあるルーティンググループ、DNSの振り分け、ローカルリスニング設定を無視することがあります。QRコードは、一度きりのノードコピー手段と考えるのが適切です。

方法3：設定ファイルをエクスポートして複雑な設定を保持する

設定エクスポートは、同じ種類のクライアントをバックアップしたり、手作業で作成したルーティングやDNSを保存したりする場合に適しています。ただし、汎用的な同期形式ではありません。v2rayNのアプリ設定、サブスクリプショングループのデータ、コアの実行設定は別々のファイルに保存されることがあります。v2rayNGがエクスポートするノード一覧も、デスクトップ側の設定をそのまま上書きできるパッケージではありません。別のクライアントへインポートする前に、そのファイルが「クライアントデータベース」「共有URLの集合」「コアJSON設定」のどれに当たるかを確認してください。

コアJSONには通常、inbounds、outbounds、routing、dnsなどのセクションが含まれます。Xrayまたはv2flyコアが通信を処理する方法を正確に記述できますが、クライアントの画面ですべての手書きフィールドを編集可能なフォームへ戻せるとは限りません。デスクトップで生成したコア設定をAndroidへそのままインポートすると、デスクトップ専用のリスニングアドレスやポートが入り込む可能性もあります。

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

上記のリスニングアドレス127.0.0.1は、ローカルからの接続だけを受け付けることを示し、デスクトップのローカルプロキシに適しています。LAN内のデバイスへプロキシを提供する場合は、リスニング方針とファイアウォールルールを別途設定してください。AndroidでシステムVPNにより通信を処理する場合、このインバウンド設定を同等の設定とみなすことはできません。ファイルを移行するときは元のバックアップを残し、動作中の設定を直接上書きしないでください。

v2rayN、v2rayNG、v2flyNGの組み合わせ方

デスクトップではv2rayNを使い、サブスクリプション、システムプロキシ、ルーティングを管理します。AndroidでXrayコアや新しいVLESS、REALITY設定が必要な場合はv2rayNGを使用できます。VMessなどv2flyコアが対応する設定を中心に使う場合は、v2flyNGも選択肢になります。3つのクライアントはいずれも、サーバーが生成した標準サブスクリプションや共有URLを読み込めますが、アプリ固有の設定を別のアプリへそのまま上書きしないでください。

同じサブスクリプションにVMess、VLESS、異なるトランスポート方式が混在している場合は、更新後にプロトコルやメモで絞り込み、現在のクライアントで正しく動作するノードを選びます。ノード名が同じだからといって、両端末の実際のパラメータまで同じとは限りません。サーバー側でUser-Agentごとに異なる内容を返したり、クライアントの機能に応じて形式を変換したりすることがあります。

• 日常の基本構成：Windowsではv2rayN、Androidではv2rayNGを使い、両方に同じサブスクリプションURLを保存します。
• v2flyコア構成：Androidではv2flyNGを使い、サブスクリプション内でv2flyコアとの互換性が明記されたVMessなどの設定を優先します。
• ルール管理の原則：ノードはサブスクリプションで集中管理し、デスクトップのルーティングとAndroidのアプリごとのプロキシはそれぞれ保存します。設定ファイルを完全に同じにする必要はありません。
• 更新の順序：まずサブスクリプションを更新し、ノード数を確認します。次にノードを選んで接続を再起動し、最後にログと実際のアクセス結果を確認します。

48個のノードを含むテスト用サブスクリプションでは、v2rayNとv2rayNGをそれぞれ更新した後、どちらも48個と表示され、ノード集合が一致しました。ただし、デスクトップでは「LANをバイパス」するルーティング、Androidでは指定アプリのみのプロキシを有効にすると、実際の通信経路は大きく異なります。この結果からも、サブスクリプションは共通の入口を担い、端末ごとのポリシーはローカルで管理すべきだと分かります。

移行後の確認手順とトラブルシューティング

同期が完了したら、まず設定が完全かを確認し、その後で速度の問題を調べます。「数量、項目、接続、ルーティング、DNS」の5段階で確認すると、サブスクリプションが更新されていないのか、ノードパラメータが不足しているのか、クライアント側の設定が異なるのかをすばやく切り分けられます。

1. ノード数を確認：たとえば元のデバイスが36個を表示しているなら、移行先も更新後にほぼ36個になるはずです。0個の場合は、サブスクリプションの取得または解析に失敗していることが多いです。
2. 3つのノードを抜き打ち確認：アドレス、リモートポート、プロトコル、TLS、トランスポート方式、メモをそれぞれ確認します。先頭の1件だけを確認しないでください。
3. 接続を確立：コアのログにタイムアウト、証明書名の不一致、接続先による拒否、ポートの競合が出ていないか確認します。
4. ローカル側の通信処理を確認：v2rayNではシステムプロキシのモード、v2rayNGではシステムVPNの許可とアプリごとのプロキシ範囲を確認します。
5. DNSを確認：接続はできるのにドメインを開けない場合は、DNS設定とルーティングルールを確認します。IPアドレスへアクセスできても、ドメイン名の名前解決が正常とは限りません。

速度測定の結果は、あくまで選別の参考値です。1回の遅延測定が85ミリ秒でも、ウェブ閲覧、動画、大容量ファイルの通信が安定するとは限りません。3回続けて測定し、大きな変動がないか確認してください。たとえば82、310、96ミリ秒と続くなら、経路に一時的な混雑があります。3回とも90～110ミリ秒なら、通常は安定性が高いと判断できます。

長期利用に適した同期戦略

安定した複数デバイス構成では、すべてのスイッチを同じにする必要はありません。サブスクリプション層でノードの取得元を統一し、クライアント層でプラットフォームに応じたポートと通信処理方式を保存し、ルール層で端末の用途に合わせてルーティングとDNSを管理する3層構成が合理的です。これならデバイスを交換しても、サブスクリプションと少数の端末設定を復元するだけで済みます。

毎月1回は手動で確認することをおすすめします。無効になったサブスクリプショングループを削除し、更新URLが有効か確認し、QRコードで重複登録したノードを整理します。また、動作中の複雑なルール設定を1部エクスポートしておきます。ファイルにはクライアント名と日付を付け、たとえばv2rayN-routing-2026-06-27.jsonのように保存すると、数か月後に別のクライアントへ誤ってインポートするのを防げます。

最終的な選択はシンプルです。2台を超えるデバイスで継続的な更新が必要なら同じサブスクリプション、単一ノードを一時的に共有するならQRコード、同じ種類のクライアント間で複雑なルールをバックアップするならエクスポートファイルを使います。3つの方法は組み合わせられますが、QRコードをサブスクリプションとみなしたり、特定クライアントの完全な設定ファイルをクロスプラットフォームの標準形式として扱ったりしないでください。