サーバーを選択済みで、コアも起動しているように見えるのに、ブラウザーがタイムアウトする、または接続を拒否される場合に役立ちます。まずブラウザーのリクエストがv2rayNに渡っているか確認し、次にローカルの待ち受け、リモートサーバー、TLSハンドシェイクを調べます。最後にルーティングとファイアウォールを確認してください。一度に変更するのは1項目だけにし、同じURLでテストを続けることで、偶然の復旧を解決と誤認しないようにします。
1. システムプロキシ：ブラウザーの通信がコアに届いているか確認
「接続済み」はWebページを開けることの証明にはなりません。サーバーを選択すると以降の通信にその設定が使われ、コアが起動するとプロセスが実行されます。しかし、ブラウザーがプロキシを使っているか、サーバーが接続を受け付けるか、Webサイトが応答するかは、それぞれ別の確認が必要です。まずメイン画面の「TUNを有効にする」を一時的にオフにし、システムプロキシだけで基本の動作をテストします。2つの方式を同時に使うと原因を特定しにくくなります。
-
システムプロキシを設定する
v2rayNのメイン画面で「システムプロキシ」→「システムプロキシを自動設定」を選びます。画面によってはウィンドウ下部に項目があります。タスクトレイの右クリックメニューからも設定できます。「システムプロキシを解除」や「システムプロキシを変更しない」のままにしないでください。
-
システム設定を確認する
Windows 11で「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」を開きます。プロキシサーバーが有効か、アドレスが
127.0.0.1か、ポートがクライアントで実際に使っているHTTPまたは混合待ち受けポートと一致しているか確認してください。 -
ブラウザー独自の設定を確認する
ブラウザーのプロキシ拡張機能を一時的に無効にします。EdgeやChromeは通常、システムプロキシの設定に従います。Firefoxでは「設定」→「一般」→「ネットワーク設定」→「接続設定」を開き、「システムのプロキシー設定を利用する」が選択されているか確認してください。
-
新しいログを確認する
以前開けなかったHTTPSページにアクセスしながら、メイン画面のログまたは接続一覧を確認します。該当ドメインへの新しいリクエストがあれば、少なくともリクエストはコアに届いています。記録がまったくない場合は、サーバーを変更する前にブラウザーのプロキシ設定を確認してください。
バージョンによってはログレベルの設定でアクセス記録が表示されないことがあります。そのため、「記録がない」ことは手がかりにすぎず、決定的な証拠ではありません。後述する明示的なプロキシ指定コマンドを使えば、システムプロキシの設定を介さずにローカルの接続口を直接確認できます。
2. 待ち受けポート：未起動とポート競合を切り分ける
「設定」→「パラメーター設定」を開き、ローカルの待ち受けポートを確認します。新しいバージョンのv2rayNでは、HTTPとSOCKSの両方を受け付ける混合ポートとして10808がよく使われます。古い設定ではSOCKSとHTTPにそれぞれ10808、10809を割り当てる場合があります。古いガイドに記載されたポートをそのまま現在のシステム設定に入力しないでください。以下のコマンドは、実際の混合ポートが10808であることを前提としています。
netstat -ano | findstr :10808
curl.exe -I --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://www.microsoft.com/netstatの出力に、ローカルアドレスに対応するLISTENINGの行があることを確認します。最後の列はプロセスのPIDです。「タスク マネージャー」→「詳細」からPIDでプロセスを探し、待ち受けているのが今回起動したコアであり、別のクライアントではないことを確認してください。コマンドの10秒は接続タイムアウトの上限、20秒はリクエスト全体の上限で、実際のネットワーク遅延を表すものではありません。
| 確認できたこと | まず判断すること | 次に行うこと |
|---|---|---|
| LISTENINGの行がない | ポートの指定ミス、またはコアの起動失敗 | 起動ログを確認し、設定エラーを修正してからサーバーを選び直す |
| 待ち受け中のPIDが別のプログラム | ポート競合 | 競合しているプロセスを終了するか、ローカルポートを変更してシステムプロキシにも反映する |
| 明示的なプロキシ指定で対象サイトのHTTP応答があるのに、ブラウザーでは失敗する | ローカルの接続口と今回のリクエストはおおむね正常 | ブラウザー拡張機能、個別のプロキシ設定、キャッシュされた接続を確認する |
| ローカルの待ち受けは正常だが、リクエストがタイムアウトし続ける | リモート接続、DNS、ルーティングに問題が残っている | サーバーを続けてテストし、同じ時刻のエラーログを確認する |
結論：まず接続口を固定し、その後に外向きの通信を確認
明示的なプロキシ指定コマンドで対象サイトからの応答を確認できた場合は、現在のサーバーとポートを維持し、ブラウザーのプロキシ経路だけを調べます。HTTP CONNECTの接続確立メッセージが表示されただけでは、その後のTLSハンドシェイクと対象サイトからの応答を確認する必要があります。アクセス成功と早合点しないでください。
3. サーバーの接続確認：Tcpingの成功はプロキシの成功ではない
サーバー一覧で対象を選び、右クリックメニューから「サーバーへの実接続遅延をテスト」を実行します。「サーバー遅延をテスト Tcping」と比較してもかまいません。メニュー名はバージョンによって多少異なりますが、「TCPポートに接続できること」と「プロキシリクエストが最後まで完了すること」を区別するのが重要です。サブスクリプションのインポートに成功しても、設定を読み込めたことを示すだけで、サーバーが現在も使えるとは限りません。
- Tcpingは成功するが、実接続に失敗する：プロトコル、ポート、ユーザーID、トランスポート方式、TLSのserverName、サーバー側で指定されたその他の認証パラメーターを優先して確認します。TCPハンドシェイクだけでは、これらの設定は検証されません。
- どちらもタイムアウトする：サーバーのドメイン名が解決できるか、リモートポートでサービスが稼働しているかを確認し、同じサーバーを別のネットワークでもテストして比較します。
- 実接続は成功するが、特定のWebサイトだけ開けない：別のHTTPSサイトもテストします。速度テストの接続先は異なるルールに一致する場合があるため、対象ドメインのルーティングやサーバー側の制限が原因ではないとは言い切れません。
- 別のサーバーなら正常：まず正常なサーバーを比較対象として残し、問題のあるサーバーのサブスクリプション内容を確認します。クライアントの再インストール、DNSのリセット、ファイアウォールの変更を同時に行わないでください。
VMessとVLESSはそれぞれ別のプロトコル設定で、相互に置き換えられるものではありません。「試しに」プロトコルを切り替えたり、TLSの検証条件を削除したりしないでください。提供元がアドレスや認証パラメーターを変更した場合は、「サブスクリプショングループ」メニューから対象のサブスクリプションを更新し、選択中のサーバーが更新後の設定を参照していることを確認してください。
エラー：connection refused
原因と対処：接続先のポートに接続を拒否されています。まずエラーに表示されたアドレスを確認してください。127.0.0.1:10808ならローカルの待ち受けを修正し、サーバーのアドレスならリモートポートとサービスの稼働状況を確認します。
エラー：i/o timeout
原因と対処：処理のどこかで読み書きがタイムアウトしています。このメッセージだけでは問題の場所を特定できません。完全なログに記録された接続先アドレスをもとに、サーバーへの接続、DNSの問い合わせ、対象サイトからの応答をそれぞれ確認してください。
4. システム時刻とTLS：検証を無効にしてエラーを回避しない
システム時刻が大きくずれていると、証明書の有効期間の判定に影響します。時刻を検証するプロトコル認証にも影響する場合があります。Windowsの「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにして、タイムゾーンを確認してから「今すぐ同期」をクリックしてください。重要なのは日付と実際の時刻が正しいことです。デスクトップに表示された時刻が近いだけでは不十分です。
エラー：x509: certificate has expired or is not yet valid
原因と対処：証明書の期限切れ、適用開始前、またはパソコンの時計のずれが考えられます。まずシステム時刻を同期してください。時刻が正しいのに再発する場合は、サーバーの管理者に証明書の有効期間を確認してもらいます。
エラー：x509: certificate signed by unknown authority
原因と対処：証明書チェーンを信頼できないか、ネットワーク上でHTTPS通信が検査されている可能性があります。サーバーの証明書チェーンとネットワーク環境を確認し、証明書検証を無効にしないでください。
TLSを使うサーバーでは、接続先アドレスと証明書検証に使うserverNameが異なる場合があります。サーバー側の設定に従って入力してください。serverNameをよく知られたWebサイトのドメインに安易に変更しないでください。REALITYを使うサーバーでは、公開鍵、shortId、サーバー指定のserverNameも確認します。これらのパラメーターに誤りがある場合、ローカルの待ち受けポートを変えても解決しません。
5. ルーティングとDNS：全般モードは原因の切り分けにのみ使う
最初の4項目に問題がなければ、メイン画面の「ルーティング」設定を確認します。現在のルール名を記録してから、一時的に組み込みの「全般」モードを選び、同じURLに再度アクセスします。一般的なプロキシ通信では、元の直接接続、プロキシ、ブロックのルールが誤っているかどうかを判断する手がかりになります。ただし、すべてのアプリやDNSリクエストがプロキシ経由になったことを意味するわけではありません。
| 比較した結果 | 考えられる原因 | 確認する場所 |
|---|---|---|
| 全般モードでは使えるが、元のルールでは失敗する | 対象への直接接続、ブロック、または不適切な出口が選ばれている | 「設定」→「ルーティング設定」でルールの順序と対象ドメインの条件を確認する |
| ログにno such hostと表示される | ドメイン名を解決できない | 解決できないのがサーバーのアドレスか対象サイトかを見分け、該当するDNS経路を確認する |
| カスタムルーティングを使った場合だけ起動に失敗する | ルールの構文エラー、または必要なデータファイルを利用できない | 組み込みルールに戻し、起動ログに記録された具体的なフィールドやファイルのエラーを確認する |
| 全般モードでも元のルールでも失敗する | 原因がルーティングとは限らない | サーバーのハンドシェイクとローカルの接続口を見直し、ドメインルールを重ねて追加しない |
ルーティングルールは通常、上から順に評価されます。先にある大まかなルールが、後ろの詳細なルールより優先される場合があります。geosite:cnやgeoip:privateなどを使う場合は、現在のコアが必要なデータを読み込めることも確認してください。Xrayと他のコアでは設定形式が異なる部分があるため、別のコア用の設定をまとめて貼り付けないでください。
- Windowsターミナルで
nslookup www.microsoft.comを実行すると、現在のシステムの名前解決経路を確認できます。ただし、コアのリモートDNSが正常であることの証明にはなりません。 - システムDNSキャッシュが原因と思われる場合は、関連設定を変更してから
ipconfig /flushdnsを実行し、ブラウザーを再起動してテストします。キャッシュの削除でサーバーの認証エラーは解決できません。 - テスト後は元のルーティングに戻し、ルールを1つずつ修正してください。一時的な全般モードを、あらゆるDNS問題の恒久的な解決策にしないでください。
6. ファイアウォールとTUN：最後に権限とブロックを確認
ローカルの待ち受け、サーバーのパラメーター、名前解決に問題がない場合に限り、セキュリティソフトのブロック履歴を確認します。「Windows セキュリティ」→「ファイアウォールとネットワーク保護」→「詳細設定」を開き、「送信の規則」に現在のコア実行ファイルを対象にしたブロックルールがないか確認してください。クライアントの更新で実行ファイルの場所が変わることがあるため、古いルール名だけで判断せず、実際のファイルの場所を確認します。
- ローカルプロキシだけをテストする場合：通常、LANへの待ち受け公開や、ルーターでの
10808のポート転送は不要です。Webページを開けるようにするために「LANからの接続を許可」を有効にしないでください。 - 明確なブロック記録がある場合：信頼できるクライアントと現在のコアに限り、必要な通信を許可するルールを作成してください。ファイアウォールやセキュリティ機能全体を恒久的に無効にしないでください。
- システムプロキシは正常だが、TUNで失敗する場合：クライアントの案内に従って必要な管理者権限を取得し、仮想ネットワークアダプターとルートの作成ログを確認します。通信を横取りする他のソフトを終了してから比較テストしてください。
- 職場や学校のネットワークを使っている場合：まずネットワーク管理規定に従ってください。同じ設定が別のネットワークでは動作する場合は、ネットワークの違いを記録し、端末の権限をむやみに広げず、管理者に出口のポリシーを確認します。
7. よくある質問：復旧後の確認
ブラウザーでは通信できるのに、ターミナルのコマンドがタイムアウトするのはなぜ？
多くのコマンドラインアプリはWindowsのシステムプロキシを自動的に使いません。まず前述のcurl.exe --proxyコマンドで接続先を明示します。成功を確認したら、そのツールの設定方法に従ってプロキシを設定してください。ブラウザーで通信できるからといって、ターミナルでも使えるとは限りません。
v2rayNを終了したら、通常のWebページも開けなくなった
システムプロキシが停止中のローカルポートを参照したままになっていないか確認します。v2rayNを再起動して「システムプロキシ」→「システムプロキシを解除」を選ぶか、Windowsのプロキシ設定で今回設定した手動プロキシをオフにしてから、ブラウザーを再起動してテストしてください。
実接続の遅延は表示されるのに、Webページが読み込み中のままなのはなぜ？
速度テストで確認できるのは、そのテスト先と実行時のリクエストだけです。同じ失敗するドメインを使ってログを確認し、一時的に組み込みの「全般」ルーティングと比較してください。そのサイトだけが失敗する場合は、サイトのルーティングと接続先のサービスを優先して調べます。速度テストの数値は、すべてのサイトが使える証明にはなりません。
最後まで確認しても解決しない場合、どの情報を伝えればよい？
v2rayNとコアの具体的なバージョン、OSのバージョン、プロキシモード、ローカルポート、問題が発生した時刻付近のログを記録してください。共有する前に、サブスクリプションURL、ユーザーID、認証パラメーター、個人のアドレスを伏せます。エラーの原文、発生した処理の段階、テスト手順は残してください。
解決後は、変更した手順を逆にたどって後片付けします。普段使うルーティングルールに戻し、一時的な変更を取り消し、ブラウザーとプロキシを必要とするアプリで通信できることを確認します。クライアントを終了した後は、システムプロキシが正しく解除されているか確認してください。正常に動作したポート、サーバー、ルール名を記録しておけば、次回のアップデート後もすぐに比較できます。