v2rayNとv2rayNG
よくある質問

パソコンではv2rayNを選び、Windows、macOS、Linuxに合わせてインストーラーを選びます。Androidでは通常、Xrayコアを搭載したv2rayNGを選び、V2Flyコアが必要な場合はv2flyNGを検討してください。名前は似ていますが、同じアプリの別デザインではありません。設定に必要なプロトコル、通信方式、安全性に関するパラメーターも確認しましょう。特に、異なるコアの系統ですべての機能が同じように使えるとは限りません。移行前に既存の設定を保存し、新しいクライアントに設定を取り込んで接続を確認してから、旧クライアントを削除するか判断してください。

クライアントは設定を読み込み、プロキシコアを実行して端末の通信を処理しますが、それ自体が接続先のサーバーになるわけではありません。サブスクリプションURLから複数のサーバー設定を取得するのが一般的です。一方、共有リンクは通常、1件の設定を含みます。いずれも利用権限のあるサービスから入手してください。インポート後はサーバー一覧に設定が表示されているか確認し、接続先を選んで接続を開始します。サブスクリプションURLには認証情報が含まれる場合があるため、公開コメントやスクリーンショット、オンライン解析ツールに貼り付けないでください。問題を相談する際は、エラーの種類と必要な設定だけを共有し、URL、ユーザーID、サブスクリプションのパラメーターは必ず伏せてください。

VLESSはプロキシプロトコル、REALITYはトランスポート層のセキュリティに関わる仕組み、Xrayは設定を実行するコアです。互いに置き換えられるクライアント名ではありません。実際の接続には、通信方式やポート、フロー制御、サーバー側が指定するセキュリティパラメーターも関係します。設定にREALITYと記載されている場合は、選択したクライアントとコアが対応しているか確認したうえで、公開鍵、サーバー名、Short IDなどを照合してください。セキュリティ設定だけをREALITYに変更して接続を試したり、通常のTLS用設定をそのまま流用したりしないでください。各項目はサーバー側から提供された設定に従いましょう。

近年のAndroidスマートフォンの多くは、対応するプロセッサー向けのarm64を選べます。APKのサイズも通常、universalより小さめです。universalには複数のアーキテクチャ向けのコンポーネントが含まれており、端末のアーキテクチャがわからない場合に適していますが、機能が多い上位版というわけではありません。購入時期だけでアーキテクチャを正確に判断することはできないため、古い端末や特殊な端末ではシステム情報を確認してください。インストール時に非対応と表示されたら、OSのバージョン、アーキテクチャ、空き容量を確認します。署名の競合が表示されても、すぐに既存アプリをアンインストールせず、先に設定をバックアップしてください。そのうえで、新旧のAPKが同じクライアントのものか、配布元が上書きインストールに対応しているか確認しましょう。

サブスクリプションURLと、単一サーバーの共有リンクを区別し、それぞれサブスクリプショングループやクリップボードからのインポートなど、適切なメニューから追加してください。コピーした文字列の前後に空白や改行、チャットアプリの文章が混ざっていないか確認し、管理ページのURLではなく、完全なサブスクリプションURLをコピーしたか確かめます。グループを作成してもサーバー一覧が空なら、手動で一度更新してログを確認してください。取得に失敗する場合は、ネットワーク、URLの有効期限、アクセス権を優先して確認します。解析に失敗する場合は、取得した内容の形式とクライアントの対応状況を確認してください。Webページを開けても、有効なサブスクリプションとは限りません。ログイン画面やエラーメッセージが返されている場合もあります。

再試行のために設定をすべて消去せず、現在のサーバー一覧を残してください。サブスクリプションの有効期限やURLの変更、端末の日付と時刻が正しいか確認したうえで、ログから接続タイムアウト、証明書エラー、サーバーによるアクセス拒否のどれかを見分けます。プロキシ経由で更新する設定がある場合は、現在選択中のサーバーに実際に接続できるか確認してください。更新に使っているサーバーがすでに無効なら、ネットワークの利用条件に問題がないことを確認して、直接更新を試す方法もあります。一度に変更するのは1項目にし、結果を記録しましょう。失敗が続く場合はサブスクリプションの提供元に状況を確認してください。更新ボタンを何度も押しても、アクセス権や無効なURLの問題は解決しません。

