V2Rayのよくある質問

V2Rayは一般に、Project Vエコシステムのプロキシ技術や関連プロジェクトを指します。コアはプロトコル処理、通信接続、ルーティングを担い、GUIクライアントはサブスクリプション管理、設定編集、起動を行います。v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けのクライアントです。画面が開いても、確認できるのはクライアントが起動したことだけで、コアが正常に動作しているとは限りません。接続状態を判断する際は、現在の設定、コアのログ、実際のアクセス結果をあわせて確認しましょう。サイト名、クライアント名、コア名を同じ設定項目として扱わないでください。

クライアントは設定や接続のためのツールであり、利用可能なリモートサーバーを自動生成するものではありません。サブスクリプションURLから複数のサーバー設定を取得でき、共有リンクは通常、1つの設定に対応します。インストール後、自分で管理している、または使用を許可された有効な設定を追加し、サーバーを選んで接続を開始してください。サブスクリプションURLには認証情報が含まれる場合があります。パスワードと同様に扱い、公開コメントやスクリーンショット、オンライン変換ツールに貼り付けないでください。有効な設定がない場合、システムプロキシの切り替えやクライアントの再インストールを繰り返しても、通常は接続問題を解決できません。

Windows、macOS、Linuxのデスクトップでは、まずv2rayNを検討してください。インストーラーはOSとプロセッサのアーキテクチャに合ったものを選びます。Androidでは通常、Xrayコアを採用したv2rayNGが候補です。既存の設定がV2Flyとの互換性を明確に必要とする場合は、v2flyNGも検討しましょう。選ぶ際は画面の見た目ではなく、設定で必要なプロトコルや通信方式、コアの対応状況を確認します。クライアントを切り替える前に、既存のグループとルーティング設定を保存してください。新しいクライアントで実際のアクセスを確認してから古い設定を削除すると、複数のプロキシ入口を同時に有効にして原因究明が難しくなるのを防げます。

システムプロキシは、設定に従うアプリの接続を指定したローカルの入口に渡します。ルーティングは、接続がコアに届いた後、プロキシ経由にするか、直接接続するか、遮断するかを決めます。TUNは仮想ネットワークインターフェースで通信を受け取ります。対象範囲はクライアントの実装やルーティング設定によって異なり、追加の権限が必要なこともあります。この3つは同じスイッチではありません。ブラウザーは使えるのに他のアプリが接続できない場合は、まずそのアプリがシステムプロキシを参照するか確認し、必要に応じてTUNを検討してください。通信を取り込めているか確認せず、ルーティングを全般モードに切り替えるのは避けましょう。

近年の一般的なAndroidスマートフォンはarm64を採用しているため、まずarm64版を検討できます。旧型や特殊な端末、アーキテクチャが分からない場合は、複数のアーキテクチャ用コンポーネントを含むuniversal版も選択肢です。プロセッサが64ビットに対応していても、端末のOSが64ビットとは限らないため、システム情報も確認してください。インストールできない場合は、上書きを繰り返すのではなく、OSの要件とアーキテクチャを確認しましょう。universal版はダウンロード容量やストレージ使用量が大きくなる傾向がありますが、接続が速くなるわけではなく、OSのバージョン要件も回避できません。

まず、説明ページや単一の共有リンクではなく、余分な空白のないサブスクリプションURL全体をコピーしているか確認します。サブスクリプションのグループ設定でグループを追加し、URLを入力して保存した後、そのグループを更新してください。解析エラーが表示される場合は、返された内容がログインページやエラーページではないか、または現在のクライアントが対応していない形式ではないか確認します。単一の共有リンクは、対応するインポート機能から追加してください。確認中にURL全体を公開しないでください。エラーの種類、クライアント名、失敗した手順を記録すると、URLの取得失敗と設定形式の非互換を切り分けやすくなります。

サブスクリプショングループを保存しても、通常はURLが保存されるだけで、設定を取得したことにはなりません。まずグループのメニューから更新し、現在の一覧が別のグループで絞り込まれていないか確認してください。更新後も空の場合は、ログに解析エラーがないか、サブスクリプション元から空の内容が返されていないかを確認します。サブスクリプション形式がクライアントに対応しているかも確認し、単一の設定をサブスクリプションURLとして使わないようにしてください。既存のグループをすぐに削除せず、古い設定を残したまま更新結果を記録し、URLの有効性と返却形式を確認すると、誤削除による設定の消失を防げます。

デスクトップでは、まずログに具体的な権限エラーや仮想ネットワークアダプターのエラーがないか確認し、クライアントの案内に従って関連サービス、ドライバー、ネットワーク拡張機能を許可します。Windowsでは管理者権限が必要な場合があります。macOSではシステムの許可ダイアログを確認し、Linuxではクライアントが必要とする権限設定を確認してください。デスクトップ環境全体を常に最高権限で実行するのは避けましょう。Androidで初めて通信を取り込む際は、システムのVPN接続を許可し、他のVPNが使用中でないか確認します。権限を設定したら関連機能を再起動してください。それでも失敗する場合は、一時的にシステムプロキシを使い、設定自体が有効か確認できます。

まず、対象の通信をどの出口経由にするか決めます。全般モードでは通常、クライアントが受け取った通信を優先的にプロキシ経由にします。「中国本土を除外」するモードでは、ドメインやIPのルールに基づき、中国本土向けと判定された接続を直接接続します。直接接続はプロキシサーバーを経由しません。具体的な動作はクライアントのプリセットやカスタムルールによって異なります。普段は用途に合ったルーティングプリセットから始め、特定のアプリで問題が起きた場合は適用されたルールを確認しましょう。全般モードでも、システムプロキシを無視するアプリの通信を強制的に取り込めるとは限りません。ルーティングを切り替えた後は、新しい接続でテストし、既存の接続が判断に影響しないようにしてください。

