V2Rayのよくある質問

V2RayはProject Vのプロキシ技術エコシステムの一部です。コアはプロトコル処理、インバウンドの待ち受け、ルーティングを担当し、クライアントはGUIを提供してノードの保存、サブスクリプションの更新、コアの起動を行います。v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けのクライアントです。トラブル時は、画面操作の失敗かコアの接続失敗かをまず切り分けましょう。サブスクリプションにノードが表示されない場合は読み込み結果を確認し、ノードがあるのに接続できない場合はコアのログを確認します。何でも最初にクライアントを再インストールするのは避けてください。

デスクトップではまずv2rayNを選びましょう。Androidでは通常、Xrayコアを採用するv2rayNGが適しています。V2Flyコアの動作が必要な場合や、互換性のある設定をすでに使っている場合はv2flyNGを検討してください。REALITYやXTLS VisionはXray関連の機能です。クライアント名が似ているだけで対応しているとは判断できません。サーバーが要求するプロトコル、安全レイヤー、トランスポート方式を確認し、クライアントに含まれるコアの対応状況と照らし合わせてください。Android向けの2つのクライアントは設定を別々に保存するため、アプリを切り替えるとサブスクリプションを再読み込みする必要がある場合があります。

クライアントは接続用のツールであり、インストーラーにそのまま使えるリモートサーバーが含まれているわけではありません。接続には、正規に入手したサーバーアドレス、ポート、認証情報と、サーバー側に合ったプロトコルおよびトランスポート設定が必要です。サブスクリプションは設定をまとめて配布するためのアドレスで、クライアントのアカウントではありません。サブスクリプションを入手したら、まず読み込んでノード一覧を更新し、接続先のサーバーを選択してください。ノードがない状態でシステムプロキシやTUNを切り替えてもサーバー情報は補われず、プロキシ接続も確立できません。

VMess、VLESS、Trojanはプロキシプロトコルの名称で、REALITYはXrayが提供するセキュアなトランスポート方式です。これらを互いに排他的な4つのプロトコルとして扱うことはできません。ノードにはTCP、WebSocket、gRPCなどのトランスポート設定や、TLS、SNIなどの項目が含まれる場合もあります。読み込み後はサーバー側から提供された情報をもとに、特にポート、パス、サービス名、安全性に関するパラメーターを含む設定全体を確認してください。トラブル対応のためにプロトコルをむやみに変更しないでください。クライアントとサーバーの設定が一致しないと、通常ハンドシェイクに失敗します。

比較的新しいAndroidスマートフォンなら、まずarm64版を選べます。ただし、製造年だけでは判断せず、端末が対応するアプリのアーキテクチャを確認してください。システムの端末情報やメーカーの仕様を参照できます。アーキテクチャがわからない場合は、複数のアーキテクチャに対応し、幅広い端末で使えるuniversal版を選びましょう。通常、ファイルサイズは大きくなります。インストール時に非対応と表示されたら、OSのバージョンとアプリのアーキテクチャを確認してください。署名の競合が表示された場合は、設定をバックアップして既存アプリの入手元を確認し、サブスクリプションやルーティング設定を失わないよう安易にアンインストールしないでください。

まず、入手したものがサブスクリプションURL、個別の共有リンク、完全なJSON設定のどれかを確認してください。それぞれ読み込み方法が異なります。サブスクリプションURLはサブスクリプショングループのアドレス欄に入力して保存し、更新します。共有リンクはクリップボードから読み込み、完全な設定ファイルはカスタム設定の読み込み機能を使います。コピー時に空白や改行、チャットアプリが付け加えた文字列が入っていないか確認しましょう。それでも表示されない場合は更新時のメッセージを確認します。認証エラーならサブスクリプションの有効期限を、形式エラーならログインページが返されていないかを確認してください。サブスクリプションURLを見知らぬオンライン解析サービスに送信しないでください。

必ずしも読み込めるとは限りません。完全なJSONはコア設定を記述するもので、インバウンド、ルーティング、複数のアウトバウンドを含む場合があります。一方、一般的なサブスクリプションは、クライアントが認識できるノードの一覧や、Base64でエンコードされた共有リンクのリストです。URLからJSONをダウンロードできても、現在のサブスクリプション読み込み機能が対応する形式とは限りません。提供元の説明を確認し、カスタム設定または形式に合った読み込み方法を選んでください。カスタム設定では待ち受けポートやルーティングが指定されていることもあるため、使用前にローカルポートの競合を確認し、復元できるよう元の設定を保存してください。

問題を切り分けやすくするため、まず通常のプロキシ方式でノードが使えることを確認してからTUNを設定してください。デスクトップでは仮想ネットワークインターフェースの作成やルート設定に、管理者権限などのシステム権限が必要な場合があります。クライアントの案内に従って許可し、仮想インターフェース用コンポーネントが正しくインストールされているか確認してください。AndroidではシステムのVPN接続許可が必要です。接続要求を承認し、ほかのVPNサービスとの競合がないか確認しましょう。ログに権限エラーやインターフェース作成失敗が記録されている場合は、競合するサービスを終了してから再試行してください。問題を回避するためにシステムのセキュリティ機能を恒久的に無効化しないでください。

