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

V2RayはProject Vのプロキシエコシステムに属し、V2Flyが関連するコアをメンテナンスしています。Xrayは別の開発系統です。コアは接続、プロトコル処理、ルーティングを担当し、v2rayNはサブスクリプション、ノード、各種設定を管理するGUIを提供します。トラブル時は、画面上の操作に失敗しているのか、コアの起動に失敗しているのかを切り分けましょう。前者は読み込んだ内容や画面の案内を、後者はクライアントのログを確認します。設定が使えるかどうかは、使用中のコアとバージョンの対応状況によって異なります。クライアント名だけで判断せず、別のコアの設定ファイルをそのまま上書きするのも避けてください。

Windows、macOS、Linuxのデスクトップではv2rayN、AndroidではXrayコアを使用するv2rayNGが第一候補です。V2Flyコアが必要な場合はv2flyNGを検討してください。3つのクライアントではメニューやコアの機能、設定形式が異なり、チュートリアルに記載された設定名もバージョンによって変わることがあります。まずOSとプロセッサのアーキテクチャを確認し、サブスクリプションのプロトコルが対応しているかを調べましょう。クライアントを変更する場合は、元のサブスクリプションを再読み込みするのがおすすめです。プログラムのフォルダー全体をそのまま移さないでください。独自のルーティング設定がある場合は、ルールとローカルポートも別途記録しておきましょう。

クライアントは設定管理と接続のためのツールであり、接続先のサーバーを自動で提供するものではありません。サブスクリプションURLからノード一覧を取得し、個別のノードリンクには接続に必要なアドレス、ポート、プロトコル、認証情報が記載されています。利用権のあるサービス、または自分で構築したサーバーから設定を取得し、クライアントに読み込んでください。サブスクリプションURLにはアカウントを特定できる情報が含まれていることが多く、URLを知る人が設定を取得できる可能性があります。公開コメントやスクリーンショット、オンライン変換サイトに貼り付けないでください。サブスクリプションが無効になった場合は、クライアントを何度も再インストールするのではなく、まずサービスの案内とアカウント状況を確認しましょう。

システムプロキシは、システム設定に従うアプリの通信をローカルプロキシに送ります。ルーティングは、コアに入った通信をプロキシ経由、直接接続、ブロックのどれにするかを決めます。TUNは仮想ネットワークインターフェースを使い、条件に合った通信を取り込みます。それぞれ役割が異なるため、システムプロキシを有効にしてもすべてのアプリがプロキシを使うとは限りません。TUNを有効にしても、すべての通信がリモートノードを経由するわけではありません。ブラウザーの通信だけを処理するなら、まずシステムプロキシを使いましょう。プロキシ設定を参照しないアプリの通信も取り込む必要がある場合は、TUNを検討し、権限、DNS、ルーティングも確認してください。

近年の一般的なAndroidスマートフォンでは、まずarm64パッケージを選べます。ただし、最終的には端末が対応するアプリのアーキテクチャを確認してください。プロセッサが64ビットに対応していても、OSで64ビットアプリをインストールできるとは限りません。universalパッケージは複数のアーキテクチャに対応する分、ファイルサイズが大きくなる傾向があり、対応アーキテクチャがわからない場合に向いています。「アプリをインストールできません」と表示されたら、アーキテクチャだけでなく、OS要件、空き容量、既存アプリとの署名の一致も確認しましょう。試しに既存のクライアントをアンインストールするのは避けてください。必要な設定をエクスポートし、サブスクリプション情報を安全に保管して、グループやルールの消失を防ぎましょう。

コピーしたものがサブスクリプションURL、個別のノードリンク、アカウント管理ページのどれかを確認してください。サブスクリプションURLはサブスクリプショングループのURL欄に入力し、保存後に更新します。個別リンクはクリップボードからの読み込みなど、対応するメニューを使ってください。コピー時に前後の空白や改行、チャットアプリが付けた句読点を取り除き、URLが途中で切れていないか確認しましょう。更新後も空のままなら、ログに形式非対応、認証失敗、Webページの内容が返されたなどのメッセージがないか確認してください。個人用のサブスクリプションを公開ツールで変換するのは避け、設定の提供元にクライアント対応形式を確認してから、再度読み込んでください。

