Shadowrocketのノード選び方｜遅延テスト・地域・プロトコルの確認ポイント

この記事の要点

Shadowrocketでノードを選ぶときは、まず接続できることを確認し、同じネットワーク・同じ方法で測定した結果を比較したうえで、実際に使うページへの接続を試します。利用者自身がサービス事業者とサブスクリプションを用意していることを前提に、遅延・地域・プロトコル・ルールがそれぞれ何に影響するかを説明します。「テスト値が低い」ことと「目的を問題なく達成できる」ことを区別するためのガイドです。

テスト条件をそろえてからノードを選ぶ

リスト内で最も小さいミリ秒値だけを見て結論を出さないでください。1回のテストで分かるのは、その時点の一連の接続状況であり、Webページの表示、継続的なダウンロード、アプリへのログインを確認する代わりにはなりません。まず接続ネットワークとテスト方法を固定し、既存のサブスクリプションから候補を2～3個選んで比較しましょう。すべての項目を頻繁に切り替えるより、原因を特定しやすくなります。

サブスクリプションを確認する

Homeでサブスクリプションとノードが読み込まれていることを確認します。再登録する場合は、Home → + → Type → Subscribeの順に開き、利用中のサービス事業者から取得したサブスクリプションURLを入力して保存し、更新します。サブスクリプションURLをサーバーアドレス欄に入力しないでください。
ネットワークを固定する

現在使用しているWi-Fiまたはモバイル通信を選び、ほかの端末で大容量通信を行っている場合は一時停止します。比較中に接続ネットワーク、テスト対象、ノードを同時に切り替えると、どの変更が結果に影響したのか判断できません。
ルーティングを確認する

Home → Global Routingを開き、現在の設定を記録します。選択したプロキシ接続を一時的に確認する場合はProxyを使い、普段のルールの動作はConfigで確認します。手動操作への影響を避けるため、調査中はSettings → On Demandも確認してください。
テストを繰り返す

HomeでConnectivity Testを開き、同じ方法で同じ候補を3回続けて測定します。候補を選択して接続を有効にしたら、同じ対象ページを開き、実際のリクエストが完了するか確認します。
設定を元に戻す

比較が終わったら、Global RoutingとOn Demandを元の設定に戻します。普段Configを使っている場合は、選択中の設定ファイルに戻ってルールを確認してください。一時的な調査用の設定をそのまま使い続けないようにしましょう。

遅延テストで測定している接続区間

遅延は通常msで表されますが、値の意味はテスト方法によって異なります。TCP接続テストでは、サーバーアドレスとポートへの接続可否を主に確認します。プロキシ経由でテスト用URLにアクセスする方法では、プロキシのハンドシェイク、DNS、TLS、接続先からの応答も関係する場合があります。測定範囲が異なるため、両者の値をそのまま比較して順位を付けることはできません。まず現在のConnectivity Testで使われている方法を確認してから、結果を読み取りましょう。

接続レベルのテスト

確認する対象: サーバーアドレスと設定されたポート
主に分かること: 接続できるかどうかと、そのときの待ち時間
確認できないこと: プロキシ認証の成功や、対象Webページへのアクセス可否
ポートの例: 443は設定値の一例であり、特定のプロトコルを示すものではありません

ポートはサブスクリプションの設定に従ってください。テストのために勝手に443へ変更しないでください。

リクエストレベルのテスト

確認する対象: プロキシ経由でテスト対象に送る1回のリクエスト
主に分かること: 関連するハンドシェイクと対象からの応答が完了するか
確認できないこと: 継続的なダウンロード速度や、ほかのWebサイトへのアクセス結果
比較の条件: 同じ対象、同じ方法、同じ接続ネットワーク

テスト対象自体に問題があると、複数のノードが同時にタイムアウトすることもあります。

たとえば、3回の測定結果が68、72、70 msの候補と、45、310、タイムアウトの候補があるとします。この記録では前者の変動が小さく、後者は1回だけ低い値が出ています。これは数値の読み方を示す例であり、実測した回線の評価や推奨ではありません。3回の結果も短時間のサンプルにすぎません。普段の問題が夜間に起きる場合は、同じ時間帯に改めて確認してください。

