V2Rayのよくある質問、設定とトラブル対処

V2RayはProject Vのプロキシエコシステムの中核プロジェクトです。V2Flyは関連するコアの開発を引き継ぎ、Xrayは別系統のコアとして開発されています。コアは接続、プロトコル処理、DNS、ルーティングを担い、v2rayNは設定を管理するGUIクライアントです。デスクトップではv2rayN、AndroidではXrayコアを採用したv2rayNG、またはV2Flyコアを採用したv2flyNGを利用できます。画面上でノードを追加できても、設定が取り込まれただけで、サーバーへの接続が成功したとは限りません。トラブル時は、まずクライアントがコアを起動しているか確認し、次に接続ログを確認してください。コアを切り替える前に、ノードのプロトコルとトランスポート設定が対応しているか確認しましょう。コアの名称だけで接続品質は判断できません。

クライアントは端末上の設定と通信転送を行うツールで、インストーラーに利用可能なリモートサービスが含まれているわけではありません。ノードにはサーバーのアドレス、ポート、プロトコル、認証情報、トランスポート設定が含まれます。サブスクリプションは、クライアントがノード一覧を定期取得するためのURLです。利用権のあるサービス、または自分で構築したサーバーから設定を入手し、クライアントに登録してください。サブスクリプションを読み込めることと、掲載されたノードに接続できることは別です。有効期限、サーバーの稼働状況、現在のネットワークも確認しましょう。ローカルのSOCKSアドレス127.0.0.1をリモートノードとして登録しないでください。また、サブスクリプションURLを公開スクリーンショットや掲示板に載せないでください。アカウントへのアクセス情報が含まれる場合があるため、機密情報として管理しましょう。

プロトコルはクライアントで自由に選ぶものではなく、サーバー側の設定で決まります。共有リンクを読み込む際は、提供元のプロトコル、ポート、トランスポート方式、セキュリティ設定をそのまま使用してください。VLESSノードでは特定のflow、REALITYの公開鍵、サーバー名が必要な場合があります。TrojanはTLSと組み合わせることが多く、VMessとShadowsocksにもそれぞれ認証情報や暗号化設定があります。プロトコルの選択欄だけを変更すると、接続できなくなることがあります。また、プロトコル名だけで速度が向上するわけではありません。初回設定では完全な共有リンクまたはQRコードを使い、接続できてから各項目を確認しましょう。プロトコルを移行する場合はサーバー側とクライアント側の両方を変更し、使用するコアがその組み合わせに対応しているか確認してください。

この3つはそれぞれ異なる役割を担います。システムプロキシはアプリにローカルのプロキシアドレスを通知する設定で、システムプロキシに対応したアプリだけが利用します。TUNは仮想ネットワークインターフェース経由で通信を取り込み、システムプロキシを参照しないアプリも対象にできる場合があります。グローバルモードはコアに取り込まれた後のルーティング方針を示し、通常は条件に一致した通信をプロキシ経由にしますが、すべてのアプリの通信を自動的に取り込むわけではありません。ルールベースのモードでは、ドメインやIPなどに応じて直接接続、プロキシ経由、遮断を選びます。アプリがプロキシを経由しているか調べるには、まず通信がクライアントに届いているか、次にどのルールに一致したかを確認してください。トラブルの初期段階では接続方式を1つに絞って検証し、システムプロキシ、TUN、ルーティングを同時に変更しないようにしましょう。

arm64版は64ビットARMアーキテクチャを採用し、対応アプリを実行できる端末向けで、一般にファイルサイズが小さくなります。universal版は複数の対応アーキテクチャを含むため、端末のアーキテクチャがわからない場合に適しています。近年の主流スマートフォンではarm64を選べることが多いものの、購入時期やプロセッサの製品説明だけでは判断できず、32ビットシステムで動作する端末もあります。アプリをインストールできない場合は、まずOSのバージョン、空き容量、既存アプリの署名、インストール権限を確認し、その後でアーキテクチャを確認してください。アップデート前にサブスクリプションのグループやカスタムルールを保存し、インストール競合を解消するためにアプリを削除して設定を失わないようにしましょう。v2rayNGとv2flyNGはそれぞれ別のアプリです。インストールパッケージも個別に選び、同一アプリの別バージョンとして上書きしないでください。

まず、サブスクリプションURLと個別ノードの共有リンクを区別してください。サブスクリプションURLはサブスクリプショングループのURL欄に入力し、個別ノードのリンクはクリップボードや共有リンクからのインポート機能を使います。v2rayNではグループを保存した後、サブスクリプションを更新する必要があります。v2rayNGも、サブスクリプションを追加しただけでなく更新してください。名前だけを保存してもノードは取得されません。コピーした内容が欠けていないか、前後の空白や改行がないか、WebサイトのログインURLや説明文を一緒に貼り付けていないか確認しましょう。ログに解析エラーが出る場合、返された内容がログインページやエラーページだったり、クライアントが対応していない設定形式だったりする可能性があります。提供元に確認してください。名前の変更や再インストールで形式の問題を直そうとせず、まず対応済みとわかっているノードリンクでインポート機能を確認しましょう。

