V2Rayクライアントのよくある質問

デスクトップではWindows、macOS、Linuxに対応するv2rayN、AndroidではXrayコアを採用したv2rayNGが候補です。V2Flyコアを採用したv2flyNGも選択肢の一つです。設定の読み込みや管理を担うのはクライアントの画面、実際の接続を担うのはコアです。そのため、名前が似ていても対応する設定がすべて同じとは限りません。選ぶ前にサーバー側のプロトコル、通信方式、必要なコア機能を確認し、OSとプロセッサのアーキテクチャに合うインストーラーを選びましょう。現在の設定で問題なく接続できているなら、画面の違いだけを理由に乗り換える必要はありません。移行する場合は、カスタムルーティングとサブスクリプションのグループ設定を事前に保存してください。

いいえ。VMessとVLESSはプロキシプロトコル、TCPやWebSocketなどは通信方式、REALITYは接続のセキュリティに関わる仕組みで、VLESSなどと組み合わせて使われます。設定を読み込む際はプロトコル名だけでなく、通信方式、セキュリティ設定、サーバー名と関連パラメーターも確認してください。クライアントにプロトコルの選択肢があっても、現在のコアがすべての組み合わせに対応しているとは限りません。サーバー側の完全な設定に合わせてコアを選び、REALITYを通常のTLS設定の代わりとして扱ったり、既存設定のプロトコルだけを変更したりしないでください。

共有リンクは通常、1台分のサーバー設定を表すもので、たとえば vmess:// や vless:// で始まる文字列です。サブスクリプションURLは通常HTTPSのURLで、複数の設定を取得し、後から更新するために使います。共有リンクはクリップボードからのインポートなどを使い、サブスクリプションURLはサブスクリプションのグループに登録してください。登録先を間違えると、解析エラーや空のリストが表示されることがあります。サブスクリプションを更新すると、通常はそのグループ内のサーバー設定が置き換わりますが、カスタムルーティングまでは自動で同期されません。どちらにも接続情報が含まれる場合があるため、トラブル調査時に内容をそのまま公開しないでください。

比較的新しいAndroid端末ではarm64を選べることが多いものの、購入時期だけで判断せず、端末が対応するアプリのアーキテクチャを確認してください。プロセッサは64ビット対応でも、OSが32ビットアプリ環境しか提供しない端末では、arm64版をインストールできないことがあります。アーキテクチャが不明な場合や、インストーラーに非対応と表示される場合は、同じクライアントのuniversal版を試してください。universal版はより多くのアーキテクチャ向けのデータを含むため、ファイルサイズは大きくなる傾向があります。署名の不一致やバージョンのダウングレードが表示される場合、アーキテクチャを変えても解決しないことがほとんどです。インストール済みアプリの入手元とバージョンを確認し、アンインストール前に設定をバックアップしてください。

まず、1件の共有リンクを読み込もうとしているのか、サブスクリプションURLを読み込もうとしているのかを確認します。コピーした内容に空白、改行、全角の句読点、説明文などが混ざっていないかもチェックしてください。サブスクリプションURLはクエリパラメーターを含めて全体を保持し、サブスクリプションのグループに登録してから更新します。ログに解析エラーが表示される場合、ログインページやエラーページが返されているか、クライアントが対応していない形式の可能性があります。ブラウザーでURLを開けても、返された内容をクライアントが解析できるとは限りません。提供元が現在のクライアントに対応した形式を案内しているか確認してください。調査中は既存のグループを残し、設定を何度も消去しないようにします。アクセス情報を含むURL全体をログのスクリーンショットに載せないでください。

既存のサーバーに接続できても、それは現在の接続パラメーターが使えるというだけで、サブスクリプションサーバーにもアクセスできるとは限りません。まず更新ログを確認し、DNSの名前解決エラー、接続タイムアウト、証明書エラー、HTTPの拒否を切り分けてから、サブスクリプションの期限やURLの変更を確認します。プロキシ経由で更新する設定がある場合は、まだ使える接続設定を使って更新を試せます。ただし現在のプロキシが使えない状態で経由を強制すると、かえって更新に失敗します。システム時刻やネットワークへのログイン状態も確認してください。一度に変更する条件は一つに絞り、更新できたらグループ内の項目を確認します。更新ボタンを繰り返し押すだけでは解決になりません。

