v2rayNは接続済みなのにWebサイトが開けない？8項目のトラブル対処チェックリスト

手順1：ノードの選択・コアの起動・リクエストの成功を切り分ける

v2rayNはGUIクライアントで、プロキシリクエストの処理には選択したコアが使われます。画面上でノードが選択されている、システムプロキシが設定済み、遅延テストに数値が表示されるといった状態だけでは、ブラウザーのHTTPSリクエストがノード経由で完了したとは限りません。TCP遅延テストで確認できるのは、通常、特定のアドレスとポートに到達できることまでです。認証、TLS、REALITY、最終的なWebサイトまでの経路全体を検証するものではありません。

まず、ネットワークを制御する他のプログラムを終了し、v2rayNのTUNモードを一時的にオフにして、「システムプロキシ＋ローカル入口」を基準にテストします。システムプロキシモードとTUNモードでは通信を取り込む範囲が異なり、同時に有効にするとルーティングやDNSの確認項目が増えます。企業プロキシや認証が必要なネットワークでは、先にネットワークへのログインを済ませてください。組織で必要な設定を安易に削除しないでください。

1. システムプロキシを一時的に解除し、普段直接アクセスできるWebサイトを開いて、インターネット接続自体が正常か確認します。
2. 調べるノードを選択して有効なサーバーに設定し、コアの起動ログに設定エラーや待ち受けエラーがないか確認します。
3. クライアントのバージョン、実際に使われているコアの名称とバージョン、テストするURLと時刻を記録します。以降の再テストでは同じ条件を使います。

システムプロキシを解除してもまったくインターネットに接続できない場合は、まずWi-Fi、ゲートウェイ、ネットワーク認証、システムDNSを確認します。この段階でVLESSやVMess、サブスクリプションのグループを切り替えても、基本的なネットワークの問題は通常解決しません。

手順2：システムプロキシのアドレスとローカル入口を確認する

v2rayNのタスクトレイメニューから「システムプロキシ」を開き、「システムプロキシを自動設定」を選択します。バージョンによって表示名が多少異なる場合があります。重要なのは、Windowsのプロキシサーバーのアドレスが、選択したノードではなく、実行中のローカル入口を指していることです。続いてWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートを確認します。

ここでの 10808 は例示用の値であり、すべてのバージョンで共通の既定値ではありません。「設定」→「パラメーター設定」でローカル待ち受けの項目を確認し、起動ログまたは実際の設定を基準にしてください。SOCKSとHTTPの入口を分けているバージョンもあれば、混合入口を使うバージョンもあります。Windowsの手動プロキシにはHTTPプロキシリクエストを受け付ける入口が必要です。SOCKS専用ポートを適当に指定しないでください。

• プロキシアドレスにはローカルのループバックアドレスを指定します。リモートノードのドメイン名やサブスクリプションURLは指定しません。
• ローカル入口のポートとノードサーバーのポートは別のものです。同じ番号である必要はありません。
• 自動構成スクリプトや手動プロキシに他のプログラムの設定が残っていないか確認し、ブラウザーが古いスクリプトを使い続けないようにします。
• コマンドラインツールや一部のアプリはWindowsのシステムプロキシに従いません。別途プロキシを指定する必要があるため、それだけでノードの故障とは判断できません。

手順3：ポートの待ち受けとプロセスの競合を確認する

システムプロキシの設定が正しくても、ローカルポートでサービスが待ち受けていなければWebサイトは開けません。PowerShellを起動し、次のコマンドを実行します。実際のポートが 10808 と異なる場合は、コマンド内の数字を置き換えてください。

netstat -ano | findstr ":10808"
Get-NetTCPConnection -LocalPort 10808 -State Listen

ローカルアドレス、LISTENING の状態、プロセスIDを確認します。待ち受けが見つからない場合は、まずコアが終了していないか確認してください。待ち受けが見つかった場合も、現在のv2rayNが起動したコアによるものか確認が必要です。タスクマネージャーの「詳細」タブでPIDを照合し、必要に応じて「コマンドライン」列を表示して実行ファイルのパスを確認します。

