V2Ray 全プラットフォームの導入・設定

共通の準備：クライアント、コア、サブスクリプション

まず、クライアント、コア、サブスクリプションの役割を整理しましょう。クライアントは画面の表示、サブスクリプションの保存、ノードの選択、プロキシの管理を担います。コアは接続パラメーターを解析し、通信を確立してルーティングを実行します。サブスクリプションは設定を取り込むためのもので、クライアントそのものではありません。インストールが完了しても、プログラムが使える状態になっただけです。接続には有効なノード設定が必要です。当サイトではクライアントの選び方と操作方法を案内していますが、サブスクリプションの提供は行っていません。アカウントの状態、通信量、サーバー設定の変更も、サービス提供元にお問い合わせください。

クライアントとコアの組み合わせ

デスクトップでは、Windows、macOS、Linuxに対応するv2rayNがおすすめです。AndroidではXrayコアを使用するv2rayNGを優先し、V2Flyの設定が必要な場合はv2flyNGを検討してください。Project Vは関連技術エコシステムの出発点で、V2FlyはV2Rayの保守・開発を引き継ぎ、Xrayは独自に進化を続ける別のコアです。クライアントの画面が似ていても、コアの実装や対応パラメーターまで同じとは限りません。未対応のプロトコルや認識されない通信方式がある場合は、まず設定要件を確認し、必要に応じてコアを切り替えてください。名前だけで互換性を判断することはできません。

ダウンロード前にOS、CPUアーキテクチャ、インストール形式を確認してください。x64は一般的なIntel・AMD製デスクトップCPU向け、arm64は対応するARM端末向けです。両者はサイズだけが異なる同一パッケージではありません。デスクトップ用とAndroid用のパッケージも互換性はありません。クライアントのダウンロードページでプラットフォームに合ったものを選びましょう。トラブル対処中にプログラム、コア、サブスクリプションを同時に変更しないよう、インストール前に既存クライアントのデータをバックアップしてください。

サブスクリプションURLと設定情報

完全なサブスクリプションURLを用意し、コピー時に説明文や改行、末尾の句読点が混ざらないようにしてください。URLにはアクセストークンが含まれる場合があり、アカウント情報と同じように扱う必要があります。公開チャットやスクリーンショット、共有ログに載せないでください。QRコードにもノードの設定情報が含まれることがあります。問い合わせ時はエラーの種類とプロトコル名を伝え、サブスクリプションURL、ユーザーID、パスワード、サーバー情報は隠してください。読み込みに成功しても設定が有効とは限りません。契約期間、通信量、ノードの状態も確認しましょう。

初回設定では、ほかのプロキシやVPNをいったん停止し、システム時刻を合わせ、通常のネットワークが使えることを確認してください。企業ネットワーク、学校の認証ページ、ホテルのログイン画面は先に認証を済ませる必要があります。プロキシアプリでこれらの手続きを代替することはできません。現在のシステムプロキシとDNS設定を記録し、その後は一度に1項目ずつ変更してください。組織管理の端末では、証明書、仮想ネットワークアダプター、ネットワーク権限がポリシーで制限される場合があります。制限を回避するために権限を何度も引き上げるのではなく、利用できる範囲を先に確認してください。

VMess、VLESS、REALITYの違い

VMessとVLESSは接続プロトコル、TLSとREALITYは関連するセキュアハンドシェイクの設定、TCPやWebSocketなどは通信方式を表します。各項目を組み合わせて設定する必要があり、プロトコル名だけでは接続方式全体を示しません。VMessは端末の時刻に影響されやすく、VLESS自体には暗号化機能がないため、設定要件に応じたセキュリティ機構が必要です。REALITYは、どのノードにも適用できる万能な高速化スイッチではありません。クライアントが対応していることを確認し、サーバーから指定された公開鍵やサーバー名などを正しく設定してください。

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

Windowsのダウンロードページからv2rayNを選んでください。デスクトップ版はクロスプラットフォームの画面を採用し、従来のWPF版は使い慣れたWindowsの操作感を引き継いでいます。違いは画面と実装方式であり、ノードの品質ではありません。初めて使う場合はデスクトップ版から始めるとよいでしょう。すでに安定した作業環境があるなら、接続トラブルの調査だけを理由にすぐ画面を切り替える必要はありません。インストーラーの案内に従って導入し、必要な実行環境は実際の表示を確認してください。古い手順を見て無関係なコンポーネントをまとめて事前インストールするのは避けましょう。