現在のネットワークからサブスクリプション元へ安定してアクセスできる経路を選びます。プロキシは使えるのにサブスクリプション元へ直接接続できない場合は、クライアントに「プロキシ経由で更新」するオプションがあれば試してください。現在のプロキシ自体が使えない場合、それに依存して更新し続けると問題が循環することがあります。直接接続を試すか、利用可能なネットワークに切り替えましょう。メニュー名はバージョンによって異なるため、サブスクリプションの取得経路を確認することが重要です。更新後はグループやサーバー情報が想定どおり変わったか確認し、ボタンを押せたことだけで成功と判断しないでください。同じサブスクリプション元へのリクエストを短時間に繰り返すのも避けましょう。

サブスクリプショングループに加えて、カスタムルーティング、DNS設定、ローカルの待ち受けポート、システムプロキシの方式、必要なアプリ別の振り分け設定も記録しておきましょう。サブスクリプションが管理するのは通常サーバー設定で、クライアントのすべての設定が同期されるとは限りません。移行時はクライアントのエクスポートまたはバックアップ機能を優先して使い、移行先のバージョンがその形式を読み込めるか確認してください。バックアップにはサーバーの認証情報やサブスクリプションURLが含まれる場合があるため、安全な場所に保管します。新しい端末では、まず1つの設定と基本的なアクセスを確認し、その後で詳細設定を順番に戻すと、すべてを一度にコピーするより互換性の問題を特定しやすくなります。

クライアント上の名称を変更するだけでは切り替えられません。VMess、VLESS、Trojanにはそれぞれ異なるプロトコル要件があり、クライアントのパラメーターをサーバーと一致させる必要があります。REALITYは通信のセキュリティに関わる仕組みで、前述の3つと同じ階層のサーバー種別ではありません。共有リンクやサブスクリプションを使う場合は、元のパラメーターを保持し、選択したコアがその組み合わせに対応しているか確認してください。接続に失敗しても、プロトコル、通信方式、セキュリティの設定を手当たり次第に変更せず、サーバー設定に基づいて一つずつ確認しましょう。サーバー側もあわせて変更し、対応するパラメーターが提供されて初めて、クライアント側のプロトコル切り替えに意味があります。

テストのタイムアウトは、制限時間内にテストが完了しなかったことを示すだけです。原因として、ローカルネットワーク、サーバーのポート、テスト対象、プロトコルのネゴシエーション、設定パラメーターの問題が考えられます。まず通常のネットワーク接続を確認し、次にシステム時刻、選択中のサーバー、ログに最初に記録された関連エラーを確認してください。特定のテスト対象だけが失敗しても、すべてのアクセスが失敗すると決めつけず、実際に利用したいサービスで再テストします。元の設定を残したまま、別の利用可能なネットワーク、または動作が確認済みの別の設定で試してください。一度に変更する条件は1つにし、複数の項目を同時に変えて比較できなくなるのを避けましょう。

接続済みという表示は、ローカルのコアやVPNインターフェースが起動したことを示すだけで、リモートへのアクセス成功を保証するものではありません。まずサーバーが選択されていることと、ログに継続的なエラーがないことを確認し、次にブラウザーが正しいシステムプロキシやローカルポートを使っているか調べます。すべてのドメインに接続できない場合はDNSの名前解決とプロキシの入口を確認し、一部のサイトだけ失敗する場合は適用されたルーティングルールと接続先サービスの状態を確認します。他のプロキシ、VPN、ネットワーク設定を変更する拡張機能を一時的に無効にして比較してください。設定を変更するたびに新しい接続で確認し、システムプロキシや複数の通信制御ツールを同時に有効にして解決しようとしないでください。

まずクライアントでコアが起動していることを確認し、システムプロキシの設定で「自動設定」を選びます。「システムプロキシを解除」や「変更しない」になっていないか確認してください。次に、OSの設定に表示されたプロキシのアドレスとポートが、現在のローカル待ち受け先と一致しているか確認します。OS側の設定が正しいのに特定のアプリが接続できない場合は、アプリ独自のプロキシ設定があるか、システムプロキシを無視していないか、ブラウザー拡張機能に上書きされていないか調べましょう。他のプロキシソフトを終了した際にシステム設定が書き換えられていないかも確認します。単一の端末内のアプリの問題を解決するために、ローカルの待ち受け範囲を広げないでください。異なる種類のアプリの通信を取り込む必要がある場合は、TUNと権限の要件を別途検討しましょう。

まずエラーが接続タイムアウト、証明書エラー、アクセス拒否、解析エラーのどれに該当するか記録し、サブスクリプションURLの期限切れや変更がないか確認します。タイムアウトの場合は直接接続とプロキシ経由を比較します。証明書エラーの場合は端末の時刻とネットワークの認証ページを確認し、証明書の検証を安易に無効にしないでください。アクセス拒否は、サブスクリプションの認証情報の失効やリクエスト制限が原因の可能性があります。内容を取得できても解析できない場合は、形式とクライアントの互換性を確認します。調査中は既存の設定を残し、利用可能なサーバーを失わないようグループを削除しないでください。調査情報を共有するときはURL内の認証情報を隠し、必要なエラーの概要だけを伝えましょう。