Shadowrocket ノードの選び方：遅延テスト・地域・プロトコルの見方と、遅延値だけでは実際の快適さを判断できない理由

まず遅延値が測定しているものを理解する

Shadowrocketのノード一覧に表示される遅延値は、主に接続を確立できるか、1回の往復におおよそどれだけかかるかを素早く確認するためのものです。初期選別には役立ちますが、ダウンロード速度、動画のバッファリング、ページの完全な読み込み時間、長時間接続の安定性を単独で示すものではありません。テスト先、現在のネットワーク、DNS解決、プロトコルのハンドシェイク、サーバーの負荷によって結果は変わります。

遅延は通常msで表示され、数値が小さいほどそのテストを速く完了したことを示します。たとえば40 msは約0.04秒、180 msは約0.18秒です。ただし、ページを開く際には1回の往復だけで終わりません。DNS問い合わせ、TCP接続、TLSハンドシェイク、リクエスト送信、リソースのダウンロードなど、複数回の通信が発生します。そのため、2つのノードの差が十数ms程度なら、体感上の安定した違いになるとは限りません。

より有用なのは、ある1回の最低値ではなく、複数回の結果が近いかどうかです。たとえばノードAが42、47、190 ms、ノードBが71、74、79 msだった場合、Aは最低値こそ低いものの変動が大きく、操作時にはBのほうが一貫した結果になりやすいでしょう。これらは判断方法の例であり、特定の地域やプロトコルの決まった性能を示すものではありません。

決まった手順で既存ノードを絞り込む

選別時は条件をそろえる必要があります。テスト中は同じ端末、同じWi-Fiまたはモバイルネットワークを使い、できるだけ近い時間帯に実施してください。データの半分が自宅Wi-Fi、残りがモバイルネットワークでは、接続方式、電波強度、通信事業者の経路差が混ざり、公平に比較できません。

1. 設定の取得元を確認する

   Homeで、既存のノードが自分の設定に由来するものか確認します。Subscribeで管理する場合は、Home右上の「+」→ Type → Subscribeを選び、例としてhttps://example.com/sub?token=xxxxのようなアドレスを入力します。保存後、設定方法に従って更新してください。

2. ローカルネットワークを固定する

   進行中の大容量転送を停止し、端末を同じWi-Fiアクセスポイントまたは同じモバイルネットワークに接続したままにします。テスト途中で接続を切り替えないでください。

3. 3回テストする

   Homeのノード一覧で遅延テストを使い、候補を少なくとも3回連続してテストします。成功、timeout、最低値、最高値を記録してください。

4. 明らかな異常を除外する

   まずテストを連続して完了できない候補を外し、次に変動が数倍に及ぶものや、数十msから数百msへ頻繁に跳ね上がるものを記録します。

5. 実際の用途で切り替えて確認する

   残った候補を1つずつ選択して接続し、同じウェブページ、同じ動画、または同じ管理対象ファイルを使って短時間検証します。Global Routingは同時に変更しないでください。

6. 時間帯を変えて再テストする

   普段利用する時間帯にもう一度テストします。昼間安定していても夜間に安定するとは限りません。時間帯をまたいだ結果は、1回だけの最低遅延より参考になります。

記録に複雑なツールは必要ありません。「ノード名、地域、プロトコル、3回分の遅延、timeoutの有無、ウェブページの初回表示、継続転送」といった列を持つ表で十分です。遅延が近い場合は、複数回の結果が安定し、実際の作業でエラーが少ない項目を優先して残します。

地域間の距離は一つの変数にすぎない

他の条件が近い場合、地理的距離が短いほど通信経路も短くなる可能性があります。ただし、ノード名に含まれる地域ラベルだけでは、実際の経路を完全には説明できません。データは異なる国際出口、中継ネットワーク、混雑ポイントを経由することがあり、近隣地域と表示された2つのノードでも、まったく異なる経路を通る場合があります。

地域を選ぶときは、まず用途が応答時間に敏感かを確認します。ウェブ閲覧、リモート操作、リアルタイムのリクエストでは往復遅延とジッターが重要です。連続したコンテンツの視聴や大容量ファイルの転送では、継続スループット、パケットロスからの回復、長時間接続の安定性が重視されます。前者は大きな遅延差を感じやすく、後者は「遅延は最低ではないが継続速度が安定している」ノードのほうが良い場合があります。