サブスクリプションの更新先はサブスクリプションサービスのURLで、ノード接続先のサーバーとは異なる場合があります。そのため、片方だけ成功することもあります。まずURLの有効期限、アカウントの状態、ログに記録されたHTTPステータスやタイムアウトを確認してください。サブスクリプションURLへのアクセスにプロキシが必要な場合は、接続できるノードを有効にしてから、クライアントの「プロキシ経由で更新」機能を選びます。直結が必要な場合は、直結で更新してください。項目名や場所はクライアントのバージョンによって異なります。システム時刻のずれ、DNSの名前解決エラー、ネットワークのログイン画面による妨げも確認しましょう。更新に失敗しても、既存のグループは残しておき、ノードをすべて削除しないでください。取得内容が長期間空のまま、または形式が変わった場合は、提供元にサブスクリプション形式を確認してください。

TUNでは仮想ネットワークインターフェースの作成とルーティングの変更が必要なため、通常のローカルプロキシより高い権限が必要です。Windowsでは、クライアントの案内に従って管理者権限で起動するか、必要なサービスを設定してください。Linuxでは、使用中のバージョンにおける権限の仕組み、仮想ネットワークデバイスへのアクセス権、サービスの状態を確認します。macOSでは、システムの案内に従って必要な許可を行ってください。AndroidではシステムのVPN許可を確認します。通常、同時に実行できるVPNサービスは1つです。まず同種のインターフェースを使用する他のツールを終了し、クライアントログに記録された具体的なエラーを確認しましょう。権限の問題をすべてノードの障害と決めつけたり、システムファイルの権限をむやみに変更したりしないでください。許可の設定がすぐにできない場合は、まずシステムプロキシでノードを検証し、通常の接続が安定してからTUNを設定しましょう。

普段のブラウジングでは、プロキシが必要な接続だけをプロキシ経由にし、それ以外はルールに従って直接接続するルールベースのモードから試すとよいでしょう。「中国大陸を除外」は通常、中国大陸のドメインやIPを分類し、直接接続するプリセットですが、具体的な動作はクライアントのルールセットによって異なります。グローバルモードはプロキシの出口を一時的に確認するときや、通信経路を統一してテストするときに便利です。ただし、すべてのアプリの通信が自動的にクライアントに取り込まれるわけではありません。切り替えた後は同じ接続先で再試行し、以前の接続が残らないよう、必要に応じて開いているページやアプリを閉じてください。グローバルモードでは接続できるのにルールベースのモードではできない場合、すぐにノードを変更せず、ルールの順序、分類データ、DNSを確認しましょう。テスト後は普段使う設定に戻し、不要な通信がプロキシ経由にならないようにしてください。

多くのコマンドラインツールはデスクトップのシステムプロキシを自動で参照しません。ツール内でプロキシアドレスを設定するか、実行中のプロセスに環境変数を設定してください。まずクライアントで実際の待受アドレス、ポート、プロトコルを確認します。SOCKSポートが10808の場合は、curl -x socks5h://127.0.0.1:10808 -I https://www.example.com を実行して接続を確認できます。ポートが異なる場合はコマンドも変更してください。socks5hは接続先のドメイン名をプロキシ側で名前解決する指定で、ローカルで名前解決する場合とは動作が異なります。アプリがコンテナや仮想マシン内で動いている場合、127.0.0.1はその環境自身を指し、ホストマシンを指すとは限りません。まずホストマシンで接続を確認し、その後、隔離環境からネットワークにアクセスできるか確認しましょう。手間を省くために、プロキシの待受をすべてのネットワークに公開しないでください。

ほかの端末では、クライアントを実行しているマシンのLAN内IPアドレスと対応するプロキシポートを指定します。127.0.0.1は常に設定中の端末自身を指すため、入力しないでください。v2rayNでLANからの接続を許可した後は、コアの待受範囲、システムファイアウォール、端末間のネットワーク接続も確認します。ルーターのゲストネットワークや無線端末間の通信分離によってアクセスが遮断される場合があります。また、HTTPとSOCKSのポートは任意に入れ替えられません。共有は信頼できるネットワークでのみ有効にし、ファイアウォールの許可範囲を必要な端末やネットワークセグメントに限定して、インターネットに公開されないようにしてください。接続できない場合は、まず同じLAN内からポートにアクセスできるか確認し、その後ノードの状態を調べます。共有が不要になったら設定を無効にし、待受設定を元に戻してください。