インストール、起動、データの保存場所

起動後、まずメイン画面が正常に開くことを確認し、ログにコアの起動失敗がないかを確認してください。圧縮形式で配布されている場合は、書き込み可能な場所に完全に展開します。圧縮ファイルのプレビュー画面から直接実行しないでください。インストール先、ユーザーデータの保存先、一時フォルダーは別々の場合があります。バックアップにはクライアントのエクスポートまたはバックアップ機能を使い、デスクトップのショートカットだけをコピーしないでください。セキュリティ警告が表示された場合は、ダウンロード元とシステムの説明を確認してください。起動トラブルの解決策として、システム保護を恒久的に無効にすることはおすすめできません。

通常のシステムプロキシを使うだけなら、一般に管理者権限で起動する必要はありません。TUNで仮想ネットワークインターフェースを作成する場合は、追加の権限が必要になることがあります。まず通常の権限でサブスクリプションを追加し、ノードに接続できることを確認してからTUNを設定してください。毎回起動時に権限エラーが出る場合は、何に失敗しているのかを確認します。ディレクトリへの書き込み、ポートのバインド、仮想ネットワークアダプターの作成は、それぞれ別の問題です。プログラム全体の権限を上げることが、常に適切な解決策とは限りません。

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

「サブスクリプショングループ」を開き、新しいグループを追加してURLを入力し、見分けやすい名前を付けます。保存後、「サブスクリプションを更新（プロキシを使用しない）」を実行してください。まだプロキシ接続を確立していない初回は、この方法のほうが結果を判断しやすいでしょう。サブスクリプションの提供元がプロキシ経由のアクセスを必須としている場合は、利用可能なノードを先に用意し、「サブスクリプションを更新（プロキシを使用）」を選びます。更新ログで内容を取得できたか確認し、メイン一覧にノードが表示されることを確かめてください。URLを保存しただけで更新していないと、一覧が空のままになることがあります。

使うノードを選択して有効な設定にし、コアが正常に動作しているか確認してください。デスクトップ版とWPF版を同時に起動し、同じローカル待ち受けポートをテストするのは避けましょう。後から起動したプロセスは、アドレスの競合で失敗することがあります。サブスクリプショングループ間で同じ名前のノードが表示されることも珍しくありません。どのグループを選んでいるか確認し、新しいサブスクリプションを更新したのに古いグループの無効な設定を使い続けていないか注意してください。

システムプロキシ、TUN、終了後の復旧

トレイメニューの「システムプロキシ」で「システムプロキシを自動設定」を選ぶと、Windowsのシステムプロキシを参照するアプリがローカルの接続先を使います。「システムプロキシをクリア」は設定を削除する操作です。「システムプロキシを変更しない」は現在の状態をそのままにするだけで、設定の削除とは異なります。ブラウザーには拡張機能、企業ポリシー、独自のネットワーク設定が影響する場合があります。また、コマンドラインのプログラムはシステムプロキシを参照しないことがあります。トレイの状態が正しくても、それだけでは通信を取り込めているとは限りません。アプリごとに確認してください。

システムプロキシを参照しないプログラムも通信させる必要がある場合は、「Tunを有効にする」を検討してください。有効にする前にほかのVPNを停止し、ローカルゲートウェイ、LAN内のサービス、クライアント自身の通信が誤ってトンネルに送られないルールになっているか確認します。終了時は先にTUNを無効にし、システムプロキシを解除してからクライアントを通常終了してください。異常終了後にブラウザーが通信できない場合は、Windowsの「設定 → ネットワークとインターネット → プロキシ」で、手動プロキシが停止済みのローカルポートを参照していないか確認します。

macOS：チップの選択、ネットワーク権限、プロキシの復旧

macOSのダウンロードページを開く前に、「Appleメニュー → このMacについて」を確認してください。Appleチップ搭載と表示される場合はarm64、Intelプロセッサと表示される場合はx64を選びます。アーキテクチャの選択はプログラムがネイティブに動作するかどうかに関わりますが、サブスクリプションの内容は変わりません。購入年だけでチップを判断しないでください。対応するv2rayNのディスクイメージをダウンロードし、配布パッケージの説明に従ってアプリを「アプリケーション」に移動します。マウントしたイメージやダウンロードフォルダーから長期間実行するのは避けましょう。

初回起動とシステムの許可

