Shadowrocketでノードを選ぶときは、同じネットワークとテスト方法で応答する候補を絞り、接続後に実際の用途で確認します。利用者が自分で用意したサービスとサブスクリプションを使う前提で、遅延値の見方、地域表示の用途、プロトコル設定の確認方法、ルールによる振り分けをノードの性能と誤認しないためのポイントを解説します。当サイトではノードやサブスクリプションの提供・販売・推奨は行っていません。
1. 遅延テストは到達性の確認に使い、数値を速度ランキングにしない
遅延は通常msで表され、テスト開始から応答を受け取るまでの時間を示します。ダウンロード速度でも、Webページの読み込み完了時間でもありません。TCP接続だけを確立するテストでは、主に接続確立までの時間が反映されます。プロキシ経由でHTTPのテスト先にアクセスする場合は、プロキシのハンドシェイクや接続先の応答時間なども影響します。「ハンドシェイクの速さを示すだけ」という説明は、遅延を帯域幅と混同しないための目安ですが、テスト方法自体の確認に代わるものではありません。
まずSettings → Connectivity Testで現在のテスト設定を確認し、Homeに戻ってConnectivity Testを実行します。同じリストの結果を比較できるのは、テスト方法、テスト先、ローカルネットワークが同じ場合です。Wi-Fiでの結果とモバイル回線での結果をそのまま順位付けしたり、異なるテスト方法の数値をまとめて平均したりしないでください。
- 数値が表示される：その条件でテスト先から応答があったことを示します。すべてのWebサイトやプロトコルの通信が正常とは限りません。
- タイムアウト：サーバーへの到達不可、ポートの制限、テスト先からの応答なし、設定の不一致などが考えられます。この結果だけでサブスクリプション全体が無効だとは判断できません。
- 結果のばらつきが大きい：同じ候補を複数回テストし、最低値だけでなく、繰り返しタイムアウトするかどうかも記録します。
たとえば「候補A：80、82、450 ms」「候補B：110、115、112 ms」という記録なら、まずAのばらつきに注目し、その後、実際の用途で確認します。これは記録方法の例であり、当サイトでの実測値でも性能の保証でもありません。Aの最低値が小さくても、継続的な通信がより快適だとは限りません。
2. Homeで再現性のある方法で候補を絞る
結果の変化の原因を把握するには、一度に変える条件を一つにします。テスト前に端末で大容量の通信を一時停止し、同じWi-Fiまたはモバイル回線を使います。バックグラウンド通信を完全になくす必要はありませんが、大きなファイルをダウンロードしながら数十msの差を比べるのは避けましょう。
-
リストを確認
Homeでサーバー項目が登録されていることを確認します。サブスクリプションを更新した直後なら、項目が残っているか確認してください。項目の編集画面でType、アドレス、ポートを確認し、古くて使えない項目を比較対象に含めないようにします。
-
テスト条件をそろえる
Settings → Connectivity Testを開き、現在のテスト方法とテスト先を確認します。設定を変えずにHomeへ戻り、Connectivity Testを実行して、応答があった候補とタイムアウトした候補を記録します。
-
複数回テストする
候補を少数に絞り、間隔を空けて3回テストします。最低値だけでなく、数値とタイムアウトの回数を記録してください。テスト中はローカルネットワークを切り替えません。
-
ルーティングを確認
Home → Global Routingでモードを確認します。Proxyを使い、選択したサーバー経由での実際のアクセス結果を比べます。Configを使っている場合は、現在のConfigでルールがどのポリシーに振り分けているかも確認してください。
-
実際の用途で確認
候補を選択して接続をオンにし、同じWebページまたは同じ動画にアクセスします。ページが開くか、コンテンツがすべて表示されるか、再生が続くかを記録し、次の候補でも同じ手順を繰り返します。
Proxyでの比較は条件を絞り込むためのもので、普段からそのモードを使う必要があるという意味ではありません。確認が終わったら、必要なGlobal Routing設定に戻してください。サーバーを切り替えても開いているページの表示がすぐ変わらない場合は、ページを閉じてから開き直します。長時間の接続やキャッシュ済みコンテンツだけでは、新しい接続経路を判断できません。
3. 地域表示は候補の絞り込みに使い、実際の経路は別途確認する
ノード名に含まれる地域情報は、通常、利用中のサービス提供元が設定したものです。物理的な設置場所、通信の出口、アクセス権限を独立して証明するものではありません。入口のアドレス、最終的な出口、接続先Webサイトのネットワークが、それぞれ異なる地域にあることもあります。名前にある都市名や国旗だけでは、接続先までの経路は判断できません。
地域が近ければ通信距離が短くなる可能性はありますが、所要時間は通信事業者間の接続、迂回経路、サーバー負荷、接続先の応答にも左右されます。地図上の距離だけで並べるより、実際の用途に応じて地域を絞り、到達性と安定性をテストするほうが比較結果を再確認しやすくなります。
用途に応じて確認するポイント
Webページと操作時の通信
- 同じページを開き、初回の表示と、その後の操作時の動作を確認します。
- タイトルが表示されるかだけでなく、画像やスクリプトなどのリソースがすべて読み込まれるか確認します。
- まず、繰り返しタイムアウトする候補を除外し、その後に応答の違いを比較します。
動画の連続再生とデータ転送
- 同じコンテンツと画質に固定し、再生中に通信が途切れないか確認します。
- 再生開始時のバッファリングと、再生中に発生する再バッファリングを区別します。
- 時間帯を変えて再確認し、一度だけ通信が空いていたときの結果を長期的な性能と見なさないようにします。
地域は候補を絞るための条件です。その用途での判断基準は、接続先にアクセスした実際の結果です。ノード名から接続先サービスの地域判定や利用可否を保証することはできません。
4. プロトコルの互換性を確認してから結果を比較する
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは、接続方式や設定項目が異なります。プロトコル名だけで一律の速度順位を付けることはできません。同じプロトコルでも、異なる伝送方式が使われる場合があります。利用中のサービスが実際に提供する設定を使ってください。Typeの名前だけを変更しても、サーバーが別のプロトコルで動作するわけではありません。
ポートもプロトコル名から推測できません。443を使う設定もありますが、すべてのサービスで固定されているわけではなく、接続が同じ伝送方式になる証拠でもありません。TLS関連の設定では、サービス指定のサーバー名なども確認します。証明書の検証を無効にして、設定の誤りを回避しようとしないでください。
プロトコルと伝送方式を確認
- Shadowsocks
- サーバー、ポート、暗号化方式、パスワードを確認します。いずれかが一致しないと接続に失敗する場合があります。
- VMess / VLESS
- ユーザーID、伝送方式、サービスで指定されているTLSなどの設定を確認します。アドレスとポートだけでは設定を再現できないことがほとんどです。
- Trojan
- パスワードとTLS関連の設定を確認し、サーバー名がサービスの設定と一致しているか確認します。
遅延の違いを比較する前に、設定がすべてそろっていることを確認します。伝送設定が異なる候補を、Typeだけを見て同じテスト条件として扱わないでください。
ネットワーク条件を確認
- Hysteria2
- QUICをベースにしており、UDP経路を使用します。TCPポートだけをテストしても、この接続が利用可能かどうかを十分に判断できません。
- WireGuard
- UDPを使用するため、鍵、Endpoint、トンネル関連の設定を一致させる必要があります。ポートから応答があっても、トンネル設定が正しいとは限りません。
- ポートの例
- 443は使用される場合があるポートの一つです。実際の値は利用者がすでに持っている設定に従い、独自に置き換えないでください。
Wi-Fiとモバイル回線ではUDPの扱いが異なる場合があります。ネットワークを切り替えたら再テストし、以前の順位をそのまま使わないでください。
Wi-Fiでは失敗し、モバイル回線では正常に動作する候補があれば、すぐにプロトコルの「速い・遅い」と結び付けず、ローカルネットワークの経路も確認してください。Type、伝送方式、ポート、失敗したネットワークを記録すると、項目名を何度も変更するより問題を特定しやすくなります。
5. Global Routingとルールによる誤判定を防ぐ
Homeで選択したサーバーが、現在のWebページの通信に使われているとは限りません。Global RoutingがDirectの場合、通信は直接接続されます。Proxyの場合はプロキシ経由になり、Configの場合は現在の設定ルールに従って通信先が決まります。Sceneの場合は、該当するシーンの設定を確認してください。候補を比較する前に、通信にどのポリシーが適用されているか把握する必要があります。
Configモードでは、DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレス範囲、GEOIPはIPの地理情報を基に照合します。FINALは、それ以前のルールに一致しなかった通信を処理します。ルールは上から順に照合されます。先行ルールでDIRECTまたはREJECTに一致している場合、後続のFINALを変更しても、その通信の判定結果は変わりません。
- Webページの表示が常に速い：まずDIRECTに一致していないか確認します。直接接続されたページでは、選択したプロキシサーバーの速度を判断できません。
- 特定のドメインだけ接続できない：REJECTに一致していないか、選択中のサーバーとは異なるポリシーが適用されていないか確認します。
- 切り替えても違いがない：現在のConfigで別のポリシーが指定されていないか確認し、ページのキャッシュや既存の長時間接続の影響も除外します。
- 接続スイッチが自動で戻る：Settings → On Demandで条件を確認し、自動接続が手動比較に影響しないようにします。
テストで応答があってもWebページが開かない場合は、DNSの名前解決と接続先自体も確認してください。ポートに到達できても、ドメイン名が正しく解決されるとは限らず、現在の出口から接続先にアクセスできるとも限りません。ルールの構文を確認するにはプロトコルマニュアルをご覧ください。ノードを選ぶためにConfig全体を一度に変更しないでください。
6. ノード選びでよくある疑問と記録方法
遅延が最も小さいのに、動画が止まるのはなぜ？
Homeに戻って候補を選び、Global Routingを確認したうえで、動画の画質を固定して再生します。接続確立の速さと継続的な転送速度は別の指標です。混雑、パケットロス、コンテンツ配信経路などが再生に影響する場合があります。数値を一つ記録するだけでなく、バッファリングが再生開始時か再生中に起きたかを記録しましょう。
テストはタイムアウトするのに、接続後はWebページが開く場合、項目を削除すべき？
まずSettings → Connectivity Testでテスト先とテスト方法を確認し、実際のアクセス結果と照らし合わせます。テスト先だけに到達できない場合や、テスト方法が実際のプロトコル経路を確認できていない場合があります。一度のタイムアウトだけで項目を削除しないでください。サブスクリプションから登録した項目は、次回の更新時にリストへ再同期されることもあります。
同じ地域、同じプロトコルなのに、結果が大きく異なるのはなぜ？
Homeで各項目の編集画面を開き、アドレス、ポート、伝送設定を確認します。地域名が同じでも、入口、出口、通信経路が同じとは限りません。同じプロトコルでも負荷は異なる場合があります。同じネットワークで繰り返しテストし、同じ用途で結果を比較してください。
サブスクリプションの更新後は、ノードを選び直す必要がある？
まず内容を確認してください。更新によってアドレス、ポート、設定、項目の構成が変わる場合があり、以前の記録がそのまま使えるとは限りません。Homeで現在の項目を確認し、Connectivity Testを実行します。サブスクリプションの内容が実際に変わった場合や、利用時に問題がある場合に、改めて全候補を比較しましょう。
実際の用途で確認した候補を2～3件残せば十分です。テスト日時、ローカルネットワーク、項目名、Type、テスト方法、3回分の結果、実際のアクセス状況を記録します。ネットワークやサブスクリプションの内容が変わったら再確認してください。パスワード、鍵、サブスクリプションURLを記録に含める必要はありません。問題を他の人に相談するときも、これらの情報は隠してください。