クライアントに「接続済み」と表示され、遅延テストに数値が出ても、ブラウザーの通信がプロキシ経由で完全に処理されているとは限りません。ウェブページへのアクセスには、少なくともドメイン名の解決、ルーティングの照合、インバウンドの待受、アウトバウンド接続、システムによるアプリ通信の取り込みといった段階があります。どこか一つでも設定を誤ると、クライアントは正常に見えるのに、ウェブページだけが読み込み中のまま、またはエラーになることがあります。
トラブルシューティングでは、ノード、DNS、ルーティング、システム設定を同時に変更しないでください。複数の変数を一度に変えると、復旧しても本当の原因を特定できません。まずノード自体を確認し、次にDNS、続いてルーティングルールを絞り込み、最後にシステムプロキシまたはVPNの取り込み状態を確認するのが安全です。各手順の後は同じテストページにアクセスし、結果を記録してください。
まず「接続済み」が何を意味するのか確認する
v2rayN、v2rayNG、v2flyNGに動作中のステータスが表示されても、通常はローカルコアが起動した、またはローカルプロキシの入口が作成されたことを示すだけです。リモートノードに到達できることや、ブラウザーがその入口を利用していることまでは保証しません。遅延テストにも限界があります。一部のテストはサーバーまでの接続時間しか測定しないため、実際のウェブリクエストはプロトコルのハンドシェイク、ドメイン名解決、ルーティングルール、リモート出口の状態にも左右されます。
まず、現象を次のように分類します。現象によって重点的に確認する箇所が異なります。
| 現象 | 優先して確認する項目 | よくある原因 |
|---|---|---|
| どのウェブページも開けない | ノード、システムプロキシ、VPNによる取り込み | ノードの無効化、ローカルポートが取り込まれていない、コアの接続失敗 |
| ドメイン名では開けないが、一部のアドレスにはアクセスできる | DNS | DNSサーバーに到達できない、DNSクエリが誤った出口を経由している |
| 一部のウェブサイトだけ開けない | ルーティング、DNS、ノードの出口 | ルールの誤マッチ、特定アドレス範囲の制限、解決結果の異常 |
| ブラウザーは使えるが、ほかのソフトは使えない | システムプロキシとアプリのプロキシ設定 | アプリがシステムプロキシを参照しない、ブラウザーだけにプロキシを設定している |
| ノードを切り替えると復旧する | 元のノード設定とサービス状態 | ノードの期限切れ、プロトコルパラメーターの不一致、リモートへの到達不能 |
ステップ1：ノードが本当に使えるか確認する
ノードは経路全体の上流にあたります。ノードが無効なら、端末側のDNSやルーティングを何度調整しても通常は改善しません。最も確実な確認方法は遅延だけを見ることではなく、同じクライアントで既知の利用可能な別ノードに切り替え、実際にウェブページへアクセスすることです。新しいノードですぐ復旧するなら、原因は元のノードまたはそのパラメーターにある可能性が高いでしょう。
ノード情報を一つずつ確認する
- アドレスとポートを確認します。サーバーアドレスに余分な空白がないこと、ポートが有効な数字であること、インポート後に誤って変更していないことを確認してください。
- プロトコルの種類を確認します。VMessとVLESSは異なるプロトコルです。アドレスとポートだけを残して相互に置き換えることはできません。クライアントに表示されるプロトコルが、元のノード設定と一致している必要があります。
- ユーザー識別子を確認します。UUIDやユーザーIDなどの認証情報は完全な状態で入力してください。コピー中に文字が欠けると、ハンドシェイクに失敗します。
- トランスポートパラメーターを確認します。TCP、WebSocket、gRPCなどのトランスポート方式に加え、Host、パス、serviceNameなどの項目もサーバー側の設定と一致させる必要があります。
- セキュリティパラメーターを確認します。TLSまたはREALITYを有効にしたVLESSノードでは、正しいサーバー名、公開鍵、短いIDなどのパラメーターが必要です。パラメーターが不足していてもローカルコアは起動することがありますが、リモートとのハンドシェイクは完了しません。
- 端末の時刻を確認します。システムの日付、時刻、タイムゾーンが大きくずれていると、証明書の検証や一部プロトコルの認証に失敗することがあります。まず自動時刻合わせを有効にしてから、再接続してください。
サブスクリプションからノードを取得している場合は、まず一度更新し、現在選択中のノードがまだ存在することを確認してください。サブスクリプションURLが空の内容を返した、ノードが削除された、古い設定を長期間更新していないといった理由で、クライアントに無効になった記録が残っていることがあります。更新後はノード数だけで判断せず、ノードを選び直して実際の接続テストを行ってください。
ステップ2：DNS解決の障害か判断する
ブラウザーでドメイン名にアクセスするには、まずドメイン名をアドレスに解決する必要があります。DNSクエリに失敗すると、プロキシコアは動作中でも、ウェブページには「サーバーが見つかりません」「アドレスを解決できません」と表示されたり、接続中のまま長時間進まなかったりします。ドメイン名だけにアクセスできず、確立済みの接続やアドレスを直接使うサービスには応答がある場合は、DNSを最優先で確認してください。
まず最小限の切り分けを行う
- エラーメッセージにドメイン名解決、名前解決、DNSに関する表示がないか確認します。
- 別のノードに切り替えて再テストします。すべてのノードで同じドメインエラーが出るなら、端末のDNS設定がより疑わしくなります。
- 一時的にクライアントのデフォルトDNS設定へ戻し、独自に追加した複雑な分岐ルールを無効にします。
- DNSクエリが使用する出口に到達できることを確認します。プロキシ経由で問い合わせる場合は、プロキシノードが先に接続できなければなりません。直接問い合わせる場合は、ローカルネットワークからそのDNSサービスへアクセスできる必要があります。
DNSとルーティングには前後関係があります。ルーティングルールがIPでマッチする場合、コアは先にドメイン名を解決する必要があるかもしれません。一方、DNSクエリ自体も直接接続かプロキシ出口かを選ぶ必要があります。複数のDNS、ドメイン分岐、アドレス分岐が同時に存在すると、「解決結果がルーティングを決め、ルーティングが解決に影響する」という複雑な連鎖が生じやすくなります。トラブルシューティング中はまずポリシーを減らし、基本的な名前解決が使えることを確認してから、一つずつ戻してください。
キャッシュもよくある干渉要因です。DNSを変更した後も、ブラウザー、OS、プロキシコアが古い解決結果を保持していることがあります。設定を変更したら、クライアントを完全に終了して再起動し、ブラウザーも開き直してください。ページの再読み込みだけでは、新しいDNSクエリが発生するとは限りません。
DNSの結果は正常なのに開けない場合
解決に成功したことはアドレスを取得できたことを示すだけで、そのアドレスに現在の出口から必ずアクセスできるとは限りません。ドメイン名が複数のIPv4またはIPv6アドレスを返し、ローカルネットワーク、ノードの出口、ルーティングルールがその一部にしか対応していないことがあります。ログで解決完了を確認した後に接続がタイムアウトする場合は、いったん単純なアドレス戦略を使うか、カスタムのIPv6優先設定を無効にして比較テストを行ってください。原因を確認したら、実際のネットワーク環境に合わせてアドレスファミリーの方針を選び直します。
ステップ3：ルーティングルールの誤ブロックと誤った出口を除外する
ルーティングルールは、接続をプロキシ、直接接続、ブロックのどれで処理するかを決めます。通常、ルールは上から順に照合され、一致すると後続のルールは確認されません。範囲の広い直接接続ルールが前にあると、本来プロキシを通すべきウェブサイトへ直接接続して失敗することがあります。範囲の広いブロックルールがあると、リクエストが端末上で終了します。
「グローバルプロキシ」で比較テストする
ノードが利用可能だと確認できたら、短時間だけグローバルプロキシモードに切り替えてみます。グローバルモードではウェブページを開けるのにルールモードでは開けない場合、原因はほぼルーティング設定にあります。この場合、ノードのパラメーターを変更し続ける必要はありません。ルールの順序、マッチ範囲、アウトバウンドタグを重点的に確認してください。
ルーティングを確認する際は、次の項目を重点的に確認します。
- フォールバック出口が存在するか。どのルールにも一致しない通信には、明確なデフォルト出口が必要です。存在しないアウトバウンドタグを指定してはいけません。
- ルールの順序が適切か。早い段階で広範なルールに一致しないよう、通常は完全一致のドメインや狭い範囲のルールを広いルールより前に置きます。
- ドメイン条件とアドレス条件を混在させていないか。アドレスによるマッチではDNS解決が発生することがあり、解決方針が最終結果に影響します。
- ブロック範囲が広すぎないか。テスト中は最近追加したブロック項目を一時的に無効にし、一つずつ戻して再テストします。
- 直接接続ルールが対象を覆っていないか。対象ドメインまたは解決されたアドレスが直接接続の範囲に入ると、ウェブページがプロキシを迂回して接続に失敗することがあります。
- アウトバウンドタグが一致しているか。ルール内の
outboundTagは、実際のアウトバウンド設定にあるタグと完全に一致している必要があります。
トラブルシューティングの判断手順：
1. ノードで実際のアクセスに成功するか
2. グローバルプロキシでアクセスに成功するか
3. ルールモードでは失敗するか
4. 対象ドメインに一致したルールを確認する
5. そのルールが proxy、direct、block のどれを指しているか確認する
6. ルールを1つ変更したらすぐ再テストする障害発生中に複数のルールセットを一度にインポートしないでください。異なるソースのルールには、互いに上書きし合うドメイン範囲やアドレス範囲が含まれている可能性があります。まずクライアントのデフォルトルールで検証し、その後カスタムルールを1つ追加してテストします。このように段階的に進めれば、どのルールが出口を変えたのかを正確に特定できます。
ステップ4：システムプロキシまたはVPNの取り込みが有効か確認する
プロキシコアを起動した後も、アプリの通信をローカルのインバウンドポートへ届ける必要があります。デスクトップでは通常、システムプロキシ、アプリ内プロキシ、その他の取り込み方式を使います。Androidのv2rayNGとv2flyNGでは、通常VPNモードで端末の通信を取り込みます。ローカルコアの動作と通信の取り込みは別々の状態なので、起動ボタンだけを見て判断しないでください。
v2rayNデスクトップ版の確認
- クライアントのウィンドウを起動しただけでなく、現在使用するノードを選択していることを確認します。
- システムプロキシモードが有効になっていることを確認し、OSのプロキシ設定に対応するローカルアドレスとポートが表示されているか確認します。
- ブラウザーに手動でプロキシを設定したことがある場合は、いったん「システムプロキシを使用」に戻すか、古いポートを削除します。ブラウザーが無効になったローカルポートへ接続し続けるのを防ぐためです。
- ほかのプロキシプログラムが同じポートを使用していないか確認します。ポートが競合すると、コアのログに待受失敗やアドレス使用中のエラーが表示されることがあります。
- クライアントを終了した後、システムプロキシが正しく元に戻っていることを確認してから再起動します。異常終了すると古いプロキシアドレスが残り、すべてのリクエストが存在しないポートへ送られ続けることがあります。
v2rayNGとv2flyNG Android版の確認
- 接続を開始したら、システムのステータス領域にVPN接続状態が表示され、クライアントによるVPN接続が許可されていることを確認します。
- アプリごとのプロキシ設定を確認します。対象のブラウザーやアプリが除外されていると、その通信はプロキシに入りません。
- テスト中は省電力設定やバックグラウンド動作の制限を一時的に無効にし、画面ロックやアプリ切り替え後にシステムがコアプロセスを停止しないようにします。
- 端末に別のVPN接続がある場合は、先に切断してからテストします。通常、システム上で2つのVPN取り込み経路を同時に正常動作させることはできません。
- ネットワークを切り替えた後は、いったん手動で切断して再接続し、コアに基盤接続を再確立させます。
「ブラウザーは使えるのに、特定のソフトだけ使えない」場合、ノード全体の障害とは限りません。システムプロキシを参照しないソフトや、独自のプロキシ設定を持つアプリがあります。また、UDPを使用する接続もあります。この場合は、まず対象アプリが取り込み対象か、UDPが許可されているか、ルーティングでその宛先に別の出口が設定されていないかを確認してください。
ステップ5：ログから失敗した層を特定する
最初の4ステップでも原因を特定できない場合は、クライアントのログを開き、古いログを消去してからテストページにもう一度アクセスします。これにより過去の記録による干渉を減らせます。コアの起動時メッセージだけでなく、リクエスト発生時に追加された行を確認してください。
| ログの手がかり | 通常示している箇所 | 次に行うこと |
|---|---|---|
| 接続タイムアウト、対象に到達できない | ノードアドレス、ネットワーク経路、リモートサービス | ノードとネットワークを切り替え、アドレスとポートを確認する |
| 認証失敗、ハンドシェイク失敗 | プロトコル、セキュリティパラメーター、端末時刻 | ノードを再インポートし、UUIDとトランスポートパラメーターを確認する |
| ドメイン名の解決に失敗 | DNS設定またはDNSの出口 | デフォルトDNSに戻し、クエリの経路を確認する |
| アウトバウンドタグが見つからない | ルーティングルールの参照エラー | ルールとアウトバウンド設定のタグを照合する |
| ポートの待受に失敗 | ローカルポートの競合 | 競合しているプログラムを終了するか、ローカルポートを変更する |
| ログにウェブリクエストがまったくない | 通信がクライアントに入っていない | システムプロキシ、VPN、アプリごとの設定を確認する |
ログに「リクエストがない」こと自体が重要な結果です。ウェブページへアクセスしても新しいインバウンド記録がないなら、問題はコアより前の段階にあります。システムプロキシまたはVPNの取り込み確認に戻ってください。インバウンドリクエストが見えるのにアウトバウンドが成功しない場合は、DNS、ルーティング、ノードのハンドシェイクのどこで失敗したかを切り分けます。「リクエストが入ったか」と「アウトバウンドがどの段階で止まったか」の2点を確認すると、範囲をすばやく絞り込めます。
最終チェックリスト：順番に確認する
- 通常のネットワーク接続自体が使えること、端末からローカルネットワークで許可されているページにアクセスできることを確認する。
- システムの日付、時刻、タイムゾーンを同期する。
- サブスクリプションを更新し、ノードを選び直す。削除済みの古い記録は使用しない。
- 既知の利用可能なノードへ少なくとも1つ切り替え、実際のウェブページへのアクセスで確認する。
- VMessまたはVLESSのプロトコル、アドレス、ポート、UUID、トランスポート、セキュリティパラメーターを確認する。
- クライアントのデフォルトDNSに戻し、クライアントとブラウザーを再起動して再テストする。
- 一時的にグローバルプロキシへ切り替える。グローバルモードが使える場合は、ルーティングルールを重点的に確認する。
- ルールの順序、直接接続の範囲、ブロック範囲、アウトバウンドタグを確認する。
- デスクトップでは、システムプロキシのアドレスとローカルの待受ポートが一致していることを確認する。
- AndroidではVPNが確立しており、対象アプリがアプリごとのルールで除外されていないことを確認する。
- ローカルポートの競合や、別のVPN接続がないか確認する。
- ログを消去して問題を一度再現し、新しいログから失敗した層を特定する。
トラブルシューティングが完了したら、一時的に切り替えたグローバルモードを普段使うルーティングモードへ戻し、カスタムDNS、ルールセット、アプリごとの設定を一つずつ復元します。各項目を戻すたびにアクセスをテストしてください。これにより、元の分岐要件を維持しながら、どの設定で障害が再発するかを特定できます。
ノードを再インポートしても認証またはハンドシェイクエラーが続き、ほかのノードは正常な場合は、そのノードの完全なパラメーターを更新する必要があるでしょう。すべてのノードが同じネットワークでタイムアウトし、ネットワークを変更すると復旧する場合は、現在のネットワークによる対象アドレス、ポート、プロトコル通信への制限を確認してください。問題を「単一ノード」「単一端末」「単一ネットワーク」のいずれかに絞ると、その後の対応が明確になります。