Shadowrocketのサーバー選び方|遅延テスト・地域・プロトコルの確認方法

登録済みのサブスクリプションからサーバーを選ぶ際は、遅延テスト、地域、プロトコルを確認しましょう。遅延値が低くても、Webページが速く表示されるとは限りません。

この記事の概要

この記事は、Shadowrocketに自分のサブスクリプションを追加済みの方を対象にしています。サーバー選びでは、同じ方法でテストして応答しない候補を除外し、利用するサービスに必要な地域やプロトコル設定、実際のアクセス状況を踏まえて判断します。最小のミリ秒値だけで切り替えるのではなく、再現可能なテスト記録を作る方法を解説します。利用者自身がサービス事業者とサブスクリプションを用意していることを前提とし、サービスの入手先選びは扱いません。

1. テスト対象と実際の接続先を確認する

Homeで選択中のサーバー、Global Routingの現在のモード、Config内のルールは、実際の通信の出口に影響します。リスト上でサーバーのテストに成功しても、Webページへの通信がそのサーバーを経由するとは限りません。特にConfigモードでは、対象ドメインがDIRECTに一致することがあります。その場合、ページの表示速度でサーバーを評価すると、テスト対象と異なる結果になります。

テストを始める前に、大容量ファイルの転送を一時停止し、同じWi-Fiまたはモバイル通信に接続した状態で測定します。ネットワークを切り替えながら2台のサーバーを比較すると、無線の電波状況、通信事業者の経路、サーバー自体の影響を切り分けられません。

  1. リストを確認

    Homeを開き、自分のサブスクリプションが展開され、サーバー一覧が表示されていることを確認します。サブスクリプションを更新した直後は、項目名と設定をあらためて確認してください。以前の項目が同じサーバーを指しているとは限りません。

  2. モードを固定

    Home → Global Routingを開きます。ルールの影響を切り分けるには、一時的にProxyを選択し、テスト後にConfigなど元の設定へ戻します。Directはプロキシサーバー経由のWebアクセス確認には使えません。Sceneの動作は、選択中のシーンに応じて確認してください。

  3. テストを実行

    Homeに戻り、Connectivity Testを実行します。使用したテスト方法を記録してください。ICMP、TCP、HTTPでは結果の意味が異なるため、異なる方法で得たミリ秒値を並べて順位付けしないでください。

  4. 候補ごとに確認

    候補のサーバーを1つ選んで接続し、決めておいたWebページにアクセスします。同じ操作をほかの候補でも行い、接続の成否、タイムアウト、初回表示までの時間、読み込み中の状態を記録します。

  5. 設定を戻す

    比較が終わったら、普段使っているGlobal Routingモードに戻し、そのモードで対象サービスを再度開きます。結果が変わった場合は、サーバーを次々に切り替える前に、ルールの一致状況とポリシーを確認してください。

2. 遅延値で分かること・分からないこと

遅延値は、特定の時点で特定の探査が完了するまでの時間です。帯域幅やWebページ全体の読み込み時間を示すものではありません。ICMPは主にネットワーク層の応答を確認しますが、サーバー側でこの種のパケットが制限される場合があります。TCPテストは指定ポートへの接続確立の状況を確認します。HTTPテストはテスト先のURL、アプリケーション層の応答、選択したテスト経路にも左右されます。数値を比較するには、テスト方法を明確にそろえる必要があります。

リストのテスト記録

接続ネットワーク
同じWi-Fiを使い、テスト中はモバイル通信に切り替えない
テスト方法
同じ方法に統一し、異なる結果を混ぜない
測定回数
候補ごとに連続して3回測定し、失敗も記録する
確認ポイント
継続して成功するか、結果の変動が大きくないか

3回という回数は操作上の目安であり、アプリで固定されたテスト回数ではありません。

実際のアクセス記録

ルーティングモード
DIRECTルールの影響を切り分けるため、一時的にProxyを使用
アクセス先
各回で同じWebページまたは同じリソースを使う
確認項目
初回表示、読み込みの継続、中断の有無
再テストの時間帯
普段使う時間帯にも再度測定する

Webページのキャッシュや接続の再利用で結果は変わります。2回目の表示速度だけを比べないでください。

たとえば、ある測定記録で候補AのTCP結果が45、48、210 ms、候補Bが85、88、86 msだったとします。この1回の測定から分かるのは、Bの応答がより安定していたということだけで、Bのダウンロード速度が必ず速いという意味ではありません。これは数値の読み方を示す例であり、本サイトが特定のサーバーを測定した結果ではありません。AでWebページの読み込みも頻繁に止まるなら、候補から一時的に外す判断材料が増えます。

3. 距離だけでなく、出口の用途で地域を選ぶ

サーバー名に表示される地域は設定上のラベルであり、出口の場所を独立して証明するものではありません。接続先アドレスの所在地、通信経路、アクセス先サイトが判定する出口IPの地域は、それぞれ異なる場合があります。物理的な距離が近いほど伝送時間を抑えられる傾向はありますが、迂回経路、ネットワーク間の接続、混雑によって利点が相殺されることもあります。

