v2rayN のログは GUI とコアの2層に分かれており、コアログはさらに読み込み・ハンドシェイク・ルーティングの3段階で並びます。本記事では2種類のログの開き方と保存先、よくあるエラー6件の意味と対処法、タイムスタンプからアウトバウンドノードまでたどる5ステップの切り分け手順を扱います。接続できない、サブスクリプションの更新に失敗する、ルーティングルールが効かないという3つの場面に向いています。
ログは2層:GUI ログとコアログ
結論から言うと、v2rayN で確認できるログは2種類あります。GUI ログはコアの起動・終了、ノードの切り替え、サブスクリプションの更新、システムプロキシのオン・オフといった画面操作を記録します。コアログは各接続がインバウンドからアウトバウンドまで通る経路を丸ごと記録します。接続系のトラブルを GUI で追っても「起動に成功しました」といった記録しか見えず、失敗の原因はそこにはありません。
ログの入口はメイン画面下部の「ログ」タブで、GUI ログとコアログを切り替えられます。GUI ログはプログラムフォルダ内の guiLogs サブフォルダにも日付ごとのファイルとして書き出されます。コアログは既定では画面にしか出力されないため、ルールのマッチ状況や名前解決の記録まで見たいときは「設定」→「パラメータ設定」でログレベル(loglevel)を warning から info または debug に変更し、調査が終わったら warning に戻します。
| 記録の層 | 開く場所 | 主な記録内容 | 向いている場面 |
|---|---|---|---|
| GUI ログ | 「ログ」タブで GUI 側に切り替え | コアの起動と終了、サブスクリプション更新、ノード切り替え、システムプロキシのオン・オフ | 画面操作の失敗か接続の失敗かを判断する |
| コアログ | 同じタブでコアログに切り替え | インバウンドの受信、ルーティング判定、アウトバウンドの接続、エラースタック | 接続失敗がどの段階で起きたかを特定する |
| ログファイル | プログラムフォルダの guiLogs サブフォルダ、日付ごとに命名 | GUI ログの履歴保存 | 再起動後に前回の起動記録を振り返る |
3つの記録のうち、接続トラブルの調査で主に見るのはコアログです。GUI ログの役割はコアが本当に起動しているかを確認することにあります。GUI ログに起動記録すらないなら、その先の分析は意味を持ちません。まずコアの起動失敗を解決してください。
コアログの3段構造:読み込み・ハンドシェイク・ルーティング
正常なリクエストはコアログに4〜6行の記録を残し、時系列で3つの段に分かれます。読み込み段はコアが設定を読み込み、ローカルポートを待ち受ける部分。ハンドシェイク段はインバウンドがリクエストを受け取り、アウトバウンドが接続を開始する部分。ルーティング段はルール判定と最終的なアウトバウンドの結果です。トラブルの切り分けは、まずエラーがどの段に落ちているかを見極めることから始まります。
2026/07/02 09:14:02 [Info] infra/conf/serial: Reading config: config.json
2026/07/02 09:14:02 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
2026/07/02 09:14:31 [Info] [4821937461] proxy/vless/inbound: received request for tcp:example.com:443
2026/07/02 09:14:31 [Info] [4821937461] app/dispatcher: default route for tcp:example.com:443
2026/07/02 09:14:31 [Info] [4821937461] transport/internet/tcp: dialing TCP to tcp:node.example.net:443
2026/07/02 09:14:32 [Info] [4821937461] proxy/vless/outbound: tunnelling request to tcp:example.com:443角括弧内の数字はリクエスト ID で、同じ接続のログはすべて同じ ID を共有します。ログの流れが速いときは1行ずつ読む必要はありません。ID の1つを検索すれば、1本の経路の記録をまとめて追えます。
| 段 | 典型的なログ行 | 説明 |
|---|---|---|
| 読み込み | Reading config、listening TCP on 127.0.0.1:10808 | コアが設定を読み込み、ローカルポートを待ち受ける。この行がなければコアが起動していない |
| ハンドシェイク | received request for tcp:...、dialing TCP to tcp:... | インバウンドが要求を受け取り、アウトバウンドが接続を開始する。前者だけあって後者がなければ、原因はルーティング判定かローカルネットワーク |
| ルーティング | default route for、tunnelling request to | ルール判定の結果と最終的なアウトバウンド。direct が出ていれば直接接続ルールに一致している |
3つの段で最も見落とされやすいのがルーティング段です。対象ドメインがルールで直接接続と判定されると、アウトバウンドの接続行もエラーも出ず、ページが読み込み中のままになります。この場合はノードを変えるのではなく、「ルーティング設定」に戻ってルールの順序を確認してください。
よくあるエラー6件の原文一覧
以下はコアログで出現頻度の高いエラー6件を、インバウンドからアウトバウンドの順に並べたものです。それぞれ原因と対処法を添えています。原文はそのままログ画面の検索ボックスに貼り付けて位置を特定できます。
エラー:address already in use
原因と対処:ローカルの待ち受けポートが使用中です。v2rayN は既定で 10808(SOCKS)と 10809(HTTP)を使うため、他のプロキシツールや終了しきっていないコアプロセスが同じポートを掴んでいるとこのエラーが出ます。まずタスクマネージャーで残ったプロセスを終了するか、「設定」→「パラメータ設定」でローカル待ち受けポートを 20808 に変更してコアを再起動してください。
エラー:failed to find an available destination
原因と対処:アウトバウンドのサーバーアドレスを名前解決できていません。ノードアドレスの打ち間違い、DNS 解決の失敗、DNS 汚染のいずれでも発生します。まず「パラメータ設定」の DNS 設定を 1.1.1.1 または 223.5.5.5 に変更してコアを再起動してください。それでも解消しない場合は、ノードアドレスを IP に置き換えて再試行し、名前解決の問題かアドレス自体の誤りかを切り分けます。
エラー:dial tcp ...: i/o timeout
原因と対処:アウトバウンド接続がタイムアウト時間内に応答を受け取れていません。まずサーバーのアドレスとポートに到達できるか、同じノードが別のネットワークでつながるかを確認します。タイムアウトが特定のノードに集中するならそのノードを変更するだけで済みます。すべてのノードでタイムアウトするなら、ローカルのファイアウォールが v2rayN とコアプロセスを許可しているかを確認してください。
エラー:tls: first record does not look like a TLS handshake
原因と対処:トランスポート層の設定がサーバー側と一致していません。サーバーで TLS を有効にしていないのにクライアントで有効にしている、あるいは両者のパラメータが食い違っている場合によく起きます。ノードの共有リンクをインポートし直し、「転送プロトコル」と「転送層のセキュリティ」の2項目がサーバーの実際の設定と一致しているか確認してください。この2項目の値は手作業で組み合わせないようにします。
エラー:rejected proxy/vless: invalid user
原因と対処:UUID またはパスワードがサーバー側に登録された値と一致していません。サブスクリプション更新後にこのエラーが出る場合は、サーバー側で UUID が変わり、ローカルに古い値が残っているケースが大半です。共有リンクをコピーし直すか、サブスクリプションを再インポートすれば解決します。ほかの設定は触る必要はありません。
エラー:connection reset by peer または EOF
原因と対処:接続の確立後に相手側から切断されています。サーバー側プロセスの再起動、プロトコルパラメータの不一致、経路上の中間機器による介入などで発生します。まず同じ設定のまま別のノードで試してください。ノードを変えて正常ならそのノード単体の問題で、どのノードでも切れるなら設定側に戻って確認します。
結論:まず段を分け、それからキーワードを照合する
同じ i/o timeout でも、アウトバウンドの接続行の後に出ていればサーバーか経路の問題、コアの起動段階で出ていればローカルネットワークと DNS を疑います。キーワードを照合する前に、リクエスト ID でそのエラーがどの段に属するかを確認してください。
切り分け手順:タイムスタンプからアウトバウンドノードまで
ログの量が多いとき、1行ずつ読むのは効率的ではありません。次の5ステップを順に進め、各ステップで1つの問いにだけ答えるようにすると、通常は2〜3分で失敗箇所を特定できます。
- タイムスタンプを突き合わせる。ログ内で
failedまたはerrorを検索し、その行の時刻を記録します。同じ秒、あるいは1〜2秒前までさかのぼり、同じリクエスト ID の最後の正常な記録を探します。障害はこの2行の間で起きています。 - トラフィックがコアに届いているか確認する。
received requestを検索します。この行がまったくない場合は、リクエストが v2rayN に届いていません。システムプロキシのスイッチ、ブラウザのプロキシ拡張、システムプロキシのポートがローカル待ち受けポート(既定 10808 / 10809)と一致しているかを確認してください。 - ルーティング判定の結果を見る。
default routeとdirectを検索します。対象が直接接続と判定されていると、アウトバウンドの接続行は出ず、つながらないのにエラーも出ない状態になります。「ルーティング設定」に戻ってルールの順序を調整してください。 - アウトバウンドの結果を見る。
dialing TCP toの直後にあるエラーが根本原因です。前節の6件の原文と照合して対処してください。接続に成功した後にEOFが出る場合は、そのノードを使用不可として扱います。 - 変数を固定して再現する。失敗する対象を1つだけ残し、サブスクリプションの自動更新と遅延測定をオフにして、1回再現したらすぐ止め、ログを消してからやり直します。これでログは数千行から数十行に減り、以降の判断を勘に頼らずに済みます。
結論:再現できるログでないと役に立たない
失敗する対象を1つのドメインに固定し、1回再現して、そのリクエスト ID の経路だけを切り出せば、通常30行以内に収まります。数千行の過去ログをめくるより、この一手のほうがはるかに精度が高いです。
ログ調査でよくある疑問
以下は実際の利用時のフィードバックから出た5つの質問で、答えはどれも具体的な操作につながります。
ログが Info ばかりなのは問題がある?
問題ありません。Info は正常な接続の記録で、対処が必要なのは Warning と Error だけです。ログレベルを warning に戻しても出力が短くなるだけで、接続の結果は変わりません。
ログの流れが速すぎて読めないときは?
まずサブスクリプションの自動更新と遅延測定をオフにし、対象ドメインを1つに固定して1回再現します。調査が終わったらログレベルを debug から warning に戻し、不要な出力を減らしてください。
3つのノードに変えても同じエラーが出る?
ノードを変える意味があるかはエラーの位置で決まります。インバウンド段とルーティング段のエラーはノードを変えても無駄で、アウトバウンド段のタイムアウトや EOF 系のエラーだけがノード変更で検証する価値があります。
ログに実際のドメインや IP が出るのは正常?
正常です。コアは各接続の接続先アドレスを記録します。ログを他人に渡す前に、自分のサーバーアドレスと対象ドメインを置き換えておいてください。
サブスクリプションの更新に失敗し、コアログには何も出ない?
サブスクリプションの更新は GUI 層で行われるため、コアログではなく GUI ログを見てください。先に利用可能なノードのいずれかに接続し、サブスクリプション設定で「プロキシ経由で更新」にチェックを入れて再試行する方法もあります。