Shadowrocketのノード選び方｜遅延テスト・地域・プロトコルを解説

1. テスト対象と現在のルーティングを確認する

ノードとは、既存の設定に含まれる接続先のことで、通常はサーバーアドレス、ポート、プロトコル、認証情報などで構成されます。サブスクリプションは、これらの項目を更新するための情報源です。ノード名に含まれる地域、倍率、用途などはラベルであり、クライアントによる実測結果ではありません。サブスクリプションの更新後はアドレスやパラメータが変わることがあるため、比較前にリストの更新が完了していることを確認し、利用可能な設定を復旧用に残しておきましょう。

以下では、iPhone / iPad版のHome、Config、Settings画面を例に説明します。他のプラットフォームでは画面構成が異なる場合があるため、ボタンの位置をそのまま当てはめないでください。テスト時は「どのノードを選択したか」と「リクエストが実際にどのルールを通ったか」を分けて考える必要があります。Global RoutingがDirectの場合、通常の閲覧で選択中のプロキシノードは使われません。Configを使用している場合は、現在の設定にあるルールによってリクエストの経路が決まります。

• Proxy：プロキシ経由の通信をまとめてテストするモードです。適用されるルールが自動選択された別の項目ではなく、テスト対象のノードを指していることも確認してください。
• Direct：現在のネットワークから直接接続します。選択中のプロキシノードの実際の通信状況を確認する用途には使えません。
• Config：現在のConfigに設定されたルールで通信を振り分けます。DIRECT、REJECT、その他のルールによって、テスト対象サイトへの経路が変わる場合があります。
• Scene：設定済みのシーンに従って動作します。結果を比較する前に、シーンで使用しているルーティングと設定を確認してください。

2. Connectivity Testの数値の見方

Connectivity Testは、Webページの読み込み全体を測るテストでも、継続的なダウンロード速度を測るテストでもありません。結果はテスト方式、テスト先、現在のネットワークによって変わります。TCP系のテストでは主に接続確立までの時間が示され、HTTP系ではプロキシとのネゴシエーション、TLS、接続先からの応答なども関係する場合があります。ここでいう「接続確立の速さ」は、短時間の接続性テストを簡潔に表したもので、アプリを開いた後に発生するすべての待ち時間を意味するわけではありません。

一度だけミリ秒の値が小さくても、そのテストが速く完了したことを示すにすぎません。Mbpsに換算できるわけではなく、動画の連続再生、ファイルのダウンロード、長時間接続の安定性を保証するものでもありません。一方、Timeoutは制限時間内にテストが完了しなかったことを示します。テスト先、ネットワーク経路、ポート、設定パラメータなどが原因として考えられ、これだけでサーバーが恒久的に使えないと判断することはできません。

• 比較前にテスト方式とテスト先を統一します。TCPとHTTPの数値を同じランキングに並べて比較しないでください。
• 候補ごとに少なくとも3回テストし、最速値だけでなく、中央値、ばらつき、タイムアウト回数を記録します。
• システムアップデート、クラウド同期、大容量ファイルの転送を一時停止し、端末のバックグラウンド通信が上り・下り回線を圧迫しないようにします。
• テストに使ったWi-Fiまたはモバイルネットワークを記録します。接続ネットワークを切り替えた後は、以前の順位を過去の記録として扱ってください。

3. 既存のリストから候補を絞る5つの手順

まず接続性を確認し、その後に実際の用途でテストします。ノードを切り替えるたびにDNS、ルール、プロトコルのパラメータまで変更すると、結果が変わっても原因を特定できません。以下の手順では候補を2つ残せば十分です。サブスクリプション内のすべての項目について、長時間のダウンロードテストを行う必要はありません。

1. リストを確認する

   Homeを開き、利用中のサブスクリプションの更新が完了していることを確認します。テストする項目のサーバーアドレス、ポート、プロトコルが正しく設定されているか確認してください。同じ名前の項目がある場合は接続パラメータで見分け、名前だけで同じ経路だと判断しないようにします。

2. 条件を固定する

   同じWi-Fiまたはモバイルネットワークを使い続け、Home → Global Routingで現在の選択を記録します。テスト中はConfigを切り替えないでください。Settings → On Demandを有効にしている場合は、テスト中に接続状態が変わらないよう、接続ルールを事前に確認します。

