v2rayN 全プラットフォーム対応インストール・設定ガイド

共通の準備：インストーラーと接続情報

クライアント・コア・ノードの違い

v2rayNはデスクトップ向けのGUIクライアントです。サーバー情報の保存、サブスクリプションの更新、実行用設定の生成、プロキシの入口の制御を担います。実際に接続を処理するのはコアで、ノードはリモートサーバーのアドレスや認証情報を指します。クライアントをインストールしても、接続可能なノードが自動で用意されるわけではありません。サブスクリプションを入手しても、すべての項目が現在のコアに対応しているとは限りません。設定を始める前に、提供元から受け取ったものがサブスクリプションURL、単一の共有リンク、完全な設定ファイルのどれなのか、対応プロトコルとクライアントも確認しましょう。

デスクトップでは、Windows、macOS、Linuxに対応するv2rayNが便利です。Androidでは、一般的な設定がXrayコアを前提とするv2rayNGを使用します。V2Flyの設定が必要な場合は、v2flyNGも検討してください。コアの名前が似ていても、プロトコルの項目がすべて同じとは限りません。特にREALITY、フロー制御、トランスポートの設定は、使用中のアプリで選択できる項目を基準にしてください。あるクライアントが出力した実行用設定を、別のアプリでも使える汎用サブスクリプションとして扱わないようにしましょう。

システムのアーキテクチャとインストール要件を確認

クライアントのダウンロードページでOSに合ったインストーラーを選び、CPUアーキテクチャも確認してください。Windows向けのダウンロードはx64です。Macは「このMacについて」でチップを確認し、Apple SiliconとIntelに合ったものを選びます。Linuxではアーキテクチャとパッケージ形式の両方を確認してください。Androidは端末のアーキテクチャを確認し、通常はarm64を選びます。判断できない場合や、アーキテクチャ不一致のエラーが出た場合は汎用版を検討しましょう。拡張子だけで互換性を判断したり、名前が似ていても異なるアーキテクチャのパッケージを繰り返しインストールしたりしないでください。

アプリと設定の保存に必要な空き容量を確保し、現在のアカウントでソフトウェアをインストールできることを確認します。通常のシステムプロキシの利用に、管理者権限での常時実行は必要ありません。一方、TUN、仮想ネットワークアダプター、ルーティングの変更では追加の許可が必要になることがあります。組織管理下の端末では、ネットワーク拡張、VPN、プロキシ設定の変更が制限されている場合があります。管理ポリシーでブロックされた場合は、まず端末の利用ルールを確認してください。また、システムの日付と時刻も正確に設定しましょう。大きくずれていると、正常な暗号化接続でもハンドシェイクに失敗することがあります。

最小構成で動作を確認する

初回設定では、ネットワークを制御する他のプロキシやVPNを一時的に停止し、テストするクライアントだけを使用します。元のシステムプロキシとDNSの設定は、復元できるよう記録しておきましょう。まずシステムプロキシでブラウザーの接続を確認し、その後にTUNを試します。ノード、ルーティング、DNS、ネットワークアダプターを一度に変更しないでください。複数の項目を同時に変更すると、接続が復旧しても原因を特定できず、ネットワークを切り替えた際に同じ問題が再発することがあります。

サブスクリプションURLにはアカウント情報やアクセストークンが含まれることがあるため、機密情報として扱ってください。URL全体を公開スクリーンショット、オンライン変換ツール、トラブル相談に貼り付けないでください。ログを共有する場合も認証情報を隠しましょう。直結の確認用に正常に開ける一般的なWebページを用意し、もう一つ、現在のノード経由でアクセスするページも用意します。アプリ名、システムプロキシの使用有無、TUNの有効・無効も併せて伝えると、「ネットにつながらない」とだけ説明するより原因を絞り込みやすくなります。

このガイドでは操作の順序と設定項目の関係を説明します。メニュー名は画面の更新に伴い変更される場合があります。同じ名前の項目が見つからない場合は、「サブスクリプション」「システムプロキシ」「ルーティング設定」などの機能から探してください。他のOSのスクリーンショットと完全に同じ場所を探す必要はありません。すでに接続できている場合は該当する章へ進んでください。インポートや有効化の順序が分からない場合は、先にクイックスタートガイドを完了してから、ルールベースの振り分けやTUNを追加しましょう。

Windows：v2rayNのインストールとシステムプロキシ

デスクトップ版と従来のWPF版から選ぶ

Windowsのダウンロード一覧を開き、用途に合わせてv2rayNのデスクトップ版または従来のWPF版を選んでください。デスクトップ版はクロスプラットフォームのUIを採用しており、複数のデスクトップOSで似た操作感を求める方に向いています。WPF版はWindows向けの従来型UIです。メニュー構成が異なる場合があるため、トラブルの相談時にはどちらを使っているか伝えてください。クライアントを2つ同時に起動してローカルの待ち受けポートを競合させないようにしましょう。後から起動したコアが入口を確保できなくなることがあります。

