プロキシ接続済みなのにインターネットへ接続できない：v2rayN・v2rayNGの徹底チェックリスト

まず「接続済み」がどの層を指すのか確認する

クライアントに実行中と表示されても、リモートノードとの通信が正常に完了したとは限りません。v2rayNがXrayまたはV2Flyコアを起動した場合に分かるのは、ローカルプロセスが動作し、設定ファイルの基本的な解析を通過したことだけです。v2rayNGの上部に鍵の状態が表示されたり、システムにVPN接続と表示されたりしても、Androidの通信取り込みサービスが確立したことを示すに過ぎません。リモートアドレスを解決できるか、ポートへ到達できるか、プロトコル設定が一致しているかは、実際の接続で確認する必要があります。

Webリクエストは通常、アプリ、ローカルプロキシの入口、ルーティングルール、プロキシの出口、リモートからの応答という順に進みます。どこか一つでも失敗すると、ブラウザが読み込み中のままになる、すぐに接続リセットと表示される、一部のサイトだけ開けないといった症状になります。クライアントのトレイアイコンの色が変わっただけでDNSを変更したり、ノードの利用可否を確認しないままルーティングモードを切り替え続けたりしないでください。

手順1：ノードの利用可否とシステム時刻を確認する

まずv2rayNのノード一覧で現在のノードを選択し、実接続遅延テストを実行します。通常のPingは対象ホストがICMPに応答するかを確認するだけで、VMess、VLESSなどのプロキシ接続でハンドシェイクまで完了できることは証明できません。実接続テストでは現在のコアを通じて実際に出口接続を確立するため、最初の切り分けに適しています。同じサブスクリプション内の複数ノードがすべてタイムアウトする場合は、まずサブスクリプションを更新し、アドレスとポートが異なる2つのノードで相互にテストしてください。

テスト時は具体的な数値を記録すると便利です。たとえばノードAの実接続遅延が186msで3回連続して応答し、ノードBが3回とも5000msを超えてタイムアウトするなら、まずノードAで次の項目を確認します。遅延が大きくても必ずしも使えないとは限りませんが、連続タイムアウト、接続拒否、ハンドシェイク直後の失敗は、通常ブラウザ設定を変更しても解決しません。

1. v2rayNのメイン画面でノードを選択し、Pingではなく実接続遅延テストを実行します。
2. サブスクリプション内のノードを少なくとも2つ切り替え、各テストの完了を待ちます。多数の接続を同時に開始しないでください。
3. 実行ログを開き、テスト時に新しい出口接続の記録が出ていることを確認します。過去の結果を読み取っているだけではないことが重要です。
4. v2rayNGで現在の設定のテスト機能をタップし、別のノードに切り替えてもう一度実行します。
5. Wi-Fiですべて失敗する場合は、別の利用可能なネットワークでテストし、ノード側の問題と現在のネットワーク制限を切り分けます。

システム時刻のずれも、時刻検証が必要な接続に影響します。Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、自動時刻設定を有効にして今すぐ同期します。Androidではシステムの日付と時刻の設定を開き、ネットワーク提供の時刻を有効にします。端末の時刻が標準時刻から数分ずれている場合は、先に補正してからクライアントのコアを完全に停止し、再起動してください。

手順2：DNS名前解決の障害を切り分ける

ノードテストは成功するのにドメインを入力するとWebページが待機し続ける場合、次にDNSを確認します。DNSはドメイン名を接続可能なアドレスへ変換します。プロキシの出口が正常でも、ローカルDNS、コアのDNS、システムのプライベートDNSの組み合わせまで正しいとは限りません。特にカスタム設定を読み込んだ場合、振り分けルールを変更した場合、暗号化DNSを有効にした場合は、ドメインの問い合わせが現在のネットワークに適さない出口へ送られることがあります。

v2rayN 7.xでは、「設定」→「パラメーター設定」から基本設定とDNS関連の項目を確認できます。カスタムDNS設定を使用している場合は、まず元の内容を保存し、その後クライアントの初期設定に戻して比較します。変更後はコアを再起動してください。ブラウザのタブを閉じるだけでは、コアは設定を再読み込みしません。Windowsではターミナルからシステム標準の問い合わせコマンドを実行し、端末で名前解決できるか確認できます。

nslookup example.com
ipconfig /flushdns

nslookupでアドレスが返っても、システムの問い合わせ経路に結果があることを示すだけで、コア内部が同じDNSを使っているとは限りません。システムの問い合わせは成功するのにv2rayNのログで名前解決失敗が続く場合は、コアのDNS設定とルーティングルールを確認します。システム側の問い合わせ自体がタイムアウトする場合は、ネットワークアダプターのDNSを自動取得に戻し、キャッシュを消去してから再テストしてください。

手順3：グローバルプロキシでルーティングルールの誤判定を除外する

ルーティングルールは、リクエストをプロキシ、直接接続、ブロックのどれに振り分けるかを決めます。カスタムルールのドメイン、IP範囲、ポート、入口タグの指定を誤ると、ノード自体は利用できるのに、特定のサイトやアプリだけ常にアクセスできない状態になります。ルールは通常、決められた順序で照合されます。範囲が広すぎる直接接続ルールが、後続のプロキシルールより先にリクエストを捕捉することもあります。

