Shadowrocketのレイテンシテストの見方｜地域・プロトコル別に既存ノードを選ぶ

1. レイテンシの数値が示すもの

レイテンシは通常 ms（ミリ秒）で表示されますが、数値の意味はテスト方法によって異なります。サーバーへの TCP 接続テストでは、主に指定したアドレスとポートへの接続にかかる時間を測定します。プロキシ経由で HTTP または HTTPS のテスト先にアクセスする場合は、プロキシのネゴシエーション、接続先への接続、応答待ち時間も含まれます。測定する経路が異なるため、同じ指標として順位付けすることはできません。

まず、アプリで現在選択されているテスト方法とテスト先を確認してから、ノードを比較します。サーバーのポートまでしか測定していない場合、数値が低くても、その区間の応答が速いことを示すだけで、対象サイトにアクセスできるとは限りません。プロキシ経由で指定先にアクセスするテストでも、その時点での対象先の状態を示すにとどまり、すべてのサイトや時間帯に当てはまるわけではありません。

タイムアウトしても、ノードが必ず使えないとは限りません。テスト先に到達できない、名前解決に失敗する、サーバーのポートが制限されている、プロトコルのハンドシェイクに失敗するなど、テストが完了しない原因はさまざまです。「ポートに接続できるか」「プロキシを確立できるか」「接続先から応答があるか」を分けて確認し、赤い結果ひとつですべての問題を判断しないようにしましょう。

2. 条件をそろえて、利用中のサブスクリプションをテスト

比較の前にサブスクリプションを更新し、使用中のネットワークを記録します。更新によってアドレス、ポート、ノード一覧が変わる場合があります。更新前と更新後の結果が混在すると、同じ設定の比較になりません。サブスクリプションのリンクはアクセス認証情報です。スクリーンショットや公開メモ、問い合わせ内容に載せないでください。

1. サブスクリプションを確認

   Home（ホーム）で自分のサブスクリプショングループを確認します。初めて追加する場合は、Home →「+」→ Type（タイプ）→ Subscribe（サブスクリプション）の順に進み、利用中のリンクを入力して保存します。すでに追加済みの場合、再登録は不要です。

2. 更新を完了

   Home で登録済みのサブスクリプションを更新し、一覧が最新になったことを確認します。更新に失敗した場合は、まずリンクへのアクセスや認証情報の問題を解決してください。古い一覧でのテスト結果を最新の状態として扱わないようにします。

3. 環境をそろえる

   同じ Wi-Fi またはモバイル通信を使い、大容量データの転送を一時停止します。Settings（設定）→ On Demand（オンデマンド）で自動接続の条件を確認し、テスト中にネットワークが切り替わって接続状態が変わらないようにします。

4. 繰り返し測定

   Home で候補ノードのレイテンシを測定し、テスト方法とテスト先を統一します。各候補を少し間隔を空けて3回ずつ測定し、タイムアウトも記録します。一括テストは候補の絞り込みに使い、数を絞った後に個別に再測定します。

5. 実際の接続を確認

   候補ノードを選択して接続し、Global Routing（グローバルルーティング）のモードを確認してから、同じテスト先のページを開きます。初回表示、続けて閲覧したとき、時間のかかるリクエストがそれぞれ正常か確認します。

3回の測定は統計的な保証ではありませんが、1回だけ測るより一時的な変動を見分けやすくなります。たとえば、ある候補が 48 / 51 / 49 ms、別の候補が 25 / タイムアウト / 180 ms なら、前者のほうが次の検証に進める候補として有望です。ここに示した数値は見方を説明する例であり、実測値や合格基準ではありません。

3. 地域で絞り込む：ノード名はあくまで手がかり

地域での絞り込みは、まず利用目的に合わせて行います。アクセス先が特定地域からの接続を求める場合は、出口の地域を確認してから同じ地域の候補を比較します。地域の指定がない場合は、安定性と実際のアクセス状況を優先して比べましょう。ノード名に含まれる地域名、旗、略称はサブスクリプションの提供内容にすぎず、サーバーの設置場所や最終的な出口の地域を証明するものではありません。

同じ地域のノードでも、入口や中継経路、出口が異なる場合があります。反対に、異なる地域名のノードでも、経路の一部を共有していることがあります。そのため、「近いほど必ず速い」「同じ地域なら同じ性能」という考え方は、選択の基準として適切ではありません。地域名だけでなく、ノード、使用したネットワーク、測定時刻を記録しましょう。

4. プロトコルで絞り込む：まず接続条件を確認

Shadowrocketで利用できるノードには、Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard などがあります。プロトコル名は接続方式を示すもので、レイテンシや帯域幅の順位を直接示すものではありません。同じプロトコルでも、サーバーやポート、ネットワーク経路によって性能は大きく異なります。特定のプロトコル名にこだわって、登録済みサブスクリプションの設定を書き換えないでください。

