ノードのタイムアウト、ウェブページが開かない、コアの起動失敗、サブスクリプション更新エラーに悩むv2rayNユーザー向けです。画面ログ、コアログ、アクセスログを区別し、時刻、接続先、出力タグ、エラー末尾から手がかりを取り出して、timeout、rejected、invalid user、connection refused、ポート競合などを具体的な確認作業に結び付けます。
まずv2rayNの3種類のログを区別する
切り分けの前に、赤字の行だけを抜き出すのは避けてください。v2rayNは設定管理、サブスクリプション更新、システムプロキシ、コアプロセスの制御を担当し、VMessやVLESSなどの接続を実際に確立するのは通常Xrayコアです。2つのプログラムは記録する対象が異なるため、同じ障害でも、まずコアログに接続失敗が現れ、その後に画面ログでテストタイムアウトとして表示されることがあります。
v2rayN 7.xでは、ボタン名がマイナーバージョンによって変わることがありますが、主ウィンドウ下部のログ欄、タスクトレイメニューのログ項目、プログラムフォルダー内のログファイルから確認できます。使用中のv2rayNバージョン、コアバージョン、ノード名、障害発生時刻を記録してから、前後10～30秒のログを確認しましょう。
| ログの種類 | 主な内容 | 切り分けに適した問題 |
|---|---|---|
| 画面・実行ログ | サブスクリプション更新、遅延テスト、設定生成、コアの起動と終了 | サブスクリプション解析失敗、ファイル入出力失敗、コアの繰り返し終了 |
| コアエラーログ | DNS、ルーティング、インバウンド待受、アウトバウンド接続、TLSとプロトコルハンドシェイク | ノードのタイムアウト、パラメーター不一致、証明書名の誤り、ポート競合 |
| アクセスログ | 送信元アドレス、接続先ドメインまたはIP、選択されたアウトバウンド、acceptedまたはrejected | リクエストがコアに入ったか、ダイレクトまたはプロキシのルールに一致したかの判断 |
ログはリクエストの経路に沿って読み進めます。ブラウザーからローカルインバウンドに入っていない場合は、システムプロキシやアプリのプロキシ設定が原因であることが多く、リクエストが入った後に誤ったアウトバウンドへ送られているならルーティングを確認します。アウトバウンドでノードが選択されているのに接続がタイムアウトする場合は、ネットワーク、名前解決、アドレス、ポートを調べます。timeoutを見てすぐプロトコルを変更するよりも、効果的な方法です。
ログレベルを設定し、完全な再現ログを1回残す
普段はwarningまたはinfoレベルを維持するのがおすすめです。warningは静かで、明確な失敗の確認に向いています。infoではインバウンド、ルーティング、アウトバウンドの流れも記録されるため、初回の切り分けに適しています。debugは記録量が多く、ログファイルが急速に大きくなる可能性があるため、再現が難しい場合や通常レベルでは情報が足りない場合だけ短時間有効にしてください。
v2rayN 7.xでは、まず「設定」→「パラメーター設定」を開き、ログ関連の項目を確認します。一部のバージョンでは、コアのログ設定が「設定」→「パラメーター設定」→「Coreタイプ設定」付近にあります。表示名が異なる場合は、log、ログレベル、アクセスログなどの語を含む項目を探してください。変更後はコアを再起動します。再起動しないと、古いプロセスが以前の設定を使い続けることがあります。
- 現在時刻を記録します。例：14:32:10。同時に実行中のダウンロードや速度測定を停止してください。
- 画面上の古い表示を消すか、ログ末尾に時刻の目印を付け、前日のエラーを今回の障害と取り違えないようにします。
- ノードを1つ選んでコアを再起動し、3～5秒待ってローカルインバウンドの待受が完了したことを確認します。
- 操作は1つだけ実行します。たとえば、ウェブページを1回開く、実際の接続遅延を1回測定する、サブスクリプションを1回更新する、といった具合です。
- 障害が発生したら連続クリックをすぐに止め、エラーの前後少なくとも20行を残します。
- ログレベルを元に戻し、タイムスタンプを使って画面ログとコアログを照合します。
2026/06/25 14:32:11 [Info] transport/internet/tcp: dialing TCP to tcp:198.51.100.24:443
2026/06/25 14:32:16 [Warning] transport/internet: failed to dial outbound
2026/06/25 14:32:16 [Error] proxy/vless/outbound: failed to find an available destination
2026/06/25 14:32:16 [Error] common/retry: dial tcp 198.51.100.24:443: i/o timeoutこの例では、最後の行が直接的なエラーで、最初の行に接続先IP、ポート、開始時刻が示されています。両者には5秒の差があり、リモート側のハンドシェイクより前のTCP接続段階で停止したことが分かります。この場合はUUID、フロー制御、伝送経路を変更する前に、アドレスへの到達性、ファイアウォール、ポートを確認します。
結論：まずinfoで1回再現する
warningで最終的なtimeoutしか残らない場合は、レベルを一時的にinfoへ変更して1回だけ再現します。それでもリクエストの到達、ルーティング選択、接続先が分からない場合に限り、短時間だけdebugを使います。
頻出エラーの原文、原因、対処の方向性
エラーメッセージは複数の層の原因が連結されていることが多く、前半はどのモジュールで失敗したか、末尾のcaused byまたはコロン以降の短い文は直接の原因を示します。最初のfailedだけを検索せず、全体の末尾から前へ読み、接続先アドレス、ポート、アウトバウンドタグと照合してください。
エラー：failed to find an available destination
原因と対処：候補となる接続先を試しても接続を確立できませんでした。この行は上位層による要約にすぎないことが多いため、直後にあるtimeout、connection refused、DNSエラーを確認します。ノードのアドレスとポートを照合し、端末上でドメインを名前解決できるかテストしてください。
エラー：dial tcp 198.51.100.24:443: i/o timeout
原因と対処：制限時間内にTCP接続を完了できていません。ネットワークに到達できない、ポートが遮断されている、リモート側が応答しない、誤ったアドレスへ解決されている、といった原因が考えられます。まず通常のネットワーク接続と端末の時刻が正しいことを確認し、サブスクリプションのサーバーアドレスと443ポートを照合してください。
エラー：context deadline exceeded
原因と対処：何らかの処理が待機期限を超えています。サブスクリプションのダウンロード、DNS問い合わせ、ノードテスト、アウトバウンド接続などで発生します。まず直前の行に示された処理対象を確認してください。サブスクリプション更新の失敗ならURLとプロキシ経由の更新設定を、ノード接続の失敗なら接続先ネットワークを調べます。
エラー：connectex: No connection could be made because the target machine actively refused it
原因と対処：接続先ホストが明確に接続を拒否しています。通常は対象ポートでサービスが待ち受けていないか、アドレスまたはポートの入力ミスが原因です。timeoutとは異なり、ネットワーク経路は接続先まで到達している可能性が高いため、まずポートとサーバー側サービスの稼働状態を確認します。
エラー：proxy/vless/encoding: invalid user
原因と対処：認証情報が接続先に受け入れられていません。UUIDのコピー漏れ、サブスクリプション更新後も古いノードを使っている、クライアントとサーバーの設定が一致していない、といった原因が一般的です。まずサブスクリプションを更新してノードを選び直し、その後UUID、プロトコル種別、関連する認証パラメーターを順に照合してください。
エラー：rejected proxy/vmess/encoding: invalid user
原因と対処：VMessのユーザー情報または時刻条件を満たしていません。システムの日付、時刻、タイムゾーンを自動同期し、ノードが現在有効なサブスクリプション由来であることを確認します。複数の端末で同じノードに同じエラーが出る場合は、設定の提供元にユーザー情報を確認してもらってください。
エラー：rejected by rule
原因と対処：リクエストがブロック用のルーティングに一致しています。これはノード自体が停止しているという意味ではありません。同じアクセス記録にあるドメイン、ポート、ルールタグを確認し、広告ブロック、プライベートアドレス、自作ルールによる誤ブロックがないか調べます。必要に応じて、接続先を明示的なプロキシまたはダイレクトのルールに追加してください。
エラー：listen tcp 127.0.0.1:10808: bind: Only one usage of each socket address is normally permitted
原因と対処：ローカルの10808ポートが別のプロセスに使用されているため、新しいコアが待ち受けできません。二重起動しているv2rayNまたは古いコアプロセスを完全に終了してください。また、「設定」→「パラメーター設定」で未使用のポートに変更し、ブラウザーやアプリのプロキシポートも合わせて変更できます。
エラー：remote error: tls: handshake failure
原因と対処：TLSハンドシェイクがリモート側に拒否されています。サーバー名、トランスポート設定、リモート証明書の設定が一致していない場合によく発生します。サブスクリプション取り込み後のserverName、伝送方式、ポートを照合し、証明書関連の検証を無効にして設定ミスを隠さないでください。
エラー：no such host
原因と対処：ノードのドメインからアドレスを解決できません。ドメインの入力ミス、DNSの一時的な障害、端末側のネットワーク制限などが考えられます。ノードアドレスをコピーして空白が入っていないか確認し、システムのネットワーク診断で解決結果を調べます。利用可能なDNSへ変更してコアを再起動してから再試行してください。
ログのacceptedも、最終的なアクセス成功を意味するとは限りません。通常は、リクエストがいずれかのインバウンドに受け付けられた、または指定されたアウトバウンドへ渡されたことを示します。acceptedの後にリモートリセット、TLS失敗、DNSエラーが続く場合は、同じ時間帯のログを下へ読み進めてください。逆に、そのリクエストがまったく見つからない場合は、システムプロキシ、ブラウザーのプロキシ、TUN設定を確認し、通信がv2rayNへ入っているかを調べます。
症状からログの手がかりを追う固定手順
同じページ上の症状でも、原因の層は異なる場合があります。ウェブページが読み込み中のままになるのは、ローカルポートが起動していないためかもしれませんし、ノード接続のタイムアウトかもしれません。遅延テストには数値が出るのにページが開かない場合は、テスト方法と実際のアクセス経路が異なる可能性があります。固定手順なら各段階で1つの層だけを切り分けられ、プロトコル、DNS、ルーティング、システムプロキシを同時に変更せずに済みます。
ステップ1：基本環境を確認する
- システムプロキシを無効にして通常のウェブサイトへアクセスし、端末のネットワーク自体が利用できることを確認します。
- システムの日付と時刻の設定で自動同期を有効にします。VMessなどの認証処理は時刻のずれに敏感です。
- v2rayNのバージョンと現在のコアバージョンを記録し、アップデート後の問題を古いログで判断しないようにします。
- サブスクリプション更新時は、リンクが完全にコピーされていることと、有効期限内であることを確認します。
ステップ2：コアが実際に起動しているか確認する
ノードを切り替えた後、設定生成、コア起動、ローカル待受の情報が表示されるか確認します。コア起動直後に終了する場合は、まずbind、設定構文、ファイル権限、コアファイルのエラーに対処します。ローカルポートが待ち受けを開始したことがログに明記されて初めて、システムプロキシから接続できる入口が用意されます。
ステップ3：リクエストがローカルポートに入っているか確認する
一般的なローカルSOCKSポートは10808で、設定によってはHTTPポートが10809になっていたり、混合ポートが使われていたりします。よくある番号をそのまま当てはめず、v2rayNの「設定」→「パラメーター設定」に表示されているポートを確認してください。ブラウザー、コマンドラインツール、システムプロキシは、実際に待ち受けている同じポートへ接続する必要があります。
| 確認できる症状 | 最初に確認するログ | 優先する対処 |
|---|---|---|
| コアが起動直後に終了する | bind、failed to start、設定読み込みエラー | ポートを解放するか、有効な設定に戻す |
| ログにウェブリクエストがまったくない | ローカルインバウンドの待受とアクセスログ | システムプロキシとアプリのプロキシポートを確認する |
| リクエストがrejectedと表示される | ドメイン、接続先ポート、ルーティングタグ | ルールの順序または一致条件を修正する |
| リクエスト到達後にi/o timeoutになる | アウトバウンドのアドレス、IP、ポート | ノードへの到達性とサブスクリプションのパラメーターを確認する |
| 一部のドメインだけ失敗する | DNSの結果と分岐先アウトバウンド | 成功したドメインと失敗したドメインのルール一致を比較する |
ステップ4：一度に1つの変数だけ変更する
ノードの変更、DNSの修正、ルーティングモードの切り替え、ポート調整を同時に行うと、接続が戻っても本当の原因を特定できません。まず元のノードを維持し、ログが示した項目だけを修正してください。再テストしても失敗したら次の層へ進みます。各テストの間隔は3～5秒空け、古いコアの終了と新しい設定の読み込みを待ちます。
結論：エラー末尾が最初の確認項目を決める
timeoutならまずネットワークへの到達性、connection refusedなら待受ポート、invalid userなら認証パラメーター、rejected by ruleならルーティングを確認します。4種類のエラーをすべてノード速度の問題に決めつけないでください。
よくあるログの疑問と具体的な対処
ログのトラブルシューティングは、warningを完全になくすことが目的ではありません。ネットワークの切り替え、閉じたブラウザー接続、アプリによるキャンセルでも警告は残ります。重要なのは、エラーの時刻が目に見える障害と一致するか、安定して再現するか、同じ接続先とアウトバウンドに集中しているかです。
ログが急速に流れるとき、どこから見ればよい？
まず速度測定と一括サブスクリプション更新を停止し、現在の秒数を記録して、失敗する接続先へ1回だけアクセスします。その後、その時刻以降で最初のWarningまたはErrorを探し、その前にある接続先アドレス、ルーティングタグ、インバウンドの記録も残します。
timeoutが出たらノードが無効になったということ？
すぐには判断できません。同じネットワークで、正常な別のノードを2つテストしてください。すべてが約5秒後にタイムアウトするなら、まず端末のネットワークや出口側の制限を確認します。1つのアドレスだけが継続的にタイムアウトし、他のノードが正常なら、そのノードのアドレスまたはポートの問題である可能性が高くなります。
遅延は正常なのに、なぜウェブページが開かない？
まずテストの種類を確認します。基本的なTCP遅延はポートの接続性だけを確認し、実接続の遅延は完全なプロキシ経路に近い測定です。次に、ウェブリクエストが10808または現在実際に使われているポートへ入っているか、アクセスログでproxy、direct、blockのどのアウトバウンドが最終選択されたかを確認します。
サブスクリプション更新でcontext deadline exceededと表示されたら？
サブスクリプションURLが完全か確認し、サブスクリプショングループの設定でプロキシ経由の更新が必要かを確認します。プロキシが必要なら、まず動作確認済みのノードへ接続してください。同時に、エラーで失敗したのがDNS問い合わせ、TCP接続、ダウンロード読み込みのどれかを確認します。
ポートを変更してもaddress already in useと表示されるのはなぜ？
v2rayNを完全に終了し、古いコアプロセスが終了していることを確認してから再起動します。新しいポートも別のプログラムに使用されていないか調べ、システムプロキシと手動設定しているアプリのポートも更新してください。コアのポートだけ変更すると、アプリは古い入口へ接続し続けます。
再現可能な情報を整理して切り分けを続ける
複雑な障害では、環境、操作、ログをまとめて確認する必要があります。failed to dial outboundという一文だけでは、DNS、TCP、TLS、認証、ルーティングのどの層が原因か判断できません。整理する際は、問題を再現できる最小限の情報を優先して残します。
- クライアント情報：v2rayNの完全なバージョン番号とXrayコアのバージョン。
- 実行環境：Windowsのバージョン、現在のネットワーク種別、直前に別のネットワークへ切り替えたかどうか。
- 設定の種類：VMessまたはVLESS、TCPまたはWebSocketなどの伝送方式。認証内容は添付しない。
- 再現操作：例として、コア起動後5秒待ち、指定した種類のウェブページを1回開く。
- 期待値と実際の結果：正常に読み込まれるはずが、実際には10秒後にタイムアウトする、または即座に拒否される。
- ログの範囲：障害発生の10秒前から10秒後まで。最初の異常と最下層の原因を含める。
- 比較結果：同じネットワークで他のノードは正常か、システムプロキシを無効にすると通常のネットワークは正常か。
1回修正したら、同じ接続先と同じ操作で再テストします。以前のinvalid userが消えてTLS handshake failureが出た場合、認証層は通過し、切り分けを伝送とTLSパラメーターへ進められる状態です。これは修正が無効だったのではなく、より深い層のエラーが見えるようになったということです。
エラーが断続的に発生する場合は、少なくとも3回分の所要時間と接続先を比較します。毎回約5秒または10秒でtimeoutになるなら、固定のタイムアウト処理が発動している可能性が高いです。所要時間が数十ミリ秒から数秒まで大きく変動する場合は、ネットワークのパケットロス、DNS結果の変化、ノード負荷をより重視します。具体的な時間差を残すほうが、「たまに遅い」とだけ説明するより判断しやすくなります。
結論：エラーのスクリーンショットではなく時系列で確認する
コアの起動、リクエストの到達、ルール一致、アウトバウンド接続、最終エラーを秒単位で並べると、障害がどの層で止まったかが分かりやすくなります。最後の1行だけを写したスクリーンショットでは、最も重要な前後関係が失われます。