V2Rayのよくある質問

V2Rayは通常、Project Vのプロキシエコシステムや関連するコア技術を指し、統一された単一のGUIを意味するものではありません。v2rayNはWindows、macOS、Linux向けのデスクトップGUIクライアント、v2rayNGはAndroid向けクライアントです。クライアントはサブスクリプション管理、設定の生成、接続の制御を担い、コアは実際のネットワーク通信を処理します。問題が起きたら、まずクライアント名、OS、使用中のコアを確認してから該当する設定を調べましょう。「V2Rayを使っている」という情報だけでは、具体的な操作場所を特定できないことがあります。メニュー名はバージョンによって変わるため、設定の機能を手がかりに探してください。

クライアントは永久無料で、ソースコードも公開されていますが、インストールしてもプロキシサーバーやサブスクリプションのURLが自動で提供されるわけではありません。サブスクリプションは接続に必要な情報を含む設定の入手元であり、利用権のあるサービスか、自分で構築したサーバーから取得する必要があります。有効なサブスクリプション、または完全な共有リンクが手元にあることを確認してから読み込んでください。通常のWebページのURLをサブスクリプションURLとして使うことはできません。サービスの有効期間、通信量、料金は提供元が決めるもので、クライアントとは別です。サブスクリプションのリンクには認証情報が含まれる場合があります。パスワードと同じように保管し、問い合わせの際もURL全体や認証情報が写った画面を公開しないでください。

名前の似ている方ではなく、設定の要件に合わせて選びましょう。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。どちらも関連するオープンソースのエコシステムに属しますが、対応するプロトコルや通信機能は完全には同じではありません。設定でREALITYやXray固有の機能が必要な場合は、v2rayNGの現在のコアが対応しているか確認してください。V2Fly向けの設定を使う場合は、v2flyNGが選択肢になります。共有リンクを読み込めても、すべての項目に互換性があるとは限りません。読み込み後はログと実際の接続状況も確認しましょう。クライアントを切り替える前に設定を保存しておくと、形式の違いをネットワーク障害と取り違えずに済みます。

システムプロキシは、OSのプロキシ設定にローカルのプロキシアドレスを書き込みます。通常はその設定を参照するブラウザーやアプリに適していますが、独自に接続を確立するプログラムやシステムプロキシを無視するプログラムには適用されないことがあります。TUNは仮想ネットワークインターフェースで通信を受け取り、ルーティングルールに従ってコアに処理させる方式です。より幅広い通信を扱えますが、適切な権限が必要で、DNSやルーティング、ほかのネットワークソフトとの連携も求められます。TUNを有効にしても、すべての通信が必ずプロキシを通るわけではなく、直接接続のルールが適用される場合もあります。初めて設定するときは、まずシステムプロキシでサーバーに接続できることを確認し、必要に応じてTUNを有効にすると、原因を切り分けやすくなります。

端末情報や信頼できるシステム情報ツールで、まずプロセッサのアーキテクチャを確認してください。2015年以降に発売された主流のスマートフォンではarm64を試せることが多いものの、発売年だけでは判断できません。端末によっては異なるビット数のOSが動作している場合もあります。universalは通常、複数のアーキテクチャに対応する分、ファイルサイズが大きく、アーキテクチャが分からない場合や専用パッケージをインストールできない場合に向いています。インストールに失敗したら、OSのバージョン要件、空き容量、旧バージョンとの署名の競合、現在の提供元からのアプリインストール許可も確認しましょう。パッケージを変える前に設定をバックアップし、アーキテクチャを試すためだけに既存のクライアントをアンインストールしないでください。

まず入力内容を確認しましょう。サブスクリプションURLは通常、完全なWebアドレスです。一方、共有リンクはvmess://、vless://、trojan://などで始まる場合があり、それぞれ適切な読み込み方法が異なります。コピーするときは、空白、改行、引用符、説明文が混入しないようにしてください。v2rayNではサブスクリプショングループの設定にURLを入力して保存し、その後にサブスクリプションを更新します。v2rayNGではサブスクリプショングループの設定にURLを追加し、メニューから更新します。グループを保存しただけでは、内容が有効とは限りません。更新しても空のままなら、ログインページに転送されていないか、エラーが表示されていないか、未対応の形式ではないかを確認し、提供元にURLの有効性を問い合わせてください。

