V2Rayの複数デバイス間で設定を同期する方法｜サブスクリプションの共有・設定のエクスポート・QRコード

ノードの同期と設定全体の移行を区別する

Macで使えるノードでも、ファイルをコピーするだけでAndroid端末でも同じプロキシ動作になるとは限りません。ノードにはサーバーアドレス、ポート、認証情報、通信パラメーターが保存されます。ルーティングはリクエストを直接接続・プロキシ・遮断のどれにするかを決め、システムプロキシやローカルリスナーはアプリの通信をクライアントに渡します。それぞれ異なる設定レイヤーです。

v2rayNはWindows、macOS、Linux向けのデスクトップクライアントです。Android版のv2rayNGはXrayカーネル、v2flyNGはV2Flyカーネルを使用します。クライアントの画面から特定形式をインポートできても、そのカーネルがすべてのプロトコルやフィールドに対応しているとは限りません。特にREALITYなどの機能を使うVLESSノードは、ノード名が同じかどうかだけで判断せず、移行先のカーネルが対応しているか確認してください。

サブスクリプション・エクスポート・QRコードの選び方

「同期」といっても、通常は2台のクライアント間でリアルタイムに設定が共有されるわけではありません。サブスクリプションを共有する場合、各端末が同じ提供元からそれぞれノードを取得します。QRコードや設定ファイルは、エクスポート時点の情報を保存したスナップショットです。元の端末で設定を変更しても自動更新されず、サーバー側で認証情報が変更されても自動修復されません。

サブスクリプション共有：各端末で個別に登録・更新

まず、サブスクリプションの提供元が認める端末数、同時接続数、通信量のルールを確認してください。同じURLを使っても複数の端末が1つの接続になるわけではなく、提供元の利用制限を回避できるわけでもありません。サービスによってはクライアントごとに異なる内容が返されるため、両端末の項目数が違っても、必ずしも同期の不具合とは限りません。

以下では、簡体字中国語の画面に表示されるメニュー名を記載しています。v2rayNはデスクトップ版のビルドによって、ボタンがメニュー内またはグループパネル内に配置されている場合があります。Android版では右上のメニューを使います。画面構成が異なる場合は、「サブスクリプショングループ設定」「サブスクリプションを更新」に相当する機能名を探してください。サブスクリプションURLをノード単体のアドレス欄に入力しないよう注意してください。

1. サブスクリプションの提供元を記録

   サービスの管理画面から完全なサブスクリプションURLを取得し、クエリパラメーターも含めて保存します。グループ名を「普段使いのサブスクリプション」などに設定し、提供元が対応する形式も記録してください。途中で省略表示されたリンク文字列だけをコピーしないようにします。

2. デスクトップ版でグループを追加

   v2rayNで「サブスクリプショングループ」→「サブスクリプショングループ設定」→「追加」を開き、別名とサブスクリプションURLを入力して保存します。メイン画面に戻り、「サブスクリプショングループ」メニューから該当するすべてのサブスクリプションの更新操作を実行します。

3. Android版でグループを追加

   v2rayNGで右上のメニュー→「サブスクリプショングループ設定」→「+」を開き、メモとURLを入力します。保存してメイン画面に戻り、右上のメニューから「サブスクリプションを更新」を実行します。

4. ノードの内容を確認

   両端末で同じ名前のノードを1つずつ選び、サーバーアドレス、ポート、プロトコル、通信パラメーターを比較します。名前はメモにすぎず、同じ名前でも設定が完全に一致するとは限りません。まず手動で1回更新し、その後に更新スケジュールを設定してください。

5. 更新方法を確認

   サブスクリプションを直接接続で取得できる場合は、まず直接接続で動作を確認します。サブスクリプションURLへのアクセスにプロキシが必要な場合に限り、プロキシ経由の更新を選んでください。更新に失敗しても接続手段を失わないよう、動作中の旧ノードを残しておきます。

設定のエクスポート：ファイルの種類を見極めて復元範囲を決める

config.jsonという名前のファイルを見つけても、ファイル名だけで用途を判断せず、まず構造を確認してください。inbounds、outbounds、routingを含むものは、通常、カーネルの実行設定です。クライアントのバックアップには、グループやサブスクリプションの提供元、画面設定が含まれる場合もあります。両者は別のデータであり、インポート機能も互換ではありません。

v2rayNは、選択中のノードやルールをもとに実行設定を生成する場合があります。生成されたファイルを直接編集すると、次にノードを切り替えたりカーネルを起動したりした際に上書きされる可能性があります。長期的に維持する設定は、クライアントが対応するカスタム設定またはルールの機能から保存してください。別のPCへ移行する前に、アプリ標準のエクスポート機能でバックアップを作成します。

• 同じ種類のデスクトップ環境への移行：クライアントを終了してからユーザーデータをバックアップし、OSとクライアントのビルド情報を記録します。移行先の既存データは残しておき、バックアップの互換性を確認してから復元してください。
• 異なるOS間の移行：Windows、macOS、Linux間でプログラムのディレクトリ全体をそのまま上書きしないでください。証明書のパス、データディレクトリ、起動項目、権限の扱いが異なる場合があります。
• Androidへの移行：まずサブスクリプションまたは共有リンクを再インポートしてください。移行先のクライアントにカスタム設定のインポート機能があり、使用するカーネルがそのファイルに対応している場合に限り、カーネル設定全体の移行を検討します。
• ルールの外部依存ファイル：ルールデータ、証明書、カスタムパスを確認します。JSONファイルを読み込めても、依存ファイルが移行済みとは限りません。

