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

1. 遅延の数値でわかるのは応答の速さ。帯域幅の上限ではない

遅延テストでは、何らかのプローブを送信して応答を受け取るまでの時間を測定し、通常はmsで表示します。テスト方法によって測定する経路は異なります。TCPハンドシェイクでは、サーバーのアドレスとポートが速やかに応答するかを確認します。プロキシ経由でテスト先にアクセスする場合は、プロキシとの接続、接続先アドレスの名前解決、接続先サーバーの応答時間も影響します。まずテスト方法を確認してから数値を比較しましょう。異なる方法の結果を同じ順位表に並べてはいけません。

HomeでConnectivity Testを使うときは、候補ごとに同じテスト方法と接続先を使います。現在の画面でテスト方法を選べる場合は、同じ設定のままにしてください。リストに表示されるのは一度のテスト結果であり、その後のすべての通信を保証するものではありません。タイムアウトは今回のテストが制限時間内に完了しなかったことを示すだけで、一度の結果だけでサブスクリプションが無効になったとは判断できません。

低遅延なら、短いやり取りが速くなる可能性があります。一方、ダウンロードを続ける場合は、利用可能な帯域幅、パケットロス、混雑、サーバー負荷、接続先の速度制限なども影響します。たとえば、応答が速い候補でも共有出口が混雑していれば、ページの最初の画面はすぐ表示されても、大きなファイルの転送速度が低いままになることがあります。反対に、応答は多少遅くても安定して転送できる候補のほうが、動画のバッファリングやファイル転送に適している場合があります。

2. テスト条件をそろえてからHomeで候補を選ぶ

遅延を比較するために、現在使えている設定を維持し、サブスクリプションの更新、ルールの変更、ネットワークの切り替えを同時に行わないでください。Homeではサーバーの選択と接続、Configでは設定ファイル、Settingsでは関連設定を管理します。それぞれを分けて確認すれば、使い心地の変化がノード選択によるものか、振り分けや自動接続の条件によるものかを判断しやすくなります。

1. サブスクリプションを確認

   Homeで、利用中のサブスクリプションのグループとサーバー項目を確認します。まだ追加していない場合は、Home → 右上の「+」→ Type → Subscribeの順に進み、サービス提供元から入手したサブスクリプションURLを入力して保存します。まず一度更新し、テスト中はグループを何度も更新しないでください。

2. ネットワークを固定

   まずは同じWi-Fiで一通りテストし、ほかのデバイスによる大容量通信を一時停止します。Settings → On Demandで設定済みの接続条件を確認してください。手動での切断や再接続に影響する場合は、元の設定を記録したうえでテスト中だけ無効にし、終了後に元へ戻します。

3. ルーティング条件をそろえる

   Home → Global Routingで現在の設定を記録します。短時間の条件をそろえた比較では、Config内の直連ルールの影響を抑えるためにProxyを選べます。テスト後は元の設定に戻してください。Directで直結された通信の速度を、選択中のノードによるものと判断しないでください。

4. 繰り返しテスト

   Home → Connectivity Testで候補を同じ方法でテストし、少し間を空けて3回繰り返します。成功回数と数値のばらつきを記録し、応答が続けて得られる候補を2〜3個残します。毎回サブスクリプション全体をテストする必要はありません。

5. 実際の通信を確認

   Homeで候補を選んで接続し、同じWebサイトと同じファイルで再テストします。切り替え後はテスト用の接続を新たに確立してください。必要に応じてShadowrocketを再接続し、以前の経路を使い続ける古い長時間接続を避けます。最後にConfigへ戻り、普段のルールでの使い心地を確認します。

3. 地域は用途から選び、実際の出口を確認する

ノード名に含まれる地域名は、通常、サブスクリプションの提供元が付けたものです。入口、出口、または特定の経路の用途を示している場合があり、デバイスから接続先Webサイトまでの実際の経路と一致するとは限りません。物理的な距離が近いほど伝搬遅延を抑えやすいものの、ネットワーク間の接続、迂回、混雑によって結果は変わります。同じ地域の2つの経路でも、性能に大きな差が出ることがあります。

Webサイトに通常見えるのはリクエストの出口アドレスですが、地域の判定にはアカウント情報、デバイスの権限、過去のセッション、アドレスデータベースなども使われることがあります。ノードを切り替えても、Webサイトの地域判定がすぐに変わるとは限りません。地域判定に問題がある場合は、まずリクエストが想定したポリシーを通っているか確認し、出口アドレスの問題とWebサイト側の判定を切り分けましょう。原因がわからないまま切り替えを繰り返すのは避けてください。

4. プロトコルはネットワーク環境に合わせて選ぶ。名称だけで速度を比べない

