V2Rayのよくある質問
サブスクリプション・プロキシ・接続トラブル

Project Vは関連するプロキシツールのエコシステムの背景にあたり、V2FlyとXrayは共通の歴史を持つコアプロジェクトです。コアはプロトコル処理、ルーティング、接続を担い、クライアントはサブスクリプション管理、画面表示、システム連携を担当します。v2rayNはデスクトップ向けで、利用できるコア機能は選択したコアとバージョンによって異なります。v2rayNGはXrayコア、v2flyNGはV2Flyコアを採用しています。トラブル対処ではクライアントとコアの両方の情報を記録してください。クライアント名だけでは、設定が利用できるか判断できません。

クライアントはプロキシ接続を設定・実行するためのツールです。インストールしただけで、利用可能なサーバーが自動で用意されるわけではありません。利用権限のあるサブスクリプションURLや共有リンク、またはサーバーの設定情報一式が必要です。手動設定では、少なくともアドレス、ポート、プロトコル、認証情報を確認します。TLSやREALITYを使う場合は、対応するセキュリティ設定も確認してください。サブスクリプションURLには通常、アクセス用の認証情報が含まれます。機密情報として管理し、スクリーンショット、ログ、問い合わせ内容ではURL全体、ユーザー識別情報、認証情報を隠してください。

VMess、VLESS、Trojanはクライアントで選択できるプロキシプロトコルです。REALITYはVLESSなどと組み合わせる通信のセキュリティ方式で、前述のプロトコルと同じ階層の選択肢ではありません。設定はサーバー側と一致させる必要があります。名前を変えるためにプロトコルの選択だけを変更しても接続できません。まずサーバー側で提供されている設定情報を確認し、次に現在のコアが対応しているかを確認しましょう。VLESSの暗号化項目だけで通信経路全体の安全性が決まるわけではありません。TLSやREALITYなどの設定も合わせて確認してください。

サブスクリプションURLを使うと、配信元から複数のサーバー設定を取得でき、配信内容に応じて更新できます。共有リンクは通常、個別のサーバー情報を記述したもので、追加しても自動更新されるわけではありません。設定ファイルにはアウトバウンド、DNS、ルーティングなど、より多くの情報が含まれる場合があります。すべての内容を読み込めるかは、クライアントが対応するファイル形式によります。URLをブラウザーで開けても、互換性のあるサブスクリプションが返されるとは限りません。Webページ、ログイン画面、エラーメッセージはサーバー一覧として読み込めません。

システムプロキシは、システム設定に従うアプリにプロキシ接続を提供しますが、すべてのプログラムの通信を経由させるわけではありません。TUNは仮想ネットワークインターフェースで通信を受け取り、通常はルーティングやDNSの設定、高い権限が必要です。AndroidクライアントのVPNモードは、システムの仮想ネットワークインターフェースを使って、選択したアプリの通信を受け取ります。VPNアイコンが表示されても、インターフェースが作成されたことを示すだけです。いずれの方式でも、すべての通信が必ずプロキシを経由するとは限りません。最終的な通信先は、ルール、除外リスト、アプリごとの設定にも左右されます。

まず追加方法を確認しましょう。個別の共有リンクはクリップボードまたは共有リンク用のメニューから追加し、サブスクリプションURLはサブスクリプショングループに登録してから更新します。コピー時に空白、改行、説明文が混ざっていないか、管理画面のWebページをサブスクリプションとして扱っていないかも確認してください。次に、エラーが接続失敗、認証失敗、内容の解析失敗のどれかを確認します。それぞれネットワーク、認証、形式の問題に対応します。サブスクリプションの解析エラーを直すためにサーバーのプロトコルを何度も変更するのは避けてください。処理段階が異なる問題です。

プロセッサーの製品名ではなく、端末が対応するアプリのABIを基準に選びましょう。比較的新しい一般的な端末なら、通常はarm64を選べます。アーキテクチャが分からない場合は、複数のアーキテクチャを含むuniversalを選べますが、ストレージを多く使用します。64ビット対応チップを搭載していても、システムが32ビットアプリしか許可しない端末もあります。インストールできない場合は、OSのバージョン、空き容量、既存アプリとインストールパッケージの署名が一致しているかも確認してください。設定を失わないよう、すぐに既存アプリをアンインストールするのは避けましょう。

