v2rayNGのよくある質問

Windows、macOS、Linuxではv2rayN、Androidでは通常、Xrayコアを使用するv2rayNGが選択肢になります。V2Flyコアを使うv2flyNGも代替クライアントですが、適合するかどうかはサブスクリプションが提供するプロトコルとトランスポートの組み合わせによります。アプリ名だけで互換性を判断せず、ノードの要件とクライアントが実際に対応する設定項目を確認してください。現在の設定で接続できている場合は、元のクライアントを残したまま別のクライアントを試しましょう。クライアント間で設定をそのまま復元できるとは限りません。

クライアントは設定の読み込み、コアの実行、通信の転送を担います。インストールしただけでは、接続先のサービスを利用できる状態にはなりません。有効なサブスクリプションURL、ノードの共有リンク、またはサーバー側の完全な接続情報が必要です。設定の入手元と利用権限を確認してからノードを追加し、使用する設定を選んでください。サブスクリプションには個人の認証情報が含まれる場合があるため、URLを公開の掲示板などに投稿しないでください。問い合わせ時はプロトコル、トランスポート、エラーの種類を伝えつつ、URL内のトークンやユーザー識別情報などの認証情報は伏せてください。

プロトコルは、VMessやVLESSのようにクライアントとサーバーがプロキシデータをやり取りする方法です。トランスポートは、TCPやWebSocketのようにデータを運ぶ仕組みです。コアは設定を解析して接続を確立する実行プログラムを指します。REALITYはセキュアな通信に関わる仕組みで、あらゆるノード設定の代わりになる汎用オプションではありません。同じプロトコルでも、トランスポートやセキュリティ設定が異なる場合があります。追加後はプロトコル、ポート、トランスポート、セキュリティ設定、サーバー名をあわせて確認してください。プロトコル名だけを別のものに変えても、接続できるとは限りません。

それぞれ役割が異なります。システムプロキシは、システム設定に従うアプリにプロキシの接続先を提供します。ルーティングは、コアに入った接続をどのアウトバウンドへ送るかを決定します。TUNは仮想ネットワークインターフェースで通信を取り込み、通常はシステムプロキシより広い範囲をカバーしますが、ルーティング、権限、アプリの設定にも左右されます。システムプロキシを有効にしても、すべてのアプリがプロキシを使うわけではありません。TUNを有効にしても、すべての接続がプロキシ経由になるわけではありません。初期設定では、まずどちらか一方の方式で接続を確認し、その後必要に応じてルーティングやTUNを調整してください。

比較的新しいAndroidスマートフォンの多くではarm64版を選べますが、最終的には端末が対応するアプリのアーキテクチャを確認してください。購入時期だけでは判断できません。universal版は複数のアーキテクチャに対応するため、通常はファイルサイズが大きく、端末のアーキテクチャがわからない場合に試せます。ただし、Androidの最低システム要件を回避するものではありません。インストール時に解析エラーや非互換の表示が出た場合は、ファイルが完全にダウンロードされていることと、OSのバージョンが要件を満たしていることを確認してから、アーキテクチャを調べてください。既存アプリに上書きインストールできない場合は、パッケージ名と署名元も確認します。アンインストールする前に設定をバックアップし、サブスクリプショングループやカスタムルールの消失を防いでください。

入力したものがサブスクリプションURLなのか、単一ノードの共有リンクなのかを確認してください。サブスクリプションURLはグループに登録し、ノードリンクはクライアントに応じたインポート機能から追加します。コピー時に前後の空白、改行、チャットアプリが付けた句読点を取り除き、説明ページのURLをサブスクリプションURLとして登録しないようにしてください。グループを保存した後、サブスクリプションを更新するとノード一覧が作成されます。形式を認識できない場合は、提供元の形式が現在のクライアントに対応しているか確認します。ブラウザーでURLを開けても、ノード設定が返されるとは限りません。ログインページやエラーページが表示されている可能性もあります。

サブスクリプションの更新とノードへの接続では、アクセスする宛先が異なります。そのため、登録済みノードで接続できても、サブスクリプションURLにアクセスできるとは限りません。まず既存のノードを残し、グループをすぐに削除しないでください。URLが変更されていないか、認証情報の有効期限が切れていないか、クライアントのログにステータスコードや解析エラーが記録されていないかを確認します。クライアントによっては、直接更新する方法とプロキシ経由で更新する方法を選べます。接続できるノードがある場合は、両方を比較してみてください。認証エラーが返る場合は提供元に利用権限を確認し、Webページが返る場合は同じURLを繰り返し追加するのではなく、ログインページへリダイレクトされていないか確認してください。

デスクトップ版のTUNは仮想ネットワークインターフェースの作成とルートの変更を行うため、クライアントの案内に従って必要な権限を付与してください。Windowsでは管理者権限や関連サービスが必要か確認し、ほかのデスクトップOSではそれぞれの権限付与手順を確認します。Androidで初めてローカルVPN接続を作成するときは、システムの接続要求を許可してください。ほかのVPNアプリが接続を使用中の場合は、競合する接続を停止してから再試行します。端末の管理ポリシーによる制限がある場合、システム設定を無理に変更しないでください。権限を付与しても失敗する場合は、ノードを次々に切り替えるのではなく、仮想インターフェースやサービスの起動エラーを確認してください。

