V2Rayのよくある質問

操作画面と実際の接続を担うコンポーネントを分けて考えましょう。v2rayNは、サブスクリプションの管理、サーバーの選択、ルーティング設定を行うデスクトップ向けGUIクライアントです。v2rayNGはXrayコアを使うことが多いAndroidクライアントで、v2flyNGはV2Flyコアを採用したAndroid向けの選択肢です。コアはプロトコルや通信方式、外向きの接続を処理し、クライアントは設定を生成してコアを呼び出します。エラーが出たら、サブスクリプションの更新、画面上の操作、コアのログのどこで発生したかを確認してから、該当する箇所を調べてください。クライアントを変えればあらゆる接続問題が解決するわけではありません。

サブスクリプションURLからは通常、更新可能なサーバー設定一式を取得でき、サブスクリプショングループに登録して使います。サーバー共有リンクは一般に1つの設定だけを含み、クリップボードからのインポートなどで取り込みます。サービス提供元のWebページはログインやアカウント確認、サブスクリプションURLの取得に使うもので、そのままサブスクリプションとしてインポートするものではありません。コピー元とクライアントの表示を確認し、URLがhttpsで始まるかどうかだけで判断しないでください。サブスクリプションURLにはアクセス用の認証情報が含まれる場合があります。ブラウザーで開けても、URL全体を公開の掲示板に貼ったり、見知らぬオンライン変換ツールにアップロードしたりしないでください。

サービス提供元が明確に対応し、現在のクライアントコアが認識できる設定を優先してください。VMessとVLESSはプロキシプロトコルで、REALITYは接続のセキュリティに関する方式です。3つを同じ階層の選択肢として単純に比較することはできません。別のプロトコルを試すために、サーバー設定のプロトコル名だけを書き換えるのは避けてください。アドレス、ポート、認証情報、通信方式、セキュリティパラメーターは、すべてサーバー側と一致させる必要があります。使えるサブスクリプションがある場合は、まず設定をすべて取り込んで元のパラメーターを保ち、実際の接続結果を見てサーバーを選びましょう。プロトコル名だけで速度や接続の可否が保証されるわけではありません。

違います。システムプロキシは、システムプロキシ設定に従うアプリのリクエストを、クライアントのローカル待ち受けポートへ送るための設定です。グローバルルーティングは、コアに入った通信をどのアウトバウンドへ送るかを決めます。TUNは仮想ネットワークインターフェースを通じて、対象となるシステム通信を取り込みます。ルーティングをグローバルにしても、すべてのアプリがクライアントを経由するとは限りません。まずアプリの通信が取り込まれているかを確認し、その後にルーティング先を調べてください。ブラウザーは使えるのに特定のデスクトップアプリが使えない場合は、グローバルルーティングを何度も切り替えるのではなく、アプリがシステムプロキシに対応しているかを確認し、必要に応じてTUNを検討しましょう。

サブスクリプショングループの設定を開き、新しいグループを作成します。サブスクリプションURL全体をアドレス欄に貼り付け、名前を入力して保存したら、サブスクリプションを更新してください。グループを保存しただけでは、通常サーバー一覧は作成されません。URLが無効と表示される場合は、ログインページやQRコード画像のURLをコピーしていないか、引用符、空白、改行が混ざっていないか確認します。解析に失敗する場合は、サービス提供元の形式が現在のクライアントに対応しているか確認してください。他のツール用の設定ファイル全体を、汎用のサブスクリプションとして使わないでください。それでも失敗する場合は、エラーメッセージを控え、更新失敗の手順に沿って調べてください。

端末のプロセッサーアーキテクチャを確認してから、インストールパッケージを選びましょう。2015年以降に発売された主流のAndroidスマートフォンではarm64が有力ですが、発売時期だけでアーキテクチャを判断することはできません。端末によっては、システムが異なるアプリ実行環境を採用している場合もあります。確認できない場合は、複数のアーキテクチャに対応することが多いuniversal版を選べますが、その分ファイルサイズは大きくなります。インストール時に解析エラーが出る、またはインストールできない場合は、Androidのバージョン要件、空き容量、既存アプリとの署名の競合も確認してください。アンインストールして再インストールする前に、クライアントのバックアップまたはエクスポート機能で設定を保存し、サブスクリプションURLを安全に保管しましょう。