初回起動時に、システムのセキュリティ確認が表示される場合があります。アプリの入手元を確認し、macOSの画面に従って許可してください。「システム設定 → プライバシーとセキュリティ」で、そのアプリの起動に関する通知を確認できます。表示内容はOSのバージョン、署名の状態、管理ポリシーによって異なるため、どの端末でも同じボタンが表示されるとは限りません。アプリが破損している、アーキテクチャが合わない、組織のポリシーで制限されていると表示された場合は、まず原因を確認してください。出所不明のターミナルコマンドでシステム全体のセキュリティ設定を変更するのは避けましょう。

メイン画面が開いたら、まず設定を保存できることと、コアを起動できることを確認してから、ネットワークを取り込むための権限を設定してください。システムプロキシの変更と仮想インターフェースの作成は別の操作です。一方を許可しても、もう一方が使える状態になるわけではありません。追加コンポーネントや管理者の確認が必要な場合は、現在のクライアントが明示する手順に従ってください。会社管理の端末ではトンネルインターフェースの作成が禁止されていることがあります。通常のアプリを繰り返し再インストールしても、この制限は解決できません。

サブスクリプションを追加し、有効なノードを確認する

「サブスクリプショングループ」でURLを追加して保存し、該当する更新操作を実行します。初回は「サブスクリプションを更新（プロキシを使用しない）」を使い、通常のネットワークから提供元にアクセスできるか確認しましょう。アカウントのログイン画面、認証画面、エラーの説明が返された場合、クライアントが応答を受信していても、ノードを読み取れないことがあります。その場合は、提供元のアカウントページでサブスクリプションの状態を確認してください。返されたWebページのテキストをノード設定として貼り付けることはできません。

更新後にノードを選択して有効な設定にし、ログでコアにパラメーターエラーがないか確認してください。初回のテストでは、通信方式、フィンガープリント、セキュリティ設定を同時に変更しないでください。通常、サブスクリプションにはサーバーが必要とする組み合わせが含まれています。システム時刻がずれていると、証明書の有効期間やプロトコル認証の判定に問題が出ることがあります。検証を無効にするより、自動の日付と時刻の設定を確認するほうが適切です。手動で変更する場合は、次回のサブスクリプション更新で調査記録が上書きされないよう、先に設定をコピーしてバックアップしてください。

システムプロキシとTUNの使い分け

「システムプロキシを自動設定」を選ぶと、通常はシステムのネットワークプロキシを参照するアプリがクライアントを利用します。「システム設定 → ネットワーク」で現在のネットワークサービスを選び、詳細画面からプロキシ設定を確認できます。OSのバージョンによっては「詳細」や「高度な設定」に項目があります。Wi-Fiと有線LANは別のネットワークサービスなので、接続方法を切り替えた後は設定を確認し直してください。ブラウザーが使えてターミナルが使えなくても、ノードに問題があるとは限りません。ターミナルのプログラムには個別のプロキシ設定が必要な場合があります。

TUNは、より広い範囲の通信を取り込む必要がある場合に使えますが、DNS、ルーティング、LANへのアクセスにも影響します。まずシステムプロキシで対象を明確にしたリクエストを確認し、その後TUNを有効にすれば、問題が発生する段階を切り分けやすくなります。ほかのVPN、リモートワーク用ソフト、ネットワークフィルタリングツールを使っていると、ルートが競合する場合があります。まず通信を取り込む入口を一つに絞り、接続できることを確かめてから一つずつ戻してください。複数のツールにデフォルトルートを同時に変更させないようにしましょう。

ネットワークの切り替え、スリープからの復帰、ドッキングステーションの交換後に接続できない場合は、まず現在のネットワークサービスが変わっていないか確認し、次にクライアントのコアが動作中か確認してください。正常に終了する前にシステムプロキシを解除し、TUNを無効にします。クライアントが停止しているのにネットワークがローカルプロキシを参照している場合は、現在のネットワークサービスのプロキシ設定を復旧してください。元の値を記録せずに、組織指定のDNSや自動プロキシアドレスを一括消去しないでください。

Linux：インストール形式、デスクトッププロキシ、TUNの権限

Linuxでは、まずディストリビューションのパッケージ形式を確認し、次にCPUアーキテクチャを確認してください。Debian・Ubuntu系はdeb、FedoraなどRPM系のディストリビューションはrpmを選びます。x64とarm64も端末に合ったものが必要です。パッケージ形式が同じでも、アーキテクチャまで同じとは限りません。Linuxのダウンロードページからv2rayNを選び、システムのソフトウェアインストーラーでファイルを開いてください。依存関係とインストール情報はパッケージマネージャーに任せ、アプリ内部のファイルを手作業でコピーしないようにしましょう。

