V2Rayのよくある質問

Windows、macOS、Linuxのデスクトップではv2rayNを使用し、サブスクリプションのグループ管理、システムプロキシ、ルーティングなどを設定します。AndroidではXrayコアを採用するv2rayNGが第一候補です。既存の設定がV2Flyに明確に依存している場合は、v2flyNGを検討してください。名前が似ていても、インストーラーや設定が完全に共通とは限らず、デスクトップ用をスマートフォンにインストールすることはできません。OSに合ったクライアントを選び、ノードのプロトコルや伝送方式、コアの対応状況を確認しましょう。画面が似ているという理由だけで設定全体を流用しないでください。

V2Rayは通常、Project Vのエコシステムに属するプロキシツールや関連設定を指します。V2Flyはそのコア開発を引き継ぎ、Xrayは別系統のコアです。GUIクライアントはサブスクリプションの保存、ノードの選択、実行設定の生成を担い、実際の接続はコアが処理します。そのため、画面上で共有リンクを読み込めても、現在のコアがすべてのパラメーターに対応しているとは限りません。REALITYや特定のフロー制御で起動できない場合は、ノード名が一覧に表示されているかだけでなく、クライアントの解析結果とコアのログも確認してください。

クライアントは設定や接続に使うツールであり、それ自体が利用可能なリモートサービスというわけではありません。接続にはサーバーアドレス、ポート、認証情報、プロトコル、伝送パラメーターが必要で、通常はサブスクリプションURLや個別の共有リンクから読み込みます。サブスクリプションURLは設定を取得するための入口であり、サーバーアドレス欄に入力するものではありません。読み込み前に提供元と利用権限を確認し、読み込み後はグループを更新してノードを選択してください。サブスクリプションにはアクセス認証情報が含まれる場合があります。URL全体、共有リンク、QRコードを公開の場に投稿しないでください。

Macでは、Appleメニューから「このMacについて」を開きます。Appleシリコンと表示される場合は対応するarm64版を、Intelプロセッサと表示される場合はx64版を選んでください。Androidのarm64とuniversalは別のインストーラー選択肢です。Macのダウンロード項目と混同しないでください。2015年以降の一般的なAndroidスマートフォンでは、まずarm64を検討できますが、最終的には端末のOSが対応するアプリのアーキテクチャによります。古い端末や、インストール時にアーキテクチャ非対応と表示される場合は、ユニバーサル版を試してください。ユニバーサル版は複数のアーキテクチャ向けコンポーネントを含むため、通常はサイズが大きく、接続が速くなるわけではありません。

まず、受け取ったものがサブスクリプションURL、個別の共有リンク、ネイティブJSONのどれかを確認します。サブスクリプションURLはグループ設定に入力してから更新します。個別の共有リンクは、クリップボードから読み込むなど、対応する機能を使ってください。ネイティブJSONはクライアントが対応するカスタム設定方法で扱います。コピー時は前後の空白や改行、チャットアプリが付けた説明文を取り除いてください。ログに形式を認識できないと表示された場合は、URLがログインページやエラーページではなく設定データを返しているか確認し、提供元にクライアント対応形式を問い合わせます。ウェブページのURLをノードとして繰り返し読み込まないでください。

現在使えるグループは残し、更新時に表示されたエラーを記録してください。サブスクリプションの有効期限、URLの変更、現在のネットワークから配信サービスにアクセスできるかを確認します。更新にプロキシが必要な場合は、まず使えるノードを選び、クライアントにプロキシ経由で更新する設定があるか確認してください。使用中のプロキシ自体が使えない場合は、配信サービスにアクセスできるネットワークから再試行します。ブラウザーでURLを開けても、正しい形式のデータが返っているとは限りません。アカウントのログインページやアクセス制限も確認してください。最初からすべてのノードを削除すると、使える接続や問題を切り分けるための手がかりを失います。

まずv2rayNのコアが正常に起動していることを確認し、システムプロキシのメニューで「システムプロキシを自動設定」を選びます。次に、システム設定のネットワークプロキシ画面で、現在使用中のWi-Fiまたは有線ネットワークにクライアントのローカル待ち受けアドレスとポートが設定されているか確認してください。macOSのバージョンによって画面名や場所は異なります。その後、テストするアプリを終了して再起動します。システムプロキシが適用されるのは、その設定に従うアプリだけです。アプリ独自のプロキシ設定、環境変数、別のプロキシツールが優先されることもあります。コマンドラインの特定のプログラムがプロキシを使わないという理由だけで、システム設定全体が無効だと判断しないでください。

TUNは仮想ネットワークインターフェースを作成し、関連するネットワーク設定を変更するため、通常は追加の許可が必要です。まず他のVPNや同様にネットワークを制御するツールを終了し、使用中のクライアントのバージョンに表示される手順に従って許可してください。Windowsでは管理者権限が必要な場合があります。macOSとLinuxでは、クライアントの権限補助機能によって手順が異なります。他のOS向けのコマンドをそのまま使ったり、原因不明のエラーを隠すために何度も高い権限で起動したりしないでください。まず通常のシステムプロキシでノードに接続できることを確認し、その後TUNだけを有効にします。失敗が続く場合は、最初のエラーとインターフェース作成に関するログを保存し、権限とルーティングの競合を一つずつ確認してください。

この2つは異なる段階で機能します。「システムプロキシを自動設定」は、システムプロキシに従うアプリのリクエストをローカルクライアントに渡すかどうかを決めます。「中国本土を迂回」は、トラフィックがコアに入った後、直接接続するかプロキシ経由にするかを決めるルーティングのプリセットです。両方を同時に有効にすることも、クライアントに入ったトラフィックをグローバルプロキシのルールで処理することもできます。アプリからクライアントにリクエストが届いていない場合、ルーティングのプリセットだけを切り替えても通常は変化しません。まずトラフィックの入口を確認し、その後ルールの一致状況と最終的な出力先を調べてください。システムプロキシのメニューをルーティングモードの切り替えとして扱わないようにしましょう。