クライアントには設定管理と接続の機能がありますが、インストールしただけでサーバー設定が手に入るわけではありません。使えるサブスクリプションURLまたはサーバー共有リンクを用意し、対応する方法でインポートしてください。サブスクリプショングループを追加済みなら、更新が有効になっているか確認して、手動で一度更新します。次にサーバー一覧の検索条件を解除し、正しいグループが表示されていることを確認してください。更新成功と表示されても一覧が空の場合は、取得内容が空ではないか、アカウントの有効期限が切れていないか、サービス提供元が設定の提供を停止していないかを調べます。有効な設定がない状態で、システムプロキシを有効にするだけで接続を試さないでください。

まずTUNを無効にしてクライアントを終了し、使用中のOSの要件に従って権限を付与してください。Windowsでは通常、管理者としてクライアントを起動する必要があります。macOSやLinuxでは、ネットワークコンポーネントの許可、仮想インターフェースの作成、クライアントが求める権限の設定が必要になることがあります。詳細はバージョンごとの案内を確認してください。Androidでは初回接続時にシステムのVPN許可ダイアログが表示され、許可すると接続できます。エラーを回避するために、システムのセキュリティ機能を全面的に無効化しないでください。許可後も失敗する場合は、他のVPNや仮想ネットワークインターフェースを使うアプリが通信の取り込み機能を占有していないかを確認し、ログで最初に発生したインターフェース作成エラーを調べてください。

まず手動で一度更新し、サブスクリプションURLが有効なことを確認します。次にサブスクリプショングループで更新を有効にし、適切な間隔を設定してください。間隔の単位は分であることが多いため、入力前に現在のバージョンの項目説明を確認しましょう。接続を維持するために毎分リクエストする必要はありません。更新頻度が高すぎると、サービス提供元のレート制限にかかることがあります。自動更新には通常、クライアントの起動と端末のネットワーク接続が必要です。端末がスリープ中に更新されなかったからといって、URLが無効とは限りません。更新後は、現在使用中のサーバーが一覧に残っているか確認してください。グループが複数ある場合は、それぞれの更新設定と最終更新時刻を確認し、1つだけ変更して全体に反映されたと思い込まないようにしましょう。

まず、クライアントが提供する「中国本土をバイパス」などの適切なプリセットを選び、ルールに必要な地理データがクライアントの手順で用意されているか確認してください。プリセットの名前や対象範囲はバージョンによって変わることがあるため、名称だけでWebサイトがすべて意図どおりに処理されるとは判断できません。直接接続するはずのサイトと、プロキシ経由にするはずのサービスにそれぞれアクセスし、ログに表示される宛先ドメインとアウトバウンドの記録を確認します。ルールにドメイン照合が含まれる場合は、アプリからドメイン名がコアへ渡されているかも確認してください。一部のドメインだけ経路が違う場合は、カスタムルールの順序と対象範囲を優先して調べ、すぐにルーティング全体をグローバルに切り替えないでください。

システムプロキシを使用している場合は、クライアントでシステムプロキシを解除してから、通常の手順で終了することをおすすめします。システムプロキシの接続先がローカルの待ち受けポートになっていると、クライアント終了後はそのポートが応答しなくなり、システムプロキシに従うアプリがネットワークに接続できなくなることがあります。正常終了時に設定を復元するバージョンもありますが、プロセスの強制終了や異常シャットダウン後に復元されるとは限りません。終了後にブラウザーがネットワークへ接続できない場合は、OSのプロキシ設定にローカルプロキシのアドレスが残っていないか確認し、組織のネットワーク設定と区別してください。TUNを使用している場合も、終了前にTUNを無効にしましょう。