インストール後に実行環境を確認する

グラフィカルインストーラーで依存関係の不足が表示されたら、まずシステムのパッケージソースを更新し、どのコンポーネントが不足しているか確認してください。ライブラリ名、デスクトップ環境、ディスプレイサーバーはディストリビューションによって異なるため、別のシステム向けの依存関係一覧をそのまま使うのは適切ではありません。アプリがメニューに表示されない場合は、デスクトップセッションに再ログインしてから確認してください。起動に失敗したら、デスクトップランチャーやシステムログでエラーを確認します。ウィンドウが見つからない、コアが起動しない、トレイに表示されない、はそれぞれ異なる現象です。

GNOMEなどのデスクトップ環境でトレイを表示できるかどうかは、デスクトップ側の対応状況によります。トレイアイコンが見当たらなくても、プロセスが終了したとは限りません。メイン画面とプロセスの状態を確認し、複数のインスタンスを続けて起動しないようにしてください。トレイを表示させるために、出所不明のデスクトップ拡張を安易にインストールするのも避けましょう。バックアップにはクライアントの設定と、自分で管理しているルールを含めてください。別の端末へ移行する場合は、ローカルパス、ポート、権限を確認します。旧環境と同じ状態だとは限りません。

サブスクリプションの追加とデスクトップのシステムプロキシ

「サブスクリプショングループ」にURLを追加して保存し、更新を実行します。ノードが表示されたら、有効な設定として選択してください。まず一般ユーザーでクライアントを起動し、コアがローカルポートで待ち受けできることを確認します。ログにアドレスの競合が表示されたら、古いプロセスやほかのプロキシが残っていないか確認してください。ポートを変更した場合、古いポートを明示的に参照するアプリの設定も更新する必要があります。クライアントのポートだけを変更し、ブラウザーやターミナルの設定を変えないままでは、一見ランダムな接続エラーが起きることがあります。

「システムプロキシを自動設定」がアプリに反映されるかどうかは、デスクトップ環境とアプリがプロキシ設定を読み取る方法によります。GNOME、KDE、独立系ウィンドウマネージャーが同じプロキシ設定を共有するとは限りません。サンドボックスアプリには独自の制限がある場合もあります。まずデスクトップのネットワーク設定で実際のプロキシアドレスを確認し、ブラウザーでテストしてください。GUIアプリは使えるのにパッケージマネージャーが接続できない場合は、ノードを切り替える前にパッケージマネージャー側のプロキシ設定を確認します。

# 現在のターミナルセッションに設定されているプロキシ環境変数を確認
printenv | grep -iE '^(http|https|all|no)_proxy='

# 現在のターミナルセッションから一般的なプロキシ変数だけを削除
unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

上記の確認と削除が対象とするのは現在のシェルだけです。デスクトップのプロキシ、システムサービス、すでに起動しているほかのプログラムは変更されません。変数がシェルの起動ファイルで設定されている場合、新しいターミナルを開くと再び表示されます。元の設定箇所を探してください。環境変数名の大文字・小文字への対応はアプリによって異なるため、変数が一つ設定されているだけで、すべてのプログラムに反映されたとは判断できません。権限を上げて起動したプログラムには、一般ユーザーの環境変数が引き継がれない場合もあります。

TUN、ルーティング、LANの範囲

TUNを使うには、システムが仮想ネットワークインターフェースをサポートし、クライアントの設計に応じてインターフェースの作成とルート設定を許可している必要があります。具体的な権限の設定方法は、現在のクライアントの案内に従ってください。デスクトップセッション全体をrootで実行し続けたり、確認していない権限付与コマンドをそのまま使ったりしないでください。初めて有効にする前にほかのVPNを停止し、元のデフォルトルートとDNSの状態を記録します。TUNを有効にした後だけ通信できなくなる場合は、インターフェースの作成、権限、ルート、DNSの取り込みに関するログを重点的に確認してください。