インストーラーの案内に従ってインストールします。初回起動時は、ノードを追加する前にメイン画面が正常に表示されることを確認してください。アプリがすぐに終了する場合は、ネットワーク設定を変更するのではなく、まずシステムの通知とアプリのログを確認します。実行環境が不足している場合は、アプリが要求するランタイムをインストールしてください。従来のWPF版はデスクトップコンポーネントを使用するため、用途の異なるランタイムで代用はできません。必要な依存関係はインストーラーの案内に従い、正常に動作している場合は無関係なコンポーネントを追加で入れる必要はありません。

サブスクリプションを追加して使用するサーバーを選ぶ

サブスクリプショングループの設定で新しいグループを作成し、判別しやすい名前を入力して、完全なサブスクリプションURLを貼り付けます。保存したら、現在のサブスクリプションを更新してください。グループを保存しただけでは、ノードが取得されていない場合があります。更新後、該当グループに切り替えてサーバーが一覧に表示されたことを確認し、その中から使用するサーバーを選びます。ブラウザーからURLをコピーする場合は、アカウントページや注文ページのURLではなく、提供元が案内したサブスクリプションURLをコピーしてください。

単一の共有リンクを使う場合は、クリップボードからのインポートとサブスクリプションの更新を区別してください。インポート後、サーバーアドレス、ポート、プロトコル、トランスポート方式を確認します。リンク末尾の名前や説明をサーバーアドレスと取り違えないようにしましょう。初回の動作確認では、利用可能と分かっている候補を一つだけ残し、自動切り替えや一括テストによる影響を減らします。リストに表示される遅延時間は、特定のテスト方法による結果にすぎません。実際のWebアクセスの代わりにはならず、その結果だけでプロトコル設定が正しいとも判断できません。

システムプロキシを有効にしてルーティングを確認

コアが正常に起動したら、システムプロキシのメニューから自動設定を選択します。Windowsのシステムプロキシ設定に従うアプリが、クライアントのローカル入口を利用するようになります。システムプロキシはリクエストをクライアントに渡し、ルーティングは受け取ったリクエストを直結とプロキシのどちらに送るかを決めます。この二つは別の設定です。「中国本土をバイパス」のプリセットを選んでも、システムプロキシが有効になるとは限りません。システムプロキシを有効にしても、すべてのアプリがその設定に従うわけではありません。ターミナル、開発ツール、一部のダウンローダーでは、個別にプロキシを設定する必要があります。

テストページを開き直して確認し、以前の接続を保持しているアプリは必要に応じて再起動します。ブラウザーでは接続できるのにコマンドラインでは直結する場合、サブスクリプションを再インポートするのではなく、コマンドラインツールがどの設定からプロキシを取得しているかを確認してください。ブラウザー独自のプロキシ拡張機能がシステム設定を上書きしていることもあります。モードの違いはシステムプロキシとルーティングモードの解説を参照してください。OSごとに画面は異なっても、入口の設定と出口の選択は別の階層です。

TUNの権限設定と終了時の復元

システムプロキシに従わないアプリを接続したい場合や、より広範囲にネットワークを制御したい場合に限り、TUNを有効にしてください。他の仮想ネットワークアダプター管理ツールを停止し、クライアントの案内に従って必要な権限を付与します。コアのログでネットワーク入口が正常に作成されたことも確認してください。セキュリティソフトがネットワークコンポーネントをブロックする場合は、対象と用途を確認します。すべての保護機能を無効にしないでください。組織のポリシーで制限された端末では、管理者権限があっても制限を解除できない場合があります。

終了する前にTUNを無効にし、クライアントが設定したシステムプロキシを解除してください。異常終了後にブラウザーからまったく接続できず、クライアントも起動していない場合は、Windowsのプロキシ設定にローカルアドレスを指定した手動プロキシが残っていないか確認します。ネットワークを復旧する際は今回の設定だけを元に戻し、正体の分からないネットワークアダプターを削除したり、ネットワーク全体をリセットしたりしないでください。起動時の問題については、ランタイムと起動権限のトラブル対処も参照し、アプリの起動失敗とノードの接続失敗を分けて対応しましょう。

macOS：チップの選択、インストール権限、プロキシ

チップに合ったインストーラーを選ぶ

Macの「このMacについて」でチップを確認し、macOSのダウンロード一覧を開きます。Apple Siliconには対応するarm64版、Intelにはx64版を選んでください。互換レイヤー経由で起動できるかではなく、Macのアーキテクチャに合ったビルドを優先します。ダウンロード後、ディスクイメージを開いて画面の案内に従い、v2rayNを「アプリケーション」フォルダに移動してから起動してください。一時的にマウントした場所から継続して実行するのは避けましょう。

