V2Rayのよくある質問

まず、設定画面と接続処理を分けて考えましょう。V2Rayは通常、Project Vのエコシステムに属するプロキシツールや関連技術を指します。V2FlyとXrayはそれぞれ機能を確認する必要があるコアプロジェクトです。v2rayN、v2rayNG、v2flyNGはGUIクライアントで、サブスクリプションの管理、ノードの選択、設定の生成を担当し、実際のプロトコル処理はコアが行います。そのため、画面上でノードを登録できても、現在のコアで動作するとは限りません。トラブル対処の際は、クライアント名、コア名、ログのエラーをあわせて記録してください。特に、プロトコル、通信方式、設定項目が対応しているかを確認し、画面上のプロトコル表示だけで互換性を判断しないようにしましょう。

デスクトップでは、Windows、macOS、Linuxに対応するv2rayNが候補です。AndroidではXrayコアを使うv2rayNGをまず検討し、V2Flyコアが必要な設定にはv2flyNGを検討してください。選ぶ際は、OS、CPUアーキテクチャ、ノードが必要とするプロトコルと通信方式を基準にします。名前が似ているかどうかで選ぶものではありません。特にVLESSやREALITYを使う場合は、選んだクライアントに付属するコアが実際に対応しているか確認しましょう。クライアントを切り替える前に現在の設定を記録し、動作確認済みのノードを読み込んで比較してください。複数のクライアントを同時に起動してシステムプロキシや仮想ネットワークインターフェースを制御すると、テスト結果が混乱するため避けましょう。

必要です。クライアントは設定管理と接続のためのツールであり、インストールしただけでリモートサーバーを利用できるわけではありません。サブスクリプションURLからノード一覧を取得できます。単一ノードの共有リンクには通常、プロトコル、サーバー、ポート、認証情報が含まれます。どちらも利用権のあるサービス、または自分で構築した設定を使ってください。クライアントはサーバー側のアカウントや通信量の枠を代替するものではありません。読み込み後はノードを選択して接続を開始し、用途に応じてシステムプロキシなどの通信経路を設定します。サブスクリプション一覧が空の場合は、インストール失敗と決めつけず、内容とアカウントの状態を確認してください。サブスクリプションURLやノード設定には認証情報が含まれることがあるため、スクリーンショットやログを共有する前に必ず伏せましょう。

システムプロキシは、OSのプロキシ設定に従うアプリからのリクエストをクライアントに渡します。ルーティングは、通信がコアに入った後、ルールに基づいて直結、プロキシ経由、遮断のいずれにするかを決めます。TUNモードは仮想ネットワークインターフェースを使って、より多くの通信を取り込みます。それぞれ処理する段階が異なるため、相互に置き換えることはできません。アプリがシステムプロキシを無視している場合、リクエストがクライアントに届いていない可能性があり、ルーティングルールを変更しても解決しないことがあります。TUNは対象範囲が広い一方で、権限、DNS、ゲートウェイ、ほかのネットワークソフトとの互換性も考慮が必要です。最初はシステムプロキシで単一ノードの動作を確認し、その後、必要に応じてTUNを検討しましょう。複数の設定を同時に変更するのは避けてください。

コピーしたものがサブスクリプションURLなのか、単一ノードの共有リンクなのかをまず確認してください。v2rayNでは通常、サブスクリプショングループの設定からURLを追加し、保存後にサブスクリプションを更新します。Androidクライアントでもサブスクリプション用の画面から追加して更新してください。WebページのURLを単一ノードとして読み込ませることはできません。コピーした内容に空白や改行が入っていないか、クエリパラメーターが欠けていないか、ログインが必要なページを指していないかも確認しましょう。それでもノードが表示されない場合は更新ログを確認し、リクエスト失敗、応答内容を解析できない、フィルター適用後に空になった、のどれかを見分けます。認証情報を含むURLを公開の変換ツールに貼り付けないでください。形式を変換する必要がある場合は、提供元の信頼性と変換後の形式の互換性を確認し、元のサブスクリプションも残して比較しましょう。

比較的新しいAndroid端末ではarm64が候補になりますが、購入年ではなく、端末が対応するアプリのアーキテクチャを基準にしてください。CPUが64ビットに対応していても、OSが32ビットアプリ環境しか提供しない端末では、arm64版をインストールできない場合があります。端末情報で対応ABIを確認するか、アーキテクチャが不明ならuniversalを選びましょう。universalは通常、複数のアーキテクチャを含むため、ファイルサイズが大きくなります。インストールに失敗した場合は、既存アプリの署名、OSのバージョン、空き容量も確認し、すぐにアーキテクチャが原因だと決めつけないでください。旧クライアントをアンインストールすると設定が削除されることがあるため、先にバックアップを取り、保存先も確認しましょう。

