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

まず、どの層で問題が起きているか確認する

クライアントに接続済みと表示されても、アプリの通信がプロキシに入ったことや、リモートノードとのハンドシェイクが完了したことまでは意味しません。1つのリクエストは少なくとも、アプリ、システムプロキシまたはTUN、ルーティング判定、プロキシの出方向け接続、DNS解決を通過します。どこか1つが失敗すると、見た目には「Webページがずっと読み込み中」という状態になります。

開始前にテスト条件を固定します。実行中のダウンロードを停止し、ブラウザーのウィンドウを1つだけ残して、確実にアクセスできる通常のHTTPSサイトを選びます。ノード、ルーティングモード、DNSを同時に切り替えないでください。一度に変更するのは1つの変数だけにし、変更後は同じページを再読み込みして結果を記録します。

範囲を切り分けるには、2つの比較テストが有効です。1つ目は、システムプロキシを無効にしてローカルネットワークへアクセスし、その後有効にして同じアドレスへアクセスする方法です。2つ目は、現在のノードと、利用できることを確認済みの別ノードを切り替える方法です。すべてのノードで失敗するなら、ローカル入口、ルーティング、DNSの可能性が高くなります。1つのノードだけ失敗するなら、そのノードの状態と設定項目を優先して確認します。

第1層：ローカル設定で確認する3項目

ローカル層は、アプリの通信をコアへ送り込む役割を担います。ここで多いのは、システムプロキシが有効になっていない、待ち受けポートが他のプログラムに使用されている、またはブラウザーに独自のプロキシ設定が残っているケースです。v2rayN 7.xでは、クライアント起動後にコアの状態とシステムプロキシの状態を両方確認し、タスクトレイのアイコンだけで判断しないでください。

1. 第1項：システムプロキシが実際に有効か確認する。 v2rayNのメイン画面で、システムプロキシモードが「システムプロキシを解除」になっていないことを確認します。続いてWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシがローカルアドレスを指しているか確認します。一般的な待ち受けアドレスは127.0.0.1ですが、ポートはv2rayNの最新ログ、または「設定」→「パラメータ設定」に表示されるローカルポートを基準にしてください。古い設定ではSOCKSポートが10808、HTTPポートが10809であることが多いものの、アップグレードや設定移行後も同じとは限りません。
2. 第2項：コアが対応するポートを待ち受けているか確認する。 WindowsではPowerShellからローカルポートをテストできます。結果のTcpTestSucceededがFalseなら、ブラウザーにプロキシアドレスが設定されていても、接続を受け付けるローカルプロセスがありません。まずv2rayNを完全に終了して再起動します。それでも失敗する場合は、ログのポート競合に関する情報を確認し、「設定」→「パラメータ設定」で未使用のポートに変更します。
3. 第3項：アプリ独自のプロキシ設定による上書きを除外する。 一部のブラウザーや開発ツールは、独立したプロキシアドレスを使用できます。システムプロキシが127.0.0.1:10809なのに、アプリが停止済みの127.0.0.1:7890を参照していれば、通信は現在のコアに入りません。アプリのプロキシを「システムプロキシを使用」に変更し、再起動してからテストします。コマンドラインツールでは、環境変数に古いHTTPまたはSOCKSプロキシの値が残っていないかも確認してください。

Test-NetConnection 127.0.0.1 -Port 10808
Test-NetConnection 127.0.0.1 -Port 10809

Androidでv2rayNGまたはv2flyNGを使う場合、ローカル入口はシステムのVPNインターフェースが管理します。接続をタップした直後に未接続へ戻るなら、まずVPNインターフェースを使用中の他のネットワークツールを停止し、接続の許可をやり直します。接続状態が維持されるのに特定のアプリだけ失敗する場合は、そのアプリが「アプリごとのプロキシ」のバイパスリストに入っていないか確認します。

第2層：ノード状態とハンドシェイク設定で確認する3項目

