Shadowrocketの遅延テストの見方｜地域・プロトコル別に既存サーバーを選ぶ方法

遅延値が示すもの：まず測定対象を確認

遅延は通常、ミリ秒（ms）で表示され、値が小さいほど、そのテストで測定したやり取りにかかる時間が短いことを示します。ただし、最初にテスト方式を確認してください。TCP接続の確立にかかる時間と、プロキシ経由でHTTPリクエストを送る時間では、測定範囲が異なります。ICMPの往復時間も、プロキシ経由のリクエスト時間と同じではありません。テスト方式が不明な場合、一覧の数値をすべてPingと呼ぶのは適切ではありません。

TCP接続の確立に成功しても、その時点で該当のアドレスとポートに接続できたことが分かるだけです。プロトコル認証、TLSハンドシェイク、Webページへのリクエストまで成功するとは限りません。HTTPテストの結果には、テスト先、DNS、TLS、サーバーの応答も影響します。実際のリクエストに近いテストほど参考になりますが、結果が示すのはそのときのリクエストだけです。

• 遅延：1回の通信で応答を待つ時間に注目します。初回応答の確認に適しています。
• スループット：一定時間に転送できるデータ量を示し、通常はMbpsやMB/sで表します。msから換算することはできません。
• ばらつき：同じ条件で結果が安定しているかを確認します。1回の最小値より、繰り返し測定した結果のほうが参考になります。
• タイムアウト：制限時間内にテストが完了しなかったことを示します。ネットワーク、ポート、プロトコル設定、テスト先などが原因として考えられ、サーバーの故障だけを意味するものではありません。

条件をそろえてからHomeで既存サーバーをテスト

有効に比較するには、サーバー以外の条件をできるだけそろえます。同じiPhoneまたはiPad、同じネットワーク、同じテスト先、同じテスト方式で測定してください。Wi-Fiとモバイル通信では外部への経路が大きく異なる場合があります。ネットワークを切り替えたら再測定し、前の順位をそのまま使わないでください。

1. 既存の設定を確認する

   Homeで既存のサーバーを確認します。手動で追加する場合は、Homeの右上にある「+」からAdd Serverを開き、手元にある情報に従ってType、アドレス、ポートを入力します。既存のサブスクリプションは先に更新し、変更前のアドレスをテストしないようにしてください。

2. 接続環境を固定する

   Wi-Fiかモバイル通信のどちらか一方を使い、大容量通信を伴うほかのタスクは一時停止します。Settings → On Demandを確認し、現在の状態を記録してください。自動再接続によって測定条件が変わるのを防ぐため一時的に無効にする場合は、元の設定を記録し、測定後に戻します。

3. 候補を1台ずつ選んでテスト

   Homeに戻り、候補のサーバーを1台ずつ選択してConnectivity Testで接続を確認します。画面に表示された結果、テスト方式、時刻を記録してください。1回接続できたからといって、すべてのWebサイトにアクセスできる証明にはなりません。

4. 3回繰り返す

   各候補を同じ方式で3回測定します。たとえば約10秒間隔で実施してください。最小値だけでなく、すべての結果を記録します。タイムアウトが発生した場合も記録し、説明なしに平均値から除外しないでください。

5. 実際のリクエストを確認する

   Home → Global Routingで接続モードを確認します。ルールの影響を一時的に切り分けるには、Proxyを使って選択したサーバーを確認し、同じページにアクセスします。終了後は元のConfigなどの設定に戻し、リクエストが実際にそのサーバーを経由したことを確認してください。

Global RoutingのDirectではリクエストが直接接続されるため、プロキシサーバー経由のアクセス性能を確認できません。Configは現在の設定に従ってリクエストを処理するため、DIRECTに振り分けられる場合があります。Sceneも設定したシーンに従って処理されるため、現在有効な条件の確認が必要です。つまり、「Webページが速い」ことと「選択したサーバーが速い」ことは、必ずしも同じではありません。

地域とプロトコルの選び方：経路を確認してから結果を比較

地域名は候補を分類する目安になりますが、通常はサービス情報に記載された名称であり、実際のデータセンターの所在地を確認したものではありません。また、入口から出口までの経路を示すものでもありません。地理的に近ければ伝送時間を短縮できる場合がありますが、通信事業者間の接続、迂回、混雑によってその利点が相殺されることもあります。地域名だけで順位を付けず、現在のネットワークで測定した結果を比べてください。