プロトコルはクライアントとサーバー間の通信方式を定めますが、それだけで回線品質が決まるわけではありません。Shadowsocks、VMess、VLESSの実際の性能は、伝送方式や関連パラメーターにも左右されます。TrojanはTLS接続で使われることが多く、Hysteria2はQUICをベースとしているため、UDP経路に依存します。WireGuardもUDPを使ってトンネルを構成します。サーバー、地域、負荷が異なる結果を、プロトコルの優劣だけに結び付けないでください。

ポートはサーバー側の設定と一致させてください。たとえば、設定にTCP 443と記載されている場合はそのポートでテストします。TLSでよく使われるという理由だけで、別の値に変更してはいけません。UDP 443とTCP 443は別の通信エンドポイントです。一方が使えても、もう一方が使えるとは限りません。テスト結果の数値を下げるために、ポートを適当に変更したり、証明書の検証を無効にしたり、認証情報を書き換えたりしないでください。

同じサービス提供元の異なるプロトコルの項目でも、入口、出口、負荷が共通でない場合は、別々の候補として全体を比較します。伝送方式が使い心地に与える影響を比べるには、サーバー、接続先、時間、ネットワークをできるだけそろえる必要があります。あるプロトコルに対応していることは接続できるという意味であり、その回線の性能を保証するものではありません。

5. 記録方法を統一し、遅延・ばらつき・スループットを見分ける

一度に比べる候補は2〜3個にし、まず続けてテストした後、普段使う時間帯に再確認することをおすすめします。以下の設定カードは手書き用の記録テンプレートで、Shadowrocketに読み込める設定ファイルではありません。時間やテスト回数は、この手順で条件をそろえるためのものであり、アプリの制限ではありません。

たとえば候補Aのテスト結果が42、45、310 ms、候補Bが78、81、80 msだったとします。これは選び方を説明するための例であり、実際の回線を測定した結果ではありません。この記録ではAの最低値のほうが小さい一方、ばらつきは大きく、Bのほうが安定しています。次に実際のリクエストでも確認してください。3回のテストだけで一日を通した安定性を判断したり、応答時間の差をダウンロード速度に換算したりすることはできません。

• Web閲覧：初回表示、再表示、画像の読み込みが一緒に遅くなるか確認します。キャッシュで差がわかりにくくなることがあります。
• 動画視聴：画質を同じにしてバッファリングや中断を確認します。プレーヤーが画質を自動で下げた後の再生の滑らかさは、同じ条件での比較になりません。
• ファイル転送：ファイルと配布元を固定し、MB/sとMbpsを区別します。10進単位では1 MB/sは8 Mbpsに相当します。
• インタラクティブな通信：変動や断続的な遅延に注目します。対象のサービスがUDPを使う場合は、UDP経路も実際に確認してください。

6. よくある問題は、ノードを変える前に通信経路を確認

Proxyでは正常で、Configに戻すと問題が起きる場合は、ノードを選び直す前にルールの経路を確認してください。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはアドレス範囲、GEOIPはIPアドレスの地理情報に基づいて照合します。FINALは、それ以前のルールに一致しなかったリクエストを処理します。ルールの順序、DNSの結果、ポリシーグループの選択は、最終的な出口に影響する場合があります。Configで現在有効な設定を確認し、リクエストの記録から適用されたルールを特定してください。

7. メイン候補と予備候補を残し、条件をそろえて再確認

選択の目的は、常に最小のmsを記録することではなく、自分の利用環境で繰り返し確認できる経路を確保することです。メイン候補は、よく使うWebサイトに接続でき、操作が安定し、継続的な通信にも十分な性能があるものを選びます。予備候補は、できるだけメイン候補と異なる経路を選んでください。名前が違っても実際には同じ出口を使う項目では、有効な予備にならないことがあります。

• 普段の利用に戻るときは、Global RoutingとOn Demandを元の設定に戻し、テスト中の一時設定を残さないでください。
• 使い心地が継続して変化したとき、サブスクリプションの項目が更新されたとき、またはネットワーク環境が変わったときに再確認します。遅延が一度上がっただけですぐに切り替える必要はありません。
• 候補名、プロトコル、ネットワーク、テスト日時を記録し、前後の比較に役立つ情報を残します。
• 問題が発生したときは一度に変える条件を1つにします。まずネットワーク、次に候補を確認し、その後でプロトコルの設定とルールを確認してください。

設定の場所や操作を確認するには、使い方ガイドをご覧ください。用語がわからない場合は用語集を参照してください。まず実際のリクエスト経路を確認してから遅延、地域、プロトコルを調べると、リスト全体を何度も更新するより原因を特定しやすくなります。