まずサーバーが接続先に選ばれ、コアが正常に起動していることを確認します。次にシステムプロキシのメニューから、自動設定を有効にしてください。コアの起動とシステムプロキシの変更は別の操作です。メイン画面が開いているだけでは、設定済みとは限りません。続いて、システムプロキシに表示されたアドレスとポートが、クライアントのローカル待ち受け設定と一致しているか、ブラウザーがシステムプロキシを使っているか、ほかのプロキシツールや拡張機能が設定を上書きしていないか確認します。システムプロキシを参照しないアプリでは、アプリ内でプロキシを設定するか、適切な通信の取り込み方法を使う必要があります。クライアント終了後にネットワークの問題が起きる場合は、閉じたローカルポートを指すプロキシ設定が残っていないか確認してください。

まずTUNを無効にし、通常のプロキシ方式で接続できるか確認してください。サーバーの問題を権限エラーと誤認するのを防げます。TUNは仮想ネットワークインターフェースとルーティング設定を使うため、必要な権限はOSとクライアントのバージョンによって異なります。Windowsではクライアントの案内に従って管理者権限を付与し、ほかのデスクトップOSでは該当バージョンの権限設定を確認してください。ログにインターフェースの作成失敗が表示された場合は、仮想ネットワークアダプターのコンポーネント、セキュリティソフトによるブロック、ほかのトンネルツールとの競合を確認します。問題の切り分けのためにファイアウォールを常時無効にしないでください。テスト中は通信を取り込むツールを1つだけ動かし、接続できたらDNSとルーティングが想定どおりか確認しましょう。

システムプロキシは通常、その設定に従うアプリにローカルのプロキシポートへリクエストを送るよう指示します。TUNは仮想ネットワークインターフェースを使って、ルールに合う通信を取り込むため、より広い範囲に影響します。Androidのクライアントでは、VpnServiceを使って端末内の通信を転送する仕組みを作るのが一般的です。初回接続時にシステムの許可が必要ですが、サーバー設定が自動で取得されるわけではありません。いずれの方式も、ルーティング、DNS、アプリごとの動作に影響されます。普段のブラウジングには、まず必要を満たすシンプルな方式を使いましょう。システムプロキシを参照しないアプリも対象にしたい場合に、TUNやモバイル端末での通信取り込みを検討してください。最初からすべてのモードを重ねて使う必要はありません。

実際のアクセス要件に合わせてルーティングを選びましょう。中国本土をバイパスするモードでは、通常、ドメインやIPアドレスのルールに一致する通信を直接接続し、それ以外をプロキシに送ります。グローバルプロキシは、クライアントに取り込まれた通信を優先的にプロキシ経由にするためのモードですが、すべてのアプリの通信を取り込めるとは限りません。切り分けの際は、一時的にグローバルプロキシへ切り替え、同じ接続先にアクセスできるかを確認すると、ルールによる振り分けが原因か判断しやすくなります。切り替え後は、既存の接続が以前の経路を使い続ける場合があるため、接続し直してください。特定のドメインだけに問題がある場合は、グローバルプロキシを万能な修正策として使い続けず、ルールの順序やルールデータ、DNSの結果を確認しましょう。

アプリ別設定を有効にしたら、まず現在のモードの意味を確認してください。通常、「除外」モードでは選択したアプリをプロキシ経由にせず、「選択したアプリのみ」では選択したアプリだけをプロキシ経由にします。実際の動作は画面の説明に従ってください。まず動作を確認しやすいアプリを1つ選んでテストし、結果を見ながら対象を増やしましょう。一度に多く選ぶと、動作の切り分けが難しくなります。設定を変更したらクライアントを再接続し、対象のアプリもいったん終了してから起動し直してください。システムコンポーネントやダウンロードサービス、ほかのアプリが代わりに送信するリクエストは、前面で操作しているアプリの選択に従わない場合があります。チェック状態だけで判断せず、ログと実際の通信を確認しましょう。