コンテナネットワーク、仮想マシンのブリッジ、会社のVPNでは、TUNとルーティング範囲が重なることがあります。LANアドレスには適切な直接接続経路を残してください。ローカルの待ち受けアドレスは、通常ループバックに限定します。ほかのインターフェースにも公開する必要が明確にある場合に限り、ファイアウォールと認証を設定してください。終了後も名前解決に問題が残る場合は、デスクトップのネットワークサービスと、実際にDNSを管理しているコンポーネントを確認します。複数の設定ファイルを同時に変更すると、次回の接続時に自動設定で上書きされることがあります。

Android：クライアント選び、サブスクリプション、VPNによる通信の取り込み

AndroidではXrayコアを使用するv2rayNGがおすすめです。V2Flyコアの設定が必要な場合はv2flyNGを選択肢にできます。アプリごとにデータ、権限、動作状態が管理されるため、別のクライアントをインストールしても、元のサブスクリプションが自動的に引き継がれるわけではありません。Androidのダウンロードページを開き、一般的なarm64端末では対応するパッケージを選んでください。CPUの互換性を判断できない場合は汎用パッケージを検討します。通常、ファイルサイズは大きくなりますが、接続性能が高くなるわけではありません。

インストール元の許可とアップデート時の設定保持

ブラウザーやファイル管理アプリに、アプリのインストール権限を求められる場合があります。実際にインストールに使うアプリだけに一時的な権限を付与し、インストール後は必要に応じて無効にしてください。インストールできないと表示されたら、アーキテクチャの不一致、システム要件の不足、空き容量不足、署名の競合を切り分けます。上書きインストールに失敗しても、すぐにアンインストールしないでください。アンインストールするとローカル設定も削除されることがあります。先にクライアントのエクスポート機能でバックアップし、バックアップファイルは機密情報として保管してください。

同じアプリでも、配布元が異なると署名の互換性に違いがある場合があります。システムに競合を報告されても、サブスクリプションに問題があるとは限りません。更新してもインストール段階のエラーは解消しません。現在のクライアントが正常に使えている場合は、まずその状態を維持し、インストール時の案内を確認してから移行を決めてください。アプリの更新後は、デスクトップにアイコンがあるかだけでなく、元のグループ、有効な設定、ルーティングの選択が意図どおりか確認します。

サブスクリプショングループ、クリップボード、QRコード

サブスクリプション設定またはグループ管理を開き、名前と完全なURLを追加して保存したら、メニューから更新を実行します。クライアントによっては、サブスクリプション管理とサーバー一覧が別の画面に分かれています。グループを追加した後、一覧に戻って該当グループを選ぶ必要がある場合があります。クリップボードからのインポートは完全なノードリンク向け、QRコードの読み取りは単一の設定向けです。ただしQRコードがサブスクリプションURLを指している場合もあります。インポート後にプロトコルと名前が妥当か確認してください。一覧が空の場合は、同じコードを何度も読み込まず、まず更新結果を確認しましょう。

ノードを選択して接続を開始すると、初回はAndroidのVPN接続確認が表示されます。この許可により、クライアントはローカルの仮想ネットワークインターフェースを作成して通信を取り込めますが、リモートノードへの接続成功を示すものではありません。ステータスバーに鍵やVPNのマークが表示されても、確認できるのはシステム側のインターフェースが作成されたことだけです。実際のWebリクエストとクライアントのログで、通信が正常か確認してください。パラメーターの解析失敗やサーバーからの接続拒否があっても、システムのマークは表示されたままの場合があります。

アプリごとのプロキシ設定とバックグラウンド動作

Androidクライアントは、システムのVPNインターフェースを使ってアプリの通信を取り込むことが多く、デスクトップ版のシステムプロキシ変更とは仕組みが異なります。アプリごとのルールを有効にする場合は、一覧が「選択したアプリだけをプロキシ経由にする」のか、「選択したアプリを除外する」のかを確認してください。選択方向を間違えると、ブラウザーでのテスト結果が逆になります。初回は対象範囲が明確な標準設定で確認し、接続が安定してから必要に応じて範囲を絞りましょう。設定を変えるたびに、同じアプリで再テストしてください。

Androidでは通常、一般的なVPNサービスを同時に一つしか有効にできません。ほかのVPN、一部のファイアウォール、ローカルVPNを使う通信フィルタリングツールが、同じ接続枠を使用して競合することがあります。「常時接続VPN」や「VPNを使用しない接続をブロック」の設定は、接続を切った後のネットワークにも影響します。クライアントを停止する前に、これらのシステム設定を確認してください。すべてのアプリが通信できなくなっても、すぐにノードの障害と決めつけないでください。システムが設定済みの通信制限を適用している可能性があります。