名称の分からないシステムプロセスをそのまま終了しないでください。ポート競合を解消したら、現在のコアを再起動して待ち受けを再確認します。コアがポートを正常に確保できていない状態でシステムプロキシだけを変更しても、問題は解決しません。

手順4：時刻を同期し、ノードのハンドシェイク設定を確認する

ローカル入口は正常なのに、すべてのリクエストが接続確立の段階で失敗する場合は、ノードの設定とデバイスの時刻を確認します。Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、自動時刻設定を有効にして「今すぐ同期」をクリックします。実際の日付と時刻を確認してください。タイムゾーン表示の変更だけでは、システム時刻が正確になったとは限りません。

サブスクリプションの更新に成功したのは設定を取得できたという意味にすぎません。ノードが現在も稼働していることや、使用中のコアがすべての項目に対応していることを示すものではありません。インポート後に項目が欠けている場合は、クライアントが実際に使用しているコアと設定形式を確認してから、設定の提供元に問い合わせてください。REALITYなどの機能は、該当するバージョンのXrayの対応範囲を確認してください。V2FlyとXrayを完全に同じコアとして扱うことはできません。

• 信頼できる設定元からノードを新たにインポートし、古い項目と比較して、手動編集による設定の抜けがないか確認します。
• 証明書の検証を無効にすることを一般的な解決策にしないでください。証明書エラーが出た場合は、まず時刻、サーバー名、サーバー証明書チェーンを確認します。
• 同じノードが別のデバイスで使える場合は、ノード名だけでなく、実際の設定とコアのバージョンを比較します。

手順5：DNSの問題とプロキシ経路の問題を切り分ける

「ドメイン名でサイトを開けない」からといって、必ずしもDNSの障害とは限りません。ノードのドメイン名の解決、直接接続する宛先のローカル解決、プロキシ経由の宛先の解決は、それぞれコアやアウトバウンド設定の影響を受けます。これらの処理で異なるDNSサーバーが使われることがあります。ブラウザーのセキュアDNS、WindowsのDNS、コアのDNSも、それぞれ別の設定です。

まずWindows標準の curl.exe でプロキシを明示し、ブラウザーの設定を介さずにテストします。以下のテストは15秒で打ち切ります。目的は応答とエラーが発生する段階の確認であり、特定のステータスコードを保証するものでも、速度測定でもありません。ポートはHTTPプロキシに対応した実際のローカル入口に置き換えてください。

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

Resolve-DnsName www.example.com

1つ目のコマンドで指定した入口経由のリクエストを確認します。2つ目のコマンドで確認できるのは、現在のWindowsの名前解決経路だけであり、コアのDNSが正常に動作している証明にはなりません。SOCKSのローカル解決とプロキシ側解決を比較する場合は、入口がSOCKSに対応していることを確認してから、次の2つのコマンドを実行します。

curl.exe -I --max-time 15 --socks5 127.0.0.1:10808 https://www.example.com/
curl.exe -I --max-time 15 --socks5-hostname 127.0.0.1:10808 https://www.example.com/

DNSを変更した後は、ipconfig /flushdns を実行してWindowsの名前解決キャッシュを削除し、ブラウザーとコアも再起動して、それぞれのキャッシュを除外します。HTTPSの接続先を安易にIPアドレスに置き換えてテストしないでください。証明書名、SNI、Webサイトの仮想ホストが変わり、別のエラーが発生する可能性があります。

手順6：ルーティングとデフォルトのアウトバウンドを確認する

明示的なプロキシテストでは同じノードが正常なのに、ブラウザーでは一部のドメインだけ失敗する場合、リクエストがルーティングによって直接接続またはブロック用のアウトバウンドに振り分けられている可能性があります。v2rayNのルーティング設定を開き、現在のルールセット、照合順序、デフォルトのアウトバウンドを確認します。メニューの場所はバージョンによって異なるため、画面上の「ルーティング設定」またはルート設定の項目を探してください。