クライアントを起動しただけでは、システムプロキシが設定されたとは限りません。まずコアが正常に動作していることと、ローカルの待ち受けポートが設定と一致していることを確認します。次にシステムプロキシの自動設定を選び、OSのネットワーク設定で実際のプロキシアドレスとポートを確認してください。システムプロキシが適用されるのは、その設定に従うアプリだけです。独自のプロキシ設定を使うアプリもあれば、TUNで通信を取り込む必要があるアプリもあります。ほかのプロキシツール、ブラウザー拡張機能、管理ポリシーが設定を上書きしていないかも確認しましょう。ルーティングルールとプロキシポートを同時に変更せず、まずシステムプロキシに対応したブラウザーで確認してから、個別アプリの例外を調べてください。

TUNは仮想ネットワークアダプターとシステムルートを扱うため、通常はシステムプロキシよりも多くの権限が必要です。Windowsではクライアントの案内に従って管理者権限を付与してください。macOSとLinuxでは、現在のインストール方法に応じて補助サービスやシステム権限を許可します。具体的な操作場所はバージョンごとの画面で確認してください。まずログに権限不足、ネットワークアダプターの作成失敗、ルートの書き込み失敗が明記されているかを確認し、ネットに接続できないという理由だけで権限を引き上げないでください。有効にする前に、通信を取り込むほかのツールを終了し、元のネットワーク設定を保存します。有効化後にネットワークに問題が起きたら、まずTUNを無効にして基本的な接続が戻ることを確認し、その後DNSとルートを調べてください。何度も再インストールする必要はありません。

ドメインやアドレスに応じて通信の出口を分ける場合は、ルールベースの振り分けを使います。特定のルールがアクセスに影響しているか一時的に確認するには、グローバルプロキシに切り替えて比較できます。グローバルプロキシは通常、コアに届いた接続をプロキシ経由で外部へ送る設定であり、端末上のすべてのアプリの通信を自動的に取り込むものではありません。ルールは上から順に判定されるため、広い条件のルールを先に置くと、後続の細かいルールが適用されないことがあります。最終的な動作はデフォルトの出口にも左右されます。変更時はルールの順序、条件、出口のタグをあわせて確認してください。テスト後は元のモードに戻し、グローバルプロキシで成功したからといって、サブスクリプションやDNSの問題まで解決したと判断しないようにしましょう。

まずアプリごとのプロキシ設定が有効か確認し、現在のモードを読み違えないようにしましょう。「選択したアプリをプロキシ経由にする」と「選択したアプリをプロキシから除外する」では、意味が逆です。対象リストを保存したら、画面の案内に従って接続を再起動します。必要に応じてテスト対象のアプリも終了して再起動し、新しい接続に設定を反映させてください。VPNに含まれていないアプリの通信はコアのルーティングに入りません。そのため、アプリの対象リストが誤っている場合にドメインルールだけを変更しても解決しません。テストでは対象を明確にしたアプリを一つだけ使い、複数のリストを同時に変更しないでください。選択肢の名前はバージョンによって異なることがあるため、チェックボックスの数だけで判断せず、現在の画面の説明を確認しましょう。

まず、アプリがドメインをどう名前解決するか、コアがどのDNSを使うか、ルーティングでドメインをIPアドレスに解決する必要があるかを切り分けます。AsIsは通常、元のドメイン名を使って優先的に照合します。IPIfNonMatchはドメインのルールに一致しない場合に名前解決を試み、IPルールとの照合に使います。IPOnDemandはルール判定でIPアドレスが必要になったときに名前解決を行います。これらの設定だけでシステム全体のDNSが置き換わるわけではありません。アプリ独自の暗号化DNSを使っている場合は、通信経路が異なることもあります。一部のドメインにアクセスできない場合は、まず名前解決のログとDNSの出口を確認してからルールを調整してください。すべてのDNSとドメイン判定の設定を同時に変えると、問題を再現しにくくなります。

