Shadowrocketのノード選び方｜遅延テスト・地域・プロトコルの確認方法と、低遅延でも快適とは限らない理由

ノードの提供元とテスト条件を確認する

Shadowrocketのノードは接続設定で、通常はサーバーアドレス、ポート、プロトコル、認証情報が含まれます。サブスクリプションを使うと設定をまとめて読み込め、更新によって変更内容を同期できます。ノード名はラベルにすぎず、サーバーの所在地や出口のIPアドレス、現在の負荷を示すものではありません。同じ名前でも、更新後に設定内容が変わっている場合があります。

比較を始める前に、Homeでサブスクリプションが読み込まれ、比較対象のノードが一覧に表示されていることを確認します。サービス提供元から設定変更の案内があった場合は、該当するサブスクリプションを更新し、反映結果を確認してください。テストの途中で更新すると、更新前後で異なるサーバー設定を測定する可能性があります。

1. 設定を確認

   Homeで登録済みのノードを確認します。初めて読み込む場合は、Homeの右上にある「+」→ Type → Subscribeを選び、自分のサブスクリプションURLを入力して保存します。読み込み後、ノードが一覧に表示されたことを確認してください。

2. ネットワークを固定

   Wi-Fiかモバイル通信のどちらか一方だけを使い、大容量ファイルの転送は一時停止します。Settings → On Demandを開いて現在の状態を記録し、テスト中にネットワーク条件の変化によって接続状態が自動で切り替わらないようにします。

3. テスト方法を統一

   Home → Connectivity Testで現在のテスト方法を確認します。すべての候補を同じ方法でテストしてください。画面上でテスト先を設定できる場合は、テスト先も統一します。

4. 繰り返し記録

   候補を少数に絞り、1つずつテストします。それぞれ最低3回、結果とテスト時刻を記録してください。タイムアウトも記録に残し、最も低かった数値だけを書き留めないようにします。

ノードのテストを行っても、通信がそのノードに切り替わったとは限りません。テスト後はHomeで候補を選び、接続状態を確認してください。すでに確立している長時間接続は、新しい経路にすぐ切り替わらないことがあります。実際の動作を確認するには、対象アプリを開き直すか、新しいリクエストを実行します。

遅延の数値で分かること・分からないこと

遅延は通常msで表示され、数値が小さいほど、そのテストで待ち時間が短かったことを示します。ただし、テスト方法によって確認する経路は異なります。TCPハンドシェイクでは主にサーバーのポートへの接続確立を確認します。プロキシ経由でテスト先にアクセスする場合は、プロトコルのハンドシェイク、テスト先の応答、関連する名前解決の処理も影響します。この2種類の数値をそのまま並べて比較することはできません。

たとえば、説明用の結果が「42、190、タイムアウト」の組と、「86、89、91」の組だったとします。前者は単発の数値が低い一方、後者はこの3回の記録では結果がより安定しています。これは記録方法を説明するための仮のデータで、実際の経路を測定した結果ではありません。長期的な品質を推測する根拠にもなりません。

遅延はスループットとは異なります。短いテストリクエストがすぐ完了しても、継続的な通信は帯域幅、混雑、パケット損失、サーバーの処理能力に左右されます。反対に、遅延がやや大きい経路でも、安定して読み込みが続く場合があります。msをダウンロード速度と混同せず、短時間のテストだけで動画を途切れずに再生できるかを判断しないでください。

地域で絞り込む：距離だけでなく利用先を確認

地域は候補を絞る条件の一つですが、地理的な距離がネットワーク経路の長さを示すとは限りません。端末から入口まで、サービス内部での転送、出口から対象サイトまででは、それぞれ経路が異なります。ノード名の地域は出口を示しており、端末が最初に接続するサーバーの所在地とは異なる場合もあります。

利用先サービスは、アカウントの地域、端末の位置情報、支払い情報、既存のセッションなども参照する場合があります。ノードの切り替えで変わるのはネットワーク条件の一部にすぎず、サービスの利用可能範囲が変わるとは限りません。ページに以前と同じ状態が表示される場合は、リクエストが実際に新しいノードを経由しているかを確認し、利用先サービスのルールも確認してください。判断が混乱するほど頻繁に切り替えるのは避けましょう。

