V2Rayのよくある質問
とトラブル対処

まず利用する端末に合ったGUIクライアントを選び、その後でコアについて確認しましょう。V2Rayは一般にProject Vのプロキシエコシステムの中核プロジェクトを指します。V2Flyはそのコミュニティを引き継ぐプロジェクトで、Xrayは関連するコアプロジェクトです。v2rayNはWindows、macOS、Linux向けのデスクトップクライアントで、設定の管理、コアの起動、プロキシの設定を行います。v2rayNGはXrayコアを採用したAndroidクライアントです。クライアントの画面とコアは別の層にあり、画面が起動していてもコアが動作中とは限りません。トラブル対処では、設定のインポート、コアの起動、アプリの通信がプロキシに届いているかをそれぞれ確認してください。

必要です。利用権限のあるサーバー設定またはサブスクリプションURLを用意し、クライアントにインポートしてください。クライアントは設定管理と通信の転送を行うもので、接続先のリモートサービスは付属しません。サブスクリプションは通常、複数のサーバー設定を1つのURLにまとめたもので、更新するとクライアントに各設定が追加されます。共有リンク1件には通常、1つの設定が記載されています。サービス提供元のログインページURLをサブスクリプションと間違えないようにしてください。また、サブスクリプションを公開掲示板に投稿しないでください。アクセス情報が含まれることがあるため、スクリーンショット、ログ、問い合わせ資料を共有する際は、URL、ユーザー識別情報、認証情報を必ず隠してください。

まず通信がどのようにクライアントへ入るかを区別し、その後、どの経路で外部へ送られるかを確認しましょう。システムプロキシはプロキシアドレスをシステムに登録するため、その設定に従うアプリでのみ有効です。グローバルルーティングは通常、コアに入った通信をプロキシ経由で外部へ送る設定であり、端末上のすべてのプログラムを制御するという意味ではありません。TUNは仮想ネットワークインターフェースを通じて、対象範囲内の通信を受け取ります。システムプロキシを参照しないアプリに適していますが、権限、ルーティング、DNSの設定が関係します。初めて設定する場合は、まずシステムプロキシで接続を確認し、必要に応じてTUNを試してください。入口とルーティングルールを同時に変更するのは避けましょう。

まず実際に利用するWebサイトやアプリで再現し、その後、別のサーバーと比較しましょう。遅延テストが示すのは、特定の測定方法と接続先における応答時間です。継続的な通信速度を示すものではなく、すべてのWebサイトで利用できるかどうかも判断できません。ページの表示速度には、DNS、通信中のパケットロス、リモート側の出口、接続先サービス、ローカルネットワークも影響します。比較するときはネットワーク、ルーティングモード、テスト先をそろえ、サーバーは一度に1つだけ変更してください。小さなページは表示できるのに大きなファイルのダウンロードが遅い場合は、帯域幅とパケットロスを確認します。特定のWebサイトだけに問題がある場合は、そのドメインの振り分け結果と接続先サービスの状態を確認してください。

端末のプロセッサと、OSが対応するアプリのアーキテクチャを確認しましょう。比較的新しいAndroid端末の多くではarm64を選べます。インストールパッケージのサイズも通常は小さくなります。アーキテクチャがわからない場合は、複数のアーキテクチャ向けのファイルを含むuniversalを選べますが、その分サイズは大きくなります。プロセッサが64ビットに対応していても、OSで64ビットアプリをインストールできるとは限りません。特に古い端末では事前に確認してください。非対応のインストールパッケージと表示された場合は、まずアーキテクチャ、OSのバージョン、空き容量を確認し、その後で別のパッケージを検討します。既存クライアントを更新するときは、パッケージ名と署名が一致するかも確認してください。アンインストールして再インストールする場合は、エクスポート可能な設定を先にバックアップしましょう。

