v2rayNのよくある質問

v2rayNはWindows、macOS、Linux向けのGUIクライアントで、v2rayNGはAndroid向けです。クライアントはサブスクリプションの管理、設定の編集、プロキシの接続口を担い、実際の接続処理はコアが行います。XrayとV2Flyは関連するオープンソースのコアエコシステムで、対応機能はバージョンによって異なります。トラブル時は「V2Rayが使えない」とだけ記すのではなく、クライアント名、コア名、エラー内容を記録してください。Android向けのv2flyNGはV2Flyコアを採用した別のクライアントです。設定が使えるかどうかは、プロトコルと各パラメーターを確認してください。

サブスクリプションURLは通常、Web上のアドレスです。クライアントがアクセスすると複数の設定を取得でき、その後も更新できます。一方、個別の共有リンクはvmess://、vless://、trojan://などのプロトコルで始まり、1つの設定をインポートするために使います。個別設定のインポート欄にサブスクリプションURLを貼り付けると、形式エラーになることがあります。サブスクリプション欄に共有リンクを入力しても、正常に更新できません。内容を見分けてから、サブスクリプショングループかクリップボードからのインポートを選んでください。サブスクリプションURLには認証情報が含まれる場合があるため、画面やURL全体を公開しないでください。

クライアントのインストールで準備できるのは端末上のツールです。接続には、適法に取得した有効なサーバー設定またはサブスクリプションが別途必要です。インポートしたら、プロトコル、サーバーアドレス、ポート、認証パラメーターを確認し、使用する設定として選択してください。クライアントに「起動中」と表示されても、通常はローカルのコアやプロキシの接続口が動作していることを示すだけで、リモート接続やすべてのアプリの動作を保証するものではありません。初回設定では、まずシステムプロキシに対応したブラウザーで確認し、その後にターミナルやゲームなどを設定してください。当サイトでは使い方を案内していますが、サブスクリプションURLや接続アカウントは提供していません。

REALITYは「全般」や「LANをバイパス」といったプロキシモードではなく、接続設定に関わるセキュリティ技術で、VLESSの設定でよく使われます。REALITYを使用するかどうかはサーバー側の構成で決まるため、トラブル対処のためにTLSへ変更しないでください。インポート後は、サーバー側で指定されたサーバー名、公開鍵、ショートIDなどのパラメーターを確認します。項目名はクライアントのバージョンによって異なる場合があります。システムプロキシはアプリからクライアントへの接続方法を決め、ルーティングは通信の出口を決めます。REALITYの設定とは別の層なので、それぞれ個別に確認してください。

まず、端末が対応するアプリのアーキテクチャに合わせて選んでください。近年の一般的なAndroidスマートフォンではarm64版が使えることが多く、universal版よりファイルサイズも小さい傾向があります。universal版は複数のアーキテクチャに対応しているため、判別できない場合に試せます。購入年だけで判断しないでください。端末によっては、システム環境とチップの対応状況が異なります。互換性エラーが出たら、まずシステムや端末の説明でアーキテクチャを確認します。universal版もインストールできない場合は、同じアーキテクチャのパッケージを繰り返し試すのではなく、Androidのバージョン、空き容量、署名の競合を確認してください。

サブスクリプショングループの設定で新しいグループを追加し、見分けやすい名前を付けて、サブスクリプションURL全体を入力欄に貼り付けます。保存後、現在のサブスクリプションを更新してください。まず、コピー時に空白、改行、引用符、説明文が混ざっていないかを確認し、URLがまだ有効かどうかも確かめます。コピーしたものが個別の共有リンクなら、サーバー設定をクリップボードからインポートする項目を使ってください。Base64は一部のサブスクリプションで使われるエンコード方式ですが、任意のエンコード文字列をURL欄に入力できるわけではありません。メニュー名は変わることがあるため、現在のバージョンにあるサブスクリプション管理の項目を確認してください。

まず、現在のシステムに合ったクライアントをダウンロードしたことを確認し、圧縮ファイルを実行可能なフォルダーにすべて展開してください。圧縮ファイルのプレビューから直接起動しないでください。外部ランタイムが必要なビルドであることが明記されている場合や、実行環境の不足を示すエラーが出た場合に限り、指示に従って対応するアーキテクチャの.NETデスクトップランタイムをインストールします。すべてのクラッシュをランタイム不足のせいにしないでください。続いて、セキュリティソフトのブロック履歴、フォルダーのアクセス権、起動ログを確認します。設定の破損が疑われる場合は、先にバックアップを取り、新しい別フォルダーでテストしてください。既存のサブスクリプションやルーティング設定をすぐに削除しないでください。

TUNは仮想ネットワークインターフェースを作成または設定します。デスクトップでは、プラットフォームやクライアントのバージョンに応じて、管理者の許可、サービスコンポーネント、システムのネットワーク権限が必要になることがあります。まず、ネットワークを制御する他のツールを終了し、クライアントの案内に従って許可してください。インストールフォルダー全体に過剰な権限を設定しないでください。AndroidではシステムのVPN接続許可を確認します。別のVPN接続が有効な場合、同時に使えないことがあります。許可しても失敗する場合は、ログにインターフェースやルーティングのエラーがないか確認してください。切り分け中はTUNを無効にし、通常のローカルプロキシでリモート設定が使えるかを確認してから、TUNを個別に調べてください。