ローカルポートが正常になったら、次にノードがTCP、TLS、その他のトランスポート層の接続を確立できるか判断します。遅延テストは最終的な利用可否の証明ではありませんが、「アドレスにまったく到達できない」状態と「ハンドシェイク後にリクエストが失敗する」状態を素早く切り分けられます。テスト時は種類も確認してください。ICMP遅延、TCP遅延、実接続遅延のいずれか1種類の結果だけでは、完全なWebリクエストの代用になりません。

4. 第4項：ノードのアドレスとポートの疎通をテストする。 v2rayNのノード一覧で現在のノードを選び、実接続遅延テストを実行します。一般的な家庭のネットワークでは、数十〜数百ミリ秒になることがあります。3回連続でタイムアウトし、ログがサーバー接続の段階で止まる場合は、サーバーのドメインとポートを確認してください。高遅延を完全な到達不能と誤判定しないよう、タイムアウト値を一時的に5000ミリ秒へ変更して再テストできます。
5. 第5項：システム時刻を調整し、TLSハンドシェイクを確認する。 TLS証明書の検証には端末の時刻が使われます。数分のずれでも、証明書がまだ有効でない、または期限切れという判定になることがあります。Windowsでは「設定」→「時刻と言語」→「日付と時刻」を開き、自動設定を有効にして今すぐ同期します。Androidではシステムの日付と時刻の設定を開き、ネットワーク提供時刻を有効にします。同期後はコアを完全に停止してから、再接続してください。
6. 第6項：ノード設定を項目ごとに照合する。 VMessでは、アドレス、ポート、ユーザーID、伝送方式、TLS、パスを重点的に確認します。VLESSではさらに、flow、セキュリティタイプ、サーバー名、Reality関連の公開鍵パラメータがノード設定で指定されたものと一致するか確認します。WebSocketのパスに含まれるスラッシュ、gRPCのserviceNameの大文字・小文字、TLSのサーバー名は完全に一致していなければなりません。プロトコル名から項目を推測して追加せず、実際のサーバー設定または最新のサブスク内容を基準にしてください。

第3層：ルーティングの振り分けで確認する3項目

ノードのハンドシェイクが成功しているのにWebサイトが開けない場合、重点的に確認するのはルーティング規則です。V2RayとXrayのコアは、ドメイン、IP、ポート、ネットワーク種別、inboundタグに基づいて出方向け接続を選択します。規則によって対象が誤ってdirectやblockへ送られても、ノード自体は切断されないため、画面には接続正常と表示されることがあります。

7. 第7項：最も単純なプロキシモードに切り替えて比較する。 一時的にルーティングをすべてプロキシ経由にするテストモードへ変更し、失敗するWebサイトを再度開きます。すぐに復旧するなら、ノードとローカル入口は正常で、問題は振り分け規則に絞られます。テスト後は元のモードに戻し、どの規則に一致したかを順に確認してください。規則の誤りを隠すために、この比較モードを常用しないでください。
8. 第8項：GeoIPとGeoSiteのデータが欠落または古くなっていないか確認する。 カスタム規則ではgeoip:cn、geosite:cnなどの分類セットを参照することがあります。データファイルが欠落すると、コアが規則の読み込み失敗を通知する場合があります。長期間更新していない場合は、新しいドメインがフォールバック規則に入ることもあります。v2rayNではメイン画面の更新確認機能からGeoファイルを更新し、完了後にコアを再起動して、ログにリソース読み込みエラーがないことを確認します。Androidではクライアントに用意されたデータ更新入口を使い、更新後に再接続してください。
9. 第9項：ドメインスニッフィングと規則の優先順位を確認する。 ブラウザーのリクエストが先にIPへ解決され、規則がドメインだけを照合していると、想定した出方向け接続を迂回することがあります。ドメインスニッフィングを有効にすると、コアはHTTP HostやTLS Server Nameからドメインを復元してルーティングに利用できますが、一部のLANサービスには適しません。まず失敗するサイトがログ上でドメインとIPのどちらとして表示されているかを確認し、その後スニッフィング設定を調整します。カスタム規則は通常上から順に照合されるため、広範囲のdirect規則を、より具体的なproxy規則より前に置かないでください。

