V2Rayのよくある質問

V2Rayが属するProject Vのエコシステムには、プロキシ通信に関連するコンポーネントがあります。V2FlyとXrayは関連するコアプロジェクトで、プロトコル、接続、ルーティング、DNSなどを処理します。v2rayN、v2rayNG、v2flyNGはGUIを提供し、サーバー情報の読み込みやサブスクリプションの管理、設定変更に使います。画面が開くからといってコアが正常に動作しているとは限らず、コアが動作していてもリモートサーバーが利用できるとは限りません。問題が起きたら、画面の接続状態だけで判断せず、クライアント設定、コアの起動ログ、サーバー側のパラメーターをそれぞれ確認してください。

Windows、macOS、Linuxのデスクトップでは、まずv2rayNを確認してください。Androidでは通常、Xrayコアを使うv2rayNGが候補です。V2Flyコアが必要な場合はv2flyNGを確認しましょう。選ぶ前に、サブスクリプションで使われているプロトコルや通信方式、必要なコア機能を確認してください。画面が似ているかどうかだけで選ぶのは避けましょう。クライアントやバージョンによって、読み込み形式、ルーティングのプリセット、設定画面の場所は異なる場合があります。移行時は現在使えている設定を残し、まず1つの項目で動作を確認してください。クライアント自体がサーバーを提供するわけではないため、有効なノード情報またはサブスクリプションURLが必要です。

arm64版はARM 64ビットアプリに対応した端末向けです。universal版は通常、複数のプロセッサーアーキテクチャ向けのコンポーネントを含むため、ファイルサイズが大きくなります。比較的新しいAndroidスマートフォンでは、まずarm64に対応しているか確認するとよいでしょう。ただし、購入年だけではアーキテクチャを判断できません。プロセッサーが64ビット対応でも、OSが32ビットアプリしかサポートしない端末もあります。端末のシステム情報でアーキテクチャを確認してください。判断できない場合は汎用版を検討し、各クライアントの最新リリース情報も確認しましょう。インストールできない場合は、ネットワークの問題と決めつけず、OSのバージョン、空き容量、既存アプリとの署名の競合も確認してください。

クライアントのプロトコル名だけを変更しても切り替えはできません。VLESS、VMess、Trojanはそれぞれ異なるプロキシプロトコルで、REALITYは関連する接続のセキュリティ設定です。通常、サーバー側の通信方式やハンドシェイクのパラメーターも一致させる必要があります。サーバーアドレス、ポート、ユーザーIDまたはパスワードに加え、必要に応じてサーバー名、公開鍵、Short IDもサーバー側の設定に合わせてください。サブスクリプションに必要な情報がすべて含まれている場合は、元の値を維持しましょう。手動で変更する前に、現在の設定を保存してください。プロトコルはサーバーの対応状況と使用中のコアとの互換性を基準に選び、名前だけで速度や接続可否を判断しないでください。

まず、サブスクリプションURLと個別ノードの共有リンクを区別しましょう。前者は通常、サブスクリプショングループに追加し、後者はクリップボードや共有リンクから読み込みます。コピーしたURLの前後に空白がないか、チャットアプリによって途中で切れていないか、Webページのタイトルまで含めてコピーしていないかを確認してください。グループを保存した後、更新を実行し、フィルターが有効になっていないかも確認します。ログインページやエラーページ、クライアントが対応していない形式が返された場合、URLを開けても有効なノードは追加されません。更新時のメッセージを記録し、提供元に対応形式を確認してください。サブスクリプションURLには認証情報が含まれるため、公開しないでください。

サブスクリプションの取得と既存ノードへの接続は、別々の通信経路を使います。そのため、一方が成功しても、もう一方が正常とは限りません。まず、失敗の原因がドメイン名の解決、接続タイムアウト、証明書エラー、認証の期限切れのどれかを確認し、端末の日時とサブスクリプションの有効期限も確認してください。クライアントにプロキシ経由で更新する設定があり、既存ノードが実際に使える場合は試してみましょう。反対に、プロキシ経由で失敗する場合は、直接接続で更新先に到達できるか確認します。調査中は既存のサブスクリプショングループと使えるノードを残し、先に削除してから更新するのは避けてください。アクセス頻度の制限が表示された場合は時間を置いて再試行し、連続クリックや同じグループの重複作成は控えましょう。