デスクトップ版はクロスプラットフォームのインターフェースを採用し、従来のWPF版はWindowsでなじみのある従来型の画面を採用しています。ダウンロードページの案内でOSとアーキテクチャを確認してから、使いやすい画面を選びましょう。インターフェースの違いを、プロトコル性能の直接的な違いと混同しないでください。メニューの場所、バックアップ内容、設定フォルダーは版によって異なる場合があります。移行前に設定をエクスポートし、独自のルーティング、DNS、ローカル待ち受けポートを記録してください。起動できない場合は、使用するインストールパッケージの案内に従って実行環境を確認し、異なるインストール先のファイルを混在させないようにしましょう。

まずクライアントのコアが実行中であること、ローカルの待ち受けアドレスとポートがシステムプロキシの設定と一致していることを確認します。そのうえで、対象のプログラムがシステムプロキシに従うか確認してください。一部のコマンドラインツールやダウンロードツール、独自のネットワーク設定を持つアプリでは、個別の設定が必要です。ブラウザー拡張機能がシステム設定を上書きすることもあります。まず、システムプロキシに従うことが分かっているアプリでテストし、次に対象ドメインがルーティング設定で直接接続になっていないか確認しましょう。より多くの通信を経由させる必要がある場合はTUNを検討してください。複数のプロキシ入口を重ねてループが発生しないよう注意しましょう。

まずログを確認し、仮想インターフェースの作成、権限の要求、ルーティング設定のどの段階で失敗したかを特定します。Windowsではクライアントの案内に従って必要な権限を付与してください。macOSやLinuxでは、それぞれのOS向けの手順で認証します。他のOSのドライバー操作をそのまま適用しないでください。仮想ネットワークインターフェースを使用しているツールやデフォルトルートを変更するツールを一時的に終了して、再度テストします。権限の問題を解決するために、ファイアウォールを恒久的に無効にするのは避けてください。ブラウザーだけをプロキシ経由にしたい場合は、まずシステムプロキシでサーバーが使えるか確認できます。

更新は通常、該当するサブスクリプショングループに適用されますが、置き換え、保持、重複排除の動作はクライアントや設定によって異なります。手動設定は別のグループに保存し、サブスクリプションから生成された項目を直接編集して次回も保持されると想定しないでください。更新前に重要な設定をバックアップし、更新後は選択中のグループ、フィルター、既定のサーバーに変更がないか確認します。一覧から項目が一時的に見えない場合、グループやフィルター条件が変わっただけの可能性もあります。すぐにすべての設定を消して再インポートせず、まずフィルターを解除して確認しましょう。

普段はルールモードを使うと、宛先ごとに直接接続、プロキシ経由、アウトバウンドの遮断を設定できます。グローバルプロキシは、問題が振り分けルールに起因するかを調べる短時間の比較テストに使えます。ただし、クライアントを経由しないアプリの通信まで切り替わるとは限りません。グローバルプロキシでは接続でき、ルールモードでは失敗する場合は、サーバーを変える前にルールの順序、ドメインの一致、最終的なアウトバウンドを確認してください。テスト後は元のモードに戻し、LAN上のサービスやローカル端末へ想定どおりアクセスできることも確認しましょう。

まず、一覧の設定が「選択したアプリのみプロキシを使う」のか、「選択したアプリを除外する」のかを確認してください。2つの動作は逆です。変更後は、クライアントの案内に従って接続を再確立し、新しい対象範囲を反映させます。アプリが別のコンポーネント、仕事用プロファイル内の複製、システムサービスを通じて通信する場合があります。メインのアプリだけを選択しても、関連するプロセスをすべてカバーできるとは限りません。まず対象を1つのアプリに絞って振り分けを確認し、その後で対象を広げましょう。原因を特定しにくくなるため、アプリごとの対象範囲、DNS、サーバーを同時に何度も変更しないでください。

Muxは、少数の下位接続で複数の論理接続を運ぶ仕組みです。効果はプロトコル、トランスポート、サーバー、利用状況によって変わり、常に速度が上がる設定ではありません。組み合わせによっては非対応、または推奨されない場合があります。特にVLESSのフロー制御などとの組み合わせは、使用中のコアの説明に従って設定してください。動作が不安定な場合は、まずMuxを無効にして基準となる状態を確認し、同じ操作で有効時と比較しましょう。モバイル端末の電池持ちは、電波状況、通信の継続、バックグラウンドでの起動にも左右されるため、スイッチの状態だけでは判断できません。