TUNは仮想ネットワークインターフェースの作成とルーティングの変更を行うため、通常は追加のシステム権限が必要です。Windowsではv2rayNを完全に終了し、使用中のバージョンの案内に従って管理者として起動してからTUNを有効にしてください。macOSとLinuxでは、クライアントの案内に従ってサービスのインストールや権限の許可を行います。それでも失敗する場合は、ログでネットワークインターフェースの作成、ドライバーの読み込み、権限拒否に関する情報を確認し、ほかの仮想ネットワークインターフェースやプロキシツールとの競合を調べましょう。エラーを消すためにセキュリティソフトを長期間無効にしたり、出所のわからない権限昇格コマンドを実行したりしないでください。対処後は、まず1つの通信取り込み方式だけで動作を確認しましょう。

macOSでは「このMacについて」でチップを確認します。Apple Siliconはarm64、Intelはx64を選び、対応するアーキテクチャのインストールパッケージを使いましょう。Linuxではアーキテクチャとパッケージ管理方式の両方を合わせます。Debian系やUbuntu系では通常deb、FedoraなどRPMを使うディストリビューションでは通常rpmを選びます。ARM64端末の場合はarm64パッケージも選択してください。同じパッケージ形式でも、すべてのディストリビューションで実行に必要な依存関係が満たされるとは限りません。インストール前にパッケージマネージャーの案内を確認し、依存関係が不足している場合は、ディストリビューションに合った方法で補いましょう。依存関係を無視して強制インストールするのは避けてください。

接続先ごとにサブスクリプショングループを分け、どのサービスのものか見分けられる名前を付けてから、対象のグループを更新しましょう。更新後は、現在選択中のノードが残っているか確認してください。サブスクリプションによってはノード名や地域、項目の順序が変わるため、以前の選択が適切とは限りません。まずノードを1つ手動で選んで接続を確認してから、自動選択やほかのルールに戻します。使い慣れた接続先を一覧の位置だけで覚えたり、自作ノードを更新で上書きされるサブスクリプショングループに混在させたりしないでください。独自の項目を残したい場合は、手動管理用のグループを別に作りましょう。

まず、変更する設定がシステムプロキシの方式なのか、コアのルーティングルールなのかを確認しましょう。中国本土を迂回する設定では、通常、ドメインやアドレスなどのルールに基づいて一部の通信を直接接続します。グローバルプロキシ系のルールは、コアに入ったより多くのリクエストをプロキシ経由にしますが、すべてのアプリの通信を取り込むものではありません。変更後は、以前失敗した接続先をもう一度試し、アクセスログで対応する送信先を確認してください。特定のドメインだけルーティングが想定と違う場合は、そのドメインと関連ドメインのルール適用順を確認します。常にグローバル設定にする必要はありません。独自ルールを変更する前にバックアップし、既存の直接接続の要件を上書きしないようにしましょう。

レイテンシテストでわかるのは、特定の方法による応答時間やハンドシェイクの状態であり、持続的なスループットを直接示すものではありません。実際の速度は、接続先サーバー、ノードの出口、混雑状況、サービス側の速度制限、ローカルの無線ネットワークなどにも左右されます。同じ時間帯に同じダウンロード先を使い、直接接続とプロキシ経由をそれぞれ試したうえで、同じサブスクリプションから候補ノードを少数選んで比較しましょう。テスト中はバックグラウンド同期を止め、通信量の上限や倍率制限がないか確認してください。すべてのノードを一度に大量に測定するのは避けましょう。帯域を消費するうえ、サーバー側の制限が発動して比較しにくくなる場合があります。