まずインストールパッケージがチップに合っているか確認します。Apple Silicon搭載Macではarm64、Intel搭載Macではx64を選び、ディスクイメージ内の手順に沿ってインストールしてください。提供元や署名を理由にOSが起動を阻止する場合は、想定したダウンロード元のファイルであることを確認してから、システム設定の「プライバシーとセキュリティ」を開き、OSが案内する個別アプリの許可手順に従います。システム全体のセキュリティ機能を無効にしたり、出所不明のターミナルコマンドを実行したりしないでください。「アプリが破損している」「アーキテクチャに対応していない」と表示された場合は、対応するパッケージを再ダウンロードし、OSのバージョン要件も確認します。アプリは起動するのに接続できない場合は、セキュリティ設定を繰り返し変更するのではなく、設定やログを確認してください。

まずTUNを無効にしてから、使用中のプラットフォームでサポートされている方法で権限を付与してください。Windowsでは通常、管理者権限が必要です。macOSやLinuxでは、クライアントが対応する特権サービスや補助コンポーネント、仮想ネットワークインターフェースの権限が必要な場合があります。詳細は現在のバージョンの説明とOSの案内を確認してください。他のプラットフォームの手順をそのまま流用しないでください。権限を付与したらクライアントを再起動し、ネットワークインターフェースの作成、ルートの設定、権限拒否に関するエラーがログに残っていないか確認します。組織管理の端末では、ポリシーにより仮想ネットワークインターフェースの作成が禁止されていることがあります。その場合は端末の管理者に相談してください。すぐに権限を付与できない場合は、システムプロキシで基本的な接続を確認し、複数の仮想ネットワークインターフェース型プロキシツールが同時に通信を処理しないようにします。

通常は、宛先のドメイン名やアドレス、ルールに応じて直接接続とプロキシを振り分けるルールベースのルーティングを使い、すべての通信を常に同じ経路に流すのは避けましょう。LAN内の機器にアクセスする場合は、LANをバイパスする設定がルートに含まれているか確認してください。プリンター、共有フォルダー、ローカルの管理画面などが遠隔地へ送られるのを防げます。特定のWebサイトの問題を切り分けるには、プロキシモードと直接接続モードを一時的に切り替えて比較し、確認後に元のルールへ戻します。モード名はクライアントのバージョンによって変わることがあるため、現在のルーティングルールとシステムプロキシの状態も確認してください。ルーティングの切り替えで変わるのは、既存の通信経路に入った後の処理です。システムプロキシを無視するアプリが自動的にプロキシを使うようになるわけではありません。

まず、システムDNS、クライアントのコアが使うDNS、ブラウザー内蔵の暗号化DNSを区別してください。それぞれ別のリクエストを処理している場合があります。現在のモードでどのDNSが名前解決を担当しているかを確認し、直接接続先とプロキシ接続先の名前解決経路がルーティングの設計に合っているか調べます。リモートDNSのアドレスを設定できても、名前解決のリクエストが必ずプロキシを通るとは限りません。そのリクエスト自体のアウトバウンドルールも確認してください。TUNを使う場合は、DNSの引き継ぎ設定と仮想ネットワークインターフェースのルーティングを連携させる必要があります。FakeDNSも、有効にするだけですべての問題を解決する機能ではありません。設定は一度に一つだけ変更し、関連アプリの再起動やキャッシュの削除後に再テストしてください。元の設定も保存しておくと、問題が起きた際に戻せます。

まずクライアントで有効な設定を選び、接続を開始します。次に必要なシステムプロキシまたはTUNを有効にし、対象のアプリから新しいリクエストを送信してください。クライアントのログにそのアプリに対応する接続記録があるかを確認し、出口IPアドレスの確認結果も合わせて、想定した経路になっているか判断します。確認用のページ自体も振り分けルールの影響を受けるため、出口IPアドレスだけでは、すべてのアプリが同じ経路を通っているとは証明できません。ブラウザーは正常で別のプログラムだけ失敗する場合は、それぞれがシステムプロキシを参照しているか調べます。テスト中は重複して動作しているプロキシツールを停止してください。スイッチの点灯、接続アイコン、設定のテスト成功だけで、すべての通信が処理されていると判断しないでください。

