V2Rayのよくある質問

V2Rayは一般に、Project Vに関連するプロキシ技術やツールのエコシステムを指します。V2FlyとXrayは、代表的なコアの系統です。コアはプロトコル接続、ルーティングの照合、データ転送を担い、GUIクライアントはサブスクリプション管理、設定画面、プロセスの起動を担います。トラブル対処では、クライアント名と実際に動作しているコアを分けて記録し、「V2Rayを使っている」とだけ書かないようにしましょう。プロトコルや伝送方式が動作するかどうかは、コアのバージョン、クライアントによる設定の生成方法、サーバー側のパラメーターが一致しているかにも左右されます。

Windows、macOS、Linuxのデスクトップでは、まずv2rayNを確認しましょう。Android端末では通常、Xrayコアを使うv2rayNGが選択肢です。V2Flyコアが必要な場合は、v2flyNGも検討してください。選ぶ際は名前の似ているかどうかではなく、端末のOS、サブスクリプションで必要なプロトコル、ルーティング要件を基準にします。読み込む前に設定がクライアントに対応しているか確認し、利用中の設定がある場合はバックアップを取っておきましょう。クライアントを変更した後は、システムプロキシや接続許可を改めて確認してください。以前のクライアントの接続状態は引き継がれません。

システムプロキシは、アプリからクライアントに接続する方法の一つで、主にシステムプロキシ設定に従うソフトに影響します。全般と中国本土を除外するモードはルーティング方針で、コアに届いた接続をどのアウトバウンドに流すかを決めます。全般を選んでも端末上のすべてのアプリが自動的に接続されるわけではありません。また、中国本土を除外するモードでも、各接続先が必ず直接接続されるとは限らず、ルールやその順序、データベースによって結果が変わります。テストでは、まずアプリの通信が実際にクライアントに届いているかを確認してから、ルーティング結果を調べましょう。接続経路の問題をルール振り分けの問題と取り違えないことが大切です。

クライアントは設定と接続の機能を提供しますが、インストールしただけで接続可能なリモートサーバーが用意されるわけではありません。リモートプロキシを利用するには、正規に取得したサブスクリプションURL、個別の共有リンク、またはサーバーの設定情報が必要です。サブスクリプションは設定一式を更新するためのもので、特定のプロトコルやクライアントのアカウントとは異なります。設定を入手したら、提供元、利用期限、対応クライアントを確認してから読み込みましょう。当サイトではクライアントの入手先と技術情報を案内していますが、接続先サーバーは提供していません。利用許可や容量については、各サービスの提供元にお問い合わせください。

サブスクリプションURLと個別の共有リンクを区別しましょう。前者はサブスクリプショングループに追加し、後者は「クリップボードから共有リンクを読み込む」などの機能を使います。URLをコピーするときは、前後の空白や改行、チャットアプリが付けた句読点を取り除き、案内ページのURLをコピーしていないか確認してください。次に読み込み時のメッセージを確認します。Webページが返された場合や形式に対応していない場合は、提供元のサブスクリプション形式がクライアントに対応しているか確認しましょう。アクセス情報が含まれることがあるため、サブスクリプションURL全体を公開の場に投稿しないでください。読み込み後はグループを更新し、設定が表示されていることも確認します。

新しいAndroidスマートフォンの多くはarm64ですが、最終的には端末のOSが対応するアプリのアーキテクチャを確認してください。プロセッサーの型番や購入年だけでは判断できません。64ビットアプリに対応していると確認できた場合はarm64を選び、アーキテクチャが不明な場合はuniversalを選べます。ただし、インストールファイルのサイズは大きくなる傾向があります。解析エラーやインストール失敗が起きた場合は、OSのバージョン、提供元不明アプリのインストール許可、同じ名前で署名の異なるアプリが入っていないかも確認してください。古いアプリを削除する前に設定をエクスポートし、バックアップが使えることを確かめて、カスタムルールの消失を防ぎましょう。

まずシステム情報でOSとプロセッサーのアーキテクチャを確認し、該当するプラットフォームのダウンロードページから選びます。Windowsはデスクトップ版と従来のWPF版、macOSはApple Silicon版とIntel版を選択します。Linuxではディストリビューションのパッケージ形式に加えて、x64とarm64の違いも確認してください。debとrpmはパッケージ管理方式の違いであり、プロキシプロトコルの違いではありません。インストールエラーが出たら、パッケージ名とシステムのエラーメッセージを記録し、対応環境や依存関係を確認しましょう。コアを適当に入れ替えたり、プログラムのディレクトリを上書きしたりして、インストール時の問題を解決しようとしないでください。

TUNは仮想ネットワークインターフェースを作成し、ルートを変更するため、デスクトップでは通常、管理者権限や権限昇格サービス、または適切なネットワーク機能が必要です。まずTUNを無効にして通常のプロキシで接続できることを確認し、現在のクライアントの案内に従って許可を与えます。LinuxではTUNデバイスが用意され、必要な権限があることも確認してください。AndroidではシステムVPNの許可が必要です。接続確認画面で許可してください。別のVPNやネットワーク制御ソフトが動作している場合は、いったん停止してから再試行します。許可後も失敗する場合は、インターフェース作成時のログを確認してください。ファイアウォール全体を無効にしたり、権限を恒常的に広く緩めたりするのは避けましょう。

