V2Rayのよくある質問
インストール・サブスクリプション・接続のトラブル対処

V2Rayは一般に、Project Vのエコシステムに属するプロキシコアや関連プロジェクトを指します。V2Flyはこのコアの系譜を引き継ぎ、Xrayは別の派生プロジェクトです。一方、v2rayNは設定のインポートやサーバーの選択、ルーティング設定を行い、コアを呼び出すGUIクライアントです。画面上でリンクをインポートできても、そのコアがすべてのパラメーターに対応しているとは限りません。互換性を確認する際は、クライアントのバージョン、実際に使用するコアとそのバージョンを記録し、プロトコル、トランスポート、安全性の設定を照合してください。

Windows、macOS、Linuxのデスクトップでは、まずv2rayNを検討し、OSとプロセッサーに合ったインストーラーを選びましょう。Androidでは通常v2rayNGを使います。V2Flyコア向けの設定が必要な場合は、v2flyNGも候補になります。選ぶ基準はクライアント名の似ているかどうかではなく、利用する設定への対応状況です。特に、Xray固有の機能に依存する設定がV2Flyでも使えるとは限りません。クライアントを切り替える前に必要な設定をエクスポートし、サブスクリプションの提供元が案内する対応クライアントと形式も確認してください。

クライアントは設定管理や接続のためのもので、インストールしただけで利用可能なサーバーが自動生成されるわけではありません。自分で管理するもの、または利用許可を得た共有リンク、設定ファイル、サブスクリプションURLをインポートしてください。共有リンクは通常、個別の設定を表します。サブスクリプションURLは更新可能な設定一覧の取得に使います。受け取った情報の種類を確認し、対応するインポート画面から追加しましょう。サブスクリプションURLをサーバーアドレスとして入力しても、有効な設定は取得できません。URLにアクセス情報が含まれる場合があるため、公開スクリーンショットや掲示板に載せないでください。

いいえ。VLESSはプロキシプロトコル、REALITYはXrayが提供するトランスポートの安全性を高める仕組みです。組み合わせて使うもので、どちらか一方を選ぶものではありません。設定にはトランスポートの種類、サーバー名、公開鍵、フィンガープリント、shortIdなどが含まれる場合があり、サーバー側の指定に合わせる必要があります。プロトコルの選択欄をVLESSに変えるだけで変換できたと考えたり、通常のTLS設定を安易にREALITYへ変更したりしないでください。種類は共有リンク全体とサーバー側の説明に基づいて選び、コアによる違いはプロトコルのドキュメントで確認しましょう。

比較的新しいAndroidスマートフォンなら、まずarm64版を選ぶとよいでしょう。インストーラーのサイズも小さめです。universal版は複数のアーキテクチャに対応しているため、端末のアーキテクチャがわからない場合に適しています。ただし、プロセッサーが64ビット対応でも、OSが必ず64ビット環境で動作するとは限らず、古い端末では汎用版が必要な場合もあります。arm64版が端末に対応していないと表示されたら、システムのアーキテクチャを確認してuniversal版を試してください。インストーラーを開けない原因は、OSのバージョン、ダウンロードの未完了、署名の競合などの場合もあり、すべてをアーキテクチャの問題と決めつけないようにしましょう。

入力したものがアカウントページや説明ページ、個別の共有リンクではなく、サブスクリプション用のURLか確認してください。コピー時に空白が入ったり、クエリパラメーターが欠けたりしていないかもチェックします。v2rayNではサブスクリプショングループを保存した後、「サブスクリプションを更新」を実行する必要があります。v2rayNGでもサブスクリプションの更新操作を行ってください。その後、更新メッセージとログを確認し、リクエストの失敗と解析の失敗を切り分けます。前者は接続経路やURLの有効期限、後者は応答形式を確認してください。項目があるのに一覧に表示されない場合は、選択中のグループによる絞り込みで非表示になっていないか確認しましょう。

リンク全体をコピーし直し、できるだけプレーンテキストのソースを使いましょう。チャットアプリによる改行、途中の省略、全角句読点の付加に注意してください。リンクの種類がクライアントのバージョンに対応しているか、特に新しいトランスポートパラメーターを含む設定かを確認します。サブスクリプションURLはサブスクリプション管理画面に登録し、共有リンクのインポートと混同しないでください。パラメーター不足のエラーが出た場合は、公開鍵やユーザー識別子を推測で補わず、設定の提供元に完全な原文を問い合わせましょう。手動で入力する場合は、プロトコル、ポート、トランスポート、安全性の設定を一つずつ照合し、インポート後に接続をテストしてください。

デスクトップでは、仮想ネットワークインターフェースの作成やルートの変更に高い権限が必要なことがあります。利用中のOSとクライアントの手順に従って権限を許可してください。Windowsでは、プログラムの入手元を確認したうえで、管理者として実行する方法もあります。ルートやインターフェースの競合を避けるため、ネットワークを制御しているほかのトンネルツールは終了しましょう。Androidでは、システムのVPN接続許可を承認し、ほかのVPNが動作していないか確認してください。セキュリティ機能を無効にすることを通常の手順にしないでください。解決しない場合はログでインターフェース、ドライバー、ルートに関するエラーを特定し、原因に応じて対処します。