初回起動時に、提供元の確認や権限の許可を求められることがあります。まず、想定したダウンロード元から入手したファイルであることを確認し、システム設定の「プライバシーとセキュリティ」で起動を許可してください。「アプリが破損している」「開発元を検証できない」「アクセス権がない」などの警告が出た場合は、ダウンロードの完了状況、インストール先への書き込み権限、システムポリシーによるブロックをそれぞれ確認します。すべてを同じ原因と決めつけたり、アプリを起動するためにシステム全体のアプリ検証機能を無効にしたりしないでください。

インポート後に動作を確認してからシステムプロキシを設定

v2rayNのサブスクリプショングループ設定を開き、名前と完全なサブスクリプションURLを入力します。保存後、現在のグループを更新してください。ノード一覧が表示されたら使用するサーバーを選び、コアが起動できることを確認します。URLを保存できても更新に失敗する場合は、余分な空白、URLの有効期限、サブスクリプションサービスへの接続を確認してください。サブスクリプションの更新とノードへの接続ではリクエスト経路が異なります。更新に成功してもノードが使えるとは限らず、更新に失敗しても既存のノードが無効とは限りません。

次にシステムプロキシのメニューから自動設定を有効にします。Macのシステムプロキシはネットワークサービスごとに設定されます。Wi-Fi、有線ネットワーク、別のネットワークサービスに切り替えた場合は、現在のサービスのプロキシ状態を再確認してください。システムプロキシの「変更しない」は、システム設定の変更を停止するだけで、プロキシ設定が解除されたことを意味しません。直結に戻すには「システムプロキシを解除」を選び、システムのネットワーク設定でも反映を確認してください。「変更しない」に切り替えるだけでは不十分です。

ブラウザーとアプリの接続を分けて確認

まず、システムプロキシに従うブラウザーで対象のページを開き、リクエストがクライアントのログに記録されるか確認します。ブラウザーは使えるのに開発ツールで接続できない場合は、そのツール固有のプロキシ設定やプロセス環境を確認してください。システムプロキシを起動時にだけ読み込むアプリでは、設定変更後に再起動が必要な場合があります。ブラウザーに独自のプロキシ拡張機能やDNS設定があると、同じMacでもアプリごとに挙動が異なります。ノードを何度も切り替えて解決しようとしないでください。

「中国本土をバイパス」や「グローバル」などのルーティングプリセットは、アクセス先に応じて選んでください。「システムプロキシを自動設定」は、すべての接続をリモート経由にする設定ではありません。システムプロキシを有効にした後も、コアのルールによって特定のドメインやアドレスを直結にできます。開発環境ではループバックアドレスとLAN内の宛先に注意し、本来はローカルでアクセスするリクエストがリモートへ送られないようにしましょう。プリンター、LAN内のサービス、内部ドメインへのアクセスには、適切な直結範囲を残してください。

TUNとスリープ復帰後の再接続

システムプロキシを使わないアプリの通信を制御する必要がある場合に、TUNを試してください。クライアントの案内に従って権限を付与するか補助コンポーネントを許可し、ネットワーク機能の承認が必要か確認します。TUNを有効にしたら、まず一般的なWebページ、次にLAN内の機器、最後に対象アプリをテストしてください。ページを一つ確認するだけでは、LANルーティングやDNSの問題を見落とすことがあります。デフォルトルートを制御するツールを複数同時に使わないでください。ウィンドウを閉じただけでは、バックグラウンドのネットワーク機能が停止していない場合もあります。

Macがスリープから復帰した後やネットワークを切り替えた後は、既存の接続が使えなくなることがあります。まず基本のネットワーク接続を確認してから、現在のノードに再接続してください。解決しない場合はTUNを無効にし、システムプロキシを元の状態に戻してから、同じ順序で再度有効にします。アプリを終了する前にプロキシを解除し、異常終了した場合は現在のネットワークサービスのプロキシ設定に残りがないか確認してください。手順の参考にはmacOSのシステムプロキシモード解説を、起動時の問題には権限と隔離属性のトラブル対処をご覧ください。

Linux：パッケージ、デスクトッププロキシ、権限

ディストリビューションとCPUアーキテクチャを確認

Linuxのダウンロード一覧を開き、使用するディストリビューションに合ったdebまたはrpmパッケージを確認してから、CPUアーキテクチャがx64かarm64かを確認してください。拡張子を変更して別形式のパッケージにしたり、CPUアーキテクチャとディストリビューション名を混同したりしないでください。システムの「設定」や「システム情報」から確認できます。ターミナルを使う場合、次のコマンドはシステム情報を表示するだけで、ソフトウェアのインストールやネットワークの変更は行いません。ダウンロードページの説明と出力されたアーキテクチャが一致することを確認してから進めてください。