利用するサービスに地域条件がある場合は、そのサービスが実際に判定した地域とアクセス結果を基準にしてください。アカウントの地域設定、位置情報の許可、過去のセッション、接続先サイトのデータベースもページ内容に影響することがあります。トップページの表示言語が変わっただけで、ネットワークの出口が切り替わったと判断しないでください。

4. プロトコルは名称で速度を決めず、互換条件を確認する

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは、接続方式や必要な設定が異なります。プロトコル名だけで速度は決まりません。サーバーの構成、転送方式、接続ネットワークで該当する通信が許可されているか、必要な設定がそろっているかが、利用可否により直接影響します。登録済みのサブスクリプションには通常これらの設定が含まれているため、まずは値を変えずに動作を確認してください。

6種類
この記事で扱うプロトコル:Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard
443
HTTPSでよく使われるポートです。サーバーの接続ポートは自分の設定を確認してください。
UDP
Hysteria2はQUICベース、WireGuardはUDPを使用するため、ネットワークで許可されているか確認してください。

Trojanは通常TLSを使用します。VMessとVLESSは、実際の転送方式やTLS設定を構成と合わせて確認してください。プロトコル名だけでは判断できません。Hysteria2の利用可否はUDP経路に左右されます。WireGuardでは、鍵、ピア、アドレスの設定も正しく行う必要があります。TCPテストだけではUDPプロトコルのセッションが利用できると証明できず、プロトコル認証の代わりにもなりません。

5. よくある症状を層ごとに確認する

トラブル対処では、まず接続ネットワーク、次にサーバーへの到達性、その後にプロトコル接続と接続先サービスを確認します。一度に変更するのは1項目だけにし、変更後は同じ対象を再テストしてください。地域やプロトコルを変え、サブスクリプションを更新し、ルールまで同時に変更すると、アクセスが復旧しても、どの操作が有効だったのか分からなくなります。

遅延は低いのに、Webページの読み込みが終わらないのはなぜですか?

Home → Global Routingで一時的にProxyを選び、対象のサーバーを選択して元のWebページを再テストします。それでも失敗する場合は、プロトコル認証、TLS設定、接続先サービスへの到達性を確認してください。復旧した場合は、Configに戻り、ルールとポリシーを確認します。テスト後は元のルーティングモードに戻してください。

同じサーバーなのに、自宅では使えてモバイル通信では使えないのはなぜですか?

Wi-Fiとモバイル通信で同じテストを実行し、使用したプロトコルも記録します。Hysteria2またはWireGuardを使用している場合は、UDP経路が制限されていないかを重点的に確認してください。また、システム設定でShadowrocketのモバイルデータ通信が許可されているかも確認しましょう。1回のタイムアウトだけでサーバー側の障害と判断しないでください。

サブスクリプションを更新したら、以前選んでいた項目が変わったのはなぜですか?

Homeに戻り、更新後のリストを確認して候補を選び直し、Type、サーバーアドレス、ポートを確認します。サブスクリプションの内容が更新され、名称が変わったりサーバーが置き換わったりすることがあります。以前のテスト記録をそのまま当てはめないでください。サブスクリプションの完全なURLや認証情報を公開のトラブル対処記録に載せないでください。

サーバーを切り替えたのに、接続先のWebサイトが変わらないように見えるのはなぜですか?

まずGlobal RoutingがDirectになっていないことを確認し、Configで対象の通信がDIRECTになるルールに一致していないか確認します。その後、開いているWebページのセッションを終了してから再アクセスしてください。接続が自動で復帰する場合や、切り替えの影響を受ける場合は、Settings → On Demandで既存の自動接続条件を確認し、自動動作と手動テストを混同しないようにします。

6. 再利用できる選定記録を残す

最終的に選ぶサーバーは、接続先サービスを利用できること、実際のアクセスが安定していること、普段のネットワークでも同じ結果を再現できることの3条件を満たす必要があります。最小遅延は候補を絞る目安にはなりますが、それだけを基準にしないでください。普段使う候補と、動作確認済みの予備候補を1つずつ残しておくと便利です。障害が起きたら、まず再テストしてから切り替え、短時間の変動を恒久的な傾向と決めつけないようにしましょう。

  1. 接続ネットワーク、テスト時間帯、テスト方法、候補項目、3回分の測定結果を記録し、失敗も残します。
  2. 出口の用途を満たすか、決めておいたWebページを開けるか、読み込み中に停止しないかを記録します。パスワード、鍵、サブスクリプションの完全なURLは記録しないでください。
  3. サブスクリプションの更新後や接続ネットワークの変更後は再確認し、以前の項目の速度ランキングを使い回さないでください。
  4. 一時的なテストが終わったら、Configなど普段の設定に戻し、対象の通信に想定したポリシーが適用されていることを確認します。
App Storeの正規配信ページ 開発者名とアプリIDを確認