システムプロキシに対応したアプリからクライアントを使う場合は、「システムプロキシを自動設定」を選びます。「システムプロキシを解除」は、クライアントが設定した接続口を削除する項目で、停止時や設定の残りを調べるときに使います。「システムプロキシを変更しない」は既存のシステム設定を積極的に変更しないという意味で、すべての通信が直接接続になるわけではありません。システムプロキシはアプリをクライアントにつなぐ方法であり、全体のルーティングとは異なり、すべてのプログラムに自動適用されるわけでもありません。切り替える前に元の設定を記録してください。特に、端末に組織のプロキシ設定がある場合は注意が必要です。動作確認後、クライアントを終了したときにシステムプロキシが想定どおりに戻るかも確認してください。

多くのコマンドラインプログラムはデスクトップのシステムプロキシを参照せず、独自のプロキシ設定やhttp_proxy、https_proxy、all_proxyなどの環境変数を使います。まずプログラムのドキュメントを確認し、HTTPプロキシとSOCKSプロキシのどちらに対応するかを調べてから、クライアントで実際に有効になっているローカルの待ち受けアドレスとポートを設定してください。SOCKS用のポートをHTTP用として使わず、バージョンが違ってもポートが同じだと決めつけないでください。環境変数は、まず現在のターミナルセッションだけに設定してテストし、成功してから永続化するか検討します。以前プロキシを設定していた場合は、古い変数やno_proxyが今回の通信に影響していないかも確認してください。

「LANをバイパス」は通常、プライベートIPアドレス宛ての通信を直接接続にして、ルーター、プリンター、ローカルサービスにアクセスできるようにします。それ以外の通信の扱いは、現在のルールセットによって異なります。グローバルルーティングは通常、クライアントに入った通信をまとめてプロキシの出口へ送りますが、クライアントを経由していないアプリまで自動的に制御するものではありません。ローカル機器にアクセスできない場合は、対象アドレスに適用されるルールとその優先順位を確認し、TUNやDNSの設定で経路が変わっていないか調べてください。プロキシモード、ルーティング、DNSを同時に変更せず、1つずつ変更して同じ宛先で再テストすると、原因を特定しやすくなります。

手動で追加した設定は独立したグループに分け、サブスクリプションから生成された設定を直接編集しないでください。次回の更新で変更が上書きされる場合があります。更新前にクライアントの設定とカスタムルートをバックアップし、使用中のグループと設定も記録してください。バックアップにも認証情報が含まれることがあるため、安全に保管します。更新後は使用中の設定が残っているか確認し、トランスポートとセキュリティのパラメーターに変更がないか調べてください。自動更新はサブスクリプションの内容を再取得する機能であり、期限切れのアカウントをサーバー側で修復するものではありません。更新結果に異常がある場合は、返された内容とログを確認してください。唯一のバックアップに何度も上書きしないでください。

まず、通常の直接接続サイトにアクセスできるか確認し、システムの自動時刻設定を有効にしてください。時刻のずれでセキュアなハンドシェイクに失敗することがあります。次に、クライアントのコアが起動しているか、ローカルの待ち受けポートが他のプログラムに使われていないかを確認し、サーバーアドレス、リモートポート、トランスポート方式、TLSまたはREALITYのパラメーターを照合します。ログを見て、ドメイン名の名前解決失敗、接続タイムアウト、接続拒否、ハンドシェイク失敗を区別してください。これらを同じ問題として扱わないでください。特定のネットワーク環境だけで失敗する場合は、利用が許可された別のネットワークでも試してください。設定ミスを隠すために証明書の検証を無効にしないでください。

まず「接続済み」がローカルサービスの起動を示すのか、リモートへのリクエスト成功を示すのかを確認します。同じブラウザーで、普段直接接続できるサイトとプロキシが必要なサイトをそれぞれ開いてください。使用する設定が正しいか、システムプロキシがクライアントの現在の待ち受けポートを指しているか、ブラウザーに独自のプロキシ設定がないかを確認します。続いてアクセス時のログを確認してください。記録がなければ、アプリがクライアントを経由していない可能性があります。記録があり名前解決に失敗している場合はDNSを、ハンドシェイクエラーがある場合はリモート側のパラメーターを確認します。サブスクリプションサービスの状態も確認してください。接続口が起動していても、アカウントが有効とは限りません。

OSのプロキシ設定を開き、アドレスとポートがクライアントの現在の待ち受け先と一致するか確認します。次に、ブラウザーの拡張機能がシステム設定を上書きしていないか調べてください。ブラウザーや仕事用のプロファイルによっては、独自のプロキシ、自動設定スクリプト、管理ポリシーを使うため、クライアントのメニューを切り替えても変更されません。端末の管理要件に反しない範囲でプロキシ拡張機能を一時的に無効にし、ブラウザーを終了してから再起動して試してください。シークレットウィンドウでも、拡張機能や管理ポリシーの影響を回避できるとは限りません。クライアントのログにリクエストがない場合は、サブスクリプションやリモートのプロトコルを変更する前に、接続口の問題を解決してください。

まず更新エラーの内容を確認します。タイムアウトの場合はリクエスト経路とネットワークを、認証失敗やアクセス拒否の場合はサブスクリプションの権限を確認してください。形式エラーは、ログイン画面やエラーページを設定として読み込もうとしている可能性があります。クライアントで更新経路を選べる場合は、まずプロキシを経由せずに更新してみてください。サブスクリプションサービスへのアクセスにプロキシが必要なら、すでに使える設定で更新します。まだインポートしていない設定に依存して、更新が循環するのを避けてください。URLの期限が切れている、またはリセットされた場合は、サービス提供元から再取得する必要があります。エラーを共有するときは、エラーの種類と必要最小限の状態情報だけを残し、URL全体、認証情報、応答内容に含まれる認証情報を隠してください。