1. 現在のルーティング設定名を記録し、カスタムルールを先にバックアップします。
2. 一時的に、対象のリクエストをプロキシ側のアウトバウンドへ送るルーティングモードを選び、同じURLで再テストします。「システムプロキシを自動設定」しても、すべてのリクエストがプロキシ経由になるわけではありません。
3. 正常に戻った場合は元のルールに戻り、ドメインルール、IPルール、ブロック項目、フォールバック先のアウトバウンドを確認します。
4. カスタムルールは一度に1グループずつ戻し、失敗が再現するまで確認します。該当するルールを特定してから変更してください。

ドメイン解決ポリシーも、名前解決を行うタイミングに影響します。AsIs、IPIfNonMatch、IPOnDemandでは解決のタイミングが異なり、「積極的に解決するほど安定する」という意味ではありません。IPルールの照合に解決結果が必要な場合、DNSの応答がアウトバウンドの選択に使われます。名前解決のエラーと広すぎるルールが重なり、リクエストが誤った経路に送られることもあります。

手順7：ブラウザー拡張機能と個別のプロキシ設定を確認する

明示的にプロキシを指定した curl.exe では接続先サイトから応答があり、ブラウザーだけ失敗する場合は、ブラウザー側を重点的に確認します。まず一時的なブラウザープロファイルで同じURLを開いてみましょう。閲覧履歴をすべて削除するより、現在の状態を保ちやすくなります。プライベートブラウジングでも完全にクリーンな状態とは限らず、一部の拡張機能は使用を許可できます。

• プロキシ拡張機能：プロキシ切り替え拡張機能を一時的に無効にし、Windowsのシステムプロキシを上書きしたり、古いポートを使い続けたりしないようにします。
• 個別のプロキシ設定：Firefoxでは「設定」→「一般」→「ネットワーク設定」→「設定」を開き、無効な手動プロキシが指定されていないか確認します。
• セキュアDNS：現在のモードを記録し、システムの名前解決経路を使ったテストと一時的に比較します。コアとブラウザーのDNSを同時に変更しないでください。
• キャッシュと接続：ブラウザーのプロセスを完全に終了してから再起動します。タブを再読み込みするだけでは、以前の接続やキャッシュされた結果が再利用されることがあります。
• セキュリティソフト：コアの実行ファイルやローカルプロキシ接続がブロックされていないか確認します。まずログを確認し、必要な通信だけを許可してください。保護機能を無効にしたままにしないでください。

特定のWebサイトだけ失敗する場合は、ほかのHTTPSサイトと比較してください。サイト側の障害、アカウントのアクセス制限、接続元アドレスの制限、証明書の問題でも「開けない」状態になります。1つのサイトだけでノード全体の状態を判断しないでください。WebサイトからHTTPエラーステータスが返ってきた場合、少なくともそのリクエストは応答を返せるサーバーまたは中間層まで到達したことを通常示します。

手順8：時刻とログを照合し、ネットワークを比較する

ログを使った詳しい調査は最後に行います。まずWebページを開いた時刻を記録し、その前後のコア出力を確認します。通常の利用では warning のままで構いません。トラブル対処では一時的に info に上げ、必要な場合のみ短時間 debug を使用します。ログレベルを上げると接続先のドメイン名や接続情報が記録されることがあります。調査後は元の設定に戻してください。

次の比較では条件を1つだけ変えます。同じPCと同じノードでスマートフォンのテザリングに切り替えるか、同じネットワークで正常に動作すると確認済みの別ノードを使います。前者は元のネットワークによる制限、後者はノードの稼働状況の判断に役立ちます。ネットワーク、プロトコル、DNS、コアを同時に切り替えると、復旧してもどの変更が効いたのか分からなくなります。