画面表示中は使えるのにロック後に切断される場合は、バッテリー最適化、バックグラウンド動作、メーカー独自の自動起動制限を確認してください。実際に使うクライアントに必要なバックグラウンド権限を設定すれば十分です。端末全体の省電力機能をまとめて無効にする必要はありません。Wi-Fiとモバイルネットワークを切り替えた後、接続が復旧するかも確認しましょう。片方のネットワークだけで失敗する場合は、DNS、認証、到達性を比較してください。テストではノード、アプリ、アクセス先を固定し、ネットワーク切り替えとサブスクリプション更新を同時に行わないでください。

ルーティングとDNS：ルールで通信経路を決める

システムプロキシとTUNは、通信をクライアントに取り込む方法を決めます。ルーティングルールは、取り込まれた通信の経路を決めます。この二つは相互に置き換えられません。アプリの通信がクライアントに入っていない場合、「全てをプロキシ」に切り替えても自動的に取り込まれるわけではありません。クライアントに入った通信も、ルールによって直接接続に振り分けられることがあります。まず入口を確認し、その後に出口を調べると効率的です。デスクトップメニューの「中国本土を除外」「ブラックリスト」「全てをプロキシ」はプリセットの方針です。実際のルール内容は、現在のクライアント設定で確認してください。

ルールの照合順序と直接接続の例外

コアのルーティングは通常、ルールを上から順に照合し、最初に一致したルールで処理が決まります。LANへの接続を保つルールは、ほかのルールと整合する順番に配置してください。対象が広すぎる直接接続ルールを先頭に置くと、後続のプロキシルールに一致しなくなることがあります。ドメインルールが機能するのは、コアがドメイン名を把握できる場合です。IPアドレスへの直接接続、アプリによる事前の名前解決、接続の再利用によって結果が変わることがあります。ルールを切り替えた後は新しい接続で確認してください。既存の接続は以前の経路を使い続ける場合があります。

以下はXray形式のルーティング設定例で、プライベートアドレスを直接接続する方法のみを示しています。単独で動作する完全な設定ではありません。組み込む前に、実際の設定にdirectという名前の直接接続用アウトバウンドがあることを確認し、既存ルールとの順序も調整してください。GUIクライアントは起動時に設定を生成することがあります。生成ファイルを直接編集すると次回起動時に上書きされる可能性があるため、継続して使うルールはクライアントが用意するルール管理機能で設定してください。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

名前解決とルールデータベース

GeoIPデータは主にIPアドレスの分類に、GeoSiteデータは主にドメインのグループ照合に使われます。両者は同じリストではありません。geoip:privateはプライベートアドレスの分類を、geosite:cnは対応するドメイングループを参照します。データベースの欠落、未対応のルール名、コアと互換性のない形式は、ルールの読み込み失敗につながります。更新後はログで読み込みの成功を確認してから、具体的なリクエストをテストしてください。ダウンロードが完了しただけでは、ルールが有効になったとは判断できません。

DNSはドメイン名の解決方法を、ルーティングは接続の出口を決めますが、両者は相互に影響します。不適切なDNS経路を選ぶと、到達できないアドレスが返されたり、ドメイン名で判定する必要がある接続からドメイン情報が失われたりすることがあります。まず、アプリ、システム、コアのどれが名前解決を担当しているか確認し、DNSリクエスト自体が直接接続とプロキシのどちらを通るか確認してください。ブラウザーで独自のセキュアDNSを使っていると、クライアントの想定どおりに問い合わせない場合もあります。調査中は名前解決の経路を一つに固定し、複数箇所を同時に変更しないでください。

FakeDNSとTUNを使う際の注意点

FakeDNSは、仮想IPアドレスとドメイン名の対応関係を使い、後続の接続時にコアがドメイン情報を復元できるようにします。実際のサーバーのアドレスがその仮想IPになるわけではなく、すべてのアプリとの互換性が保証されるわけでもありません。アプリのキャッシュ、ルーティングからの除外、同じ対応関係を経由しないDNSリクエストによって、仮想IPが誤って使われることがあります。クライアント、コア、通信の取り込み経路の組み合わせを確認したうえで有効にしてください。あらゆる名前解決トラブルに使える万能な解決策ではありません。

