V2Rayは接続済みなのにサイトが開かない？原因を特定する10項目チェックリスト

1. まず基本のネットワークを確認する：認証画面と回線切断を切り分ける

まず、現在のノード名、プロキシモード、直近のエラーを控えます。次にTUNを一時的にオフにし、v2rayNのタスクトレイメニューで「システムプロキシ」→「システムプロキシを解除」を選択します。その状態で、通常なら直接アクセスできるサイトを開いてください。それでも失敗する場合は、サブスクリプションを何度も更新するのではなく、Wi-Fi、有線接続、ルーター、ネットワーク認証を確認します。

ホテル、学校、公共のネットワークでは、認証ページを開く必要がある場合があります。ネットワークアイコンに「接続済み」と表示されても、端末がローカルネットワークにつながっていることを示すだけです。認証を済ませてから、プロキシ接続を再テストしてください。以下の3つの手順で再現可能なテスト条件を整えます。以降の確認でも、同じブラウザーと同じURLを使います。

1. 現在の状態を記録

   ノード名、システムプロキシの状態、TUNのオン／オフ、テスト時刻を記録します。エラーのキーワードは控え、サブスクリプションURL全体は公開しないでください。

2. 直接接続を確認

   TUNをオフにし、「システムプロキシ」→「システムプロキシを解除」を選択します。直接アクセスできるサイトを開き、必要であれば先にネットワーク認証を済ませます。

3. テスト先を固定

   ノードを戻したら、URLを1つだけテストします。すぐにエラーになるのか、長時間応答を待つのか、画像だけ読み込めないのかを記録し、複数の条件を同時に切り替えないようにします。

2. システムプロキシを確認する：通信がv2rayNに届いているか

v2rayNのタスクトレイメニューに戻り、「システムプロキシ」→「システムプロキシを自動設定」を選択します。Windows 11では、「設定」→「ネットワークとインターネット」→「プロキシ」で、実際のプロキシアドレスとポートを確認できます。通常、ローカルプロキシのアドレスは127.0.0.1です。ポートはクライアントが現在待ち受けている値と一致させてください。古い画面の例をそのまま入力しないようにします。

システムプロキシの設定が反映されるのは、その設定に従うアプリが中心です。すべてのプログラムの通信が自動的に切り替わるわけではありません。まずTUNをオフにし、システムプロキシ経由の通信だけを確認します。ブラウザーでページを再読み込みしてもクライアントに該当する接続ログが出ない場合は、明示的にプロキシを指定するコマンドで、ブラウザーの設定を介さずにテストできます。以下の10808は、HTTPまたは混合待ち受けを有効にしている場合の例です。実行前に、実際のポート番号に置き換えてください。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

• コマンドに対象サイトのHTTPレスポンスが返る：今回のリクエストでは、ローカルプロキシから対象サイトまで通信できています。ブラウザーまたはシステムプロキシの設定を確認してください。
• ローカルポートへの接続エラーがすぐに表示される：3項目に進み、コアが待ち受けているか確認してください。
• プロキシトンネルの確立後にTLSエラーまたはタイムアウトが発生する：サイトにアクセスできたとは判断できません。接続先、DNS、証明書を続けて確認してください。

3. 待ち受けポートを確認する：未起動とポート競合を切り分ける

v2rayNは管理画面で、実際に通信を処理するのはコアのプロセスです。画面が開いていてもコアの起動に失敗していると、システムプロキシがサービスのないローカルポートを指している場合があります。「設定」→「パラメーター設定」でローカル待ち受け関連の項目を確認し、ログの待ち受けアドレスと照合します。項目名や既定のポートはバージョンによって異なります。

PowerShellで次のコマンドを実行します。1つ目で待ち受けポートとプロセスIDを調べ、2つ目で実際に取得したIDからプロセスを確認します。例の1234は固定値ではありません。ポート番号が同じという理由だけでプロセスを終了しないでください。正体の分からないシステムサービスを強制終了するのも避けてください。

Get-NetTCPConnection -LocalPort 10808 -State Listen
Get-Process -Id 1234

4. ノードとサブスクリプションを確認する：テスト結果だけでは実用性は分からない

ノード一覧に遅延時間が表示されても、プロキシ経路全体が正常とは限りません。TCP遅延で分かるのは、多くの場合、特定のアドレスとポートに接続できることだけです。実際の遅延テストの結果は、クライアントが使用するテスト先にも左右されます。まずノードを選択して有効にし、そのノード経由で実際の対象サイトにアクセスしてください。一覧の数値だけで判断しないようにします。

