Shadowrocketでノードを選ぶ際は、まず接続できることを確認し、複数回のテストで安定性を比較したうえで、実際のWebサイトや動画で確かめます。利用中のサービスとサブスクリプションがある方向けに、Home → Connectivity Test の結果の見方、地域やプロトコルの確認方法、設定を変更せずに普段使い用と予備用の候補を残す方法を解説します。
1. 遅延・スループット・実際の使いやすさを区別する
遅延が低いということは、あるテストで応答が速かったことを示します。データ転送が継続して速いとは限りません。スループットは単位時間あたりに転送できるデータ量です。実際の使いやすさには、接続の成否、目的のサービスにアクセスできるか、長時間の接続が途切れないかも関わります。これらは関連しますが、同じ指標ではありません。ノードを選ぶ際、SERVER リストで最小の数値だけを見て決めないようにしましょう。
Home から Connectivity Test を開き、テスト方法を確認します。結果を見る前に、テスト方法と対象を確認してください。TCP 接続テストでは、サーバーの指定ポートへの接続確立を主に確認します。プロキシ経由で HTTP または HTTPS の接続先にアクセスするテストでは、プロキシのハンドシェイク、名前解決、接続先からの応答も影響する場合があります。テスト方法によって確認できる経路が異なるため、結果をそのまま並べて比較するのは適切ではありません。選択できる項目はアプリ内の英語表示を確認してください。
サーバーのポートは、サービス提供元の指定と一致させてください。元の設定が 8443 の場合、「速くする」ために 443 へ変更してはいけません。ポート番号は速度の段階ではありません。テストに成功しても、そのテストで確認した範囲が正常だったことを示すだけで、動画再生やアップロード、すべてのWebサイトへのアクセスを保証するものではありません。
結論：テストを安定して完了できる候補を残す
テスト方法と対象を固定し、3回続けて確認します。まず頻繁にタイムアウトする候補を除き、残った候補で同じ実際の接続先にアクセスして比較しましょう。1回の最小値だけで決めないでください。
2. 順序を決めてテストし、ネットワークの変化とノードの差を混同しない
一度に変更する条件は1つだけにします。デバイス、利用中のネットワーク、テスト方法、接続先を固定してからノードを切り替えてください。Wi-Fiでの結果とモバイル通信での結果を直接比較したり、大容量ファイルをダウンロードしながらテスト値で回線品質を判断したりしないでください。一括テストは候補の絞り込みに使えます。候補が決まったら、1つずつ再テストすると一時的な変動を見分けやすくなります。
- リストの内容を確認します。Home の SERVER 欄で、利用中のサブスクリプションに含まれる項目を探し、名前と所属グループを確認します。サービス提供元が設定を変更している場合は、比較を始める前に該当するサブスクリプションを更新してください。
- テスト条件を固定します。Home → Connectivity Test で同じテスト方法を使います。テスト中は同じWi-Fiまたはモバイル通信を利用し、ほかのデバイスで大容量の通信を行わないようにします。
- 3回測定して記録します。応答値、タイムアウトの有無、テスト時刻、ネットワークの種類を各回記録します。測定の間隔を少し空け、最も良かった1回だけを記録しないようにしてください。
- 候補を選んでから接続します。現在選択している項目を確認し、Home → Global Routing も確認してください。ポリシーグループを使っている場合は、グループ内で実際に選ばれている項目も確認します。リスト上の選択だけを変更し、対象の通信が別の出口を使ったままにならないようにしてください。
- 実際の使い方で確認します。同じWebページで初回読み込みと再読み込みを確認し、同じ動画・画質で再生開始、シーク、連続再生の状態を見ます。接続の再利用による影響を避けるため、古いテスト接続を切断してから確認してください。
以下は記録方法を示す仮の例であり、実測結果や性能を保証するものではありません。候補Aは3回の結果が 42 / 260 / タイムアウト、候補Bは 88 / 91 / 89 ms だったとします。Aは最小値こそ小さいものの、変動が大きくなっています。Bのほうが実際の用途で確認する候補として適しています。3回の測定は初期選別に使えるだけで、長期的なパケット損失率の算出や、別の時間帯での同じ結果を保証するものではありません。
3. 地域名は手がかり。アクセス経路全体を確認する
地域間の距離は伝搬遅延に影響しますが、デバイスから入口サーバー、入口から出口、出口から接続先のWebサイトまでの経路はそれぞれ異なります。ノード名に含まれる地域名は、通常、提供元が付けた目印です。名前だけで実際の入口や出口の場所、中継経路を判断することはできません。物理的な距離が近くても、迂回や相互接続の混雑、サーバー負荷によって遅くなることがあります。
地域を比較する前に、用途を明確にしましょう。Web操作やリモート操作では応答待ちを感じやすく、長時間の動画視聴ではデータを安定して供給できるかがより重要です。接続先のサービスが出口のIPアドレスに応じてコンテンツ配信サーバーを選ぶ場合もあり、同じ候補でもWebサイトによって体感が異なることがあります。「サーバーまで速い」ことを「接続先のWebサイトまで速い」ことと同一視しないでください。
確認方法：実際の用途に応じて候補を残す
Web閲覧・インタラクティブな操作
- 同じページを使い、初回表示と繰り返し操作を比較します。
- 最低遅延だけでなく、応答が安定しているかを優先して確認します。
- ログイン後のリダイレクト、画像の読み込み、送信リクエストが正常に完了するかを確認します。
動画・継続的なデータ転送
- 画質を固定し、自動画質調整によって差が見えにくくならないようにします。
- 再生開始、シーク、連続再生がそれぞれ途切れないか確認します。
- 普段使う時間帯にも再テストし、混雑が繰り返し発生するか記録します。
地域情報は候補を絞る手がかりです。最終的には、現在のネットワークから実際の接続先までの経路全体で判断します。
Wi-Fi、モバイル通信、利用場所の都市が変わると、以前の順位が入れ替わることがあります。すでに候補がある場合、毎日すべて選び直す必要はありません。体感の変化が続くときに、同じ手順で再テストしてください。一時的な最小値を頻繁に追うより、検証済みの予備を1つ残しておくほうが、問題の切り分けに役立ちます。
4. プロトコルは対応条件で確認し、名称だけで速度を比べない
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは、接続の仕組みやパラメータが異なります。正常に動作するには、まずサーバー側とクライアント側の設定が一致している必要があり、次に現在のネットワークが各通信方式に対応しているかが関わります。プロトコル名だけで「高速」や「低遅延」が保証されるわけではありません。また、既存項目の Type を変更しても、別のプロトコルとして使えるようにはなりません。
| プロトコル | 把握しておきたい特性 | 比較前に確認する項目 |
|---|---|---|
| Shadowsocks | 設定で指定された暗号化方式と認証情報を使用します。 | サーバーアドレス、ポート、暗号化方式、パスワードが一致しているか。 |
| VMess / VLESS | 複数のトランスポート方式やセキュリティ設定を組み合わせられます。プロトコル名だけでは接続経路全体を把握できません。 | 認証パラメータ、トランスポート方式、サーバーが求めるTLSなどの設定。 |
| Trojan | 通常、TLSを使って接続します。 | パスワード、サーバー名、証明書の検証が元の設定と一致しているか。 |
| Hysteria2 | QUICベースで、UDPで通信できることが前提です。 | 現在のネットワークで該当するUDP通信が許可されているか、認証パラメータが一致しているか。 |
| WireGuard | UDPを使用し、鍵とトンネルのパラメータで通信を確立します。 | 鍵、接続先アドレス、トンネルのパラメータがすべて一致しているか。 |
たとえば、利用中のWi-FiでUDPが制限されていると、UDPに依存する候補は正常に接続できないことがあります。しかし、すべてのネットワークでそのプロトコルが遅いという意味ではありません。逆に、TCP接続テストに成功しても、UDPを使う通信が正常とは限りません。1つのテスト結果だけであらゆるプロトコルを評価せず、実際の用途で確認してください。
- プロトコルを比較するときは、出口の地域、テスト対象、テスト時刻をできるだけそろえます。サーバーの違いによる差が、プロトコルの違いより大きい場合があります。
- サブスクリプションで指定された元のパラメータを維持し、テストを通すために証明書の検証を無効にしないでください。
- 問題の記録を共有する際は、パスワード、鍵、認証パラメータ、サブスクリプションの完全なURLを伏せ、必要なプロトコル名と現象だけを記載します。
5. Global Routingを確認し、選択したノード以外を測定していないか確認する
ノードを切り替えてもWebサイトの表示がまったく変わらない場合、まずルーティングを確認します。Home → Global Routing では、全体の通信処理方法を設定します。速度の段階を示すものではありません。Config ページのルールやポリシーによっても、対象のリクエストが実際にどの出口を使うかが決まります。対象の通信が候補を経由していると確認できて初めて、テスト結果を比較できます。
Config
おすすめ現在有効な設定のルールに従って通信を処理します。ルールに一致した後の動作は、指定されたポリシーによって決まります。先行するルールに一致しなかったリクエストは、後続のルールまたは FINAL によって処理されるため、すべてが直接接続になるわけではありません。
適した用途：ルールとポリシーの振り分け先を確認したうえでの日常利用
Proxy
全体の通信をプロキシ経由で処理します。ルールによる振り分けの影響を一時的に減らす用途に使えますが、実際に選択されているプロキシと接続の成否を確認してください。
適した用途：ルールによって接続経路が変わっているかを短時間確認する
Direct
全体の通信を直接接続で処理します。この状態での接続先へのアクセス結果は、選択中のプロキシノードの評価には使えません。現在のネットワークから接続先へ直接アクセスできるかを確認する用途に使えます。
適した用途：直接接続との比較。ノードの速度テストには不向き
Scene を使用している場合は、実際に適用されるシーンの設定を確認してください。シーン名だけで接続先が固定されるわけではありません。Settings → On Demand を有効にしている場合は、テスト中にオンデマンド接続が接続状態を変えていないかも確認します。重要なのは条件をそろえることで、速度測定のために日常設定を恒久的に変更することではありません。
結論：ノードの切り替え後、経路を確認してから差を判断する
Global Routing、ルールのポリシー、現在選択中のプロキシを確認してから、接続先への接続をやり直します。比較のため一時的に Proxy に変更した場合は、終了後に普段の設定へ戻してください。
6. 遅延は低いのにWebや動画が遅い場合の確認手順
テスト値と実際の体感に差がある場合、まず「最初から遅い」のか「しばらく通信すると遅くなる」のかを区別します。前者は名前解決、ハンドシェイク、接続先からの応答、ルーティングに関係する可能性があります。後者では、継続的なスループット、混雑、接続の安定性を確認するとよいでしょう。次の順に調べると、不要な変更を減らせます。
- テストは速いのに、実際の接続先はすべて遅い：まずテスト方法がサーバーへの接続確立だけを確認していないか調べ、Global Routing と実際の出口を確認します。バックグラウンド通信を一時停止し、検証済みの別候補と比較してください。
- 特定のWebサイトだけ遅い：別の接続先でもテストし、そのサイト自体の応答、コンテンツ配信経路、アクセス制限の影響を切り分けます。1つのサイトの問題だけで、ノード全体が使えないと判断しないでください。
- 動画はすぐ再生されるのに、その後何度もバッファリングする：画質を固定して状態を確認します。短時間のハンドシェイクが速くても、継続的なスループットが十分とは限りません。時間帯をそろえて予備候補と比較すると、判断しやすくなります。
- 夜間だけ遅く、ほかの時間帯は正常：同じ接続先を異なる時間帯に確認し、共有回線の混雑や負荷の変化を考慮します。混雑時間帯に一度遅かっただけで、プロトコルのパラメータを変更しないでください。
- すべての候補が同時にタイムアウトする：まずデバイスのネットワークが正常か確認し、サブスクリプションが更新されているか、サービスの設定に変更がないかを確認します。複数の候補が同時に使えない場合は、共通する原因を優先して調べてください。
問題を報告するときは、デバイスのネットワークの種類、プロトコル名、テスト方法、発生した時間帯、特定の接続先だけで起きるか、別候補での結果を記録します。実際の認証情報は公開しないでください。最低遅延のスクリーンショットだけを共有するより、こうした記録のほうが、ローカルネットワーク、サービス設定、接続先の問題を切り分けやすくなります。