Windowsでは、まずダウンロードページに記載されたシステム要件を確認し、デスクトップ版を選ぶ方法があります。クロスプラットフォームのUIを採用しており、共通の操作環境から始めたい場合に適しています。従来のUIに慣れている場合はWPF版を選び、必要なランタイムがインストール済みか確認してください。メニューの位置や設定名はバージョンによって異なることがあります。古い解説記事の画面だけで、機能がなくなったと判断しないでください。アップグレードや版の切り替え前にはクライアントを終了し、設定をバックアップしたうえで別のフォルダーにインストールして試しましょう。複数のプロセスがローカルポートを取り合うのを防げます。macOSとLinuxでは、それぞれのプラットフォームに対応するデスクトップ版を選んでください。

まず、サブスクリプションURLを最後まで正しくコピーできているか確認し、先頭と末尾の空白や改行を削除します。リンクの期限切れ、リセット、再認証の要否も確認してください。次に、クライアントがそのサブスクリプション形式に対応しているかを確認します。ログインページやエラーページ、別のクライアント専用の設定ファイルが取得されている場合、サーバー情報を解析できないことがあります。更新に既存のプロキシ接続が必要な場合は、利用可能な設定を選んでから、プロキシ経由で更新するオプションを試してください。問題を切り分ける際は元のグループを残し、新しいテスト用グループにインポートして、有効な設定を上書きしないようにします。ログではエラーの種類を確認するだけにとどめ、共有前にサブスクリプションURL全体を必ず隠してください。

まずTUNを無効にし、通常のシステムプロキシで接続できることを確認してから、権限を個別に確認してください。Windowsではクライアントの案内に従って必要なサービスをインストールまたは起動し、必要に応じて管理者権限を使用します。macOSとLinuxでは、該当するバージョンの説明に従ってシステムの許可や特権サービスを設定してください。他のプラットフォーム向けのコマンドをそのまま使わないでください。AndroidクライアントではシステムのVPN権限を使用するため、初回接続時に表示される許可ダイアログを確認します。既存のVPNや他の仮想ネットワークツールと競合する場合があるため、いったん終了してから再度試してください。権限を設定したらTUNを有効にし直し、スイッチの状態だけでなく、ログでインターフェースとルートが作成されたことも確認しましょう。

利用可能なサーバーを選び、システムプロキシの自動設定を有効にします。次に、システム設定に表示されたプロキシのアドレスとポートが、クライアントの待ち受け設定と一致するか確認してください。システムプロキシを使うブラウザーでテストページを開き、クライアントのログや接続履歴に対応するリクエストが記録されるかを確認します。より明確に検証するには、コマンドラインツールでローカルプロキシポートを明示して使用し、プロキシを使わない場合と比較します。この2つのテストでは通信の入口が異なります。ブラウザー拡張機能、ブラウザー独自のプロキシ設定、キャッシュも判定に影響することがあります。出口IPアドレスの変化だけではなく、リクエスト履歴とルーティング結果も確認してください。

まずは標準のルーティング振り分けを使い、普段使うWebサイト、LAN内の端末、業務アプリに問題なくアクセスできる状態を基準にしましょう。振り分けでは、ドメイン、アドレス、ルールの順序に基づいて直結かプロキシかを選べるため、日常的な併用に適しています。グローバルルーティングは、振り分けルールが原因かどうかを一時的に確認する場合に便利です。グローバルでは正常で振り分けでは問題が起きる場合、グローバル設定で長期的に回避せず、対象ドメインに適用されるルール、DNSの結果、ルールデータが利用可能かを確認してください。テスト後は元の設定に戻し、LAN内の通信が誤ってリモート側に送られていないかも確認しましょう。プリンター、ファイル共有、社内ネットワークに影響することがあります。

サブスクリプションごとにグループを分け、見分けやすい名前を付けましょう。同じサブスクリプションを複数の場所に重複してインポートしないでください。更新前に現在使用中の項目と重要な設定を記録し、更新後に選択中の項目が引き続き有効か確認します。サーバー側で設定が削除、改名、変更されることがあります。手動で追加した設定はできるだけ別のグループに保存し、サブスクリプションの更新で置き換わらないようにしましょう。無効なグループは定期的に整理しますが、すべての設定を頻繁にリセットするのは避けてください。自動更新を使う場合は、現在のネットワークから更新先にアクセスできることを確認します。問題が発生したら、再インポートする前に更新時刻とログを確認してください。

