V2Rayのよくある質問

Windows・macOS・Linuxのデスクトップでは、まずv2rayNを選び、CPUアーキテクチャとOSに合ったインストーラーを選択します。AndroidではXrayコアを搭載したv2rayNGが第一候補です。既存の設定がV2Fly向けの場合は、v2flyNGも選択肢になります。いずれも設定の読み込み、サーバーの選択、接続管理を行うGUIクライアントです。利用できるプロトコルはクライアントに搭載されたコアとそのバージョンによって異なるため、アプリ名だけでは判断できません。移行前にサーバー側が対応するプロトコルとセキュリティレイヤーを確認してください。

クライアントは接続を管理するツールです。インストールしただけでは、接続先のサーバーは用意されません。接続にはサーバーアドレス、認証情報、ポート、プロトコルや通信方式の設定が必要で、通常はサブスクリプションURL、共有リンク、設定ファイルから取得します。サブスクリプションは設定項目をまとめて取得・更新するためのもので、クライアントが接続サービスを自動で提供するわけではありません。利用権限があり、信頼できる提供元から設定を入手してください。他人の設定一式を公開の場に転載したり、出所不明のサブスクリプションを繰り返し読み込んだりしないようにしましょう。

VMess・VLESS・Trojan・Shadowsocksはプロキシプロトコルの選択肢です。REALITYはVLESSなどと組み合わせるセキュリティレイヤーで、すべてのプロトコル項目を置き換える汎用タイプではありません。設定の読み込み時には、通信方式、TLS、SNI、フロー制御なども表示されることがあります。これらは接続の異なるレイヤーを指定する項目です。サーバー側から提示された設定一式に従い、トラブル対処のためにVLESSをVMessへ、TLSをREALITYへと安易に変更しないでください。必要な項目が画面にない場合は、使用中のクライアントとコアが対応しているか確認しましょう。

システムプロキシは、OSのプロキシ設定に従うアプリに接続経路を提供しますが、すべてのアプリが利用するとは限りません。TUNは仮想ネットワークインターフェースを通じて対象の通信を処理するため、通常は追加の権限が必要です。ほかの仮想NICやセキュリティソフトの影響を受けることもあります。ルーティングモードは、コアに届いた通信を直接接続・プロキシ・遮断のどれにするかを決めます。これらは同じ設定ではありません。ルーティングをグローバルプロキシにしても、プロキシ経路を通らないアプリの通信が自動的に取り込まれるわけではありません。まず通信がクライアントに届いているかを確認し、その後にルーティング先を調べましょう。

2015年以降に発売された一般的なAndroidスマートフォンではarm64が候補になりますが、実際に対応するアプリのアーキテクチャを優先してください。universal版は複数のアーキテクチャ向けコンポーネントを1つにまとめたもので、対応機種がわからない場合や複数の端末で使う場合に便利ですが、ファイルサイズは大きくなりがちです。arm64版で非対応と表示されたら、端末情報でCPUとOSのアーキテクチャを確認してからuniversal版を試してください。メーカー名や購入年だけで判断しないようにしましょう。インストール済みアプリの更新に失敗する場合は、配布元の署名が一致しているかも確認してください。

サブスクリプションURLと単独の共有リンクを区別し、それぞれに対応した読み込み方法を選びます。URLをコピーするときは、前後の空白や改行、説明文の混入を確認してください。WebページのURLが実際のサブスクリプションURLとは限りません。内容を取得できても認識されない場合は、ログイン画面やエラーページが返っているか、現在のバージョンが形式に対応していない可能性があります。URLの末尾だけで判断せず、提供元にクライアント対応形式を確認しましょう。サブスクリプションURLにはアクセス情報が含まれることが多いため、トラブル対処の際に公開変換サイトへ貼り付けたり、画面を撮影して公開したりしないでください。

サブスクリプショングループに有効なURLを追加して更新するか、対応するメニューから単独の共有リンクを読み込みます。一覧に設定が表示されたら、接続先のサーバーを1つ選択します。次にコアを起動し、システムプロキシのメニューから自動設定を有効にして、システムプロキシを使うブラウザーで確認したいサイトにアクセスします。アプリのアイコンだけでなく、ログにリクエストが記録されているか確認してください。メニュー名はバージョンによって異なる場合があります。設定を読み込む、サーバーを選ぶ、コアを起動する、通信経路を設定する、実際にアクセスを確認する、の順に進めましょう。

まずログを確認し、仮想NICの作成、ルートの追加、バックグラウンドサービスの起動のどこでエラーが発生したかを特定します。Windowsでは、使用中のバージョンの案内に従って管理者権限や付属サービスが必要になる場合があります。macOS・Linuxでは、アプリの案内に沿って必要なシステム権限を許可してください。AndroidではVPN接続にシステムの許可が必要です。許可ダイアログを確認し、同種の接続を別のアプリが使用していないかも調べましょう。切り分けのためにセキュリティ機能をすべて無効にするのは避けてください。権限を許可しても解決しない場合は、仮想NICの競合を確認します。一時的にシステムプロキシへ切り替えると、原因を絞り込みやすくなります。