主な用途で特定地域向けのコンテンツにアクセスする必要がある場合は、サービス自体の地域ポリシーも考慮します。遅延が最も低い地域でも目的のサービスの利用条件を満たすとは限らず、地域条件を満たすノードが最低遅延とは限りません。まず必要な地域を決め、その地域にある手元の候補の中で安定性を比較してください。

• 近隣地域：低遅延候補として適していますが、夜間の変動も確認してください。
• 遠い地域：基本遅延は高くなる可能性があるため、安定性と実際の用途との適合性を重点的に確認します。
• 同じ地域の複数ノード：最低値だけで残さず、3回分の変動と実際の成功率を個別に記録します。
• 名前が似たノード：名前が同じ基盤回線を証明するわけではないため、テスト結果は個別に記録します。

プロトコルの種類でテスト結果は変わる

Shadowrocketはさまざまなプロトコルと転送方式の組み合わせに対応しています。プロトコル名からはカプセル化や接続方式の一部が分かりますが、速度を単独で決めるものではありません。同じプロトコルでも、異なるサーバー、ポート、ネットワーク経路に配置されれば結果は大きく変わります。一方、品質の良い同じ経路であれば、異なるプロトコルでも日常利用に十分な場合があります。

Shadowsocksは比較的シンプルな構成です。VMessとVLESSは、実際の性能が下位の転送方式や暗号化設定の影響を受けます。Trojanは通常TLSと組み合わせます。Hysteria2はUDPベースの転送特性を重視し、WireGuardもUDPベースのトンネルプロトコルです。UDPは一部のネットワークで良好に動作しますが、制限やパケットロスが目立つ環境では影響を受ける可能性があります。HTTPS通信ではTCP 443が一般的で、HTTP/3や一部のUDP方式ではUDP 443が使われることがあります。ただし、実際のポートはユーザーの手元の設定によって決まります。

プロトコルの選別で「特定の種類が必ず最速」という固定的な結論を出すべきではありません。ユーザーの既存設定から、地域と負荷条件が近い候補を選び、それぞれ遅延と実際の作業をテストするのが正しい方法です。あるUDPプロトコルがWi-Fiでは安定し、モバイルネットワークでは頻繁に失敗する場合は、一般的な結論に広げず、ネットワーク環境の違いとして記録します。

テスト記録の例
ネットワーク：同じWi-Fi
Global Routing：Config
候補A：VLESS、68 / 72 / 70 ms、ウェブページの初回表示は安定
候補B：Trojan、55 / 160 / 59 ms、ときどき停止
候補C：Hysteria2、83 / 81 / 85 ms、継続転送は安定

結論：用途に応じてAとCを残し、Bは別の時間帯に再テストする。

Global Routingが一致しないと結果が歪む

ノードをテストするときは、Global Routingを必ず統一します。Configはルールを順番に照合し、Proxyはトラフィックを現在のプロキシ経由に統一し、Directは直接接続し、Sceneは設定済みのシーンに従って実行します。AのテストではConfig、BのテストではProxyに切り替えると、異なる処理経路を通る可能性があり、直接比較できません。

Configを使う場合は、ルールによってテスト対象がDIRECTに割り当てられていないかも確認します。ルールは設定順に照合され、DOMAIN-SUFFIXはドメインのサフィックス、GEOIPはIPの所属地域、IP-CIDRはネットワーク範囲、FINALはそれまでに一致しなかったトラフィックを処理します。テスト対象のリソースがDIRECTに一致した場合、観測しているのは選択したノードの性能ではありません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

上の例では、example.comは先にPROXYに一致し、ローカルネットワークの範囲はDIRECTを通り、その後GEOIPが条件に合うアドレスを処理し、残りのトラフィックをFINALに渡します。ルールは上から下へ照合されるため、より具体的なルールは、それを覆う可能性のある広いルールより前に置くのが一般的です。

低遅延でも快適とは限らない理由

遅延テストが対象とするのは、接続体験の一部だけです。実際のアクセスは、帯域幅の上限、サーバーの同時接続負荷、経路上のパケットロス、ジッター、再送、DNS応答、対象サービスの処理時間にも左右されます。短いテストでは素早く応答するノードでも、継続転送時に混雑で速度が低下することがあります。一方、基本遅延が高くてもスループットが安定するノードもあります。

よくある現象には、ノード一覧では50 msなのに動画再生後に頻繁にバッファリングする、遅延は100 ms前後でもウェブページは安定して読み込める、初回テストは正常でも夜間に同じ候補が数百msまで変動する、Wi-Fiでは正常なのにモバイルネットワークへ切り替えるとUDP接続の挙動が変わる、といったものがあります。いずれも層ごとに判断する必要があります。

