「ノードを選んだのにWebページが開かない」「コアを起動してもすぐ終了する」といった場合に役立つ記事です。まずクライアントログとコアのログを区別し、ローカルの待ち受け、ノードへの接続、TLSハンドシェイク、接続先へのアクセスの順にエラーを確認します。キーワードの見方、Windowsでのポート確認コマンド、1回の操作で再現する手順を紹介し、設定を一度に何度も変更せず問題の箇所を絞り込みます。
まずログがどの層のものか確認する
v2rayNはクライアントの画面で、実際の接続処理は選択したコアが行います。サブスクリプションの取得失敗、画面の異常、コアの起動失敗はクライアントのメッセージに表示される場合があります。一方、ノードへの接続、DNS問い合わせ、出方向けのハンドシェイクは通常コアのログに記録されます。発生する段階が異なるため、「サブスクリプションの更新に成功した」ことは「プロキシ接続に成功した」ことを意味しません。また、速度測定の失敗だけで、すべてのアプリがインターネットに接続できないとは判断できません。
この記事では、v2rayNからXrayコアを利用するケースを中心に説明します。メイン画面のメッセージまたはログ欄で、現在使っているコアの名前を確認してください。その後、「設定」→「パラメーター設定」でログ関連の項目を確認します。デスクトップ画面やバージョンによって項目の分類名は異なることがあります。現在の画面に表示される「ログレベル」を基準にし、以下のXrayフィールドをサブスクリプションURL欄に貼り付けないでください。
ログはこの流れに沿って後ろへ追います。アプリがリクエストをローカルポートに送ったか、ルーティングで想定した出方向が選ばれたか、コアがノードに接続したか、ノードとのプロトコルハンドシェイクが完了したかを確認します。前の段階が正常だと確認できて初めて、次の段階のエラーを原因特定に役立てられます。TUNを有効にしている場合は仮想ネットワークアダプターと権限も確認してください。ただし、その後のノード接続やハンドシェイクの見方は同じです。
ログレベルと1回の再現：確認しやすいログを取得する
Xrayでよく使われるloglevelの値は、debug、info、warning、error、noneです。詳細なログでは接続の状況を把握しやすくなる一方、アクセス先の情報も記録されやすくなります。通常は控えめなレベルに設定し、トラブル対処時に一時的にinfoへ変更します。それでも情報が足りない場合に限り、短時間だけdebugを使用してください。
| レベルまたは記録 | 確認できること | これだけでは判断できないこと |
|---|---|---|
debug | 名前解決、接続、ハンドシェイクの詳細 | 情報量が多くても、障害が増えたとは限らない |
info | 接続の流れや通常の動作イベント | エラーがなくてもWebページの読み込み完了とは限らない |
warning | 注意が必要な異常接続 | 警告が1件あっても、コア全体が停止したとは限らない |
error | 重大なエラーや一部の起動時エラー | すべてのリクエスト失敗が記録されるとは限らない |
| アクセスログ | リクエスト先、受信側・送信側のタグ | acceptedは接続先とのハンドシェイク成功を保証しない |
アクセスログとエラーログは別のものです。出力されるかどうかは設定にもよります。「acceptedを確認する」ためだけに、すべてのログを安易に有効にしないでください。以下の手順で1回のリクエストを記録すると、何百行ものログをまとめて見るより原因を絞り込みやすくなります。
環境を記録する
「ヘルプ」→「バージョン情報」で確認できるクライアントのバージョンを書き留め、起動メッセージからコアのバージョンも記録します。そのメニューが表示されない場合は、ウィンドウに実際に表示されているバージョン情報を記録してください。
ログレベルを変更する
「設定」→「パラメーター設定」を開き、ログレベルを一時的にinfoにします。保存後、現在のコアを再起動し、新しい設定が反映されたことを確認してください。
条件を絞る
ノード、ブラウザー、アクセス先のページをそれぞれ1つに固定し、一括速度測定とサブスクリプション更新を一時停止します。起動エラーは残したまま、画面に表示された古いログを消去してください。確認に必要なログファイルは削除しないでください。
1回だけ再現する
リクエストした時刻を記録し、ページを1回だけ再読み込みして、その前後のエラーを一連の流れがわかる形で収集します。ログに接続IDがある場合は、同じIDを使って追跡してください。隣り合った行だけを見て関連付けないようにします。
設定を元に戻す
原因を特定したら、ログレベルを元の値に戻します。ログを共有する前に、サブスクリプションURL、認証情報、ノードのアドレス、アクセス先のドメインを伏せ、必要なエラーのキーワードとポートの役割だけを残してください。
connection refusedとポート競合：拒否元を確認する
connection refusedは、接続を確立しようとした際に拒否されたことを示します。該当ポートでサービスが待ち受けていない場合や、ネットワーク機器が接続を拒否した場合によく発生します。タイムアウトとは異なります。重要なのはキーワードだけでなく、エラーに記載された接続先アドレスです。127.0.0.1なら自分のPC、ノードのアドレスならノードへの接続、別のリモート接続先なら直接接続の出方向で問題が起きている可能性があります。
エラー：dial tcp 127.0.0.1:10808: connect: connection refused
原因：接続元がローカルの10808ポートにアクセスした際、待ち受けサービスに接続できませんでした。コアの終了、ポート番号の変更、プロキシアドレスの入力ミスなどが原因として考えられます。
対処：まずコアの起動メッセージを確認し、「設定」→「パラメーター設定」でローカルの待ち受けポートを確認します。アプリに設定されているアドレス、ポート、プロキシの種類が一致していることも確認してください。
エラー：bind: address already in use
原因：コアが待ち受けようとしているアドレスとポートを、別のプロセスがすでに使用しています。Windowsでは「通常、各ソケット アドレスは 1 回しか使用できません」と表示される場合もあります。
対処：ポートを使用しているプロセスを調べ、重複して起動しているクライアントを終了するか、ローカルポートを変更してアプリ側のプロキシ設定も更新します。正体のわからないシステムプロセスは終了しないでください。
以下の数値はポートの役割を説明する例であり、すべてのバージョンの初期値ではありません。10808はローカルの待ち受けポート、443はノードのポートの例です。実際に確認する際は、現在の設定値を使ってください。
Windows PowerShellでは、まず待ち受けポートを調べ、結果に表示されるPIDからプロセスを特定できます。最初のコマンドで待ち受けが見つからない場合は、ノードのTLS設定を変更する前に、コアが正常に起動したか確認してください。
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-NetTCPConnection -LocalPort 10808 -State Listen |
ForEach-Object { Get-Process -Id $_.OwningProcess }コマンドで確認できるのはPC上のポートであり、ノードが使用可能かどうかではありません。待ち受けアドレスが127.0.0.1の場合、アクセスできるのは自分のPCからだけです。トラブル対処のために、安易にLANからアクセスできる設定へ変更しないでください。
i/o timeout：接続タイムアウトと読み取りタイムアウトを区別する
i/o timeoutは、何らかの処理が制限時間内に終わらなかったことを示すだけです。前後のdial tcp、read tcp、DNSに関する情報とあわせて読み取ってください。接続タイムアウトは接続が確立する前に起きます。読み取りタイムアウトは、データを待っている間に応答が届かなかったことを示します。確認すべき箇所はそれぞれ異なります。
エラー：dial tcp 192.0.2.10:443: i/o timeout
原因：ノードのポートへの接続が時間内に完了しませんでした。アドレスの誤り、サービスへの到達不能、経路上のパケットロス、ファイアウォールによる破棄などが原因として考えられます。このアドレスは説明用であり、実際の接続テストには使えません。
対処：サブスクリプションに記載されたノードのアドレスとポートを確認し、別のネットワークまたは利用可能とわかっている別のノードで比較します。1回タイムアウトしただけで、すべての通信設定を変更しないでください。
エラー：read tcp …: i/o timeout
原因：接続の途中でデータの読み取りを待っている間にタイムアウトしました。ハンドシェイク、リモート側からの応答、接続のアイドル状態などが関係している可能性があり、ノードのポートに接続できないとは限りません。
対処：同じ接続の前に記録されたハンドシェイクのログを確認し、タイムアウトがノードとのハンドシェイク前に起きたのか、接続先へのアクセス後に起きたのかを見分けます。そのうえでノード設定とアクセス先をそれぞれ確認してください。
- すべてのノードでタイムアウト：まずローカルネットワーク、プロキシのループ、ファイアウォール、システム時刻を確認します。一括速度測定によるネットワークの混雑でないことも確かめてください。
- 特定のノードだけタイムアウト：ネットワーク環境はそのままにして他のノードと比較し、問題のノードのアドレス、ポート、サービスの状態を重点的に確認します。
- 特定のWebサイトだけタイムアウト：そのドメインにどの出方向が適用されているか、接続先自体が利用できるかを確認します。サブスクリプション全体をすぐにリセットしないでください。
TCPポートのテストに成功しても、その時点でTCP接続が確立したことしか確認できず、VMess、VLESS、TLSのハンドシェイクが正しいとは限りません。逆に、ICMP応答がないだけでプロキシサービスが使えないとも判断できません。
TLSハンドシェイク失敗：証明書、名前、通信設定を切り分ける
ノードのポートに接続できても、TLSの段階で失敗することがあります。まずエラーが「クライアントからノードへの接続」と「ブラウザーから接続先Webサイトへの接続」のどちらで起きているか確認してください。ブラウザーに表示された証明書エラー画面を、そのままXrayのノードハンドシェイクログとみなすことはできません。同じ接続について記録されたコアのエラーを確認してください。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間と現在のシステム時刻が一致していません。ノードの証明書が期限切れになっている場合も、PCの日付やタイムゾーンの設定が原因で時刻がずれている場合もあります。
対処：Windowsの「設定」→「時刻と言語」→「日付と時刻」を開き、時刻を確認して同期してください。時刻が正しい場合は、ノードの管理者に証明書を確認してもらいます。
エラー：x509: certificate signed by unknown authority
原因：証明書チェーンを、現在の環境で信頼されているルート証明書で検証できません。サーバー証明書チェーンの不足、自己署名証明書、ネットワーク上のTLS検査などが原因として考えられます。
対処：まずノードの提供元、証明書の設定、システムの信頼環境を確認してください。証明書検証の無効化を、日常的な解決策として使わないでください。
エラー：remote error: tls: handshake failure
原因：リモート側がTLSハンドシェイクを中断しました。SNI、TLS設定、サーバー側のポリシーの不一致などが原因として考えられますが、このメッセージだけでは特定できません。
対処：ノードの提供元が指定したサーバー名と通信設定を照合し、サブスクリプションを更新してから再接続します。拒否された理由はサーバー側のログもあわせて確認してください。
ノードの編集画面で、serverNameに対応するサーバー名、TLSの有効・無効、選択中の通信方式を確認します。WebSocketのHost、パス、TLSのSNIはそれぞれ別の層にあるため、ドメイン名が1つ表示されているだけで、すべての項目を同じ値にしないでください。gRPCのサービス名もサーバー側の設定と一致させる必要があります。
DNS、EOF、ルーティングタグ：エラーの前後関係を確認する
DNSエラーは、まず「ノードのドメイン名を解決できない」場合と「アクセス先のドメイン名を解決できない」場合に分けて確認します。前者ではプロキシ接続自体を確立できないことがあり、後者では一部のWebサイトだけに影響する場合があります。ドメインルール、IPルール、DNSの出方向によって名前解決の場所も変わるため、DNSエラーを見てWindowsのネットワークアダプター設定だけを変更しないでください。
エラー：no such host
原因：ドメイン名の問い合わせで有効なホスト情報を取得できませんでした。入力ミス、ドメインの失効、DNSリゾルバーからの否定応答などが原因として考えられます。
対処：エラーに出ているドメインがノードと接続先のどちらのものか確認し、入力、DNSサーバー、名前解決に使う出方向を調べてください。すべてのドメインをIPアドレスに置き換えたままにしないでください。
エラー：unexpected EOF
原因：プログラムがさらにデータを受け取ると想定している段階で、相手側が接続を閉じました。プロトコルの不一致、転送設定の異常、リモート側からの切断などが原因として考えられます。
対処：切断がTLS、プロキシプロトコル、接続先からの応答のどの段階で起きたかを確認し、通信方式とサーバー設定を照合してください。このエラーだけで認証情報の誤りと決めつけることはできません。
以下は簡略化したアクセスログの例で、実際の速度測定結果ではありません。httpは受信側のタグ、proxyは送信側のタグです。名称は設定によって異なります。ログのacceptedはリクエストを受け付けて処理したことを示しますが、ノードでの認証完了や接続先Webページからの応答を意味するものではありません。
from 127.0.0.1:52134 accepted tcp:example.com:443 [http -> proxy]- プロキシ経由の想定なのに
directが表示される場合は、まずルーティングルールの順序、ドメインの一致条件、現在選択中のルーティング設定を確認してください。 blockが表示される場合は、ブロックルールに一致していないか確認してください。これはノードへの接続障害ではありません。- リクエストを再現しても該当するログがまったくない場合は、アクセスログが有効か確認し、ブラウザーがシステムプロキシを使っているか、アプリの通信がTUNに入っているかを確認します。
- 複数のリクエストが入り交じっている場合は、時刻、接続先、接続IDを使って関連付けます。別のバックグラウンドリクエストのエラーを、現在のページの結果と取り違えないでください。
よくある質問と、トラブル対処に必要な情報
warningが次々に表示されます。ノードの故障でしょうか？
まず一括速度測定を停止し、実際のアクセスを1回だけ再現してください。ページが正常に表示され、警告がキャンセル済みのバックグラウンドリクエストに関するものなら、警告の数だけを理由にノードを変更する必要はありません。同じリクエストが失敗し続ける場合は、エラーの流れ全体を記録してから判断してください。
サブスクリプションを更新できるのに、プロキシに接続できないのはなぜですか？
サブスクリプションの更新で取得できるのは設定内容です。メイン画面に戻り、そのグループ内のノードが選択されていることを確認してから、コアが正常に起動したか調べてください。その後、ローカルの待ち受けとノードのハンドシェイクログを確認します。どちらもサブスクリプションの更新成功だけでは保証されません。
Webページが開かず、ログにもエラーがない場合はどうすればよいですか？
まずログレベルと表示欄が正しいか確認してください。ブラウザーからリクエストを1回だけ送り、システムプロキシの接続先ポートを確認します。TUNを使用している場合は、ネットワークアダプターと権限に関するメッセージも確認してください。リクエストがコアに届いていなければ、対応する出方向のエラーは記録されません。
ログファイルを丸ごと人に送る必要がありますか？
通常は、起動情報、再現時刻の前後にある必要最小限のログ、クライアントとコアのバージョン、TUNの使用有無を共有すれば十分です。認証情報、サブスクリプションURL全体、個人的なアクセス先は伏せてください。スクリーンショットを共有する場合も、画面にノード名やアドレスが写っていないか確認します。
状況を確認しやすい報告には、使用OS、クライアントとコアのバージョン、障害が1つのノードだけかすべてのノードか、発生した正確な時刻、実施済みの単一条件テストを含めます。たとえば「ローカルの10808は待ち受け中。ネットワークを変えても同じノードでTLS段階の失敗が続く」と書くと、「ソフトが使えない」より次の確認箇所を絞り込みやすくなります。
- まず起動：コアの終了、設定の解析エラー、ポート競合を確認します。
- 次に接続：接続拒否、接続タイムアウト、DNSエラーを区別します。
- 続いてハンドシェイク：時刻、証明書、サーバー名、通信設定を確認します。
- 最後に接続先：出方向のタグと接続先からの応答を確認し、ルーティングまたはサイト側の問題か判断します。