同じ配信元が管理するサーバーは、両方の端末でサブスクリプションURLから追加し、それぞれの端末で更新する方法がおすすめです。手動設定を1件だけ移す場合は、共有リンクやQRコードを使えますが、プロトコルとトランスポートの各項目が維持されているか確認してください。クライアントのバックアップファイルは、異なる端末間で互換性があるとは限りません。デスクトップのルーティング、DNS、待ち受けポートと、Androidのアプリごとの設定も自動では対応しません。移行時は、まず1台のサーバーで動作を確認してから、ローカル設定を1つずつ再構築します。サブスクリプションやバックアップは安全な方法で受け渡し、認証情報を含むファイルを公開場所にアップロードしないでください。

まず端末の通常のネットワーク接続を確認し、次にサーバーのアドレス、ポート、認証情報、端末の時刻を確認します。TCPの接続テストと、実際のプロキシ経由のリクエストを区別してください。ポートに接続できても、プロトコルのハンドシェイクや宛先へのアクセスが成功するとは限りません。また、個別のテストがタイムアウトしても、すべてのアプリが利用できないとは限りません。ログに名前解決エラー、接続拒否、ハンドシェイク失敗がないか確認し、対応する設定と照らし合わせます。既知の正常な設定と比較する場合は、他の設定を変えず、ネットワークと複数のセキュリティ項目を同時に切り替えないようにしましょう。

接続済みと表示されても、コアや仮想ネットワークインターフェースが起動しただけで、リモート接続が成功していない場合があります。まず、実際のWebリクエストがログに記録されているか確認してください。記録がなければ、アプリのプロキシ設定、VPNの権限、アプリごとの対象範囲を確認します。記録があり失敗している場合は、アウトバウンドの選択、DNS、ハンドシェイク情報を確認しましょう。次に複数の宛先を試し、特定サイトの問題か全般的な問題かを切り分けます。ブラウザーだけで問題が起きる場合は、拡張機能、独自のセキュアDNS、キャッシュも確認してください。最初からクライアントのデータをすべて消去するのは避けましょう。

サブスクリプションの取得とサーバーへの接続は別の経路です。既存の設定で接続できても、サブスクリプションの配信元にアクセスできるとは限りません。サブスクリプションの有効期限や認証情報に変更がないか、ログにHTTPステータスエラー、証明書エラー、解析失敗がないか確認してください。更新経路に直接接続とプロキシの選択肢がある場合は、実際のネットワーク環境に合わせて比較できます。ただし、利用できないサーバー経由で更新する設定に依存しないようにしましょう。既存のグループをすぐに削除せず、使える設定とバックアップを残し、配信元から互換性のある内容が返ることを確認してから更新してください。

まず、名前解決の前後どちらで失敗しているかログで確認します。名前解決の失敗、空の応答、DNSリゾルバーへの接続不可がある場合は、DNS経路を調べます。アドレスを取得した後に接続拒否やハンドシェイクエラーが起きる場合は、リモート接続を確認してください。ローカルDNSとリモートDNSのリクエスト先、クライアントがシステムの名前解決を引き受けているかをそれぞれ確認します。ブラウザーのセキュアDNSが独自にリクエストを送る場合もあるため、確認対象に含めましょう。IPアドレスへの直接アクセスだけで判断しないでください。HTTPSでは正しいドメイン名と証明書が必要な場合があります。

まず、システムのプロキシ設定がクライアントのローカルポートを指したままになっていないか確認します。プロセスが終了してもプロキシ設定が残っていると、アプリは存在しない接続先へ通信し続けます。クライアントのシステムプロキシ解除機能を使うか、システムのネットワーク設定で元の設定に戻してください。TUNを使っていた場合は、仮想インターフェース、デフォルトルート、DNSも正しく復元されているか確認し、必要に応じてOSの方法でネットワークに再接続します。操作前に、元の企業プロキシや独自のDNS設定を記録しておき、必要なネットワーク設定まで削除しないようにしましょう。