• 「サブスクリプショングループ」で該当するグループを選び、サブスクリプションを更新します。ノードのアドレスとポート、サービス提供元からのお知らせも確認してください。更新操作の表示名はバージョンによって若干異なる場合があります。
• アカウントの通信量、利用期限、端末数の制限、ノードのメンテナンス状況を確認します。サブスクリプションの更新に成功しても、取得した設定の接続先サービスが稼働中とは限りません。
• 同じサブスクリプション内の別のノードに切り替え、対象URLとルーティングモードは変えずにテストします。特定のノードだけ失敗する場合は、クライアントを再インストールするより、そのノードの状態を優先して確認してください。
• Androidでは、v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。設定のインポートに成功しても、コアがすべてのパラメーターに対応しているとは限りません。プロトコルとトランスポートの組み合わせを確認してください。

VMessとVLESSはプロキシプロトコル、REALITYは関連するセキュアトランスポート方式です。この3つを互いに排他的なノード種別として扱わないでください。パラメーターを手動で編集する前にバックアップします。特にVLESSとREALITYを組み合わせる設定では、サーバーアドレス、公開鍵、Short ID、サーバー名などをサーバー側の指定に合わせる必要があります。推測で値を補わないでください。

5. ルーティングによる振り分けを確認する：対象サイトの通信経路を特定する

一部のサイトだけ開けない場合は、まずルーティングを確認してください。システムプロキシはリクエストをローカルの入口に渡し、ルーティングルールはそのリクエストを直接接続、プロキシ経由、または遮断のいずれにするか決めます。これは別々の処理です。システムプロキシが有効でも、すべての通信がリモートノードに送られるとは限りません。

ルーティング設定の名称はバージョンやカスタム設定によって異なるため、実際のルールがどの接続先に振り分けるかを確認してください。詳しくはルーティング用語の解説をご覧ください。確認後は、普段の利用に適した設定に戻してください。一時的な比較用設定をそのまま使い続けないようにします。

6. DNSを確認する：ノードのドメインと接続先のドメインを区別する

DNSが関わるアドレスは、少なくとも2種類あります。クライアントがまずリモートサーバーを見つけるためのアドレスと、Webサイトのドメイン名を適切な場所で解決するためのアドレスです。前者に失敗すると、通常はノードに接続できません。後者に問題があると、ノードに遅延時間が表示されていてもサイトが開かないことがあります。IPアドレスが分かっても、名前解決が正しいとは限りません。また、ネットワークごとに異なるIPアドレスが返るだけでDNS汚染とは判断できません。コンテンツ配信ネットワークは、異なる結果を返すことがあります。

Resolve-DnsName example.com
ipconfig /flushdns
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

1つ目のコマンドでシステムの名前解決結果を確認し、2つ目でWindowsのDNSキャッシュを消去します。3つ目は、そのポートでSOCKS5または混合待ち受けが有効な場合にのみ使用してください。socks5hでは対象のホスト名をプロキシ側で処理するため、ローカルの名前解決経路との比較に使えます。ただし、コア内部のDNS設定やルーティング設定を回避できるとは限りません。

• システムの名前解決がタイムアウトする：ネットワークから割り当てられたDNSに到達できるか、現在のネットワークで特定の名前解決サービスが制限されていないか確認します。
• キャッシュを消去しても失敗する：ブラウザーのセキュアDNS、クライアントのDNS設定、コアのキャッシュも確認してください。システムキャッシュだけが原因とは限りません。
• プロキシ側の名前解決は成功し、ローカルの名前解決経路では失敗する：ローカルDNSの経路を重点的に確認します。DNSサービスを切り替えた後も、対象サイトに再アクセスして結果を確認してください。

7. システム時刻、TLS、SNIを確認する

証明書エラーは、どの段階で発生したかを確認する必要があります。ノードとのTLSハンドシェイクに失敗している場合もあれば、ブラウザーから対象サイトにアクセスした際に証明書エラーが返っている場合もあります。Windows 11では、「設定」→「時刻と言語」→「日付と時刻」を開き、自動時刻設定を有効にして「今すぐ同期」を実行します。証明書の検証には実際のシステム時刻が使われます。表示するタイムゾーンを変えるだけでは、時刻の同期になりません。

SNIにはサーバー側で指定された名前を設定します。接続先アドレスと同じとは限らず、有名なWebサイトのドメイン名を適当に設定してはいけません。allowInsecureを万能な修正スイッチとして使わないでください。証明書検証を回避すると、接続先の誤りや中間経路の問題を見逃すおそれがありますが、アカウント、ルーティング、トランスポートの問題は解決しません。