提供元の更新頻度に合わせて更新間隔を設定すれば十分です。接続を維持するために何度も更新する必要はありません。更新するとサブスクリプショングループの設定が再取得されるため、提供元が削除・変更した項目は変わることがあり、クライアント上で手動編集した項目が上書きされる場合もあります。長期保存したい手動設定は、バックアップするか、別のグループに保存してください。更新前に対象のグループを確認し、更新後は使用中の設定が残っているか確認します。使用中の設定が置き換わった場合は、設定を選び直して接続を再起動する必要があります。自動更新にも、URLの有効性、ネットワークへの接続、クライアントの動作が必要です。期限切れのサブスクリプションや形式エラーへの対処に代わるものではありません。

まずサブスクリプションURLが完全で、サービスの期限が切れておらず、端末の日時が正確であることを確認してください。次に「プロキシを経由せず更新」と「プロキシを経由して更新」をそれぞれ試します。前者は現在のネットワークから直接アクセスし、後者はすでに使用可能なプロキシ接続が必要です。初めて読み込む段階で有効な設定がない場合、プロキシ経由の更新は完了できないことがあります。ログの具体的なエラーを確認し、DNSの名前解決失敗、接続タイムアウト、証明書エラー、アクセス拒否、データの解析失敗を切り分けてください。URLからサブスクリプションデータではなくWebページが返る場合は、提供元に修正を依頼します。更新ボタンを何度も押したり、URL全体を公開ログに貼り付けたりしないでください。エラーの種類と発生時刻を記録すると原因を特定しやすくなります。

タイムアウトは、特定のテストが制限時間内に完了しなかったことを示すだけで、サーバーが故障したと断定する根拠にはなりません。まず端末が通常のネットワークに接続できることを確認し、サーバーのアドレス、ポート、プロトコル、通信パラメーターがサブスクリプションの内容と一致しているか調べます。TCPの疎通テストと、プロキシ経由で実際の宛先へ接続するテストは別です。前者に成功しても、認証やプロトコルのネゴシエーションに成功したとは限りません。使用できることが分かっている別の設定と比較し、名前解決失敗、接続拒否、ハンドシェイクエラーがログに出ていないか確認してください。一部のテスト先だけ失敗する場合は、テスト用URLとそのルーティングを調べます。すべての設定で失敗する場合は、端末のネットワークや権限、ほかのプロキシソフトとの競合を優先して確認しましょう。

「接続済み」は通常、クライアントまたはコアが起動したことを示すだけで、ブラウザーのリクエストがプロキシに届いているとは限りません。まずシステムプロキシのアドレスとポートが現在のクライアントを指しているか確認し、Webページにアクセスしたときにログへ新しい接続記録が追加されるか調べてください。記録がない場合は、ブラウザー独自のプロキシ設定や拡張機能、システムプロキシの適用状況を確認します。記録があるのに失敗する場合は、DNS、認証、プロトコルのネゴシエーション、接続先側のエラーを切り分けます。TUNを一時的に無効にし、システムプロキシだけを使って比較することもできますが、通信を処理する方式は一度に一つに絞ってください。クライアントを停止してもネットワークに接続できない場合は、残ったシステムプロキシ設定を解除し、仮想ネットワークインターフェースの状態を確認します。ネットワーク設定全体をすぐにリセットする必要はありません。

まず通常のブラウザーでプロキシ経由のアクセスができることを確認し、クライアントのローカル待ち受けアドレスとポートを調べます。特定のプログラムだけ動作しない場合は、システムプロキシを無視している、独自のプロキシ設定を使っている、または別のネットワークインターフェースに依存している可能性があります。そのプログラムがHTTPまたはSOCKSプロキシを手動で設定できるか確認し、指定するポートのプロトコルも確かめてください。ポート番号だけでプロトコルを推測することはできません。プロキシに対応していないプログラムでは、必要な権限、ルーティング、DNSの条件を満たしたうえでTUNを検討します。コマンドラインツールは環境変数を参照する場合もあるため、システムプロキシのスイッチが影響するとは限りません。テスト後は一時設定を元に戻し、クライアント終了後も古いプロキシアドレスが残って接続を妨げないようにしてください。