uname -m
cat /etc/os-release

ディストリビューション付属のソフトウェアインストーラーでパッケージを開き、依存関係に関する表示を確認してインストールします。コンポーネントが不足していると表示された場合は、現在のディストリビューションが提供する通常のソフトウェアリポジトリから依存関係を解決してください。他のディストリビューションのパッケージを混在させないでください。インストール後にウィンドウが表示されない場合は、インストール済みのアプリをターミナルから起動してエラーを確認します。グラフィカルセッション、デスクトップコンポーネント、ファイル権限の問題を切り分けましょう。この段階ではまだノードへの接続を試していないため、サブスクリプションを変更しても意味がありません。

一般ユーザーで起動して待ち受け入口を確認

GUIを日常的に使う場合は、一般ユーザーで起動してください。一度高い権限で実行すると、設定フォルダの所有者が変わり、一般ユーザーから書き込めなくなることがあります。初回起動時にサブスクリプションやアプリ設定を保存できるか確認し、いったん終了して再起動した後も残っていることを確かめます。変更が保存されない場合は、設定フォルダの権限、ディスクの状態、一時フォルダから実行していないかを確認してください。バックアップや移行でも適切なファイル所有者を維持し、問題を隠すためにすべてのフォルダの権限を緩めないでください。

サブスクリプショングループを作成し、URLを入力して保存・更新します。ノードを選んだらコアのログを確認してください。アドレスが使用中と表示される場合は、別のコアやプロキシツールが同じローカルポートを使っている可能性があります。使用中のプロセスを特定し、重複したインスタンスを停止するか、クライアントの入口ポートを変更してください。ポートを変更した場合は、その入口を使うアプリの設定も合わせて更新します。クライアントだけ変更してブラウザー、ターミナル、デスクトッププロキシを更新しないと、「コアは正常だがリクエストが届かない」状態になります。

デスクトップ環境ごとに異なるシステムプロキシ

Linuxのデスクトッププロキシの動作は、デスクトップ環境とアプリの実装によって異なります。クライアントにシステムプロキシの設定がある場合も、デスクトップのネットワーク設定に反映されたか確認してください。GUIアプリの中にはデスクトップ設定を読み込むものがありますが、コマンドラインのプログラムは環境変数や独自の設定ファイルを参照することがあります。起動済みのプロセスには設定変更が自動で反映されない場合もあります。まずプロキシ対応が明確なアプリ一つでローカル入口を使い、ノードへの接続を確認してから、他のアプリに広げると切り分けやすくなります。

ターミナルにプロキシを設定する前に、ツールが対応するプロキシプロトコルと、クライアントが実際に有効にしている待ち受け方式を確認します。HTTP入口とSOCKS入口は、どちらもローカルで待ち受けているからといって相互に使えるわけではありません。一時的な環境変数は通常、現在のターミナルとそこから起動したプロセスにだけ適用され、デスクトップ全体の設定は変更しません。設定を解除する場合も該当する環境変数を削除してください。残したままだと、クライアント終了後も新しいコマンドが存在しないローカルポートに接続しようとして、システムのネットワーク障害のように見えることがあります。

TUN・ルーティング・ネットワーク管理サービス

TUNは仮想ネットワークデバイスへのアクセスとルーティングの変更が必要です。権限が不足している場合は、クライアントの案内に従って必要な許可を設定してください。TUNを起動するために、デスクトップアプリ全体を常時高い権限で実行しないでください。有効にした後は、ネットワーク入口が作成されたか、他のVPNがデフォルトルートを制御していないか、LAN内の宛先にアクセスできるかを確認します。デスクトップのネットワーク管理サービスは、ネットワーク切り替え時に設定を再適用することがあります。一度起動に成功しても、切り替え後の状態が同じとは限りません。

DNSはデスクトップ環境、ネットワーク管理サービス、ローカルの名前解決サービスがそれぞれ管理している場合があります。まずどの階層が管理しているか確認してから、クライアントのDNSを変更してください。システムが管理する名前解決ファイルを直接上書きするのは避けましょう。名前を解決できない場合は、まずTUNを無効にして元の状態に戻し、システムの名前解決が復旧するか確認します。基本のネットワークが復旧したら、仮想入口とルールを順に確認してください。終了時は今回追加したプロキシ設定を解除し、元のネットワーク設定を残します。特にリモート管理中のマシンでは、復旧手段を確保せずにデフォルトルートを変更しないでください。

Android：サブスクリプションの追加とVPN権限

v2rayNGとv2flyNGから選ぶ

