よくある質問：V2Ray

V2RayはProject Vのプロキシツール群に属し、V2FlyとXrayは関連するコアの系統です。コアはプロトコル処理や接続の確立、ルーティングを担い、GUIクライアントは設定の編集、サブスクリプションの管理、コアの起動を行います。v2rayNはデスクトップ向け、v2rayNGはXrayコアを使用し、v2flyNGはV2Flyコアを使用します。クライアントをダウンロードしても、利用可能なサーバー設定が自動で手に入るわけではありません。利用開始前に、使用権限のあるサブスクリプションまたはノード情報を用意してください。

Windows、macOS、Linuxでは、まずOSに合ったv2rayNを選びます。Androidではv2rayNGが候補です。V2Flyコアとの互換性が必要な場合はv2flyNGを検討してください。Windowsのダウンロード欄にはDesktopとWPFの2種類があり、前者はクロスプラットフォームUI、後者は従来型のWPF UIを採用しています。クライアントを選ぶ際は、OS、プロセッサのアーキテクチャ、プロトコルの対応状況を確認しましょう。同じリンクを読み込めるからといって、すべての接続パラメータに互換性があるとは限りません。

サブスクリプションURLは通常、複数のサーバー設定を取得するためのアドレスです。クライアントで更新すると、そのアドレスに再度アクセスします。一方、個別ノードの共有リンクはプロトコル名で始まることが多く、1つの接続設定を記述します。それぞれ対応する方法で読み込んでください。URLが長いという理由だけで、サブスクリプションと判断することはできません。サブスクリプションURLにはアカウント情報や認証情報が含まれる場合があるため、機密情報として扱いましょう。問い合わせの際はエラーの種類を伝え、URL全体やQRコード、認証情報が写ったスクリーンショットは公開しないでください。

システムプロキシは、OSの設定に従うアプリのリクエストをローカルのプロキシポートへ送ります。ルーティング設定は、コアに届いたリクエストを直接接続、プロキシ、ブロックのどれに振り分けるかを決めます。TUNモードは仮想ネットワークインターフェースで通信を受け取りますが、対象範囲は実装や権限、ルート設定によって異なります。それぞれ処理する段階が異なり、同じ機能を切り替えるスイッチではありません。初めて設定する場合は、まずTUNを無効にしてシステムプロキシで基本の接続を確認し、アプリがシステムプロキシに従うかどうかを見てからTUNを使うか判断してください。

まず、サブスクリプションURLを最後まで正しくコピーできているか確認し、前後の空白や改行、チャットアプリが付けた句読点を取り除きます。v2rayNではサブスクリプショングループにURLを保存してから、そのグループの更新を実行します。Androidクライアントではサブスクリプション設定に保存して更新してください。URLを保存しただけでは、ノードの取得は完了していません。ノードが表示されない場合は更新ログを確認し、通信エラー、取得内容の解析失敗、有効なノードがない状態を切り分けます。WebサイトのログインURLやプランの説明ページ、期限切れのサブスクリプションは、ノード用として読み込めません。

まず、端末のプロセッサとOSが対応するアプリのアーキテクチャを確認してください。2015年以降の一般的なスマートフォンではarm64が候補になりますが、プロセッサが64ビット対応でも、現在のOSで64ビットアプリをインストールできるとは限りません。端末情報を確認して選びましょう。アーキテクチャが分からない場合はuniversalを選べます。通常、複数のアーキテクチャ向けのコンポーネントを含むため、インストールファイルは比較的大きくなります。インストールパッケージを解析できない場合は、アーキテクチャだけでなくOSのバージョン、ダウンロードの中断、同名アプリの署名元の違いも確認してください。アンインストールする前に設定をバックアップしましょう。

まずコアが起動していることと、接続先のサーバーが選択されていることを確認し、v2rayNでシステムプロキシを自動設定します。OSのネットワーク設定を開き、ローカルのアドレスとポートがクライアントの設定と一致するか確認してください。ブラウザー拡張機能や別のプロキシツール、組織の管理ポリシーによって設定が上書きされることがあります。また、システムプロキシを参照しないアプリもあります。競合するツールを終了し、システムプロキシに対応するブラウザーでテストしてください。Linuxデスクトップでは設定画面の場所が環境によって異なるため、必要に応じてGNOMEまたはKDEのネットワーク設定を確認します。

まずTUNを無効にし、通常のプロキシ接続が使えることを確認してから、仮想インターフェースの権限を設定します。Windowsでは通常、管理者権限と対応するドライバーが必要です。macOSとLinuxではクライアントの案内に従って許可を与えてください。権限設定の代わりに、出所の分からないコマンドを実行しないでください。Androidでは初回起動時にOSのVPN接続許可を求められます。拒否した場合は接続を再度開始し、許可してください。別のVPNアプリがシステムインターフェースを使用している場合は、先に停止します。権限を設定しても失敗する場合は、ログでインターフェースの作成やルートの追加に関するエラーを確認し、スイッチを何度も切り替えるのは避けてください。