TUNモードは仮想ネットワークインターフェースを作成し、関連するルートを変更するため、通常のローカルプロキシより高い権限が必要です。Windowsではクライアントの案内に従って管理者権限で実行するか、対応するサービスをインストールしてください。macOSとLinuxでは、使用中のバージョンに表示される手順に従って許可します。設定ディレクトリ全体の権限を安易に変更しないでください。AndroidではシステムのVPN接続許可を確認し、同種の接続を別のアプリが使用中でないか確認します。許可後も失敗する場合は、ログに表示されるインターフェース、ドライバー、ルートのエラーを確認してください。まず通常のプロキシに戻してノードを検証し、その後TUNを確認しましょう。調査のためにファイアウォールやほかのシステム保護機能を長期間無効にするのは避けてください。

まずクライアントのコアが起動していることを確認し、システムプロキシの接続先がクライアントの現在のローカル待ち受けアドレスとポートになっているか確認してください。HTTPとSOCKSではポートが異なる場合があります。ブラウザー独自のプロキシ拡張機能やネットワーク設定が有効だと、システム設定が上書きされることがあります。また、システムプロキシを参照しないアプリもあります。いったんプロキシの管理方法を1つに絞り、ブラウザーを再起動して確認し、システムプロキシの例外リストもチェックしてください。端末内の問題を解決するために、待ち受けアドレスをすべてのネットワークインターフェースに変更しないでください。アプリがシステムプロキシを使わない場合は、アプリ側の手動プロキシ設定を確認するか、通信の対象範囲を理解したうえでTUNを使ってください。

システムプロキシは、どのアプリのリクエストをクライアントに渡すかを決めます。ルーティングモードは、コアに入ったリクエストの送信先を決めます。TUNは通信を取り込む方法を変える設定です。この3つは異なる層の設定です。クライアントのグローバルモードは通常、取り込んだ通信にプロキシ経由の送信先を優先させる設定であり、すべてのプログラムが自動的に対象になるわけではありません。ルールベースの振り分けでは、ドメインやアドレスなどの条件に応じて、プロキシ、直接接続、ブロックを選びます。TUNで通信を取り込んだ後も、ルーティングルールが適用される場合があります。調査時はまずリクエストがコアに届いているか確認し、その後ルールの適用結果を確認してください。通信を取り込めていない問題をノードの問題と取り違えないようにしましょう。

テスト結果が示すのは、その時点で特定の方法により確認した状態に限られます。ポートテストに成功しても、リモートポートに到達できるだけで、プロトコルのハンドシェイク、ドメイン名の解決、接続先サイトへのリクエストまで成功するとは限りません。実際のリクエストを使うテストも、指定したテスト先に対する結果です。ノードを選ぶ際は、まず実際にアクセスできることを確認し、継続利用時の安定性を見て、提供元が案内する通信量の倍率や地域情報も確認してください。遅延が一度低かったからといって、スループットが高いとは限りません。比較時はテスト方法とネットワーク環境をそろえて、ノードを1つずつ切り替えましょう。DNS、ルーティング、ノードを同時に変更すると、どの設定が影響したのか判断できなくなります。

提供元ごとにグループを分け、用途がわかる名前を付けて、更新URLとフィルター条件をそれぞれ確認しましょう。自動更新を有効にする前に、新しいサブスクリプションを正常に読み込めるか確認してください。残しておきたい手動登録のノードは別の場所に保存し、更新時に上書きされないようにします。名前が同じでも同一サーバーとは限りません。比較時はアドレス、ポート、プロトコル、グループの提供元も確認してください。更新後に一覧が短くなった場合は、まずフィルター条件と提供元からの応答を確認し、すぐにグループをすべて削除しないでください。設定をエクスポートまたはバックアップするときは、サブスクリプションの認証情報やユーザーID、パスワードが含まれる可能性があるため、安全な場所に保管してください。

