V2Ray よくある質問

V2RayはProject Vエコシステムのプロキシソフトウェアです。V2Flyは関連コアの開発を引き継ぎ、Xrayは同じ系統から派生して独自に機能や設定を発展させています。v2rayNはサブスクリプション、ノード、プロキシモードを管理するデスクトップ向けGUIクライアントで、実際の接続処理は選択したコアが担います。そのため、クライアントにプロトコルの項目が表示されても、現在のコアがその設定に対応しているとは限りません。トラブル対処ではクライアントのバージョン、コア名、起動ログをあわせて確認しましょう。REALITYやVisionの設定では、選択中のコアが対応しているか特に注意してください。

Windows、macOS、Linuxのデスクトップでは、各プラットフォームに対応したv2rayNのインストーラーを選びます。Androidでは、Xrayコアを使用するv2rayNGが第一候補です。V2Flyの設定が必要な場合は、v2flyNGも検討できます。選ぶ際は名前の似ているかどうかではなく、OS、プロセッサアーキテクチャ、ノードで必要な機能を基準にしてください。クライアントによってメニューの場所、ルーティング設定、サブスクリプションの解析方法は異なるため、移行時には設定を確認し直しましょう。まず1つのクライアントで読み込みと接続を検証してから他の端末へ移行すると、複数の要因を同時に調べずに済みます。

VMess、VLESS、Trojanはプロキシプロトコルの種類で、Shadowsocksも同じ階層に属します。一方、REALITYはセキュアな通信に関する設定で、VLESSと組み合わせて使われることが多く、自由に置き換えられるプロトコル名ではありません。VLESS自体には通信内容を暗号化する機能がないため、通信の保護には別途設定が必要です。クライアントにはTCP、WebSocket、TLS、flowなどの項目もありますが、それぞれ接続の異なる階層を表します。読み込みや手入力の際は、サーバー側で指定されたパラメーター一式を項目ごとに照合してください。プロトコルのプルダウンだけを変更したり、名前が似ているから互換性があると判断したりしないでください。

サブスクリプションURLは通常、複数のノードを取得するためのアドレスです。更新時にはクライアントがURLへ再アクセスして内容を取得します。共有リンクはvmess://やvless://など、通常は1つのノードを表します。ネイティブJSON設定には、inbound、outbound、ルーティング、DNSなどの設定一式を含められます。これらを同じ入力欄に貼り付けることはできません。ノード一覧を定期的に更新する場合はサブスクリプショングループ、単一のノードリンクの場合はクリップボードからの読み込み、設定一式の場合はクライアントの設定インポート機能を使いましょう。サブスクリプションURLにアクセス用の認証情報が含まれることがあります。スクリーンショットやログを共有したり、サポートを求めたりする際は、URL全体を隠してください。

比較的新しいAndroidスマートフォンの多くはarm64版を選べます。通常、ファイルサイズも小さめです。universal版は複数のプロセッサアーキテクチャに対応しており、アーキテクチャが不明な場合や古い端末との互換性が必要な場合に適しています。購入年はあくまで目安です。64ビット対応チップを搭載していても、32ビットOSが動作している端末があります。OSが対応するアプリのABIを確認してください。arm64版が非対応と表示された場合は、システム要件を確認してからuniversal版を試しましょう。アップデート時はアプリの署名元をそろえてください。インストールに失敗する原因はアーキテクチャだけとは限らず、署名の競合、OSのバージョン、ストレージ不足なども考えられます。

まず、サービスの案内ページやQRコード画像のURL、単一の共有リンクではなく、サブスクリプションURL全体をコピーしているか確認します。貼り付ける際は前後の空白を取り除き、メッセージアプリでURLの一部が切れていないかも確認してください。次に、URLが有効か、アカウントに利用権限があるか、返された内容がクライアント対応の形式かを調べます。ブラウザーでURLを開けても、ノード一覧が返されているとは限りません。ログインページ、エラーページ、リダイレクト先が表示されることもあります。提供元が案内するクライアント用の読み込み手順を優先し、プロトコルの種類を何度も変更しないでください。共有リンクの場合は、クリップボードから読み込む機能を使います。