システムプロキシは、OSのプロキシ設定に従うアプリを対象とします。TUNはネットワーク層で対象の通信を取り込むため、システムプロキシを参照しないアプリにも利用できます。ルーティングルールは、コアに渡された接続の送信先を決めます。それぞれ異なる段階を担当します。最初はシステムプロキシでブラウザーの接続を確認し、必要に応じてTUNを有効にしましょう。一度に複数の条件を変えないことが大切です。TUNを有効にした後もDNSとルーティングルールを確認してください。通信を取り込むことと、すべての通信をプロキシ経由にすることは同じではありません。OSによってメニューや動作が異なる点にも注意しましょう。

まずテストの種類を確認します。TCP接続テストでわかるのはポートへの接続状況です。実際のリクエストテストでは、プロトコルのハンドシェイクや接続先へのアクセスも関係します。ダウンロードテストの結果は回線速度やテスト対象にも左右されます。テストに成功しても、すべてのWebサイトが利用できるとは限りません。1回タイムアウトしただけで設定が無効だと判断するのも早計です。同じサーバー、ルート、接続先で条件をそろえて繰り返し確認し、コアのログと照合しましょう。ブラウザーのプロキシ拡張機能、セキュアDNS、キャッシュによって、クライアントのテストとは異なる経路を使っている可能性もあります。

自動更新に対応するクライアントで対象のサブスクリプショングループの自動更新を有効にし、適切な間隔を設定して、実際に更新が完了するか確認してください。アプリを終了している場合や、スマートフォンのバックグラウンド動作が制限されている場合は、予定どおりに更新されないことがあります。サブスクリプションの項目は通常、リモートの内容から再生成されるため、直接編集した内容は次回の更新で上書きされる可能性があります。長く使うカスタム設定は別の手動グループにコピーし、配信元を区別しましょう。サブスクリプションの認証情報が変わった場合はURLを更新してください。古いURLを繰り返し更新しても、認証エラーは解消しません。

異なるOS間でフォルダー全体を上書きすることはおすすめしません。クライアントによってデータベース、ファイルパス、インターフェース名、ルーティング設定が異なり、同じサブスクリプションでも特定のクライアント向けの内容が返される場合があります。各端末で対応するサブスクリプションを登録するか、クライアントのインポート・エクスポート機能で必要な設定だけ移行してください。システムプロキシ、TUN、DNS、アプリごとの振り分けは移行先の端末で再確認します。バックアップにサーバーの認証情報やサブスクリプションのトークンが含まれる場合があるため、安全な場所に保管してください。同期後は個別に動作を確認してから、元の設定を置き換えましょう。

コアが起動したことと、接続先にアクセスできることは別です。まずサーバーを選択しているか確認し、ブラウザーがシステムプロキシを使っているか、クライアントのプロキシモードが適切か、ローカルの待ち受けポートが競合していないかをチェックします。次にブラウザーのプロキシ拡張機能を一時的に無効にして同じ接続先を試し、コアのログで接続エラーやDNSエラーを確認してください。一部のWebサイトだけで起きる場合は、ルーティングルールとブラウザーのセキュアDNSも確認します。原因を見失わないよう、設定を元に戻せる状態にして、一度に一つずつ変更してください。

まず端末自体がインターネットに接続できることを確認し、サーバーアドレス、ポート、サブスクリプションの有効期限を照合します。システムの時刻を自動設定にし、使用中のコアが必要な設定に対応しているか確認したうえで、トランスポート、安全性の種類、サーバー名などをチェックしてください。ログを確認し、名前解決の失敗、接続タイムアウト、ハンドシェイクの失敗を区別します。対処方法はそれぞれ異なります。設定が1つだけ失敗するなら、提供元にサーバーの稼働状況を問い合わせましょう。複数の設定で同時に失敗する場合は、ローカルネットワーク、プロキシの経路、ファイアウォールルールを優先して調べてください。エラーを回避するために証明書検証を安易に無効にしないでください。

システムプロキシはすべてのアプリを対象にするわけではありません。独自のネットワークスタックを使うアプリや、個別にプロキシ設定を保持するアプリもあります。まずシステムプロキシに従うブラウザーで動作を確認し、対象アプリにHTTPまたはSOCKSプロキシの設定項目があるか調べてください。設定がある場合は、クライアントの待ち受け方式とポートに合わせて入力します。ブラウザー拡張機能、企業ポリシー、ほかのプロキシツールがシステム設定を上書きしていることもあります。ネットワーク層での制御が必要な場合はTUNを検討し、迂回ルールの有無も確認しましょう。アプリがプロキシ設定を参照するかどうかは、待ち受けアドレスをLANに広げても解決しません。

登録済みの設定で接続できるのは、現在のサーバーが動作していることを示すだけです。サブスクリプション用URLへの接続経路、認証、応答形式に問題が残っている可能性があります。まず更新時のメッセージを確認しましょう。認証エラーならサブスクリプションの認証情報、タイムアウトならURLへの到達性、解析エラーなら応答内容がクライアント対応の形式かを確認します。クライアントが直接更新とプロキシ経由の更新に対応している場合は、利用可能なサーバー設定を残したまま、それぞれ試してください。プロキシが実際に動作していることも確認します。最初にすべての設定を削除せず、失敗した時刻と個人情報を伏せたエラー内容を記録すると、原因を特定しやすくなります。