Shadowrocketの遅延表示は、特定の条件で行ったテスト結果であり、速度ランキングではありません。利用中のサービスやサブスクリプションがあることを前提に、テスト条件をそろえ、地域やプロトコルを確認し、実際のルール適用先を確かめる方法を解説します。手持ちのサーバーからメインと予備を選ぶ際は、まず実際のリクエストが完了するか、次に安定性を確認し、遅延の大小は最後に比較します。
1. 遅延テストで分かること、分からないこと
遅延は通常ミリ秒で表示され、特定の測定にかかった時間を示します。まずテスト方法を確認しましょう。TCP接続テストは主にサーバーのポートへの接続確立を測定します。プロキシ経由でテスト先にアクセスする方法では、プロキシのハンドシェイク、テスト先のDNS解決、接続先サイトの応答時間も影響します。測定方法が異なる数値を、同じランキングで直接比較することはできません。
Homeで手持ちのサーバーの遅延をテストする前に、Settingsで現在のテスト方法を確認してください。テスト先を使う方法の場合は、同じアドレスを使い続けます。画面上の項目や選べるテスト方法は、アプリの現在の表示に従ってください。一度テストに成功しても、確認できるのはそのときの測定条件を満たしたことだけです。ウェブ閲覧、継続的なデータ転送、リアルタイム通話の確認には代わりません。
| 表示された結果 | 判断できること | そのままでは判断できないこと |
|---|---|---|
| TCP接続の所要時間が短い | 測定時に、対象ポートへの接続が速く確立した | プロキシ認証が正しく、接続先のウェブサイトも必ず開けること |
| プロキシ経由のリクエストテストに成功 | 指定された経路で、そのテストリクエストが完了した | ほかのウェブサイトやUDPアプリも必ず正常に動作すること |
| 一度だけタイムアウト | 制限時間内に測定が完了しなかった | サーバーが永久に使えないこと、またはパスワードが必ず間違っていること |
| 測定結果が大きくばらつく | 測定経路または接続先に変動があり、追加の切り分けが必要 | 最も低かった一度の数値だけでメインを選べること |
スループットは単位時間あたりに転送できるデータ量、遅延は1回の通信で待つ時間を表し、別の指標です。小さなリクエストへの応答が速くても、継続的な転送では帯域幅、混雑、パケットロス、サーバー負荷の影響を受けることがあります。反対に、ハンドシェイクに少し時間がかかる接続でも、確立後は安定して転送できる場合があります。
2. Global Routingを固定して手持ちのサーバーを比較
Homeで選択中のサーバーを切り替えても、すべてのリクエストがそのサーバーを使うとは限りません。Global Routingのモード、現在のConfigのルール、ポリシーグループの選択が実際の経路に影響します。確認するウェブページへの通信がルールによってDirectに振り分けられている場合、そのページの読み込み速度で選択中のプロキシサーバーを評価することはできません。
Config：通常の利用環境で確認
推奨現在の設定にあるルールとポリシーに従って接続を処理します。まずテスト先に適用されるポリシーを確認し、次にそのポリシーで実際に使われるサーバーを確認してください。日本国内のアドレスはすべてDirect、その他のアドレスはすべてProxyになると決めつけることはできません。
用途：普段の振り分けを維持し、実際の利用環境で確認する
Proxy：ルールの影響を一時的に切り分け
Shadowrocketが処理する接続をプロキシ経由にして、問題がConfigの振り分けに起因するかを確認しやすくします。ネットワークや接続先への到達を保証するものではありません。確認後は元のモードに戻してください。
用途：同じウェブページを短時間比較し、ルールやポリシー選択を確認する
Direct：直接接続時の基準
処理対象の接続を直接接続にします。このときのウェブ閲覧の状態は、選択中のプロキシサーバーの性能を示すものではなく、現在のネットワークから直接接続した場合の参考値です。
用途：直接接続でも同じ問題が起きるか確認する
Sceneを使っている場合は、現在のネットワーク条件で実際にどのルーティングモードが適用されているかを確認してください。Sceneの名前を、別の遅延テスト方法と混同しないようにしましょう。切り分け中はSettings → On Demandも確認し、自動接続の条件によって「手動で切断した」状態が再び変わらないようにしてください。
- Home → Global Routingで現在選択されている項目と、Configで使用中の設定を記録します。
- 手持ちのサーバーを1つ選び、同じテスト方法で連続3回測定します。成功した数値だけでなく、タイムアウトも記録してください。
- 接続後、決めた接続先を開き、リクエスト記録に表示されるルール、ポリシー、サーバーが想定どおりか確認します。
- 次の候補を測るときはサーバーの選択だけを変更し、ネットワーク、接続先アドレス、ルーティングモードは固定します。
- 比較のため一時的にProxyへ切り替えた場合は、テスト後に元のConfigまたはSceneの設定に戻してください。
3. 地域表示は候補を絞る目安。実際の経路確認は別途必要
サーバー名に含まれる地域は、通常、設定を提供する側が付けたラベルであり、クライアントが物理的な所在地を独自に確認したものではありません。入口アドレスの所在地、最終的な出口の所在地、接続先サイトが判定する地域は一致しないことがあります。名前に「近い」とあっても、ネットワーク経路が短いとは限りません。通信事業者間の接続や経路の迂回によって、実際の所要時間は変わります。
地域を選ぶときは、まず用途を確認しましょう。一般的なウェブ閲覧では、リクエストが安定して完了するかが重要です。地域制限のあるコンテンツを利用する場合は、接続先が実際にどの地域の出口として認識するかを確認してください。サーバー名、遅延、単一アドレスの位置情報データベースだけでは、接続先サービスがその出口を受け入れるかどうかは分かりません。
ネットワークごとに分けて確認：Wi-Fiとモバイル通信
Wi-Fi
- 同じアクセスポイントに接続して測定し、大容量通信を一時停止します。
- まずよく使う接続先を確認し、次に別の接続先でも確認します。
- 普段使う時間帯に、タイムアウトや中断が起きるか記録します。
モバイル通信
- Wi-Fiから切り替わっていることを確認し、接続ネットワークの記録違いを防ぎます。
- なるべく同じ場所で同じテストを繰り返します。
- ネットワークを切り替えたら、以前のリクエストを使い回さず、テスト接続を新たに確立します。
同じサーバーでもWi-Fiとモバイル通信の結果は分けて記録します。普段使うネットワーク向けのメインを決め、手持ちの一覧から実際に確認済みの予備も選んでおきましょう。
テストする時間帯もそろえてください。午前中は正常でも夜間に何度も中断する場合、混雑のピークやサーバー負荷が関係している可能性があります。地域名だけでは説明できません。問題が起きやすい時間帯に再測定してから選択を見直し、一度だけ出た最低遅延を追って頻繁に切り替えるのは避けましょう。
4. プロトコルは接続条件を決めるもの。固定の速度順位はない
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはプロトコルの種類を示すもので、回線品質のランクではありません。サーバー側が対応するプロトコルとパラメーターをサポートしている必要があります。手持ちの設定でプロトコルの種類だけを別のものに変えても、サーバーにその機能が自動的に備わるわけではなく、ハンドシェイクに失敗する可能性があります。
| プロトコル | 確認する項目 | 切り分け時の注意点 |
|---|---|---|
| Shadowsocks | アドレス、ポート、暗号化方式、パスワード。プラグインを使う場合はその設定も一致させる | TCPが使えても、UDP転送の設定が正しいとは限りません。 |
| VMess / VLESS | ユーザーID、通信方式、および設定で指定されているTLS、Host、パスなどのパラメーター | アドレスとポートだけでは、ハンドシェイクに必要な条件がそろっているか確認できません。 |
| Trojan | パスワード、TLS、サーバー名など、実際に設定されているパラメーター | ポートに接続できても、TLSと認証が成功したとは限りません。 |
| Hysteria2 | QUICベースのUDPへの到達性、認証、TLSパラメーター | ネットワークでUDPが制限されている場合、TCPの測定結果で実際のプロトコル動作を確認することはできません。 |
| WireGuard | 鍵、Peer、Endpoint、トンネルアドレスなどの設定 | UDPを使用します。Endpointアドレスだけでは、正しいトンネルを確立できません。 |
たとえばTCP 443を使う設定では、ポートに接続できてもTLSや認証の段階で失敗することがあります。UDP 443を使う設定の場合、TCP 443で成功してもUDP側が使える証明にはなりません。ポート番号が同じでも、通信方式は同じとは限りません。手持ちの設定に沿って確認し、すべてのサーバーを一律に443へ変更したり、一度成功させるために証明書検証を無効にしたりしないでください。
まとめ：まずプロトコルで接続できるか確認し、次に実際の用途で比較
手持ちの設定がモバイル通信だけで失敗する場合は、まずそのネットワークで対応する通信方式に到達できるか、ハンドシェイクの記録を確認してください。プロトコル全体が遅いとすぐに判断する必要はありません。認証と接続先へのリクエストが完了してから、同じ用途で待ち時間、読み込みの停止、継続的な安定性を比べましょう。
5. 遅延、ルール、DNS、サブスクリプションの問題を分けて確認
「サーバーの遅延は測れるのにウェブページが開かない」場合、テストと実際のリクエストで確認範囲が異なることがあります。測定ではポートに接続できても、ウェブページの表示にはドメインの名前解決、プロキシ認証、正しいポリシーへの振り分け、接続先へのアクセスが必要です。サーバーを次々に変更して調査を終えるのではなく、リクエスト経路に沿って順に確認しましょう。
- まずルールを確認：Configで使用中の設定を開き、
DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINALの順序と適用先のポリシーを確認します。ルールは上から順に照合され、FINALはそれ以前のルールに一致しなかった接続を処理します。 - 次にポリシーを確認：ルールが適用するポリシーはDirectの場合も、別のポリシーグループの場合もあります。Homeで現在選択されている項目が、そのリクエストで最終的に使われるサーバーとは限りません。
- DNSを確認：アドレスには接続できてもドメインへのリクエストが失敗する場合は、現在のConfigのDNS設定とリクエスト記録を確認してください。DNS、プロトコル、サーバーを同時に変更すると、どの変更が影響したのか特定しにくくなります。
- サブスクリプションを確認：利用中のサービスのアドレス、ポート、認証情報が変更された場合は、まずHomeで該当するサブスクリプションを更新し、更新後の項目をテストしているか確認してください。リストの更新に成功しても、すべての項目が使えるとは限りません。
- 接続をやり直す：設定を切り替えたら、古いテストページを閉じて新たにリクエストしてください。既存の長時間接続がしばらく以前の経路を使い続け、比較結果に影響することがあります。
調査結果には、サーバーを見分けるためのローカル名、接続ネットワーク、テスト方法、発生した現象だけを記録してください。サブスクリプションURL、パスワード、ユーザーID、鍵は機密情報です。公開するスクリーンショットやテスト記録に含めないでください。既存サブスクリプションの読み込みや管理方法は、サブスクリプションマニュアルをご覧ください。
6. よくある質問とメイン・予備の選び方
遅延が数十ミリ秒なのに、動画が何度もバッファリングするのはなぜ？
まず動画のリクエストが実際に選択中のサーバーを経由しているか確認し、同じコンテンツと画質で継続的な転送を観察してください。遅延テストのデータ量は小さく、帯域幅、混雑、コンテンツ配信経路は分かりません。バッファリングが起きる時間帯を記録し、手持ちの予備サーバーと同じ条件で比較しましょう。
一覧ではタイムアウトと表示されるのに、ウェブページは開けます。使い続けても大丈夫？
まずSettingsでテスト方法とテスト先を確認し、ウェブページのリクエスト記録を見て、実際にそのサーバーを経由しているか確認してください。実際のリクエストが安定し、測定だけが失敗する場合は、テスト先や方法が適切か調べましょう。タイムアウト表示だけを根拠に、手持ちの設定を削除する必要はありません。
同じ地域のサーバーが複数あります。いつでも数値が最も低いものを選べばよいですか？
いいえ。同じ条件でそれぞれ3回測定し、よく使うウェブページと継続的な通信も確認してください。繰り返しタイムアウトや中断が発生する候補には印を付けます。安定して用途を満たせる候補の中から、遅延と地域の要件を考慮し、現在のネットワークで使うメインを決めましょう。
Wi-Fiを切り替えたら、使えていた設定が動かなくなりました。サブスクリプションを再読み込みする必要がありますか？
まず接続ネットワークへのログインが完了しているか確認し、次にSettings → On Demandの自動接続条件を確認してから、元の設定で再接続・テストしてください。元のネットワークに戻すと復旧する場合は、まず新しいネットワークからの到達性を調べます。既存サブスクリプションのパラメーターが実際に更新または欠落している場合に限り、該当するサブスクリプションを更新するか、再読み込みしてください。
最後に、メイン、予備、対応する接続ネットワーク、テスト方法、よく使う接続先が安定して利用できるかを簡潔に記録しておきましょう。予備は実際に動作を確認したものを選び、一覧から遅延の低い名前を適当に選ぶだけでは不十分です。その後は、継続的な失敗、接続ネットワークの変更、手持ちの設定の更新があったときに再測定します。一時的な数値の変動だけを理由に変更を繰り返す必要はありません。
ShadowrocketはAppleプラットフォーム向けの有料アプリで、主にiPhoneとiPadで利用できます。入手先はApp Storeのみです。アプリの買い切り購入に回線サービスは含まれません。この記事では、ユーザーがすでに利用しているサーバーの確認と選び方を扱い、サーバーやサブスクリプションサービスの提供、販売、推奨は行いません。システム要件とデバイスの対応状況はApp Storeの掲載内容をご確認ください。