v2rayNでは設定の提供元ごとにサブスクリプショングループを作成し、それぞれのURLを登録できます。グループや備考のキーワードで項目を絞り込むこともできます。更新時には提供元の内容が再同期されるため、提供元が削除・改名・変更したサーバーは、以前と同じ場所に表示されなくなる場合があります。ローカルのフィルターによって一時的に見えなくなっている可能性もあります。まず絞り込みを解除し、正しいグループを選んでから更新ログを確認しましょう。手動で管理する項目は別に保存し、重要な変更をサブスクリプション同期の項目だけに残さないようにしてください。設定の保持方法はクライアントのバージョンによって異なります。

まずクライアントの標準ルーティングで再現性のあるアクセスを確認し、その後、必要に応じてドメインルールやDNSを調整します。特定のサイトで問題が起きたら、ログに記録されたドメイン、適用されたルール、通信の出口を確認し、意図せず直接接続になっていないか調べてから、名前解決の結果とリモートDNSへの到達性を確認しましょう。ルーティングテンプレート、DNSアドレス、ドメインポリシーを同時に変更すると、原因を特定しにくくなります。geositeとgeoipのデータも判定結果に影響します。ルールデータを更新したら、あらためてテストしてください。すべての通信を同じ経路に切り替える方法は比較には使えますが、原因の切り分けの代わりにはなりません。

画面ロック、ネットワークの切り替え、システムによるバックグラウンドアプリの終了の後に切断されるかを確認します。Androidのバッテリー設定でv2rayNGのバックグラウンド動作が制限されていないか調べ、端末の設定に従って必要なバックグラウンド動作を許可してください。VPNの許可が維持されているか、ほかのネットワークアプリが接続を引き継いでいないかも確認します。省電力機能を一度にすべて無効にせず、まずv2rayNGだけ設定を変更して再テストしましょう。アプリが動作中でもリクエストに失敗する場合は、ネットワーク切り替え後に接続の再確立が必要な可能性があります。ログと再接続後の状態をあわせて確認してください。

まずサブスクリプションの提供元、手動で追加したサーバー、ルーティングの変更、DNS設定を記録し、現在のクライアントが対応する方法で必要なデータを書き出してください。サブスクリプションURLから設定を再取得できても、ローカルのグループ順、備考の変更、アプリの設定まですべて復元できるとは限りません。JSON形式の設定も、異なるコア間でそのまま使える保証はありません。移行後にプロトコル、セキュリティレイヤー、通信方式の項目を確認しましょう。エクスポートファイルや共有リンクには認証情報が含まれることがあるため、安全に管理できる場所に保存し、公開文書に掲載しないでください。新しい端末で接続を確認してから、古い端末に残る機密データを削除します。

まず更新ログで、ドメインの名前解決失敗、接続タイムアウト、アクセス拒否、内容の解析失敗を区別します。サブスクリプションが有効か、アカウントページでURLの再発行が必要になっていないか確認してください。現在選択中のサーバーが使えず、更新にもそのプロキシが必要な場合は、更新時にプロキシを経由しない設定を試せます。ただし、そのURLに直接接続できない場合は、利用可能な接続経路が必要です。取得は成功しても解析に失敗する場合は、返された内容がクライアントの対応形式か確認しましょう。DNSを手当たり次第に変更したり、グループをまとめて削除したりせず、まず元のURLとエラー情報を記録してください。

必ずしもそうとは限りません。テストによっては特定のポートだけを確認したり、プロキシ経由で指定のテスト先にアクセスしたりするため、結果はローカルネットワーク、テスト先、プロトコルのハンドシェイクに左右されます。まず通常のネットワーク接続を確認し、動作がわかっている別の設定と比較して、実際のWebサイトにもアクセスしてみましょう。1つだけ問題がある場合は、サーバーアドレス、ポート、認証情報、セキュリティレイヤーの設定を確認します。すべての設定で失敗する場合は、ローカルのファイアウォール、ネットワーク環境、コアの起動状態を優先して調べてください。テストを何度も繰り返しても設定ミスは直りません。同じ時間帯のログを保存すると原因を特定しやすくなります。

接続済みの表示は、通常、ローカルサービスや仮想インターフェースが起動したことを示すだけで、サーバーとのハンドシェイクやWebサイトへのアクセス成功を意味しません。まずログにブラウザーのリクエストがあるか確認します。リクエストがない場合は、システムプロキシの設定、ブラウザー独自のプロキシ設定、ほかのツールによるプロキシ設定の変更を確認してください。リクエストがある場合は、適用されたルート、DNS、通信先のエラーを調べます。別の設定とWebサイトでも試し、結果を比較しましょう。クライアントを終了する前に、メニューからシステムプロキシを解除してください。異常終了後に通常のネットワークも使えない場合は、停止したローカルポートを指すプロキシ設定がOSに残っていないか確認します。

ログ画面で、最初に失敗した時点の前後を含むエラー全文を保存します。アドレスが使用中と表示された場合は、クライアントの多重起動や、ほかのプログラムによるローカル待受ポートの使用を確認してください。設定項目のエラーが表示された場合は、読み込み形式と現在のコアの対応範囲を確認します。TLS証明書エラーでは、まずOSの時刻を合わせ、サーバー名、SNI、証明書のドメイン名が一致するか調べてください。証明書の検証を無効にしたまま使うのは避けましょう。他の人に相談する際は、サブスクリプションURL、認証情報、個人用パスを隠し、エラーの種類、関連する項目名、必要なOS・クライアント情報だけを共有してください。