各端末で同じサブスクリプションURLを使ってノード一覧を更新するか、個別ノードの共有リンクやQRコードで設定を渡せます。サブスクリプションで配布されるのは通常ノード情報のみで、システムプロキシ、TUNの権限、ローカルポート、すべてのルーティングルールは同期されません。同じノード一覧でも通信経路が同じとは限りません。まずサブスクリプションの取得元と更新タイミングを統一し、各端末で使用中のノード、ルールベースのモード、DNS、カスタムルールを確認してください。デスクトップ版とAndroid版では画面や対応機能が異なるため、設定ファイル全体をそのまま相互に使うのは避け、読み込み前に形式の互換性を確認しましょう。QRコードやバックアップファイルを共有する際は、認証情報が含まれていないか確認し、公開アルバムやグループチャットには保存しないでください。端末を切り替えた後はあらためて接続をテストし、ノード名だけで設定が一致していると判断しないようにしましょう。

必ずしもそうとは限りません。TCP接続テスト、実際のリクエストテスト、アプリでのアクセス確認では、検証している内容が異なります。テスト先自体に到達できない場合もタイムアウトになります。まずコアが正常に起動しているかを確認し、ノードのアドレスとポート、システム時刻、トランスポート設定を見直してください。TLSのサーバー名、REALITYの公開鍵、flowの設定ミスによってハンドシェイクに失敗することもあります。接続できるとわかっているノードと同じテスト先で比較し、別の正常なネットワーク接続も試して、サーバー側と現在のネットワークのどちらに問題があるか切り分けましょう。一度のテスト結果を継続的な接続保証と考えたり、設定ミスを隠すためにタイムアウト時間だけを延ばしたりしないでください。複数のノードが同時に失敗する場合は、まずローカルネットワークとクライアントログを確認します。特定のノードだけ失敗する場合は、提供元に問い合わせてください。

「接続済み」はコアやVPNインターフェースが起動したことを示すだけで、すべての接続先へのリクエストが成功するとは限りません。まず端末からネットワークに正常に接続でき、ネットワークのログインも完了しているか確認します。次にシステム時刻、使用中のノード、クライアントログを確認してください。その後、ローカルの待受ポートとアプリのプロキシ設定を確認し、プロキシを明示したリクエストで通信がそのポートを通るかテストします。そのテストは成功するのにブラウザーで開けない場合は、ブラウザーのプロキシ拡張機能とシステム設定を確認します。リクエストがコアに届いてから失敗する場合は、グローバルモードとルールベースのモードを一時的に比較し、ルーティングまたはDNSの問題を切り分けてください。TUNを使っている場合は、仮想インターフェースとルーティングも確認します。一度に変更する設定は1つにして、結果を記録してください。ノードの切り替え、DNSの変更、全ルールのリセットを同時に行うと、どの操作で解決したのか判断しにくくなります。

まず、クライアントに設定されたプロキシアドレスとシステムのネットワーク設定が一致しているか確認し、該当ポートが実際に待ち受けていることを確認してください。Linuxではデスクトップ環境によってシステムプロキシへの対応が異なり、独自の設定や環境変数だけを参照するアプリもあります。ブラウザーの拡張機能がシステムプロキシの設定を上書きすることもあります。プロキシを明示できるツールで接続をテストし、成功する場合はコアを再インストールするのではなく、アプリの通信がクライアントに取り込まれる方法を確認しましょう。通信がクライアントに届いていないのか、届いた後にルールによって直接接続されているのかも、リクエストログで切り分けてください。システムプロキシを参照しないアプリも対象にする必要がある場合は、TUNの利用を検討します。クライアント終了後にネットワークへ接続できなくなった場合は、システムプロキシの設定を元に戻してください。待受が停止しているのにシステムがそのポートを参照し続けていると、アプリの接続に失敗します。

まず、アクセスできないドメインとログのエラーを記録し、名前解決の失敗、接続タイムアウト、証明書エラーを区別します。グローバルモードとルールベースのモードを比較してください。ルールベースのモードだけで失敗する場合は、優先順位の高いカスタムルールが誤った経路に送っていないか、geositeやgeoipの分類データがルールと合っているかを確認します。DNS設定は通信の出口に合わせ、ノードサーバーのアドレスとアクセス先のドメインがそれぞれどこで名前解決されるか確認してください。ブラウザーのセキュアDNSが別の経路で名前解決していることもあります。設定を変更したら接続を張り直し、必要であればアプリのキャッシュを消して同じドメインをテストします。TLSを使用するドメインへのアクセスにIPアドレスを常用すると、サーバー名や証明書の検証に影響する場合があります。ログにIPv6が関係するエラーがある場合は、IPv6のネットワーク接続も確認し、根拠なく複数のDNS設定を同時に変更しないでください。