v2rayNは起動してノードも選択済みなのに、ブラウザーがタイムアウトする、一部のサイトが開かない、サブスクリプションを更新できない場合に役立つチェックリストです。まずブラウザーの通信がローカルプロキシに届いているかを確認し、次に名前解決、ルール、サーバーへの接続を調べます。主にWindowsを対象に、ローカルポート、コマンド出力、ログの時刻を手がかりに問題箇所を絞り込みます。むやみに再インストールしたり、複数の設定を同時に変更したりする必要はありません。
1. コアの起動とWeb接続を切り分ける
v2rayNはクライアントの画面で、実際の通信は選択したコアが処理します。ノードの選択、コアの起動、システムプロキシの有効化、Webサイトへの接続はそれぞれ別の段階です。画面に実行中と表示されても、通常はローカルプログラムが処理を開始したことしか分かりません。リモートサーバーとの認証が完了したとも、すべてのアプリがプロキシを使っているとも限りません。
ノード一覧に表示されるTCP遅延も、Webサイトへの接続確認の代わりにはなりません。TCP接続が確立できても、その段階で確認できるのはTCPレベルの到達性だけです。VLESSやVMessの設定、TLSハンドシェイク、接続先サイトへのアクセスで失敗することもあります。プロトコルをすぐに変更するのではなく、まずどの範囲で問題が起きているかを記録しましょう。
- すべてのアプリがインターネットに接続できない：まずシステムプロキシを一時的に解除し、通信を処理しているTUNモードを終了して、通常のネットワーク接続が戻るか確認します。
- ブラウザーだけ接続できない：ブラウザー独自のプロキシ設定、プロキシ拡張機能、セキュアDNSを優先して確認します。
- 一部のドメインだけ接続できない：DNS、ルールの適用状況、接続先サイトの応答を確認します。ノード全体が使えないとすぐに判断しないでください。
- ノードを切り替えた直後から接続できない：切り替えた時刻を記録し、その後のコアログを確認します。古い接続やエラーが調査に影響していないか確かめましょう。
2. システムプロキシとブラウザーの設定を確認する
システムプロキシは、その設定に従うアプリの通信先を指定するもので、すべてのプログラムの通信を自動的に取り込むものではありません。ブラウザー独自のプロキシ拡張機能が有効だと、Windowsの設定を使わない場合があります。ターミナルのツールも、コマンドライン引数や環境変数だけを参照することがあります。そのため、「ブラウザーで開けない」問題と「コアが通信を転送できない」問題は分けて確認しましょう。
-
使用するノードを設定する
v2rayNのサーバー一覧で対象の項目を右クリックし、「アクティブサーバーに設定」を選択します。画面下部のアクティブサーバー情報が更新されたことを確認し、コアが正常に起動するか見てください。
-
システムプロキシを有効にする
メイン画面下部の「システムプロキシ」メニューから「システムプロキシを自動設定」を選びます。通知領域のアイコンから同じメニューを開くこともできます。原因を調べている間は、通信経路が分かりにくくなるためTUNを同時に有効にしないでください。
-
プロキシのアドレスを確認する
Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとクライアントの待ち受け設定を照合します。ループバックアドレスは通常
127.0.0.1です。ポートは、実際に使用しているHTTPまたは混合プロキシの待ち受けポートと一致している必要があります。 -
ブラウザー独自の設定を確認する
ブラウザーのプロキシ拡張機能を一時停止し、独自のプロキシ設定をシステムプロキシ使用に変更してから、ブラウザーを再起動します。同じURLを使って先にテストし、DNSやルーティングは同時に変更しないでください。
システムプロキシを解除すると通常のサイトが開き、再び有効にするとすべて接続できなくなる場合、問題がプロキシ経路に関係していることは分かりますが、ノードが使えないとは限りません。次にローカルポートで実際に待ち受けているか、ブラウザーのプロキシプロトコルが待ち受け方式と一致しているかを確認します。
3. ローカルポートと明示的なプロキシ接続で問題箇所を絞る
v2rayNの「設定」→「パラメーター設定」で、ローカルの待ち受け設定を確認します。項目の場所は現在のバージョンによって異なります。混合ポートは対応する複数のプロキシプロトコルを受け付けますが、SOCKS専用の待ち受けをHTTPプロキシとして使うことはできません。以下のコマンドはWindowsターミナルで実行します。HTTPまたは混合プロキシのポートを10808と仮定した例です。
netstat -ano | findstr :10808
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/netstatの出力では、ポート番号が表示されているかだけでなく、ローカルアドレスとLISTENINGの状態、PIDを確認してください。タスクマネージャーの「詳細」タブでPIDを検索し、現在のクライアントが起動したコアがポートを使用していることを確かめます。実行元が分からないシステムプロセスを終了しないでください。
| 確認結果 | 判断できること | 次に行うこと |
|---|---|---|
| ローカルポートで待ち受けていない | 通信がプロキシコアに届いていない | 起動ログ、設定の読み込みエラー、ポートの競合を確認する |
| 明示的なプロキシ接続は成功するが、ブラウザーは失敗する | テスト先へのプロキシ経路は利用できる | システムプロキシ、ブラウザー拡張機能、ブラウザーのDNS設定を確認する |
| HTTP 403または405が返る | HTTP応答は受信できており、接続タイムアウトとは異なる | 証明書、レスポンスヘッダー、ほかのサイトの結果をもとに制限の原因を判断する |
| 直接接続は成功するが、明示的なプロキシ接続はタイムアウトする | プロキシ経路に問題が集中している | 該当リクエストの名前解決、アウトバウンド、ハンドシェイクのログを確認する |
ポイント：アプリの入口と外部への接続経路を分けて確認する
同じURLへの明示的なプロキシテストで応答が返るのに、ブラウザーがタイムアウトする場合は、まずブラウザーからローカルポートまでの経路を修正します。この段階でサブスクリプションを何度も更新したり、ノードを切り替えたりしても、入口の設定ミスは解決しないことがほとんどです。
待ち受けポートがSOCKS専用の場合は、--proxy socks5h://127.0.0.1:10808を使って別途テストできます。ここでのsocks5hは、接続先のドメイン名をプロキシ側で解決する指定です。ローカルでドメインを解決してからSOCKSに渡すテストとは結果が異なります。
4. DNSの問題を2段階に分けて確認する
DNSは接続先サイトの名前解決だけに関係するわけではありません。ノードのアドレスがドメイン名の場合、コアは通常、まずノードのドメイン名をIPアドレスに解決する必要があります。ここで失敗すると、プロキシ接続を開始できません。接続先サイトのドメイン名は、ローカル、コアに設定されたリゾルバー、またはリモート側で解決されることがあり、実際の処理は接続方式、ルーティング、DNS設定によって異なります。
nslookup example.com
ipconfig /flushdnsnslookupを使うと、Windowsの現在の既定の名前解決経路を確認できます。ただし、v2rayN内蔵DNSやブラウザーのセキュアDNSを経由するとは限りません。アドレスが返ってきても、その問い合わせで結果を受け取れたことしか分からず、現在のネットワークでそのアドレスが使えることやプロキシ経路が正常なことまでは確認できません。システムのDNSキャッシュを消去しても、ブラウザーやコアに個別のキャッシュが残る場合があります。
- まずノードのドメイン名を確認：ノードの編集画面でサーバーアドレスを確認し、余分な空白や誤った文字がないか、ドメインの有効期限が切れていないかを調べます。
- 次に接続先のドメイン名を確認：同じ接続先に対するシステムの名前解決結果とコアログを照らし合わせ、名前解決の失敗と、その後の接続タイムアウトを切り分けます。
- ブラウザーのセキュアDNSを確認：一時的にシステムの名前解決を使う設定に戻して比較し、結果を記録してからどの経路を使うか判断します。
- コアのDNS設定を確認：現在のバージョンに「設定」→「DNS設定」がある場合は、リゾルバーのアドレスと、リゾルバーへの通信に使うルートを確認します。ノードのドメイン名を解決する通信が、まだ確立していない同じプロキシ接続に依存しないようにしてください。
5. ルーティングと実際のアウトバウンドを確認する
システムプロキシを有効にしても、コアに届いたすべてのリクエストがプロキシサーバーを経由するとは限りません。ルールによって、ドメイン名やIPアドレスが直接接続、プロキシ、ブロックのいずれかに振り分けられます。ルールは通常、上から順に評価されます。先にある範囲の広いルールが、後の細かいルールより優先される場合があります。IPルールが適用される理由を理解するには、ドメイン名の解決方式も確認してください。
- メイン画面下部の「ルーティング」メニューで現在のプリセットを記録します。カスタムルールがある場合は、先にバックアップを取り、テスト対象がプロキシ経由になることを明示したプリセットまたはルールを一時的に選択します。
- 接続先サイトを1つだけ開き、時刻を記録します。ログの詳細度を設定できる場合は、接続先ドメイン、インバウンド接続、選択されたアウトバウンドのタグを探し、意図せず直接接続されたりブロックされたりしていないか確認します。
- カスタム設定を手動で変更した場合は、ルールが参照するアウトバウンドタグが存在するか確認します。画面に表示されるノード名と、コアのアウトバウンドタグは別のものです。
- 元のプリセットに戻して再テストします。ルールを切り替えたときにだけ安定して違いを再現できる場合は、まずルールを修正します。ノードとDNSを同時に変更しないでください。
TUNは別の通信入口で、仮想ネットワークアダプター、ルーティングテーブル、権限も関係します。明示的なプロキシ接続は正常でTUNだけ失敗する場合は、ブラウザーのシステムプロキシではなく、TUNの起動ログとシステムルートを確認します。モードごとに分けて検証すれば、ネットワークアダプターの問題をプロトコルの問題と誤認せずに済みます。
6. エラーメッセージからノードとサブスクリプションを確認する
ローカルの待ち受けとアプリの入口を確認してから、リモート接続を調べます。以下はログに出る可能性があるエラーの一部です。コアやシステムによって、実際のメッセージ全文は異なります。キーワードだけで判断せず、前後に記録された接続先アドレスと時刻を確認してください。
エラー：bind: address already in use
原因：起動時にバインドしようとしたアドレスまたはポートが、すでに使用されています。対処方法：ログに記録された実際のポートからPIDを調べ、重複して起動したインスタンスを終了するか、待ち受けポートを変更してシステムプロキシの設定も更新します。
エラー：connection refused
原因：接続先のポートで接続が拒否されています。ローカルの待ち受けポートでも、リモートノードでも起こり得ます。対処方法：まずエラーに記録されたIPアドレスとポートを確認します。ローカルアドレスならコアの状態を、リモートアドレスならサーバーのポートとサービスの状態を調べてください。
エラー：no such host
原因：該当ドメイン名を、その時点で使用していた名前解決経路からIPアドレスに解決できませんでした。対処方法：エラーに記録されたドメインがノードと接続先サイトのどちらかを確認し、対応するリゾルバー、ドメイン名の入力、DNSへの通信経路を調べます。
エラー：context deadline exceeded
原因：処理が所定の時間内に完了しませんでした。このメッセージだけでは、DNS、接続、ハンドシェイクのどの段階で失敗したかは判断できません。対処方法：前後のログから段階を特定し、同じ接続先を使って、正常に使えることが分かっている別のノードと比較します。
ノードを編集するときは、サービス提供元が現在指定している値と、サーバーアドレス、ポート、ユーザーID、トランスポート方式、TLS、サーバー名を1つずつ照合します。VMessとVLESSは異なるプロトコルです。プロトコル名だけを変更して、ほかの項目をそのまま流用することはできません。REALITYを使う設定では、公開鍵やShort IDなどの値と、実行中のコアがその設定に対応しているかも確認します。
証明書の有効期間やハンドシェイクの異常は、システム時刻のずれが原因の場合もあります。Windowsの「設定」→「時刻と言語」→「日付と時刻」で時刻の自動設定を確認し、時刻を同期してください。アドレスや時刻の誤りを隠すために、証明書の検証を無効にしないでください。
- サブスクリプションに項目があっても、有効とは限りません：最終更新の結果、サービスの有効期限、通信量の残量を確認し、古いノードが入れ替わっていないか調べます。
- サブスクリプションの更新失敗は、Webサイトへのプロキシ接続失敗とは限りません：更新リクエストは別の経路を使うことがあります。現在のバージョンに、プロキシ経由で更新する設定があるか確認してください。
- ログを共有する前に機密情報を隠す：サブスクリプションのURL、ユーザーID、認証情報を伏せ、時刻、エラーメッセージ、必要なポート情報は残してください。
7. よくある質問と復旧後の確認
遅延が80ミリ秒なのに、Webサイトがタイムアウトするのはなぜですか？
ここでの80ミリ秒はTCPテストの仮の結果であり、Webページの読み込み時間ではありません。まずテストの種類を確認し、次に明示的なプロキシ接続を試してください。TCPで接続できても、ユーザー認証、TLSハンドシェイク、接続先サイトへのアクセスで失敗する場合があります。
ポートを変更したのに、ブラウザーが接続できないのはなぜですか？
「システムプロキシ」で一度設定を解除してから「システムプロキシを自動設定」を選び、Windowsのプロキシポートを確認してください。ブラウザーの拡張機能に古いポートが設定されている場合は、拡張機能の設定も変更してブラウザーを再起動します。
v2rayNを終了すると、通常のWebページも開けなくなるのはなぜですか？
Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、ローカルの待ち受けサービスが終了した手動プロキシを無効にします。TUNを有効にしていた場合は、停止していることも確認してください。通常のネットワーク接続が戻ったら、クライアントを起動して各項目を順に確認します。
設定をすべて削除して再インストールする必要はありますか？
まず削除しないでください。現在の設定を保存してエラーを記録します。設定を読み込めない、プログラムファイルが見つからない、互換性の問題が明らかといった場合に限り、ダウンロードページから適切なバージョンを入手して比較します。再インストールしても、無効になったノードや誤ったサブスクリプションは自動的に修復されません。
修復後は同じURLを使って、ブラウザーからのアクセスと明示的なプロキシ接続を再テストし、普段使うサイトも確認します。元のルーティング、ブラウザー拡張機能、TUNの設定は1つずつ戻し、設定を戻すたびにテストしてください。特定の設定を戻すと問題が再発した場合は、その再現結果を記録して調査を続けます。
- 想定したコアがローカルポートで待ち受けており、システムプロキシが正しいアドレスとポートを指定している。
- 接続先から妥当な応答があり、ログに接続や名前解決のエラーが繰り返し記録されていない。
- クライアントを再起動しても接続でき、終了後のシステムのネットワーク状態も想定どおりである。