DNSも「ノードが遅い」という錯覚を生むことがあります。ドメインの解決待ちはコンテンツ転送より前に発生するため、解決がタイムアウトしたり適切でない経路を返したりすると、ページの初回表示は遅くなりますが、遅延値は正常な場合があります。切り分けではDNS設定を変えず、まず複数の候補を比較してください。すべての候補で同時に似たドメイン初回表示の問題が起きるなら、設定内のDNS項目を個別に確認します。

ローカルネットワークも基本的な変数です。Wi-Fiの電波が弱い、アクセスポイントが混雑している、モバイル信号が頻繁に切り替わる、バックグラウンド同期が帯域を使っている、といった状況では、すべてのノードが一斉に遅くなります。複数の地域・複数のプロトコルで同時に高遅延が発生した場合は、ノードのパラメータを一つずつ変更する前に、Directの基準値とローカルネットワークを確認してください。

• 1回だけの最低遅延は初期選別に使い、最終判断には使わない。
• 3〜5回の変動は、1回だけの結果より重要です。
• ウェブ、動画、継続転送はそれぞれ個別に検証する。
• すべての候補で同時に異常が出たら、まずローカルネットワークとDNSを確認する。
• 特定のネットワークで特定のプロトコルだけに異常が出る場合は、TCP、UDP、ポートの条件を確認する。

On DemandとSubscribe更新後の再確認

Settings → On Demandは、ネットワーク条件に応じて接続動作を決めるための機能です。有効にすると、Wi-Fi名、ネットワークの種類、その他の条件によって接続または切断が発生することがあります。テスト中にネットワーク状態が変化してOn Demandが起動すると、現在の接続が再確立され、前後のデータが同じ条件でなくなる可能性があります。

正式なテスト前に、Settings → On Demandで既存のルールを確認し、現在のWi-Fiとモバイルネットワークでどのアクションが起きるかを確認できます。テスト中は条件を完全に固定するか、明確に固定した条件を一時的に使ってください。選択が終わったら、自動接続を元に戻し、想定どおり動作するか確認します。

Subscribeの更新によってノードが追加、削除、調整されるほか、名前や下位パラメータが変わることもあります。更新後は名前が同じように見えても、接続可能性と遅延を改めてテストしてください。複数の設定を自分で管理している場合は、現在どのConfigが有効かも確認し、別の設定でノードを選ばないようにします。

ShadowrocketはAppleプラットフォーム向けの有料商用アプリです。主な利用端末はiPhoneとiPadで、ストアの互換性欄にはMac、Apple TV、Apple Visionが記載される場合もあります。システム要件はApp Storeページの表示に従ってください。正規の入手先はApp Storeで、開発者はShadow Launch Technology Limited、アプリIDは932747118です。買い切りで得られるのはクライアント本体です。

再現可能な選択基準を作る

1回のテストで分かるのは、その時点の状態だけです。より信頼できる方法は、候補を少数残し、「主に使う地域、予備地域、TCP候補、UDP候補」と簡単にメモしておくことです。ネットワーク環境や利用場所が変わったら、対応する候補グループから再テストし、一覧全体を最初から調べ直す必要はありません。

2つのノードで3回の遅延、ページの初回表示、継続転送がいずれも近いなら、数msの差を追い続ける必要はありません。名前が分かりやすく、動作が安定し、更新後にも見分けやすい方を選べば十分です。頻繁に切り替えすぎると、DNSキャッシュ、接続の再利用、テスト時間帯が変わり続け、かえって比較の質が下がります。

1. 端末、ネットワーク、Global Routing、テストリソースを固定する。
2. 既存の候補について、少なくとも3回の遅延テストを実施する。
3. 連続するtimeoutと明らかに不安定な項目を除外する。
4. 必要な地域とプロトコルの条件で候補を絞る。
5. ウェブ操作と継続転送を分けて再テストする。
6. 普段使う時間帯にもう一度確認し、予備候補を記録する。

この手順を終えて得られるのは、永久に変わらない「最速ノード」ではなく、現在のネットワークと用途に適した選択肢のグループです。ネットワーク経路と負荷は変化するため、体感が明らかに変わったら、まずローカルネットワークの基準値から確認し、次にルール、DNS、プロトコル、ノードの状態を順に点検してください。