設定をインポートしたものの、接続テストがタイムアウトする、またはWebページを開けない場合に向けた内容です。まずローカルのプロキシが動作するかを確認し、次に接続先のポート、通信方式、TLS、最後にルーティングとDNSを確認します。Windows版v2rayNを例に、1回につき変更する項目は1つだけにし、ログと同じリクエストで結果を見比べます。速度テストの失敗だけでノードが使えないと判断しないようにしましょう。
1. テストのタイムアウトと接続失敗を切り分ける
「タイムアウト」は、操作が制限時間内に完了しなかったことを示すだけで、原因箇所までは分かりません。遅延テスト、サブスクリプションの更新、ブラウザーでのアクセスは、それぞれリクエストの経路が異なります。サブスクリプションサーバーに接続できなくても、インポート済みのノードが使えないとは限りません。テスト先の応答が遅くても、すべてのWebサイトにアクセスできないとは限りません。
| 症状 | まず確認すること | 次の手順 |
|---|---|---|
| 遅延テストだけタイムアウトする | 実際のWebページが開くか、テスト先に接続できるか | 固定のURLにプロキシ経由でアクセスする |
| ブラウザーで開けず、コアのリクエストログにも記録がない | システムプロキシ、ローカルの待受ポート、ブラウザーのプロキシ拡張機能 | まずローカルのプロキシをテストする |
| ログに接続先への接続タイムアウトが記録される | ノードのドメイン解決、接続先ポート、現在のネットワーク | 接続先に到達できるか確認する |
| 一部のWebサイトだけ開けない | ルーティングの判定、対象サイト、DNS | 該当ドメインのアウトバウンドログを確認する |
テストを始める前に、ノードの備考、クライアントのバージョン、使用するコア、テスト時刻を控えておきます。v2rayNはクライアントの画面であり、実際に接続を確立するのはコアです。画面が開いていても、コアが正常に起動しているとは限りません。バージョンは「ヘルプ」→「バージョン情報」で確認できます。バージョンによってメニュー名が多少異なる場合があるため、記録には実際の画面表示を使ってください。
2. PCの時刻を合わせ、最小構成でテストする
PCの日付や時刻がずれていると、証明書の有効期間の判定に影響したり、VMessの時刻に関係する認証に失敗したりする場合があります。VLESSは同じ時刻認証方式を使いませんが、TLSを使用する場合は証明書の時刻確認が行われます。まず日付と時刻を同期してください。認証エラーのすべてをプロトコルの問題と決めつけないようにしましょう。
-
時刻を同期する
Windows 11では「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」をオンにします。「その他の設定」にある「今すぐ同期」をクリックしてください。日付とタイムゾーンも確認します。表示上のタイムゾーンを変更するだけでは、システム時刻のずれは直りません。
-
テストするノードを固定する
v2rayNのノード一覧で対象を右クリックし、「アクティブサーバーに設定」を選びます。切り分け中はこの設定だけを使い、自動切り替えはオフにしてください。連続するリクエストが別々のサーバーを経由するのを防げます。
-
接続経路をシンプルにする
まずv2rayNのメイン画面で「TUNを有効にする」をオフにし、通信を中継するほかのプロキシやVPNアプリも終了します。ここでは確認項目を減らすのが目的です。ローカルプロキシのテスト後に、TUNは個別に確認してください。
-
1回だけ再現させる
ログ画面を開いて時刻を控え、固定したURLに1回だけアクセスします。該当リクエストの前後にあるエラーを記録してください。ノードを何度も切り替えてから、混在したログを見て原因を推測するのは避けましょう。
3. システムプロキシとローカルの待受ポートを確認する
まずv2rayNの「設定」→「パラメーター設定」で、ローカルの待受ポートに関する設定を探し、実際のポート番号とプロトコルを確認します。以下ではSOCKSの接続先として127.0.0.1:10808を例にします。すべてのバージョンやインストール環境で同じポートが使われるわけではありません。PC上の設定値が異なる場合は、コマンド内の値も合わせて変更してください。
Windows PowerShellで次の2つのコマンドを実行します。1つ目は待受状態とプロセスIDを確認します。2つ目は、アプリがシステムプロキシを読み取るかどうかに左右されず、ローカルSOCKS経由で直接リクエストを送信します。example.comはテスト用の例です。1つのURLで失敗した場合は、正常に使えると分かっている別のURLでも確認してください。
netstat -ano | findstr ":10808"
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 15 -I https://example.com/- LISTENINGが表示されない場合：コアが起動しているか、ポート番号に誤りがないか確認します。クライアントのウィンドウが開いているだけで判断しないでください。
- 待受はあるが、PIDに心当たりがない場合：「タスクマネージャー」→「詳細」でPIDを確認します。IPv4とIPv6で複数の待受が表示されても、必ずしも競合しているとは限りません。重要なのは、どのプロセスがそのポートを使っているかです。
- コマンドでHTTP応答が返り、ブラウザーでは失敗する場合：システムプロキシとブラウザー拡張機能を優先して確認します。301や403などのステータスもHTTP応答を受け取ったことを示しますが、対象サイトのすべての機能が使えることを意味するわけではありません。
- ローカル接続がすぐに拒否される場合：まず待受アドレス、ポート、コアの起動状態を確認してください。この時点では、接続先のノードに問題があるとは判断できません。
コマンドが成功したら、v2rayNの下部にある「システムプロキシ」メニューから「システムプロキシを自動設定」を選び、ブラウザーでもう一度試します。Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」を開き、プロキシのアドレスとポートを確認します。ポートはクライアントのHTTPまたは混合プロキシの接続先に合わせてください。SOCKS専用ポートを適当に設定しないでください。
結論：まずローカルのプロキシが使えることを確認する
ローカルプロキシを明示したリクエストは成功するのに、ブラウザーでは失敗する場合は、まずアプリのプロキシ接続先を修正してください。ノードのUUID、TLS、通信経路を変更する必要はありません。
4. ログからDNSエラー・接続拒否・タイムアウトを見分ける
ローカルプロキシが正常に動作することを確認したら、コアが接続先に接続する際のエラーを確認します。以下はよくあるログの例です。実際のログの前後に付く文字列は、コアやOSによって異なる場合があります。1行のエラーだけで分かるのは原因の方向性です。対象のアドレスと発生時刻も合わせて確認してください。
no such host
原因：関連するドメインの名前解決に失敗しています。ノードのドメインの場合も、アクセス先サイトのドメインの場合もあります。
対処：まずログに表示されたドメインが何を指しているか確認し、入力ミスとPCのDNS設定をチェックします。名前解決エラーだけを見て、ノード全体をすぐに入れ替えないでください。
connection refused
原因：接続が明示的に拒否されています。接続先ポートでサービスが待ち受けていない場合や、接続が拒否されている場合によく発生します。
対処：接続先のポート番号とサービスの稼働状況を確認します。エラーに表示されたアドレスがローカルのループバックアドレスなら、ローカルの待受を確認してください。
i/o timeout
原因：ネットワークの読み書きが制限時間内に完了していません。通信経路、ファイアウォール、サーバー負荷、後続のハンドシェイクなどが関係する可能性があります。
対処：まず、エラーが接続時とハンドシェイク時のどちらで発生したかを確認します。同じ設定を別のネットワークでも試してください。このエラーだけでアカウントが無効だと判断しないでください。
address already in use
原因：コアが使用するローカルアドレスとポートを、別のプロセスがすでに使用しています。
対処：PIDから使用中のプログラムを特定して重複したプロセスを終了するか、ローカルポートを変更し、アプリのプロキシ設定も合わせて変更します。
接続先サーバーのアドレスとポートが分かっている場合は、PowerShellのTest-NetConnectionでTCP接続を確認できます。以下はコマンドの形式を示す例です。example.com:443は実際のノードではありません。診断には、サブスクリプションの提供元が指定したサーバーとポートを入力してください。
Test-NetConnection -ComputerName example.com -Port 443TcpTestSucceeded: Trueは、TCP接続が確立したことだけを示します。TLSやVMess、VLESSの認証に成功したことを示すものではありません。UDPベースの通信方式では、このTCPテストでデータ経路を検証することもできません。同じ設定がスマートフォンのテザリングでは使えて、現在のネットワークでは失敗する場合は、まずネットワークの制限を確認してください。最終的な判断にはサーバー側のログも必要です。
5. 通信方式とTLSの設定を項目ごとに照合する
接続先のポートには接続できるのにハンドシェイクが失敗する場合は、ノードの編集画面を開き、提供元の元の設定と項目ごとに照合してください。ポートが443だからといって、必ずTLSを有効にするとは限りません。エラーを消すために証明書の検証を無効にするのも避けてください。
| 確認項目 | 一致させる設定 | よくある誤り |
|---|---|---|
| プロトコルと認証 | VMessまたはVLESS、UUID、設定で必要となるその他の認証項目 | プロトコル名だけ変更し、別のプロトコルの項目を残す |
| アドレスとポート | サーバーアドレス、接続先の待受ポート | ローカルの10808を接続先ポートに入力する |
| WebSocket | 通信方式、パス、Host | パスの先頭のスラッシュを省略する、またはHostをSNIとして扱う |
| gRPC | 通信方式、serviceName、サーバーが要求するTLS設定 | serviceNameにWebSocketのパスと同じ感覚でスラッシュを追加する |
| TLS | TLSの有効・無効、serverName/SNI、証明書の信頼性と有効期間 | 接続先アドレスをIPに変更した際、SNIまでIPに変更する |
| REALITY | serverName、公鍵、shortId、フィンガープリント、flowなど、組み合わせに必要な設定 | 通常のTLSと同じように扱い、異なる設定の項目を混在させる |
x509: certificate has expired or is not yet valid
原因：証明書の有効期間の確認に失敗しています。PCの時刻が誤っている場合や、サーバーの証明書が期限切れの場合があります。
対処：まずシステム時刻を同期します。時刻が正しいのに失敗する場合は、サービスの提供元に証明書の設定と更新状況を確認してください。
websocket: bad handshake
原因：WebSocketのアップグレードハンドシェイクで期待した応答がありません。パス、Host、リバースプロキシのルールが一致していない場合によく発生します。
対処：元の設定と照らし合わせてパスとHostを復元し、サーバー側で該当サイトの転送ルールを確認してもらってください。
VMessとVLESSはプロキシプロトコル、WebSocketとgRPCは通信方式、TLSはセキュリティ層です。互いに置き換えられる設定ではありません。サブスクリプションを更新した後に設定項目が不完全に見える場合は、提供元に確認した設定を再インポートし、使用中のコアがその組み合わせに対応しているか確認してください。複数のノードの設定を手作業で組み合わせるのは避けましょう。
6. 最後にルーティング、DNS、TUNを確認する
同じノードで一部のWebサイトにはアクセスできる場合、「すべてのリクエストが失敗する」場合よりもルーティング設定の確認が重要です。v2rayN下部のルーティング選択とシステムプロキシは別の設定です。システムプロキシはアプリがリクエストを送る先を決め、コアのルーティングは受け取ったリクエストのアウトバウンド先を決めます。アプリがローカルプロキシを経由しない場合、コアのルールを変更しても反映されません。
- まずルールの判定結果を確認：アクセスに失敗するドメインを開き、該当リクエストがログに記録されているか、プロキシと直接接続のどちらを使ったか確認します。必要に応じて一時的にログレベルを上げ、再現後に元に戻してください。アクセスの詳細を長期間記録し続けないようにしましょう。
- 一度に1項目だけ変更して比較：テスト通信をプロキシのアウトバウンドに送るルーティングプリセットを選び、同じリクエストを再試行します。改善した場合は、元のルールの順序と適用範囲を確認してください。テスト用プリセットを使い続ける必要はありません。
- 2種類の名前解決を区別：ノードサーバーのドメイン解決は接続先への接続に関わり、アクセス先サイトのドメイン解決はサイトへのアクセスやルーティングに関わります。一方を修正しても、もう一方が正常になるとは限りません。
- ルール用リソースを確認：
geositeはドメインのリスト、geoipはIPアドレスのリストです。リソースがない、またはルールの参照先が誤っていると、読み込みに失敗する場合があります。まずコアの起動ログを確認し、必要に応じて該当リソースを更新してください。
ローカルプロキシの動作を確認した後、「TUNを有効にする」をオンにして、システムプロキシを使わないアプリでテストします。TUNは通常、仮想NIC、ルーティング、DNSの制御に関わり、追加の権限が必要な場合もあります。オンにした直後にネットワークが切断されたら、まずTUNをオフにして接続が戻るか確認してください。その後、権限、ほかのVPNのルート、仮想NICの競合を調べます。通信方式の設定を同時に変更しないでください。
結論：同じリクエストでTUNの問題を切り分ける
同じノードでローカルプロキシを明示した場合は成功し、TUNを有効にしたときだけ失敗するなら、接続先のプロトコルを変更する前に、仮想NIC、ルーティング、DNSの制御を確認してください。
7. よくある質問と切り分けを終える目安
遅延テストはすべてタイムアウトするのにWebページは開けます。ノードを変更すべきですか？
まず変更する必要はありません。Webページの通信が実際にプロキシを経由していることを確認し、テスト先、テスト方法、タイムアウト設定を見直してください。同じURLへのアクセスを繰り返し、実際の接続状況を確認しましょう。単一のテスト結果だけで接続状態を判断しないでください。
サブスクリプションの更新がタイムアウトします。プロキシ経由で更新すべきですか？
まずサブスクリプションURLが有効か、使用可能なプロキシがあるかを確認します。直接接続ではサブスクリプションサイトにアクセスできず、プロキシ経由なら成功する場合は、適切なプロキシ経由の更新方法を選んでください。すべてのノードが使えない状態でプロキシ経由の更新を強制すると、解決できない循環に陥る場合があります。
PCでは接続できるのに、Androidでは同じ設定が使えません。
まず2台の端末を同じネットワークに接続し、時刻、使用中の設定、ログを確認してください。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用するため、設定への対応状況はそれぞれのコアに依存します。Xray固有の機能に依存する設定は、共有リンクからインポートできただけでは互換性があると判断できません。
タイムアウトを5秒から30秒に延ばせば直りますか？
応答が遅い場合に、待ち時間を延ばせるだけです。ポート番号、認証項目、証明書の誤りは修正できません。一定の待ち時間を設定して変更前後を比較してください。それでもリクエストが失敗する場合は、ログから失敗した段階を特定します。
ローカルポートが正常で、設定を配布元と照合済み、システム時刻も正しい状態で、同じノードが2つの独立したネットワークでも同じ段階で失敗する場合は、むやみに設定を変更するのをやめましょう。サービス提供元には、個人情報を伏せた発生時刻、コアのバージョン、エラーログの一部、接続先ポートのテスト結果を送ると、DNSを手当たり次第に変更するより効果的です。
- 失敗したリクエストの時系列を1件分残し、個人設定全体は送らないでください。
- ローカルの待受、接続先への接続、TLSハンドシェイク、対象サイトへのアクセスのどの段階で失敗したかを伝えてください。
- 確認が終わったら、元のルーティング、ログレベル、必要なプロキシモードに戻してください。