v2rayNは接続済みなのにWebサイトが開けない：macOS・Windowsの原因と対処法

ノードの選択とリクエストの接続を切り分ける

v2rayNでサーバーを選択しても、ブラウザーの通信がプロキシ経由になるとは限りません。ノード一覧の遅延時間は特定のタイミングでの測定結果にすぎず、現在のサイトの名前解決、TLSハンドシェイク、ページ内リソースの取得まで保証するものではありません。調査を始める前に、重複して起動しているプロキシクライアントを終了し、TUNは使わず、システムプロキシだけを入口として確認します。

現在のノード、システムプロキシの状態、ルーティングモード、ローカルの待ち受けポートを記録します。クライアントのログを開いてから、決めたURLに一度アクセスしてください。該当する通信がログにまったく出ない場合は、まず入口を確認します。対象ドメインや接続先のエラーが記録されている場合は、後半の通信経路を調べます。ログの詳細度によって表示内容は変わるため、記録が空白だからといって、ブラウザーからリクエストが送信されていないとは限りません。

• すべてのサイトに接続できない：まずローカルの待ち受けとシステムプロキシを確認します。ポートを変更した直後や、クライアントを終了した後は特に注意してください。
• 一部のサイトだけ接続できない：ドメインを記録し、ルールの適用結果、DNSの応答、サイト側の状態を重点的に確認します。
• ブラウザーは使えるのに、ほかのアプリは使えない：そのアプリがシステムプロキシに対応しているかを確認し、すぐにノードの異常と判断しないでください。

手順1：システムプロキシが現在のポートを参照しているか確認

v2rayNのメイン画面またはトレイメニューから「システムプロキシ」を開き、「システムプロキシを自動設定」を選択します。「システムプロキシをクリア」は関連する設定を削除し、「システムプロキシを変更しない」は現在の設定を維持します。後者はプロキシが有効になっているという意味ではありません。メニューの位置はバージョンによって異なるため、アイコンの色だけで判断せず、メニュー名を確認してください。

ローカルプロキシのアドレスには通常 127.0.0.1 を指定し、ポートには現在のクライアント設定の値を使います。「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートとプロトコルの種類を確認してください。プロバイダーのサーバー側ポートをシステムプロキシに指定したり、SOCKS専用ポートをHTTPプロキシ欄に入力したりしないでください。

手順2：ローカルポートが実際に待ち受けているか確認

ここでは確認手順の例として 10808 を使います。すべてのバージョンで共通のポートではありません。クライアント設定でHTTPまたは混合待ち受けと明記されている場合に限り、後述のHTTPプロキシテストを実行してください。設定が異なる場合は、コマンド内のポートを実際の値に置き換えます。

macOSのターミナルで確認

lsof -nP -iTCP:10808 -sTCP:LISTEN
curl -I --max-time 15 --proxy http://127.0.0.1:10808 https://example.com/

Windows PowerShellで確認

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

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

Windowsでは curl.exe を明示して、古いPowerShellで curl が別のコマンドとして解釈されるのを防ぎます。待ち受けプロセスが見つかったら、プロセスIDを使って「タスクマネージャー」で名前を確認してください。macOSでは lsof の出力からプロセスを確認します。別のプロセスがポートを使用している場合は、用途を特定してから、重複するクライアントを終了するか待ち受けポートを変更してください。見覚えのないシステムプロセスをそのまま終了しないでください。

手順3：ルーティングの適用結果を確認し、全般モードを解決策にしない

システムプロキシはリクエストの最初の転送先を決め、ルーティングルールが直結、プロキシ経由、ブロックのどれにするかを決めます。「日本国内のサイトは開けるが、ほかのサイトは開けない」場合、直結する通信だけが正常な可能性があります。「特定のドメインだけ開けない」場合は、意図せず直結またはブロックのルールが適用されていないか確認してください。

1. 現在のルーティングモードを記録し、自分で追加したルールをバックアップします。
2. v2rayNの「ルーティング」メニューで現在の設定を確認します。ルールを確認する場合は、「設定」からルーティング設定を開いてください。メニュー名はインストールしたバージョンによって異なります。
3. テスト対象のリクエストがプロキシに送られる全般ルーティングモードを一時的に選び、ノードとテストURLは変更しません。
4. アクセスが復旧した場合は元のモードに戻し、対象ドメイン、ドメイン末尾のルール、ルールの順序を確認して、修正後に再テストします。

全般ルーティングが処理するのは、クライアントに届いたリクエストだけです。システムプロキシを利用しないアプリを自動的に接続するものではありません。また、ルールをすべて削除しないでください。社内ネットワーク、会社のサービス、ローカルデバイスで直結が必要な場合があります。障害が起きているドメインに関係するルールだけを一度に1つ変更すると、再現可能な結果を得やすくなります。

手順4：DNSのどこで失敗しているか切り分ける

DNSの障害には少なくとも2種類あります。ノードサーバーのアドレスを名前解決できない場合と、接続先サイトのドメインを名前解決できない場合です。前者ではプロキシからの接続自体が失敗し、後者では一部のサイトだけに影響することがあります。まずログでエラーが発生したドメインを特定し、システムの名前解決、コアのDNS、ブラウザーのセキュアDNSのどれを確認するか判断してください。

macOSでは、次のコマンドで現在のシステムの名前解決結果を確認できます。確認できるのはシステムのリゾルバーの状態だけであり、コアのDNSやプロキシ側での名前解決の確認には代用できません。

dscacheutil -q host -a name example.com

Windows PowerShellでも同じドメインを確認できます。システムDNSを修正した後、古いキャッシュを消去する必要があれば2つ目のコマンドを実行してください。権限が必要な場合は、システムの指示に従います。

Resolve-DnsName example.com
ipconfig /flushdns

• 特定のブラウザーだけ失敗する：そのブラウザーの「セキュアDNS」または「HTTPS経由のDNS」設定を一時的に無効にして比較します。テスト後、設定を戻すかどうか判断してください。
• SOCKSでテストする場合：socks5:// と socks5h:// では、ドメインを解決する場所が異なります。curlの socks5h:// は対象ドメインの解決をプロキシに任せます。
• DNSを変更しても解決しない：DNSリクエスト自体のルーティングを確認してください。接続できていないプロキシを経由しないと到達できないDNSサーバーを使うと、依存関係の問題が起きることがあります。

手順5：ノード設定とシステム時刻を確認

ローカルの入口が正常で、ルーティングもプロキシ経由になっていることを確認してから、ノードをテストします。同じサブスクリプション内で、利用可能と分かっている別のノードに切り替え、ブラウザー、URL、ルーティングモードは変えずに確認してください。1つのノードだけ失敗する場合は、そのノードの稼働状況と設定を調べます。すべてのノードが失敗する場合は、現在のネットワーク制限、サブスクリプションの有効期限、コアが正しく起動しているかも確認してください。

macOSでは「システム設定」→「一般」→「日付と時刻」を開き、自動設定を確認します。Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にしてください。必要に応じて「今すぐ同期」をクリックします。時刻が大きくずれていると、TLS証明書の有効期限判定や一部の認証処理に影響することがありますが、すべてのタイムアウトの原因ではありません。

再テストの結果から残る問題を確認

上記の手順を終えたら、最初のURLで再テストし、変更内容と結果を記録します。問い合わせる場合は、OS、クライアントのバージョン、使用中のコア、エラー発生時刻、機密情報を伏せたログを伝えてください。サブスクリプションURL、ユーザーID、パスワード、ノード設定全体を公開画像に含めないでください。