結果を比較する前に、テスト方法を確認してください。TCP接続テストで分かるのは主にポートに接続できるかどうかです。アプリケーション層の遅延テストでは、ハンドシェイクやテスト先の応答も関係します。どちらもダウンロード速度と同じではありません。同じネットワーク、テスト先、時間帯にそろえ、まず普段使うウェブサイトが開けることを確認してから、継続的な通信が安定しているか調べましょう。多数のノードを同時にテストし、1回の結果だけで順位を決めるのは避けてください。ネットワークの混雑やサーバー側のレート制限が結果に影響することがあります。遅延の小さいノードでも目的のサイトにアクセスできない場合は、速度テストを繰り返すのではなく、DNS、ルーティング、リモート側の出口を確認してください。

まず現在のDNS設定を記録し、システムDNS、ブラウザーの暗号化DNS、コアのDNSのどれがリクエストに関わっているかを切り分けます。一部のドメインだけにアクセスできない場合は、ログの名前解決エラー、DNSリクエストの経路、ルーティングのループを確認してください。すべてのリゾルバーとルーティングルールを一度に変更しないでください。TUNを使用している場合は、DNSの制御範囲と、リゾルバーのアドレスに想定どおり直接またはプロキシ経由でアクセスできるかを特に確認します。同じドメインでテストし、必要に応じて関連するキャッシュを消去してください。リモートサーバーに接続できない、または証明書のパラメーターが誤っている場合、DNSを適当に変更しても解決しません。

サブスクリプションのグループ情報、カスタムルーティング、DNS設定、手動管理しているノードのパラメーターをバックアップし、バックアップに含まれる認証情報が公開されないよう確認してください。コアを切り替える前に、移行先のコアが現在のプロトコル、伝送方式、REALITYのパラメーター、フロー制御に対応しているか確認します。プロトコル名が同じというだけで完全互換と判断しないでください。一度に変更するのは一項目だけにします。まずノードを切り替えて接続を確認し、その後にコアやルーティングを調整してください。サブスクリプションの更新で、サブスクリプションから作成したノードが上書きされることがあります。長期間手動で変更する場合は、独立した設定として別に保存してください。複数の端末で使う場合も、設定一式をそのままコピーするのではなく、各クライアントの対応状況を個別に確認しましょう。

まずプロキシを無効にして、本来直接アクセスできるウェブサイトに接続できるか確認し、その後クライアントのログを調べます。接続タイムアウト、接続拒否、ドメイン名の解決失敗、認証失敗はそれぞれ異なる問題で、すべてをタイムアウトとして扱うべきではありません。サーバーアドレスとポートが誤って変更されていないか、端末の日時が正確か確認してから、同じノードを使って別のネットワークで試します。1つのノードだけ失敗する場合は、そのノードのサービスと設定を優先して確認してください。すべてのノードで失敗する場合は、まずローカルのファイアウォール、ネットワーク制限、コアが起動しているかを確認します。切り分け中に複数のパラメーターを頻繁に変更すると、どの操作が結果に影響したか分からなくなります。

「接続済み」という表示は、ローカルサービスが起動したことだけを示し、すべてのリモートリクエストが成功したことを意味しない場合があります。まず、ブラウザーからリクエストを送ったときに、クライアントのログに対応する記録があるか確認してください。記録がなければ、システムプロキシ、ブラウザー独自のプロキシ、ローカルポートを確認します。記録はあるものの失敗している場合は、DNS、ハンドシェイク、ルーティングの出力先に関するエラーを調べます。すべてのサイトにアクセスできないのか、一部のドメインだけなのかも切り分けてください。システムプロキシとTUNを同時に有効にしている場合は、一方を無効にして最小限の設定で再テストします。DNS、ノード、ルーティングを同時に変更せず、リクエストがクライアントに届いているかを手がかりに順番に調べると効率的です。

まずインストーラーのアーキテクチャとOSの要件を確認し、エラー全文を保存してください。Windowsでは、必要な.NETデスクトップランタイムの不足とアプリの設定異常を区別します。ランタイムの追加インストールが必要かどうかは、配布パッケージによって異なります。Linuxではパッケージ形式と不足している依存関係を確認してください。Macでは、未確認の開発元に関する警告、ファイルアクセス権の問題、アプリ自体のクラッシュを区別します。入手元を確認したうえで、システム設定の「プライバシーとセキュリティ」に表示される案内に従ってください。開けない原因をすべて同じ権限問題と決めつけたり、システム保護機能を一括で無効にしたりしないでください。更新後に問題が発生した場合は、まず設定をバックアップし、起動ログから原因を調べます。

終了後にネットにつながらない場合、システムが停止済みのローカルプロキシポートを参照したままになっていないか確認してください。クライアントを再度起動し、「システムプロキシを解除」を選んでから終了します。別のネットワークツールが設定を書き換えていないかも確認してください。TUNを使用していた場合は、仮想インターフェースとルーティングが元に戻っているか確認します。特定のアプリだけプロキシを使わない場合は、そのアプリ独自のネットワーク設定を調べてください。コマンドラインツールがプロキシ環境変数を読み込んでいる可能性もあります。ローカルアプリの問題を解決するために、待ち受けをすべてのネットワークインターフェースに公開しないでください。さらにサポートを求める場合は、OS、クライアント、通信の制御方式、エラーの概要を伝えます。ログに含まれるサブスクリプションの認証情報や個人情報は、事前に伏せてください。