v2rayNは接続済みなのにWebサイトが開けない？システムプロキシ・ポート・ルーティングの確認手順

1. 「接続済み」でもWebサイトが表示されるとは限らない

v2rayNの動作状態、ノードの遅延テスト結果、Webサイトへのアクセス可否は、それぞれ別の指標です。コアプロセスが起動しているのは、プログラムが動作していることを示すにすぎません。TCP遅延が測定できても、通常は相手側ポートに接続できたことしか確認できません。認証、トランスポート層のハンドシェイク、DNS名前解決、接続先サイトへのアクセスは失敗する可能性があります。遅延テストを繰り返すのではなく、実際のリクエストを確認しましょう。

新しい設定では、HTTPとSOCKSの両方を受け付ける混合ポートが使われる場合があります。以前の設定では、2種類の受け口が分かれていることもあります。10808がすべての環境で使えるとは限りません。画面にHTTPポートとして10809と表示されている場合は、HTTPのテストにそのポートを使ってください。ノードサーバーのポートはサーバー側の設定で決まるため、例に合わせて443に変更しないでください。

1. まずプロキシを無効にし、ローカルネットワークから通常アクセスできるWebサイトが開くことを確認します。
2. 現在のノード、ルーティングモード、ローカルポート、障害が発生した時刻を記録します。
3. 一時的に通信を中継する方法を一つに絞ります。システムプロキシを調べる際はTUNを無効にし、経路が重複して干渉しないようにしてください。
4. クライアントのログを開き、リクエストを一度実行して、同じ時刻のエラーを確認します。

2. システムプロキシ：ブラウザーのリクエスト先を確認する

システムプロキシは、アプリがリクエストをローカルポートに送るかどうかを決めます。ルーティングモードは、リクエストがコアに入った後にどのアウトバウンドを選ぶかを決めるもので、両者は代わりにはなりません。プロキシノードを選んでいてもシステムプロキシが設定されていなければ、システム設定に従うブラウザーは直接接続することがあります。反対に、システムプロキシが停止中のポートを参照していると、通常は開けるWebサイトにもアクセスできません。

1. 受け口を確認する

   v2rayNの「設定」→「パラメータ設定」を開き、ローカルの待ち受けアドレス、ポート、受け入れプロトコルを確認します。バージョンによって項目名やグループ名が異なる場合があります。実際の値を記録し、古い手順をもとにポート番号を推測しないでください。

2. システムプロキシを設定する

   メイン画面または通知領域のメニューから「システムプロキシ」→「自動設定」を選びます。これはシステムプロキシ設定を書き換える操作です。すべてのバージョンでPACが有効になるわけではなく、すべてのアプリの通信がプロキシ経由になるわけでもありません。

3. システム側の設定値を確認する

   Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシまたはセットアップスクリプトの現在の設定を確認します。手動プロキシのアドレスはローカルの待ち受け設定と一致させてください。HTTPプロキシにSOCKS専用ポートを指定することはできません。

4. ブラウザー独自の設定を確認する

   プロキシ切り替え拡張機能を一時的に無効にし、ブラウザー独自のプロキシ設定を確認してから、ブラウザーを再起動してテストします。システムプロキシの値が何度も変わる場合は、まずプロキシ設定を変更するほかのプログラムを終了してください。

コマンドラインツールがWindowsのシステムプロキシを使うとは限りません。ターミナルからのリクエストが成功するか失敗するかだけでは、ブラウザーの設定が正しいとは判断できません。以下で--proxyを明示するのは、この違いを避けてローカルの受け口とその先の接続を個別に確認するためです。

3. ローカルポート：プロキシを明示したリクエストで入口と出口を切り分ける

PowerShellで以下のコマンドを実行します。環境によってはcurlが別のコマンドとして解釈されることがあるため、curl.exeと明記しています。1つ目はHTTPまたは混合受け口、2つ目はSOCKSまたは混合受け口で使います。現在の受け口の種類に合ったコマンドだけを実行してください。両方の成功を確認する必要はありません。

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

socks5hでは接続先のドメイン名をSOCKS側に渡します。ローカルでの名前解決経路と比較するのに便利ですが、リクエストが必ずリモートDNSを使うことを証明するものではありません。HTTPのテストで200 Connection establishedだけが表示された場合は、続けてTLSと接続先サイトからの応答を確認してください。これはプロキシトンネル確立時の中間応答であり、Webページのリクエストが完了したことを意味しません。

ポートが使用中と表示された場合は、以下のコマンドで待ち受けプロセスを調べます。ローカルアドレスの列とLISTENINGの状態を確認してください。一番右の列がPIDです。「タスクマネージャー」→「詳細」でプロセスを確認します。PIDだけを根拠に、正体の分からないシステムプロセスを強制終了しないでください。

netstat -ano | findstr ":10808"

古いコアプロセスが残っている場合は、該当するクライアントを通常の手順で終了し、再起動します。ローカルポートを変更する場合は、システムプロキシとアプリ独自のプロキシ設定も同時に変更してください。一方だけ変えると、ポートの競合が接続拒否に変わるだけです。1台で使う場合、通常は待ち受けを127.0.0.1に設定すれば十分で、LANからのアクセスを許可する必要はありません。

4. 時刻とハンドシェイク：ログから認証・通信エラーを切り分ける

システム時刻のずれはVMess認証に影響するほか、TLS証明書が有効期間外と判定される原因にもなります。Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にして「今すぐ同期」をクリックします。日付とタイムゾーンも確認してください。見た目の時刻が近いかどうかではなく、実際の時刻が正確であることが重要です。

