ノードをインポート済みなのに接続がタイムアウトする、またはWebページを開けない場合に役立つ手順です。まずコマンドでローカルプロキシがリクエストを受け付けているか確認し、次にアプリの通信がコアに届いているか、最後にノード設定と接続先ポートを確認します。一度に変更するのは一項目だけにして再テストすれば、端末の設定、プロトコルのハンドシェイク、サーバー側の問題を切り分けやすくなり、すべてをノードの障害と決めつけずに済みます。
1. タイムアウトが発生する段階を切り分ける
v2rayNは設定の管理、コアの起動、システムプロキシの設定を行うデスクトップクライアントで、実際の通信は選択したコアが処理します。画面が開くことやサブスクリプションを更新できることは、プロキシ経由の通信が正常であることを意味しません。サブスクリプションの取得とWebサイトへのアクセスでは、異なるネットワーク経路が使われることもあります。ノード一覧の状態だけを見るのではなく、具体的なリクエストを一度送って確認しましょう。
ノード、接続先、テスト方法をそれぞれ一つに決めます。連続した速度測定や自動切り替えは一時停止し、再現した時刻を記録してください。クライアントのテストだけがタイムアウトし、ブラウザーでは利用できる場合は、まずテスト先にそのノードからアクセスできるか確認します。テスト先に接続できないだけでは、すべてのWebサイトにアクセスできないとは限りません。
- すべてのノードで失敗する：ノードを一つずつ変更する前に、ローカルポート、コアの起動、システムプロキシを確認します。
- 特定のノードだけ失敗する：同じ条件でテストし、そのノードの設定、接続先ポート、サーバーの稼働状況を確認します。
- 特定のアプリだけ失敗する：そのアプリがシステムプロキシを使うか、独自のプロキシやDNSを設定していないか確認します。
- 一部のWebサイトだけ失敗する：ルーティング、ドメイン名の名前解決、接続先サイトの制限を確認します。すぐにクライアントを再インストールする必要はありません。
2. ローカルポート：コアが待ち受けているか確認する
まずv2rayNの「設定」→「パラメータ設定」で、ローカルの待ち受けポートとプロキシの種類を確認します。画面のバージョンによって項目の位置が異なる場合があるため、現在の設定と起動ログを基準にしてください。以下では 127.0.0.1:10808 の混合インバウンドを例にします。HTTPまたはSOCKSの専用インバウンドを使っている場合は、該当するポートに読み替えてください。この数値がすべてのバージョンで固定の既定値というわけではありません。
WindowsではPowerShellで次のコマンドを実行します。1つ目で待ち受けの有無を確認し、2つ目で結果のプロセス番号に対応するプログラムを調べます。LISTENING と表示されればポートが待ち受け中です。接続記録だけで待ち受け記録がない場合は、確認できたことにはなりません。
netstat -ano | findstr ":10808"
tasklist /FI "PID eq 1234"2つ目のコマンドにある 1234 はプロセス番号の例です。実行前に、1つ目の結果の最終列にある実際の番号へ置き換えてください。macOSとLinuxでは次のコマンドで確認できます。Linuxに lsof がインストールされていない場合は ss を使えます。
lsof -nP -iTCP:10808 -sTCP:LISTEN
# Linuxでの別の確認方法
ss -lntp 'sport = :10808'- 待ち受けていない：コアの起動ログを確認し、設定の読み込み失敗、コアの不足、権限エラーなどを解消してからノードを再度有効にします。
- 他のプログラムがポートを使用中：まず使用中のプロセスを特定し、競合するプログラムを終了するかインバウンドのポートを変更します。変更後はアプリのプロキシ設定も更新してください。
- 待ち受けアドレスが一致しない：IPv6のループバックアドレスだけで待ち受けている場合、IPv4の
127.0.0.1への接続に失敗することがあります。アドレスとインバウンド設定を一致させてください。
3. システムプロキシ：明示的なリクエストで切り分ける
ローカルの待ち受けを確認したら、システムプロキシの設定を介さず、プロキシポートへ直接リクエストを送ります。WindowsではPowerShell環境による同名エイリアスの動作差を避けるため curl.exe を使い、macOSとLinuxでは curl を使います。example.com はテスト先の例です。コマンド内のポートは実際のインバウンドに合わせてください。
# Windows：HTTP対応のインバウンドでのみ使用
curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com
# macOS / Linux：SOCKS5対応のインバウンドでのみ使用
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.comsocks5h は、接続先のドメイン名をプロキシ側で処理する指定です。2つのコマンドは異なるインバウンドプロトコルをテストするためのものです。SOCKS専用ポートにHTTPプロキシの書式を使うことはできません。HTTPレスポンスヘッダーが返れば、リクエストが応答を返すサーバーまで到達したことを示します。403 などが返った場合は、接続タイムアウトとみなさず、サイト側のポリシーも確認してください。
-
プロキシポートを確認
v2rayNの「設定」→「パラメータ設定」でローカルのインバウンドポートと種類を確認し、該当する明示的プロキシのコマンドを実行します。
-
システムプロキシを有効化
Windowsではv2rayNのトレイメニューから「システムプロキシ」→「システムプロキシを自動設定」を選んで有効にし、ブラウザーを開き直してテストします。
-
システムの設定を確認
Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、アドレスとポートがクライアントの設定と一致しているか確認します。他のプログラムが設定を繰り返し書き換えていないかも確認してください。
-
アプリ側の設定を確認
ブラウザーのプロキシ拡張機能とアプリ独自のネットワーク設定を確認します。独自のプロキシ設定を一時的に無効にし、通信を経由させる方法を一つだけにして再テストしてください。
結論：明示的なプロキシ接続に成功したら、まずアプリ側の入口を確認
コマンドは成功するのにブラウザーで失敗する場合は、ブラウザーのプロキシ、システムプロキシ、アプリのDNS設定の違いを確認します。この段階では、通信がローカルプロキシに届いていない問題をノードの変更で解決できるとは限りません。
macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」で設定を確認できます。Linuxでは、システムプロキシが個々のプログラムに適用されるかどうかは、デスクトップ環境やアプリの実装によって異なります。コマンドラインツールがデスクトップのプロキシ設定を読み取るとも限らないため、明示的なオプションか、ツールが対応するプロキシ環境変数を使ってください。
4. クライアントログ：最後の行ではなく失敗した段階を見る
リクエストをもう一度送信しながら、v2rayNのログ欄または現在のバージョンに備わっているログウィンドウを確認します。リクエストの前後にある数行を残し、特にインバウンドアドレス、接続先アドレス、ルーティング先のアウトバウンド、最も内側にあるエラーに注目してください。「接続の処理に失敗しました」といった外側のメッセージは概要にすぎないことが多く、実際の原因は後続のDNS、TCP、TLSエラーに記録されています。
bind: address already in use
原因：プログラムがバインドしようとしているローカルアドレスとポートが、すでに使用されています。
対処法：使用中のプロセスを特定して用途を確認し、競合を解消してからコアを再起動します。ポートを変更した場合は、システムプロキシも更新してください。
connect: connection refused
原因：接続が明示的に拒否されました。該当ポートでサービスが待ち受けていない場合のほか、端末やファイアウォールが拒否している可能性もあります。
対処法：エラーに表示されたアドレスがローカルかリモートかを確認し、該当する側の待ち受け状態と拒否ルールを調べます。
i/o timeout
原因：ネットワークの読み書きが制限時間内に完了しませんでした。このメッセージだけではノードの障害か接続先サイトの無応答かを判断できません。
対処法：前後のログから名前解決、接続、データ転送のどの段階で止まったかを確認し、ノードのポートと接続先サイトをそれぞれテストします。
x509: certificate has expired or is not yet valid
原因：証明書の有効期間の確認に失敗しました。端末の時刻がずれている場合と、サーバー証明書の期限が切れている場合があります。
対処法：まずシステムの日付と時刻を同期します。時刻が正しいのにエラーが続く場合は、サーバー管理者に証明書と証明書チェーンを確認してもらってください。
エラーの文面はOSやコアによって異なります。上記はよくあるエラーの一部であり、すべてのバージョンで同じ文言が出るとは限りません。コアでアクセスログを有効にしているのに該当するリクエストが記録されない場合は、まずアプリ側の入口を再確認します。アクセスログが無効なら、「リクエストが見当たらない」ことだけを根拠に通信が届いていないと判断することはできません。
5. ノード設定：プロトコルと通信パラメータを照合する
接続先ポートでTCP接続を確立できても、プロキシ認証や通信のハンドシェイクが成功するとは限りません。VMess、VLESS、Trojan、Shadowsocksでは、認証とセキュリティの仕組みがそれぞれ異なります。トランスポート層、TLS、プロトコル名は別の設定項目です。プロトコルの選択欄を変更しただけで、ノードのプロトコルが別のものに変わるわけではありません。
| 確認項目 | 確認する内容 | 対処方法 |
|---|---|---|
| アドレスとポート | サーバーのドメイン名、IPアドレス、サーバー側の待ち受けポート | 提供元の情報と一致させます。ローカルの10808をノードの接続先ポートに入力しないでください。 |
| プロトコルと認証 | VMess/VLESSのUUID、Trojanのパスワード、Shadowsocksの方式とパスワード | 入力時の空白や文字の抜けを避けるため、設定一式を再インポートします。 |
| トランスポート設定 | TCP、WebSocketなどのトランスポート方式と、対応するパス、Host | 項目ごとにサーバー側と照合します。パスの大文字・小文字や先頭のスラッシュも一致させてください。 |
| TLS設定 | TLSの有効・無効、サーバー名、証明書のドメイン名 | サーバー側の要件に合わせて設定し、接続先アドレスとTLSのサーバー名を区別します。 |
| コアの対応状況 | 選択中のコアが、ノードに必要なプロトコル、トランスポート、セキュリティ設定に対応しているか | 実際に起動しているコアとエラーメッセージを確認します。クライアント名だけで対応状況を判断しないでください。 |
サブスクリプションに更新がある場合は、まず「サブスクリプショングループ」の更新操作で最新の設定を取得し、現在選択中のノードが古い設定のままではないか確認します。接続を試すためだけにTLSサーバー名を削除したり、証明書の検証を無効にしたりしないでください。設定ミスが隠れ、通信の安全性も低下します。VMessの認証にも適切なシステム時刻が必要なため、時刻の同期は証明書エラーが出た場合に限らず、基本項目として確認してください。
- Windows：「設定」→「時刻と言語」→「日付と時刻」を開き、時刻の自動設定を確認して同期を実行します。
- macOS：「システム設定」→「一般」→「日付と時刻」を開き、時刻の取得元と現在の時刻を確認します。
- Android：v2rayNGまたはv2flyNGを使う場合も、システム時刻、ノードの各項目、接続ログを確認してください。デスクトップ版のシステムプロキシ設定をAndroidのVPN方式による通信制御にそのまま適用することはできません。
6. サーバーへの接続性：ポート、ハンドシェイク、転送を切り分ける
ローカルの待ち受け、アプリ側の入口、ノード設定を確認したら、現在のネットワークから接続先へ到達できるかテストします。WindowsではPowerShellで次のコマンドを実行します。例にある example.com と 443 は、実際のノードサーバーのアドレスとポートに置き換えてください。例のまま実行しても、ノードが使えることの証明にはなりません。
Test-NetConnection -ComputerName example.com -Port 443TcpTestSucceeded の結果を確認します。True はTCP接続が確立したことを示すだけで、UUID、パスワード、TLS、WebSocketのパス、サーバー側の転送が正しいとは限りません。False の場合は、名前解決、サーバーの待ち受け、セキュリティグループ、ファイアウォールを追加で確認します。UDPベースのトランスポートでは、このTCPテストを該当プロトコルの確認の代わりにはできません。
- 名前解決を確認：
nslookup example.comでサーバーのドメイン名を調べます。自分のノードのドメイン名に置き換え、結果がサーバーの構成と一致するか確認してください。IPv4とIPv6の両方のアドレスがある場合は、実際の接続で使用されるアドレスをそれぞれ確認します。 - 待ち受けを確認：自分で管理するLinuxサーバーでは
ss -lntpでTCPの待ち受けを確認できます。UDPサービスの場合はss -lnupを使います。待ち受けアドレス、ポート、プロセスが実際の構成と一致しているか確認してください。 - 接続許可ルールを確認：クラウドのセキュリティグループとOSのファイアウォールの両方で、実際のサーバーポートと対応プロトコルを許可する必要があります。原因を調べる代わりに、ファイアウォール全体を長期間無効にしないでください。
- ハンドシェイク経路を確認：リバースプロキシを使用している場合は、ドメイン名、TLS証明書、転送パス、バックエンドサービスの状態も確認します。入口のポートが開いていても、バックエンドが正常とは限りません。
- サーバーからの外向き通信を確認：ハンドシェイクに成功しても接続先にアクセスできない場合は、サーバー側のDNS、外向き接続、ルーティングポリシー、接続先サイトの応答を確認します。
結論：同じノードでネットワークを比較する
ノード、端末、接続先サイトは変えず、信頼できる別のネットワークで再テストします。特定のネットワークだけで失敗する場合は、そのネットワークの名前解決、IPv6経路、外部接続の制限を優先して確認します。異なるネットワークでも同じ段階で失敗する場合は、ノードとサーバーを重点的に調べてください。
ping が使うICMPは、サーバーや途中のネットワークで制限されることがあります。そのため、pingに応答がなくてもプロキシポートに到達できないとは限りません。反対に、pingに応答があってもプロキシ認証の成功を示すわけではありません。一つのテスト結果だけで通信経路全体を判断しないでください。
7. 修正後に再テストし、正常時の基準を残す
変更後は、元のリクエスト経路を最初から再確認します。待ち受けを確認し、明示的なプロキシコマンドを実行してから、実際に使うアプリをテストしてください。一度に変更するのは一項目だけにし、変更前後でエラーが変わったか記録します。接続タイムアウトが認証エラーに変わった場合は、切り分けが次の段階へ進んだということです。すぐにすべての変更を取り消して最初からやり直す必要はありません。
- 再現性を確認：同じ接続先に繰り返しリクエストを送り、ログに同じエラーが続けて出ないか確認します。
- ルーティングを確認：リクエストがプロキシ経由と直接接続のどちらに振り分けられたか確認し、直接接続の成功をノードの復旧と取り違えないようにします。
- 通常の設定に戻す：一時的なデバッグログを終了し、不要なプロキシ設定の上書きを解除して、必要なファイアウォールルールを残します。
- 問い合わせ用の情報を残す：クライアントのバージョン、コアの種類とバージョン、ノードのプロトコル、失敗した段階、エラーの原文、ネットワークを変えた比較結果を記録します。認証情報は添付しないでください。
原因を特定できない場合は、トラブル対処ガイドも確認してください。設定のインポート、有効化、システムプロキシの手順をまだ確認していない場合は、まずクイックスタートガイドに沿って再現可能な基本設定を整えてからログを調べると、ノード、DNS、コアを同時に変更するより原因を見つけやすくなります。