V2Rayのよくある質問
設定・接続トラブルの対処法

まずは使うデバイスのOSで候補を絞ります。Windows、macOS、Linuxのデスクトップではv2rayN、Androidでは通常、Xrayコアを採用したv2rayNGが候補です。V2Flyコアを使いたい場合はv2flyNGを検討してください。機能はバージョンやコアによって異なるため、名前だけでプロトコルの互換性を判断することはできません。設定がすでにある場合は、提供元が指定するプロトコル、トランスポート、安全設定を確認し、クライアントがその組み合わせに対応しているか調べましょう。接続できないからといって、まずクライアントを替えるのは避けてください。

クライアントは画面操作や設定管理、プロキシのオン・オフを担当し、コアは設定に基づいて接続、ルーティング、プロトコル処理を行います。ノードは接続先の情報一式、サブスクリプションはその情報を取得・更新するためのURLです。クライアントをインストールしただけでは、使えるノードがあるとは限りません。画面が起動しても、コアや接続先が正常とは限りません。トラブル時は、画面操作、コアの起動、サブスクリプションの取得、ノードへの接続のどの段階で問題が起きているか切り分けましょう。サブスクリプションURLには認証情報が含まれる場合があるため、アカウント情報と同様に管理し、スクリーンショットや掲示板に公開しないでください。

そのまま置き換えることはできません。VMess、VLESS、Trojanはそれぞれ異なるプロキシプロトコルです。REALITYはセキュリティ層の方式であり、これらと並ぶ独立したノードプロトコルではありません。接続できるかどうかは、クライアントとサーバーのプロトコル、トランスポート、セキュリティ層、関連項目が一致しているかで決まります。プロトコル名を変えたり、設定を一つオンにしたりするだけでは、通常、接続できる設定にはなりません。まずは提供元の完全なリンクをインポートしてください。手動で編集する場合は、元の設定をバックアップし、ポート、ユーザーID、サーバー名、公開鍵など必要な項目を一つずつ確認しましょう。

システムプロキシはOSにプロキシのアドレスを登録し、その設定を参照するアプリに適用します。TUNは仮想ネットワークインターフェースを使って、ルーティング条件に合う通信を取り込みます。より広い範囲を扱えますが、権限、ルーティング、DNSの連携が必要です。初めて使う場合は、まずTUNをオフにし、システムプロキシで設定が使えるか確認してから、システムプロキシに従わないアプリへの対応を検討しましょう。TUNは接続品質を高めるスイッチではなく、すべての通信を取り込めるとは限りません。切り替えるときは一度に一項目だけ変更し、ほかの仮想NICやプロキシソフトとの同時利用を避けてください。

デバイスが64ビットARMアプリに対応していると確認できた場合は、arm64を選びましょう。アーキテクチャがわからない場合は、複数のアーキテクチャ向けファイルを含むuniversalを選べます。universalはファイルサイズが大きくなる傾向がありますが、接続が速くなるわけではありません。購入年だけで判断しないでください。プロセッサは64ビット対応でも、OSが32ビット環境で動作している端末があります。アプリ非対応と表示された場合は、OS要件、デバイスのアーキテクチャ、インストールパッケージの入手元を確認してください。署名の競合が表示された場合は設定をバックアップし、既存アプリと同じ配布元のものか確認しましょう。

まず、サブスクリプションURLと個別ノードの共有リンクを区別します。サブスクリプションURLはサブスクリプショングループに追加し、個別リンクはクリップボードからのインポートなど適切な機能を使います。コピー時に前後の空白、改行、途中での切れがないか確認し、Webページのタイトルやログイン画面ではなく、元のURLを取得できているか確かめましょう。グループを追加した後、更新を実行して初めてノードが表示されることがあります。内容を取得できても解析できない場合は、形式が非対応か、エラーページが返されている可能性があります。対応クライアントと出力形式を提供元に確認してください。トラブル対処のために、サブスクリプションURL全体を見知らぬ変換サイトに送信しないでください。

まずエラーメッセージを記録し、OS、プロセッサのアーキテクチャ、インストールパッケージの種類に応じた動作要件を確認します。圧縮ファイルは書き込み可能な場所に完全に展開し、圧縮ソフト上から直接起動しないでください。インストーラーの場合は画面の案内に従ってインストールします。Windowsのデスクトップ版とWPF版では画面の技術が異なります。必要な実行環境は各リリースの説明を確認し、起動エラーをすべて同じランタイム不足と決めつけないようにしましょう。以前は起動できていた場合、残っているプロセスを終了して設定をバックアップし、別のフォルダーに新しい設定を用意して、プログラムと既存設定のどちらに問題があるか切り分けます。

デスクトップでは、まずログで失敗した処理を確認し、使用中のOSとクライアントの要件に応じて管理者権限やネットワーク拡張の許可を付与してください。システムのセキュリティ機能を長期間オフにするのは避けましょう。AndroidではOSのVPN接続許可が必要です。また、通常は同じVPN経路を使用する別のアプリと同時に動かせません。以前は使えていた場合、別のVPN、仮想NICツール、セキュリティソフトによってネットワーク環境が変わっていないか確認します。ほかの通信を取り込むソフトを終了してクライアントを再起動しても失敗する場合は、いったんシステムプロキシに戻してノードを確認し、権限エラーをサーバー側の障害と誤認しないようにしましょう。