低遅延：短いリクエストへの応答には有利な傾向がありますが、MB/sに直接換算することはできません。
タイムアウト：今回のテストが制限時間内に完了しなかったことを示します。サーバーが今後も利用不能だと証明するものではありません。
変動：無線電波の状態、接続ネットワークの混雑、サーバー負荷、接続先サービスの状態などが原因として考えられます。順番に切り分けてください。

地域名と実際の出口を分けて考える

ノード名に含まれる地域名はサービス事業者が付けたラベルであり、クライアントが地理的な位置を独自に確認した証明ではありません。入口、出口、またはサービスの分類を表している場合があります。実際の出口は、接続後に接続先サービスから確認できるアドレスを基準にします。IPアドレスの位置情報データベースには反映の遅れもあるため、地域ラベルだけで、すべてのWebサイトが同じ地域と判定するとは限りません。

目的に応じて地域の確認方法を決める

通常の閲覧とリクエスト応答

同じページを対象に、表示と再読み込みの結果を記録します。
地域の近さだけでなく、リクエストを繰り返し正常に完了できるかを比べます。
ダウンロードでは継続的な転送速度も確認し、最初の応答時間を通信量の指標として扱わないでください。

接続先サービスに地域条件がある場合

まず接続先サービスが定める利用条件と地域要件を確認します。
対象の通信が実際に選択したプロキシの出口を経由していることを確認します。
IPの地域ラベルだけで判断せず、アカウントの地域、位置情報の権限、キャッシュも確認します。

地域は候補を絞るための条件です。目的を達成できるかどうかは、同じ設定で実際に確認してください。

地理的に近くても、実際のネットワーク経路が短いとは限りません。通信は異なる事業者間の接続、入口での中継、出口の経路を通る場合があります。DNSが返す接続先アドレスも最終的な経路に影響します。地域名が同じ2つのノードで同じページの表示結果に大きな差がある場合は、名前だけから原因を推測せず、テスト条件とエラーの状況を記録してください。

プロトコルは名前で順位を付けず、互換性と設定を確認する

プロトコルはクライアントとサーバーが接続を確立し、通信を運ぶ方法を定めるもので、速度を直接決めるものではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは設定要件が異なり、Typeだけを変更して相互に切り替えることはできません。サブスクリプションに必要な設定がそろっている場合は、まずそのまま使用してください。設定が不足している場合は、利用中のサービス事業者に正確な値を確認してください。

プロトコル	確認する設定	確認のポイント
Shadowsocks	サーバー、ポート、暗号化方式、パスワード	暗号化方式とパスワードがサーバー側の設定と一致している必要があります。
VMess / VLESS	ユーザー識別子、転送方式、関連するセキュリティ設定	実際の設定に合わせてTLS、Server Name、パスなどを確認してください。異なるプロトコルの認証設定を混在させないでください。
Trojan	パスワード、ポート、TLS関連の設定	Server Nameと証明書の検証条件を確認してください。検証を無効にして問題を回避しないでください。
Hysteria2	認証情報、TLS、サービス事業者が指定するその他の設定	QUICを使用するため、現在のネットワークでUDPが到達可能か確認してください。
WireGuard	鍵、接続先アドレス、ポート、トンネル関連の設定	UDPを使用します。ハンドシェイクとルーティングの設定の両方がアクセス結果に影響する場合があります。

TCPポートに接続できても、UDPを使うプロトコルが正常に動作するとは限りません。同様に、あるプロトコルが現在のWi-Fiで失敗しても、モバイル通信で同じ結果になるとは限りません。比較には、サブスクリプションで正しく設定済みの項目を使い、接続ネットワークか候補のどちらか一方だけを変更してください。同じプロトコル名のノードでも、出口、サーバー負荷、転送設定が異なれば結果は変わります。

遅延値に問題がないのにWebページが開かない場合は、ルールと接続経路を確認する