まず、サブスクリプショングループ、手動ノード、独自のルーティング、DNS、ローカルの待ち受けポート、通信の取り込み方式を記録します。そのうえで、使用中のクライアントが対応するエクスポート機能やバックアップ機能で設定を保存しましょう。バックアップファイルには認証情報や個人用サブスクリプションURLが含まれる場合があるため、信頼できる場所に保管してください。ログを共有するときも、これらの情報を隠しましょう。アップデート後はノードを1つと、よく使うルールを1つ確認してから、複雑な設定を戻します。OSやクライアントをまたいで移行する場合は、元のサブスクリプションを読み込み直し、必要なルールを手動で再設定するのがおすすめです。設定フォルダーの構成やコアの形式は異なることがあり、フォルダー全体を上書きすると古い設定との競合を招く可能性があります。

まず、サブスクリプションURLが完全で、アカウントが有効か、サービスから障害のお知らせが出ていないか確認してから、更新ログの具体的なエラーを確認します。認証失敗やアクセス拒否の場合は、設定の提供元にURLがリセットされていないか問い合わせてください。タイムアウトやドメイン名の解決失敗の場合は、ローカルネットワークとDNSを確認します。クライアントにプロキシ経由とプロキシを使わない更新方法がある場合は、現在のネットワークに合わせて選びましょう。前者では使用するノードが実際に接続できることを確認し、使えないノードが更新を妨げないようにしてください。短時間に何度も再試行せず、エラー内容と発生時刻を記録してから対処しましょう。問い合わせの際も、サブスクリプションURL全体を公開しないでください。

まず、ローカルネットワークから通常のWebサイトにアクセスできることを確認し、次にクライアントのコアが正常に起動しているか調べます。設定が正しいとわかっているノードを1つだけテストし、アドレス、ポート、通信方式、安全設定が提供元の指定と一致しているか確認してください。同じグループのノードがすべてタイムアウトする場合は、利用が許可された別のネットワークでも再テストします。1つのノードだけ失敗する場合は、その回線の状態を優先して確認しましょう。ログにTLSハンドシェイクや証明書の問題が示されている場合は、ポートの接続不良と決めつけず、システム時刻とサーバー名を確認してください。テストのタイムアウトは、その時点の確認に失敗したことを示すだけです。実際のリクエストログも合わせて判断しましょう。

接続済み、またはコアが動作中という表示は、起動処理の一部が完了したことを示すだけで、Webページへのリクエスト成功を保証するものではありません。まず、ブラウザーのリクエストがクライアントのアクセスログに記録されているか確認しましょう。記録がない場合はシステムプロキシ、ローカルの待ち受けポート、アプリ独自のプロキシ設定を優先して確認します。記録があるのに失敗する場合は、選択中のノード、ルーティングの送信先、DNSを調べてください。ほかのプロキシツールを一時的に無効にして再テストし、ドメイン名の解決エラーと接続エラーをそれぞれ比較しましょう。変更は一度に1項目だけにし、元の値を記録しておきます。1つのWebサイトだけ開けない場合は、そのサイトの状態、ブラウザー拡張機能、関連ドメインも確認してください。

まず、システムのネットワーク設定にあるプロキシのアドレスとポートが、クライアントの現在の待ち受け設定と一致しているか確認します。次に、そのアプリからのリクエストがクライアントのログに記録されるか調べましょう。システムプロキシを参照しないアプリや、ブラウザーの設定・拡張機能によってプロキシ設定が上書きされるケースがあります。まずはシステムプロキシに従うブラウザーで確認し、必要に応じてアプリを完全に終了してから再起動してください。ほかのプロキシやVPNツールがある場合は、設定が繰り返し書き換えられないよう、その通信取り込み機能を一時的に停止します。システムプロキシに対応しないアプリの通信を取り込む必要がある場合は、チュートリアルを参考にTUNを検討し、ルーティングとDNSも確認してください。ローカル接続の問題を解決するために、待ち受けアドレスを公開アドレスに変更しないでください。