サブスクリプションの取得とノードへの接続は別の通信経路です。既存ノードが使えても、サブスクリプションURLにアクセスできるとは限りません。まず現在の設定を残し、URLの有効期限が切れていないか、認証情報が無効になっていないか確認し、更新ログでタイムアウト、アクセス拒否、解析エラーを調べましょう。クライアントにプロキシ経由と直接接続の更新方法がある場合は、利用できるノードがある状態でそれぞれ試せます。メニュー名はバージョンによって異なる場合があります。ログイン画面やアクセス拒否が返る場合は、提供元に権限を確認してください。グループを何度も削除したり、短時間に更新を繰り返したりしないでください。

普段はルールベースのルーティングを使い、宛先ごとにルールで直接接続、プロキシ、遮断を選ぶ方法が便利です。グローバルモードは一時的な比較テストに向いていますが、具体的な動作はクライアントの設定によって異なります。すべてのアプリの通信がクライアントに取り込まれるという意味ではありません。対象範囲はシステムプロキシ、アプリ側のプロキシ、TUNによって決まります。切り替えた後はリクエストを再送し、必要に応じてアプリの既存接続を切断してください。確立済みの接続が以前の経路を使い続けることがあります。ルールモードだけで失敗する場合は、まずマッチしたルールとDNSの結果を確認し、すぐにノードを変更しないでください。

必ずしもそうではありません。TCP接続テストでわかるのは、通常、指定したアドレスとポートに接続できるかどうかです。実際のリクエストテストは、テスト先、TLS、DNS、サーバー側の設定にも左右されます。テストに失敗しても、ノードがまったく使えないとは限りません。応答があっても、すべてのWebサイトやアプリが使えるとは限りません。普段使う宛先で少数のテストを行い、ログで失敗した段階も確認しましょう。大量のテストは通信量の増加やサービス側の制限につながることがあります。同時実行数を抑え、単一の数値を追うのではなく、同じ環境での結果を比較してください。

まずクライアントのエクスポートまたはバックアップ機能を使い、現在のコア、プロキシモード、待ち受けポート、カスタムルールも記録します。設定フォルダーをコピーする場合は、書き込み中のファイルを複製しないよう、先にクライアントを正常終了してください。バックアップにはノードの認証情報やサブスクリプションURLが含まれる場合があります。安全な場所に保管し、ログや設定を共有する前に機密情報を削除しましょう。一度に変更するのは一種類の設定だけにし、保存後、同じ宛先で再テストして結果を記録します。復元時はクライアントのバージョンと設定形式の互換性を確認してください。コアのJSONをGUIクライアントの管理データベースにそのまま上書きしないでください。

まずプロキシをオフにして、通常のネットワーク接続が使えるか確認します。次に、システム時刻、ノードのアドレスとポート、現在のネットワークでWeb認証が必要かを確認しましょう。ログで名前解決に失敗している場合はDNS、接続確立のタイムアウトなら接続先、ポート、ネットワーク経路を確認します。ハンドシェイクに失敗する場合は、プロトコル、セキュリティ層、認証項目を確認してください。同じノードを利用が許可された別のネットワークで試すか、現在のネットワークで既知の設定を試すと、原因を絞り込めます。最初からDNS、ルーティング、プロトコルを同時に変更しないでください。変更を重ねると、元の問題と新たに発生した問題を区別しにくくなります。

「接続済み」は、コアが起動した、またはOSのVPN接続が確立したことを示すだけの場合があり、接続先へのリクエストが成功したとは限りません。まずブラウザーで明確なテスト先にアクセスし、対応する接続ログがクライアントに出るか確認しましょう。ログがなければ、アプリの通信がプロキシを通っているか確認します。ログがあり、ドメイン名の解決に失敗している場合はDNSを確認し、証明書やハンドシェイクのエラーが出る場合はシステム時刻とセキュリティ設定を確認してください。一時的に別のルーティングモードでも試し、ルールの誤判定がないか切り分けます。プロキシをオフにしても通信できない場合は、まず通常のネットワーク接続を復旧し、ほかの通信を取り込むソフトを終了して、プロキシ設定が残っていないか確認しましょう。

すべてのアプリがOSのプロキシ設定を参照するわけではありません。アプリ独自のプロキシ設定を使うもの、起動時にだけ設定を読み込むもの、一般的なHTTPプロキシでは扱えない通信もあります。まずクライアントがシステムプロキシを正しく設定しているか、待ち受けアドレスとポートが合っているか確認します。その後、対象アプリを完全に終了してから再起動してください。アプリが手動プロキシに対応している場合は、クライアントのプロトコルとポートを指定し、HTTPとSOCKSを混同しないようにしましょう。より広い範囲の通信を取り込む必要がある場合はTUNを検討し、アプリの除外設定やルーティングルールも確認してください。システムプロキシのスイッチだけで通信経路を判断しないようにしましょう。

まず、影響があるのは特定のドメイン、一部のアプリ、すべての接続のどれかを確認し、ログに記録された名前解決の結果と出力先を控えます。アプリ、OS、コアがそれぞれ名前解決に関わることがあります。ブラウザーで暗号化DNSを有効にしていると、リクエストが想定したコアのDNS経路を通らない場合もあります。DNSサーバーに到達できるか、DNSリクエストがどの経路で送信されるか、ルーティングがドメイン名とIPアドレスのどちらで判定されるか、古いキャッシュが残っていないかを順番に確認しましょう。設定変更後は接続を作り直してテストします。FakeDNS、IPv6、ドメイン名の解決方法は互いに影響するため、一つのドメインが開けないからといって高度な設定を一度にすべて有効にするのは避けてください。