ドメイン規則：domain:example.com
サフィックス規則：domainSuffix:example.com
完全一致：full:service.example.com
ポート範囲：80,443
フォールバック動作：proxy / direct / block

第4層：DNS解決で確認する3項目

DNS障害では、ノードの遅延やIPアドレスへの接続は正常なのに、ドメインのWebページだけ開けないことがあります。トップページは開けても、異なるサブドメインから配信される画像やログインAPIがタイムアウトする場合もあります。確認時は「ノードサーバーのドメイン解決」と「アクセス先ドメインの解決」を分けて考えてください。前者が失敗するとノード接続を確立できず、後者はノード接続後に発生します。

10. 第10項：DNSサーバー自体に到達できるか確認する。 プロキシ経由でしかアクセスできない名前解決サービスを設定しているのに、DNSクエリをdirectへ送ると、クエリはタイムアウトし続けます。逆に、ローカルドメインをすべてリモートDNSへ送ると、現在のネットワークに適さないアドレスが返ることもあります。まず一時的にシステムDNSを使って比較します。復旧後はローカルクエリとプロキシクエリの出方向け経路を分けて設定し、ログの問い合わせ時間を確認してください。通常のクエリは数十〜数百ミリ秒で返るはずで、2000ミリ秒を連続して超える場合は異常と考えます。
11. 第11項：キャッシュを削除し、FakeDNSの適用範囲を確認する。 ブラウザー、システム、コアはそれぞれ名前解決結果をキャッシュすることがあります。DNSを変更しても関連プロセスを再起動しなければ、テストで古いアドレスが使われる可能性があります。Windowsではブラウザーを閉じてシステムのDNSキャッシュを削除し、その後v2rayNを再起動します。TUNとFakeDNSを使用する場合は、仮想アドレスプールが対応する通信経路だけで使われているか確認してください。アプリが仮想アドレスを取得した後にTUNを迂回してdirect接続すると、必ず失敗します。
12. 第12項：IPv4とIPv6の応答結果を確認する。 AAAAレコードは解決できても、安定したIPv6の出口がないネットワークがあります。その場合、ブラウザーが到達不能なアドレスを先に試し、タイムアウトまで待つことがあります。ログで対象へのIPv6接続が優先され、毎回数秒後にIPv4へフォールバックしているなら、比較のためドメインの優先順位を一時的にIPv4優先へ変更します。問題を確認したら、ローカルIPv6ネットワークを修正するか、環境に適した名前解決方針を維持してください。すべてのDNS問題をノードのせいにしてはいけません。

結果から原因を絞り込み、再テストを完了する

12項目の確認が終わっても、「どこかのトップページが開いた」だけで復旧と判断しないでください。少なくとも通常のHTTPSページ、複数のサブドメインからリソースを読み込むページを1つずつテストし、サブスク更新も1回実行します。デスクトップではブラウザーも再起動し、Androidでは一度切断してから再接続して、システムプロキシまたはVPNインターフェースが安定して再構築されることを確認してください。

ローカルポートが利用でき、複数ノードの実接続テストが正常で、全プロキシならアクセスできるのに元の振り分けモードだけ失敗するなら、障害はルーティング層に絞れます。ノードのドメインを解決できない、または接続確立前にログへlookupエラーが出る場合は、先にブートストラップDNSを処理します。1つのノードだけが異なるネットワークでもハンドシェイクに失敗する場合は、そのノードの設定とサービス状態を確認してください。

• ローカル層の合格基準：アプリが正しい入口を使い、コアの待ち受けポートが存在し、ログに新しいリクエストが入ったことが記録される。
• ノード層の合格基準：サーバーアドレスに到達でき、システム時刻が正確で、VMessまたはVLESSの項目が実際の設定と一致している。
• ルーティング層の合格基準：失敗するドメインが想定した出方向け接続に一致し、Geoデータが正常に読み込まれ、広範囲の規則によって優先順位が上書きされていない。
• DNS層の合格基準：ノードのドメインと対象ドメインの両方が、妥当な時間内に現在のネットワークから到達可能なアドレスを返す。