変更前に現在のプリセットと使えるノードを記録し、一度に1つだけ設定を変更してください。クライアントの案内に従って設定を保存し、コアを再読み込みまたは再起動します。ルーティングルールは評価順序が影響することがあるため、より広い条件のルールが先に適用され、確認したいルールを上書きしていないか確認してください。DNSはブラウザー独自の名前解決、システムキャッシュ、コアのキャッシュにも影響されます。同じ接続先で繰り返し確認し、設定画面のスイッチだけでなく、ログで実際の送信先や名前解決エラーも確認してください。確認後は一時的に変更したログレベルを元に戻しましょう。ログを共有する場合は、アドレス、認証情報、個人のアクセス履歴を削除し、問題に関係する部分だけを提出してください。

まずプロキシを無効にして、通常のネットワーク接続が使えることを確認します。次に、現在のノードのアドレス、ポート、プロトコル、サブスクリプションの状態を確認してください。1つのノードだけ失敗する場合は、同じサブスクリプションの別のノードに切り替えて比較します。すべて失敗する場合は、コアが起動しているか、端末の日時が正しいか、ローカルのファイアウォールがクライアントの通信を遮断していないかを優先して確認してください。ログの接続タイムアウトと認証失敗は原因が異なります。認証失敗の場合は、認証情報とプロトコルのパラメーターを確認しましょう。必要に応じて、利用できることがわかっている別のネットワークでも比較します。ただし、ソフトウェアの再インストールと設定の書き換えを同時に行わないでください。ノードのサービス障害やサブスクリプションの期限切れは、提供元に問い合わせる必要があります。

画面に接続済みと表示されても、コアが動作しているだけの場合があります。まずブラウザーのリクエストが実際にクライアントへ届いているか確認してください。システムプロキシのモード、ローカルの待ち受けポート、ブラウザー独自のプロキシ設定を確認し、次にログで名前解決エラー、ハンドシェイクの失敗、誤った送信先へのルーティングがないか確認します。同じWebサイトで利用できることがわかっているノードに切り替え、ノード側の問題かローカル設定の問題かを切り分けましょう。その後、DNS設定と振り分けルールを確認し、必要なら一時的にクライアントのデフォルト設定に戻して比較します。一部のWebサイトだけで問題が起きる場合は、サイト側の稼働状況やアクセス制限も考慮してください。プロキシ接続全体の失敗と決めつけないようにしましょう。

まず、失敗しているのがサーバーのドメイン名か、接続先Webサイトのドメイン名かを確認してください。前者の場合はノードに接続できず、後者の場合はノードに接続できてもWebページを開けないことがあります。設定したDNSのプロトコル、アドレス、到達経路を確認しましょう。暗号化DNSを使う場合は、そのDNSサービスのドメイン名を初回にどう解決するかも確認してください。まだ確立していないプロキシ経由ですべての名前解決を行う設定は避けましょう。依存関係が循環するおそれがあります。ブラウザー独自のDNSとシステムの名前解決では経路が異なることがあるため、それぞれ確認してください。設定は一度に1つだけ変更し、コアを再読み込みしてからテストします。パブリックDNSに変更しても、すべてのネットワーク環境で問題が解決するわけではありません。

終了後は、システムプロキシが停止済みのローカルポートを指したままになっていないか確認してください。必要に応じてシステムのネットワーク設定で自動設定に戻すか、手動プロキシを無効にし、ほかのプロキシツールの設定が残っていないかも確認します。TUNを使っていた場合は、まずクライアントから正常に停止し、その後、仮想インターフェースとルートが元に戻っているか確認してください。よくわからないシステムインターフェースを直接削除しないでください。Wi-Fiの切り替え後やスリープから復帰した後は、通常のネットワークに再接続してからコアを再起動し、ノードを確認します。問題が続く場合はエラーログを保存し、直近の変更を1つずつ元に戻してください。ほかの業務用接続に影響するおそれがあるため、ネットワーク設定全体をすぐにリセットしないでください。