まずOSの情報でアーキテクチャを確認し、それに合うパッケージ形式を選びましょう。Windowsではx64版の要件を満たしているか確認します。macOSでは「このMacについて」を開き、Apple SiliconかIntelかを確認してください。Linuxではx64またはarm64に加え、ディストリビューションが使うdeb、rpmなどのパッケージ形式も確認します。拡張子が同じでもアーキテクチャが同じとは限らず、パッケージを開けても実行環境の要件を満たしているとは限りません。起動できない場合は、OSのメッセージとクライアントの起動ログを確認してから、実行に必要な依存関係を調べましょう。ほかの端末のプログラムフォルダーをそのままコピーするのは避けてください。異なるプラットフォームへ移行する際は、サブスクリプションと必要な設定を優先して移し、パス、ネットワークインターフェース、権限の設定は新しい端末で確認し直しましょう。

まず通常の接続が動作することを確認してから、TUNの権限を設定しましょう。Windowsでは、クライアントの案内に従って管理者権限で実行するか、関連サービスを設定する必要があります。macOSやLinuxでも、ネットワークインターフェースの作成やルートの変更に許可が必要な場合があります。手順はクライアントのバージョンによって異なります。Androidクライアントで初めて通信を取り込む際は、OSからVPNの許可を求められるので、システムダイアログで承認してください。許可に失敗した場合は、仮想ネットワークインターフェースを使用中のほかのアプリを終了し、ログにインターフェース作成やルート設定のエラーがないか確認します。エラーを回避するために、システムの保護機能を長期間無効にしないでください。テスト後はTUNを無効にすると元のネットワークに戻ることを確認し、日常的に使うか判断しましょう。

それぞれ測定している処理が異なります。Tcpingで主に確認するのはサーバーのポートに対するTCP接続時間で、認証、プロキシ経由の通信、接続先サイトへのアクセスが成功することまでは分かりません。接続テストでは通常、プロキシ経由で指定先にリクエストするため、より多くのプロトコル処理やネットワーク経路が関わります。ダウンロード速度テストでは継続的な転送能力を測りますが、テスト用ファイル、同時接続数、サーバー側の速度制限にも左右されます。そのため、接続時の遅延が小さくてもダウンロードが速いとは限らず、接続テストの失敗もテスト先に到達できないことが原因かもしれません。ノードを比較するときは、テスト先と時間をそろえ、まず接続できることを確認してから、実際のアプリでの使い心地を基準に選びましょう。ダウンロードテストは通信量を消費するため、通信量に倍率が設定されたノードでは回数を抑えてください。

サブスクリプションごとにグループを作り、提供元や用途が分かる名前を付けましょう。まず1つのグループだけ更新し、ノード数や項目に問題がないことを確認してから、定期更新を設定します。フィルター条件は一つずつ追加し、すべてのノードが一度に非表示にならないようにしてください。更新時にノード情報が置き換わったり、サーバー側で名前、アドレス、並び順が変わったりするため、クライアントが以前の選択状態を維持できないことがあります。更新後は一覧が新しくなったかだけでなく、選択中のノード、ルーティングモード、再接続の要否も確認しましょう。手動で追加したノードは独立したグループに入れ、自動更新される内容と混在しないようにするのがおすすめです。古いグループを削除する前に必要な設定をバックアップし、バックアップ内の認証情報も安全に保管してください。

まず通信が実際にクライアントへ届いていることを確認し、変更後のルーティング設定が選択されているか確認しましょう。ルールは通常、上から順に評価されるため、範囲の広いルールが先にあると、後続の詳細なルールに一致しない場合があります。ドメインルール、IPルール、アウトバウンドのタグが正しいか、参照先のgeoリソースが存在するかを確認してください。また、ドメイン名でのリクエストと、すでにIPアドレスに解決されたリクエストを区別しましょう。保存後はクライアントの指示に従ってコアを再起動するか再接続し、既存の接続が以前の経路を使い続けないようにします。テストでは接続先を一つに絞り、ログで接続先アドレスとアウトバウンドの選択を確認してください。原因をルールの順序だけに限定せず、アプリ独自のプロキシ設定やDNSの動作も考慮しましょう。