システムプロキシが適用されるのは、システムのプロキシ設定に従うアプリだけです。すべての通信が自動的にクライアントへ送られるわけではありません。まずノードを選択しているか、コアが正常に動作しているかを確認し、クライアントのローカル待ち受けポートとシステムプロキシに登録されたポートが一致しているか調べます。ブラウザー拡張機能、企業ポリシー、ブラウザー独自のプロキシ設定がシステム設定より優先される場合があります。設定を変更した後は、ブラウザーを完全に終了してから再起動してください。特定のアプリだけで機能しない場合は、そのアプリのプロキシ設定を確認します。すべてのアプリで機能しない場合は、ローカルポートが他のアプリに使用されていないか、セキュリティソフトにブロックされていないか確認しましょう。より多くのアプリの通信をクライアントへ送る必要がある場合は、複数のプロキシツールを同時に有効にするのではなく、TUNを検討してください。

TUNモードでは仮想ネットワークインターフェースを作成し、ルーティングやDNSを変更することがあるため、通常のシステムプロキシより高い権限が必要です。Windowsではクライアントの案内に従って管理者権限で起動し、仮想ネットワークアダプターのコンポーネントが正常に読み込まれているか確認します。macOSとLinuxでは使用中のバージョンの説明に従って権限を設定し、別のOS向けの手順を流用しないでください。再試行する前に、他のVPNや同種のTUNプログラムを終了します。それでも失敗する場合は、ログに記録された権限やデバイスのエラーを確認し、システムポリシーでインターフェースの作成が許可されているか調べましょう。警告を消すためにファイアウォールを常時無効にしないでください。通常のブラウザー利用であれば、いったんシステムプロキシに戻して動作を確認できます。

この3つは同じ階層の機能ではありません。システムプロキシとTUNは、通信をクライアントに取り込む方法を決めます。ルールルーティングとグローバルルーティングは、取り込んだ通信にどのアウトバウンドを使うかを決めます。プロキシに対応するブラウザーだけを使う場合は、まずシステムプロキシを有効にしてルールルーティングを利用できます。システムプロキシに従わないアプリの通信も処理する必要がある場合は、TUNを検討してください。グローバルルーティングでは、取り込まれた通信を通常すべてプロキシ経由にできますが、クライアントに取り込まれていないアプリの通信まで自動的に処理できるわけではありません。設定を変更するときは、一度に1つの階層だけを変更し、元の設定を残してアクセス結果を確認してから次の項目に進みましょう。通信の取り込み方の問題をノード障害と誤認しにくくなります。

まずノード一覧で使用するノードを1つ明確に選択し、コアを起動して必要なプロキシモードを設定します。一覧のテスト結果は目安です。テスト方法によってTCP接続、ハンドシェイク、指定URLへの応答など測定対象が異なり、実際のWebページのダウンロード速度を示すとは限りません。確認時は、プロキシ経由になるはずのページにアクセスするとともに、接続が確立したか、どのアウトバウンドが使われたかをログで確認します。次に、直接接続されるはずのページへアクセスし、ルーティングが設定どおりか確かめましょう。モードやルールを変えずにノードだけ切り替えると、結果を比較しやすくなります。テストに一度失敗しただけでサブスクリプション全体を削除する必要はありません。

AndroidのVpnServiceは、端末内の通信を取り込むためのインターフェースを作成します。初回起動時にはシステムの許可が必要です。画面消灯後に切断される場合は、アプリがバッテリー最適化、バックグラウンド実行、自動起動の制限を受けていないか確認し、端末の設定で必要なバックグラウンド動作を許可してください。アプリ別プロキシの対象アプリ指定モードでは選択したアプリのみが通信を取り込まれ、除外モードでは選択したアプリが対象外になります。設定前に現在のモードを確認し、変更後は接続を再起動してください。動作確認中のブラウザーを誤って除外リストに入れないよう注意しましょう。バックグラウンドでの切断とノードのタイムアウトは別の問題です。サブスクリプションをすぐに変更するのではなく、切断時刻とログから原因を判断してください。