プロトコル名は接続方式を示すもので、速度のランクではありません。Shadowsocks、VMess、VLESS、Trojanの実際の性能は、伝送方式、暗号化、TLS、サーバー設定にも左右されます。名称だけで速さを判断することはできません。Hysteria2はQUICをベースとしており、UDPが利用可能かどうかが関係します。WireGuardもUDPを使用しますが、トンネルの仕組みは異なるため、同じテスト対象として扱うことはできません。

• まずTypeを確認：Add ServerのTypeは、手元のサービス情報と一致させてください。数値を下げるためにプロトコルを勝手に変更しないでください。
• 次にパラメータを確認：ポート、認証情報、TLSの設定を一致させます。443はポート番号にすぎず、それだけでプロトコルがTrojanだと判断したり、接続成功を保証したりすることはできません。
• 伝送方式を区別：UDPを使う設定では、同じアドレスのTCPポートを個別に調べても、実際のプロトコルが使える証明にはなりません。プロトコル接続と実際のリクエストを合わせて確認してください。
• 条件の違いに注意：地域もプロトコルも異なる2つの結果を選択の参考にはできますが、「プロトコル自体が速い」と結論づけることはできません。

3回の測定結果の見方：最小値より安定性を重視

以下の数値は記録方法を説明するための仮定データであり、本サイトでの実測値ではありません。特定の地域やプロトコルの性能を示すものでもありません。比較では、まず接続できたかを確認し、次に中央値とばらつきを見ます。最後に実際のページ表示や継続的なデータ転送も検証してください。

3回の測定は一次選別にすぎず、長期的なパケットロス率を信頼性高く算出するには不十分です。Aがときどき速く、Bが安定しているなら、Webページの操作はBのほうがスムーズな場合があります。実際のアクセス結果が異なる場合は、再現性のある実作業の結果を優先してください。どのネットワークにも共通する固定の遅延基準値を、合格ラインとして使わないでください。

低遅延なのにWebページが遅い場合：リクエストの経路を確認

Webページを開くときには、複数回の通信が発生します。DNSの問い合わせ、接続の確立、TLSハンドシェイク、メイン文書や複数のリソースへのリクエストが待ち時間に加わります。リソースによっては異なるドメインから読み込まれます。遅延テストの接続先への応答が速くても、Webサイトの名前解決、出口までの経路、サーバーの応答も速いとは限りません。大容量ファイルのダウンロードでは、継続的な帯域幅、混雑、パケットロスの影響がより大きくなります。

1. リクエストの経路を確認。Home → Global Routingで現在の接続モードを確認します。Configを使う場合は、Homeで選択したサーバーだけでなく、Configで有効になっているファイルを確認してください。
2. ルールの適用先を確認。たとえばDOMAIN-SUFFIX,example.com,DIRECTは該当ドメインへの接続をDIRECTに振り分けます。FINAL,PROXYが処理するのは、それより前のルールに一致しなかったリクエストだけです。ルールは上から順に適用されるため、選択中のサーバーを切り替えても、適用済みのDIRECTポリシーは変わりません。
3. 初回表示とキャッシュを区別。初回の読み込みにはDNSやTLSの処理が含まれる場合があります。2回目以降はキャッシュを使ったり、接続を再利用したりすることがあります。比較するときはそれぞれを分けて記録し、一方の接続の初回表示と、もう一方のキャッシュ読み込みを比べないでください。
4. 設定をむやみに変更せず、別のタスクも試す。まず同じページを確認し、次に自分がアクセスできる別の接続先を試します。問題が特定のサイトだけで起きる場合は、接続先までの経路やサイト側の応答を優先して確認し、ポート、DNS、プロトコルを同時に変更しないでください。
5. 時間帯を変えてネットワークを再確認。短時間のテストでは正常でも、継続的なデータ転送の速度が徐々に落ちる場合は、同じ環境で時間を置いて再測定し、混雑する時間帯だけに発生するか記録してください。

ルールのGEOIPとIP-CIDRはIPアドレスに基づく振り分けに使うもので、サーバーまでの距離や速度を測るものではありません。設定に特定の地域条件があっても、選択したサーバーの出口所在地を証明することはできません。問題を調べるときは、「ルールが通信先をどう決めるか」と「経路の実際の品質」を分けて確認してください。

よくある質問：タイムアウト、更新、自動切り替え

最終的な選択手順は、設定が正しいこと、実際に使えること、繰り返し測定して安定していること、目的のタスクに合っていることを確認し、最後に数msの差を比べることです。この記事では、ユーザーがすでに持っている設定のテスト方法と使い方を説明しています。クライアントの購入条件と、利用中のサービスの利用条件はそれぞれ確認してください。