3. 繰り返しテストする

   HomeでConnectivity Testを開き、同じテスト方式で3回実行します。結果が連続して得られ、ばらつきの少ない項目を優先し、Timeoutの回数も記録してください。一度の失敗だけを理由に削除しないようにします。

4. 実際の接続を確認する

   Homeで候補を選び、接続スイッチをオンにして、同じWebサイトで動作を確認します。必要に応じて一時的にGlobal Routing → Proxyに切り替え、適用されるルールが候補のノードを指していることを確認してください。最初の画面、その後のページ、実際に使うサービスが正常に動作するか記録します。

5. ルール設定を戻す

   テスト後はGlobal RoutingとOn Demandを元の設定に戻します。現在のネットワークで利用できることを確認した予備の項目を残し、ネットワークの変更後やサブスクリプションの更新後に再確認してください。今日の結果を長期的な順位として扱わないようにします。

4. 地域は利用するサービスと接続ネットワークを基準に判断する

地理的な距離は、通信経路に影響する要素の一つにすぎません。端末からサーバーまでの間には、異なる通信事業者間の接続、入口での中継、混雑した経路などが含まれることがあり、近い地域として表示されていても遅延が短いとは限りません。サーバー名に記載された地域が、最終的な出口IPの所在地と一致するとも限りません。利用するサービスが地域を判定する際は、IPアドレスのデータベースに加え、アカウントの地域や端末の設定を参照する場合があります。

利用するサービスで特定の地域が必要な場合は、まず条件に合う既存の項目を選び、その中で安定性を比較します。テスト値を小さくするために、サービスで必要な地域条件を無視しないでください。アカウントを使うサービスでは、テスト中に地域を頻繁に切り替えると追加認証が発生することがあるため、避けるのが無難です。

5. プロトコルの種類で決まること、決まらないこと

プロトコル名は接続や通信の仕組みを表すもので、速度のランクではありません。まず利用中のサーバーが求めるプロトコルとパラメータを満たし、そのうえで接続ネットワークが該当する通信方式に対応しているか確認します。クライアント側の種類を別の名前に変更しても、サーバーが自動的に対応するわけではありません。特に認証情報、TLS、トランスポート層、サーバーポートは既存の設定と一致させる必要があります。

ポート番号だけでプロトコルを特定することはできません。たとえばTCP 443とUDP 443は、異なる通信の入口です。「443」と表示されているだけでTrojanだと断定したり、ネットワークが必ず通信を許可すると判断したりすることはできません。使用するポートは利用中の設定に従ってください。遅延を下げるためにむやみに変更したり、証明書エラーを無視するために検証を無効にしたりしないでください。

6. ルールや自動接続による誤判定を防ぐ

よくある誤解の一つは「ノードを切り替えたのにWebページの表示が変わらない」というものです。Configモードでは、対象のドメインにDIRECTが適用されていたり、別のポリシーグループが指定されていたりするため、表示が変わらないことがあります。ルールは通常、設定された順に照合されます。DOMAIN-SUFFIXはドメインの末尾、IP-CIDRはアドレス範囲で照合し、GEOIPはIPアドレスの地域情報を使って判定します。FINALは他のルールに該当しない場合に適用されます。ノードを選択しても、すべてのルールが上書きされるわけではありません。

特定のWebサイトだけが開けない場合は、そのサイトに適用されるルール、DNSの結果、サービス自体の状態を確認します。すべての候補で同時に問題が起きる場合は、まずローカルネットワーク、サブスクリプションのパラメータ、現在の接続状態を確認してください。設定を一度にすべてリセットするのではなく、一度に一つだけ変更して結果を記録すると、再現可能なトラブルシューティングの手掛かりを残せます。詳しい手順は接続トラブルの対処ガイドをご覧ください。

7. 遅延テストと実際の利用に関するよくある質問

選ぶ順番は「用途の条件に合う」「接続できる」「繰り返しテストして安定している」「実際の用途で問題がない」です。遅延値は候補を絞る目安の一つであり、最終的な判断材料ではありません。