Hysteria2 は QUIC をベースに動作します。現在のネットワークで UDP が制限されている場合、同じ地域の別名のノードに切り替えても解決しないことがあります。WireGuard も UDP を利用しますが、ハンドシェイクとトンネルの仕組みが異なるため、TCP の接続時間だけで接続状態を判断できません。VMess や VLESS も Type の比較だけでは不十分で、トランスポート方式やサーバー設定を考慮する必要があります。

• 同じ地域のプロトコルを比較するときは、測定時刻とテスト先をできるだけそろえ、環境の変化を抑えます。
• プロトコル接続に失敗した場合は、まずサブスクリプションの更新状況、アドレス、ポート、認証パラメータを確認します。一度接続するために検証要件を下げないでください。
• ある Wi-Fi だけで特定の接続方式が失敗し、モバイル通信では正常な場合は、まずそのネットワークの通信制限を確認します。
• サブスクリプション内のノードのポート、TLS、トランスポート設定を一括で手動変更しないでください。これらの設定にはサーバー側の対応も必要です。

5. レイテンシは低いのに開けない：Global Routing とルールを確認

レイテンシテストに成功しても、実際の閲覧リクエストがテストしたノードを通っているとは限りません。Home → Global Routing の Proxy（プロキシ）、Direct（直接接続）、Config（設定）、Scene（シーン）がルーティング方法を決めます。通常の利用では、現在の Config による振り分けを使い、トラブルの切り分けではリクエストがどの経路を通ったかを明確にします。

Scene は状況に応じたルーティングに使用します。実際の動作は登録済みのシーン設定によって異なるため、名前だけで使用中の経路を判断できません。Scene が有効な場合は、テスト前に該当する設定を確認するか、元の設定を記録したうえで、トラブルの切り分けに適したモードに切り替えてください。

• Config（設定）で現在有効な設定を確認します。無効なファイルを見ているだけでは不十分です。
• DOMAIN-SUFFIX はドメインのサフィックスで照合します。GEOIP は IP の地理情報で照合し、IP-CIDR は IP アドレスの範囲で照合します。
• FINAL は、それ以前のルールに一致しなかった場合の最終的な行き先です。ルールの順序と参照先のポリシーも結果に影響します。
• 接続ログで接続先、適用されたルール、通信の行き先を確認します。接続先が DIRECT に振り分けられていた場合、そのページの表示結果でプロキシノードを評価することはできません。

6. 実際のリクエストで「応答の速さ」と「通信の安定性」を見分ける

低レイテンシは小さなリクエストを頻繁に行う場面では有利ですが、継続的なデータ転送は、利用可能な帯域幅、パケットロス、混雑、接続先サーバーの負荷にも左右されます。ハンドシェイクはすぐ完了しても、データ転送中に何度も待たされるノードもあります。一方、初回応答がやや遅くても、その後のリクエストを安定して完了できるノードもあります。用途に応じてそれぞれ確認し、異なる指標をひとつの数値にまとめないようにしましょう。

ブラウザーのキャッシュや接続の再利用も、体感速度に影響します。同じページを2回目に開いたとき速くなった場合、ノードの性能が向上したのではなく、キャッシュが使われた可能性があります。比較する際は、同じ内容と近いリクエスト条件を使いましょう。動画を再生したり、大量のファイルを同期したりしながら、レイテンシの変化だけでノードの優劣を判断しないでください。テスト自体も通信量を消費するため、利用中サービスの通信量制限も考慮します。

7. 再現できる選択結果を残す

最終的に残すのは、永久的な順位ではなく「特定のネットワークと用途で検証済みの候補」です。サブスクリプションの更新、サーバーの変更、ローカルネットワークの変化によって、以前の結果が当てはまらなくなることがあります。すべてのノードを頻繁にテストする必要はありません。問題が発生したときや、ネットワークまたはサブスクリプションが変わったときに、よく使う候補を少数再確認すれば十分です。

1. 条件を記録：Wi-Fi またはモバイル通信、テスト方法、テスト先、測定時刻を記録し、サブスクリプションの認証情報は公開しないでください。
2. 候補を記録：ノード名、地域ラベル、Type、更新状況を残し、名前の似た項目を取り違えないようにします。
3. 結果を記録：レイテンシ、タイムアウトの回数、実際のリクエスト状況をそれぞれ記録し、最小値だけを切り取らないでください。
4. ルーティングを記録：Global Routing のモードと、実際に適用されたポリシーを記録し、次回も同じ条件で検証できるようにします。
5. 予備を残す：利用中の設定から、テスト済みの代替候補を1つ残します。切り替えた後は、アクセス結果を改めて確認してください。