v2rayNを起動してノードを選択してもWebサイトを開けないデスクトップユーザー向けです。まずブラウザーのリクエストがローカルのコアに届いているかを確認し、次にルーティング、名前解決、リモート接続を調べます。一度に変更する設定は一つだけにして、同じURLで再テストしてください。ポート確認、コマンドラインからのリクエスト、ログを照合すれば、システムプロキシの未適用、コアの未起動、ノードの接続不可を切り分けられます。クライアントを何度も再インストールする必要はありません。
1. 接続状態だけでなくシステムプロキシを確認
まず「システムプロキシ」が「システムプロキシを自動設定」になっているか確認します。クライアントが起動し、ノード名が表示され、遅延テストの結果が出ていても、ブラウザーがプロキシを使っているとは限りません。v2rayNは設定と管理を行う画面です。ローカルのリクエストを受け付けてリモートサーバーに接続するのはコアです。アプリ側の入口とコアの状態を両方確認しましょう。
以下のメニュー名は、一般的な中国語版インターフェースに基づいています。デスクトップ版によってメニューの位置が異なる場合があります。画面下部に該当項目が見つからない場合は、タスクバーの通知領域にあるv2rayNアイコンを右クリックし、同じ名前のメニューを確認してください。まず現在の設定を記録し、TUNモードを一時的にオフにして、システムプロキシだけで確認します。二つの接続方式が重なるのを避けるためです。
-
直接接続を確認
v2rayNの「システムプロキシ」から「システムプロキシをクリア」を選び、普段から直接アクセスできるWebサイトを開きます。この状態でも接続できない場合は、PCのネットワーク接続、Wi-Fiの認証、上位ネットワークを先に確認してください。
-
使用するノードを設定
メイン画面で対象のノードを選択し、右クリックして「アクティブサーバーに設定」を選びます。コアが起動するまで待ちます。画面下部のログに起動失敗がすぐ表示された場合は、次のセクションでポートを確認してください。
-
システムプロキシを有効化
「システムプロキシ」→「システムプロキシを自動設定」を選びます。Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で、プロキシのアドレスがローカルPCを指し、ポートがクライアントのインバウンド設定と一致していることを確認してください。
-
個別プロキシ設定を確認
ブラウザー拡張機能とブラウザー独自のプロキシ設定を確認します。プロキシを個別に指定している場合は、いったんその設定を無効にしてください。ブラウザーを完全に終了してから再起動し、同じURLで再テストします。
2. ローカルポートとコアの待ち受けを確認
システムプロキシのポートは、コアが実際に待ち受けているポートと一致している必要があります。v2rayNの「設定」→「パラメーター設定」を開き、ローカルインバウンドの待ち受けアドレス、ポート、プロトコルを確認してください。バージョンによっては「Core:基本設定」またはインバウンド関連のタブにあります。リモートノードのサーバーポートをシステムプロキシに設定しないでください。
以下のコマンドはWindows PowerShell向けです。クライアントのHTTPまたは混合インバウンドポートが10808だと仮定しています。実際のポートが異なる場合は、コマンド内の数字を置き換えてください。SOCKSインバウンドしか設定していない場合は、このHTTPプロキシテストをそのまま使わないでください。
Test-NetConnection 127.0.0.1 -Port 10808
netstat -ano | findstr ":10808"
curl.exe -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:10808 https://www.example.com/TcpTestSucceeded : Trueはローカルポートに接続できたことを示すだけです。リモートノード、DNS、接続先のWebサイトが利用できることまでは確認できません。netstatでLISTENINGの行と最後の列のPIDを確認し、タスクマネージャーの「詳細」タブでプロセスを照合します。ポート番号だけを根拠に、正体の分からないプロセスを終了しないでください。- プロキシ経由のリクエストでHTTPステータスコードが返れば、リクエストに応答があったことを示します。
403はWebサイト側のポリシーが原因の場合もあり、ローカルポートの障害とは限りません。また、200 Connection establishedだけでは、その後のTLS接続やWebページのリクエストが成功したとはいえません。 - ポートが待ち受けていない場合は、クライアントのログで起動エラーを確認します。別のローカルプロキシプロセスが待ち受けている場合は、重複しているプロセスを終了するか、インバウンドポートを変更してシステムプロキシを設定し直してください。
判断の目安：コマンドで接続できるなら、まずアプリ側の設定を確認
ローカルプロキシを明示したリクエストは成功するのに、ブラウザーでは同じURLを開けない場合は、ブラウザー、システムプロキシ、拡張機能の設定を確認してください。この場合、サブスクリプションやDNSを何度も変更しても、入口設定の不一致は解消しないことがほとんどです。
3. ルーティングでリクエストの出口が誤っていないか確認
ローカルポートに問題がなければ、次に「ルーティング」を確認します。ルーティングとは、ルールに従ってリクエストをプロキシ、直接接続、またはブロックへ振り分ける仕組みです。ブラウザーのリクエストがコアに届いても、選択中のノードを必ず経由するとは限りません。カスタムルールによって、特定のドメインが直接接続されたり、ブロックされたりすることもあります。
- 現在のルーティング設定名を控えてください。画面に「グローバル」または「グローバルプロキシ」のプリセットがある場合は、一時的に切り替え、同じアクセスできないURLを再テストします。ここで変更するのはルーティングであり、TUNモードへの切り替えではありません。
- グローバルプロキシでは接続できるのに元のモードでは失敗する場合は、元の設定に戻し、対象ドメインがカスタムの直接接続ルール、ブロックルール、または範囲が広すぎるドメインサフィックスルールに一致していないか確認してください。
- ログにルーティング情報が表示される場合は、リクエスト時刻から対象ドメインを探し、実際のアウトバウンドタグを確認します。該当情報がログにない場合、一覧に表示されたノード名だけで出口を判断しないでください。
- ルールを修正したら元のモードに戻し、直接接続するはずのWebサイトと、プロキシを通すはずのWebサイトを一つずつテストします。局所的な問題を新たなルーティングの誤りに置き換えていないか確認してください。
4. システムDNS、コアのDNS、ノードのドメイン解決を切り分ける
DNSはドメイン名をIPアドレスに変換する仕組みです。少なくとも、リモートノードのサーバー名とアクセスしたいWebサイトのドメイン名を分けて考える必要があります。前者の名前解決に失敗すると、コアがノードに接続できない場合があります。後者で失敗した場合は、一部のWebサイトだけに影響することがあります。また、システムDNSとコアのDNSで異なる設定が使われている場合もあります。
Windowsでは、以下の2つのコマンドでシステムの名前解決結果を確認し、システムキャッシュを消去できます。2つ目のコマンドが消去するのはPC上のシステムDNSキャッシュだけです。コアの設定やブラウザー独自の名前解決キャッシュはリセットされません。
Resolve-DnsName www.example.com
ipconfig /flushdns- システムで名前解決できる場合：現在のシステムリゾルバーが結果を返したことしか分かりません。コアも同じ経路で名前解決していることや、その結果が現在のネットワークに適していることを示すものではありません。
- ノードのドメイン名を解決できない場合：まずノードアドレスの入力ミスがないか確認し、プロキシ接続の確立に使うDNS経路を調べます。リゾルバーへの接続に、まだ確立していないプロキシが必要な場合、起動時に依存関係の循環が発生します。
- DNSを変更する場合：「設定」→「DNS設定」で、現在のコアに対応する項目を確認します。バージョンによってDNS設定が「パラメーター設定」にある場合は、該当タブを開いてください。まず現在の値を保存し、一度に変更する設定は一組に絞ります。画面の指示に従って保存し、コアを再起動してください。
- URLをIPアドレスに置き換えないでください：HTTPSサイトでは通常、証明書の検証や接続先サイトの判定にドメイン名が使われます。IPアドレスでアクセスできなかったとしても、DNS障害の確かな証拠にはなりません。
SOCKSインバウンドが設定されていることを確認できた場合は、以下の方法で接続先のドメイン名をSOCKSプロキシに渡し、プロキシ経由で名前解決することもできます。コマンド内の10808は、実際のSOCKSまたは混合インバウンドポートに合わせてください。システムから直接名前解決した結果と比較できますが、それだけで各段階の名前解決場所を特定することはできません。
curl.exe -I --connect-timeout 10 --max-time 20 --socks5-hostname 127.0.0.1:10808 https://www.example.com/5. ログのエラーからノードとハンドシェイクの問題を特定
入口、ポート、ルーティング、DNSを確認してから、ノードを検証します。クライアント画面下部のログまたは「ログ」を開き、リクエストの時刻を記録してから障害を再現してください。以下は発生する可能性のあるエラーの一部です。前後の内容はコアやシステムによって異なるため、最後の一語だけを切り取って判断しないでください。
エラー：bind: address already in use
原因と対処：コアが待ち受けようとしたローカルアドレスまたはポートが使用中です。ポートを照会して使用プロセスを確認し、重複しているクライアントを終了するか、ローカルインバウンドポートを変更してください。その後、システムプロキシを設定し直します。
エラー：connection refused
原因と対処：接続先のエンドポイントに接続を拒否されました。エラーがローカルとリモートのどちらを指しているかを確認します。ローカルアドレスなら待ち受け状態を、リモートアドレスならノードのポートとサービスの稼働状況を確認してください。すべてをDNSの問題と決めつけないでください。
エラー：lookup …: no such host
原因と対処：ドメイン名を有効な結果に解決できませんでした。省略部分には実際に照会したドメイン名が入ります。まずノードとWebサイトのどちらのドメインかを確認し、入力、DNS設定、リゾルバーへの接続を調べてください。
エラー：i/o timeout
原因と対処：ネットワーク処理のいずれかの段階でタイムアウトしました。前後の宛先アドレスから、DNS、リモート接続、応答の読み取りのどこで発生したかを確認します。既知の別ノードでも試して比較してください。このログだけでアカウントが無効だと判断することはできません。
エラー：x509: certificate has expired or is not yet valid
原因と対処：証明書の有効期間の検証に失敗しました。PCの時刻またはサーバー証明書に問題がある可能性があります。まずシステムの「日付と時刻」で時刻を合わせてください。時刻が正しいのに失敗する場合は、サービス提供元に証明書の確認を依頼してください。証明書検証を無効にしないでください。
ノードを切り替えるときは、ルーティングとテストURLを同じに保ち、アクティブノードだけを変更します。TCP遅延の結果は、あるポート接続に応答があったことを示すにすぎません。プロトコル認証、TLSハンドシェイク、Webリクエストがすべて成功したことを保証するものではありません。クライアントの接続確認テストを使う場合も、テスト先が実際にアクセスするWebサイトと異なる可能性に注意してください。
- 特定のノードだけ失敗する場合は、サブスクリプションが更新されているか、アカウントの通信量、期限、サービスのお知らせを確認してください。
- すべてのノードが突然使えなくなった場合は、PCを一時的にスマートフォンのテザリングに接続するなど、別のネットワークでも比較してください。比較中にコアとDNSを同時に変更しないでください。
- VLESSとVMessでは設定項目が異なります。REALITYを使うノードでは、対応する公開鍵、サーバー名、その他の提供元指定パラメーターも一致させる必要があります。不明な項目を空欄のままにしたり、推測で入力したりしないでください。
- 「設定」→「パラメーター設定」で、コアの種類に関する項目を確認し、使用中のコアがその設定に対応しているか調べます。コアの切り替えですべての問題が解決するわけではありません。先に元の設定を記録し、起動ログを確認してください。
6. よくある症状と復旧後の確認
遅延が数十ミリ秒なのに、Webサイトが開けないのはなぜ？
遅延テストにWebページのリクエスト全体が含まれるとは限りません。まずローカルプロキシを明示したコマンドを実行し、同じ時刻のログを確認してください。ポートに接続できてもハンドシェイクに失敗する場合は、遅延順でノードを選び直すのではなく、プロトコル設定、システム時刻、ノードの状態を確認します。
Webサイトが一つだけ開けない場合、再インストールが必要？
まず再インストールはしないでください。現在のノードのまま別のWebサイトを試し、次にグローバルプロキシへ一時的に切り替えて、問題のWebサイトに再接続します。他のサイトが開ける場合は、対象サイトの稼働状況、ドメインルール、DNS、接続元に対するサイト側のアクセス制限を優先して確認してください。
ブラウザーは使えるのに、ほかのアプリは接続できない？
まず対象アプリのネットワーク設定で「システムプロキシを使用」または個別プロキシの項目を探します。手動プロキシに対応している場合は、ローカルアドレスと実際のインバウンドポートを入力し、HTTPまたはSOCKSの種類を一致させてください。コマンドラインツールも個別の設定が必要なことがあり、すべてのツールがシステムプロキシを使うとは限りません。
クライアントを終了したら、通常のWebサイトも開けなくなった？
v2rayNを再度起動し、「システムプロキシ」→「システムプロキシをクリア」を選んでから終了します。クライアントが起動しない場合は、システムのネットワーク設定で、手動プロキシが停止済みのローカルポートを指したままになっていないか確認してください。変更前に元の値を控え、職場のネットワークで必要なプロキシ設定を上書きしないようにします。
トラブル対処後に残すべき設定は？
効果を確認できた修正だけを残し、一時変更したルーティングとログレベルを元に戻します。効果のなかったDNS変更は取り消してください。以前TUNモードを使っていた場合は、まずシステムプロキシ経由の接続が正常であることを確認し、その後TUNモードを個別に戻してテストします。通信経路の同時制御による影響を避けるためです。
修復後は同じブラウザーで、以前開けなかったURLを再度開き、直接接続するはずのWebサイトも確認してください。引き続きサポートが必要な場合は、クライアントとコアのバージョン、OS、障害発生時刻、テスト方法、該当するエラー行をまとめます。共有前にサブスクリプションURL、ユーザー識別情報、認証パラメーターを隠してください。サポートを受けるために、サブスクリプション全体や設定ファイル全体を公開しないでください。