v2rayNのデスクトップ版や、v2rayNG・v2flyNGのAndroid版で「起動したのにブラウザーでアクセスできない」ときに役立つチェックリストです。まずリクエストがクライアントに届いているか、次にコアがリモートサーバーへ接続できているかを確認します。変更は一度に1項目に絞り、同じURLで再テストしてください。システム設定の場所、ポート確認コマンド、DNSの比較方法、ログの見方を解説します。接続アイコンや一度の遅延テストだけで、Webサイトが使えると判断しないことが大切です。
1. 接続状態とWebリクエストを切り分ける
クライアントの「接続済み」は、ローカルのコアが起動した状態を指す場合もあれば、AndroidのVPNインターフェースが確立した状態を指す場合もあります。リモートノードでの認証成功や、Webアクセスに必要なDNS・TCP・TLSが正常であることを意味するわけではありません。遅延テストも特定のアドレスや接続方式だけを確認する場合があり、すべてのWebサイトの動作を保証するものではありません。
現在の設定はそのまま残し、障害の発生時刻、使用中のノード、接続方式、アクセスできないURLを記録します。テストごとに経路が変わらないよう、自動ノード切り替えはオフにしてください。DNS、サブスクリプション、コアを同時に変更すると、復旧しても原因を特定できません。
- すべてのWebサイトにアクセスできない：まず基本ネットワーク、ローカルの待ち受け、トラフィックの取り込み状態を確認します。
- 一部のドメインだけアクセスできない：DNS、ルーティングの適用状況、接続先サイトの状態を比較します。
- ブラウザーだけ失敗し、ほかのアプリは正常：ブラウザーのプロキシ拡張機能、個別のプロキシ設定、セキュアDNSを確認します。
- Wi-Fiでは正常だがモバイル通信では失敗：ノードを変えずに再テストし、ネットワークごとの差を記録します。サブスクリプションが無効だとすぐに判断しないでください。
2. システムプロキシとVPN接続を確認
v2rayNのシステムプロキシは、システムプロキシ設定に従うアプリのリクエストをローカルポートへ転送します。TUNは仮想ネットワークインターフェース経由でトラフィックを取り込みます。通常のブラウザーを調べるときは、まずシステムプロキシだけを使って変数を減らしましょう。すでにTUNを使っている場合は、元の設定を保存してから接続方式を切り替え、結果を比較してください。
-
現在のノードを確認
v2rayNのメイン画面で、選択中のサーバーがテストする設定と一致しているか確認し、ログにコアの終了が記録されていないか調べます。リスト上の行を選択する操作と、設定を実際に有効化する操作は異なる場合があります。現在有効な設定とログを基準に判断してください。
-
システムプロキシを設定
v2rayNのタスクトレイメニューで「システムプロキシ」→「システムプロキシを自動設定」を選択します。画面のバージョンによって表示名は多少異なります。システムプロキシを待ち受け中のローカルアドレスに向けることが目的で、メイン画面を起動するだけでは設定されません。
-
システムのアドレスを確認
Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」を開き、アドレスとポートを確認します。クライアントが自動構成スクリプトを使う場合は、該当するスクリプト設定を確認し、手動プロキシを重ねて設定しないでください。
-
ブラウザー側の設定を確認
プロキシ設定を変更するブラウザー拡張機能を一時的に無効にし、ブラウザーを終了してから再起動します。Firefoxでは「設定」→「一般」→「ネットワーク設定」→「接続設定」を開き、システムのプロキシ設定を使用しているか確認できます。
-
Androidの接続を確認
v2rayNGまたはv2flyNGを使う場合は、設定を起動し、VPN接続を許可したか確認します。アプリごとのプロキシ設定を有効にしている場合は、ブラウザーが対象に含まれているか確認してください。また、別のアプリがVPN接続を使用していないかも調べます。
AndroidのVPNアイコンが示すのは、インターフェースが存在することだけです。クライアントのバックグラウンド動作がシステムに制限されると、インターフェースや画面の状態が実際の転送状況を反映しない場合があります。アプリを前面に表示したまま同じURLに再アクセスし、新しい接続ログが記録されるか確認してください。バックグラウンド動作の権限は、システムの「設定」→「アプリ」から対象クライアントのバッテリー管理画面で確認できます。項目名は端末やOSによって異なります。
3. ローカルポートが実際に待ち受けているか確認
プロキシアドレスが正しくても、ポートが待ち受けていなければブラウザーは接続できません。ここではローカルのSOCKSインバウンド 127.0.0.1:10808 を例に説明します。このポートは確認用の例であり、すべてのバージョンで同じ既定値を使う必要はありません。クライアントの現在のインバウンド設定または起動ログで実際のポートを確認し、コマンド内の番号を置き換えてください。
Windows PowerShellで次のコマンドを実行します。1行目はTCPの待ち受けと接続を一覧表示し、2行目はローカルのTCP接続が確立できるかだけを確認します。LISTENINGと表示された場合も、最後の列のPIDを確認し、想定したコアではなく別のプロセスが待ち受けていないか調べてください。
netstat -ano | findstr ":10808"
Test-NetConnection -ComputerName 127.0.0.1 -Port 10808- 待ち受けの記録がない：コアの起動ログを確認し、設定の読み込みに成功しているか調べます。ブラウザーのプロキシ設定を何度も切り替える必要はありません。
- 別のプロセスが待ち受けている：タスクマネージャーの「詳細」タブでPIDを検索します。用途を確認してから競合するプログラムを終了するか、クライアントのインバウンドポートを変更し、システム設定も合わせて更新してください。
- ローカルTCPテストに成功：ポートが接続を受け付けることを確認できただけです。SOCKSのネゴシエーションやリモート側への接続が正常とは限りません。
次に、システムプロキシ設定を経由せず、プロキシを明示したリクエストを実行します。Windowsではコマンドのエイリアスによる引数の違いを避けるため curl.exe を使います。macOSやLinuxでは、利用可能な curl を使えます。以下のコマンドはSOCKS5対応ポートを前提としているため、HTTP専用のインバウンドポートでは代用できません。
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/判定：明示的なプロキシ接続に成功したらブラウザーを確認
このコマンドでHTTPレスポンスを受信できるのにブラウザーでは失敗する場合、次にブラウザー側のプロキシ設定の上書きとシステムプロキシのアドレスを確認します。403や405が返った場合も、HTTP層のレスポンスを受信できています。「ローカルポートが待ち受けていない」状態とは区別してください。
4. DNS名前解決がどこで失敗しているか確認
DNSには少なくとも2種類のドメインが関係します。ノードサーバーとWebサイトのドメインです。前者の名前解決に失敗すると、クライアントはリモートサーバーを見つけられません。後者で失敗すると、一部のWebサイトだけが開けないことがあります。ブラウザーに「サーバーが見つかりません」と表示されただけで、システムDNSの変更が必要だと決めつけないでください。
まずローカルで名前解決を行い、次にSOCKS接続を2通り比較します。socks5://では通常、curlがローカルで接続先ドメインを名前解決します。一方、socks5h://では接続先ドメインの処理をプロキシに任せます。後者で最終的に使われる名前解決の方法は、コアのDNS設定とルーティング設定によって異なり、必ずしもリモートサーバーのシステムDNSを使うとは限りません。
nslookup example.com
curl.exe --noproxy "" --proxy socks5://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では成功：まずローカルの名前解決経路を確認します。WindowsでDNS設定を変更した後は
ipconfig /flushdnsを実行できますが、キャッシュを消去しても到達不能なDNSサーバーは直りません。 - どちらのプロキシリクエストもタイムアウト：ルーティングとリモート接続の確認を続けてください。DNSだけを変更し続けないようにしましょう。
- システムでの名前解決は正常だが、ブラウザーだけ失敗：ブラウザーのセキュアDNSを確認します。システムの問い合わせとは別の経路を使っている可能性があります。
- ログにノードのドメイン名が記録されている：
nslookupの後に実際のノードのドメイン名を指定して確認します。ノードのドメイン名とアクセス先Webサイトのドメイン名を混同しないでください。
5. ルーティングとノードの状態を確認
ローカルポートとDNSが正常なら、失敗したリクエストにどのアウトバウンドが適用されたかを確認します。V2Ray/Xrayのルーティングは通常、ルールの順序に従って照合され、最初に一致したルールが通信経路を決定します。範囲の広すぎる直接接続やブロックのルール、アプリの除外設定によって、リクエストが想定したプロキシを通らないことがあります。
- 現在のルーティングモードとカスタムルールを記録し、元に戻せるよう設定の複製を保存します。クライアントの接続ログまたはアクセスログを見て、テスト対象のドメインがコアに届いているか確認してください。
- 一時的にクライアントの全般プロキシルーティングモードへ切り替え、同じドメインに再アクセスします。これはコアのアウトバウンド選択を変更する操作であり、システムプロキシのスイッチを再度オンにする操作ではありません。
- 全般モードでは成功し、ルールベースのモードでは失敗する場合は、元のモードに戻してから、該当ドメインに適用されるルールの順序、直接接続のアウトバウンド、ドメイン/IPの照合条件を確認します。
- 全般モードでも失敗する場合は、ほかの設定を変えずに、正常に使えることが確認済みの別の設定で比較します。特定の設定だけ失敗する場合に限り、そのサーバーアドレス、ポート、認証情報、有効期限を確認してください。
VMessとVLESSはプロトコルの種類であり、接続方法を切り替えるスイッチではありません。設定で指定された伝送方式、TLS、SNI、REALITYの各パラメーターはサーバー側と一致させる必要があります。プロトコルを適当に変更しても解決にはなりません。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。サブスクリプションをインポートできても、含まれるすべてのパラメーターが現在のコアでサポートされるとは限りません。クライアントの選び方はクライアント比較ガイドをご覧ください。
サブスクリプションの更新に成功しても、取得できたことを示すだけで、含まれるすべての設定が現在使えるとは限りません。ノードのTCPポートに接続できても、プロトコル認証の成功を意味しません。テスト中はノードを1つに固定し、HTTPSリクエスト全体が応答することを確認してから、自動選択や複雑なルーティングに戻してください。
6. ログのエラーと次の対処
失敗するリクエストを1回実行し、その時刻に最初に記録された関連エラーを確認します。以下はよくあるエラーの例です。コアによってはアドレスやポート、さらに詳しい原因が付記されることがあります。最後の1行だけを見て、すべてノードの問題だと決めつけないでください。ログを共有する前に、サブスクリプションURL、認証情報、個人のネットワーク情報を削除してください。
エラー：connection refused
原因：接続先のポートが接続を拒否しています。ローカルのプロキシポートでも、リモートサーバーのポートでも発生する可能性があります。
対処：まずエラーに記載されたアドレスを確認します。127.0.0.1ならローカルの待ち受けを、ノードのアドレスならサーバー側のポートとサービスの状態を調べてください。
エラー：no such host
原因：いずれかのドメイン名を名前解決できていません。対象は同じ行または前後のログから特定します。
対処：まずドメイン名の入力ミスがないか確認し、ノードのドメインとWebサイトのドメインを切り分けます。前のセクションの方法で、それぞれの名前解決経路を確認してください。
エラー：context deadline exceeded
原因：処理が制限時間を超えています。DNS、リモート接続、ハンドシェイクの待機などが考えられますが、このエラーだけでは原因を特定できません。
対処：直前のログから停止している段階を特定し、同じノードでネットワークを変える、または同じネットワークでノードを変えるなど、一度に1つの条件だけを比較します。
エラー：address already in use
原因：コアがバインドしようとしているローカルアドレスとポートがすでに使用されており、該当するインバウンドを起動できません。
対処：ポート確認コマンドでPIDを特定し、競合を解消してからコアを再起動します。その後、システムプロキシが実際に使用中の新しいポートを指していることを確認してください。
証明書の期限切れ、ホスト名の不一致、ハンドシェイクの失敗が発生した場合は、まずシステムの日付・時刻・タイムゾーンを確認し、サブスクリプションで指定されたTLSパラメーターを照合します。証明書検証のスキップを通常の対処方法にしないでください。復旧したら一時的に有効にした詳細ログを無効にし、アクセス情報を不要に記録し続けないようにします。
7. 復旧後によくある質問
速度テストは成功するのに、Webサイトがタイムアウトするのはなぜ？
速度テストでは、指定されたアドレスへの接続しか確認しない場合があります。この記事のプロキシを明示したコマンドで実際のHTTPSリクエストを確認し、ブラウザーの結果と比較してください。ブラウザーだけで失敗する場合は、個別のプロキシ設定とセキュアDNSを優先して確認します。
TUNを有効にすれば、すべてのアプリがインターネットに接続できる？
いいえ。TUNはトラフィックの取り込み方法を変えるだけで、使えなくなったノードや認証情報の誤りを自動で修正するものではありません。まずシステムプロキシモードで通信経路を確認してください。システムプロキシに従わないアプリの通信も取り込む必要がある場合は、クライアントの要件に従ってTUNを有効にし、権限、ルーティング、DNSを確認します。
クライアントを終了したら、かえってブラウザーで開けなくなったのはなぜ？
ローカルポートを指すシステムプロキシが残っていないか確認してください。Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシを解除します。またはv2rayNを再び起動し、「システムプロキシ」→「システムプロキシを解除」を選んで終了してください。
トラブル対処後、どの設定変更を残せばよい？
比較テストで効果を確認できた変更だけを残します。一時的な全般ルーティングを元に戻し、デバッグログを無効にして、ブラウザーのプロキシ方式が現在の接続方式と一致しているか確認してください。変更内容、テストしたURL、日時を記録しておくと、再発時に同じ箇所から確認できます。
原因を特定できない場合は、クライアント名、コアの種類、接続モード、個人情報を除いたログに加え、「プロキシを明示したリクエストが成功したか」をまとめてください。接続済み画面のスクリーンショットだけよりも、障害範囲を判断しやすくなります。基本設定はインストール・設定ガイド、関連用語は用語集をご覧ください。