この記事は、ノードのインポート後に接続できない、ウェブページが開かない、または接続が断続的に切れる場合に役立ちます。ログ全体を逐一読むのではなく、まず発生時刻を記録し、受信待受、ルーティング、リモート送信の3段階から最初の異常を探します。最後に1つずつ条件を変えて原因を確認します。
まず、本当に役立つ実行ログを見つける
v2rayN、v2rayNG、v2flyNGはいずれもクライアントの状態を表示しますが、画面の通知はコアの実行ログとは異なります。「起動しました」「テスト完了」といった表示は操作が実行されたことを示すだけです。リクエストがどこで止まったかを判断するには、時刻、ログレベル、接続先、エラーの連鎖を含むコア出力を確認してください。
v2rayN 7.xを例にすると、まずメイン画面の「情報」欄を確認します。ログの記録範囲を調整する場合は、「設定」→「パラメータ設定」を開き、コアのログレベルに関する項目を探します。v2rayNG 1.10.xでは、サイドメニューから「ログ」を開きます。ログレベルは通常、「設定」の詳細オプションにあります。バージョンによって名称が多少異なる場合がありますが、サブスクリプション更新の通知だけでなく、コアのログを選択してください。
ログを記録する前に、問題をクリーンな状態で再現する
- 実行中のダウンロード、速度テスト、バックグラウンド同期を停止し、無関係な接続を減らします。
- 現在のログを消去するか、テスト開始時刻を正確に控えます。
- 対象ノードを起動し、コアの状態が安定するまで待ってから、明確なURLまたはアプリの機能を1つ開きます。
- 30秒以内に問題を再現してすぐ操作を止め、障害発生前後のログを約20〜50行保存します。
- 使用したノード、システムプロキシの状態、TUNの状態、ローカルポートを記録します。ただし、完全なサブスクリプションURL、UUID、パスワード、アクセストークンは公開しないでください。
受信・ルーティング・送信の順にエラーの連鎖を読む
通常、リクエストはブラウザーなどのアプリから送られ、ローカルのSOCKS、HTTP、またはTUNの受信口を通ってコアに入り、ルーティングルールに照合された後、プロキシノードまたは直接接続の出口から送信されます。ログのエラーは複数の層の情報が連結されていることが多く、外側は「処理失敗」を示し、内側ほど元の原因に近くなります。
最後に出たerrorだけを検索しないでください。同じ時刻の前後に新しい接続があるか確認し、外側から内側へエラーの連鎖をたどって、dial、lookup、authentication、routing、bindなどのキーワードを探します。その後に大量発生するキャンセル情報より、最初の異常のほうが診断に役立ちます。
第1段階：受信口はリクエストを受け取っているか
ウェブページを開いてもログに新しい接続がまったく追加されない場合、問題はまだコアに到達していない可能性が高いです。システムプロキシが有効か、ブラウザーが個別のプロキシを使っていないか、アプリがシステムプロキシを無視していないか、ローカルのアドレスとポートが一致しているかを確認します。v2rayNの一般的なローカルポートは10808ですが、アップグレード、設定の移行、手動変更後は「設定」→「パラメータ設定」に表示される実際の値を優先してください。
- ログに
127.0.0.1からの接続が表示される：アプリはローカルの受信口まで到達しています。 - 新しい記録がまったくない：まずアプリのプロキシ設定とシステムプロキシの状態を確認します。
bindまたはaddress already in useが表示される：ローカルの待受ポートが別のプロセスに使用されています。- SOCKSクライアントがHTTPポートへ接続している：プロトコルバージョンエラーや、接続が即座に拒否されることがあります。
第2・第3段階：どの出口がルールで選ばれたか
受信が正常なら、次にリクエストがプロキシ、直接接続、ブロックのどれへ送られたかを確認します。ルーティングルールの順序が誤っていると、ノード自体は正常でも、対象ドメインが先にある直接接続またはブロックルールに捕捉されます。その後、送信ダイヤルを確認します。この段階では、ドメイン解決、サーバーポート、通信方式、TLSパラメータ、ユーザー認証が関係します。
| 確認する場所 | 典型的な症状 | 優先して確認する項目 |
|---|---|---|
| 受信 | 接続記録がない、または待受に失敗 | システムプロキシ、10808ポート、プロトコル種別 |
| ルーティング | リクエストが誤った出口に送られた | ルールの順序、ドメイン分類、直接接続とブロックのルール |
| 送信 | ダイヤルのタイムアウト、認証失敗 | サーバーアドレス、ポート、UUID、通信方式、TLS |
| 応答段階 | 接続したがすぐ切断される | リモートの応答、ネットワーク切り替え、アイドル接続の切断 |
rejected、timeout、invalid userはそれぞれ何を意味するか
同じ問題でも、V2RayとXrayのコア、通信方式、バージョンによって表現が少し異なる場合があります。判断では中心となる動作に注目してください。rejectedはどこかの層が接続を明確に拒否したこと、timeoutは制限時間内に処理が完了しなかったこと、invalid userは認証情報の不一致を直接示します。
エラー：rejected
原因と対処：拒否はローカルの受信口、ルーティングによるブロック、またはリモートサーバーで発生する可能性があります。rejectedの後に続くモジュール名を確認してください。blockedも同時に出ている場合はルーティングルールを確認し、authenticationやinvalid userが続く場合はノードの認証パラメータを確認します。
エラー：connection timeout
原因と対処：制限時間内に接続を確立できなかった状態です。まずサーバーアドレスとポートを確認し、現在のネットワークと別の利用可能なネットワークでそれぞれテストします。1つのノードだけがタイムアウトする場合は、ノードのパラメータまたはリモート側への到達性を優先して確認します。
エラー：dial tcp: i/o timeout
原因と対処：TCPダイヤルが時間内に完了していません。対象アドレスに到達できない、ポートが応答しない、ネットワーク経路が不安定といった原因が一般的です。UUIDを先に変更せず、まずアドレス、ポート、基本的なネットワーク接続を確認します。
エラー：invalid user
原因と対処：サーバーがクライアントから送信されたユーザー情報を認識できていません。VMessまたはVLESSノードのUUID、追加の認証パラメータ、サブスクリプションの更新時刻を確認し、古いノードと新しい設定を混在させていないか確認します。
エラー：failed to find an available destination
原因と対処：送信先として利用できる宛先が見つかっていません。アドレス解決の失敗、宛先リストが空、先行するダイヤルがすべて失敗したことなどが原因です。ノードアドレスの入力ミスとDNSの結果を確認し、コアを再起動して再テストします。
エラー：context canceled
原因と対処：上位の処理によって現在の操作がキャンセルされています。ノードの切り替え、コアの停止、先行する接続失敗などでよく発生します。多くの場合は結果として出るメッセージなので、上にさかのぼって、より早いtimeout、rejected、認証エラーを探します。
エラー：address already in use
原因と対処：待受に使用するローカルポートがすでに占有されています。重複起動しているクライアントを終了するか、「設定」→「パラメータ設定」で未使用のローカルポートに変更します。たとえば10808から空いているポートへ変更し、アプリのプロキシ設定も同じポートに更新します。
rejectedをすべてノード障害と判断しない
ログには広告ドメイン、LAN上の検出、システムの接続確認、ユーザーが意図的にアクセスした通信が同時に含まれることがあります。ブロックルールが想定どおりリクエストを拒否した場合も、rejected系の情報が出ます。エラーの時刻が対象操作と一致し、該当ドメインやIPが今回のアクセス先そのものである場合に限り、主要な手がかりとして扱ってください。
- 1つのドメインだけ失敗し、他のサイトは正常：そのドメインのルーティング分類とDNSの結果を確認します。
- すべてのプロキシリクエストがタイムアウト：ノードアドレス、サーバーポート、現在のネットワークを確認します。
- すべてのノードでポート占有が表示される：ローカルの受信口を対処し、ノードごとに変更する必要はありません。
- サブスクリプション更新後に突然invalid userが出る：クライアントで実際に有効になっているノードが更新後のものか確認します。
1つずつ条件を変えて原因を絞り込む
効果的な切り分けには再現可能な比較が必要です。DNS、ポート、通信方式、ルーティングルールを一度に変更すると、接続が戻ってもどの変更が効いたのか分かりません。元の設定をコピーして保存し、毎回1つの条件だけを変更し、同じ対象に対して再テストする方法が確実です。
- ローカル受信を確認：コアを起動した後、実際に設定されているポートで正常に待受できているか確認し、ブラウザーのリクエストがログに入るか観察します。
- ノード選択を確認：クライアントのメイン画面で対象ノードを選び直し、編集したノードとは別のノードを使用していないか確認します。
- ルーティングを一時的に簡略化：設定への影響範囲を明確にしたうえで、基本的なプロキシルールで再テストし、複雑な分岐が誤判定の原因かどうかを確認します。
- 送信パラメータを確認：サーバーアドレス、ポート、VMessまたはVLESSの種別、UUID、通信方式、TLS、サーバー名を項目ごとに比較します。
- ネットワークを切り替えて比較：ノードとクライアント設定を変えずにネットワークだけを切り替えます。エラーが継続的なタイムアウトから正常な接続に変わるなら、原因は現在のネットワーク経路に近いと考えられます。
- 設定を戻して確認：原因が分かったら、その他の一時設定を元に戻し、よく使う対象に3回続けてアクセスします。少なくとも2分間、同じエラーが再発しないか観察します。
ポート占有を完全に切り分ける手順
v2rayNの起動後にウェブページへまったくアクセスできず、ログにリモートへのダイヤルエラーではなくローカル待受エラーが最初に出たとします。この場合はまず10808ポートを対処し、ノードの変更や通信パラメータの修正は行いません。典型的なログは次のような形になります。
failed to start inbound
listen tcp 127.0.0.1:10808: bind: address already in use重複起動しているクライアントのプロセスを完全に終了してから、もう一度起動します。それでも占有されている場合は、「設定」→「パラメータ設定」で別の未使用ローカルポートを選び、ブラウザーまたはシステムプロキシにも同じポートを設定します。変更後のログでは、まず待受成功が表示され、その後に本機からの接続記録が出るはずです。リクエストがコアに入ってから、ルーティングと送信を確認します。
よくあるログの症状別対処
トラブルは1つのエラーテキストだけでなく、「接続記録はあるのにウェブページが返らない」「起動直後は正常だが数分後にタイムアウトする」といった複合的な症状になることがあります。ここではよくある状況ごとに最初に行う操作を示します。完了後も、障害が発生した時刻付近のログに戻って確認してください。
ログが流れ続ける場合、直前の失敗をどう見つける？
まずログを消去し、バックグラウンドのダウンロードを停止して、テスト用のウェブページを1つだけ開きます。クリックした時刻を控え、その後30秒間の記録から対象ドメイン、timeout、rejected、failed、errorを検索します。
起動成功と表示されるのに、ブラウザーに新しいログがまったくない？
v2rayNのシステムプロキシの状態と、ブラウザーに個別のプロキシが設定されていないかを確認します。手動でプロキシを入力している場合、アドレスは127.0.0.1にし、ポートはクライアントの現在の設定と一致させます。
connection timeoutが発生するのが1つのノードだけ？
ネットワークを変えず、既知の正常な別ノードへ切り替えてテストします。他のノードが正常なら、問題のノードのサーバーアドレス、ポート、通信パラメータを確認し、サブスクリプションを更新してからノードを選び直します。
ノード切り替え後にcontext canceledが大量に出る？
ノードを切り替えると古い接続が終了するため、通常この記録を個別に処理する必要はありません。新しいコアの状態が安定してから再テストし、新しい時刻の範囲で、より早く発生したダイヤルまたは認証エラーを探します。
v2rayNGでは接続済みなのに、アプリがタイムアウトする？
サイドメニューからログを開き、対象アプリのリクエストが記録されているか確認します。記録がなければ、システムの接続許可とアプリ自身のプロキシ設定を確認します。記録があれば、ルーティングと送信の段階に沿って切り分けます。
DNSの問題とノードの問題を見分ける方法
ログにドメイン解決の失敗が出ていて、既知のIPを直接使う別のリクエストが正常なら、原因はDNSに近いと考えられます。ノードサーバー自体がドメイン名で指定されている場合、解決失敗によって送信ダイヤルが直接阻止されます。対象ドメインだけ解決に失敗する場合は、DNSの分岐設定とドメインルールも確認が必要です。timeoutが出たからといって、すぐDNSだと判断しないでください。ポートに到達できない場合もタイムアウトになります。
lookup、no such hostが表示される：まずDNS設定とノードアドレスの入力ミスを確認します。- IPアドレスの解決後に
dial tcpがタイムアウトする：ポートとネットワーク経路を重点的に確認します。 - TCP接続後に認証エラーが出る：UUID、プロトコル種別、サーバー側のパラメータを確認します。
- 特定のドメインだけ誤った出口を通る：ルーティングルールの順序と、GeoSiteデータが最新かどうかを確認します。
古いルーティングデータが残っていると、ドメイン分類が想定と一致しないことがあります。ただし通常、invalid userを発生させることはありません。エラーと処理範囲を対応させれば、無関係な変更を避けられます。認証エラーはユーザーパラメータ、待受エラーはローカルポート、名前解決エラーはDNS、ルールの誤適用はルーティングを確認します。
再確認できるトラブル記録を保存する
断続的な切断は、再起動すると一時的に直ることがあるため、特に対処が難しい問題です。最後のエラーだけを切り取るのではなく、構造化した記録を保存すれば、次回の再現時に直接比較できます。クライアント、コア、ネットワーク環境、ノード種別、発生時刻、最初の異常を記録してください。
| 記録項目 | 記入例 | 用途 |
|---|---|---|
| クライアントとバージョン | v2rayN 7.x | メニューの場所と初期動作を判断する |
| コアの種類 | XrayまたはV2Ray | ログ表現の違いを説明する |
| ローカル受信 | 127.0.0.1:10808 | アプリが正しいポートへ接続しているか確認する |
| プロトコルと通信方式 | VLESSとTCP | 認証と通信方式の確認範囲を絞る |
| 再現時刻 | 14:32:10〜14:32:40 | 大量のログからリクエストを特定する |
| 最初の異常 | dial tcp: i/o timeout | 根本原因と後続の連鎖エラーを区別する |
設定の管理者に問題を報告する際は、上記の環境情報と、機密情報を伏せたエラー部分を提供できます。サブスクリプションURL、UUID、パスワード、トークン、完全なサーバーアドレス、個人がアクセスしたドメインは削除してください。時刻、モジュール名、エラー種別、ポートを残せば、多くの判断に必要な情報を保てます。
- まず元のテキストをコピーしてから機密情報を伏せ、スクリーンショットで重要な前後関係が切れないようにします。
- エラーの前後を少なくとも10行残し、どの操作を行ったかを記載します。
- 問題が安定して再現するのか、断続的に発生するのか、ネットワークやノードを切り替えた場合の比較結果を説明します。
- 修復後は同じ操作を繰り返し、画面に「接続済み」と表示されるだけでなく、元のエラーが再発しないことを確認します。