設定を一つ選んで接続を開始し、システムプロキシに従うことが明確なブラウザーで、アクセス可能とわかっているサイトを開きます。同時にクライアントの接続履歴やログを確認し、テスト通信がコアに届き、想定したアウトバウンドを使っているか調べましょう。接続アイコンが示すのは、通常、プロセスやローカルサービスが起動したことだけで、リモートとのハンドシェイク成功を保証しません。テスト中はルーティングを一時的に簡素化し、終了後に通常の設定へ戻せます。ブラウザーでは使えて他のソフトでは使えない場合は、そのソフトのプロキシ設定と接続方法を確認してください。サーバー設定一式をすぐに変更する必要はありません。

ルーティングは通常、設定された順序で照合されます。広い範囲を対象にするルールが先にあると、後続の細かいルールが適用されないことがあります。まず、リクエストが現在の設定に届いていることを確認し、domain、ip、outboundTagの条件とタグが対応しているかを調べてから、適用ログを確認します。ドメインルールを使うには、コアがドメイン情報を取得できる必要があります。宛先IPしか分からない場合、geositeのルールに一致しないことがあります。geoipとgeositeのデータも設定との互換性が必要です。変更は一度に一つに絞り、設定を再起動または再読み込みしてください。変更前のルールを残しておけば、結果の比較や切り戻しが容易になります。

バックグラウンドで切断される場合は、まずシステムがv2rayNGのバックグラウンド動作を制限していないか確認します。必要に応じてバッテリー設定でバックグラウンド実行を許可し、システムVPNの許可が有効かも確認してください。端末によっては自動起動を別途許可する必要があります。メニュー名はOSのバージョンによって異なります。アプリ別設定では、選んだアプリだけをプロキシ経由にするのか、選んだアプリを除外するのかを確認し、保存後に接続し直してテストします。システムVPNのアイコンが表示されていても、すべてのアプリがプロキシを通るとは限りません。対象アプリの指定を逆にすると、ブラウザーと他のアプリで挙動が大きく異なることがあります。

最低限、サブスクリプショングループ、カスタムサーバー、ルーティングルール、DNS設定、ローカルの待ち受けポートを保存します。エクスポート機能を使った後、バックアップファイルが実際に作成され、後から見つけられる場所に保存されていることを確認してください。コアによって対応するプロトコル項目やルーティング構文が異なる場合があります。切り替え後は、動作確認済みの設定を一つ使ってテストしてから、複雑なルールを戻しましょう。サブスクリプションを再更新しても、手動で追加した項目が復元されるとは限りません。バックアップにはサブスクリプションの認証情報やサーバーの認証情報が含まれる場合があるため、アクセスを制限し、通常のスクリーンショットやログの添付ファイルとして公開しないでください。

まず更新ログを読み、ドメインの名前解決、接続タイムアウト、証明書エラー、認証失敗、コンテンツ解析エラーを切り分けます。サブスクリプションの有効期限、端末の日付、URLが提供元によって変更されていないかも確認してください。更新にプロキシが必要なのに、選択中のノードがすでに使えない場合、更新も接続もできない状態に陥ることがあります。クライアントの更新方法に従って直接接続を試すか、動作確認済みの別の設定に切り替えてください。認証エラーが返された場合はサブスクリプションの状態を確認します。リクエストを何度も繰り返したり、証明書の検証を無効にして問題を隠したりしないでください。

まず、タイムアウトが接続先への接続、プロトコルのハンドシェイク、実際のリクエストのどの段階で発生しているか確認します。サーバーアドレス、ポート、伝送方式、TLSやREALITY関連の項目が提供元の情報と一致しているか、端末の時刻が正確かを確認してください。次に、同じ設定でネットワークを変えて試すか、同じネットワークで動作確認済みの別設定と比較します。一度に変更する条件は一つにしましょう。ICMPテストの失敗だけではプロキシが使えないとは限らず、TCP接続の成功もプロトコル認証の成功を意味しません。認証やハンドシェイクのエラーがログにある場合は、ローカルのルーティングを繰り返し調整するのではなく、まずパラメーターを確認してください。

まずTUNと複雑なルールを一時停止し、通常のシステムプロキシで動作確認済みの設定をテストします。コアが正常に動作していること、ローカルの待ち受けアドレスとポートがシステムプロキシの設定と一致していることを確認し、ブラウザー拡張機能や他のプロキシツールが設定を上書きしていないかも調べてください。ログにテストリクエストがない場合は、アプリがシステムプロキシに従っているかを確認します。リクエストはあるものの名前解決に失敗する場合はDNSを、ハンドシェイクに失敗する場合はリモート側の設定を確認してください。コマンドラインツールや一部のデスクトップアプリでは、個別にプロキシを設定する必要があります。クライアント終了後もネットにつながらない場合は、停止済みポートを指すシステムプロキシ設定が残っていないか確認しましょう。

まずクライアントからTUNを正しく無効にし、他のVPNを終了します。DNSを自動取得に戻すか、以前使えていたネットワーク設定に戻してから、基本的なネットワーク接続をテストしてください。基本接続は正常で、クライアントを有効にしたときだけ失敗する場合は、DNSリクエストが使うアウトバウンド、DNSサーバーへの到達性、まだ確立していないプロキシへの依存を確認し、名前解決のループを防ぎます。再起動が必要な場合は、先にログと設定を保存し、再起動後はネットワーク制御ツールを一つだけ起動してください。接続が戻ったら、ルーティング、DNS、TUNを一つずつ有効にして原因を特定します。すべての設定を一度にリセットすると、原因を特定しにくくなります。