最も直接的な診断方法は、すぐにルールを削除することではなく、一時的にグローバルプロキシモードへ切り替えて同じドメインへアクセスすることです。グローバルプロキシでは開けるのに元のルーティングモードでは失敗するなら、原因を振り分け設定に絞れます。テスト後は元のモードに戻し、カスタムルールの対象と出口の動作を1行ずつ確認してください。

VMessとVLESSはノード接続用のプロトコルであり、ルーティングルールはどのリクエストをそのノードへ渡すかを決めるものです。両者を同じ項目として扱ってはいけません。プロトコルパラメータを変更しても、誤った直接接続ルールは直せません。反対に、グローバルプロキシへ切り替えても、誤ったユーザー識別子、トランスポート層のパラメータ、サーバーポートは修復できません。

手順4：v2rayNのシステムプロキシとローカルポートを確認する

Windows、macOS、Linuxのデスクトップアプリがプロキシ経路に入るかどうかは、アプリがシステムプロキシを読み取るか、独自プロキシが設定されているか、TUNが有効かによって決まります。v2rayNのコアが動作中なら、通常はSOCKSまたはHTTPの入口をローカルで待ち受けています。システムプロキシが実際の待受ポートを指していないと、ブラウザが直接インターネットへ接続したり、古いポートを指してページを開けなくなったりします。

v2rayNでまず「設定」→「パラメーター設定」を開き、ローカルのSOCKS、HTTP、混合入口のポートを確認します。一般的な設定ではSOCKS入口に127.0.0.1:10808、HTTP入口に127.0.0.1:10809を使用しますが、実際の値は現在の画面に従ってください。その後、トレイメニューからシステムプロキシの自動設定を選び、システムプロキシのアドレスがクライアントの現在のポートと一致しているか確認します。

• ローカルアドレスはまず127.0.0.1を確認し、リモートノードのアドレスをシステムプロキシに設定しないでください。
• ポートを変更した場合は、必ずコアを再起動し、システムプロキシ設定を再適用します。
• ブラウザに手動プロキシを設定している場合は、プロトコルとポートが一致しているか確認するか、一時的にシステムプロキシを使用する設定に変更します。
• コマンドラインプログラムはデスクトップのシステムプロキシを読み取るとは限りません。そのプログラムが対応するプロキシ環境変数や設定項目を確認してください。
• ポートが他のプロセスに使用されていると、コアの起動に失敗したり、該当する入口を作成できなかったりします。

手順5：v2rayNGのVPN取り込みと対象アプリを確認する

v2rayNGはAndroid上で通常、システムのVPNインターフェースを通じて通信を取り込みます。ステータスバーに接続マークが表示された後も、システムがサービスの実行を許可しているか、アプリごとのプロキシ、LANのバイパス、ルーティングモード、バッテリー管理の設定を確認する必要があります。特定のアプリだけアクセスできず、ブラウザは正常な場合、問題は通常ノードではなく、アプリごとの選択やアプリ自身のネットワークポリシーにあります。

まずv2rayNGの設定でローカルポートとルーティング項目を確認し、アプリごとのプロキシが有効か確認します。「選択したアプリのみプロキシ」を有効にしている場合、対象アプリが一覧に入っていなければなりません。反対に除外方式を有効にしている場合、対象アプリを除外一覧から外します。変更後は接続を切断し、数秒待ってから再接続して、システムにVPNルートを再構築させてください。

v2flyNGでV2Flyコアを使用する場合も、Androidの通信取り込みは同様の仕組みに従います。ただし、コアの対応範囲やログ内容は異なる場合があります。v2rayNG向けのXray専用設定をそのままv2flyNGへ適用しないでください。サブスクリプションに特定コア依存のパラメータが含まれる場合は、ノードの要件に合ったクライアントとコアを選択します。

最後に決めた順番で再テストし、ログを読む

各項目の確認が終わったら、同じテスト条件で再確認します。同じネットワーク、同じノード、同じドメイン、同じブラウザを使用してください。毎回テスト対象を変えると、ページが表示されるようになっても本当の原因を判断しにくくなります。ログウィンドウは開いたままにし、コアの起動時から確認するのがおすすめです。最後の赤いメッセージだけを切り取らないでください。

ログは時系列で読みます。まずローカル入口がリクエストを受信したかを確認し、次にどの出口がルーティングで選ばれたかを見て、最後に名前解決、接続、ハンドシェイク、リモート応答のどの段階で失敗したかを判断します。timeoutの1行は操作が期限を超えたことしか示しません。前後の行にある対象アドレス、出口タグ、DNS情報が対処方法を決めます。

1. システムプロキシを無効にするかAndroidのVPNを切断し、端末自体の基本ネットワークで通常のページへアクセスできることを確認します。
2. システム時刻を合わせ、サブスクリプションを更新し、実接続テストに成功したノードを選択します。
3. コアを起動した後にログを確認し、設定解析の失敗やローカルポートの占有がないことを確認します。
4. 一時的にグローバルプロキシで同じドメインをテストし、カスタムルーティングルールを除外します。
5. 初期DNSに戻して比較し、コアの再起動後にブラウザまたはシステムのDNSキャッシュを消去します。
6. デスクトップ版でシステムプロキシを再適用し、127.0.0.1と実際の待受ポートを確認します。
7. Android版でVPNを再確立し、アプリごとの対象範囲、プライベートDNS、バックグラウンド実行権限を確認します。
8. 復旧後は個別設定を一つずつ元に戻し、戻すたびに再テストします。