LANプリンター、社内ドメイン、企業ネットワークでは、適切な名前解決経路を特に維持する必要があります。新しいDNS設定を有効にした後、社内サービスだけ使えなくなった場合は、まず元の設定に戻し、必要な直接接続と名前解決の例外を追加してください。フィールド間の関係はconfig.jsonの構造解説、ルールデータの更新はGeoIP・GeoSiteデータベースの解説、仮想アドレスの仕組みはFakeDNSの仕組みをご覧ください。

接続確認：ローカルの入口から実際のリクエストまで

接続を確認するときは「起動中」という表示だけで判断しないでください。通信経路には、クライアントのプロセス、コアの待ち受け、アプリの通信取り込み、ルーティングの照合、リモートとのハンドシェイク、接続先サービスの応答が含まれます。前の段階が正常でも、次の段階も正常とは限りません。まずシステムプロキシでブラウザーのリクエストを確認し、次にシステムプロキシを参照しないアプリをテストし、最後にTUNを検討してください。これなら各段階を切り分けやすくなります。AndroidではVPNインターフェースが確立したことを確認してから、有効なノードと対象アプリの範囲を確認します。

再現可能なテストを行う

現在のネットワーク、有効なノード、プロキシモード、ルーティングモード、テスト対象を記録し、一度に一項目だけ変更してください。まず通常のネットワークでアクセスできるページを開いて基礎接続を確認し、次にプロキシを有効にして目的のサイトへアクセスします。テストには新しい接続を使い、必要に応じて古いタブを閉じるか、テストアプリを再起動してください。キャッシュの影響で常に成功しているように見えることがあります。クライアントのテストが成功しても、そのテスト項目が通ったことを示すだけで、すべての通信が使えるとは限りません。

ブラウザーでは使えるのに特定のプログラムで失敗する場合は、そのプログラムがシステムプロキシを参照するか、独自のプロキシを設定しているか、異なるプロトコルを使用しているか確認してください。HTTPプロキシで一般的なWebリクエストを処理できても、あらゆるUDP通信を同じ経路で利用できるとは限りません。TUNも通信を取り込む手段にすぎず、実際の通信にはリモートノードとコアの対応が必要です。アプリのネットワークエラーは、接続タイムアウト、証明書エラー、名前解決の失敗、サーバーによる拒否に分けて確認してください。すべてを単に「速度が遅い」と扱わないようにしましょう。

ログと確認結果を段階別に読む

認証失敗のログが出た場合は、ノードのパラメーターとサービスの状態を確認してください。接続拒否は、接続先ポートが開いていない、またはサービスが稼働していない可能性があります。タイムアウトは、期限内に想定した処理が完了しなかったことを示すだけで、原因はローカルネットワーク、通信経路、サーバーのいずれにもあり得ます。エラーメッセージは発生した段階と合わせて読みましょう。該当するリクエストがログにまったくない場合は、リモート側の設定を変更する前にアプリの入口を確認してください。詳細なログが必要な場合は、一時的にログレベルを上げ、原因を特定したら通常のレベルに戻します。アクセス情報を過剰に記録したままにしないでください。

遅延、ダウンロード速度、安定性を分けて確認する

疎通テスト、ハンドシェイク時間、大容量ファイルの転送速度は、それぞれ異なる指標です。応答遅延が小さくてもダウンロードが速いとは限らず、1回の速度測定が高くても長時間の接続が安定するとは限りません。同じ接続先、近い時間帯、同じネットワークで測定し、Wi-Fiの電波状況、帯域の使用状況、サーバー負荷も確認してください。すべてのノードを同時に測定して、その瞬間の結果だけで選ばないようにしましょう。同時テスト自体が回線を使い切り、測定結果に影響することがあります。

特定のノードだけ継続して失敗する場合は、別の設定と比較してください。あるネットワークでは全ノードが失敗し、ネットワークを変えると使える場合は、まずローカルのネットワーク経路を確認します。システムプロキシは正常でTUNだけ失敗する場合は、権限、ルーティング、DNSの取り込みを確認してください。結果を記録しておくほうが、何度も再インストールするより効果的です。さらに詳しい切り分け方はV2Rayの速度低下を段階別に調べる方法をご覧ください。間欠的な切断にも応用できます。

設定に関するよくある質問：更新、移行、トラブルからの復旧

ここでは、プラットフォームを問わず起こりやすい仕上げの問題を扱います。更新、ネットワーク切り替え、スリープ、ルール変更、プログラム終了のどの後に障害が発生したかを確認してから、復旧する段階を決めてください。設定が複雑になるほど、動作確認済みの基準を残すことが重要です。有効なノード一つ、明確なプロキシ設定、復元できるルールのバックアップを用意しましょう。変更を一つずつ元に戻せば、原因を判断しやすくなります。初心者が迷いやすいメニューについてはv2rayN初心者向けFAQ 10選も参考になります。

