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

プラットフォームを基準に選択：Windows、macOS、Linuxのデスクトップでは、サブスクリプションやシステムプロキシ、ルーティングルールをまとめて管理しやすいv2rayNが候補です。Androidでは、Xrayコアを採用したv2rayNGが候補になります。v2flyNGはV2Flyコア系列の選択肢で、既存の設定が同系列の動作に依存している場合に適しています。この順序は対応プラットフォームと設定との適合性を基準にしたもので、接続速度のランキングではありません。すでにサブスクリプションがある場合は、プロトコル、通信方式、安全性に関するパラメーターを確認してからクライアントを選びましょう。サーバー側の障害を直すためにクライアントを変更するのは、基本的な解決策ではありません。

役割の違い：クライアントはサブスクリプションの管理、ノードの選択、設定画面を提供します。コアは設定を読み込み、ルーティングを実行して接続を確立します。ノードには、リモートサーバーのアドレス、ポート、認証パラメーターが記述されています。画面上でノードを追加できても、設定を読み込めたことを示すだけで、リモートサーバーが利用可能とは限りません。トラブル対処では、クライアントの起動失敗、コアの設定エラー、リモート接続の失敗を切り分けましょう。クライアントのバージョン、実際に動作しているコア、エラーの発生時刻を記録すると、同じサブスクリプションを何度も追加し直すより原因を特定しやすくなります。

通信の対象範囲：システムプロキシの影響を受けるのは、主にOSのプロキシ設定に従うアプリです。設定を無視したり、独自のプロキシ設定を使ったりするアプリもあります。TUNは仮想ネットワークインターフェースとルーティングを使い、条件に合う通信を取り込みます。より多くのアプリを対象にできますが、権限やDNS、ほかのネットワークツールとの互換性にも注意が必要です。初めて設定する場合は、まずシステムプロキシでノードに接続できることを確認し、その後TUNを個別にテストしてください。どちらも速度の段階を表すものではありません。TUNを有効にしてもノードの設定ミスは直らず、すべてのアプリの通信経路が統一されるわけでもありません。

パラメーターの整合性：プロトコル、通信方式、安全性の設定はサーバー側と一致させる必要があります。クライアントのメニューで名前だけ変更しても接続できません。VLESS、VMess、Trojanはそれぞれ異なるプロキシプロトコルです。REALITYはセキュリティ機構で、特定のVLESS設定と組み合わせて使われることが多く、これらのプロトコルと同列に自由に置き換えられるものではありません。インポート後は、設定の提供元が指定したフロー制御、通信方式、安全性に関する項目を維持してください。未対応の項目がある場合は、まず現在のコアが対応しているか確認しましょう。タイムアウトを解消しようとプロトコルを変更すると、別の要因が加わることがあります。まず元の設定とサービスの状態を確認してください。

アーキテクチャの選び方：近年のAndroidスマートフォンの多くはarm64に対応しているため、まず対応するインストールパッケージを選びましょう。universalは通常、複数のプロセッサアーキテクチャに対応しており、サイズは大きめですが、アーキテクチャを確認できない場合に便利です。発売年は目安にとどめ、最終的には端末とOSが対応するアーキテクチャを確認してください。パッケージを解析できない場合は、ダウンロードが完了しているか、OSがそのバージョンの要件を満たしているか、アーキテクチャが一致しているかを確認しましょう。更新時は同じアプリへの上書きと署名の互換性も確認してください。アンインストールして再インストールする前に、サブスクリプションとカスタム設定をバックアップしましょう。