8. TUN、権限、仮想ネットワークアダプターの競合を確認する

明示的なプロキシ指定では通信できるのに、TUNを有効にすると端末全体がネットにつながらない場合は、仮想ネットワークアダプター、ルーティング、DNSの引き継ぎを確認します。TUNはシステムの通信経路を変更するため、通常は権限の昇格が必要です。ブラウザーにプロキシを設定するだけのテストで、TUNまで同時に有効にする必要はありません。

1. まずTUNをオフにし、2項目目の明示的なプロキシテストが成功することを確認します。仮想ネットワークアダプターを使わない場合の基準を作ります。
2. クライアントの案内に従い、ネットワークアダプターの作成とルーティングの変更に必要な権限を付与します。Windowsでは、v2rayNを終了して管理者として起動し、再度有効化してみてください。
3. 複数の仮想ネットワークアダプターが同時にデフォルトルートを書き換えないよう、ほかのVPNや通信制御ソフトを一時的に終了します。組織管理下の端末では、まず組織のネットワーク利用ルールに従ってください。
4. Get-NetAdapterでネットワークアダプターの状態を確認し、route printでルーティング情報を保存します。まず記録を残し、見慣れないルートをまとめて削除しないでください。

Android版のv2rayNGとv2flyNGは、システムのVPNサービスを使って選択したアプリの通信を処理します。接続の許可、アプリごとのプロキシ対象リスト、システム内に別のVPN接続がないかを確認してください。画面ロック後だけ通信が切れる場合は、バッテリー最適化とバックグラウンド実行の制限を調べます。バックグラウンドでアプリが終了しただけなのに、ノード障害と判断しないでください。デスクトップ版TUNの基本についてはTUNの使い方をご覧ください。

9. ブラウザー、アプリのプロキシ設定、ファイアウォールを確認する

明示的なプロキシテストは成功するのにブラウザーで失敗する場合は、アプリ側の設定の違いを確認します。ブラウザー拡張機能がシステムプロキシを上書きしていることもあれば、セキュアDNSが別の名前解決経路を選んでいることもあります。ターミナルのアプリはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを参照する場合もあります。シークレットウィンドウでも、拡張機能や組織のポリシーがすべて無効になるとは限りません。原因を特定する唯一の根拠にしないでください。

• プロキシ関連の拡張機能を一時的に無効にし、ブラウザーに手動プロキシ設定やポリシー設定がないか確認してから、ブラウザーを完全に終了し、再起動します。
• アプリに個別のプロキシを設定している場合は、HTTPとSOCKS5の種類が一致しているか確認します。同じポートで両方の接続を受け付けられるのは、混合待ち受けに対応している場合だけです。
• Get-ChildItem Env:*PROXY*を実行し、現在のPowerShellに設定されているプロキシ環境変数を確認します。古いポートが見つかった場合は、以前の設定だと確認できた項目だけを削除し、影響を受けるアプリを再起動してください。
• ファイアウォールやセキュリティソフトがコアのプログラムをブロックしていないか、記録を確認します。必要な場合はプログラムのパスを指定して許可ルールを作成してください。切り分けのために保護機能全体を長時間無効にしないでください。

特定のサイトでログインに失敗する、403が返る、または認証画面が表示される場合、少なくともサイト側から応答を受け取っています。「まったくネットにつながらない」状態とは分けて考えてください。出口IPの評価、地域制限、アカウントのリスク判定などが原因の可能性があるため、接続タイムアウトとは別に対処します。

10. ログで原因を絞り込む：変更は一度に1項目だけ

最初の9項目で原因を特定できない場合は、現在のログ表示をクリアして時刻を記録し、対象サイトへのリクエストを1回だけ実行します。必要であればログの詳細度を一時的に上げ、再現後に元へ戻してください。アクセスに関する情報が長時間記録され続けるのを防げます。失敗がどの段階で起きたか、ローカルへの接続、リモートへの接続、ハンドシェイク、対象サイトからの応答のどこで止まったかを確認します。

管理者に問い合わせる際は、OS、クライアントのバージョン、コアのバージョン、テスト時刻、ネットワークの種類、個人情報を伏せたエラーの抜粋を伝えてください。サブスクリプションのトークン、ユーザーID、パスワード、秘密鍵、機密性のあるアクセス記録は隠し、設定ファイル全体をそのまま送らないでください。クライアントを更新する場合は、先にノードとルーティング設定をバックアップし、クライアントのダウンロードページで対応するプラットフォームとアーキテクチャを選択してください。

よくある質問：テスト結果の見方