Shadowrocketのノード選び方｜レイテンシ測定・接続先の地域・プロトコルと実際の使い心地

1. レイテンシの測定値が示す接続区間

レイテンシは通常ミリ秒（ms）で表示され、ある種の測定が完了するまでの時間を示します。これは短いやり取りにかかる時間であり、1秒あたりに転送できるデータ量ではありません。Shadowrocketの測定結果は、使用した測定方法とあわせて読み取る必要があります。同じ接続設定でも、測定方法や測定先、利用中のネットワークによって数値は変わることがあり、異なる条件の結果を一つのランキングに並べて比較することはできません。

たとえばTCP測定では、指定したサーバーのポートにTCP接続を確立するまでの時間が主に示されます。ポートに接続できても、プロトコル認証が成功するとは限らず、接続先から目的のWebサイトに正常にアクセスできることも保証されません。プロキシ経由のHTTP測定はより広い範囲を確認できますが、測定先のURL、DNS、TLSハンドシェイク、応答方法などの影響も受けます。測定項目の名前だけで、実際の通信経路全体を確認できると思い込まないようにしましょう。

タイムアウトしても、必ずしも「サーバーが停止している」という意味ではありません。測定先に到達できない、ポートの入力が誤っている、現在のネットワークが特定の通信方式を制限している、測定方法とプロトコルが合っていない、といった原因でもタイムアウトすることがあります。一方、レイテンシが非常に小さく表示されても、その測定が短時間で完了したことを示すだけです。実際に接続してアプリで確認する必要があります。

2. 測定条件を揃えて、手元の設定を比較する

まず、利用中のサブスクリプションがHomeに正しく読み込まれ、サーバーアドレス、ポート、プロトコルの各項目に不足がないことを確認します。サブスクリプションの更新は設定情報を同期するもので、サーバーの帯域を増やしたり、接続先Webサイトの制限を自動的に解消したりするものではありません。サービス提供元がアドレスや認証情報を変更した場合は、先に設定を更新してから比較してください。各回の測定の間に、サブスクリプションの更新、ネットワークの切り替え、ルールの変更を同時に行わないようにします。

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

   同じWi-Fiまたはモバイル通信を使い、帯域を消費する同期処理は一時停止します。測定中にネットワークを切り替えず、測定した時間帯も記録してください。

2. 設定を確認する

   Homeで手元にある設定を選び、編集画面でType、アドレス、ポートを確認します。たとえばサーバー側でTCP 443が指定されている場合、推測で8443に変更してはいけません。ポートは利用中のサービス提供元が指定した値に従ってください。

3. ルーティングを固定する

   Home → Global Routingを開き、現在の設定がConfigかProxyかを記録します。ルールの影響を切り分けるには、一時的にProxyにして比較できます。完了後は元の設定に戻してください。また、Settings → On Demandも確認し、自動接続の条件によって測定状態が変わらないようにします。

4. 測定を繰り返す

   HomeのConnectivity Testを使い、測定方法と測定先を揃えて候補ごとに3～5回測定します。タイムアウトの回数、代表的な所要時間、最も長かった時間を記録し、最小値だけを書き留めないようにしてください。

5. 実際の利用状況を確認する

   接続後、同じ目的のサービスにアクセスし、最初の表示、読み込みの継続、短時間のアイドル状態からの復帰を順に確認します。たとえば候補ごとに同じ5分間観察してから、次の設定に切り替えます。

以下は記録方法を示すための仮定データであり、製品の実測値でも、利用可能なサービスに対応するものでもありません。5回のうちタイムアウトが発生した場合は別に数え、平均値に0 msとして含めてはいけません。成功した測定値の中央値を使えば単発の異常値の影響を抑えられますが、失敗した記録もあわせて残してください。

3. 地域表示だけでは実際の経路や出口の性能は分からない