VLESS、VMess、Trojanでは、ノードをインポートした後もアドレス、ポート、認証情報、トランスポート設定を確認してください。TLSのserverName、WebSocketのパス、gRPCのserviceNameはサーバー側の設定と一致させる必要があります。REALITYでは、サーバーから提供された公開鍵やshortIdなどのパラメータも一致させてください。プロトコル変更を万能な解決策と考えないでください。使用するクライアントコアがその設定に対応している必要もあります。

5. ルーティングとDNS：誤ったアウトバウンドが選ばれていないか確認する

リクエストがコアに届いているログがあるのに、一部のドメインにアクセスできない場合は、ルールによる振り分けを確認します。V2Ray/Xrayのrouting.rulesは上から順に照合し、一致したルールに応じてアウトバウンドを選択します。outboundTagは実在するoutbounds[].tagを参照している必要があります。どのルールにも一致しなかった場合のデフォルトのアウトバウンドも確認してください。必ずプロキシ経由になるとは限りません。

• まずルーティングを比較：現在のモードを記録し、通常の接続先へのリクエストがプロキシ経由になるモードを一時的に選んで、同じURLにアクセスしてから元の設定に戻します。v2rayNのルーティングモードとシステムプロキシのメニューは別の設定項目です。
• 次にブロックルールを確認：通常のWebサイトには接続できるのに特定のドメインだけ失敗する場合は、そのドメインが直接接続またはブロックのルールに一致していないかを確認します。範囲の広いドメインルールやIPルールの順序にも注意してください。
• 名前解決の対象を特定：ノードにドメイン名が使われている場合、ノードへ接続する前に名前解決が必要です。接続先サイトのDNSだけを変更しても、ノードのドメイン名を解決できない問題は解消しない場合があります。
• 設定項目の役割を理解：routing.domainStrategyはルーティングの照合でドメイン名を解決する方法を制御します。アプリの通信をプロキシに流す設定ではなく、DNS通信が外部に出ないことを単独で保証するものでもありません。
• 確認に必要な情報を記録：ログに表示される接続先アドレスとアウトバウンドのtagを一時的に確認します。GUIが設定を自動生成する場合は、該当するルーティング設定を変更してください。一時生成されたファイルを直接編集すると、上書きされる可能性があります。

ブラウザーのセキュアDNS、システムDNS、コアのDNSで名前解決の経路が異なる場合があります。nslookupではシステムが使うリゾルバーを確認できますが、プロキシ内部の名前解決が正常だとは証明できません。また、ブラウザーのすべてのDNSリクエストの送信先を判断することもできません。ブラウザーだけで失敗する場合は、比較のためにセキュアDNSの設定を一時的に変更し、テスト後に元の設定へ戻してください。

6. ノードの状態：ポートへの接続とプロトコルの利用可否を区別する

ローカルの待ち受けに問題がなく、プロキシを明示したリクエストも失敗する場合は、リモート側を確認します。PowerShellのポートテストで確認できるのはTCP接続の確立までで、VMess、VLESS、Trojanの認証やトランスポート設定は検証されません。そのため、TcpTestSucceeded: Trueで原因の範囲は絞れますが、実際のWebリクエストの代わりにはなりません。

$nodeHost = Read-Host "現在のノードのサーバーアドレスを入力"
$nodePort = [int](Read-Host "現在のノードのサーバーポートを入力")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort

1. 設定の取得元を確認：サブスクリプションが更新済みか、アカウントの有効期限が切れていないか、通信容量を使い切っていないかを確認します。サブスクリプションURL、UUID、パスワード、設定全体を見知らぬ相手に送らないでください。
2. 動作確認済みのノードに切り替える：ローカルポートとルーティング設定は変えず、同じURLで再テストします。特定のノードだけ失敗する場合は、まずそのノードの設定値とサーバーの状態を確認してください。
3. ネットワークを切り替える：スマートフォンのテザリングと現在のネットワークを比較します。テザリングでは使えて元のネットワークでは失敗する場合は、元のネットワークの外向き通信制限、DNS、ファイアウォール設定を重点的に確認します。
4. ブロック履歴を確認：セキュリティソフトが画面側のプログラムを許可していても、コアプロセスの通信をブロックする場合があります。プログラムのパスとログを確認して必要な許可を追加してください。ファイアウォールを常時無効にすることは解決策ではありません。

すべてのノードで同時に失敗し、ログにコアを起動できないと表示されている場合は、サブスクリプションの更新を繰り返すのではなく、設定の解析エラーやコアの互換性を先に確認してください。アップグレード前に設定をバックアップし、アップグレード後は選択中のコアがノードのプロトコルに対応しているか確認します。ソフトウェアを更新しても、リモート証明書、アカウントの通信容量、サーバー設定の誤りは解決しません。

7. よくある質問と復旧後の確認

接続が回復したら、調査のために一時追加した全体向けルーティングやデバッグ設定を元に戻し、必要なシステムプロキシ設定だけを残します。通常は直接接続するサイト、プロキシが必要なサイト、以前失敗したアプリを少なくとも1つずつ再テストしてください。3つとも想定どおりに動作することを確認してから、有効だった変更を記録します。

• 問い合わせ時に添える情報：クライアントのバージョン、コアのバージョン、OSのバージョン、実際のローカルポート、ルーティングモード、テストした時刻。
• ログを共有する範囲：失敗の前後にある関連行だけを抜粋してください。公開前にサブスクリプションURL、認証情報、公開を望まないサーバー情報を隠します。
• 設定項目をさらに確認：受け口、アウトバウンド、ルーティングの対応関係を確認するにはJSON設定マニュアルをご覧ください。基本設定の手順は使い方ガイドをご確認ください。