v2rayNでコアが起動し、ノードに遅延時間が表示されるのにWebサイトを閲覧できない場合に役立つ内容です。まずブラウザーのリクエストがローカルポートに届いているかを確認し、次にルーティング、名前解決、時刻、接続先ノードを調べます。プロキシを明示したテストと同じ宛先での比較により、入口側と外向き通信のどちらに問題があるかを切り分けられます。設定を一度にいくつも変更して判断材料を失わないようにしましょう。
1. 「コアの起動」と「Web閲覧可能」は別
v2rayNは設定を管理し、プロキシコアを起動するクライアントです。画面にコア起動と表示されても、通常はローカルプロセスの起動に成功したことを示すだけです。ノード一覧に遅延時間が表示されても、その時点で該当のテスト結果が得られたことしか分かりません。ブラウザーのリクエストは、ローカルの入口、ルーティング、ノードへの接続、接続先サイトからの応答を経由します。どこか一つでも失敗すれば、Webページが読み込み中のままになることがあります。
以下ではWindowsデスクトップ環境を例に説明します。バージョンによって設定項目の分類が異なる場合があるため、まず「ヘルプ」→「バージョン情報」でバージョンを確認してから、設定名を手掛かりに該当項目を探してください。ポートの例には 127.0.0.1:10808 を使いますが、すべてのバージョンで固定されているわけではありません。古い設定ではHTTPポートに 10809 を使う場合もあります。「設定」→「パラメーター設定」のローカル待ち受け設定と起動ログで実際の値を確認してください。
| 表示されている状態 | 確認できること | 追加で確認すること |
|---|---|---|
| コアの起動に成功 | プロセスが起動し、設定を読み込んだ | 待ち受けポート、システムプロキシ、外向き接続 |
| TCP遅延時間が表示される | テスト時にサーバーのポートへ接続できた | プロトコルのハンドシェイク、認証、TLS、Webサイトの応答 |
| 実接続テストに成功 | 指定したテストリクエストが完了した | ブラウザーの入口、ほかのWebサイト、ルーティングルール |
| ブラウザーにプロキシエラーが表示される | ブラウザーがプロキシを使おうとして失敗した | 実際のプロキシアドレス・ポート・プロセスの状態 |
切り分けでは、ノード、テスト用Webサイト、ネットワークをそれぞれ一つに固定し、変更前後のエラーを記録してください。TUNを有効にする、DNSを変更する、コアを切り替える、サブスクリプションを更新するといった操作を同時に行うのは避けましょう。復旧しても、どの変更が有効だったのか分からなくなります。
2. システムプロキシ：ブラウザーのリクエストがクライアントに届くか確認
システムプロキシはアプリケーションからv2rayNへ通信を渡す方法を決め、ルーティングは受け取った通信の転送先を決めます。ノードを選ぶだけで、すべてのアプリが自動的にそのノードを使うわけではありません。Windowsのシステムプロキシに従うアプリもあれば、個別の設定が必要なアプリもあります。原因を絞り込むには、まずTUNモードを一時停止し、通常のシステムプロキシ経由の通信だけを確認してください。テスト後は元の設定に戻します。
-
システムプロキシを有効にする
メイン画面の下部またはトレイメニューから「システムプロキシ」→「システムプロキシを自動設定」を選びます。入口の確認にPACルールが影響しないよう、まずはPACモードを使わないでください。
-
システム側の入口を確認する
Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」を開き、クライアントが設定したアドレスとポートを確認します。ローカルのHTTPまたは混合待ち受けポートと一致しているか照合してください。
-
ブラウザー側の設定による上書きを確認する
プロキシ設定を変更するブラウザー拡張機能を一時的に無効にします。ブラウザーに個別のプロキシ設定がある場合は、システムプロキシを使う設定にしてください。ブラウザーを再起動し、先ほどのテスト用Webサイトにアクセスします。
-
プロキシを明示してテストする
PowerShellで以下のコマンドを実行します。HTTPプロキシを明示するため、ブラウザーがシステム設定を参照するかどうかに左右されません。ローカルポートがSOCKSのみを提供する場合は、後述のSOCKSテストを使ってください。
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/example.com はテスト用の宛先例です。現在開けないWebサイトに置き換えても構いません。--noproxy "" は、この実行時にプロキシの除外リストが影響しないようにします。HTTPステータスコードが返れば、少なくともHTTP応答は得られていますが、サイトのすべてのリソースが読み込めるとは限りません。プロキシ自体がエラーページを返す場合は、応答内容とコアのログも確認してください。
判定：プロキシを明示したテストが成功するなら、まずブラウザーの入口を確認
同じノード、同じ宛先でコマンドラインからプロキシ経由の応答を受け取れるのに、ブラウザーでは失敗する場合は、システムプロキシ、ブラウザー独自のプロキシ設定、拡張機能を優先して確認してください。ノードの変更やDNSの再設定は後回しにします。
3. ローカルポート：待ち受けプロセスとプロキシ種別を確認
ローカル接続が拒否される場合、通常は通信がリモート側に届く前に問題が起きています。よくある原因はコアの終了、ポートの入力ミス、別プロセスによるポートの占有です。Windowsでは、まず待ち受け状態を確認し、次にプロセスを調べます。プロセスIDが表示されても、すぐにタスクを終了しないでください。
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
# 直前の出力にある OwningProcess の番号を指定して調べる
Get-Process -Id 12341234 はプロセスIDの指定例です。実際には、直前のコマンドで返された値を使ってください。待ち受けの記録がなければ、v2rayNのログに戻り、起動に失敗した原因を確認します。別のプログラムがポートを使用している場合は、まずそのプログラムを正常に終了するか、「設定」→「パラメーター設定」でローカル待ち受けポートを変更し、システムプロキシを再設定してください。
エラー：bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因：Windowsで同じ待ち受けアドレスとポートがすでに使われており、コアがバインドできません。
対処：使用中のプロセスを調べ、重複して起動しているクライアントを終了するか、待ち受けポートを変更してシステムプロキシにも反映します。
エラー：ERR_PROXY_CONNECTION_FAILED
原因：ブラウザーが設定されたプロキシに接続できません。ポートで待ち受けていないか、プロキシアドレスが古くなっている可能性があります。
対処：Windowsのプロキシ設定にあるアドレスとポートを確認し、プロキシを明示したコマンドでテストします。まずローカルの入口を直し、プロトコルの変更は急がないでください。
4. ルーティング設定：想定した出力先へ通信が送られているか確認
ローカルの入口が使えることを確認したら、次にリクエストの振り分け先を調べます。ルーティングルールは通常、上から順に評価され、最初に一致したルールで出力先が決まります。カスタムルールによって特定のドメインが直接接続されたり、遮断用の出力先に送られたりすることがあります。「バイパス」系のプリセットに切り替えた後、一部のWebサイトだけが開けなくなった場合は、すべてをノードの問題と決めつけず、ルールを確認してください。
- 現在の設定を保存：画面下部の「ルーティング」で選択中のプリセットと、カスタムルールの有効・無効を記録しておきます。元の設定に戻すときに役立ちます。
- 一時的に比較する：クライアントにグローバルプロキシのプリセットがある場合は、一時的に選択します。設定の反映を待ってから、同じ宛先を再テストしてください。ここで変更するのはルーティングであり、システムプロキシのオン・オフではありません。
- 接続ログを確認：テストリクエストがコアに届いていることを確認し、表示される宛先アドレスと出力先のタグを調べます。タグ名は設定によって異なり、必ずしも
proxyやdirectとは限りません。 - ルールの範囲を絞る：グローバルプロキシでは使えて元のプリセットでは使えない場合、元のプリセットに戻し、対象ドメイン、IPルール、参照されているルールデータファイルを一つずつ確認します。
「グローバル」と表示されているだけで、すべての通信がプロキシ経由になるとは限りません。通常、対象となるのはコアに届いたリクエストだけです。システムプロキシを使わないアプリは直接接続する可能性があります。ドメインルールとIPルールの動作は、コアの domainStrategy などの設定にも左右されます。一つのWebサイトの問題を解決するためにルーティング全体の動作を変えないよう、切り分け中はデフォルトの方針を維持してください。
5. DNS：本機・コア・ノードアドレスの名前解決を切り分ける
DNSの問題は「Webサイトのドメインを解決できない」ケースだけではありません。ノードサーバーがドメイン名で指定されている場合も、接続の確立前に名前解決が必要です。また、ブラウザーのセキュアDNS、システムのリゾルバー、コアのDNS設定では、異なる経路が使われることがあります。Windowsのキャッシュを消去しても、影響するのは本機の該当キャッシュだけです。ブラウザーやプロキシ側の名前解決結果をすべて消去することはできません。
# システムの名前解決経路を確認する。コアのDNS確認の代わりにはならない
Resolve-DnsName example.com
# SOCKS経由で、宛先ドメインの名前解決をプロキシ側に任せる
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
# 比較用：本機で宛先ドメインを解決してからSOCKSに接続する
curl.exe --noproxy "" --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
# 関連設定を変更した後、必要に応じてWindowsのDNSキャッシュを消去する
ipconfig /flushdns上記のSOCKSコマンドは、ポートがSOCKSに対応していることが前提です。socks5h は宛先ドメインの名前解決をプロキシ側に任せ、socks5 は本機で先に名前解決します。前者は成功して後者が失敗する場合は、本機の名前解決経路を優先して調べてください。ただし、ドメインとIPで異なるルーティングルールに一致して結果が変わることもあります。ログも確認し、一度の結果だけで判断しないでください。
エラー：Could not resolve host
原因：curlが現在使用している名前解決経路で、宛先アドレスを取得できませんでした。このエラーだけでは、ノードのプロトコルに問題があるとは判断できません。
対処：まずシステムの名前解決を確認し、次に2種類のSOCKSテストを比較して、本機側とプロキシ側のどちらで失敗しているかを特定します。
エラー：no such host
原因：ログに記録されたドメインの名前解決に失敗しています。ノードサーバーのドメインか、接続先Webサイトのドメインの可能性があります。
対処：まずエラー付近に記録された完全なドメイン名を確認し、ノードアドレスの入力と実際に使われているDNS設定を調べてください。一時的な検索で取得したIPアドレスに、安易に置き換えないでください。
ブラウザーだけで失敗する場合は、ブラウザーの設定で「セキュア DNS」を検索し、現在の設定を記録してから一時的に無効にし、結果を比較してください。ノードのドメイン解決に失敗する場合は、プロキシ接続がまだ確立されていないのに、その接続に依存する名前解決を行おうとせず、まずプロキシの確立に必要な基本の名前解決経路を直します。
6. システム時刻とノード：ハンドシェイクとサーバー側の問題を確認
システムの日付が大幅にずれていると、TLS証明書の有効期間を正しく判定できないことがあります。一部のプロトコル認証も時刻に関係します。Windowsの時刻設定で表示されるタイムゾーン名だけでは判断できません。重要なのは、システムの実時刻が正確かどうかです。まず時刻を同期してから証明書エラーに対処してください。証明書検証をスキップして修復の代わりにするのは避けてください。
-
システム時刻を同期する
Windowsの「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」を有効にします。タイムゾーンを確認して「今すぐ同期」をクリックしてください。同期に失敗する場合は、まず基本のネットワーク接続と時刻サービスを確認します。
-
ノードの設定項目を確認する
現在のノードの編集画面を開き、サーバー提供元の設定と照らし合わせて、サーバーアドレス、ポート、ユーザーID、トランスポート方式、TLSサーバー名、および使用プロトコルで必要なパラメーターを確認してください。異なるノードの設定項目を混ぜて使わないでください。
-
別のノードと比較する
システムプロキシ、ルーティング、DNSは変更せず、同じサブスクリプション内で、動作確認済みの別ノードに切り替えます。元のノードだけが失敗する場合は、提供元の有効期限、利用可能な通信量、回線の状態を確認してください。
-
接続するネットワークを切り替える
それでも切り分けられない場合は、スマートフォンのテザリングで同じノード、同じ宛先を再テストします。ネットワークによって結果が大きく異なる場合は、現在のネットワークの接続制限、ポータル認証、回線の問題を調べてください。
エラー：x509: certificate has expired or is not yet valid
原因：本機の時刻が正しくないか、接続先が提示した証明書の有効期間が切れている、または有効開始前です。
対処：システム時刻を同期して再試行します。それでも発生する場合は、ノードのTLS名を確認し、証明書の設定をサーバー提供元に確認してもらってください。
エラー：i/o timeout
原因：ネットワーク操作が制限時間内に完了しませんでした。接続、ハンドシェイク、応答の読み取りのいずれかで発生する可能性があります。
対処：エラー前後の宛先アドレスから発生段階を特定し、ノードとネットワークを変えて比較してください。タイムアウトをDNSエラーと決めつけないでください。
VLESSとREALITYを使う場合、クライアントで選択したコアが該当設定に対応し、サーバー提供元から指定された公開鍵、サーバー名、ショートIDなどが正しく入力されている必要があります。同じV2Rayエコシステムの製品だからといって、コアごとの対応範囲が完全に同じとは限りません。TCPポートに接続できても、ハンドシェイクのパラメーターが正しいとは限りません。
判定：ノードの変更だけで復旧したら、ローカル設定はそのままにする
同じ入口と宛先でノードを変更すると安定して応答が得られる場合は、現在のローカル設定を維持し、元のノードのパラメーター、サーバーの状態、回線を重点的に確認してください。ポートやDNSを同時に変更するのは避けます。
7. よくある質問と復旧後の確認
ノードの遅延が80msなのに、Webサイトが開けないのはなぜ？
80msは遅延時間の例にすぎず、Webサイト全体が利用できる証明にはなりません。まず、使ったテストがTCP遅延テストか実接続テストかを確認します。次にプロキシを明示して、現在開けないWebサイトへアクセスし、コアのログにリクエストが届いているかを確認してください。
v2rayNを終了したら、通常のWebサイトまで開けなくなったのはなぜ？
システムにローカルポートを指すプロキシ設定が残っている可能性があります。クライアントを再起動し、「システムプロキシ」から「システムプロキシを解除」を選びます。またはWindowsの「ネットワークとインターネット」→「プロキシ」を開き、残っている手動プロキシをオフにしてから、直接接続できるか確認してください。
Webサイトが一つだけ開けません。クライアントを再インストールすべきですか？
まず同じノードで別のHTTPSサイトにアクセスし、そのドメインに適用されるルーティングルール、名前解決結果、応答ステータスを確認してください。403または429が返っている場合、HTTP応答は得られています。再インストールする前に、サイト側のアクセス制限やレート制限を調べましょう。
TUNを有効にすると直る場合、システムプロキシも修正する必要がありますか？
入口となる経路はそれぞれ異なるため、TUNが使えてもシステムプロキシの設定が正しいとは限りません。普段システムプロキシを使うなら、TUNを一時停止してからポート確認とプロキシを明示したテストをやり直してください。TUNを使う場合も、ほかの通信制御ソフトと同時に有効にしないようにします。
切り分けが終わったら、一時的に変更したルーティング、ブラウザーのDNS、ログレベルを元に戻し、不要になったテスト設定を削除します。解決しない場合は、クライアントとコアのバージョン、問題の発生時刻、プロキシ入口のポート、テストした宛先、個人情報を伏せたエラーの抜粋をまとめてください。スクリーンショットを共有する前に、サブスクリプションURL、ノードの認証情報、個人のネットワーク情報を隠します。「接続済みと表示される」という情報だけよりも、原因の特定に役立ちます。