V2Rayのよくある質問

Windows、macOS、Linuxのデスクトップではv2rayNが有力な選択肢です。Androidでは通常、Xrayコアを採用したv2rayNGを選び、V2Flyの設定環境が必要な場合はv2flyNGを検討します。クライアントはサブスクリプション管理や画面表示、プロキシの入口を担い、コアは設定の解析と接続を担います。役割の異なるものなので、まずOSを確認し、サーバー側のプロトコル、通信方式、安全層への対応も照合してください。クライアント名だけで互換性を判断するのは避けましょう。クライアントをインストールしても、利用可能なサービスが自動で手に入るわけではありません。利用権限のあるサブスクリプションまたは接続設定を別途用意してください。

VMessとVLESSはプロキシプロトコル、REALITYは安全層の仕組みです。REALITYを同列の独立したアウトバウンドプロトコルとして扱うことはできません。よくある構成はVLESSとREALITYの組み合わせですが、クライアントはプロトコル、通信方式、安全層をそれぞれ認識する必要があります。インポート後はサーバーの設定と照らし合わせ、アドレス、ポート、ユーザーID、serverNameに加え、REALITYで使うpublicKeyとshortIdを確認してください。サーバー側で特定のflowが指定されている場合は、それも一致させます。安全層の選択欄をREALITYに変えるだけでは、既存の設定が自動的に対応するわけではありません。不足しているパラメーターは設定の提供元に確認しましょう。

サブスクリプションURLは、通常、クライアントが複数の接続設定を取得するためのアドレスです。更新時にも同じURLへアクセスします。一方、個別ノードの共有リンクは1つの接続を示すもので、インポート後にサブスクリプションの変更が自動反映されることはありません。受け取った内容がサブスクリプションURLかノード共有リンクかを確認し、対応する方法でインポートしてください。サブスクリプションURLを個別ノードの編集欄に貼り付けると、形式エラーや一覧が空になる原因になります。URLにアクセス用の認証情報が含まれる場合もあるため、アカウント情報と同様に管理してください。トラブルの相談時に、URL全体やQRコード、認証情報が写ったスクリーンショットを公開しないでください。

変換を検討するのは、元のサブスクリプション形式を利用先のクライアントが認識できない場合に限ります。クライアントにそのままインポートできるなら、元のサブスクリプションを使いましょう。変換は通常、設定項目の並べ替えにすぎず、サブスクリプションの有効期限を延ばしたり、サーバーの停止や認証パラメーターの不足を解決したりするものではありません。サードパーティの変換サービスには、サブスクリプションURL全体やアクセス用の認証情報が渡る可能性があります。利用前に信頼できる相手かを確認し、まずは提供元が案内する互換形式を使ってください。変換後も通信方式、安全層、flow、ルーティングの情報を一つずつ確認し、テキストが生成されたことだけで接続できると判断しないでください。

v2rayNのサブスクリプショングループ設定で名前とURLを追加して保存しても、通常はグループが作成されるだけで、ノードを取得したことにはなりません。メイン画面に戻り、そのグループのサブスクリプションを更新して、一覧に設定が表示されたことを確認します。最後に使いたい項目を選び、アクティブサーバーに設定してください。メニュー名はバージョンによって多少異なるため、実際の画面に従いましょう。グループがすでにある場合は、URLが途中で切れていないか、前後に空白が入っていないか、正しいグループを更新しているかを確認してください。同じ名前のグループを何度も作ると項目が重複し、更新結果を判断しにくくなります。

まずv2rayNGのサブスクリプション設定に名前と完全なURLを追加して保存し、設定一覧に戻って更新を実行します。個別ノードの共有リンクを受け取った場合は、クリップボードからインポートするなど、該当する方法を選んでください。一覧に設定が表示されたら、使う項目を選んで接続を開始します。初回起動時は、システムの案内に従ってVPN接続を許可してください。ステータスアイコンが示すのは端末上の接続サービスが起動したことだけで、接続先が必ず利用できるとは限りません。接続後に通信できない場合は、同じ内容を何度もインポートせず、ログ、選択中の設定、DNSを確認しましょう。