実際の利用目的に合わせてルーティング設定を選び、対象ドメインに適用されるルールを確認してください。「中国本土を除外」する設定では、通常、ドメインやIPの分類ルールに基づいて該当する通信を直接接続します。グローバルプロキシでは、通常、コアに届いたリクエストを優先的にプロキシ経由にしますが、実際の経路は選択中のルールにも左右されます。ルーティングの「グローバル」は、端末全体の通信を引き受けるという意味ではありません。コアに届いていないアプリの通信には影響しません。特定のサイトだけに問題がある場合は、一時的に設定を切り替えて比較します。原因を確認してからルールを調整し、設定の問題を隠すためにプロキシ対象を広げたままにしないでください。

読み込み済みのサーバーを選び、コアを起動してシステムプロキシを設定したら、正常に表示できるHTTPSページにアクセスしながら、クライアントの接続履歴やログを確認します。対象ドメインが記録されているか、プロキシと直接接続のどちらに振り分けられたかを確認してください。ノードのテストに成功しても、特定のテスト通信が使えたことしか分からず、ブラウザーがプロキシを利用している証明にはなりません。ブラウザーの通信が記録されない場合は、ブラウザー独自のプロキシ設定や拡張機能、OSの設定を確認します。ログの情報が足りない場合は一時的にログレベルを上げ、特定できたら通常のレベルに戻し、ログを適切に管理してください。

サブスクリプショングループ内のノードは、通常、リモートのサブスクリプション内容から生成されます。更新時にクライアントがリモートのデータから項目を再作成したり、上書きしたりするため、サブスクリプション内のノードを長期的な手動設定の保存先にするのは避けましょう。個別の設定を残したい場合は、まずバックアップを取り、クライアントの複製機能または手動追加機能で独立した項目を作成します。元のサブスクリプショングループとは明確に区別してください。更新によって項目の識別情報が変わり、以前の接続先が選択されなくなる場合もあります。更新後は接続先、ルーティング設定、重要な接続パラメータを確認してから、接続テストを行いましょう。

まずクライアントのエクスポートまたはバックアップ機能を使い、サブスクリプショングループ、手動で追加したノード、カスタムルーティング、必要なDNS設定を保存します。ローカルの待ち受けポートやよく使うモードも記録しておきましょう。バックアップファイルにはサーバーのパスワードやユーザー情報、サブスクリプションの認証情報が含まれる場合があります。安全な場所に保管し、通常の添付ファイルとして公開しないでください。別のクライアントに移行する場合は、まず基本の接続設定を移し、ルーティングとDNSは一つずつ再設定します。画面上の設定や設定ファイルの形式は互換性がないことがあります。復元後はノードを1つテストし、正常に動作することを確認してから、残りの設定を移行してください。

まず端末のネットワークが使えることと、システム時刻が正しいことを確認します。次にノードのアドレス、ポート、プロトコルのパラメータに不足がないか確認してください。同じサブスクリプション内の別のノードと比較し、可能であれば別のネットワークでも試します。1つのノードだけ失敗する場合は、そのサーバーや設定に原因がある可能性が高く、すべてのノードが失敗する場合はローカルネットワーク、コアの起動状態、サブスクリプションを確認します。TCPで接続できても、TLSやプロトコルのハンドシェイクが成功したとは限りません。ログで名前解決の失敗、接続タイムアウト、ハンドシェイクエラーを確認し、発生した段階に応じて対処しましょう。原因を追えなくなるため、複数のパラメータを同時に変更しないでください。

「接続済み」と表示されても、通常はローカルサービスまたはシステムインターフェースが起動したことを示すだけで、リモート接続や名前解決まで正常とは限りません。まず現在の接続先を確認し、ブラウザーの通信がコアに届いているか調べます。通信が届いてから失敗する場合は、DNSの名前解決、ルーティングの出口、ハンドシェイクのログを確認してください。ログに何も記録されない場合は、システムプロキシやTUNの対象範囲に戻って確認します。別の正常なHTTPSページを開き、特定サイトだけの障害かどうかも調べましょう。最初からファイアウォールやすべてのセキュリティ設定を無効にするのではなく、ログを使ってアプリ、名前解決、ルーティング、サーバーのどこで問題が起きているか絞り込んでください。

ノードへの接続では保存済みのサーバー設定を使い、サブスクリプションの更新ではサブスクリプションURLにアクセスします。2つの経路ではDNSやルーティング、アクセス条件が異なることがあります。まずサブスクリプションの期限、URLが変更されていないか、ログに記録されたHTTPステータスを確認してください。認証や権限のエラーは、サブスクリプションの提供元に確認します。ネットワークのタイムアウトは、クライアントが対応していれば、直接接続での更新とプロキシ経由の更新を比較してください。プロキシ経由の更新に使うノード自体が利用できない場合、更新できなくなることがあります。短時間に何度も再試行するとリクエスト制限に達する可能性があるため、エラー情報を保存し、時間をおいて再試行しましょう。

まずクライアントを再起動してTUNを無効にし、システムプロキシを解除してから通常の手順で終了します。クライアントを起動できない場合は、OSのネットワーク設定を開き、ローカル宛ての手動プロキシ設定が残っていないか確認してください。ほかのアプリがそのプロキシ設定を使用していないことを確かめてから解除します。AndroidではシステムのVPN接続が有効なままになっていないか確認してください。デスクトップでは、ほかのVPNや仮想ネットワークツールも確認します。復旧後は通常の直接接続でページを開いてテストしてください。原因を特定し、元のネットワーク設定を復元できる準備が整っていない限り、すべてのネットワークアダプターを削除したり、すべてのルートをリセットしたりしないでください。