プロトコルで絞り込む：まず互換条件を確認

プロトコル名が示すのは接続の確立方法であり、性能のランクではありません。同じプロトコルでも、サーバーやネットワーク経路が異なれば結果は変わります。同じサーバーで複数のプロトコルが提供されている場合もあります。比較では、できるだけ他の条件をそろえましょう。地域、サーバー、プロトコルを同時に変更したときの変化を、すべてプロトコルの違いに結びつけることはできません。

ポート番号は接続設定の一部にすぎません。たとえば、設定に443とあっても、それだけでノードのプロトコル、TLSの有効化、現在のネットワークからの接続可否は判断できません。テストを通すためだけに元のポートを安易に443へ変更しないでください。サーバーがそのポートで対応するサービスを実際に提供している必要があります。

遅延が低いのに開けない：Global Routingを確認

ノードのテストに成功したということは、そのテストが完了したことを示すだけです。実際のアクセスには、Global Routing、現在の設定ルール、DNS、利用先サービスの状態も影響します。通信がDirectを通っていたり、ルールで別のポリシーが指定されていたりする場合、測定したノードの遅延だけでは実際のアクセス状況を説明できません。

Sceneを使っている場合は、該当するシーンの設定と実際の適用状態も確認してください。シーンの切り替えをノード自体の変更と混同しないようにします。比較中はGlobal Routingの設定を固定し、テスト後に戻す設定も記録してください。

• DOMAIN-SUFFIX,example.com,PROXY：例のドメイン末尾に一致した場合、PROXYポリシーを使用します。
• IP-CIDR,192.168.0.0/16,DIRECT：例のプライベートアドレス範囲ではDIRECTを使用します。
• GEOIP,CN,DIRECT：GEOIPの判定結果に基づいて一致します。ノード名から地域を判断するものではありません。
• FINAL,PROXY：前のルールに一致しない場合はPROXYを使用します。ルールは順番に確認してください。

上記はルールを説明するための例であり、既存の設定を置き換える指示ではありません。特定のドメインだけにアクセスできない場合は、そのリクエストに適用されるポリシーと名前解決の結果をまず確認します。どの候補でも同じ対象にアクセスできない場合は、すべてのノードが使えないとすぐに判断せず、利用先自体の状態も確認してください。

テスト結果を整理して、メインと予備を決める

一次選定後は候補を少数に絞り、実際の利用手順に沿って確認します。対象ページを開き、次の階層へ進み、数分間操作を続けてください。動画やファイル転送を比較する場合は、画質やファイルなどの条件をそろえ、通信量にも注意します。キャッシュが使われると2回目の表示が大幅に速くなることがあるため、2回目の読み込みだけでノードが改善したと判断しないでください。

1. メインを選ぶ：普段使うネットワークと時間帯で、対象へ最後までアクセスでき、繰り返しの結果が安定する候補を優先します。単発で最も低いmsを追い求めないでください。
2. 予備を残す：登録済みのサブスクリプションから、同じ確認を通過した候補をもう1つ残します。名前が異なっても、基盤となる経路が別とは限りません。別の経路かどうかは、利用中のサービス情報で確認してください。
3. ネットワークを変えて再テスト：Wi-Fiでの順位をモバイル通信にもそのまま当てはめることはできません。ネットワークを切り替えたら、短いテストと対象へのアクセスをやり直してください。
4. 変更後に再確認：サブスクリプションの更新、設定の切り替え、サービスパラメータの変更後は、選択中のノードとGlobal Routingの状態をもう一度確認してください。

記録は簡潔で構いません。ネットワークの種類、時刻、ノード名、プロトコル、3回分の遅延、対象が最後まで読み込めたかを記録します。候補が夜間だけ頻繁に失敗する場合、「快適」「不便」とだけ書くより、その条件を記録したほうが次の判断に役立ちます。