端末が64ビットARMアーキテクチャだと確認できている場合は、arm64を選びましょう。アーキテクチャが不明な場合や、ほかの対応アーキテクチャとの互換性が必要な場合はuniversalを選べますが、インストーラーのサイズは通常大きくなります。最近の一般的なスマートフォンは64ビットARMプロセッサを採用していますが、プロセッサの対応状況と実際のOS環境が必ずしも一致するとは限りません。端末の仕様とアプリの互換要件を確認してください。インストールできない場合は、OSのバージョン、空き容量、既存アプリの署名、ダウンロードしたパッケージの完全性を確認します。インストール失敗だけを理由にプロトコルの変更が必要だと判断しないでください。アーキテクチャと接続設定は別の問題です。

まず、ネットワークを制御する可能性のあるほかのプログラムを終了し、使用中のプラットフォームで仮想ネットワークアダプターの作成やルート変更に必要な権限を付与してください。Windowsでは通常、管理者権限が必要です。macOSとLinuxではクライアントの案内に従って許可を設定します。手順はバージョンやインストール方法によって異なります。権限を確認したら、コアが正常に起動していることを確かめてからTUNを有効にし、ログを確認してください。通常のシステムプロキシが使えていた場合は、それを基準として設定を一つずつ試すのがおすすめです。権限の問題を回避するために、システムの保護機能を無効のままにしないでください。ネットワークアダプターやルートが残った場合は、まずTUNを停止してからシステムのネットワーク状態を確認しましょう。

システムプロキシがプロキシアドレスを提供するのは、基本的にシステム設定に従うアプリです。すべてのプロセスの通信を強制的に制御するわけではありません。まずv2rayNのコアが動作中であること、ローカルの待ち受けポートが正しいこと、システムプロキシの自動設定が選択されていることを確認します。次に、対象アプリが独自のプロキシ設定や環境変数、独自の通信方式を使っていないか確認してください。ブラウザー拡張機能がシステム設定を上書きする場合もあります。一部のアプリだけがプロキシを経由しない場合は、そのアプリにローカルプロキシを設定できます。より広範囲の通信を制御する必要があるときに、TUNを検討してください。クライアントを終了する前にシステムプロキシを解除すると、停止済みのローカルポートへシステムが接続し続けるのを防げます。

システムプロキシは、アプリが通信をクライアントに渡すかどうかを決めます。ルーティングルールは、コアに届いた通信をプロキシ経由、直接接続、または遮断のどれにするかを決めます。両者は別の設定です。普段使う場合は、まず用途に合ったルーティングプリセットを選び、対象のドメインに想定どおりのルールが適用されているか確認しましょう。切り分けのために一時的にすべての通信をプロキシ経由にすると、振り分け設定の誤りを見つけやすくなります。ただし、すべてのアプリの通信が自動的にコアへ届くわけではありません。テスト後は元の設定に戻し、LANへのアクセスやDNSの動作も確認してください。特定のサイトを直すために、すべての接続経路を長期的に変更するのは避けましょう。

判断の基準はノードのプロトコルではなく、現在のネットワークからサブスクリプションURLへ直接アクセスできるかどうかです。直接アクセスできる場合は、既存の接続への依存を減らすため、プロキシを経由せずに更新できます。利用可能な接続を使わないとURLにアクセスできない場合に限り、プロキシ経由での更新を試してください。現在のアクティブノードが使えない状態なら、そのノード経由の更新も失敗しがちです。直接更新に切り替えるか、利用できることを確認した別の設定を選びましょう。自動更新の間隔を調整する前に、まず手動で更新に成功することを確認してください。サブスクリプションの有効期間と利用頻度に合わせて間隔を設定し、頻繁なリクエストで原因の確認を代替しないようにしましょう。