既存のノードはそのまま残してください。サブスクリプションの更新では設定配布先にアクセスし、ノード接続ではプロキシサーバーにアクセスします。2つの経路はそれぞれ別に成功・失敗します。サブスクリプションの期限切れやURLの変更がないか確認し、クライアントの選択肢に応じて、直接更新とプロキシ経由の更新をそれぞれ試してください。プロキシ経由で更新するには、接続可能なノードが必要です。タイムアウトの場合は現在のネットワークを、認証エラーの場合はサブスクリプションの利用権限を確認してください。何度も一覧を削除すると使える設定まで失われます。先にバックアップを取り、短時間に繰り返し試すのではなく、具体的なエラーを記録しましょう。

システムプロキシは、システム設定に従うアプリにローカルのプロキシポートへリクエストを渡すよう指示します。グローバルルーティングは通常、コアに入ったトラフィックを優先的にプロキシ経由で送る設定ですが、すべてのアプリの通信がコアに入るとは限りません。TUNは仮想ネットワークインターフェースを通じて、条件に合うトラフィックを取り込みます。3つは異なる階層の機能で、組み合わせて使えますが、同じものではありません。ブラウザーは使えるのに特定のアプリが使えない場合は、まずそのアプリがシステムプロキシに対応しているか確認し、必要に応じてアプリ内のプロキシ設定やTUNを検討してください。最初からすべてのルーティング規則をグローバルプロキシに変更する必要はありません。

まずTCPingでサーバーのポートにTCP接続できるか確認し、次に実接続テストでプロキシのハンドシェイクと接続先へのアクセスを調べ、最後に実際のアプリで出口IPを確認します。TCPingに成功しても、認証、TLS、ルーティングが正しいとは限りません。実接続テストの結果も、テスト先のURLや現在のネットワークに左右されます。出口IPの確認には信頼できる確認ページを使い、リクエストが想定どおりプロキシ経由になっていることを確かめてください。単発の遅延値は通信速度を示すものではありません。ノードを選ぶときは最小値だけで並べず、継続して安定したアクセスができるかも確認しましょう。

クライアント名、OSの種類、使用中のコア、発生時刻、プロキシ方式、エラー全文を記録し、最小限の操作で再現してください。ログは問題の発生前後の範囲を優先して保存すると、名前解決の失敗、接続タイムアウト、認証エラーを区別しやすくなります。スクリーンショットや設定を共有する前に、サブスクリプションURL、ユーザー識別情報、パスワード、接続情報を復元できるQRコードを隠してください。設定の構造を見せる場合は、機密項目をサンプル値に置き換え、項目名とエラー前後の情報は残します。ログレベルの引き上げは短期間の調査に限り、終了後は元に戻してください。

まずプロキシを無効にして、ローカルネットワークから正常にアクセスできることを確認し、サーバーアドレスとポートに不足がないか調べてください。TCPingと実接続テストを別々に確認します。ポート接続もタイムアウトする場合は、ネットワーク経路、サーバーの状態、ファイアウォールを優先して調べます。ポートには接続できても実接続に失敗する場合は、プロトコル、認証、安全レイヤー、トランスポート設定を確認してください。信頼できる別のネットワークと比較する場合も、一度に変更する項目は1つにします。すべてのノードで失敗するならローカルネットワークやクライアント共通の設定を確認し、特定のノードだけ失敗するなら、そのサーバーの設定や状態に絞って調べましょう。

接続済みという表示は、コアが起動した、または仮想インターフェースが作成されたことを示すだけの場合があり、目的のサイトにアクセスできるとは限りません。まず接続先のノードが選択されていることを確認し、ローカルのインバウンドが待ち受けているか、ブラウザーが正しいプロキシポートを使っているか、ルーティングがリクエストを想定したアウトバウンドに送っているかを確認してください。ログにドメインの名前解決エラーがある場合は、DNSサーバーに到達できるか調べます。まだ確立していないプロキシにDNSリクエストが依存するループを避けてください。一部のサイトだけ使えない場合は、該当するルーティング規則と接続先サービスの状態を確認し、ノード、DNS、ルーティングを一度に変更しないでください。

まずOSのプロキシ設定を確認し、アドレスが古いポートではなく、クライアントが実際に待ち受けているローカルアドレスとポートを指しているか確認してください。ブラウザー拡張機能、アプリ内プロキシ、自動設定スクリプトがシステム設定を上書きしていないかも調べます。システムプロキシを参照しないアプリは、個別の設定が必要です。クライアントを終了しても接続できない場合は、残っているシステムプロキシ設定を解除してから、直接接続を試してください。再起動時はプロキシツールを1つだけ有効にし、設定を1つずつ戻します。リモートサーバーのアドレス欄にローカルの待ち受けアドレスを入力しないでください。用途が異なります。

証明書検証のスキップを恒久的な対策にすることはおすすめできません。まずシステムの日付、時刻、タイムゾーンを合わせ、SNIがサーバーの要件に合っているか、証明書が該当ドメインをカバーしているか、有効期限が切れていないか確認してください。サーバーアドレスとSNIは異なる場合がありますが、サーバー側の設定に従って入力し、任意に置き換えないでください。REALITYを使用している場合は、公開鍵、ショートID、フィンガープリントなどのパラメーターも確認します。最近ノード設定を変更した場合は、信頼できる提供元から情報を再度入手して読み込んでください。解決しない場合は元のエラーを保存し、設定提供元にサーバーの状態を確認しましょう。