TcpingはサーバーのポートにTCP接続できるかを確認し、実接続遅延はプロキシ経由でテスト先へのリクエストが完了するかを調べ、ダウンロード速度測定は一定時間の転送速度を測ります。「遅延は出るのにWebページが開かない」「遅延は低いのにダウンロードが遅い」といった問題を抱える方に向けて、測定範囲や設定の確認方法、結果の組み合わせ方を解説します。1つの数値だけでノードを選ばないための切り分け手順も紹介します。
Tcping・実接続遅延・ダウンロード速度測定で分かること
v2rayNは、設定を管理し、プロキシコアを起動するデスクトップクライアントです。ノード一覧に表示される測定結果は、それぞれ異なる手順で測ったもので、同じ回線を異なる単位で表示しているわけではありません。測定範囲を理解しておけば、テストの成功で何が確認でき、何が未確認なのか判断できます。
| テスト項目 | 主な測定対象 | 直接確認できないこと |
|---|---|---|
| Tcping | PCからノードのアドレス・ポートまでTCP接続を確立する時間 | プロキシの認証が正しいこと、接続先のWebサイトにアクセスできること |
| 実接続遅延 | テスト対象のプロキシ経由で指定URLへアクセスする際の所要時間 | すべてのWebサイトが利用できること、継続的なダウンロード速度が速いこと |
| ダウンロード速度測定 | テスト対象のプロキシ経由で測定用データを受信する速度 | 操作への応答が速いこと、すべてのダウンロード元で同じ速度が出ること |
測定結果は、クライアントのバージョンやコア、テストURL、タイムアウト、同時接続数の設定にも左右されます。実接続遅延には通常、プロキシへの接続や必要なハンドシェイク、接続先から応答を受け取るまでの時間が含まれます。ただし、計測の開始・終了地点や接続の再利用方法は実装によって異なります。単一のネットワーク往復時間を正確に測るものではなく、Tcpingとの差からサーバーの処理時間を算出することもできません。
Tcpingが成功しても通信できないのはなぜ？
Tcpingは、コマンドラインのICMP pingとは異なります。サーバーがICMPに応答しなくても、プロキシのポートが使えないとは限りません。反対に、TCP接続が成功しても、確認できるのは指定したアドレスとポートが接続を受け付けたことだけです。接続先のサービスがVMessやVLESSを正しく処理できるか、ユーザーIDが有効か、トランスポート設定が一致しているかは、まだ確認されていません。
一般的なTCP接続では、Tcpingが確認するのは主に処理の前半です。その後のTLSハンドシェイクの失敗、WebSocketパスの誤り、REALITYの公開鍵やサーバー名の不一致などにより、「Tcpingは数値が出るのに実接続はタイムアウトする」ことがあります。同じアドレスの背後にリバースプロキシや中継サーバーがある場合、TCP接続が成功しても入口に到達しただけで、その先のプロキシサービスは未確認ということもあります。
- 認証情報：サブスクリプションが最新か、ユーザーIDやパスワードなどを手動で変更していないか確認します。別のノードの項目を流用して現在の設定に混ぜないでください。
- トランスポート設定：WebSocketパス、Host、TLSサーバー名、REALITY関連の項目を確認し、サーバー側で指定された組み合わせを維持します。
- システム時刻：システム時刻の自動同期を有効にします。時刻が大きくずれていると、証明書の有効期間判定や時刻検証を伴うプロトコル認証に影響することがあります。
- サーバー側の外向き通信：接続を受け付ける入口に問題がなくても、サーバー側のDNSや接続先Webサイトへの通信に異常があれば、実接続は失敗します。
このような場合は、まずコアのログでハンドシェイク、認証、名前解決のエラーを確認し、その後に設定を見直します。Tcpingを何度繰り返しても、後続の処理は検証されず、プロトコル設定の誤りも解決しません。証明書や認証のエラーを隠すために、証明書検証を無効にすることはおすすめしません。
実接続遅延：テスト先と実際のブラウジングは分けて考える
実接続遅延は、プロキシコアを起動または呼び出し、テスト対象のノード経由で指定アドレスにリクエストを送るため、Tcpingより日常の通信に近いテストです。「この設定でプロキシ経由のリクエストを完了できるか」の判断には役立ちますが、あくまで特定のリクエストを測るもので、ブラウザーでのアクセス全体を再現するものではありません。
実接続テストの条件
- 設定画面
- 「設定」→「パラメーター設定」にある速度測定関連の項目
- テスト先のアドレス
- 画面に設定されている遅延テストURLを記録する
- 比較条件
- テスト中はURL、ネットワーク、タイムアウトの設定を変更しない
項目名や場所はバージョンによって異なる場合があります。現在の画面に表示されているテスト先とタイムアウトの設定を確認してください。
ブラウザーでのアクセス条件
- プロキシの利用設定
- ブラウザーがシステムプロキシを使っているか、ローカルプロキシを明示的に設定しているか確認する
- ノードの選択
- 現在使用中のノードが、直前にテストしたノードと同じか確認する
- ルーティングの確認
- ログを見て、実際のWebサイトへの通信がプロキシ経由か直接接続か確認する
内蔵テストはテスト対象のプロキシを直接利用でき、システムプロキシが有効であることを前提としません。
そのため、実接続テストが成功してもブラウザーで失敗することはあります。ブラウザーがプロキシを使っていない、または拡張機能で別のプロキシ設定を使っている可能性があります。Webサイトのドメインが直接接続のルールに一致し、テストURLだけがプロキシ経由になっている場合もあります。ブラウザーからリクエストを送る際にログを確認し、リクエストがコアに届いているか、どのアウトバウンドに振り分けられたかを確認してください。
反対に、ブラウザーでよく使うWebサイトを開けるのに実接続テストが失敗する場合は、テストサイトに接続できない、テストの実装が想定する形式で応答が返らない、またはタイムアウトが短すぎるといった原因が考えられます。まず同じノードでテスト先にアクセスし、次に利用可能と確認済みの軽量なテスト先に切り替えて再測定します。テスト先の変更は測定条件を検証するためのもので、数値を低く出しやすいテスト先を選ぶことが目的ではありません。
- ノード一覧からテスト対象をいくつか選び、右クリックメニューで「実接続遅延」を含む項目を選択します。
- 今回のテストが完了するまで待ち、成功・失敗と現在のテスト先を記録します。メニューの表記は使用中のバージョンによって異なります。
- 成功したノードの1つをアクティブノードに設定し、ブラウザーで実際に使うWebサイトへアクセスします。
- 結果が一致しない場合は、システムプロキシ、ローカルの待ち受けポート、ブラウザーのプロキシ設定、ルーティングログを確認してください。
ダウンロード速度測定：スループット、単位、通信量
ダウンロード速度測定では、一定時間にデータを受信する能力を確認します。回線の帯域幅、サーバーの負荷、パケットロス、輻輳制御、測定ファイルの配信元、測定時間はいずれも結果に影響します。遅延が低いと操作への応答は速くなりやすいものの、継続的な転送速度が高いとは限りません。帯域幅の広い遠距離回線でも、実接続遅延が最小になるとは限りません。
- まず単位を確認：
MB/sとMbpsは異なる単位です。10進のバイト単位で換算すると、1 MB/sは8 Mbpsに相当します。画面の単位がMiB/sの場合は、2進のバイト単位で換算してください。 - 帯域の競合を避ける：大容量ファイルのダウンロード、クラウド同期、ほかのノードの速度測定を一時停止します。そうしないと、共有回線の帯域を奪い合った結果が測定されます。
- まず少数のノードで再測定：実接続テストに成功したノードから候補を絞り、最初からサブスクリプション全体のダウンロード速度を測定しないでください。
- 通信量を確認：速度測定では実際にデータをダウンロードするため、システムやサーバー側で通信量に加算されることがあります。繰り返し実行してもコストのかからないテストではありません。
短時間のダウンロードでは、接続確立や転送速度が上がるまでの影響を受けやすく、長時間のダウンロードでは負荷の変動が反映されやすくなります。瞬間的に高い速度が出た後、大きく低下する場合は、最高値だけでなく安定した区間の速度を確認してください。測定用データの配信元によってネットワークは異なります。配信元側で速度が制限されている場合、その結果だけでノードの出口帯域が不足しているとは判断できません。
ポートとテストの順序：まず利用可否を確認し、その後に速度を比較
切り分けで混同しやすいのが、ノードのポート、ローカルの待ち受けポート、接続先Webサイトのポートです。それぞれ異なる通信区間にあります。以下の数値はポートの役割を説明する例であり、すべてのノードに推奨する設定ではありません。また、現在のv2rayNの固定デフォルト値を示すものでもありません。
たとえば、アプリが127.0.0.1:10808に接続する場合、接続先はローカルの待ち受けポートであり、リモートノードの443番ポートではありません。現在の設定で10808番ポートがそのアプリに必要なプロキシプロトコルを提供している場合に限り、この設定が使えます。ポート番号が同じでもプロトコルが同じとは限りません。HTTPプロキシとSOCKSプロキシの設定を入れ替えて使うこともできません。
- 設定を確認：サブスクリプションを更新したら、ノードのアドレス、ポート、トランスポート情報を確認します。コアの起動エラーがある場合は、まず起動の問題を解決してください。
- Tcpingで一次確認：TCP接続の明らかな異常を見つけるのに使いますが、最小の数値だけを見てすぐにアクティブノードを決めないでください。
- 実接続で再確認：候補ノードを同じテストURLで測定します。失敗したノードはログを使って原因を調べ、成功したノードは次の手順に進みます。
- ダウンロード速度測定で補足：継続的な転送が必要な候補だけを測定し、同じ測定用データを使って速度が安定するか確認します。
- 実際のアプリで確認：必要なプロキシ接続方法を有効にして、よく使うWebサイトにアクセスします。ルーティングとログが想定どおりか確認してください。
同じ条件で3回繰り返し、最も良かった結果だけを残すのではなく、中央値と失敗回数を記録するのがおすすめです。これは比較方法であり、性能を保証するものではありません。平日と夜間で負荷が異なる場合は、それぞれ記録を残し、早朝の結果から混雑時間帯の性能を推測しないようにしましょう。
よくある結果の組み合わせと対処法
Tcpingは成功するのに実接続が毎回タイムアウトする場合、まず何を確認すればよいですか？
まずログを開き、ノードを1つだけ選んでテストします。認証エラーが出た場合は、サブスクリプションを更新してユーザーIDを確認してください。TLSまたはREALITYのハンドシェイクエラーが出た場合は、サーバー名や公開鍵などを確認します。名前解決に失敗した場合は、該当ドメインのDNSを調べてください。トランスポート、ルーティング、DNSを同時に変更すると、どの変更が影響したのか分からなくなります。
実接続は成功するのに、ブラウザーでページを開けない場合は？
まずそのノードをアクティブノードに設定し、メイン画面のシステムプロキシ設定から利用方法に合った項目を選びます。続いて、ブラウザーに別のプロキシ設定がないか、ローカルポートがアプリに設定した値と一致しているか確認してください。リクエストがすでにコアに届いている場合は、測定先を変更し続けるのではなく、対象ドメインに適用されたルーティングを確認します。
遅延がかなり低いのに、ダウンロードが遅いのはなぜですか？
まずほかのダウンロードを一時停止し、同じ測定用データを使って候補ノードを1つずつ測定します。特定のダウンロードサイトだけ遅い場合は、接続先の速度制限やノードの出口からそのサイトまでの経路を確認してください。複数の配信元で遅い場合は、ローカル回線の帯域、ノードの混雑、時間帯による違いを比較します。遅延のミリ秒数をダウンロード帯域幅に換算することはできません。
結果が-1またはタイムアウトの場合、ノードは完全に使えなくなったのでしょうか？
負の値やタイムアウトは通常、そのテストで有効な結果を取得できなかったことを示します。具体的な表示方法はバージョンによって異なり、「負の遅延」を意味するわけではありません。テスト先にアクセスできるか、コアが正常に起動したかを確認してから、同じノードを再測定してください。複数のノードが同時に失敗する場合は、共通のテスト先、ローカルネットワーク、待ち受けポートを優先して確認します。
ノード選びは、まず利用可否、次に安定性を確認
普段のブラウジングでは、実接続テストが繰り返し失敗するノードを除外し、複数回のテストで応答速度やばらつきを比較します。大容量ファイルの転送が必要なら、ダウンロード速度の継続的な測定結果も確認してください。1つの項目が優れているノードが、あらゆる用途に適しているとは限りません。すべてのネットワークやWebサイトに共通して「合格」と判断できる遅延のしきい値もありません。
- Web閲覧・操作：実際のWebサイトにアクセスできること、接続成功率が安定していること、複数回の実接続遅延に大きなばらつきがないことを重視します。
- 継続的なダウンロード：利用できるノードの中から、同じ測定用データで安定した転送速度を比較し、通信量にも注意します。
- 問題の再現：テスト時刻、ネットワーク、対象URL、エラーの種類、ルーティング結果を記録します。サブスクリプションURLや認証情報は公開しないでください。
3種類のテストは、確認範囲を段階的に広げるものと考えると分かりやすくなります。Tcpingでは入口を確認し、実接続ではプロキシ経由のリクエストを確認し、ダウンロード速度測定では継続的な転送を確認します。最後に実際のアプリで動作を確かめることで、「一覧に数値が表示される」状態から「現在の使い方で実際に利用できる」状態まで確認できます。接続方法やルーティング設定を確認する場合は、ルーティング設定ガイドをご覧ください。サブスクリプションを更新できない場合は、サブスクリプションのトラブルシューティングをご確認ください。