この記事は、サブスクリプションをインポート済みなのに、ノードがタイムアウトする、Webページが開かない、接続が不安定といった問題に悩む方を対象にしています。まずクライアントログとコアログを区別し、リクエスト時刻、宛先、アウトバウンドタグ、最終エラーを順に追うことで、原因がシステムプロキシ、ローカルポート、DNS、ノード設定、リモートサーバーのどこに近いか判断できます。
まずクライアントログとaccess・errorを区別する
調査を始める前に、確認しているログがどの層のものかを確かめます。v2rayNとv2rayNGは、サブスクリプション、ノード、システムプロキシ、コアプロセスを管理するクライアントです。Xrayまたはv2flyコアは、実際に接続を受け付け、ルーティングを実行し、アウトバウンド接続を確立します。クライアント画面に「起動成功」と表示されても、コアプロセスが起動したことを示すだけで、特定のノードへの接続まで保証するものではありません。
accessには、リクエストがどのインバウンドを通り、何にアクセスし、最終的にどのアウトバウンドが選ばれたかが記録されます。「リクエストがコアに届いたか」「ドメインがどのルールで処理されたか」を確認するのに適しています。accessの記録があれば、通常はブラウザやアプリがローカルプロキシポートへ通信を送れていることを意味します。
errorは障害の原因に近いログで、ドメイン解決失敗、接続タイムアウト、ポート競合、プロトコルハンドシェイク失敗、リモート側による切断などが記録されます。ログレベルには通常、debug、info、warning、errorがあります。普段はinfoで十分です。原因不明の問題を再現するときだけ一時的にdebugへ切り替えてください。debugでは短時間に大量のログが生成されるためです。
| ログの種類 | 主な内容 | 優先して確認する項目 |
|---|---|---|
| クライアントログ | 設定生成、コア起動、サブスクリプション更新、システムプロキシの切り替え | コアファイル、設定形式、プロセスの状態、サブスクリプションURL |
| accessログ | リクエスト先、インバウンドタグ、ルーティング結果、アウトバウンドタグ | アプリがプロキシに接続したか、振り分けルールが想定どおりか |
| errorログ | 接続、名前解決、ハンドシェイク、転送、リスニングの失敗 | ローカルポート、DNS、ノード設定、ネットワーク、リモート側の状態 |
v2rayNとv2rayNGで有効なログを取得する
ログは、明確な1回の操作と対応付けて初めて役立ちます。始める前に、連続速度テスト、自動サブスクリプション更新、バックグラウンドダウンロードを停止し、複数のリクエストが混ざらないようにします。次に1つのノードを選び、ログ画面を開いて問題を1回だけ再現します。たとえば、確実に利用できるHTTPSページを1つだけ開くか、実際の接続テストを1回だけ実行します。
v2rayN 7.xを例にすると、まずメイン画面で現在のアクティブサーバーを確認し、「設定」→「パラメータ設定」→「Core タイプ」の順に開いて、選択中のコアが現在の設定と一致しているか確認します。その後メイン画面に戻り、ログ欄で起動メッセージを確認します。記録の詳細度を上げる場合は、パラメータ設定でログレベルを探し、infoを一時的にdebugへ変更して保存した後、コアを再起動します。
-
アクティブノードを確認する
v2rayNのメイン一覧で現在のアクティブサーバーを確認し、アドレス、ポート、プロトコルを記録します。リモート側のポートには443、8443、サービス提供元が指定するその他のポートなどがあります。ローカルの待受ポートで代用することはできません。
-
コアを再起動する
設定を保存したら、「サービスを再起動」を1回実行します。まずログに設定の読み込みとローカルリスニングの成功が表示されたことを確認してからWebページを開き、旧プロセスの記録を今回の結果と混同しないようにします。
-
1回だけ再現する
Webページを1つ開くか接続テストを1回実行し、10〜15秒待ってから操作を止めます。同時に20個のノードをテストすると、複数のtimeoutが発生し、どの記録が現在のノードに対応するのか分かりにくくなります。
-
前後のログをまとめて保存する
最初の宛先リクエストから、その後の10〜20行までをまとめて保存します。最後の1行だけを切り取らないでください。最後に出るcontext canceledは、直前の接続失敗後に実行された後処理であることが多いためです。
v2rayNGでは、サイドメニューから「ログ」を開いて実行記録を確認できます。v2rayNGでXrayコアを使用している場合、ログにはAndroid側の起動情報とコアの出力が同時に含まれます。調査では、現在のノード名、宛先ドメイン、アウトバウンドタグ、失敗した時刻を重点的に確認します。最初の行から1行ずつ読む必要はありません。
ローカルのSOCKSポートには10808、HTTPポートには10809が使われることが多いものの、実際の値はクライアントの現在の設定を確認してください。別のアプリに127.0.0.1:10809を手動入力した一方、クライアント側が10811に変更されている場合、そのアプリのリクエストは現在のコアに届きません。このとき、errorログに該当する記録がないこともあります。
2026/07/15 14:32:10 [Info] transport/internet/tcp: listening TCP on 127.0.0.1:10808
2026/07/15 14:32:12 from 127.0.0.1:53142 accepted tcp:example.com:443 [socks -> proxy]
2026/07/15 14:32:22 [Warning] app/proxyman/outbound: failed to process outbound traffic
2026/07/15 14:32:22 [Warning] common/retry: all retry attempts failedこの一連の記録から、ローカルの10808がリスニングを開始し、53142の一時ポートからのリクエストがSOCKSインバウンドに入り、proxyという名前のアウトバウンドへ送られたことが分かります。問題はアウトバウンド接続の確立後に発生しているため、調査の重点はノードアドレス、リモートポート、ネットワーク到達性、プロトコル設定に置くべきです。ブラウザのプロキシ設定を切り替え続ける必要はありません。
1つのリクエストの経路に沿ってログを読む
1つのプロキシリクエストは通常、アプリ、ローカルインバウンド、ルーティング判定、プロキシアウトバウンド、リモートの宛先という段階を通ります。複数の接続が並行して処理されるため、ログの順序が1行ずつ厳密に対応するとは限りません。それでも同じ時間帯に現れる宛先ドメイン、接続識別子、アウトバウンドタグから経路を復元できます。
最初にacceptedがあるか確認します。Webページを更新しても新しいaccess記録がまったく出ない場合、システムプロキシが有効になっていない、アプリがシステムプロキシを利用しない、またはアプリに誤ったポートが入力されている可能性があります。v2rayNでは「コアを起動」と「システムプロキシを設定」も区別してください。前者はローカルポートで待ち受けを開始するだけで、後者によって初めてシステムプロキシ対応アプリの通信がそのポートへ向けられます。
次に宛先が正しいか確認します。ログにはtcp:example.com:443のように表示される場合もあれば、解決後のIPが表示される場合もあります。ポート443は通常HTTPS、80は通常HTTPに対応します。Webページを開いたとき、ログにLAN内のアドレスや無関係なドメインしか出ない場合は、他のバックグラウンドアプリを終了してから、もう一度単独で再現してください。
3番目に、角括弧内のルーティング結果を確認します。たとえば[socks -> proxy]は、リクエストがsocksインバウンドから入り、proxyアウトバウンドへ渡されたことを示します。[socks -> direct]は、ルールによって直接接続されたことを示します。本来プロキシを通すべき宛先がdirectへ入る場合は、VMessやVLESSのノード設定を変更するのではなく、現在のルーティングモード、ドメインルール、ルールの順序を確認します。
- access記録がない：システムプロキシの状態、ローカルの待受アドレス、アプリが使用するポートを確認します。
- directに入った後で失敗：ルーティングの振り分けで宛先が誤って直接接続になっていないか確認します。
- proxyに入った後でtimeout：ノードアドレス、リモートポート、ローカルネットワーク、サーバーの状態を確認します。
- ハンドシェイクエラーがすぐに発生：サブスクリプションのプロトコル、セキュリティ方式、伝送方式、Host、パス、SNIを照合します。
- 接続後に頻繁に切断：特定のネットワーク、特定のノード、大容量通信でのみ発生するか確認します。
頻出エラーの意味と対処の順番
errorログには複数の層でラップされた情報が含まれることがあります。外側にはfailed to process outbound trafficとしか書かれていなくても、本当の原因は後ろに続くcaused by、dial、lookup、handshake付近にあることが多いです。最初の行だけを検索するより、末端の具体的な原因から前へ読み返すほうが効果的です。
エラー：context canceled
原因と対処：上位レイヤーによって現在のリクエストがキャンセルされています。ノードの切り替え、コアの再起動、ページの終了、直前の接続失敗後の後処理などでよく発生します。まず同じ時刻の直前5〜20行を確認してください。再起動を実行した直後で、その後の接続が正常なら、この記録だけを個別に処理する必要は通常ありません。
エラー：i/o timeout
原因と対処：決められた時間内に接続または読み書きが完了しませんでした。まず通常のネットワークが利用できることを確認し、ノードアドレスとリモートポートを照合します。その後、同じサブスクリプション内の別ノードで試します。複数のノードが同時にタイムアウトする場合は、ローカルネットワーク、システム時刻、DNSを優先して確認してください。
エラー：connection refused
原因と対処：対象ホストが該当ポートへの接続を明確に拒否しています。リモートサービスが待ち受けていない、ポートの入力が間違っている、またはローカルアプリが起動していない10808や10809へ接続している可能性があります。ログの宛先IPを確認し、拒否がローカルとリモートのどちらで発生したか判断します。
エラー：failed to find an available destination
原因と対処：コアが利用可能な宛先を取得できませんでした。ノードのドメイン解決失敗や宛先設定の異常が原因であることが多いです。サーバーアドレスに空白や余分な文字が含まれていないか確認し、利用可能なDNSへ切り替えてからコアを再起動します。その後、より具体的なlookupエラーが出るか確認してください。
エラー：rejected
原因と対処：リクエストがルーティングルール、プロトコルチェック、宛先ポリシーによって拒否されました。まず同じ行の近くにあるアウトバウンドタグと理由を確認します。blockアウトバウンドに入っている場合はルーティングルールを調整し、invalid requestや認証情報が伴う場合は、有効なサブスクリプションからノード設定を再インポートします。
エラー：EOF
原因と対処：接続相手が想定されたデータの受信完了前に接続を閉じました。1回だけならWebページがリクエストをキャンセルした可能性があります。同じノードへの接続で毎回すぐに発生する場合は、VMessまたはVLESSの伝送方式、TLS、セキュリティ設定、Host、パス、SNIを確認してください。
rejectedを常にノード障害と考えてはいけません。たとえばルーティング設定で広告ドメインをblockアウトバウンドへ送っている場合、拒否は想定された動作です。障害かどうかを判断するには、宛先ドメインとアウトバウンドタグを同時に確認します。ルールでブロックされたリクエストだけがrejectedになり、主要ページが正常に読み込まれているなら、ノードを変更する必要はありません。
context canceledも、原因ではなく結果であることがよくあります。速度テストの完了前にノードを切り替えると、古い接続がキャンセルされます。クライアントがコアを再起動すると、実行中のDNSクエリやアウトバウンド接続も終了します。手動操作をしていないのに毎回リクエストがキャンセルされる場合に限り、プロセスの再起動ループ、設定の自動更新、ネットワーク切り替えを詳しく確認します。
ログからDNS・ポート・設定・リモート状態へ絞り込む
エラーを見つけても、複数の設定を同時に変更しないでください。一度に1つの仮説だけを検証すれば、どの操作が実際に効果を発揮したか分かります。まずローカル経路を確認し、次にドメイン解決を確認し、その後複数のノードを比較して、最後にプロトコル設定を項目ごとに確認するのがおすすめです。設定をすべて削除して再インポートすると一時的に直ることがありますが、原因究明の手がかりを失うおそれがあります。
ログにlookup、no such host、または宛先アドレスを取得できない内容が出ている場合は、DNSを優先して確認します。まずノードのサーバーアドレスを誤ってコピーしていないか確認し、ドメイン指定ノードとIP指定ノードの結果を比較します。ドメイン指定ノードだけが失敗し、IP指定ノードが使える場合はDNSが有力です。すべてのノードが失敗する場合は、ローカルネットワークとコアの起動状態も確認してください。
| 観察された結果 | 可能性の高い範囲 | 次に行う確認 |
|---|---|---|
| 10808のリスニングに失敗 | ローカルポートの競合 | 古いプロセスを終了するか未使用のポートへ変更し、再起動後にlistening記録を確認する |
| 新しいaccess記録がない | システムプロキシまたはアプリのプロキシ設定 | アプリに入力した127.0.0.1と、実際のHTTP・SOCKSポートを照合する |
| 複数のドメイン指定ノードでlookupに失敗 | DNSまたは現在のネットワーク | 安定したネットワークへ切り替えて再度名前解決し、ノードのプロトコル設定は同時に変更しない |
| 1つのノードだけ継続的にtimeout | ノードのポートまたはリモートサービス | 同じサブスクリプション内の別ノードと比較し、単一ノードの問題か確認する |
| すべてのノードでハンドシェイクに即時失敗 | システム時刻または設定の不一致 | システム時刻を同期し、サブスクリプションを再更新して伝送パラメータを照合する |
| proxyは成功するが特定のドメインがdirectへ進む | ルーティングの振り分け | ドメインルール、ルールの優先順位、現在のプロキシモードを確認する |
ポートの問題では、ローカルポートとリモートポートを区別する必要があります。ローカルの10808、10809はアプリがクライアントへ接続するために使い、ノードの443、8443などはコアがサーバーへ接続するために使います。ログに127.0.0.1:10808でリスニングできないと記録されている場合は、ローカルのポート競合を解消します。サーバーアドレスの443への接続がタイムアウトしている場合は、ローカルのSOCKSポートを変更しても通常は解決しません。
プロトコル設定の問題は、TCP接続までは成功するものの、ハンドシェイクがすぐに失敗する形で現れることが多いです。VMessでは正しいユーザーID、伝送方式、セキュリティ設定が必要です。VLESSでは正しいユーザーID、トランスポート層のパラメータ、サーバーと一致するTLSなどのセキュリティ設定が必要です。WebSocketを使用する場合はパスとHost、TLSを使用する場合はSNIも確認します。最も確実なのは有効なサブスクリプションを更新することで、推測で設定を補わないでください。
誤判断しやすいログの例
ログにwarningが出たからといって、すべての接続が失敗しているとは限りません。ブラウザで1ページを開くと、画像、スクリプト、解析用アドレス、バックグラウンドAPIなどへ並行してリクエストが送られます。そのうち1つの補助的なリクエストがタイムアウトしても、メインページは正常に表示されることがあります。影響範囲を判断するときは、宛先ドメイン、失敗回数、実際のページ表示を同時に確認してください。
ログにtimeoutが出続ける場合、サブスクリプションが無効になっていますか？
まず一括速度テストを停止し、1つのノードだけ選んで1ページを開きます。そのノードが失敗したら、同じサブスクリプション内の2つ目のノードをテストします。同じネットワークで複数ノードがすべてタイムアウトした場合に限り、サブスクリプションの有効性、ローカルネットワーク、システム時刻、DNSを確認します。
context canceledが出たらノードを変更すべきですか？
発生前にノードを切り替えたか、サービスを再起動したか、テストページを閉じたか確認します。これらの操作をしていたなら、多くの場合は接続の後処理を示す記録です。手動操作をしていない場合は、ログをさかのぼって最初に現れたtimeout、EOF、プロセス終了の記録を探します。
コアは起動成功なのに、なぜWebページが開かないのですか？
Webページを更新した際にaccess記録が生成されているか確認します。記録がない場合は、システムプロキシと10808、10809など実際の待受ポートを照合します。記録がある場合は、リクエストがdirect、proxy、blockのどのアウトバウンドへ進んだかを確認します。
1つのWebサイトだけ開けない場合、どう調べますか？
現在のログを消去してから、そのWebサイトだけにアクセスし、宛先ドメインとアウトバウンドタグを記録します。directへ送られている場合は、該当するドメインルールを一時的に調整して検証します。proxyへ進んだ後に失敗する場合は、DNSの結果と宛先サイトへの接続記録を確認します。
v2rayNは使えるのに、v2rayNGがタイムアウトする場合は？
すぐにノード障害だと判断しないでください。まず両方で同じ最新のサブスクリプションと同じノードを使用していることを確認し、その後ネットワーク環境、システム時刻、Xrayコアのバージョン、伝送パラメータ、DNS設定を比較します。異なるネットワークで得た結果をそのまま置き換えて考えることはできません。
もう1つのよくある誤解は、遅延テストだけを見ることです。遅延値は1回の探測にかかった時間を示すだけで、実際のプロキシ経路を完全に検証するものではありません。あるノードが180ミリ秒と表示されても、プロトコルのハンドシェイク、TLSパラメータ、Webページの転送まで正常とは限りません。逆に、特定のテスト方式がタイムアウトしても、実際の接続が利用できないとは限りません。最終的には実際のアクセス結果と対応するログを基準にしてください。
調査が終わったら、debugのログレベルをinfoに戻し、簡潔な結論を1つ残します。たとえば「ローカル10808は正常にリスニングし、accessはproxyへ入り、2つのノードがどちらもリモート443への接続後約10秒でtimeoutになった」のように記録します。「クライアントが使えない」と書くより、次に似た問題が起きたときに比較しやすくなります。