Androidのダウンロード一覧からクライアントを選びます。一般的なXray設定にはv2rayNGを使用してください。設定情報が明確にV2Flyを前提としている場合は、v2flyNGを検討します。どちらもノードを管理できますが、アプリ名から機能やプロトコルの対応状況が同じだと判断することはできません。設定情報でREALITYや特定のフロー制御が必要な場合は、インポート前に現在のクライアントで該当項目を設定できるか確認してください。インポート後に、実行時に認識できないことが分かる事態を避けられます。

インストーラーにはarm64版と汎用版があります。新しい一般的な端末ではarm64を選べることが多いものの、実際のCPUアーキテクチャを確認してください。互換性がないと表示された場合は、アーキテクチャとシステム要件を確認し、異なる配布元のパッケージを繰り返し上書きしないでください。ブラウザーからインストールする場合、Androidでその配布元からのアプリのインストール許可を求められることがあります。今回使用する配布元に限って、必要な許可を設定してください。インストール後はアプリ一覧から起動し、メイン画面が開いて設定を保存できることを確認します。

URLを貼り付けてサブスクリプションを更新

完全なサブスクリプションURLをコピーし、アプリのサブスクリプション設定またはグループ管理で新しい配布元を追加します。名前を入力して保存した後、サブスクリプションを更新してください。画面によっては更新メニューがメインの一覧にあります。設定画面にURLが表示されているだけでは、更新が完了したとは限りません。更新後、ノード一覧に戻り、使用する項目を選びます。共有リンクしかない場合は、サブスクリプション専用の入力欄に貼り付けるのではなく、クリップボードからのインポート機能を使ってください。

スマートフォンでは、コピーした情報に改行や空白、チャットアプリが付けた説明文が混ざりやすいため、インポート前に先頭のプロトコルと全体の内容を確認してください。QRコードの読み取りは、エンコードされた情報を取り込む機能であり、設定が現在も有効かどうかまでは確認できません。ノード名が表示されても起動できない場合は、トランスポート方式、暗号化接続のパラメーター、コアの対応状況を確認し、ログも参照してください。形式の違いについてはサブスクリプション・ネイティブJSON・共有リンクの解説をご覧ください。すべてのテキストを同じ方法でインポートしないようにしましょう。

AndroidのVPNによる通信制御の仕組み

接続をタップすると、通常はシステムからVPN接続のリクエストが表示されます。許可すると、アプリがローカルの仮想ネットワーク入口を通じて通信を受け取れるようになります。これはAndroidがこの種のクライアントに提供する通信制御の仕組みであり、ノード情報が自動で補完されるという意味ではありません。VPNのステータスアイコンは、ローカルの通信経路が確立したことを示すだけです。リモート接続の成否は、ログと実際のアクセス先へのリクエストで確認してください。システムの許可が拒否された場合、ノードを変更しても解決しません。

通常、同じシステムユーザーの通信を複数の一般的なVPNアプリが同時に制御することはできません。他のVPN、フィルタリングツール、VPNインターフェースを使うネットワークアプリがあれば、テスト前に停止してください。アプリ内のアプリ別プロキシでは、通信を制御する対象アプリを選べます。「選択したアプリのみをプロキシ」と「選択したアプリを除外」では意味が異なる場合があるため、現在のモードを確認してから操作してください。リストでアプリを選んでも、必ずプロキシ経由になるとは限りません。どちらの動作になるかはモードの定義によります。

バックグラウンド制限とネットワーク切り替え後の復旧

画面を表示している間は使えるのに、画面ロック後に接続が頻繁に切れる場合は、クライアントへのバッテリー最適化、バックグラウンド実行、自動起動の制限を確認してください。必要なバックグラウンド動作だけを許可すればよく、無関係なアプリまで一括で許可する必要はありません。システムがプロセスを終了したのか、Wi-Fiからモバイル通信に切り替わって以前の接続が切れたのかも確認してください。前者はバックグラウンド制限、後者は現在の設定での再接続とログの確認が必要です。

初回の動作確認では、「常時接続VPN」や「VPNを使用しない接続をブロック」などのシステム設定をすぐに有効にしないでください。クライアントが接続に失敗した際、他の通信までブロックされ、基本のネットワーク状態が分かりにくくなることがあります。必要な場合は、通常接続、切断、再起動後の動作を確認してから設定してください。トラブル対処後はアプリ内で接続を切り、システムのVPN状態も解除されたことを確認します。別のクライアントへ移行する場合も、前のアプリによる通信制御を停止し、残った状態を新しいアプリの障害と誤認しないようにしましょう。

サブスクリプション：形式・更新・設定の移行

情報の種類を確認して適切な方法でインポート