サブスクリプションの更新に成功したのに接続できないのはなぜ？

更新成功は、クライアントが何らかの取得または解析を完了したことを示すだけで、すべてのノードがオンラインであることを意味しません。設定が一覧に表示されているか、現在の有効なノードが今回更新したグループに属しているか、アカウントサービスが有効かを確認してください。提供元がURLを再発行した場合、古いURLはエラー内容を返し続けることがあります。アカウントページから完全なURLを取得し直してください。更新後に一部の項目を認識できない場合は、クライアントとコアのプロトコル対応を確認します。保存するためにセキュリティ設定を安易に削除しないでください。

手動で変更したサブスクリプションのノードは、次回の更新で上書きされる場合があります。カスタム設定を継続して使う場合は、クライアントが対応する方法で独立したグループにコピーし、変更の目的も記録してください。コピーしたノードが、元のサブスクリプションから今後もすべての更新を受け取ると考えないでください。両者の同期が切れている場合があります。端末を移行する際も、インポートするものがサブスクリプションURL、ノードのスナップショット、クライアントの完全なバックアップのどれなのか確認してください。それぞれ更新の挙動が異なります。

クライアント更新とコア切り替えの順序

更新前に必要なデータをエクスポートし、実行中の転送を停止してから、古いプログラムを通常終了してください。更新後は元のノードとモードでまず動作を確認し、基本機能が正常になってからコアの切り替えやルールの変更を検討します。クライアントとコアの更新が常に連動するとは限りません。GUIで項目を認識できても、実際に使うコアがその組み合わせに対応しているとは限りません。調査時は「更新した」という情報だけでなく、実際に使っているコアの名前とエラーの種類を記録してください。

デスクトップでコアを切り替える場合は、プロトコル、セキュリティ機構、通信方式、ルール形式を確認してください。同じ設定でも、コアによって対応範囲が異なる場合があります。一方のコア用のカスタム項目を、もう一方にそのまま流用しないでください。Androidのv2rayNGとv2flyNGは別々のアプリです。切り替える場合は、サブスクリプションの再インポート、VPNの許可、バックグラウンド権限の設定も必要になります。切り替え後だけ失敗する場合は、まず動作確認済みの組み合わせに戻し、結果を比較しながら互換性を調べてください。

終了後にネットワークへ接続できない場合の復旧手順

デスクトップでは、まずシステムプロキシが停止済みのローカルポートを参照していないか確認し、次にTUNが無効になっているか、最後にDNSとほかのVPNの状態を確認してください。ブラウザーに独自のプロキシ拡張機能がある場合は、そちらも個別に確認します。Androidでは「常時接続VPN」と「VPNを使用しない接続をブロック」の設定を確認し、システムが設定どおりに通信を遮断していないか確認してください。再起動で一時的な状態が解消することはありますが、誤った設定が保存されていると再起動後も同じ問題が起きます。

復旧時は、職場や家庭のネットワークで必要なプロキシとDNS設定を保持してください。設定をすべて初期化するのは避けましょう。PCからLAN内のサービスに接続する必要がある場合は、新しく有効にした通信取り込み機能を停止して元のネットワークを確認し、その後で例外ルールを一つずつ戻します。問題が1台だけに発生するなら、まずその端末を調べてください。同じネットワークのすべての端末で問題が起きる場合は、ルーター、上位回線、認証状態を確認します。クライアントが処理できるのは、クライアントに入った通信だけです。ネットワーク全体の基礎的な障害は修復できません。

トラブルを報告するときに残す情報

OS、クライアント名、コアの種類、通信の取り込み方法、障害が起きた手順、実施済みの比較テストを記載してください。ログは該当時刻の前後にあるエラーだけを切り出し、サブスクリプション、ユーザーID、パスワード、サーバーを特定できる情報を隠します。設定全体を送る必要はありません。再現できる場合は、「モードを切り替えると、特定のアプリで特定のエラーが出る」のように書くと、「ずっと接続できない」より原因を特定しやすくなります。インストールから接続までの手順をやり直す場合は使い方ガイドへ、インストール形式やアーキテクチャを確認する場合はダウンロードページへ戻ってください。