クライアントに「接続済み」や「サービス起動中」と表示されても、通常はローカルのプロキシコアが動作し、待受ポートが開いていることを示すだけです。ブラウザーのリクエストがプロキシを経由したことや、リモートノードへの接続が完了したことまでは意味しません。確認時は、サブスクリプションを何度も更新したりノードを連続して切り替えたりせず、リクエストが実際に通る経路に沿って外側へ調べます。
このリストは、v2rayN、v2rayNG、v2flyNGを起動しているのにWebページがタイムアウトしたり、白紙になったり、接続できないと表示されたりする場合に役立ちます。通信がローカルポートへ入っているか、ノードへ到達できるか、ドメインを解決できるか、ルーティングで誤って振り分けられていないか、システム時刻が正確かを順番に確認すれば、問題の層を絞り込めます。
まず「クライアント接続済み」の意味を確認する
V2Ray、Xray、V2Flyのコアは、必要になった時点でリモート接続を確立するのが一般的です。クライアントを起動すると、ローカルのHTTP、SOCKS、VPNインターフェースが先に動作します。ブラウザーが実際にリクエストを送って初めて、コアがDNS解決、ルール照合、プロトコルのカプセル化、リモートへの接続を行います。そのため、画面上の動作状態だけで完全なWebリクエストのテストを代用することはできません。
まず障害の範囲を切り分けます。プロキシを完全に無効にした状態で通常のWebサイトを開けるか、プロキシを有効にするとすべてのサイトで失敗するのか、それともプロキシ対象のサイトだけ失敗するのかを確認します。ドメイン名で失敗する場合は、既知のアドレスへ直接アクセスしても失敗するかも試します。3つの結果から、ローカルネットワーク、プロキシ経路、DNSまたはルーティング層を判断できます。
ステップ1：システムプロキシが本当にクライアントを向いているか確認する
Windowsでv2rayNを使う場合、コアの動作とシステムプロキシは別々の状態です。サービスを起動しただけでシステムプロキシを設定していなければ、ブラウザーは直接接続します。v2rayNのメイン画面で「システムプロキシ」→「システムプロキシを自動設定」を選び、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開いて、プロキシサーバーが 127.0.0.1 を指し、ポートがv2rayNの現在のHTTPポートと一致していることを確認します。
- v2rayNの「設定」→「パラメータ設定」を開き、ローカルのSOCKSポートとHTTP待受ポートを記録します。
- ポートが手動で別の番号に変更されていないか確認します。一般的な組み合わせは、SOCKS
10808、HTTP10809です。 - ブラウザーにプロキシ拡張機能や固定プロキシアドレスが個別設定されていないか確認し、システムプロキシが上書きされないようにします。
- システムプロキシを変更する他のネットワークツールを一時的に終了し、「システムプロキシを自動設定」をもう一度実行します。
- ブラウザーを終了して再起動し、古い接続プールと古いプロキシ設定を無効にします。
システムプロキシの設定を介さずにローカルポートを確認したい場合は、ターミナルからHTTPプロキシ経由でリクエストを送れます。次のテストでHTTPレスポンスヘッダーが返れば、ブラウザーからローカルプロキシまでの経路はおおむね正常です。127.0.0.1 への接続にすぐ失敗する場合は、コアが終了していないか、ポート番号を間違えていないか、待受アドレスが変更されていないかを優先して確認します。
curl --proxy http://127.0.0.1:10809 --head https://v2help.com/エラー：Failed to connect to 127.0.0.1 port 10809
原因と対処：ローカルHTTPポートが待ち受けていないか、実際のポートが10809ではありません。「設定」→「パラメータ設定」に戻ってポートを確認し、保存後にコアを再起動します。
エラー：address already in use
原因と対処：別のプロセスが待受ポートを使用しています。同じポートを使っているプログラムを終了するか、HTTPとSOCKSのポートを未使用の番号へ変更し、システムプロキシも更新します。
Androidでは仕組みが異なります。v2rayNGとv2flyNGは、システムのVpnService権限を取得して初めてアプリの通信を引き受けられます。初回接続で許可をスキップした場合や、システムがバックグラウンドでVPNを停止した場合、クライアント画面にはノード情報が残っているのに、実際の通信がコアへ入らないことがあります。接続をもう一度タップし、ステータスバーにVPNアイコンが表示されることを確認します。また「設定」→「アプリごとのプロキシ」で、テスト中のブラウザーが誤って除外されていないか確認してください。
ステップ2：ノードへの到達性とサブスクリプション設定を確認する
システムプロキシが正しければ、次はノード自体を確認します。遅延テストは、特定の探測に応答があったことしか示さず、VMess、VLESS、またはトランスポート層のハンドシェイクが完全に成功したことまでは証明しません。より確実なのは、単一のノードを選んで実際にWebページへアクセスし、クライアントの実行ログで接続開始、TLS、WebSocket、認証エラーなどを確認する方法です。
| 観察結果 | 可能性が高い問題の層 | 次に確認する項目 |
|---|---|---|
| 複数のノードがいずれも約10秒後にタイムアウトする | ローカルネットワーク、DNS、または公共経路 | ネットワークを切り替えてドメイン解決を確認する |
| 1つのノードだけタイムアウトする | ノードアドレス、ポート、またはサービス状態 | サブスクリプションを更新してノード設定を確認する |
| TCP接続後すぐに拒否される | ユーザー識別子、伝送経路、またはプロトコルの不一致 | サブスクリプション提供元と設定を再同期する |
| トップページは開くが、画像やスクリプトだけ失敗し続ける | 回線のパケットロス、MTU、または振り分けの不一致 | グローバルモードと別のネットワークを比較する |
サブスクリプションの更新に成功しても、クライアントが設定を1つ取得したことを示すだけで、すべてのノードが利用できるとは限りません。ユーザー識別子、ポート、TLSサーバー名、WebSocketパスを推測して手動入力しないでください。これらの項目はサーバー側と一致している必要があります。更新直後にすべてのノードが使えなくなった場合は、現在選択しているグループが本当に新しいノードを参照しているか確認してからコアを再起動し、古いアクティブ設定が残っていないようにします。
エラー：dial tcp: i/o timeout
原因と対処：指定したアドレスとポートで、タイムアウト時間内に接続を確立できませんでした。同じサブスクリプション内の別ノードに切り替えて比較し、その後ローカルネットワークも切り替えて、単一ノードの障害か現在の回線から到達できないのかを切り分けます。
エラー：connection refused
原因と対処：リモートアドレスには到達できますが、対象ポートが接続を受け付けていません。サブスクリプションを更新してポートを確認し、このノードだけで起きるならローカルプロキシの変更を続けないでください。
エラー：invalid user
原因と対処：VMessまたはVLESSのユーザー識別子がサーバー側と一致していないか、古い設定が無効になっています。サブスクリプションを更新してノードを選び直し、ユーザー識別子を自分で書き換えないでください。
エラー：failed to dial WebSocket
原因と対処：WebSocketパス、ホスト名、TLSパラメータ、または中間ネットワークの設定が一致していません。サブスクリプションの元設定と照合し、伝送方式とパスが手動で変更されていないか重点的に確認します。
結論：ノードを連続して替えるのではなく、1変数ずつ比較する
同じネットワークのままクライアント設定を保持し、既知の利用可能なノードだけを切り替えます。次にノードを固定して、別のネットワークへ切り替えます。この2回の比較で、「ノードの障害」と「ローカル回線の障害」を切り分けられます。
ステップ3：プロキシへ渡る前にDNSで失敗していないか確認する
ブラウザーがドメイン名へアクセスするには、まずアドレスを取得する必要があります。ノードサーバー自体がドメイン名で指定されている場合、クライアントは最初にノードアドレスも解決しなければなりません。ここで失敗すると、プロキシプロトコルはハンドシェイクを開始する機会すらありません。ログに lookup、no such host、failed to find an available destination が出る一方、ローカルキャッシュに残った古いページだけが一時的に開くことがあります。
nslookup v2help.com
nslookup v2help.com 1.1.1.11つ目は現在のシステムDNSを使い、2つ目は比較用に別のDNSサーバーを指定します。1つ目だけが継続的にタイムアウトし、2つ目が1～2秒でアドレスを返すなら、まずシステムDNSを修復します。両方とも失敗する場合は、現在のネットワークがDNS問い合わせを許可しているかを引き続き確認します。テスト後はクライアントに戻り、コアを再起動してリクエストを再実行し、以前の失敗キャッシュが判断に影響しないようにします。
- Windowsでは「設定」→「ネットワークとインターネット」→現在のネットワーク接続を開き、DNS設定を確認できます。
- DNSを変更したら
ipconfig /flushdnsを実行し、ブラウザーを完全に終了してから再起動します。 - v2rayN 7.xでカスタムDNSを使う場合は、入力したサーバーアドレスが解決可能で、設定構文に余分なコンマや無効な項目がないことを確認します。
- ルーティングルールでドメイン名を照合する必要がある場合は、解決前にすべてのドメインをルールの想定と合わないアドレスへ強制的に書き換えないでください。
- ノードのドメイン名だけ解決できず、通常のドメインは正常な場合は、サブスクリプション内のノードアドレスが完全か、空白が混入していないか確認します。
エラー：failed to lookup ip for domain
原因と対処：コアが現在のDNSからノードまたは対象ドメインのアドレスを取得できていません。システムDNSを自動取得に戻すか、利用可能なDNS設定へ変更してからコアを再起動します。
エラー：no such host
原因と対処：ドメインが存在しない、入力を誤っている、またはDNSが存在しない結果を返しています。サブスクリプションのサーバーアドレスを確認し、トランスポート層のホスト名とノードアドレスを入れ替えないでください。
エラー：failed to find an available destination
原因と対処：アウトバウンドの接続先に利用可能なアドレスがありません。解決失敗やアドレスファミリーの不一致でよく起こります。まずDNSを既定値に戻し、IPv4と現在のネットワークが提供するアドレスを個別にテストします。
ステップ4：ルーティングでリクエストが誤った出口へ送られていないか確認する
ルーティングの振り分けによって、リクエストがプロキシ、直接接続、ブロックのどれを通るかが決まります。ノードが完全に利用可能でも、ルールが対象ドメインを直接接続へ送れば、Webページはタイムアウトすることがあります。逆に、LANアドレスがプロキシへ送られると、ルーターの管理画面やローカルサービスが開けなくなる場合もあります。最も有効な診断は、すぐにルールを書き換えるのではなく、一時的にグローバルプロキシへ切り替えて比較することです。
- 現在のルーティング設定を保存し、使用中のルールセット名を記録します。
- v2rayNでグローバルプロキシに対応するルーティングモードを一時的に選択し、コアを再起動します。
- ブラウザーで開いているタブを閉じ、先ほど失敗した同じアドレスへ再度アクセスします。
- グローバルモードで復旧する場合、問題はドメインルール、アドレスルール、またはアウトバウンドタグにあります。
- 元のルーティングへ戻し、ルールの照合順を1つずつ確認します。誤ったルールを隠すために、グローバルモードを常用しないでください。
V2RayとXrayのルーティングは通常、設定の順番に従って照合されます。範囲の広いルールを前に置くと、後ろにある正確なルールが先に取り込まれることがあります。例えば、範囲が広すぎる直接接続のドメインルールが、プロキシへ送るべきリクエストを直接送ってしまう場合があります。早い位置にブロックルールがあると、リクエストがローカルで拒否されます。ログに対象ドメインとアウトバウンドタグが表示されるなら、実際の照合結果を基準に判断してください。
v2rayNGとv2flyNGでは、アプリごとのプロキシも追加で確認します。選択したアプリだけVPNを通す設定で、ブラウザーが選択されていなければ、クライアントは接続中でもブラウザーは常に直接接続します。「設定」→「アプリごとのプロキシ」を開き、現在のモードが「選択したアプリを除外」なのか「選択したアプリのみプロキシ」なのかを確認してください。この2つはチェックの意味が逆です。
結論：グローバルで使えるならルールの照合結果を確認する
同じノードがグローバルモードではWebページを開け、振り分けへ戻すとすぐ失敗するなら、ノードとローカルポートは検証済みです。次はドメインルール、アドレス範囲、アプリごとの対象リスト、アウトバウンドタグだけを確認します。
ステップ5：システム時刻を合わせ、TLSとプロトコル設定を確認する
システム時刻がずれていると、TLS証明書の有効期間判定に影響し、時間枠に依存する認証処理にも支障が出ます。VMessはクライアントとサーバーの時刻差に比較的敏感です。PCのスリープ後に時刻がずれたり、仮想環境の停止から復帰したりすると、ローカルポートは正常なのにリモート側で接続を拒否され続けることがあります。VLESSでTLSを使う場合も、証明書検証には正確な時刻が必要です。
- Windowsで「設定」→「時刻と言語」→「日付と時刻」を開き、「時刻を自動的に設定する」と「タイムゾーンを自動的に設定する」を有効にします。
- 「今すぐ同期」をクリックし、日付、タイムゾーン、分がすべて正しいことを確認します。
- Androidでシステムの「設定」→「システム」→「日付と時刻」を開き、ネットワーク提供の時刻を有効にします。
- 時刻を合わせたら、ブラウザーのページを更新するだけでなく、v2rayN、v2rayNG、v2flyNGのコアを再起動します。
- ログにTLSエラーが残る場合は、サブスクリプションのサーバー名、トランスポートのセキュリティ方式、ポートを確認し、他のノードのパラメータを手動で混在させないでください。
エラー：certificate has expired or is not yet valid
原因と対処：端末の時刻が間違っているか、リモート証明書が有効期間外です。まずシステム時刻を同期します。時刻が正しく、1つのノードだけで発生する場合は、そのノードの使用を中止してサブスクリプションを更新します。
エラー：tls: handshake failure
原因と対処：TLSサーバー名、プロトコルネゴシエーション、またはリモート設定が一致していません。サブスクリプションにあるTLSパラメータへ戻し、別ノードのサーバー名をコピーしていないことを確認します。
エラー：rejected proxy connection
原因と対処：プロキシ経路上で接続が拒否されています。認証パラメータの失効や、現在のアウトバウンドによる接続先のブロックが考えられます。サブスクリプションを更新し、同じグループの別ノードと比較して、どのアウトバウンドで拒否されたかログを確認します。
クライアントのコアがノードの機能に対応しているかも確認してください。v2rayNは設定に応じて適切なコアを呼び出せます。v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。通常のVMessやVLESS設定だからといって、すべての拡張トランスポート機能を異なるコア間でそのまま交換できるわけではありません。インポート後に項目が欠けていたり、ログに未対応と明示されたりする場合は、設定の機能に対応したクライアントを選び、未知の項目を無闇に削除しないでください。
手順どおりに進める最終確認リスト
ここまでの確認を終えたら、次の順番でもう一度確認できます。各項目には「通過」か「未通過」だけで答え、最初に未通過となった層を処理してから先へ進みます。変更を重ねずに済むため、原因の特定が早まり、復旧後に一時設定を戻しやすくなります。
- 基本ネットワーク：プロキシを無効にすると、現在のネットワークから通常のWebページへ正常にアクセスできる。
- コアの状態：クライアントの実行ログに、ポート競合、設定解析の失敗、プロセス終了の表示がない。
- ローカル入口：システムプロキシが
127.0.0.1と実際のHTTPポートを指している、またはAndroid VPNの権限が許可されている。 - リクエストの受信：Webページを更新すると、アクセスログに新しい対象ドメインまたは接続記録が表示される。
- ノード到達性：少なくとも1つのノードで、遅延探測だけでなく実際のWebリクエストを完了できる。
- DNSの正常性：システムの問い合わせが約1～2秒で結果を返し、ログにlookupエラーが継続して表示されない。
- ルーティングの正確性：グローバルモードと振り分けモードの比較結果が明確で、対象が想定したアウトバウンドに一致している。
- 時刻の正確性：システムの日付、タイムゾーン、分が同期され、TLSログに有効期間の問題が表示されない。
- アプリの対象範囲：ブラウザーがアプリごとのプロキシから除外されておらず、古い個別プロキシ設定も使用していない。
- 設定の一貫性：プロトコル、ポート、ユーザー識別子、TLSサーバー名、伝送パスがすべて同じサブスクリプション項目に由来している。
遅延テストには数値が出るのに、なぜWebページはタイムアウトする？
遅延探測では、プロトコルのハンドシェイクや対象サイトへのアクセスまで完了しないことがあります。ノードを選択して実行ログを開き、Webページへアクセスして i/o timeout、TLS、認証エラーが出ていないか確認します。
ブラウザーだけ開けず、他のアプリはインターネットに接続できる場合は？
まずブラウザー独自のプロキシ設定と拡張機能を無効にし、システムプロキシに従っていることを確認します。その後ブラウザーを完全に終了して再起動し、古い接続プールがテストに影響しないようにします。
サブスクリプションを更新したのに古いノードが使われるのはなぜ？
現在のアクティブグループと選択中のノードを確認し、更新後の項目を選び直してからコアを再起動します。サブスクリプション一覧を更新しただけでは、実行中の古い接続がすぐ切り替わるとは限りません。
グローバルモードは使えるのに、振り分けモードでは使えない場合の直し方は？
振り分けへ戻した後、対象ドメインが照合されたアウトバウンドタグを確認します。前方にある範囲の広い直接接続ルール、ブロックルール、Androidのアプリごとのプロキシ対象リストを優先して確認してください。
PCを再起動するとまた開けなくなります。再設定は必要？
まずクライアントが起動しているか、システムプロキシが現在のポートを指しているか、ポートが他のプログラムに使用されていないか確認します。設定ファイルにエラーがなければ、サブスクリプション全体を再インポートする必要はありません。
確認リストが「リクエストの受信」で止まるなら、問題はブラウザー、システムプロキシ、VPN権限に集中しています。コアにリクエストが入った後で接続エラーが出るなら、ノード、ネットワーク、DNSを確認します。振り分けモードだけ失敗する場合は、ルールの照合結果に戻ります。問題を1つの層に絞ってから設定を変更するほうが、クライアントを一度に再インストールするより再現性のある結果を得やすくなります。