サブスクリプションURLは、繰り返しリクエストできる情報の取得先です。クライアントはこのURLからノード情報を取得します。共有リンクは通常、単一ノードの設定を表します。ネイティブJSONには、インバウンド、アウトバウンド、ルーティング、DNSを含む構成全体が記述されている場合があります。拡張子を変えるだけで相互に使えるファイルではありません。インポートに失敗したら、まず入力した情報の種類とクライアントの対応状況を確認してください。Webページをテキストとして保存したり、エンコード済みの内容を再度エンコードしたりしても、有効な設定にはなりません。

Base64形式のサブスクリプションは、複数の共有リンクをまとめてエンコードする用途でよく使われます。デコード後も、クライアントが認識できるリンク形式である必要があります。サブスクリプションサービスによっては、リクエスト方法に応じて異なる形式を返すため、ブラウザーで表示される内容とクライアントが受け取る内容が一致しない場合があります。更新ログでレスポンスと解析エラーを確認し、ブラウザーでURLを開けるかどうかだけで判断しないでください。ログイン画面、エラーメッセージ、空のレスポンスが返されると、インポート可能なノードがないことがあります。

情報の種類	主な用途	最初に確認する項目
サブスクリプションURL	ノードの一括取得・更新	有効期限、アクセス権、レスポンス形式
共有リンク	単一ノードの設定をインポート	プロトコル、トランスポート、認証項目
ネイティブJSON	コアの実行設定を記述	コアの種類、項目構成、インバウンド、ルーティング

グループの更新とノードの選択を分ける

サブスクリプショングループには、配布元や用途が分かる名前を付けましょう。「現在のグループを更新」はその配布元だけを更新しますが、「すべてのサブスクリプションを更新」すると、複数グループの項目が同時に置き換わることがあります。サブスクリプション内のノードを手動で変更した場合は、更新前にバックアップしてください。クライアントが配布元から情報を再生成し、手動の変更が残らない場合があります。長期的に使うカスタムノードは、更新のたびに同じサブスクリプション項目を変更するのではなく、別に保存するのがおすすめです。

更新が終わったら、現在選択しているノードが残っているか確認してください。ノード名、サーバーアドレス、設定内容が変わっていることがあります。グループの更新成功だけを見て確認を終えないようにしましょう。自動更新の間隔は配布元の制限に合わせ、失敗時に短時間で何度も更新しないようにします。サブスクリプションサービスに一時的にアクセスできなくても、保存済みのノードが利用できる場合は、そのまま使いながら更新経路を調べられます。すべての項目を削除して環境を作り直す必要はありません。

移行にはアプリのバックアップ機能を優先

同じクライアント間で移行する場合は、アプリのバックアップ・復元機能を使うか、案内に従って設定フォルダをバックアップしてください。コピー中のデータベースが書き換わらないよう、移行前にアプリを終了します。復元前には移行先の設定も別途保存しておきましょう。バックアップには完全なサブスクリプションURL、認証情報、ローカルの利用履歴が含まれることがあります。アクセスを制限できる場所に保管してください。新しい端末で復元した後は、ローカルの待ち受けポート、システムプロキシ、TUNの設定を確認します。端末ごとの設定がそのまま使えるとは限りません。

OSをまたいで移行する場合は、ファイルパス、権限の扱い、ネットワークサービスの違いに注意してください。WindowsのパスはMacでは使えず、Linuxの権限設定をAndroidにそのまま適用することもできません。別のクライアントに移行する場合は、双方が対応する共有形式を使い、重要なパラメーターを一つずつ確認してください。完全な実行設定には特定のコア専用の項目が含まれる場合があります。どちらもJSONだからといって互換性があるとは限りません。インポート時にエラーが出なくても、実際の接続とルーティングを確認しましょう。

REALITYとトランスポートの設定を確認

VLESSノードでは、サーバーアドレス、ポート、ユーザーID、トランスポート方式、接続のセキュリティ、フロー制御をそれぞれ確認します。REALITYのサーバー名、公開鍵、ショートIDはサーバー側の指定と一致させてください。他のノードの値を任意に組み合わせてはいけません。サーバー名は実際の接続先アドレスと同じとは限りません。必要なパラメーターが不明な場合は、検証を無効にして試すのではなく、情報の提供元に確認してください。仕組みについてはREALITYとXTLS Visionの解説をご覧ください。

移行後は2段階で動作を確認します。まず新しい端末で最小構成の接続を確立し、その後で元のルールベースの振り分け、自動更新、バックグラウンド設定を追加してください。安定してから旧端末の情報を整理します。新しい端末で接続を確認できるまでは旧端末の設定を残しておくと、情報の問題とOS環境の問題を切り分けやすくなります。形式変換の詳しい注意点はサブスクリプション形式の解説をご覧ください。

システムプロキシ・TUN・ルーティング・DNS

リクエストがどこからクライアントに入るかを確認