まず現在の設定をバックアップし、使用中のコアと、動作確認済みの設定を1つ記録します。次に、切り替え先のコアがその設定のプロトコル、通信方式、セキュリティパラメーターに対応しているか確認してください。クライアントに切り替え機能があっても、すべての設定をそのまま使えるとは限りません。特に拡張フィールド、DNS設定、TUNの実装の違いに注意しましょう。切り替え後は、まずシンプルなルーティングとサーバー1台で確認し、接続できてからカスタムルールを戻します。未知のフィールドや起動失敗が発生した場合は元のコアに戻し、ログを比較してください。設定項目を次々と削除して試すのは避けましょう。クライアントとコアの更新も分けて確認すると、変更の原因を特定しやすくなります。

端末、サブスクリプション、サーバー、システムの4段階で確認します。まず端末の時刻が正確でネットワークが利用できること、コア起動後にローカルポートが実際に待ち受けていることを確認してください。次にサブスクリプションを更新し、古いアドレス、期限切れの認証情報、インポート漏れを除外します。その後、サーバーアドレス、ポート、通信方式、セキュリティパラメーターを確認し、同じネットワークで動作確認済みの別設定と比較します。最後にファイアウォール、他のプロキシツール、仮想ネットワークとの競合を確認してください。一度のタイムアウトだけでリモートサーバーの停止とは判断できません。再テストでは接続先と条件をそろえましょう。何度も再インストールするより、最初にエラーが発生した時刻とログの種類を記録するほうが原因の特定に役立ちます。

まずコアのログを確認し、ローカルプロキシやVPNインターフェースが有効になっているだけでなく、リモート接続が実際に成功しているかを確認します。次に、ブラウザーのリクエストがクライアントに届いているかを調べます。リクエストが記録されない場合は、システムプロキシ、ブラウザー独自の設定、ローカルポートを確認してください。リクエストがあるのに失敗する場合は、ルーティング、DNS、サーバーの状態を確認します。ドメイン名でのアクセスだけが失敗する場合は、名前解決エラーを優先して確認しましょう。LAN内とすべてのWebサイトで同時に問題が起きる場合は、TUNを無効にして再テストし、ルーティングの競合を確認してください。プロキシの入口と実行中のクライアントを1つずつに絞り、他のツールの影響を除外します。DNS、ポート、ルーティングモードを同時に変更しないでください。

以前の設定は残し、リストを消去しないでください。既存のサーバーに接続できても、サブスクリプションURLが有効とは限りません。サブスクリプションがリセットまたは期限切れになっていないか、リクエスト制限に達していないかを確認し、端末の時刻と証明書エラーも確認してください。直接接続で更新できない場合は、利用可能なサーバーを選んでから、プロキシ経由の更新を試します。プロキシ経由で失敗する場合も直接接続と比較し、更新リクエストが特定の接続に依存していないか確認しましょう。サーバーからログインページが返される場合や形式が変わった場合は、対応するURLを再取得してください。短時間に何度も更新しないでください。ステータスコードとエラーの概要を記録し、サブスクリプションの提供元に問い合わせる際は認証情報を隠してください。

ポートが使用中の場合、まずクライアントが2つ起動していないか確認し、次にOSのネットワークツールで該当ポートを使用しているプロセスを調べます。用途を確認して競合するプログラムを終了するか、設定で空いているポートに変更してください。手動で設定したブラウザーや他のアプリのプロキシも、同じポートに合わせて変更します。出所のわからないシステムプロセスを終了しないでください。クライアントを終了した後も直接接続できない場合は、システムのプロキシ設定を開き、残っている手動プロキシや自動設定URLを無効にします。その後、TUNや他のVPNが動作中でないか確認してください。ネットワークが復旧したらクライアントを1つだけ起動して検証します。次回からは、終了前にシステムプロキシを解除して、通常の手順で終了してください。