追加方法と形式：サブスクリプションURLと、単一ノードの共有リンクを区別しましょう。サブスクリプションURLはサブスクリプショングループに追加して更新し、ノードの共有リンクはクライアントが対応するクリップボードからのインポート機能を使います。コピー時に前後の空白や改行、チャットアプリが付けた説明文を取り除き、URLの有効期限が切れていないか、再認証が必要か確認してください。解析エラーが表示された場合、取得した内容がWebページやログイン画面、非対応形式になっている可能性があります。文字コードを手当たり次第に変更するのは避けましょう。エラーログから、リクエスト段階と解析段階のどちらで失敗したかを確認できます。サブスクリプションURLは機密情報です。内容全体が見えるスクリーンショットを公開したり、URLをそのまま貼り付けたりしないでください。

起動の手順：サブスクリプションを追加しただけでは、プロキシ接続が確立したとは限りません。まずノードを選び、コアが正常に起動していることを確認します。次にv2rayNでシステムプロキシの自動設定を有効にし、システムプロキシのアドレスがクライアントの実際の待ち受けポートと一致しているか確認してください。ポート番号は現在の設定を参照し、ほかのガイドに記載された数字をそのまま使わないでください。特定のアプリだけ使えない場合は、アプリ独自のプロキシ設定を確認します。すべてのアプリで失敗する場合は、ポートの競合、コアの起動ログ、セキュリティソフトによるブロックを確認してください。テスト中は、システム設定が上書きされないよう、ほかのプロキシツールをいったん終了しましょう。

権限の確認：まず通常のプロキシモードが使えることを確認してから、TUNの権限を設定します。Windowsではクライアントの案内に従って管理者権限を許可してください。macOSとLinuxでは、使用中のバージョンの要件に応じて補助サービスや権限昇格を許可します。Androidでは、システムに表示されるVPN接続リクエストを確認してください。プラットフォームごとに許可の手順は異なります。失敗が続く場合は、ログの詳細なエラーを確認し、ほかのVPN、仮想ネットワークインターフェース、セキュリティソフトとの競合がないか調べましょう。何度も許可を繰り返したり、すべてのセキュリティ機能を無効にしたりしないでください。競合するプログラムを終了し、クライアントを再起動して、最小限の設定で再テストしましょう。

リクエスト経路：まずサブスクリプションURLが有効か確認し、接続タイムアウト、アクセス拒否、内容の解析失敗を切り分けます。直通接続で取得できず、すでに利用可能なノードがある場合は、サブスクリプション更新時にプロキシを使う設定を有効にして、手動で一度更新し、ログを確認してください。この設定は既存のプロキシが使えることを前提としています。初回設定で利用可能なノードがない場合は、依存関係が循環する可能性があるため、有効にするとかえって更新できません。リクエストが成功しても解析に失敗する場合は、プロキシを切り替え続けるのではなく、サブスクリプションの形式と取得した内容を確認しましょう。自動更新の間隔は提供元の更新頻度に合わせ、短時間にリクエストを繰り返さないようにしてください。

グループ管理：提供元ごとにサブスクリプショングループを作成し、用途がわかる名前を付けましょう。複数のURLを同じグループに何度も追加するのは避けてください。更新前に選択中のノードと所属グループを記録し、更新後にノードが削除、改名、置換されていないか確認します。自動更新では通常、提供元のノード情報が再構成されます。重要な手動変更をサブスクリプションのノードに直接加えるのは避け、長期的に使う設定は別に保存してください。グループを削除する前に、手動で追加した項目が含まれていないか確認しましょう。フィルター条件は少数から試し、利用可能なノードまで非表示にならないようにしてください。

ルーティングの選び方：普段は用途に合ったルールベースの振り分けを使い、指定した宛先だけをプロキシ経由にし、ほかの通信はルールに従って直接接続する方法がおすすめです。グローバルプロキシは、問題が振り分けルールに起因するか短時間で比較する際に便利です。ただし、クライアントが通信を取り込む範囲に左右され、端末のすべての通信が対象になるわけではありません。グローバルプロキシでは正常でルールモードでは失敗する場合、ノードをすぐに変更するのではなく、ルールの順序、ドメインの判定、DNSの経路を確認しましょう。LAN、プリンター、内部サービスには、明示的な直接接続ルールが必要な場合があります。変更前に元の設定を保存し、一度に一項目だけ変更して結果を記録してください。