普段の接続先を選ぶときは、ping単独よりも実接続の遅延のほうがプロキシ利用時の経路に近い指標ですが、ダウンロード速度を表すものではありません。pingは通常ICMPの往復時間を測り、TCPテストはポートへの接続を確認します。実接続テストでは、プロキシのハンドシェイクや測定先からの応答も関わることがあります。測定方法や対象が異なれば、結果を直接比較できません。ネットワーク、測定先、測定方法をそろえて複数回測り、最小値だけで判断しないでください。ダウンロード速度はサーバーの負荷、回線のパケットロス、接続先サイトにも左右されます。遅延が小さくても転送速度が出ない場合は、別途、一定時間の転送テストを行い、一覧の数値だけで順位を決めないようにしましょう。

端末の基本的なネット接続、システム時刻、サブスクリプションの状態、接続パラメーター、コアのログの順に確認します。まずプロキシを一時停止して通常のネット接続が使えることを確かめ、時刻とタイムゾーンに大きなずれがないか確認してください。続いてサブスクリプションを更新し、アドレス、ポート、プロトコル、通信方式、セキュリティ設定、サーバー名を照合します。TCPポートに接続できても、通信の入口に到達しただけで、その後の認証に成功したとは限りません。タイムアウトがログに記録される場合は、ネットワークを変えたり、動作確認済みの別設定と比較したりします。ハンドシェイクや認証のエラーなら、パラメーターを見直してください。テストごとのエラーと変更点を記録し、ノードとDNSを同時に変えて原因を見失わないようにしましょう。

「接続済み」は、ローカルサービスやAndroidのVPNインターフェースが起動したことを示しているだけで、サーバーや接続先のWebサイトまで到達できるとは限りません。まず対象のアプリが実際にプロキシを経由しているか確認し、アクセス時にコアのログが出るかを調べます。ログがない場合は、システムプロキシ、アプリごとの対象リスト、TUNによる通信の取り込みを優先して確認してください。DNSエラーがある場合は名前解決の経路を、認証やハンドシェイクのエラーがある場合はサーバーのパラメーターを確認します。一部のサイトだけ開けない場合は、ルールとの照合、接続先サイト、アプリのキャッシュも調べてください。同じ接続先で通常接続とプロキシ接続を比較し、1つのWebページの結果でネット全体の状態を判断したり、接続アイコンだけで成功とみなしたりしないようにしましょう。

まず、画面をオフにした後だけ切断されるのかを確認し、アプリを再び開いたときにサービスが動作中か調べます。Androidの省電力機能がバックグラウンド動作を制限している場合は、システム設定でクライアントのバックグラウンド実行を許可し、端末に用意された設定に応じてバッテリー最適化や自動起動の権限を調整してください。常駐通知が無効になっていたり、バックグラウンドのアプリが終了されたりすると、サービスの状態を確認しにくくなることもあります。Androidで同時に有効にできるVPNは通常1つです。別のVPNアプリを起動すると、現在の接続が置き換わる場合があります。すべての切断を省電力機能のせいにせず、画面がオンのときも失敗する場合は、ネットワークの切り替わり、ノードの状態、コアのログを確認し、発生条件を個別に記録してください。

検証の無効化を通常の対処方法にするべきではありません。まずシステム時刻、サーバーアドレス、ポート、サーバー名、セキュリティ方式がサーバー側の設定と一致しているか確認してください。通常のTLSでは証明書の有効期限と信頼チェーンも確認します。REALITYでは公開鍵、short ID、フィンガープリントなどの設定とコアの対応状況を確認します。通常のTLSの証明書トラブルと同じ方法では判断できません。設定がサブスクリプションで管理されている場合は、まず更新して提供元の案内と照合し、推測で一つずつ変更しないでください。同じ設定が別の端末で動作するなら、この端末のコアのバージョンやネットワーク環境を確認します。診断ログを公開する前に、アドレス、識別情報、アクセス情報を削除してください。