v2rayNでノードがタイムアウトする、ブラウザーでWebページを開けない、Androidクライアントを起動しても通信できないといった場合に役立つガイドです。通信経路を7段階に分け、各段階で変更する条件は1つだけにします。ポートテスト、プロキシを明示したリクエスト、ログを使って、端末の設定、サーバーへの到達性、プロトコル設定のどこに問題があるかを切り分けます。「ノードが使えない」と一括りにするのを避けましょう。
ステップ1：端末のネットワークとテスト結果を確認する
まずクライアントを終了するか、プロキシによる通信制御を停止して、普段そのまま開けるWebサイトにアクセスします。Windowsでは、v2rayNのタスクトレイメニューから「システムプロキシ」→「システムプロキシを解除」を選択します。TUNを有効にしている場合は、TUNも無効にしてください。システムプロキシを解除しただけでは、仮想ネットワークアダプターによる通信制御は止まりません。Androidでは、まずv2rayNGまたはv2flyNGの接続を停止し、Wi-Fiまたはモバイルデータ通信を確認します。
ノード一覧に表示される遅延は、すべて同じ指標ではありません。TCPテストで主に確認できるのは、サーバーのポートに接続できるかどうかです。実際の遅延テストでは、プロキシプロトコル、テスト先URL、接続先からの応答も関係します。TCPテストに数値が出ても認証に成功したとは限らず、テスト先がタイムアウトしてもサーバーが必ず停止しているとは限りません。クライアントに「接続中」と表示されても、ローカルサービスやVPNインターフェースが起動しただけの場合があります。
- 直接接続も失敗する：まずWi-Fi、ルーター、ネットワークのログイン画面を確認し、ノード設定はまだ変更しないでください。
- 同じノードが別のネットワークでは使える：利用が許可された別のネットワークでもテストし、元のネットワークからサーバーへ接続できるかを重点的に確認します。
- 特定のWebサイトだけ開けない：テスト先を2つ変え、接続先サイト自体の障害や特定のルーティングルールの影響を切り分けます。
- すべてのノードが同時に失敗する：まず端末のプロキシ接続口、時刻、コアの起動状態を確認します。複数のノードが同じサーバーを使っている可能性もあるため、ノード数だけで原因を判断しないでください。
ステップ2：システム時刻を同期し、証明書や認証の問題を切り分ける
システム時刻がずれていると、証明書の有効期間を正しく判定できず、一部のプロトコルの認証にも影響することがあります。タイムゾーンの表示が異なっていても問題とは限りません。重要なのは、端末に設定された実際の時刻が正確かどうかです。時刻を数分進めるのは解決策になりません。
-
時刻の設定を開く
Windows 11では「設定」→「時刻と言語」→「日付と時刻」の順に開き、「時刻を自動的に設定する」をオンにします。「その他の設定」にある「今すぐ同期」をクリックしてください。
-
同期結果を確認する
年月日と現在時刻を確認し、同期が成功したことを確かめます。同期できない場合は、まず通常のネットワーク接続に戻してから再試行します。長期間同期できない場合は、システム時刻サービスやデバイス管理ポリシーを確認してください。
-
再起動して再テストする
Androidでは、システムの「日付と時刻」でネットワーク提供の時刻を有効にします。設定の場所はシステムによって異なります。設定後、クライアントの接続をいったん停止して再起動し、同じノードと同じURLでテストしてください。
エラー：x509: certificate has expired or is not yet valid
考えられる原因：端末の時刻が不正確か、サーバー証明書の有効期間が切れている、またはまだ有効になっていません。
対処：まず時刻を同期します。時刻が正しいのにエラーが続く場合は、サービス提供元に証明書の確認を依頼してください。証明書検証を無効にして回避するのは避けましょう。
ステップ3：システムプロキシ、TUN、ローカルの待ち受けポートを確認する
システムプロキシの影響を受けるのは、システムプロキシ設定に従うアプリだけです。TUNは仮想ネットワークアダプターで通信を制御するため、権限、ルーティング、DNS設定にも左右されます。切り分け時は、まずTUNを無効にして、ローカルのプロキシ接続口を1つだけテストするのがおすすめです。成功したら、元の通信制御モードに戻します。これにより、「コアが外部へ接続できない」問題と「アプリの通信がプロキシに入っていない」問題を分けられます。
v2rayN 7.xで一般的な画面構成を例にすると、「設定」→「パラメーター設定」でローカルの待ち受け設定を確認し、タスクトレイの「システムプロキシ」→「システムプロキシを自動設定」からシステムプロキシを有効にします。バージョンによって項目名が異なる場合があるため、現在の画面に表示されるポートと接続口の種類を確認してください。10808はよく使われるローカルポートですが、古い設定ではSOCKSが10808、HTTPが10809の場合もあります。ポート番号だけでプロトコルの種類を判断しないでください。
| 確認箇所 | 確認する内容 | 問題がある場合の対処 |
|---|---|---|
| クライアントの待ち受け設定 | HTTP、SOCKS、または混合接続口の実際のポート | 接続口の種類に合ったテストコマンドを使い、以前のポートをそのまま使わない |
| ブラウザーのプロキシ設定 | システム設定に従うか、独自のプロキシを設定しているか | 一時的に独自設定を解除し、設定の競合を解消する |
| TUNの設定 | 切り分け中に確実に無効になっているか | まず通常のプロキシをテストし、その後TUNを個別に確認する |
| 端末のセキュリティポリシー | コアの起動や外向きの通信をブロックしていないか | ブロック履歴を確認し、セキュリティ機能全体を無効にしない |
以下は、Windowsのターミナルでプロキシを明示してテストする例です。ポートはクライアントの実際の待ち受けポートに置き換えてください。HTTPコマンドはHTTPまたは混合接続口に、SOCKSコマンドはSOCKSまたは混合接続口に使います。--socks5-hostnameを使うと、接続先のドメイン名はプロキシ側で名前解決されます。どちらのコマンドも診断用の例であり、本記事での実測結果ではありません。
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com
curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com結論：プロキシを明示したテストに成功したら、次はブラウザーを確認する
プロキシを明示したリクエストで接続先サイトからHTTP応答が返るのに、ブラウザーでは失敗する場合は、まずブラウザーの接続口とシステムプロキシを確認します。すぐにノードを変更する必要はありません。127.0.0.1のポートに接続できないと表示される場合は、待ち受けポートまたはコアの起動を先に確認してください。
ステップ4：ノードのアドレス、ポート、認証情報を確認する
ローカルの接続口に問題がなければ、実際に使用しているノードを選択して編集画面を開き、サービス提供元から渡された設定全体と照合します。まずサーバーアドレスとリモートポートを確認し、次にプロトコル、UUIDなどの認証情報を確認してください。サーバーのポートとローカルの待ち受けポートは別物です。ローカル接続口が10808でも、サーバーは443を使う場合があります。ただし、ポートが443であることだけでは、そのノードがTLSを使う証拠にはなりません。
- アドレス：サーバー欄にはドメイン名またはIPアドレスを入力します。WebページのURL全体を誤って貼り付けたり、前後に空白を入れたりしないでください。
- ポート：サーバー側の設定と一致させます。一般的な設定で
443が使われているからといって、ポートを443に変更しないでください。 - プロトコル：VMessとVLESSでは認証方法やセキュリティ設定が異なります。ドロップダウンの項目名を切り替えるだけでノードを変換することはできません。
- サブスクリプション：提供元がサーバーや認証情報を変更した場合は、既存のサブスクリプショングループを更新し、更新後のノードを明示的に選択してください。
- コアの互換性：v2rayNGはXray系のコアを使用し、v2flyNGはv2fly系のコアを使用します。たとえばREALITYはXray関連の機能です。異なるコアが同じ設定をサポートするとは限りません。
サーバーのTCPポートだけを確認する場合は、Windows PowerShellでTest-NetConnectionを実行します。以下ではexample.comと443を使ってコマンドの書式を示しています。実際にテストする際は、自分のサーバーアドレスとポートを指定してください。結果のTcpTestSucceeded : Trueが示すのはTCP接続の成功だけであり、プロキシ認証やTLSを検証するものではありません。
Test-NetConnection -ComputerName example.com -Port 443エラー：connect: connection refused
考えられる原因：接続先のポートで待ち受けていないか、途中の機器が接続を拒否しています。接続先が端末自身のアドレスの場合は、ローカルのコアが起動していない可能性があります。
対処：まずエラーに表示された接続先アドレスを確認し、該当するポートを照合します。リモートポートが正しいのに拒否される場合は、サービス提供元にサーバーの稼働状況を確認してください。
ステップ5：通信方式、TLS、REALITYの関連項目を確認する
TCPで接続できるのに実際のリクエストが失敗する場合は、通信方式を確認します。通信方式はサーバー側の設定と一致させる必要があります。WebSocketではパスやHostがリバースプロキシの振り分けに使われる場合があり、gRPCではサービス名を一致させる必要があります。別のノードのパス、Host、サービス名を「試しに」コピーしないでください。原因を追えない条件が増えてしまいます。
| 設定の種類 | 主な項目 | 区別すべきポイント |
|---|---|---|
| WebSocket | 通信方式、パス、Host | Hostと接続先アドレスは異なる場合があります。提供元の指定どおりに入力してください。 |
| gRPC | 通信方式、serviceName | サービス名は任意のメモではありません。大文字・小文字も含めて一致させてください。 |
| TLS | サーバー名、証明書の検証、ALPN | SNIはハンドシェイクに使われます。接続先サイトのドメイン名に安易に置き換えないでください。 |
| REALITY | serverName、公開鍵、shortId、flow | クライアントの公開鍵はサーバー側の鍵設定に対応している必要があります。flowはノードの指定に従って設定します。 |
TLSのサーバー名は通常、ハンドシェイク時の選択と証明書名の検証の両方に関係します。REALITYには一式の関連パラメーターが必要で、セキュリティの種類をREALITYに変更するだけでは設定できません。インポート後に項目が欠けている場合は、使用中のクライアントとコアのバージョンがその設定に対応しているかを確認し、ダウンロードページから適切なバージョンを選んでください。項目の不一致を隠すためにセキュリティチェックを無効にしないでください。
エラー：tls: handshake failure
考えられる原因：サーバーがハンドシェイクを拒否しています。SNI、TLS設定、前段のサービスなどが関係している可能性があります。このエラーだけでは、具体的な原因を特定できません。
対処：ノードの元の設定とセキュリティの種類、サーバー名を照合し、エラー直前のログも確認してください。TLSの項目を手当たり次第に変更しないでください。
エラー：x509: certificate signed by unknown authority
考えられる原因：証明書チェーンが不完全、システムの信頼済み証明書ストアに問題がある、または接続中に証明書が差し替えられている可能性があります。
対処：端末の信頼環境とサーバーの証明書チェーンを確認し、必要に応じて管理者またはサービス提供元に問い合わせてください。証明書検証をスキップする設定を安易に有効にしないでください。
ステップ6：ノードのドメイン名解決と接続先のドメイン名解決を切り分ける
DNSの問題には少なくとも2つの段階があります。まずクライアントがノードサーバーのアドレスを調べ、プロキシ接続後に接続先サイトのドメイン名も解決します。前者に失敗するとノードに接続できません。後者に失敗すると、ノードのテストには成功するのにWebページを開けないことがあります。ルーティングルールがドメイン名や名前解決後のIPアドレスに基づく場合もあるため、DNSを変更した後の変化が名前解決だけによるとは限りません。
-
ノードのドメイン名を確認する
Windowsで
Resolve-DnsNameを実行し、実際のノードのドメイン名を調べます。結果が返り、名前解決エラーが出ていないことを確認してください。名前解決に成功しても、サーバーのポートに接続できるとは限りません。 -
元の設定を記録する
クライアントに現在設定されているDNSとルーティングの設定を記録してから、項目を1つずつ変更します。DNSリゾルバーの変更、TUNの有効化、ルーティングの変更を同時に行うと、どの変更が結果に影響したのか特定できません。
-
ルーティングの適用先を確認する
ログを確認し、対象のリクエストがプロキシ経由か直接接続かを調べます。特定の種類のドメインだけ失敗する場合は、適切でない経路に振り分けられていないか確認し、元のルールに戻して比較テストしてください。
-
キャッシュをクリアして再テストする
システムDNSを変更した後は、
ipconfig /flushdnsを実行してからクライアントの接続を再起動します。ブラウザーには別のDNSキャッシュやセキュアDNSの設定がある場合もあるため、個別に確認してください。
Resolve-DnsName example.com
ipconfig /flushdnsコマンドのexample.comは書式の例です。ノードのドメイン名を一時的に確認済みのIPアドレスに置き換えて比較する場合も、正しいTLSサーバー名を維持し、その接続方法がサービス提供元で許可されていることを確認してください。動的アドレスや前段サービスを使うノードでは、IPアドレスの固定は適しません。設定の詳しい背景はDNS設定ガイドを参照してください。
エラー：no such host
考えられる原因：ログに表示されたドメイン名を名前解決できません。入力ミス、DNSレコードの無効化、またはDNSリゾルバーから存在しないという結果が返された可能性があります。
対処：まずエラーに表示されたドメインがノードのものか接続先サイトのものかを確認します。そのうえで、該当するドメインと、その名前解決を担当するDNS設定をそれぞれ確認してください。
ステップ7：コアのログで原因を特定し、条件を1つずつ変えて再テストする
ここまで原因が見つからない場合は、コアのログを確認します。v2rayNは管理画面であり、実際のプロキシ処理は選択したコアが行います。画面が起動していても、コアが設定の読み込みに成功したとは限りません。まず起動時の設定解析エラー、ポートの競合、プロセスの終了を確認し、その後リクエストを1回実行してログを確認します。接続ボタンを何度も押すと、同じ記録が増えるだけです。
- ログレベル：現在のバージョンのパラメーター設定で「ログレベル」または
loglevelを探し、必要に応じて一時的にinfoに設定します。より詳しい情報が必要な場合は、短時間だけdebugを使い、調査後に元のレベルへ戻してください。 - 再現時の記録：日時を明確に記録し、接続を開始してからテスト用URLを1つだけ開きます。1日分のログを切り取るのではなく、そのリクエストの前後のログを保存してください。
- 確認する箇所：ローカルの待ち受け、ノードへの接続、TLSハンドシェイク、ドメイン名の名前解決、接続先サイトからの応答のどこで失敗したかを確認し、該当するステップに戻って対処します。
- 問い合わせ時に伝える情報：クライアントとコアのバージョン、ネットワークの種類、エラーの発生時刻、必要に応じて機密情報を伏せたログを提供します。サブスクリプションURL、UUID、認証情報、個人のアドレスは隠してください。
エラー：address already in use
考えられる原因：ローカルの待ち受けアドレスとポートを別のプロセスが使用しているか、コアを重複して起動しています。
対処：重複したプロセスを終了し、ポートの使用状況を確認します。待ち受けポートを変更する必要がある場合は、システムプロキシやアプリ側のポート設定も更新してください。
エラー：i/o timeout
考えられる原因：ネットワーク処理が制限時間を超えています。名前解決、接続の確立、データの読み取りのいずれかで発生する可能性があり、このエラーだけでノードが使えないとは判断できません。
対処：前後のログから接続先アドレスと処理段階を確認し、DNS、サーバーのポート、接続先からの応答をそれぞれ調べてください。
エラー：context deadline exceeded
考えられる原因：テストまたはリクエスト全体が制限時間に達しています。基盤となる接続の失敗だけでなく、テスト先から応答が返らないことも原因として考えられます。
対処：まずテスト先を変更し、その後、下位のエラーを確認します。タイムアウト時間の延長は応答が遅いかどうかの判定には使えますが、設定ミスの解決にはなりません。
修正後はネットワーク、接続先、モードを変えずにリクエストを3回続けて実行し、ブラウザーで実際にアクセスできるか確認します。通常のプロキシでは使えるのにTUNだけ失敗する場合は、個別にTUN設定のトラブルシューティングに進んでください。サーバーのポートに常に接続できず、別のネットワークでも同じ結果になる場合は、ローカルのTLSやDNSを変更し続けるのではなく、サービス提供元に稼働状況を確認してください。
結論：失敗した段階に応じて次の対応を決める
ローカル接続口で失敗する場合は待ち受け設定を、リモート接続の確立で失敗する場合はアドレスとネットワークを、ハンドシェイクで失敗する場合は関連する設定項目を確認します。接続先の名前解決に失敗する場合はDNSとルーティングを調べてください。変更は毎回1項目だけにして結果を記録すれば、役立つ情報を残し、改善しない場合も元の設定に戻しやすくなります。