異なる提供元のサブスクリプションは別々のグループに分け、更新に失敗したグループを特定しやすい名前を付けます。自動更新の間隔は提供元の制限やノードの更新頻度に合わせましょう。数分おきに設定する必要はありません。頻繁な更新はリクエスト制限にかかる原因となり、モバイル端末のバックグラウンド動作も増えます。初回読み込み後に手動更新が成功することを確認してから、自動更新を有効にしてください。一時的なネットワーク障害で更新に失敗しても、既存のノードがすべて使えなくなったとは限りません。重複ノードを整理したりサブスクリプションURLを変更したりする前に、現在使用中のノードと必要な設定を記録し、更新後に接続を復旧できる設定が失われないようにしましょう。

サブスクリプションの更新リクエストとノードへの接続は、別々の経路を使います。既存ノードが使えても、サブスクリプションURLにアクセスできるとは限りません。まず、エラーがURLの無効、リクエストのタイムアウト、証明書エラー、内容の解析失敗のどれに当たるかを確認し、現在のプロキシ経由で更新する必要があるか調べます。関連メニューの名称はバージョンによって異なる場合があるため、更新リクエストが実際にどの経路を通るか確認してください。証明書エラーが出た場合は、システムの日付、時刻、タイムゾーンを確認し、証明書の検証を無効にしないでください。ログインページやエラーメッセージが返される場合は、提供元にURLの状態を問い合わせましょう。連続して失敗する場合は短時間に何度も再試行せず、使えるノードを残したうえでサブスクリプションの問題に対処してください。

まず端末の通常のネットワーク接続を確認し、次にコアが正常に起動しているか調べます。ローカルの待ち受けポートの競合や設定の解析エラーがあれば、先に解消してください。コアが動作している場合は、ノードのアドレス、ポート、プロトコル、通信方式、安全設定が提供元の情報と一致しているか確認します。プロキシモードとルーティングを変えずに、動作が確認済みの別ノードと比較します。1つのノードだけが失敗する場合は、そのノードの設定またはサーバーの状態に問題がある可能性が高くなります。すべてのノードが失敗する場合は、システム時刻、DNS、ネットワーク環境、セキュリティソフトのログも確認してください。テストのタイムアウトだけでは原因を特定できません。実際のアクセスと接続ログをあわせて判断しましょう。

接続済みという表示は、通常、ローカルサービスや仮想インターフェースが起動したことを示すだけで、リモート側とのハンドシェイクや目的のサイトへのアクセスが成功したとは限りません。まず通常アクセスできるページを開いて、基本的なネットワーク接続を確認します。次に、ブラウザーの通信がクライアントに取り込まれているか確認してください。ログに新しい接続がない場合は、システムプロキシ、アプリ別設定、TUNによる通信の取り込みを優先して調べます。接続ログにハンドシェイクエラーがある場合は、SNI、証明書、プロトコルのパラメーターを確認します。ドメイン名の解決エラーが出る場合は、DNSの経路を確認してください。最後に、ルーティングによって通信が誤ったアウトバウンドに送られていないか調べます。一度に1項目だけ変更して再テストし、ノード、DNS、ルールを同時に変更して原因が分からなくなるのを避けましょう。

まず、すべてのアクセスで異常が起きているのか、一部のドメインだけ失敗するのかを確認します。TUN使用時はDNSリクエストも取り込まれることがあります。また、リモートDNSへのアクセスがプロキシ経由でないとできない場合、起動時に相互依存が発生していないか確認し、選択中のコアが現在のDNS設定に対応しているか調べてください。復旧時はクライアント上でTUNとシステムプロキシを正常に無効化してから、プログラムを終了します。その後、システムにローカルプロキシや無効なDNS設定が残っていないか確認してください。必要であればネットワークアダプターを元の自動取得設定に戻し、ネットワークへ再接続します。元の設定を記録してから、すべての設定を公共DNSのアドレスに置き換えるようなことは避けてください。