選択したノードを、対象ページの通信が必ず通るとは限りません。Global RoutingのProxyはプロキシ経路を一時的に比較する場合、Directは直接接続の比較、Configは選択した設定に従った処理に使います。Sceneは設定されたシーン条件に応じて動作を選ぶ機能で、固定のプロキシ切り替えスイッチとは異なります。ポリシーグループを使っている場合、対象ルールがグループ内の別ノードを選んでいる可能性もあるため、実際に適用された結果を確認してください。

Configのルールは上から順に照合されます。以下は構文の説明用であり、あらゆるネットワークで使える完全な設定ではありません。example.comは例示用のドメインで、サブスクリプションやテストサービスではありません。また、文書用に予約されたアドレス192.0.2.0/24も、実際のサービス接続先を示すものではありません。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIXは指定したドメインのサフィックスに一致します。この例では、そのドメインとサブドメインをPROXYに振り分けます。
IP-CIDRは対象IPの範囲に一致します。no-resolveは、このルールに一致させるための追加のドメイン解決を行わない指定です。
GEOIPは対象IPの地域データベースに基づいて判定します。ノード名の地域表示を使うものではありません。
FINALは、それ以前のルールに一致しなかったリクエストを処理するため、最後のフォールバック位置に置きます。

Proxyではページを開けるのにConfigでは失敗する場合、遅延を基準にノードを選び直すより、Configで選択されているファイル、ルールの順序、ポリシーの振り分け先を先に確認してください。反対に、複数の候補で同じドメインだけ開けない場合は、その接続先のDNS、TLS、サービス状態を確認します。リクエストログで対象ドメイン、適用されたルール、エラー情報を確認し、トラブルシューティングで症状に応じた手順を続けてください。

ノード選びでよくある4つの疑問

遅延が30 msなのに、ダウンロードが遅いのはなぜ？

30 msは選択したテストでの1回の応答時間であり、帯域幅を表す値ではありません。同じファイル、同じノード、同じネットワークで継続的な転送が安定しているか確認し、端末やほかの機器が帯域を使っていないかも調べてください。異なるダウンロードサイトの速度をそのまま比べないでください。

すべてタイムアウトします。サブスクリプションを再登録すべきですか？

まず端末自体がインターネットに接続できることを確認し、Home → Connectivity Testでテスト方法と対象を確認します。プロキシ経由のリクエストテストでは、対象が利用できなくなっているだけで、すべてタイムアウトする場合もあります。サブスクリプションの内容が期限切れ、または設定値が変更されたと確認できてから更新し、根拠なく既存の設定を削除しないでください。

同じノードでも、Wi-Fiでは使えてモバイル通信では使えないのはなぜ？

ノードはそのままにして接続ネットワークだけ切り替え、プロトコル、エラー、発生時刻を記録して比較します。Settings → On Demandによってネットワーク条件に応じて接続動作が変わっていないか確認してください。Hysteria2やWireGuardの場合は、UDPの到達可否と通常のTCP接続結果を分けて確認します。

サブスクリプション更新後、以前選んだ項目が見つからないのはなぜ？

Homeに戻って更新後のリストを確認し、サービス事業者が名称やサーバー設定を変更していないか調べます。現在も存在する項目を選び直し、Configで参照されているポリシーグループも確認してください。古いアドレスやパスワードを新しい項目にコピーして修復を試みず、正確な設定値は利用中のサービス事業者に確認してください。

最低限の記録を残し、印象だけで切り替え続けない

比較を1回行ったら、「接続ネットワーク、時刻、プロトコル、テスト方法、3回分の遅延、対象リクエストの結果」を記録すれば十分です。記録や相談用のスクリーンショットに、サブスクリプションURL全体、パスワード、ユーザー識別子、秘密鍵を載せないでください。サブスクリプションURLのtokenはアクセスに使われることがあるため、共有前に全体を隠してください。

記録例：自宅のWi-Fi、候補A、Trojan、同じリクエストレベルのテスト、68 / 72 / 70 ms、対象ページを3回続けて表示できた。記録形式の例です。
条件をそろえて比較：問題が起きたら同じ条件でテストをやり直し、ネットワークか候補を1つずつ変更してください。プロトコル設定とルールを同時に変更しないでください。
切り替えをやめる：既存の項目で目的を安定して達成できているなら、1回の測定値をさらに小さくするために何度も設定を変える必要はありません。