「接続済み」は、通常、コアが起動したかプロキシインターフェースが確立したことを示すだけで、Webサイトにアクセスできるとは限りません。この記事ではWindows版v2rayNを例に、まずノードとシステム時刻を確認し、DNS、ルーティング、ローカルの待ち受けを切り分けます。Androidでも同じ順序で確認できます。一度に変更する項目は一つにし、同じURLで再テストすると、一時的な復旧を設定の正しさと取り違えにくくなります。
1. コアの起動とWebリクエストの成功を切り分ける
まず現在の設定を残し、選択中のノード、プロキシモード、テスト用URL、失敗した時刻を記録します。クライアントのログを開いてから、Webページを一度更新してください。ステータス欄の「実行中」より、ログに新しい記録が追加されたかどうかのほうが、リクエストの到達状況を判断する手がかりになります。この段階でサブスクリプションの更新、DNSの変更、TUNの有効化を同時に行うのは避けましょう。復旧しても原因を特定しにくくなります。
v2rayNは設定・管理用のクライアントで、実際の接続は選択したコアが処理します。V2RayやXrayはステータスボタンの名称ではありません。Android版のv2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。VPNインターフェースが確立していても、ノード認証、名前解決、外向き接続の段階で失敗することがあります。
| 表示されている状態 | わかること | 次の確認 |
|---|---|---|
| コアが実行中 | プロセスが起動した状態。リクエストの成功を示すものではありません | Webページを更新し、新しいログを確認する |
| ノードに遅延時間が表示される | 何らかのプローブに応答があった | 実際のHTTPSリクエストを試す |
| ブラウザーにプロキシ接続エラーが表示される | ローカルのプロキシ入口に接続できていない可能性があります | 待ち受けアドレスとポートを確認する |
| 一部のWebサイトだけ開けない | ドメインルール、名前解決、接続先サイトが原因の可能性があります | 失敗したドメインの外向き接続ログを確認する |
2. ノードを確認：ポートに接続できても認証成功とは限らない
まずプロキシを無効にし、現在のネットワークで通常アクセスできるWebサイトを開いて、端末の基本的なインターネット接続を確認します。次にプロキシを有効にして、同じHTTPS URLを現在のノードと、利用できることが確認済みの別のノードで試してください。別のノードでのみ復旧した場合は、クライアントの再インストールよりも、最初のノード設定またはサーバー側の問題を優先して疑います。
-
現在のノードを確認する
v2rayNのメイン画面で、実際に有効になっているサーバーを確認します。行を選択しただけでは、アクティブなサーバーに設定されたとは限りません。現在のバージョンで「アクティブなサーバーに設定」に相当する操作を行って切り替え、ログを確認してください。
-
接続設定を確認する
サーバーの編集画面を開き、サブスクリプションの情報と照らし合わせて、アドレス、ポート、認証情報、トランスポート方式、TLS設定を確認します。WebSocketを使う場合はパスとHostも確認してください。HostとTLSのserverNameは別の項目なので、同じものとして安易に置き換えないでください。
-
別のノードと比較する
ルーティング、DNS、プロキシモードは変えずに、ノードだけ切り替えて再試行します。すべてのノードで失敗する場合は、時刻とローカルの通信取り込みを確認します。特定のノードだけ失敗する場合は、該当するサブスクリプションを更新するか、サービス提供元に問い合わせてください。
-
コアの対応状況を確認する
設定の読み込みエラーが発生した場合は、現在のコアが該当するプロトコルとトランスポートの組み合わせに対応しているか確認します。VMessとVLESSは名前が似ていますが、認証方式や設定項目は互換ではありません。ノードのパラメーターを別のプロトコル用に手動で書き換えるのも避けてください。
遅延テストではTCP接続だけを確認する場合があります。一部のテスト機能はHTTPリクエストを送信するため、結果の意味は選択した機能によって異なります。ノードのポートに接続できても、TLSハンドシェイク、ユーザー認証、サーバーからの外向き接続が失敗することがあります。サブスクリプションの更新に成功したことも、設定内のすべてのノードが使える証明にはなりません。
3. システム時刻を同期してから、TLSと認証のログを確認する
証明書や認証のエラーに対処する前に、パソコンの実際の時刻を修正します。Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにして「今すぐ同期」をクリックします。日付、年、タイムゾーンも確認してください。表示上のタイムゾーンだけを変更しても、システム時計のずれが直るとは限りません。同期後にコアを再起動し、もう一度リクエストを送信します。
- VMess：認証には時刻に関する検証が含まれます。クライアントとサーバーの時刻に大きなずれがあると、接続に失敗することがあります。許容範囲は実装によって異なるため、すべてのノードに共通する秒数を基準に判断しないでください。
- TLS：システムの日付が正しくないと、証明書が有効期間前または期限切れと判定されることがあります。時刻を修正しても証明書エラーが続く場合は、serverName、サーバー証明書、ネットワーク上の干渉を確認してください。
- その他の認証：VLESSの認証方式にVMessの説明をそのまま当てはめることはできません。ただし、接続にTLSを組み合わせている場合は、システム時刻が正しい必要があります。
エラー：x509: certificate has expired or is not yet valid
原因と対処：端末の時刻が誤っているか、サーバー証明書の有効期間に問題があります。まずシステム時刻を同期してください。再発する場合は、ログに記録された証明書の有効期間を確認し、サービス提供元に対応を依頼します。証明書検証を無効にして回避するのは避けてください。
エラー：tls: handshake failure
原因と対処：接続先にTLSハンドシェイクを拒否されています。serverName、プロトコルのパラメーター、サーバー設定などが原因として考えられます。サブスクリプションに記載された元の設定に戻し、サーバーログも確認して原因を特定してください。このエラーだけでDNS障害と決めつけることはできません。
4. システムDNSとプロキシコアのDNSを分けて確認する
まず、名前解決に失敗しているドメインを特定します。ノードサーバーのドメインか、アクセス先Webサイトのドメインかを確認してください。前者が解決できないとトンネルを確立できず、後者の場合は一部のリクエストだけに影響することがあります。Windowsのnslookupでシステム側の名前解決を確認できますが、その結果だけでは、コアに設定したリモートDNSやブラウザーの暗号化DNSも正常とは判断できません。
nslookup example.com
curl.exe --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 -I https://example.com/上記は診断例であり、速度測定の結果ではありません。まず10808が現在実際に待ち受けているSOCKSポートまたは混合ポートであることを確認してから、2つ目のコマンドを実行してください。URLは実際に開けないWebサイトに置き換えます。socks5hではドメイン名の解決をプロキシ側に任せますが、socks5では通常curlがローカルで名前解決します。両者の挙動に差がある場合は名前解決の経路をさらに調べ、ログと合わせて判断してください。
- システム側の名前解決は失敗するが、プロキシ経由のリクエストは成功する：システムDNS、ブラウザーのDNS設定、リクエストがプロキシを経由せずに送信されていないかを確認します。ノードの故障と決めつけないでください。
- システム側の名前解決は成功するが、プロキシ側では失敗する：コアのDNSアドレス、接続経路、ルーティングを確認します。リモートDNSもプロキシ経由で接続する必要がある場合、未完了の名前解決に接続が依存して起動時の循環依存にならないようにしてください。
- ノードのドメイン名だけ解決できない：サブスクリプションに記載されたノードアドレスの綴りが正しいか、DNSレコードが無効になっていないか確認します。一度の名前解決で取得したIPアドレスにノードアドレスを恒久的に置き換えるのは避けてください。証明書や負荷分散に不整合が生じるおそれがあります。
エラー：no such host
原因と対処：現在の名前解決経路で、そのホストの有効な結果を取得できていません。まずエラーに記載されたドメイン名を確認し、綴り、DNS応答、名前解決の設定を調べます。すべてのネットワーク接続が切断されたことを意味するわけではありません。
5. ルーティングを確認：リクエストが誤った出力先に送られていないか
一時的にグローバルプロキシのルーティングに切り替えて比較し、その後、元の振り分け設定に戻します。ここでいう「グローバル」はルーティング方針を指し、システムプロキシやTUNを有効にすることではありません。アプリが先にリクエストをコアへ渡さなければ、コア内のルールは適用されません。システムプロキシ経由になっていないアプリは、コアのルーティングを切り替えても自動的にプロキシを使うようにはなりません。
v2rayNで現在のルーティング設定を記録し、現在のバージョンで選択できるグローバルプロキシ設定に切り替えて、同じURLをテストします。グローバルでは成功し、振り分け時に失敗する場合は、ドメインルール、IPルール、デフォルトの出力先を重点的に確認してください。画面上の名称はバージョンやコアによって異なるため、設定名だけで判断せず、実際の出力先のログを確認します。
| 比較結果 | 優先して確認する項目 | 対処方法 |
|---|---|---|
| グローバルでは使えるが、振り分けでは失敗する | ルールの順序、ドメインの照合、デフォルトの出力先 | 失敗したリクエストの実際の出力先を確認し、カスタムルールの適用範囲を絞る |
| 振り分け時に接続先が直接接続される | 範囲が広すぎる直接接続用ドメインルールまたはIPルール | 該当ルールを修正し、関連するサブドメインもテストする |
| 接続先がブロックされる | ブロックルール、またはルールセットの誤判定 | 誤判定した項目だけを変更し、ほかの有効なルールは維持する |
| どちらのルーティングでも失敗する | ノード、DNS、ローカルの待ち受け、アプリの通信取り込み | 失敗したときのログに戻り、ルーティング例外を追加し続けない |
要点：比較テストで復旧してから振り分け設定を変更する
グローバルと振り分けのどちらでも同じHTTPSリクエストが成功しない場合は、ドメインルールの追加をいったん止めます。明示的にプロキシを指定したリクエストでローカル入口とノードを確認し、問題の範囲を絞ってから振り分け設定を戻してください。
6. ローカルポートとシステムプロキシの入口を確認する
最後に、ローカルポートが実際に待ち受けているか、ブラウザーがそのポートを参照しているかを確認します。v2rayNのポートは変更できます。また、以前の設定やバージョンによっても異なる場合があります。以下の数値は確認例にすぎないため、クライアントに現在表示されている実際の値に置き換えてください。ノードのサーバーポートをWindowsのローカルプロキシ設定に入力しないでください。
Windows PowerShellで以下の2つのコマンドを実行します。1つ目は待ち受けポートとプロセスIDを確認し、2つ目はそのプロキシ入口経由でHTTPSリクエストを送信できるかを確認します。SOCKS専用ポートを通常のHTTPプロキシとしてシステム設定に入力することはできません。混合ポートが両方のプロトコルに対応するかは、現在のコア設定を確認してください。
Get-NetTCPConnection -State Listen -LocalPort 10808 |
Select-Object LocalAddress, LocalPort, OwningProcess
curl.exe --connect-timeout 10 --max-time 20 --proxy socks5h://127.0.0.1:10808 -I https://example.com/エラー：bind: Only one usage of each socket address (protocol/network address/port) is normally permitted.
原因と対処：待ち受けアドレスとポートがすでに使用されています。プロセスIDから使用中のプログラムを確認し、クライアントの二重起動を解消するか、ローカルポートを変更してアプリのプロキシ設定も更新してください。見覚えのないシステムプロセスをむやみに終了しないでください。
エラー：Failed to connect to 127.0.0.1 port 10808
原因と対処：指定されたローカル入口に接続できていません。コアが起動しているか、実際のポートが一致しているか、待ち受けアドレスにループバックアドレスが含まれているかを確認してから、リモートノードの問題に進んでください。
プロキシを明示したコマンドでは成功するのにブラウザーで失敗する場合は、Windows 11の「設定」→「ネットワークとインターネット」→「プロキシ」を開き、現在設定されているローカルHTTPまたは混合の入口と照合します。v2rayNのタスクトレイメニューで「システムプロキシ」→「システムプロキシを自動設定」を実行した後も、システム設定に戻って反映結果を確認してください。メニュー名はインストール済みバージョンによって異なります。ブラウザーのプロキシ拡張機能がシステム設定を上書きしている場合があるため、テスト中は該当する拡張機能を一時的に無効にしてください。
- コマンドラインは必ずしもシステムプロキシを使いません：環境変数とシステム設定の競合を避けるため、コマンドの
--proxyで入口を明示してください。 - TUNは個別にテストします：まずTUNを無効にして明示的なプロキシ接続を確認し、その後TUNを有効にして比較します。TUN使用時だけ失敗する場合は、ノードの認証情報を再変更するのではなく、仮想ネットワークアダプター、DNSの取り込み、ルーティングの競合を確認してください。
- 複数の通信取り込み機能を同時に使わない：トラブルの切り分け中は必要なネットワークツールだけを残し、システムプロキシ、ルーティング、DNSが重複して変更されないようにしてください。企業管理端末のセキュリティポリシーについては、管理者に確認してください。
7. よくある質問と復旧後の確認
遅延時間が表示されているのにWebサイトが開けないのはなぜ？
遅延の測定とWebページへの一連のリクエストは別の処理です。同じノードを使い、--proxyを指定したcurlコマンドで実際に開けないURLにリクエストを送り、該当時刻のコアログを確認します。HTTPステータスコードが返ればHTTP応答を受信したことはわかりますが、403や405などの場合は接続先サイトのルールも確認する必要があります。
スマートフォンでは同じサブスクリプションを使えるのに、パソコンでは使えません。再インストールが必要ですか？
まず両方の端末で同じノードを選択しているか確認し、パソコンとスマートフォンを同じネットワークに接続して比較します。サブスクリプションが同じでも、選択中のノード、コアの対応機能、DNS設定まで同じとは限りません。パソコンではローカルの待ち受けと、プロキシを明示したリクエストを優先して確認します。ログを保存してから設定の再構築を検討してください。
AndroidでVPN接続済みと表示されるのに、どのアプリからも開けない場合は？
v2rayNGまたはv2flyNGで現在のノードを確認し、アプリ別プロキシの設定でブラウザーが除外されていないか調べます。アプリ別の振り分けを一時的に無効にして比較し、コアのエラーログも確認してください。VPNアイコンが示すのはインターフェースの確立だけで、リモート認証やDNSリクエストの成功を保証するものではありません。
クライアントを終了した後、通常のWebサイトも開けなくなった場合は？
まずv2rayNを再度起動し、タスクトレイの「システムプロキシ」メニューからシステムプロキシを解除してから終了します。または、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、トラブル対応中に設定した手動プロキシや構成スクリプトを無効にしてください。組織が管理する設定は、許可なく変更しないでください。TUNを使用した場合は、クライアントが正常に通信の取り込みを停止していることも確認します。
アクセスが復旧したら、一時的なグローバルプロキシ、デバッグログ、テスト用DNSを、使用予定の設定に一つずつ戻し、変更のたびにテストします。「失敗した状態・変更した項目・再テストの結果」を簡潔に記録しておくと、出所のわからない例外ルールを残すより役立ちます。
- 以前開けなかったWebサイトを少なくとも1つ、普段使うWebサイトも1つ確認し、特定のドメインだけが直った状態になっていないか確かめてください。
- クライアントを再起動してもう一度テストし、変更が保存されていることと、システムプロキシが正しい入口を参照していることを確認してください。
- 問い合わせ時は、クライアントとコアのバージョン、発生時刻、機密情報を伏せたログを添えてください。サブスクリプションURL、UUID、パスワードなどの認証情報は削除します。