システムプロキシは、アプリと連携する仕組みです。システムにプロキシの入口を登録し、その設定を読み込むアプリがリクエストを入口に送ります。一方、TUNはネットワーク層に仮想入口を作り、ルーティングによって条件に合う通信をクライアントに渡します。どちらも主に通信を受け取るための仕組みであり、すべてのリクエストの出口を決めるものではありません。アプリがシステムプロキシに従わない場合、リクエストがコアに届いていないため、ノードの振り分けルールを変更しても効果はありません。

入口が機能しているか確認するには、明確なリクエストを一度送り、ログに記録された宛先ドメイン、接続時刻、アプリの動作が対応しているか確認します。記録がない場合は、プロキシ入口とアプリの設定を調べてください。記録があり接続に失敗する場合は、ノード、ルーティング、名前解決を確認します。ログレベルを高くしすぎたままにせず、確認後は通常のレベルに戻し、機密情報を含む記録を削除してください。接続が再利用されると、ページを再読み込みしても新しい接続が記録されない場合があります。必要に応じてアプリを開き直して確認しましょう。

ルーティングルールは順序に従って出口を選択

「中国本土をバイパス」では、通常、関連するリクエストをドメインやアドレスのルールで直結に振り分け、残りのリクエストはプリセットに従って処理します。ルールは順序が重要です。範囲の広いルールを先に置くと、後続の詳細なルールに一致しないことがあります。LAN内のアドレス、特定の開発用ドメイン、リモートの宛先は、それぞれ分けて検討してください。すべてのアドレスを対象にするルールを一つ追加するだけでは不十分です。特に社内ネットワークでは、内部ドメインの名前解決に社内DNSが必要な場合があるため、一律にリモートへ送らないようにしましょう。

以下は、データベースルールと出口のタグの関係を示すXrayルーティング設定の例です。既存の設定に組み込んで使うものであり、クライアント全体の設定としてそのまま起動できるものではありません。directとproxyという名前のアウトバウンドと、利用可能なルールデータベースがすでに設定されていることを前提としています。GUIクライアントは実行用設定を再生成する場合があるため、日常的な変更には一時生成ファイルの直接編集ではなく、クライアントのルーティング画面を使ってください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private", "geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

DNSはアドレスを入力するだけではない

ドメイン名の解決は、アプリ、システム、クライアント、リモートのいずれかで行われ、プロキシ方式によって解決場所が異なる場合もあります。ブラウザーが暗号化DNSを独自に有効にしていると、システムDNSを変更しても影響しないことがあります。トラブル対処では、まず対象アプリがどの階層で名前解決しているかを確認し、次にクライアントのルールからドメイン名を確認できるか調べます。リクエストがアドレスだけの状態で届くと、ドメイン名に基づくルールが想定どおりに適用されないことがあります。ページを開けないからといって、複数の階層で同時にDNSを変更しないでください。

クライアントのDNS、直結出口、プロキシ出口が相互に依存することもあります。たとえばノードサーバーのアドレスを解決するためのリクエストが、そのノード経由でなければ処理できない場合、接続開始がループします。まず接続先サーバーに必要な基本の名前解決を確保し、その後で対象ドメインの振り分けを設定してください。TUN使用時は、設計どおりにDNSリクエストが制御されているかも確認します。システムとクライアントが異なる結果を使うと、同じドメインへのアクセスが一貫しないことがあります。

データベースルールとUDPを分けて確認

GeoSiteはドメインの分類、GeoIPはIPアドレス範囲の分類に使われ、相互に置き換えられるデータではありません。ルールの書き方が正しくても分類が機能しない場合は、データベースが存在するか、正常に読み込まれたか、現在のコアがその形式に対応しているかを確認してください。データベース更新後は、コアが再読み込みしたことも確認しましょう。ダウンロード完了だけでは反映されたとは限りません。ルールの詳しい評価順序はGeoIP・GeoSite更新ガイドをご覧ください。

ブラウザーでWebページを開けても、UDPを使うアプリが動作するとは限りません。UDPの転送可否は、アプリの入口、クライアントの設定、プロトコルの機能、ノード側のサービス、ネットワーク環境に左右されます。音声通話、リアルタイム通信、別のトランスポートを使うアプリで問題が起きた場合は、その通信を個別に確認し、Webページの結果だけで判断しないでください。構成は段階的に増やします。システムプロキシを確認してからルーティング、次にTUN、最後にDNSや特定アプリの要件を確認し、各段階で直前の設定に戻せるようにしましょう。

よくある設定トラブル：失敗した段階から切り分ける

アプリが開かない・コアを起動できない