まずホスト端末自身で接続できることを確認してから、LANからの接続を許可します。実際の待ち受けプロトコルとポートを確認し、ホストのファイアウォールでは信頼できるLANからの該当する受信接続だけを許可してください。ほかの端末にはホストのLAN内IPアドレスとプロキシポートを入力します。端末自身を指す127.0.0.1は使用できません。両方の端末が相互に通信できるネットワークに接続されている必要があります。ゲストネットワークや無線クライアント間の通信分離によって接続できないこともあります。ローカルのプロキシポートをインターネットに直接公開しないでください。共有を使い終えたら無効にできます。ホストがスリープ状態になる、IPアドレスが変わる、クライアントを終了するなどの理由で、ほかの端末の接続は切断されます。

まず、ログでサーバーのドメイン名を名前解決できているかを確認し、続いて接続先のアドレスとポートへ接続できるか調べます。名前解決の失敗と接続タイムアウトは別の問題です。ポート、通信方式、システム時刻、サーバーの稼働状況を確認し、別の正常な設定と比較してください。可能であればスマートフォンのテザリングでも試しますが、一度に複数の設定を変更しないでください。同じネットワークでどの設定もタイムアウトする場合は、ネットワーク、ファイアウォール、端末側の通信取り込み設定を優先して確認します。特定の設定だけが失敗し続ける場合は、設定の提供元にサーバーの状態を確認してください。遅延テストの失敗だけでは、実際の通信が利用できないとは断定できません。

「接続済み」と表示されても、ローカルサービスの起動やシステムトンネルの確立を示すだけで、Webサイトへのリクエストが成功しているとは限りません。まず通常のHTTPSページを1つ選んでテストし、そのリクエストがクライアントのログに記録されるか確認してください。記録がない場合は、システムプロキシ、ブラウザーの設定、アプリ別の対象リスト、TUNの通信取り込み範囲を確認します。記録はあるものの接続に失敗する場合は、選択中のサーバーとプロトコルの設定を確認してください。ドメイン名でのアクセスだけが失敗する場合は、DNSを調べます。テスト中はほかのプロキシツールと、プロキシ設定を上書きする可能性のあるブラウザー拡張機能を無効にしてください。変更のたびにページを再読み込みするか接続し直し、キャッシュや既存の接続に判断を妨げられないようにします。すべての設定を一度にリセットする必要はありません。

DNSの可能性はありますが、ルーティングルール、接続先サイトの制限、サーバー側の接続失敗も考えられます。まず問題が起きるドメイン名とエラーを記録し、ログで名前解決の結果、適用されたルール、通信の出口を確認してください。同じドメインへの接続が直接接続とプロキシ経由で異なる場合は、クライアントのDNS、システムDNS、ブラウザーの暗号化DNSの組み合わせを確認し、想定した名前解決経路を迂回していないか調べます。出所のわからないDNSサーバーをむやみに設定しないでください。また、HTTPSのドメイン名を使ったテストの代わりにIPアドレスへ直接アクセスするのもおすすめしません。証明書やホスティングの仕組みによって、正確な結果が得られない場合があります。設定を1つ変更したら、関連するキャッシュを消去するか接続を再起動し、同じ条件でテストし直しましょう。

まずシステムのバッテリー使用状況を確認し、クライアントの消費が実際に大きいか調べます。継続的な大量通信と、頻繁な再接続も区別してください。画面ロック後だけ切断される場合は、バックグラウンド動作の制限、自動起動の権限、バッテリー最適化の設定を確認します。長時間接続が必要なら、システムの設定でバックグラウンド動作を許可できますが、待機中のバッテリー消費が増える可能性があります。システムのVPN接続を使用するアプリを複数同時に実行しないでください。接続が頻繁に再確立される場合は、Wi-Fiの切り替え、サーバーの安定性、ログのエラーを調べ、接続障害をキープアライブだけで覆い隠さないようにしましょう。設定を変更した後は、同じような使い方でしばらく様子を見てください。短時間のバッテリー残量だけを一度比較して判断しないでください。