この記事は、Shadowrocketに自分のサブスクリプションを読み込み済みの方を対象としています。接続とルールが正しく機能していることを確認してから、同じネットワークでの遅延のばらつき、利用するサービスに必要な地域、プロトコルの適合性を順に比較します。読み終えると、遅延値が最小の項目だけを選ぶのではなく、同じ条件で繰り返し比較する方法がわかります。サブスクリプションリンクはご利用のサービス提供元から入手してください。
1. テスト条件をそろえて、登録済みのノードを比較する
ノード名には地域やプロトコル、サービス提供元独自の表記が含まれることがありますが、名前だけで性能を判断することはできません。最初に比較するときは、サブスクリプションが更新済みで、選択した項目のパラメータがそろっていることを確認し、ネットワークと接続先のWebサイトを固定します。Wi-Fiとモバイル通信を切り替えたり、異なるWebページを使ったりしながら比較すると、差がノードによるものかローカルネットワークによるものか判断できません。
-
サブスクリプションを確認する
Homeで登録済みのサブスクリプションを開き、項目と有効期限を確認します。再登録する場合は、Home → + → Type → Subscribeを選び、ご利用のサービス提供元から入手したリンクを入力して保存します。更新してから比較し、期限切れの項目を混ぜないようにしてください。
-
ネットワークを固定する
同じWi-Fiまたは同じモバイルネットワークを使い、ほかのデバイスでの大容量通信を一時停止します。Settings → On Demandでオンデマンド接続の条件を確認し、テスト中にネットワーク条件が変わって接続状態が切り替わらないようにします。
-
ルーティングを確認する
Home → Global Routingで、現在のProxy、Direct、Config、Sceneのいずれが使われているか確認します。元の設定を記録しておき、Proxyで一時的に比較する場合は、終了後に元の設定へ戻してください。普段のルーティングまで変えてしまわないようにします。
-
項目ごとに再テストする
Homeで候補を1つ選び、接続を有効にしてからConnectivity Testを実行し、同じ接続先のページにアクセスします。各候補で3回続けて確認し、接続の可否、画面が表示されるまでの時間、途中で止まるかどうかを記録します。ミリ秒の数値だけで判断しないでください。
サブスクリプションを更新すると、項目数やアドレス、パラメータが変わることがあります。更新前後で選択した項目をそれぞれ記録し、実際の選択先が変わったのに古い結果を使い続けないようにしましょう。サブスクリプションURL内のtokenはアクセス認証情報です。公開スクリーンショットやログ、テスト記録に含めないでください。
2. Ping値・接続遅延・実際の読み込み速度は別の指標
日常会話で「Ping」は遅延全般を指すことがありますが、テスト方法によって測定する経路は異なります。ICMPによる応答確認、TCP接続の確立、プロキシ経由でのテスト用アドレスへのアクセスでは、確認できる処理がそれぞれ異なります。比較する前にテスト方法と接続先を確認してください。同じリスト内の数値を直接比較できるのは、テスト条件がそろっている場合です。
遅延は、1回の応答確認や接続にかかる時間を表します。スループットは継続的なデータ転送能力を表します。Webページの表示には、DNS、接続確立、TLSハンドシェイク、サーバーの応答、複数のリソース取得も関係します。遅延が小さければ一部の待ち時間は短くなる可能性がありますが、大容量ファイルの転送が速いとは限らず、接続先のWebサイトがその出口IPアドレスを受け入れる保証にもなりません。
| テスト結果 | わかること | 次に確認すること |
|---|---|---|
| 応答確認で低遅延 | 今回のテスト経路では応答が速い | 実際に使うWebサイトを開き、初回表示と連続読み込みを確認する |
| 応答確認はタイムアウトしたが、Webページは利用できる | テスト方法または接続先が適切でない可能性がある | テスト方法を確認し、同じ接続先で再比較する |
| 接続は成功するが、通信がたびたび止まる | 接続が確立しても、その後の通信が安定するとは限らない | ローカルネットワークの混雑を除外してから、パケットロスとサーバー負荷を比較する |
| 通常のWebページは表示できるが、特定のサイトだけ失敗する | 接続先サイト、DNS、ルールが原因の可能性がある | リクエストに適用されたルールと実際の出口を確認する |
例として、候補Aの3回の結果が45、260、タイムアウト、候補Bが85、88、91ミリ秒だったとします。この例ではBのばらつきが小さいものの、実際に利用するサービスへのアクセス確認が必要です。これは実測による性能ランキングではなく、特定の地域やプロトコルが常に速いことを示すものでもありません。たまたま出た最低値より、繰り返し得られる結果を重視して選びましょう。
3. 地域を選ぶときは入口・出口・接続先サービスを区別する
ノードに記載された地域は、出口を示す場合もあれば、サービス提供元独自の命名である場合もあります。デバイスから入口に接続し、通信がサービス提供元のネットワークを経由して出口に到達してから、接続先サービスへアクセスします。地理的な距離で説明できるのは、その一部にすぎません。地図上で近い場所がネットワーク経路も短いとは限らず、ノード名の地域表記も実際の出口についての説明の代わりにはなりません。
地域で絞り込む：通常の閲覧と地域指定サービス
通常の閲覧
- 登録済みのサブスクリプションから、出口の異なる候補を2つ選びます。
- 同じネットワークを使い、近い時間帯に同じページを閲覧します。
- 地図上の距離だけでなく、継続して利用できるか、遅延にばらつきがあるかを優先して記録します。
地域指定サービス
- まず、接続先サービスの地域要件と利用規約を確認します。
- 選択した項目の実際の出口地域を、サービス提供元に確認します。
- 接続先へのリクエストが実際にその出口を経由していることを確認し、サービスからの応答を基準に判断します。
地域は選択条件のひとつであり、利用可能であることを保証するものではありません。同じ地域でも、回線ごとに個別の確認が必要です。
地域の判定は、アカウント情報、デバイスの位置情報、既存のセッション、サービス独自のポリシーにも影響されることがあります。そのため、地域を切り替えても表示が変わらないからといって、Shadowrocketが接続されていないとは限りません。まずルーティングと出口を確認し、接続先サービスの通常の手順でセッションを作り直してください。原因を調べずに項目を何度も切り替えるのは避けましょう。
4. プロトコルはサーバーの設定とネットワーク条件に合わせる
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはそれぞれ異なるプロトコルであり、速度のランクを表すものではありません。サーバー側が該当するプロトコルを提供し、必要なパラメータがすべてそろっている場合にのみ、クライアントで設定する意味があります。Typeを別の名前に変えても、元のサーバーが新しいプロトコルに対応するわけではありません。ポート番号だけでプロトコルを判断することもできません。
| プロトコル | 優先して確認するパラメータ | 比較時の注意点 |
|---|---|---|
| Shadowsocks | サーバー、ポート、暗号化方式、パスワード | パラメータをサーバー側の設定と一致させます。アドレスが名前解決できることだけでは不十分です。 |
| VMess / VLESS | UUID、転送方式、TLS、関連する転送パラメータ | 認証方式が異なるため、Typeをそのまま入れ替えることはできません。 |
| Trojan | パスワード、ポート、TLS、SNI | SNI、証明書、サーバー設定を一致させます。パラメータを修正せずに検証を無効化するのは避けてください。 |
| Hysteria2 | 認証情報、TLS、サーバーが要求するその他のパラメータ | UDPベースのQUICを使用します。ネットワークによるUDP制限は接続に影響します。 |
| WireGuard | PrivateKey、PublicKey、Endpoint、Address、MTU | UDPを使用します。鍵、アドレス、ルーティング条件をすべて正しく設定する必要があります。 |
たとえば、ある項目のサーバーポートが8443に設定されている場合は、サービス提供元が指定した8443を入力します。HTTPSでよく使われるポートが443だからといって、自分で置き換えないでください。Hysteria2とWireGuardはいずれもUDPを使用しますが、同じネットワークで同じ結果になるとは限りません。サーバーの場所、実装、回線の負荷、パラメータも異なります。
- 同じプロトコルの一部の項目だけ失敗する場合：該当項目のアドレス、ポート、認証情報、サービスの状態を確認します。
- 同じネットワークで複数のUDPプロトコルの項目が失敗する場合：利用が許可されている別のネットワークで再テストし、UDP制限の有無を確認します。
- どのプロトコルでもアクセスできない場合：プロトコルが不適切と決めつけず、まずローカルネットワーク、システム時刻、接続の許可、現在のルーティングを確認します。
5. Global Routingを確認し、選択したノードが実際に使われているか調べる
Homeで項目を選択しても、すべてのリクエストがその項目を経由するとは限りません。リクエストの処理方法はGlobal Routingで決まり、Configではルールが個別のポリシーやポリシーグループを指定している場合もあります。ノード間の違いを調べる前に、対象のリクエストが実際にどこへ向かっているか確認してください。確認しないままでは、ずっと直接接続の経路を測定している可能性があります。
Config
おすすめ現在の設定にあるルールに基づいてリクエストの経路を決めます。まずConfigで有効な設定を確認し、接続先ドメインに適用されるルールとポリシーを調べます。ルールに一致しないリクエストが必ず直接接続になるとは限りません。
適している用途：適切なルールベースの振り分け設定を使った普段の利用
Proxy
プロキシ対象のリクエストをプロキシモードで処理します。ルールによる振り分けの影響を一時的に減らして比較できますが、システムや設定による除外範囲も考慮してください。すべてのデバイス通信がプロキシ経由になることを示すものではありません。
適している用途：プロキシ経路を一時的に比較し、終了後に元の設定へ戻す場合
Direct
直接接続の経路を使います。Homeでノードが選択されていても、そのノードのアクセス性能を評価することはできません。ローカルネットワークの比較条件として利用できます。
適している用途：プロキシを使わずに接続先へアクセスできるか確認する場合
Scene
設定したシーンの条件に応じて、該当する設定を適用します。テスト前に現在適用されているシーンを確認してください。ネットワークを切り替えても同じルーティング条件が使われるとは限りません。
適している用途：シーンを設定済みで、環境に応じて切り替えて使う場合
ルールは通常、上から順に照合され、FINALはそれ以前のルールに一致しなかったリクエストを処理します。以下は構文の説明例です。既存の設定全体をこの例で置き換えないでください。PROXYの実際の接続先は、現在の設定に応じて確認する必要があります。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYこの例では、example.comとそのサブドメインは最初にDOMAIN-SUFFIXで一致します。IP-CIDRは指定したアドレス範囲に一致し、no-resolveはこのルールのためにドメイン名の名前解決を実行しないことを示します。その後にGEOIPを判定し、最後にFINALで処理します。接続先が先行するDIRECTルールに一致している場合、Homeでノードを切り替えても通常は接続経路が変わりません。
6. よくある現象と再テストの方法
遅延が最も小さいノードなのに、動画が途中で止まるのはなぜ？
低遅延が示すのは、テストした処理の応答時間だけです。同じ動画、画質、ネットワークを使い、2つの候補それぞれで再生が続くか、バッファリング後に再開するかを確認します。同時に、バックグラウンドでの大容量通信を一時停止してください。ピーク時間帯だけ止まる場合は、その時間帯を記録してから比較します。1回の応答確認で継続的なデータ転送の状態を判断することはできません。
Homeでタイムアウトと表示されたら、ノードは使えなくなったということ？
まずテスト方法と接続先を確認します。その後、該当項目を選択して接続を有効にし、Home → Connectivity Testを実行して実際の接続先にもアクセスします。テストに失敗しても通常の通信ができる場合は、応答確認の条件を調べてください。両方とも失敗する場合は、サブスクリプションの更新状況、アドレス、ポート、認証パラメータを確認します。
ノードを切り替えても、Webページの速度も地域も変わらないのはなぜ？
まずHome → Global RoutingがDirectになっていないか確認します。Configの場合は、Configで対象がDIRECTまたは固定ポリシーグループに一致していないか調べてください。対象への接続をいったん確立し直してから確認します。すでに確立済みの長時間接続は、項目の選択を変えてもすぐに作り直されないことがあります。リスト上の選択表示だけで実際の出口を判断しないでください。
Wi-Fiでは正常なのに、モバイル通信では同じ項目が使えない場合は？
まずモバイルデータ通信自体が使えることを確認します。次にSettings → On Demandでネットワーク条件を確認し、現在のGlobal Routingとシーンも確認してください。パラメータを変えていないのにネットワークを切り替えると失敗する場合は、プロトコル、発生時刻、エラーの内容を記録し、そのネットワークから接続できるかサービス提供元に確認します。パスワードや鍵を何度も変更しないでください。
7. 最小値を追い続けるのではなく、再テストの記録を残す
普段使う項目を1つ、動作を確認済みの予備項目を1つ残しておくとよいでしょう。これは登録済みサブスクリプションを整理する方法であり、サービスの入手先を推奨するものではありません。記録には、ネットワーク、テスト日時、プロトコル、出口に関する説明、連続テストの結果、実際のアプリでの使用感を含めます。サブスクリプションURL全体、パスワード、PrivateKey、その他の認証情報は記録しないでください。
- 接続：接続できるか、Connectivity Testを繰り返し実行して成功するか。
- 使用感：同じWebページが安定して最初に表示されるか、継続利用中に中断しないか。
- ルーティング：Global Routing、現在の設定、接続先に適用されるポリシーが一致しているか。
- 再テストのタイミング：ネットワークの切り替え、サブスクリプションの更新、継続的な不具合の発生後に再比較します。一度の変動ですぐに切り替える必要はありません。
確認は「接続できる → ルーティングが正しい → 接続先を利用できる → 安定して使える → 遅延を比較する」の順に行います。こうすることで、パラメータの誤り、ルールの問題、回線の状態を切り分けられ、アクセスの不具合をすべてノードの速度のせいにせずに済みます。