復元後は、まずノードを1つテストしてからルーティングを追加してください。クライアントで未対応のフィールドが表示された場合は、エクスポート元とインポート先のカーネル種類および設定形式を確認します。エラーが出たフィールドを手当たり次第に削除しないでください。通信方式やセキュリティのパラメーターを削除すると、接続条件が変わる可能性があります。

QRコードでの共有：ノード1件向け。バックアップの代用にはならない

デスクトップ版では、選択したノードの共有またはエクスポート機能から共有リンクやQRコードを取得できます。Android版v2rayNGでは、右上の「+」→「QRコードをスキャン」を使うか、リンクをコピーして「クリップボードからインポート」を選びます。信頼できる自分の端末に表示された内容だけを読み取り、インポート後もノードの詳細を開いて確認してください。

vmess://とvless://は異なる共有形式です。先頭部分を書き換えて相互変換することはできません。QRコードには通常、認証情報が含まれます。長いリンクはQRコードの密度、画面の拡大率、カメラのピントによって読み取りにくくなる場合もあります。読み取りに失敗した場合は、信頼できるローカルな方法で完全なURIを送ってください。長いパラメーター列を手入力するのは避けましょう。

1. 送信元では、動作確認済みのノードを1つだけ選んで共有情報を作成します。サブスクリプションURLをノード単体のQRコードと取り違えないようにしてください。
2. 移行先では、インポート後にサーバーのポート、UUID、通信方式、TLSの有効・無効、サーバー名を確認します。REALITYを使う場合は、公開鍵やshort IDなどのパラメーターも確認してください。
3. 移行先の端末だけで接続テストを行います。送信元では接続できるのに移行先では失敗する場合、まずプロトコルの対応状況とネットワーク環境を確認し、その後にコピー内容が完全か確認してください。
4. インポート結果を確認したら、一時的なスクリーンショットや転送履歴を削除します。後でノードが変更された場合は、再度共有するかサブスクリプションを更新してください。

ルーティングの再利用：方針をそろえ、端末固有の設定は個別に管理

ルーティングを同期する際は、ルールの順序、照合フィールド、アウトバウンドタグを比較してください。どちらの画面にも「LANをバイパス」と表示されていても、ルール全体が一致するとは限りません。geositeやgeoipを使うルールは、移行先に対応するデータファイルも必要です。クライアント独自のルールプリセット名を、共通のインポート形式として扱わないでください。

以下はローカルプロキシのトラブルシューティングに使える例であり、すべてのバージョンの初期設定を示すものではありません。実際のポートはクライアントの現在のリスニング設定で確認し、対応するリスナーがある場合にのみ入力してください。

クライアントを端末ごとに独立して実行する場合、各端末の127.0.0.1はその端末自身を指します。Macのシステムプロキシアドレスを別のPCにそのまま入力しても、Macには接続されません。LAN内の他の端末にプロキシを共有するには、リスニングアドレス、ファイアウォール、アクセス制御の設定が必要です。これは設定同期とは別の運用方法です。

移行後の動作確認と認証情報の管理

動作確認は設定レイヤーごとに進めます。まずサブスクリプションを取得できるか、次にノードへ接続できるか、最後にアプリのリクエストがルーティングどおりのアウトバウンドに送られるかを確認してください。ノードのテストに成功しただけでは、システムプロキシが有効とも、すべてのアプリがプロキシを使っているとも限りません。

サブスクリプションURLにはアカウントのトークンが含まれていることが多く、共有URIにもノードの利用に必要な情報が含まれます。Base64は暗号化ではなくエンコードであり、QRコードも認証情報を隠しません。これらを公開ドキュメントや公開スクリーンショットに載せたり、オンライン変換ツールに入力したりしないでください。保存が必要な場合は、アクセスを制限した暗号化ストレージを使ってください。

• 更新前に復元ポイントを作成：直前に使えていた設定とルールを保存し、エクスポート日、提供元、移行先のクライアントを記録します。ファイル名に完全なアドレスやトークンを含める必要はありません。
• 自動更新は事前に検証：まず手動で取得と接続をテストしてから自動更新を設定します。端末のスリープやバックグラウンド動作の制限によって、実行時刻がずれることがあります。
• 同時書き込みによる上書きを防止：実行中のクライアントデータベースを、ファイル同期ツールで同時に書き換えないでください。実行用ディレクトリを複数の端末で共有すると、上書きや競合、状態の消失につながるおそれがあります。
• 漏えいした認証情報を更新：サブスクリプションの提供元でURLまたは認証情報を再発行し、各端末で順に更新します。端末内のスクリーンショットを削除しても、漏えいした認証情報を無効にはできません。

最後に、ノードの更新元、ルールの復元方法、端末で使う通信の取り込み方式を簡潔に記録しておけば十分です。端末を買い替えた際に設定を再現しやすくなり、問題が起きたときも、サブスクリプション、カーネル、ルーティング、システムプロキシのどこに原因があるか切り分けられます。