V2Rayのよくある質問
設定・接続のトラブル対処

V2RayはProject Vのエコシステムに属し、V2Flyは関連するコアの開発を引き継いでいます。Xrayは別の系統で開発されているコアです。コアはプロトコル接続、ルーティング、DNSを処理し、v2rayNはそれらの設定を管理するデスクトップ用GUIを提供します。Androidでは、v2rayNGはXrayコア、v2flyNGはv2flyコアを採用するのが一般的です。クライアントがリンクを読み込めても、現在のコアがすべてのパラメーターに対応しているとは限りません。選ぶ際はプロトコル、転送方式、セキュリティ層、実際に使われるコアのバージョンを確認してください。

クライアントは設定を読み込んで接続を確立するもので、インストールしただけで利用可能なサーバー情報が生成されるわけではありません。利用権限のあるサブスクリプションURL、共有リンク、またはサーバー設定一式を用意してください。手動で入力する場合は、サーバーアドレス、ポート、ユーザーIDまたはパスワード、TLSや転送方式などのパラメーターをサーバー側と一致させる必要があります。まず端末が通常のネットワークに接続できることを確認し、提供元が明確な設定を1つ読み込んでテストしましょう。クライアントのインストール完了とサーバーへの接続成功は別の状態です。

システムプロキシを使うと、その設定に従うアプリの通信がクライアントに渡されます。設定に従わないアプリは、引き続き直接接続する場合があります。TUNは仮想ネットワークインターフェース経由で通信を取り込み、より広い範囲をカバーできますが、システム権限やルーティング、DNSの設定が必要です。ルーティングは、通信がコアに入った後、プロキシ経由・直接接続・遮断のいずれにするかを決めます。それぞれ役割が異なるため、トラブル時はまずアプリの通信がクライアントに届いているか確認し、その後ルーティングを調べてください。TUNを有効にしただけで、すべての通信がプロキシ経由になるとは限りません。

まずサーバー側が提供する方式を選んでください。クライアントでプロトコル名だけ変更しても、方式を変換できるわけではありません。VLESS、VMess、Trojanでは認証項目やセキュリティ設定が異なります。REALITYは通常、VLESSなどと組み合わせるセキュリティ層の設定であり、任意に置き換えられるプロトコル名ではありません。比較時はTLS、転送方式、コアの対応状況も確認してください。環境に関係なく適用できる速度ランキングはありません。サーバー側が明確に対応し、必要なパラメーターがそろっていて、クライアントのコアと互換性のある組み合わせを選び、実際の接続状況で判断しましょう。

まず追加する内容の種類を確認してください。共有リンクは通常vmess://、vless://、trojan://、ss://で始まり、サブスクリプションURLは通常HTTPSのURLです。コピー時に付いた説明文や改行、前後の空白を削除し、クリップボードからの追加、またはサブスクリプショングループ用の画面を使いましょう。未対応と表示された場合は、クライアントとコアがその転送設定に対応しているか確認してください。WebページのURL、ログインページ、JSONファイルをすべて共有リンクとして扱うことはできません。複雑なアウトバウンドやルーティングを含むJSONも、単一のサーバー設定に変換できるとは限りません。

比較的新しいAndroidスマートフォンではarm64を選ぶのが一般的ですが、最終的には端末のOSが対応するABIを確認してください。プロセッサーの製品名だけでは判断できません。universal版は通常、複数のアーキテクチャに対応するためファイルサイズが大きく、端末のアーキテクチャが分からない場合に便利です。対応アーキテクチャはクライアントの配布パッケージによって異なります。解析エラーや互換性の警告が表示されたら、OSのバージョン、インストールファイルのダウンロード完了、旧版アプリとの署名の一致も確認してください。別のクライアントに切り替える前に設定をバックアップし、唯一の設定コピーを残したままアンインストールしないようにしましょう。

v2rayNで使用するサーバーを選び、コアが正常に起動していることを確認してから、必要に応じてシステムプロキシを設定するかTUNを有効にします。リストの項目を選択しただけでは、アプリの通信が取り込まれたことにはなりません。Androidではクライアントのサービスを起動し、VPNモードを使う場合はシステムの接続許可に同意してください。実際のブラウザーでアクセスを試し、ログからリクエストがコアに届いているか、どのアウトバウンドが使われたかを確認します。画面上の接続状態や遅延の結果が示すのは一部の状況だけです。それだけでブラウザー、DNS、接続先サイトがすべて正常だとは判断できません。

デスクトップでは、まずログで失敗した処理を確認してください。仮想インターフェースの作成、ルートの追加、ポートのバインドでは、それぞれ対処方法が異なります。Windowsではクライアントの要件に応じて管理者権限で実行してください。macOSとLinuxでは、使用中のバージョンの説明に従ってシステムの許可や補助コンポーネントのインストールを行い、ファイル権限を一律に緩めないでください。AndroidのVPN許可とデスクトップのTUN権限は仕組みが異なります。通常はVPNインターフェースを使用中のほかのアプリも停止する必要があります。許可した後にサービスを再起動し、古い仮想インターフェースやほかのネットワークツールのルートが競合していないか確認しましょう。