まずメイン画面が表示されるか確認してください。画面が開かない場合は、インストーラーのアーキテクチャ、システムの依存関係、アプリの権限、セキュリティ警告を優先して確認します。この段階では通常、サブスクリプションの内容は主な原因ではありません。画面は開くのにコアが終了する場合は、コアのログで設定の解析失敗、ローカルポートの競合、ファイルへのアクセス失敗、未対応の項目を確認してください。エラーが発生した段階を記録しておけば、アプリの起動問題でノードを繰り返し変更したり、設定ミスでクライアント全体を何度も再インストールしたりせずに済みます。

設定を変更した直後に起動できなくなった場合は、まず最後に変更した項目を元に戻してください。バックアップがあれば、起動できると確認済みの設定に復元します。ログや有効な情報が残っている可能性があるため、設定フォルダ全体をすぐに削除しないでください。ポートの競合では重複して起動中のクライアントを探し、権限エラーでは問題のファイルの場所を確認します。OSをまたぐ起動トラブルについてはv2rayNのクラッシュと権限のトラブル対処を参照してください。まずアプリが正常に起動する状態に戻してから、ネットワークをテストします。

サブスクリプションの更新失敗と接続失敗

サブスクリプションの更新に失敗した場合は、まずサブスクリプションサービスにアクセスできるか、次にレスポンスを認識できるかを確認します。タイムアウト、認証の失効、未対応の形式はそれぞれ異なる問題です。URLが完全でアクセス権が有効であることを確認し、現在のネットワークでログインページやアクセス制限が発生していないか調べてください。既存のノードは使えるのにサブスクリプションへアクセスできない場合は、クライアントに適切な更新リクエスト方法があるか確認します。機密性の高いサブスクリプションをオンライン変換サービスに渡さないでください。設定の問題が認証情報の漏えいにつながるおそれがあります。

ノードをインポートできても接続できない場合は、リモートアドレス、ポート、プロトコル、トランスポート、セキュリティのパラメーターを一つずつ確認してください。タイムアウトでは到達性とサービスの状態を調べます。認証やハンドシェイクのエラーでは、設定内容、システム時刻、サーバー側の要件を重点的に確認しましょう。エラーメッセージだけで原因を断定せず、どの段階で発生したかと併せて判断してください。ノードをまとめて切り替える前に、情報が明確な設定を一つテストします。すべての設定で同じ段階に失敗する場合は、個々の項目より共通の環境を先に確認してください。

接続済みなのにWebページやアプリが使えない

クライアントに「実行中」と表示されるのは、ローカルのプロセスが動作していることを示すだけです。まずリクエストがログに記録されるか、次に一致した出口、最後に名前解決とリモートの応答を確認します。ブラウザーは使えるのに他のアプリが使えない場合は、入口とアプリのプロキシ設定を比較してください。すべてのアプリで失敗する場合は、コアとノードを再確認します。一部のドメインだけに問題がある場合は、ルーティングの分類、DNSの結果、対象サービスの状態を調べましょう。必要がないのに、すぐ広範囲な通信制御を有効にする必要はありません。

ページの一部だけ読み込めない、ダウンロードが中断する、動画が止まるといった症状を、すぐに「ノードが遅い」と決めつけないでください。ページは複数のドメインに同時にリクエストを送ることがあり、一部のリソースが誤って別の出口に振り分けられると、一部だけ読み込みに失敗します。失敗したリソースの宛先と出口を確認し、想定した経路を通っているか調べてください。遅延テストは特定の接続を測るもので、通信速度、長時間の転送、すべてのプロトコルの性能を示すわけではありません。ノードを比較するときは、宛先、ネットワーク、プロキシ方式をそろえ、条件の異なる結果を混ぜないようにしましょう。

終了後もネットにつながらない・問い合わせの準備

クライアントを終了した後にネットにつながらない場合は、まずシステムプロキシがローカル入口を指したままか、次にTUNやシステムVPNが通信を制御しているか確認します。復旧する際は、クライアントが変更した設定を元に戻してから、直結用の確認ページにアクセスしてください。Linuxではターミナルの環境変数とデスクトッププロキシの両方に設定が残っていないか、Macでは現在のネットワークサービス、Androidでは「VPNを使用しない接続をブロック」の設定も確認します。「終了後にネットにつながらない」というだけでネットワーク全体をリセットせず、今回の操作に対応する設定から戻してください。

引き続き相談する場合は、OSとアーキテクチャ、クライアント名、設定情報の形式、接続方法、再現手順をまとめ、機密情報を隠したエラー部分を添えてください。すべての宛先で失敗するのか一部だけなのか、直結は正常か、インストール直後に発生したのかネットワーク切り替え後に発生したのかも記載します。一度に一つの仮説を検証し、結果を記録してから次に進みましょう。よくある用語はよくある質問をご覧ください。接続手順を最初から確認する場合は使用ガイドに戻り、インポート、選択、有効化、確認の順に基本状態を作ってください。