移行時は、まず有効なサブスクリプションを追加し直し、移行先のクライアントでローカルポート、システムプロキシ、DNS、ルーティングを個別に確認してください。これらのローカル設定は、サブスクリプションに含まれていない場合があります。設定のエクスポートが必要な場合は、信頼できるローカル環境または管理された経路だけで受け渡し、移行後に一時ファイルとクリップボードの履歴を削除してください。コアやクライアントが異なると、設定項目をすべて共通して使えるとは限りません。特に通信方式、flow、安全層のパラメーターに注意が必要です。設定フォルダー全体を上書きしてすぐにTUNを有効にするのではなく、まず1つの接続が正常に動作することを確認し、その後で通信の振り分けや制御を段階的に戻しましょう。

まず端末自体がインターネットに接続できることを確認し、次にサブスクリプションの有効期限、選択中の設定、アドレスやポートの誤変更を確認してください。その後、クライアントのログを見て、ドメイン名の名前解決失敗、接続タイムアウト、認証失敗、ハンドシェイクエラーのどれに該当するかを切り分けます。それぞれ対処法が異なります。同じサブスクリプション内の別の設定と比較できますが、1回のテストだけで特定のプロトコル全体が使えないと判断することはできません。すべての項目で同時に問題が起きる場合は、まずローカルネットワーク、DNS、ファイアウォール、時刻設定を確認してください。1つだけ問題が続く場合は、サービス提供元に状態を確認しましょう。具体的なエラーを見ずにクライアントの再インストールを繰り返すのは避けてください。

接続済みと表示されても、コアやローカルネットワークサービスが起動しただけで、目的のサイトにアクセスできるとは限りません。まず選択中の設定とシステムプロキシが正しいことを確認し、ログから名前解決の失敗、接続先の問題、通信がクライアントに届いていない問題のどれかを判断します。TUNを使っている場合は一時停止し、システムプロキシで基本的な接続を確認すると、仮想ネットワークアダプターとプロトコルの問題を分けて調べられます。ほかのプロキシソフト、ブラウザー拡張機能、セキュリティソフトがネットワーク設定を同時に変更していないかも確認してください。変更は一度に一つだけ行い、結果を記録しましょう。DNS、ルーティング、サブスクリプションを一度にリセットすると、原因を特定しにくくなります。

まずサブスクリプションURLが完全か確認します。特に「?」以降のパラメーターや、コピー時に入った改行・空白に注意してください。次にアカウントの有効期限と、提供元が指定するサブスクリプション形式を確認します。ログイン画面やエラーページ、空の内容が返ってくる場合、URLを開けてもクライアントが設定データを取得できているとは限りません。Base64やプロトコル項目のエラーが出ても、内容全体を何度もエンコードし直すのは避けてください。元の形式が現在のクライアントに対応しているかを確認し、元のURLを保管しましょう。更新後は、選択中のグループとフィルター条件を確認し、一覧の絞り込みを空のサブスクリプションと誤認しないようにしてください。必要であれば、対象のクライアントに適した形式を提供元に問い合わせましょう。

まずエラーがサブスクリプションURLへのアクセス、応答のダウンロード、内容の解析のどの段階で発生しているかを確認し、有効期限切れやリセットがないかも調べてください。URLがリセットされると、クライアントに古いURLが残っていても使えなくなる場合があります。その際は新しい完全なURLに差し替えましょう。直接更新とプロキシ経由の更新をそれぞれ試すことはできますが、どちらも接続経路が実際に利用可能であることが前提です。プロキシ経由で更新する場合は、アクティブノードも確認してください。サーバー側でリクエスト頻度が制限されている場合は、連続して再試行せず、提供元の案内に従って待ちましょう。問い合わせ時はクライアント名、OS環境、認証情報を除いたエラー概要だけを伝え、サブスクリプションURL全体は公開しないでください。