設定をインポート済みなのに接続できない、または接続が不安定な場合に役立つ内容です。まずログがクライアントとコアのどちらから出ているかを確認し、ローカル待ち受け、名前解決、リモート接続、TLS、プロトコル設定の順に調べます。エラー別の見方やWindowsの確認コマンド、再現手順を紹介し、赤いエラー表示を見て設定をすべて変更するのではなく、どの段階で失敗したかを特定します。
クライアントログ・アクセスログ・エラーログを区別する
v2rayNは、設定の管理やコアの起動、システムプロキシの操作などを担うデスクトップクライアントです。実際に接続を処理するのは、選択したコアです。Androidでは、v2rayNGは主にXrayコアを、v2flyNGはV2Flyコアを使用します。クライアント画面のエラーと、コアが出力する接続エラーは別の問題です。サブスクリプションの取得に失敗しても、現在のプロキシ接続が必ず使えないとは限りません。また、コアが起動していない場合、ブラウザーのDNS設定を変えても解決しません。
調査を始める前に、クライアントのバージョン、実際に使っているコアの名前とバージョンを記録してください。コアによってエラーの書式や設定の対応範囲はバージョンごとに異なるため、別のコア向けの設定をそのまま貼り付けないでください。以下ではログの意味を説明します。例にあるアドレス、ポート、ログの一部は解説用であり、特定バージョンの出力全体を示すものではありません。
| ログの種類 | 主な記録内容 | 優先して確認する項目 |
|---|---|---|
| クライアントログ | サブスクリプションの更新、プロセスの起動、設定の生成 | 実行環境、ファイル権限、サブスクリプションへのリクエスト |
| コアのアクセスログ | 受信した宛先リクエスト、インバウンド、アウトバウンドの情報 | アプリのリクエストがコアに届いているか、ルーティングの選択 |
| コアのエラーログ | 名前解決、ダイヤル、ハンドシェイク、設定のエラー | 根本原因と対象アドレス |
アクセスログのacceptedは、通常、ローカルのインバウンドがリクエストを受け付けたことを示します。リモートへの接続が完了した、あるいはWebページから完全な応答を受信したことを意味するわけではありません。反対に、アクセスログが見当たらなくても、ログ自体が無効になっている可能性があります。すぐにアプリがプロキシを経由していないと判断しないでください。
ログレベルの選び方：まずwarning、必要なときだけdebug
Xray・V2Flyの一般的なエラーログレベルはdebug、info、warning、error、noneです。warningでは通常、警告とエラーが記録されます。debugにすると詳細なデバッグ情報が増え、noneではエラーログの出力が停止します。アクセスログは別に設定するため、エラーログのレベルと混同しないでください。
-
コアを確認する
v2rayNの起動情報でコア名、バージョン、起動結果を記録し、想定したコアが動作していることを確認します。ノードがVMessかVLESSかだけを見ても、使用中のコアは判断できません。
-
ログレベルを変更する
v2rayNでは通常、「設定」→「パラメータ設定」→「Core: 基本設定」→「ログレベル」から変更できます。バージョンによって項目の分類や名称が異なる場合があるため、実際の画面に従ってください。一時的にdebugを選び、保存してからコアを再起動します。
-
一度だけ再現する
システム時刻を記録し、確認したいアドレスだけを開きます。その時刻の前後約10秒分のログを連続して取得してください。速度テストやサブスクリプション更新、複数のWebページへのアクセスを同時に行わないでください。
-
設定を元に戻す
再現確認が終わったらwarningに戻し、必要に応じてアクセスログを無効にします。共有する前に、サブスクリプションURL、ユーザー識別情報、認証情報、個人用ドメインを伏せ、エラーの種類と必要なポート情報だけを残してください。
コアの設定をカスタマイズする場合、ログ部分は次のように記述できます。これはトップレベルのlog設定の一部であり、単独で動作する完全な設定ではありません。クライアントが生成した設定は次回起動時に上書きされる場合があるため、まずクライアント画面から変更してください。
{
"log": {
"loglevel": "debug"
}
}接続の流れに沿ってログを読む：対象を確認し、根本原因を探す
これは原因を調べる順序の目安であり、すべてのリクエストが必ずこの時間順に進むわけではありません。ルーティングの判定前にDNS問い合わせが行われる場合や、ダイレクト接続がプロキシサーバーを経由しない場合もあります。ログを読む際は、リクエストの宛先、選択されたアウトバウンド、実際に接続を試みたアドレスを確認してください。「接続先サイトにアクセスできない」ことを「プロキシサーバーのポートに接続できない」と取り違えないようにしましょう。
以下は簡略化したエラーの流れです。外側のメッセージはプロキシリクエストの処理が完了しなかったことを示し、内側のdial tcpがTCP接続の失敗を示しています。203.0.113.10は説明用のアドレス、443は例として示したリモートポートです。実際のノード設定に転用しないでください。
proxy: failed to process outbound traffic
transport/internet: failed to open connection
dial tcp 203.0.113.10:443: i/o timeout- まず時刻を確認：今回の再現時間帯だけを調べ、ノード切り替え前に発生したエラーを現在の問題と混同しないようにします。
- 次にリクエストを確認：ログに接続IDがある場合は、同じIDの行をたどって関連情報を確認します。並行して発生したリクエストでは、隣り合う行が同じ接続とは限りません。
- 最後に原因を読む：エラーを階層ごとにたどり、名前解決、接続拒否、タイムアウト、証明書検証など、具体的な失敗原因を特定します。
判断の基本：プロトコルを変更する前に、失敗した段階を確認する
最も深い原因がリモートTCP接続のタイムアウトなら、まずアドレスとポートを確認してください。TCP接続が確立していない段階では、VMessのユーザーIDやVLESSのパラメーターを変更しても、通常は解決しません。
よくあるエラーの意味：接続拒否、タイムアウト、名前解決失敗、ポート競合
同じエラーワードでも、発生した段階によって意味が異なります。特にconnection refusedは、ローカルの127.0.0.1:10808への接続が拒否された場合と、リモートサーバーの443への接続が拒否された場合で、対処方法がまったく異なります。以下に代表的なログを挙げます。前置き部分やシステムのエラー表記は環境によって異なる場合があります。
エラー：connection refused
原因：接続先から明示的に拒否されています。対象ポートでサービスが待ち受けていない場合や、ファイアウォールが接続を拒否している場合によく発生します。
対処：ログに記録された接続先のIPアドレスとポートを確認します。ローカルアドレスならコアが起動しているかを確認し、リモートアドレスならノードのポートとサーバー側の待ち受け状態を確認してください。
エラー：i/o timeout
原因：ネットワークの読み書きが制限時間を超えています。TCP接続、ハンドシェイク、その後のデータ転送のいずれで発生する可能性もあり、この表示だけでノードが使えないとは判断できません。
対処：直前の処理名と接続先アドレスを確認します。dialの段階で発生した場合は通信経路とポートを、接続確立後に発生した場合はハンドシェイクの設定とリモート側の応答を調べてください。
エラー：no such host
原因：現在の名前解決経路で、そのドメイン名を解決できていません。スペルミス、DNSレコードの欠落、リゾルバーの動作などが原因として考えられます。
対処：まずノードのドメイン名に誤りがないか確認し、システムの名前解決ツールで結果を調べます。コアが独自のDNSを使う場合は、コア側DNSへの接続性とルールも確認してください。
エラー：address already in use
原因：ローカルの待ち受けアドレスとポートが別のプロセスに使われているか、同じプログラムが重複して起動しています。
対処：ポートを使用しているプロセスを特定し、重複したプロセスを終了します。インバウンドのポートを変更する場合は、アプリのプロキシ設定も合わせて変更してください。コア側だけを変更しても接続できません。
エラー：failed to find an available destination
原因：コアが接続可能な宛先を見つけられていません。包括的なエラーであり、名前解決の失敗、アドレスへの到達不能、複数回の接続失敗などを伴う場合があります。
対処：続く入れ子のエラーを確認し、具体的な名前解決や接続の原因を調べます。この1行だけを根拠にDNS障害と決めつけないでください。
TLSハンドシェイクの失敗：証明書名、システム時刻、通信設定を確認
TLSエラーは通常、接続がセキュアハンドシェイクの段階に進んだことを示しますが、正しいサービスに接続できたとは限りません。誤ったポート、転送設定の不一致、中継機器の干渉などにより、クライアントが想定外のデータを受信することがあります。別のセキュリティ方式を使う設定の場合、一般的なTLS証明書エラーの対処法をそのまま適用することはできません。
| エラーの例 | 意味 | 確認すること |
|---|---|---|
x509: certificate has expired or is not yet valid | 証明書の有効期間と端末の時刻が一致しない | システムの日付、時刻、タイムゾーンを合わせてから、サーバー証明書の有効期間を確認する |
x509: certificate is valid for | 証明書の対象名が想定している名前と一致しない | serverName/SNIと証明書のドメイン名を確認する |
tls: first record does not look like a TLS handshake | 受信データが想定したTLSレコードではない | 接続先ポートがTLSを提供しているか確認し、リバースプロキシの入口を調べる |
EOFまたはconnection reset by peer | 通信の終了または接続のリセット。原因は一つとは限らない | 発生した段階を踏まえ、通信方式、パス、Host、サーバーログを確認する |
サーバーアドレスとserverNameは必ずしも同じではありません。前者は接続先を決め、後者はTLSの名前検証とSNIに使われます。WebSocketではパスとHTTP Hostもそれぞれ役割があります。正しいIPアドレスに接続できても、これらの値が一致しているとは限りません。VMess・VLESSの認証情報もサーバー側と一致させる必要があります。EOFが1回出ただけで、どの項目が間違っているかを特定することはできません。
Windowsでの確認例：ローカルの10808とリモートの443を分けてテスト
ここでは、クライアント設定のローカルHTTPまたは混合インバウンドポートを10808、リモートサーバーのポートを443と仮定します。手順を説明するための例であり、初期設定が同じとは限りません。実行前にポートとドメイン名を実際の設定に置き換えてください。example.netは説明用のドメイン名で、接続可能なノードではありません。
# PowerShell：ローカルポートが待ち受け中か確認
Get-NetTCPConnection -LocalPort 10808 -State Listen
# システムのDNS名前解決結果を確認
Resolve-DnsName example.net
# 指定したリモートTCPポートを確認
Test-NetConnection -ComputerName example.net -Port 443
# HTTPプロキシを提供するローカルインバウンドでのみ使用
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 https://example.com/- ローカルで待ち受けていない：まずコアの起動ログ、設定の解析エラー、ポート競合を確認します。この状態でブラウザーのプロキシ設定を何度切り替えても意味はありません。
- リモートTCPテストに失敗：今回のテストではTCP接続を確立できていません。アドレス、ネットワーク、ファイアウォール、サーバーの待ち受け状態を切り分けてください。このコマンドではUDPをテストできません。
- リモートTCPテストに成功：そのポートでTCP接続を確立できたことだけを示します。TLS、VMess/VLESSの認証、通信設定が正しいことを保証するものではありません。
- コマンドは成功するのにブラウザーでは失敗：ブラウザーが同じプロキシの接続先を使っているか確認し、システムプロキシ、拡張機能、アプリ固有のプロキシ設定を調べてください。
ローカルポートがSOCKSインバウンドのみを提供する場合は、curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/を使います。socks5hでは接続先のドメイン名をプロキシ側で解決するため、ローカルの名前解決経路との比較に役立ちます。ただし、すべてのDNSリクエストが自動的に同じ方法で処理されるわけではありません。コマンドのテスト時刻もログと照合し、バックグラウンドで動作する別のプログラムの接続をテスト結果と取り違えないようにしてください。
結論：一度に変更する項目は一つだけ
ノード、接続先アドレス、プロキシの接続先を固定してから、項目を一つずつ確認してください。同じリクエストを再現しながら一度に一つの設定だけ変更すれば、改善がポート、DNS、ハンドシェイク設定のどれによるものかを判断できます。ネットワーク経路を偶然切り替えた影響と混同せずに済みます。
ログ調査のよくある質問と問い合わせ時の情報
warningがログに次々と出ます。すべての接続が失敗しているのでしょうか？
必ずしもそうではありません。バックグラウンドアプリの再試行や、接続確認リクエストのキャンセルでも警告が残ることがあります。まず一括速度テストを止め、接続先を一つだけ開いて時刻を記録します。その後、宛先アドレスや接続IDを使って同じリクエストの前後のログを確認してください。
システムプロキシを有効にしたのに、ログにブラウザーのリクエストがありません。
まずアクセスログが有効か確認し、システムプロキシの接続先ポートがクライアントのインバウンドと一致しているか調べます。プロキシを明示したcurlコマンドで比較してください。システムプロキシを参照しないアプリもあるため、設定スイッチだけで適用範囲を判断することはできません。
サブスクリプションの更新はタイムアウトするのに、選択中のノードではWebページを閲覧できます。
サブスクリプションの取得は、独立したHTTPリクエストとして調べてください。更新時に直接接続とプロキシ接続のどちらを使うか、サブスクリプションの配信元に接続できるかを確認し、URLが有効かも調べます。更新エラーの調査を始める前に、まだ使えるノード設定を削除しないでください。
Androidで接続後にタイムアウトします。Windowsのようなポート情報がないのはなぜですか？
v2rayNG・v2flyNGのVPN経由の通信経路は、デスクトップのシステムプロキシとは異なります。まずアプリ内のログを確認し、コアのバージョン、ネットワークの種類、失敗した時刻を記録してください。ノードのドメイン名、ポート、安全性の設定を確認し、デスクトップのローカルインバウンドポートをそのまま当てはめないでください。
問い合わせ用の情報をまとめるときは、エラー1行を切り取るより、前後のログを連続して残すほうが役立ちます。以下の項目を記録し、まず個人情報を伏せたコピーを手元に保存してから、必要な範囲だけ共有してください。サブスクリプションURLにはアクセストークンが含まれていることが多く、パスワードの文字がなくても公開してはいけません。
- OSの種類、クライアントのバージョン、実際に使用しているコアの名前とバージョン。
- 問題が発生した正確な時刻と、そのときシステムプロキシとTUNのどちらを使っていたか。
- 再現手順、接続先の種類、毎回発生するか、ネットワークを切り替えた後の状態。
- 個人情報を伏せたエラー全体、ローカルとリモートのポート、前述のコマンドが成功したか失敗したか。
- 設定の更新、コアの変更、DNS設定の変更、ネットワークの切り替えなど、直近に行った変更。
最終的な目標は、ログをすべて空にすることではなく、同じリクエストの各段階で結果を検証できるようにすることです。DNS、インバウンド、ルーティングの設定をさらに確認する場合は設定ガイドをご覧ください。起動や実行環境の問題が残っている場合は、まずトラブルシューティングで基本項目を確認してから、ネットワーク接続を調べてください。