クライアント名とバージョン、OS、システムプロキシとTUNのどちらを使用しているか、問題を再現できる操作手順を記録してください。エラー発生前後のログを一部だけ抜き出し、設定ファイル全体や実行ログ全体を公開しないようにしましょう。共有前に、サブスクリプションURL全体、アクセストークン、ユーザー識別情報、パスワード、非公開のサーバー情報を隠してください。スクリーンショットにアドレス欄、QRコード、クリップボードのポップアップが写っていないかも確認します。エラーの種類、発生順、アウトバウンドの記録は残すと、問題がどの層で起きているか判断しやすくなります。ログにアクセス先が含まれる場合があるため、共有前にドメイン名がプライバシーに関わらないか確認してください。

まずプロキシを無効にし、現在のネットワークで通常どおりアクセスできることを確認します。次に、システム時刻とサブスクリプションの有効性を確認してください。1つのサーバーだけタイムアウトする場合は、同じサブスクリプション内の別の有効なサーバーに切り替え、特定サーバーの障害か比較します。すべてタイムアウトする場合は、信頼できる別のネットワークでも試し、ログの接続先とエラーが発生した段階を確認します。タイムアウトの原因には、名前解決、接続先ポートへの到達不可、通信パラメーターの不一致、サーバーからの応答停止などがあります。遅延テストが一度失敗しただけで結論を出さず、接続確認の代わりにサブスクリプション更新を繰り返さないでください。エラーの原文を控え、サービス提供元にサーバーの状態を確認しましょう。

接続済みという表示は、通常、コアが起動したか通信の取り込み機能が確立したことを示すだけで、目的のWebサイトに必ず接続できるという意味ではありません。Webページを開きながら、クライアントのログに新しいリクエストが記録されるか確認してください。記録がない場合は、ブラウザーがシステムプロキシに従っているか、プロキシのポートが一致しているか、独自のプロキシ設定を行う拡張機能がないかを調べます。記録はあるのに失敗する場合は、名前解決、接続タイムアウト、安全な接続のハンドシェイクのどこでエラーが起きたかを確認します。まず利用可能なデフォルトのルーティングとDNS設定に戻し、変更は一度に1つだけ行ってください。特定のサイトだけ失敗する場合は、そのサイトと関連ルールを調べ、クライアントの再インストールとネットワーク設定全体の変更を同時に行わないようにしましょう。

まず、そのアプリがシステムプロキシ設定を参照するか確認してください。一部のゲーム、コマンドラインツール、独自のネットワーク設定を持つアプリはシステムプロキシを使用しないため、スイッチを有効にしても強制的に経由させることはできません。アプリでプロキシを手動設定できる場合は、クライアントが実際に提供するHTTPまたはSOCKSの待ち受け方式に合わせて、ローカルアドレスとポートを入力してください。ポートを取り違えないようにしましょう。設定後にアプリを再起動し、ログでリクエストがコアに届いているか確認します。手動設定できないアプリでは、権限やネットワークの競合を確認したうえでTUNを試せます。組織の管理端末では管理ポリシーが適用される場合があります。既存のプロキシスクリプトや組織のネットワーク設定を上書きしないでください。

エラーの種類に応じて対処してください。タイムアウトの場合は、現在のネットワークとサブスクリプションのドメインにアクセスできるか確認します。更新方法で直接接続とプロキシ経由を選べる場合は、有効な接続を確保したうえで、それぞれ試してください。使えないサーバー経由で更新が繰り返し失敗するのを避けられます。認証エラーやアクセス拒否の場合は、サービス提供元のアカウントページで、有効期限とURLの変更有無を確認してください。解析エラーの場合は、取得した内容がログインページ、エラーページ、非対応形式のいずれかを確認します。User-Agentはサービス提供元から明確に指定された場合のみ設定してください。リクエスト頻度が高すぎると表示されたら、時間をおいて再試行します。短時間に更新を繰り返したり、サブスクリプションURL全体を見知らぬサイトに送って確認させたりしないでください。