まず、失敗しているのがドメイン名の解決なのか、プロキシ接続なのかを切り分けましょう。最初からすべてのDNS設定を置き換えるのはおすすめしません。直接接続で使うDNSとプロキシ経由で使うDNSでは到達経路が異なります。リモートDNSへのアクセスにプロキシが必要な場合は、クライアントが適切なアウトバウンドを選べることを確認してください。そうしないと、プロキシ接続の確立に、そのDNSの結果が必要になる循環状態が起こることがあります。変更前に現在の設定を記録し、一項目ずつ変更して既知のドメインでテストした後、アプリ独自の暗号化DNSが有効になっていないか確認しましょう。ブラウザー、OS、クライアントのキャッシュにより、結果がしばらく一致しない場合もあります。パブリックDNSのアドレスはDNSサービスの接続先にすぎず、すべてのネットワークから到達できる保証はありません。また、DNSを変更してもノードの認証情報やサーバーのポート設定の誤りは解決しません。

まずURLが完全か、アカウントが有効か確認し、更新ログでリクエストの結果を調べましょう。接続タイムアウトの場合は、サブスクリプションのドメイン名解決とアクセス経路を優先して確認します。HTTP 401や403の場合は、認証情報やサーバー側のポリシーを確認してください。リクエストが成功しても解析できない場合は、応答がノードのサブスクリプションではなく、ログインページやエラーページになっていないか確認します。現在のノードが使えない場合、プロキシ経由の更新も失敗することがあります。クライアントに選択肢があれば、直接更新とプロキシ経由の更新を比較してください。アクセス制限を招かないよう、更新ボタンを何度も押すのは避けましょう。必要ならサブスクリプションの提供元に連絡し、エラーの内容を伝えてください。ログを共有する際はURL内の認証情報を削除します。グループを削除して作り直すのは通常、最初に試す方法ではありません。フィルターや更新設定が失われるおそれがあります。

同じネットワークで動作確認済みのノードを試し、次に現在のノードを接続テストしましょう。1つのノードだけ失敗する場合は、サーバーアドレス、ポート、認証情報、通信設定、サーバーの状態を重点的に確認します。複数のノードが同時に失敗する場合は、端末のネットワーク、システム時刻、ファイアウォール、ほかのプロキシソフトを確認してください。ハンドシェイクに成功しても、ポートに到達できる可能性があると分かるだけで、認証やプロトコルの誤りは否定できません。コアが起動していないというログがある場合は、ノードを次々に切り替えるのではなく、ポートの競合や設定ミスを先に解決しましょう。テスト中は重複する通信制御を一時的に無効にし、一度に一項目だけ変更して結果を記録してください。1回のタイムアウトだけでサブスクリプション全体を削除したり、テストサイトにアクセスできないだけで、すべてのサイトが使えないと判断したりしないでください。

まず、クライアントが起動していることと、接続先へのリクエストが成功していることを区別しましょう。ブラウザーの通信がクライアントに届いているか、システムプロキシの状態、アプリ独自のプロキシ設定、選択中のノードを確認します。次に、ドメイン名の解決、ルーティングのアウトバウンド、ログの接続エラーを調べます。一部のWebサイトだけが開けない場合は、すぐに設定全体をリセットせず、該当するルールと接続先サービスの状態を確認してください。TUNを使用している場合は、DNSの取り込み、インターフェースのルート、ほかの仮想ネットワークソフトとの競合も調べましょう。まずTUNを終了し、システムプロキシで通常のWebページを確認すると、原因を絞り込めます。クライアントを終了してもネットワークに問題が残る場合は、システムプロキシが残っていないか、元のDNSやゲートウェイに戻っているかを確認してから、再起動してテストしてください。

OSに設定されている現在のプロキシアドレスとポートを確認し、起動中のクライアントの待ち受けポートを指しているか確認しましょう。クライアントのポートを変更した、別のソフトが設定を上書きした、プログラムが異常終了した、といった場合に、誤ったシステムプロキシが残ることがあります。正常に終了しても、閉じたローカルポートを指したままなら、クライアントまたはOSの設定でプロキシを解除し、直接接続をテストしてください。システムプロキシを参照しないアプリでは、アプリ内でプロキシを指定するか、TUNを検討する必要があります。HTTPとSOCKSのポートは任意に入れ替えられません。トラブル対処中はクライアントを一つだけ起動し、設定を互いに上書きしないようにしましょう。ローカルの待ち受けポートを安易にLANへ公開しないでください。ほかの端末から接続できるようにする場合は、認証とアクセス範囲を別途検討する必要があります。