ログを調べるときは、まず実行中のコアを確認し、アクセス記録と診断情報を区別しましょう。v2rayNでWebページが開かない、v2rayNGで接続がタイムアウトする、v2flyNGで名前解決に失敗するといった場合に役立つ内容です。再現できるリクエストを起点に、ローカルのインバウンド、ルーティングとアウトバウンド、DNS、TCP、TLSの順に切り分ければ、errorが1行出ただけでサブスクリプション全体を何度も入れ替える必要はありません。
1. accessログとerrorログに記録される内容
v2rayNはクライアントの画面で、接続処理を担うコアはV2RayまたはXrayです。ログの形式は、実際に起動しているコアとバージョンによって異なります。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。調査を始める前に、起動時の出力からコア名とバージョンを記録しましょう。クライアント名だけでは不十分です。
| ログの種類 | 主な内容 | ログだけでは判断できないこと |
|---|---|---|
| access | 接続元や接続先のアドレス、一部の形式ではインバウンドとアウトバウンドのタグ。 | acceptedが記録されても、接続先のWebページが正常に返されたとは限りません。 |
| error | コアの起動、接続、名前解決、データ転送に関する診断情報。 | ファイル名がerrorでも、すべての行がエラーレベルとは限りません。 |
| クライアントの実行ログ | コアの標準出力、クライアントのイベント、サブスクリプション取得情報などがまとめて記録される場合があります。 | サブスクリプションの更新失敗が、プロキシ経由の接続失敗とは限りません。 |
たとえばアクセスログにaccepted tcp:example.com:443とあれば、通常はローカルのインバウンドがリクエストを受け付けたことを示します。その後、ノードへの接続タイムアウト、TLS検証エラー、接続先による切断が発生する可能性はあります。ログに[インバウンドタグ -> アウトバウンドタグ]と表示される場合、ルーティングの振り分けを確認できます。タグ名は現在の設定によって異なります。
2. loglevelの選び方：通常はwarning、再現時のみ一時的にdebug
V2RayとXrayで一般的なログレベルはdebug、info、warning、error、noneです。debugからerrorへ進むほど出力範囲が絞られ、noneでは該当する診断ログが出力されません。アクセスログは個別に出力設定するため、loglevelだけではaccessログの有効・無効は判断できません。
- debug：詳細な処理内容を記録します。短時間の再現調査に適していますが、コアやバージョンによって出力項目は異なります。
- info：接続やルーティングの動きを確認するのに適しており、debugよりログが少ない傾向があります。
- warning：日常的な設定の目安です。警告以上の重要な情報が記録されます。
- error：エラーに絞って確認できますが、原因を特定するための前後関係が記録されない場合があります。
- none：トラブル調査時には避けましょう。「ログがない」状態を「リクエストがない」と誤認するおそれがあります。
v2rayNでは「設定」→「パラメーター設定」から、使用中のバージョンにあるログレベルの項目を探します。保存後、コアを再起動してください。画面の分類名はバージョンによって異なるため、実際の表示を確認しましょう。v2rayNGやv2flyNGも同様に、設定内のログ項目を探してからログ表示画面を開きます。サブスクリプション一覧はコアの実行ログではありません。
以下はコア設定のlogフィールドの例であり、そのまま起動できる完全な設定ではありません。フィールドの関係を示すための例です。クライアントが管理する設定は、画面から変更することを優先してください。生成ファイルを手動で編集すると、次回の起動時に上書きされることがあります。
{
"log": {
"access": "C:/Temp/v2ray-logs/access.log",
"error": "C:/Temp/v2ray-logs/error.log",
"loglevel": "debug"
}
}Windowsの絶対パスを使った例です。まずC:\Temp\v2ray-logsを作成し、コアを起動するアカウントに書き込み権限があることを確認してください。ファイル出力を有効にすると、一部のログが従来のコンソール画面に表示されなくなる場合があります。出力先のファイルも確認しましょう。再現テストが終わったらwarningに戻し、ログが増え続けないようにしてください。
3. 接続タイムアウト・接続拒否：まず失敗したアドレスを確認
以下はよくあるログのエラー部分を抜粋したもので、固定のログ全体を示すものではありません。モジュールの接頭辞やパッケージのパス、エラーの入れ子の数はコアのバージョンによって変わります。最も内側の原因を見つけてから、それがノードサーバー、DNSサーバー、接続先サイトのどれに関係するかを確認しましょう。
エラー：dial tcp …: i/o timeout
原因：ログに示されたアドレスへのTCP接続が、制限時間内に完了しませんでした。
対処：まず失敗したアドレスがノードの接続先か確認します。ノードのポート、現在のネットワーク、サーバー側のインバウンド設定を調べましょう。接続先サイトのアドレスであれば、リモート側から接続先までの通信を確認します。
エラー：connect: connection refused
原因：接続が明示的に拒否されました。接続先のポートでサービスが待ち受けていない場合や、ネットワーク機器が接続を拒否した場合によく発生します。
対処：エラーに記録されたIPアドレスとポートを確認します。127.0.0.1:10808の場合は、リモートノードを変更する前に、ローカルのコアが起動しており、待ち受けポートが一致しているか確認してください。
エラー：context deadline exceeded
原因：何らかの処理が期限内に完了しませんでした。このメッセージだけでは、DNS・接続処理・ハンドシェイクのどの段階か判断できません。
対処：前後の関連ログを残し、同じ接続に関するモジュール名と、より内側にあるエラーを探して、失敗した段階を特定します。
Windowsでは接続拒否が、上記の英語メッセージではなくconnectexを含むシステムエラーとして表示される場合があります。対処の考え方は同じです。タイムアウトは応答を待っても完了しなかったこと、接続拒否は拒否応答を受け取ったことを示します。どちらもVMessやVLESSの設定に問題があると直ちに判断できるものではありません。
判断のポイント：「タイムアウト」の文字より、エラーに記録されたアドレスが重要
エラーのアドレスを、ローカルの待ち受け、ノードの接続先、接続先サービスに分類して、その区間だけを確認します。ノードが別のポートを使う場合はサブスクリプションの設定を優先し、一律に443へ変更しないでください。
4. TLSハンドシェイク失敗：証明書・ドメイン名・システム時刻を個別に確認
TLSハンドシェイクは基礎となる接続が確立した後に行われますが、失敗の原因は証明書だけではありません。TCP接続が成功したからといって、ノードが完全に使えるとは限らず、SNIや通信経路、サーバー側の設定との不一致も考えられます。VLESSのノードが必ず同じセキュリティ方式を使うわけではありません。実際の設定がTLS、REALITY、その他の組み合わせのどれなのか、先に確認してください。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間と現在のシステム時刻が一致していません。端末の時刻が誤っている場合も、サーバーの証明書が期限切れの場合もあります。
対処：まずシステムの日付、タイムゾーン、自動時刻合わせを確認します。時刻が正しければ、サービス提供元に証明書の更新と証明書チェーンの確認を依頼してください。
エラー：x509: certificate signed by unknown authority
原因：現在の環境で信頼できる証明書チェーンを構築できません。中間証明書の不足、端末の信頼ストア、ネットワーク上での証明書の差し替えなどが考えられます。
対処：サーバーの証明書チェーンと端末の信頼環境を確認してください。証明書検証を無効にする方法を、通常の解決策として使わないでください。
エラー：tls: handshake failure
原因：TLSのネゴシエーションが拒否されました。このログだけでは、具体的にどの設定が原因か特定できません。
対処：サービス提供元の設定に合わせて、サーバー名、TLS設定、通信方式を確認します。同じ時刻のサーバーログも照合してください。
- サーバーアドレスとserverName：アドレスは接続先を指定し、サーバー名はTLSなどで使われます。異なる値の場合もありますが、自由に入れ替えてよいわけではありません。
- WebSocketなどの通信方式：Hostとパスを確認します。HTTP 404や403などの応答は、リバースプロキシや誤ったパスから返される場合があり、証明書エラーとは限りません。
- REALITYの設定：実際の設定に従って公開鍵、shortId、サーバー名を確認してください。通常の証明書更新と同じ方法で対処しないでください。
- EOF：ストリームの終端に達したことを示します。それだけで認証失敗とは判断できません。ハンドシェイクの前・途中・正常なデータ転送の終了時のどこで発生したかを確認してください。
5. DNS名前解決エラー：ノードのドメイン名と接続先のドメイン名を区別
「DNSの問題」だけでは原因を絞り込めません。クライアントはまずノードサーバーのドメイン名を解決する必要があります。プロキシ接続の確立後には、接続先サイトのドメイン名がローカルまたはリモートで解決される場合があります。また、ルーティングのdomainStrategyはIPルールとの照合のために名前解決を行うことがあります。これはアウトバウンド側の名前解決方式とは別の設定です。
| ログの例 | このログだけで分かること | 次に確認すること |
|---|---|---|
lookup …: no such host | この名前解決で利用可能な結果が得られませんでした。ドメインが存在しないか、否定応答が返された可能性があります。 | エラーに記録されたドメイン名の綴りを確認し、それがノードかWebサイトかを特定して、実際に使用しているDNSリゾルバーを調べます。 |
failed to lookup ip | 上位の処理からIPアドレスの検索失敗が報告されています。具体的な原因は、後続または内側の情報に記録されていることが多いです。 | タイムアウト、空の応答、リゾルバーへの接続エラーを続けて探します。この概要メッセージだけで判断しないでください。 |
read udp …: i/o timeout | 該当するアドレスがDNSサーバーなら、DNSの応答が時間内に返っていない可能性があります。 | リゾルバーまでの通信経路、UDPの到達性、関連するルーティング設定を確認します。 |
Windowsでは、次のコマンドでシステムの名前解決結果を確認できます。example.comはコマンドの例です。実際の調査ではログにあるドメイン名に置き換えてください。システムコマンドが成功しても、コア内蔵のDNS、暗号化DNS、プロキシ経由の名前解決が正常とは限りません。
Resolve-DnsName example.com6. 1回のリクエストでログを追う：ローカル待ち受け → ルーティング → リモート
再現テストの前に、バックグラウンド接続を大量に発生させるアプリを一時的に終了し、ノードとプロキシ接続方式を1つずつに固定します。以下はWindowsで、HTTPまたは混合インバウンドの127.0.0.1:10808を使う例です。現在のポートがSOCKS専用の場合は、対応するSOCKS用のテストコマンドを使ってください。プロトコルの不一致をノードの障害と誤認しないようにしましょう。
- 待ち受けを確認：PowerShellでローカルポートを確認します。待ち受けがなければ、まずコアの起動またはポート設定を解決してください。リモート側の証明書はまだ調べる必要はありません。
- 詳細ログを一時的に有効化：開始時刻を記録し、テストリクエストを1回だけ送信して、その時間帯のaccessログとerrorログを確認します。
- インバウンドを確認：アクセス記録がない場合は、accessログが有効か、正しい場所を確認しているかを調べます。アプリが実際にプロキシを使っているかも確認してください。
- ルーティングを確認：ログにアウトバウンドタグがある場合、リクエストが想定したプロキシのアウトバウンドに流れているか確認します。直接接続、ブロック、プロキシ経由は分けて判断してください。
- 最も内側のエラーを追う：DNS、TCP、TLS、プロトコル認証、接続先サービスの順に原因を特定します。関連する設定を一度に1つだけ変更し、同じリクエストを再実行してください。
Get-NetTCPConnection -LocalPort 10808 -State Listen
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/このcurlコマンドはプロキシを明示的に指定するため、ブラウザーやシステムのプロキシ設定に依存しません。10秒は接続処理のタイムアウト上限、20秒はコマンド全体の制限時間です。どちらも今回のテスト用の値であり、コアの性能指標ではありません。HTTPプロキシでトンネルの確立に成功しても、その後のTLS接続やWebページの応答が成功したとは限らないため、結果全体を確認してください。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/2つ目のコマンドは、SOCKSに対応するインバウンドでのみ使用します。socks5hでは接続先のドメイン名をSOCKSプロキシ側で解決します。通常のsocks5では、curlがローカルで接続先のドメイン名を解決します。両者を比較するときは名前解決の場所が変わる点を考慮し、結果の差をすべてノードの速度のせいにしないでください。
判断のポイント：明示的なプロキシ接続は成功し、ブラウザーでは失敗するなら、まず通信の入口を確認
同じノードと接続先で、明示的に指定したプロキシ経由のリクエストが成功する一方、ブラウザーに対応するaccessログがない場合は、システムプロキシ、ブラウザー拡張機能、プロキシ除外リストを優先して確認します。この状況でVMessやVLESSの設定を繰り返し変更しても、原因から外れてしまう可能性があります。
7. ログ調査でよくある質問と問い合わせ時の情報
warningが何度も出るのに、Webページは開けるのはなぜですか？
まず時刻と接続先を手がかりに、warningがどのリクエストに関するものか確認します。バックグラウンドアプリ、キャンセルされた接続、到達できない付随リソースなどでもログが出ることがあります。警告が1件あるだけで、すべての通信が失敗しているとは限りません。接続先を固定して再現し、該当するリクエストが本当に失敗したかを確認してください。
debugを有効にしてもログ画面が空白のままです。どうすればよいですか？
設定を保存した後にコアを再起動したか確認し、ファイル出力が設定されているかも調べます。ファイルにログを書き込む場合は、絶対パスとディレクトリのアクセス権を確認してください。また、サブスクリプション更新の履歴ではなく、コアの出力を表示していることを確かめましょう。
acceptedが出ていれば、ノードに接続できたということですか？
いいえ。通常はリクエストがインバウンドで受け付けられたことを示すだけです。同じ接続のアウトバウンド接続処理とハンドシェイクのログを追い、curlの最終応答で接続先へのアクセスを確認してください。acceptedの1行だけを切り取って結論を出すことはできません。
サブスクリプションの更新がタイムアウトした場合も、ノードの接続タイムアウトとして扱うべきですか？
まず、サブスクリプションURLへのリクエストと、プロキシのデータ通信を区別します。サブスクリプション更新がプロキシ経由か、現在のプロキシが使えるか、サブスクリプションのサービス自体に到達できるかを確認してください。問い合わせ時は、サブスクリプションURLに含まれるトークンを隠し、URL全体を公開しないでください。
さらに相談する場合は、画面全体のスクリーンショットより、同じ失敗を追える最小限の情報を共有すると効果的です。ログにはアクセス先のドメイン名、サーバーアドレス、ローカルパスが含まれる場合があります。共有前に内容を確認し、エラーの種類と関連性を残したうえで、アカウント識別情報、UUID、パスワード、秘密鍵、サブスクリプションのトークンを削除してください。
- 環境：OS、クライアントのバージョン、実際に使っているコア名とバージョン。バージョン情報は端末の画面または起動時の出力で確認します。
- 接続方式：システムプロキシ、明示的なHTTP/SOCKSプロキシ、TUNのいずれか。実際のローカル待ち受けポートも記載してください。
- 再現条件：接続先の種類、発生時刻、すべてのノードで失敗するか、ネットワークを変えても再現するか。
- ログの抜粋：同じリクエストの前後のログ、エラーの連鎖、アウトバウンドタグを残します。機密性のあるアドレスは、同じ文字列に置き換えてください。
- 試した操作：変更した設定とその結果を1つずつ記録し、調査が終わったら通常のログレベルに戻します。