システムプロキシの影響を受けるのは、主にその設定を参照するアプリです。独自のネットワーク設定を使うアプリや、システムプロキシを自動的に経由しない種類の通信もあります。まずブラウザーで現在のプロキシ接続を確認し、対象アプリにプロキシアドレスを個別に設定する必要があるか調べてください。アドレスとポートはクライアントの現在のローカル待ち受け設定を確認し、別の端末の値をそのまま使わないでください。アプリがHTTPプロキシとSOCKSプロキシのどちらを必要としているかも確認します。より多くのアプリの通信を取り込む必要がある場合はTUNを検討し、対象の通信がルーティングで直接接続に設定されていないか確認してください。

まず現在のメニューが、システムプロキシによる通信の取り込み方法を設定するものなのか、コアのルーティングプリセットを設定するものなのかを確認してください。両者は別の設定です。ルーティングプリセットのグローバルプロキシは通常、コアに入ったより多くの接続をプロキシ経由にします。「中国本土を除外」する設定は通常、ドメインやアドレスのルールに基づき、中国本土に関連する宛先を直接接続にします。詳しくはプリセットの内容を確認してください。どちらの設定も、クライアントに取り込まれていない通信を自動的に処理するものではありません。普段は用途に合った分岐プリセットを選び、特定のサイトを調べるときだけ一時的にグローバルルールと比較してください。確認後は元の設定に戻し、DNSと複数のルートを同時に変更しないようにします。

カスタムルールが、より広い条件に一致するルールより前にあるか、ルールで指定したアウトバウンドのタグが実際に存在するかを確認してください。ルーティングは通常、上から順に判定されます。先に一致したルールが適用されると、後続のルールはその接続を処理しません。次に、クライアントが取得しているのがドメイン名かIPアドレスかを確認します。ドメインルールは、IPアドレスだけの接続には常に一致するとは限らず、DNSの名前解決を行う場所もアドレス判定に影響します。設定を変更したら適用し、対象アプリの既存接続を終了してからテストしてください。長時間接続は変更前の経路を使い続けることがあるため、それだけで新しいルールが効いていないと判断しないでください。

サブスクリプショングループ、手動で追加したノード、カスタムルーティング、DNS設定、アプリごとの振り分け設定を優先して保存し、現在使用中のプロキシモードも記録しておきましょう。クライアントに設定のエクスポート機能がある場合は、バックアップに利用できます。バックアップには認証情報が含まれる場合があるため、管理された場所に保管し、公開アップロードしないでください。更新後は、まず元の設定を正常に読み込めることを確認してから、古いファイルを整理します。別のクライアントへ移行する場合は、対応するサブスクリプションや共有リンクから再インポートし、ローカル設定を一つずつ作り直してください。項目の違いで起動に失敗するおそれがあるため、設定フォルダー全体をそのまま上書きしないでください。

まず端末の基本的なネットワーク接続を確認し、次にシステムの日付と時刻が自動同期されているかを確認します。その後サブスクリプションを更新し、ノード設定が期限切れになっていないか、変更されていないかを確認してください。ノードを一つ選んでテストし、同じネットワーク上で接続確認済みの別設定と比較します。すべての問題をクライアントのせいにしないようにしましょう。続いてプロトコル、ポート、サーバー名、セキュリティ関連のトランスポート設定を確認し、最後にDNS、接続タイムアウト、ハンドシェイクエラーなどのログを確認します。遅延テストが一度失敗しただけでは、ノードが使えないとは限りません。実際の通信もあわせて判断してください。すべてのノードで同時に失敗する場合は、まずローカルネットワークと通信の取り込み設定を確認します。

接続済みの表示は、ローカルサービスやVPNトンネルが起動したことを示すだけで、リモートへのリクエストが成功したとは限りません。まず使用するノードが正しいか確認し、次にブラウザーの通信がクライアントに取り込まれているか調べます。ログに該当するアクセス記録があるかも確認してください。記録がない場合は、システムプロキシ、アプリ独自のプロキシ、TUNの取り込み範囲を確認します。記録はあるものの名前解決エラーが出る場合は、DNSを調べてください。ハンドシェイクやリモート接続のエラーが出る場合は、ノードの設定とサービスの稼働状況を確認します。一度に変更する設定は一つにし、同じ宛先で繰り返しテストしてください。複数の設定を同時に変えると、原因がわかりにくくなります。

まずコアが正常に起動していることと、ローカルの待ち受けポートがほかのプログラムに使用されていないことを確認します。次にOSのプロキシ設定が、現在のクライアントのアドレスとポートを指しているか確認してください。ブラウザー拡張機能、別のプロキシクライアント、端末の管理ポリシーがシステム設定を上書きしている場合があります。一つずつ原因を調べ、複数のプログラムから同時にプロキシ設定を書き込まないようにしてください。ブラウザーを終了して再起動してからテストし、クライアントにリクエストが届いているかも確認します。クライアントを停止するとネットワークが使えなくなる場合は、終了したクライアントのポートを指すプロキシ設定が残っていないか確認し、システムプロキシの解除機能を使うか、OSの設定から元の状態に戻してください。

DNSエラーの場合は、基本的なネットワーク接続、DNSサーバーへの到達性、名前解決のリクエストが直接接続とプロキシ経由のどちらで送られるかを確認してください。特定のドメインだけで問題が起きる場合は、該当する分岐ルールも確認します。TLSハンドシェイクに失敗する場合は、システム時刻、サーバー名、証明書関連の設定、ノードのセキュリティ付きトランスポート設定を優先して確認してください。すぐにDNSの問題だと決めつけないでください。証明書検証の無効化を一般的な解決策として使わないようにしましょう。ログを共有して相談する際は、エラーの種類と前後の関連行を残し、サブスクリプションURL、認証情報、個人がアクセスするドメインを伏せてください。設定全体を共有する場合も、事前に機密情報を削除してください。