接続名に表示される地域は、通常、設定の提供元が入力したものです。入口、出口、サービスのグループなどを示している可能性があり、クライアントが物理的な場所を独自に確認した結果ではありません。通信経路には、ローカルネットワーク、接続事業者、入口サーバー、中継、出口、接続先サイトなどが含まれる場合があります。地理的に近い地域でも、経路が短いとは限りません。経路の迂回やネットワーク間の混雑によって、距離の利点が相殺されることもあります。

接続先アプリが出口IPアドレスで地域を判定する場合は、Homeの一覧名ではなく、アプリから見える実際の出口とサービス側の規則を基準にしてください。Webサイトはアカウントの地域、位置情報の許可、過去のセッションなども判定に使うことがあります。設定を切り替えても以前の地域が表示されるからといって、すぐにレイテンシ測定の誤りだと決めつけることはできません。そもそも、この二つは別の事柄です。

• 操作への応答：地理的な名称だけで判断せず、初回表示、検索、送信、連続タップへの反応を確認します。
• 継続的な転送：転送が維持されるか、頻繁に停止しないかを確認します。短い測定への応答が速くても、長時間接続で十分なスループットが得られるとは限りません。
• リアルタイム通信：往復時間だけでなく、ジッター、パケットロス、UDPの到達性も確認します。UDPが通らない場合、TCP測定に成功しても実際の通信が利用できるとは限りません。
• 地域限定サービス：対象サービスの提供地域とアカウント要件を確認し、通信が想定した出口を実際に通っているかも確かめます。

4. プロトコルの違いは接続条件に関わるもので、速度の順位ではない

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは接続の仕組みが異なりますが、プロトコル名だけでどの設定が速いかは判断できません。サーバーの場所や負荷、転送パラメーター、ローカルネットワーク、接続先までの経路などが結果に影響します。まず読み込んだ項目がサーバー側の指定と一致していることを確認してください。Typeだけを変更して、既存のサーバーを別のプロトコルに切り替えようとしないでください。

ポート番号だけではプロトコルの特性は分かりません。TCP 443とUDP 443は異なる通信プロトコルを使うため、数字が同じでも接続条件は別です。ネットワークでTCP 443が許可されていても、UDP 443にも到達できるとは限りません。Wi-Fiでは使えるのにモバイル通信では使えない設定がある場合は、元のパラメーターを維持したまま、ネットワークと通信条件をそれぞれ確認してください。ポートを適当に変更したり、TLS検証を無効にしたりしないでください。

5. Global Routingとルールによる誤判定を防ぐ

設定を選択したからといって、すべてのリクエストがその設定を使うとは限りません。Global Routingで全体のルーティング方針が決まります。Configの場合は、有効な設定ファイル、適用されるルール、ルールで指定されたポリシーも確認してください。あるドメインがDIRECTに一致している場合、プロキシ設定を変更しても、そのドメインの実際の経路は変わらないことがあります。

たとえば、以下の説明用コードではexample.comとそのサブドメインが先にDIRECTに一致し、それ以外のリクエストはFINALで指定されたPROXYに振り分けられます。例示のドメインは構文の説明に使うもので、測定用サービスでも利用可能な接続設定でもありません。

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

Configで現在有効なファイルを確認し、リクエストの記録と照らし合わせて適用ポリシーを確認します。ルールは上から順に評価されます。DOMAIN-SUFFIXのほか、GEOIPやIP-CIDRなどの条件も経路に影響することがあります。FINALは、それより前のルールに一致しなかった場合のフォールバックです。また、ポリシーが別の指定設定やポリシーグループを参照していないかも確認してください。リクエストが必ずHomeで現在選択中の項目を使うとは限りません。

6. よくある症状と次に確認すること

最終的には「目的のサービスを正常に使える → よく使うネットワークで安定する → 普段の時間帯でも再現する → レイテンシとスループットが要件を満たす」の順に候補を絞り込みます。問題が起きたら、ネットワークの種類、時刻、プロトコル、ルーティング設定、測定方法、エラーの状況を記録し、利用中のサービス提供元にサーバーの状態を確認してください。記録を共有する際は、パスワード、鍵、認証情報、サブスクリプションURL全体を隠し、認証情報が写った画面を公開しないようにします。