ドメインのマッピング：FakeDNSは仮想IPとドメインを対応付けます。対応するTUNとルーティングの組み合わせでドメイン情報を保持し、ドメインルールの判定に役立ちます。汎用的な通信速度向上機能ではなく、DNSの経路を理解しないまま有効にするのは避けてください。実際の名前解決結果に依存するアプリでは、アクセスに問題が起きることがあります。テスト前にDNSとルーティングの設定を保存しましょう。有効にした後、特定のアプリだけで失敗する場合は、FakeDNSを無効にして元の名前解決設定に戻し、クライアントを再接続します。アプリまたはシステムのDNSキャッシュを消去し、問題が解消するか確認してください。

段階的な切り分け：まず端末から通常どおりインターネットに接続できることを確認し、コアが起動しているか、待ち受けポートが競合していないか、システムプロキシが正しいアドレスを参照しているかを調べます。続いて、選択中のノードとサブスクリプションの更新時刻を確認し、端末の時計を点検したうえで、ログからドメインの名前解決、接続確立、ハンドシェイクのどの段階でタイムアウトしたかを判断します。利用実績のある別の設定、または別のネットワークと比較できますが、一度に変更する条件は一つにしてください。遅延テストに失敗しても、アプリでのアクセスが必ず失敗するとは限りません。テストで異なる接続先を使う場合があります。同じノードで複数の端末が失敗する場合は、設定の提供元にリモートサービスの状態を確認しましょう。

接続状態の確認：「接続済み」や「実行中」は通常、ローカルサービスが起動していることを示すだけで、すべての宛先に接続できるとは限りません。まずブラウザーがシステムプロキシと独自のプロキシ設定のどちらを使っているか確認し、同じ宛先でルールモードとグローバルプロキシを比較します。ログにDNSの名前解決失敗、誤った送信先へのルーティング、認証失敗がないか確認してください。通常のプロキシは使えるのにTUNで失敗する場合は、仮想ネットワークインターフェース、DNS、ルーティングの競合を重点的に調べます。ブラウザーだけで失敗する場合は、拡張機能とブラウザーのプロキシ設定を確認しましょう。クライアントの再インストール、ノードの変更、DNSの変更を同時に行うと、どの操作が影響したのか判断しづらくなります。

ハンドシェイクのパラメーター：まずシステムの日付、時刻、タイムゾーンを正確に設定します。次に設定の提供元が指定するサーバー名、SNI、通信パスなどの安全性に関するパラメーターを確認してください。接続先アドレスと証明書検証に使う名前は異なる場合があります。サーバー側の設定に従って入力し、異なるからといって同じ値に変更しないでください。通常のTLS接続では、証明書の名前を検証する必要があります。REALITYの設定では、専用パラメーターとコアの対応状況も確認してください。証明書検証のスキップを長期的な解決策にするのは避けましょう。具体的なエラー情報を残し、アドレスと認証情報を隠して共有すると、証明書、パラメーター、サーバー設定のどこに問題があるかを切り分けやすくなります。

比較方法：まず問題が特定のアプリやドメインだけで起きているか確認し、ログでドメインの名前解決結果と実際の送信先を調べます。同じ宛先がグローバルプロキシでは開けるのにルールモードでは失敗する場合は、ルールの適用順、ドメインルールのデータ、DNSの選択を優先して確認してください。どちらのモードでも失敗する場合は、ノードと接続先のサービスを引き続き確認します。IPアドレスへの直接アクセスだけで判断しないでください。ドメイン名と正しいTLS名が必要なサービスもあります。DNSを変更したら接続を確立し直し、必要に応じてキャッシュを消去しましょう。複数のリゾルバーを同時に変更すると再現性が失われるため、変更前後の記録を残してください。