サブスクリプションの内容と手動設定は、別々のグループに分けてください。更新前に、どのサブスクリプショングループを操作するか確認しましょう。更新時には、リモートの内容に応じてグループ内のサーバー設定が再作成または変更されることがあります。長期間残したい手動変更を、サブスクリプション由来の設定だけに加えるのは避けてください。編集が必要なら、設定を複製して独立したものとして保存します。認証情報を更新した場合は、サーバー側も確認してください。クライアントのエクスポートやバックアップ機能を定期的に使い、ファイルを安全に保管しましょう。サブスクリプションURLやエクスポートした設定にはアクセス情報が含まれることがあるため、スクリーンショットや添付ファイルとして公開しないでください。

まずクライアント内蔵のルーティング設定を使い、カスタムルールは1つずつ追加してください。設定一式を一度に置き換えるのは避けましょう。ルールの優先順位、ドメイン判定方式、デフォルトのアウトバウンドを確認します。たとえばgeosite:category-ads-all → blockは、該当するドメインセットに一致した通信を遮断する設定ですが、使用するコアとルールデータがこの形式に対応している必要があります。ルール形式はコアごとに異なり、共通ではありません。変更後は、直接接続する対象とプロキシ経由にする対象をそれぞれテストし、ログも確認してください。IPIfNonMatchはドメイン名が一致しない場合の名前解決判定に関わる設定で、すべてのドメインをプロキシ経由にするスイッチではありません。

まず、システムがサービスを停止したのか、サービスは動作中でも接続が切れたのかを切り分けます。前者は、バッテリー最適化、バックグラウンド実行の許可、メーカー独自のアプリ休止設定を確認し、必要に応じてクライアントの継続実行を許可します。後者は、ネットワークの切り替わり、サブスクリプション設定、コアのログを確認してください。電池消費を調べる際は、長時間の通信、頻繁な再接続、不要なバックグラウンド通信に注目します。必要ならアプリごとのプロキシ設定で対象を絞りましょう。VPNモードだからといって必ず異常に電池を消費するわけではありません。動作維持のために、すべてのアプリのバッテリー制限を無効にするのも避けてください。一度に変更する設定は1つにして、改善するか確認しましょう。

サブスクリプションURLにはアクセストークンが含まれる場合があり、共有リンクやQRコードには接続に必要な認証情報が含まれることがあります。調査資料を提出する前に、URL内の機密部分、ユーザーID、パスワード、非公開サーバーのアドレス、公開したくないアクセス先のドメインを隠してください。クライアント名、正確なバージョン、OSの種類、エラー全文、発生時刻は残しておくと、原因を特定しやすくなります。状況説明のために設定一式をそのまま公開しないでください。情報を伏せたうえで、プロトコル、転送方式、セキュリティ層と、最近変更した設定を説明しましょう。

まず端末が通常のネットワークに接続できることを確認し、サーバーアドレスを名前解決できるか、ポートが正しいか、サブスクリプションの期限が切れていないか、サーバーが稼働中かを調べます。クライアントのTCPテストと、実際のプロキシ通信は別のテストです。ポートに接続できてもプロトコル認証の成功を意味せず、1回のタイムアウトだけで設定が無効とは判断できません。同じ設定を別のネットワークでも試し、認証、TLS、転送方式に関するログを確認してください。特定の設定だけ失敗する場合は、その設定を優先して調べます。すべて失敗する場合は、端末上のプロキシ競合、DNS、現在のネットワーク状態を確認しましょう。

ブラウザーからアクセスしたときに、クライアントのログにリクエストが記録されるか確認します。記録がない場合は、システムプロキシが有効か、ブラウザー独自のプロキシ設定が使われていないか、アプリごとのルールで対象アプリが除外されていないかを調べてください。ログがあるのにアクセスできない場合は、DNSの名前解決、ルーティング先の誤り、接続先への接続失敗を切り分けます。ドメイン名でのみ失敗するならDNSを重点的に確認しますが、HTTPSサイトにIPアドレスで直接接続する方法は一般的な確認手段ではありません。既知の設定に一度戻して順にテストし、DNS、ルーティング、転送パラメーターを同時に変更して原因が分からなくなるのを避けましょう。

クライアントの設定画面で実際のローカル待ち受けポートを確認し、システムプロキシの接続先アドレスとポートが一致しているか調べてください。設定によってはsocks 10808、http 10809が使われますが、すべてのバージョンや設定で共通の値ではありません。現在の画面とログを基準にしてください。ブラウザー拡張、ほかのプロキシソフト、企業の管理ポリシーがシステム設定を上書きすることがあります。システムプロキシを参照しないアプリは個別に設定するか、適切なTUN接続方式を使う必要があります。ほかのプロキシツールを終了してからシステムプロキシを設定し直し、ポートが使用中でないか確認してください。ローカル側の接続問題を解決するためにサーバーを何度も切り替えるのは避けましょう。

サブスクリプションの更新に失敗したら、URLが完全か、アクセストークンが有効か、応答がログインページやエラーページに変わっていないか確認します。接続タイムアウトと、返された内容の形式エラーは分けて対処してください。プロキシ経由で更新する場合は、まず現在のプロキシが動作している必要があります。必要に応じてクライアントが対応する別の更新方法を使いましょう。TLSハンドシェイクエラーでは、システム時刻、証明書の有効期限、SNI、サーバー側の要件を確認します。サブスクリプションのドメイン名とサーバー設定のserverNameを混同しないでください。allowInsecureで証明書検証を無効にした状態を長期間続けるのはおすすめできません。時刻、ドメイン名、サーバー証明書を修正してから再テストしましょう。