Shadowrocketのサーバーの選び方｜遅延テスト・地域・プロトコルの見方と注意点

1. 遅延の数値からわかること

一覧に表示されるミリ秒数は、テストにかかった時間を示します。その意味はテスト方法と測定先によって異なります。接続の確立だけを確認するテストと、プロキシ経由で宛先にリクエストを送るテストでは、対象となる通信経路が異なります。比較する前に、現在のConnectivity Testの方式を確認してください。方式や測定先を変えた場合、前後の数値をそのまま順位付けすることはできません。

接続の確立に成功しても、その後の認証、ドメイン名の解決、Webサイトへのアクセスまで成功したとは限りません。プロキシ経由のテストであっても、その時点で測定先まで通信できたことを示すだけです。Webページの表示には通常、複数のドメインへのリクエストや複数の接続、リソースのダウンロードが必要です。動画では、安定した転送速度やバッファリングの状態も大きく影響します。

たとえば、あるテストが40 ms、別のテストが90 msだった場合、まず言えるのは前者の所要時間がその回では短かったということだけです。数値の見方を示すための仮定例であり、実測性能ではありません。この結果だけで前者のダウンロード速度が速いとは判断できず、一度タイムアウトしただけでサーバーが恒久的に利用できないとも断定できません。

2. 条件をそろえて、普段使うサーバーを選ぶ

始める前に、現在利用できる設定を残し、サブスクリプションがすでに利用しているサービスから提供されたものか確認します。サブスクリプションを更新すると、サーバー一覧やパラメータが変わることがあります。更新直後の場合は、以前選択していた項目が残っているか確認してから比較してください。遅延の数値を下げるために、サーバーアドレス、ポート、認証情報をむやみに書き換えないでください。

1. ネットワークを固定する

   同じWi-Fi、または同じモバイルネットワーク接続のままテストし、途中で切り替えないようにします。大容量通信を行うほかのタスクを一時停止し、現在のテスト方式も記録してください。モバイルの電波状況やWi-Fiアクセスポイントが変わった場合は、新しい条件であらためて記録します。

2. モードを確認する

   Home → Global Routingを開き、現在のモードがConfig、Proxy、Direct、Sceneのどれか確認します。Configを使っている場合は、Configで実際に選択されている設定も確認してください。ルールによって通信が別のポリシーに振り分けられることがあります。

3. サーバーを選択する

   Homeに戻り、利用可能なサーバー一覧から候補を選択して、左側に選択マークが付いていることを確認します。設定内のポリシーグループで別のサーバーが指定されている場合、Homeでデフォルトサーバーを変更しても、対象の通信の出口が変わるとは限りません。

4. テストを実行する

   HomeのConnectivity Testを使います。条件を変えずに3回に分けて実行し、成功、タイムアウト、所要時間を記録します。この3回は確認手順の例であり、アプリで固定されたテスト回数ではありません。また、パケット損失率の測定とも異なります。

5. 実際のアクセス先で確認する

   接続スイッチをオンにし、初回利用時はシステムの案内に従ってVPN構成の追加を許可します。実際に利用するWebサイトやサービスにアクセスし、表示できるか、最初の画面が遅れないか、利用中に接続が途切れないかを記録します。同じ手順で次の候補も確認してください。

サーバーを選択した後、テスト結果と実際のアクセス状況が食い違う場合は、通信が本当にそのサーバーを経由しているか確認します。接続スイッチの状態、Global Routingの選択、Config内のルールやポリシーグループが通信経路に影響します。一覧の左側に選択マークがあるだけでは、すべてのリクエストがその項目を使っているとは限りません。

3. Global Routingによって比較条件が変わる

サーバーを比較する前に、ルーティングの状態を確認しましょう。Config、Proxy、Directはそれぞれ異なる通信処理の選択肢です。Sceneは現在のシーン設定も確認する必要があり、特定の出口を示す固定モードではありません。ここではShadowrocketにある設定項目だけを比較します。

4. 地域名とWebサイトが判定する地域は同じとは限らない

サブスクリプション内の項目にある地域名は、通常サービス提供元が付けた名称であり、選択時の手がかりにすぎません。アプリが地理的位置を独自に検証した結果ではありません。入口のアドレスがある場所、最終的な出口アドレスの場所、対象サービスが参照する地域データベースは、それぞれ異なる場合があります。複数の中継を経由する場合、入口の遅延が小さくても、最終出口が対象に近いとは限りません。

• 目的を明確にする。Webページの応答を安定させたい場合は、地域ラベルだけで選ばず、実際のページ読み込みを比較します。距離が近いほど通信距離は短くなる傾向がありますが、ネットワーク間の接続状況や混雑によって結果は変わります。
• 出口を確認する。対象サービスが表示する地域情報を確認し、サービス提供元の出口に関する説明とあわせて判断します。サブスクリプション名に含まれる都市名や国名を、出口の所在地が確認済みであることの証拠にしないでください。
• 地域とアカウントの条件を分けて考える。サービスによっては、アカウントの地域、コンテンツの利用権、その他の条件も確認します。地域ラベルを変えても、特定のコンテンツや機能を利用できるとは限りません。
• 同じ対象で比較する。ある候補でWebサイトAが快適に開いても、WebサイトBでも同じとは限りません。同じページを、近い時間帯に、キャッシュ条件をそろえて比較してください。

Wi-Fiでは使えても、モバイルネットワークに切り替えると状況が変わることがあります。必ずしも地域の選択が間違っているわけではありません。接続ネットワークの変化は、DNS、ルーティング、UDPの到達性に影響します。その場合はモバイルネットワークを別のテスト条件として扱い、Connectivity Testをあらためて実行してください。異なる条件の結果を同じ順位表に混ぜないようにしましょう。

5. プロトコルは条件の照合に使い、単純な順位付けには使わない

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは、それぞれ異なるプロトコルと設定要件を示す名称であり、速度のランクではありません。まずサーバー側とクライアント側のパラメータが一致しているかが、接続の可否を左右します。プロトコルが利用できても、実際のネットワーク、サーバーの負荷、接続先までの経路によって使い心地は変わります。

利用中のサブスクリプションに同じ地域の異なるプロトコルの項目がある場合は、候補として一つずつ確認できます。ただし、名称が似ていても同じサーバー、同じ出口、同じ負荷とは限りません。そのため、この比較はその時点で利用できる項目を選ぶ手助けにはなりますが、プロトコル自体の厳密な性能評価にはなりません。

速度を上げる目的で、項目のTypeを別のプロトコルに変更しないでください。クライアント側でタイプを切り替えても、サーバー側のプロトコルは自動で切り替わりません。元のポートや認証情報も使えるとは限りません。別のプロトコルを使う場合は、利用中のサービス提供元が実際に用意している対応設定を使ってください。

6. 遅延は小さいのに使いにくい場合の確認方法

遅延テストを何度も更新するより、まず「どの段階で失敗するか」を記録しましょう。接続の確立、ドメイン名の解決、ページの初回表示、リソースのダウンロード、長時間の動画再生は、それぞれ異なる段階です。テストに成功してもページが開かない場合は、問題の範囲を絞り込み、すべてを「サーバーが遅い」とまとめないようにしてください。

最終的に選ぶのは、目的に合い、繰り返しテストして利用でき、実際のアクセスも安定している項目です。特定の回で遅延が最小だった項目とは限りません。接続ネットワーク、候補名、プロトコル、Global Routing、テスト方式、実際の状況を簡単に記録しておくと便利です。サブスクリプションの更新後や接続ネットワークの変更後は、同じ手順で再確認してください。