この記事は、Shadowrocketに自分で契約しているサービス事業者の設定を読み込み、接続は成功するものの、ウェブページの表示やファイル転送が遅い場合に適しています。テスト対象と時間を固定し、ノードの状態、通信経路、プロトコル設定、ローカルネットワークを順に確認します。Global Routing、Connectivity Test、繰り返しテストの結果から原因を判断してください。
まず「遅い」の意味を定義し、テスト条件を固定する
「接続成功」はシステムのトンネルが確立したことを示すだけで、端末から対象サイトまでの経路全体が最適な状態とは限りません。通常、リクエストはローカルのWi-Fiまたはモバイル通信、システムのVPNトンネル、Shadowrocketのルール判定、自分が利用するサーバー、対象サイトを経由します。どこかでキュー待ち、パケットロス、名前解決の待機が発生すると、ページが読み込み中のままになることがあります。
まず、現象を3種類に分けます。1つ目は起動時だけ遅いケースです。ウェブページが長時間白紙のままでも、その後の読み込みは正常で、DNS、接続確立、最初のバイトの待機が原因になりやすい状態です。2つ目は継続的に遅いケースです。大きなファイルの開始から終了まで速度が低い場合は、回線のスループット、サーバー負荷、ローカルネットワークを確認します。3つ目は速度が不安定なケースです。速度が頻繁に変わり、動画の画質も切り替わる場合は、パケットロス、無線干渉、混雑時間帯の負荷を確認します。
テストサイトを固定する
安定してアクセスできる同じウェブページと、サイズが明確な同じテストファイルを選びます。サイトごとに帯域幅やキャッシュ方針が異なるため、異なるサイトの結果を直接比較しないでください。
設定を固定する
Homeで同じノード、同じGlobal Routingの状態、同じネットワーク接続方式を維持し、まず3回連続でテストします。初回応答時間と継続転送速度を記録してください。
バックグラウンド処理を停止する
写真の同期、アプリのアップデート、クラウドバックアップ、その他の大容量通信を一時停止します。そうしないと、帯域幅の競合によってテスト結果を比較できなくなります。
変数を1つずつ変更する
1回のテストでは要因を1つだけ変更します。たとえばノードだけを変更する、またはWi-Fiからモバイル通信に切り替える、といった方法です。複数のパラメータを同時に変えると、どの変更が効果を生んだのか判断できません。
第1層:ノード負荷とサーバー応答を確認する
ノード層では、利用しているサーバーが接続をすぐに受け付け、データを処理できるかを確認します。レイテンシが低くても、スループットが高いとは限りません。Connectivity Testに表示されるミリ秒値は、主に接続またはリクエストの往復にかかる時間を示します。継続的なダウンロード速度は、サーバーの外向き帯域幅、同時接続数、対象サイトの制限にも左右されます。
Homeのノード一覧で、現在のノードにConnectivity Testを実行します。成功したか、タイムアウトしたか、レイテンシが大きく変動していないかを記録してください。画面レイアウトによっては、テスト項目がノードの操作メニューにある場合があります。アプリ内の現在の表示に従ってください。たとえば3回の結果が85 ms、92 ms、410 msの場合、3回目だけが大きく外れているため、経路またはサーバーに不安定さがあると考えられます。毎回すぐに完了するのに大きなファイルだけが低速なら、回線のスループットを確認します。
現在のノードを確認する
Homeに戻り、実際に選択されているサーバー項目を確認します。サブスクリプションのグループ名を、現在の外向きノードと取り違えないでください。
接続テストを実行する
同じノードに対してConnectivity Testを3回連続で実行します。各回の間隔を約5秒空け、成功したかどうかとレイテンシの変動幅を記録してください。
同じグループ内で比較する
自分が利用しているサービス事業者の設定から、既知の利用可能な別ノードを選びます。変更するのはノードだけにして、同じテストを繰り返してください。新しいノードで正常に戻る場合、原因は元のノードまたはその上流経路にある可能性が高くなります。
サブスクリプションの状態を確認する
Homeで下にスワイプして、既存のサブスクリプションを更新します。サーバーアドレスとポートが、サービス事業者から現在提供されている値か確認してください。サブスクリプションURLの例を示す場合は、https://example.com/sub?token=xxxx のような形式に限ります。実際の情報は自分のサービス事業者に確認してください。
エラー:The request timed out
原因と対処:規定時間内に応答を受信できていません。ノードの一時的な混雑、回線のパケットロス、サーバーへの到達不能などが考えられます。ほかの条件を変えずにテストを繰り返し、自分の設定にある別の利用可能なノードでも比較してください。
エラー:Connection reset by peer
原因と対処:リモート側または途中のネットワークが接続を強制的にリセットしました。まずサーバーアドレス、ポート、パスワード、UUID、トランスポート設定を確認します。設定に問題がないのに繰り返し発生する場合は、該当するサービス事業者にサーバー側の状態を確認してもらってください。
エラー:Failed to load subscription
原因と対処:サブスクリプションURLの期限切れ、応答のタイムアウト、アクセス条件の変更などが考えられます。URLが自分のサービス事業者から提供されたものか確認し、Homeで下にスワイプして更新します。それでも失敗する場合は、サービス事業者にURLの有効性を確認してください。
ノード名に含まれる地域名だけで速度を判断しないでください。名前は設定上のラベルであり、実際の経路、負荷、出口品質を直接示すものではありません。繰り返しテストの成功状況、レイテンシの変動、初回応答時間、固定ファイルの継続転送速度を総合して判断します。
第2層:回線のレイテンシ、パケットロス、混雑を確認する
回線とは、端末からサーバーまでの間に通るネットワーク経路です。サーバー自体の負荷が正常でも、接続ネットワーク、通信事業者の経路、時間帯によって大きな差が生じます。典型的な回線の問題には、安定しているものの高いレイテンシ、突然のレイテンシ上昇、断続的なタイムアウト、小さなウェブページは開けるのに長時間の転送だけ速度が落ちる現象があります。
回線テストでは、時間帯と接続方式を比較することが重要です。Shadowrocketのノードとプロトコルを変えず、Wi-Fiで1回テストした後、モバイル通信に切り替えてもう1回テストします。一方の接続方式だけが明らかに遅い場合は、プロトコル設定をすぐに変更するのではなく、そのローカルネットワークとサーバーまでの経路を優先して確認します。
- 低レイテンシで速度も安定:ノードと回線は現時点でおおむね正常です。一部のサイトだけ遅い場合は、対象サイトまたはルールの判定を確認します。
- レイテンシは高いが安定:経路の距離が長い、または迂回している可能性があります。操作への応答は遅くなりますが、継続転送まで完全に利用できないとは限りません。
- レイテンシが数百ミリ秒以上変動:動画のバッファリングやページのリソースが段階的に表示されることがあります。パケットロス、無線信号、混雑時間帯の混雑を確認してください。
- テストがときどきタイムアウト:接続が中断していることを示します。成功した1回の最低レイテンシだけを見て判断しないでください。
- 日中は正常で特定の時間帯だけ遅い:時間帯による負荷またはネットワーク混雑の可能性が高いため、同じ時間帯に数日連続で再テストします。
| 観察結果 | まず確認すること | 次の対応 |
|---|---|---|
| Wi-Fiは遅いがモバイル通信は正常 | ルーター、無線干渉、またはブロードバンド経路 | ルーターに近づき、周波数帯を切り替え、ネットワーク機器を再起動して再テストする |
| 両方のネットワークで1つのノードだけ遅い | ノード負荷またはノードの上流回線 | 自分の設定にある別ノードで比較する |
| すべてのノードで特定のサイトだけ遅い | 対象サイト、DNS、またはルール判定 | リクエストが想定どおりDIRECTまたはプロキシ方針を通っているか確認する |
| 夜間に全体的に速度が低下する | 混雑時間帯の混雑 | 朝と夜に同じ条件で各3回測定し、中央値を比較する |
第3層:プロトコルとトランスポートパラメータのオーバーヘッドを確認する
Shadowrocketは、Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどの設定タイプに対応しています。プロトコルごとにハンドシェイク方式、暗号処理、トランスポート層、パケットロスからの復旧方式が異なりますが、サーバー側の設定を確認せずに、どれが必ず速いかを判断することはできません。クライアントのパラメータはサーバー側と項目ごとに一致させる必要があります。
プロトコル層の問題は、回線が遅いと誤認されがちです。トランスポート方式、TLS、SNI、Path、パスワード、UUIDなどが一致しないと、ハンドシェイクの繰り返し、接続リセット、完全な接続不能が発生することがあります。UDPが制限されている場合、UDPに依存する設定では速度テストが不安定になることもあります。この場合、Global Routingを繰り返し切り替えてもパラメータの誤りは直りません。
| 設定タイプ | 確認するポイント | よくある判断材料 |
|---|---|---|
| Shadowsocks | サーバーアドレス、ポート、パスワード、暗号方式 | いずれかが一致しないと、通常は接続失敗または即時切断になる |
| VMess / VLESS | UUID、TLS、SNI、Transport、Path | ハンドシェイクがタイムアウトまたはリセットされる場合は、完全なパラメータの組み合わせを先に確認する |
| Trojan | パスワード、TLS、SNI、証明書関連の設定 | TLS段階の異常は、接続を確立できない状態として現れることがある |
| Hysteria2 | UDPの到達性、認証情報、サーバーパラメータ | 制限されたネットワークでは、不安定になったり接続を完了できないことがある |
| WireGuard | キー、Endpoint、Allowed IPs、MTU | 一部のサイトだけ停止し、小さなリクエストは正常な場合はMTUを確認する |
元の設定を保存する
変更前に現在のサーバーアドレス、ポート、プロトコルパラメータを記録します。推測でTLS、MTU、Transport、UDP関連の項目をまとめて変更しないでください。
サーバー側の情報を確認する
Homeのノード詳細と、自分のサービス事業者が現在提供している設定を項目ごとに比較します。特に大文字・小文字、Path先頭のスラッシュ、SNI、ポートを確認してください。
パラメータを1つだけ変更する
1回につき、明確に一致していないフィールドを1つだけ修正します。保存後に再接続し、同じテストを繰り返してください。変更履歴を追えなくなるのを防げます。
元の値に戻す
変更しても改善しない、または新しいエラーが発生した場合は、記録しておいた元の設定にすぐ戻し、別の層の確認を続けます。
MTUは、明確なフラグメント発生や特定サイトの停止を示す根拠がある場合だけ変更します。値が大きすぎると一部のパケットが通過できず、小さすぎるとヘッダーの割合と処理回数が増えます。あるネットワーク環境で有効だったMTU値を、すべての設定にそのまま適用しないでください。
第4層:ローカルのWi-Fi、モバイル通信、バックグラウンド通信を確認する
ローカルネットワークは見落とされやすい層です。ルーターから端末が遠い、同じ周波数帯に干渉がある、ルーターが長時間高負荷になっている、ブロードバンドの上り帯域が使い切られている、といった状況はいずれもShadowrocketのレイテンシを上昇させます。この場合、接続を切ってローカルサイトにアクセスしても遅いことがあります。まず接続をオフにした状態とオンにした状態を比較してください。
Wi-Fiの電波アイコンが最大でも、端末が強い無線信号を受信していることを示すだけで、インターネット出口の混雑がないとは限りません。2.4 GHzは一般にカバー範囲が広い一方、同じ周波数帯の機器による干渉を受けやすくなります。5 GHzは近距離で利用できる帯域幅が大きい傾向がありますが、壁による減衰が大きくなります。周波数帯の名称と切り替え方法はルーターによって異なります。
バックグラウンド転送を停止する
クラウド写真同期、システムバックアップ、アプリのアップデート、ローカルネットワーク内のファイル転送を一時停止し、約30秒待ってから再テストします。
ルーターに近づく
障害物の少ない近距離で同じノードをテストします。レイテンシの変動が明らかに小さくなる場合は、無線のカバレッジまたは干渉を優先して確認してください。
接続ネットワークを切り替える
ノード、プロトコル、Global Routingを変えずに、Wi-Fiからモバイル通信へ切り替えます。同じウェブページとファイルでテストを繰り返してください。
ネットワーク接続を再構築する
Shadowrocketの接続スイッチをオフにし、現在のネットワークへ再接続してから、もう一度オンにします。それでも異常が続く場合は、端末とルーターの通常の操作手順に従って再起動し、再テストしてください。
On Demandを確認する
Settings → On Demandを開き、Wi-Fiとモバイル通信の切り替え時にルールが接続と切断を繰り返していないか確認します。調査中は元の設定を記録したうえで一時的に無効にし、手動接続でテストできます。
エラー:Network is unreachable
原因と対処:端末に利用可能なネットワーク経路がないか、ネットワーク切り替え中でルートがまだ復旧していません。まずWi-Fiまたはモバイル通信自体にアクセスできることを確認し、Shadowrocketの接続をオフにしてから再度オンにします。
エラー:The Internet connection appears to be offline
原因と対処:システムが利用可能なインターネット接続を検出できていません。まずShadowrocketをオフにした状態でローカルネットワークを確認し、接続が復旧してからシステムVPNトンネルを再確立します。
Global Routing、ルール判定、DNS待機を確認する
速度の問題は、通信が誤った経路を通っていることでも発生します。ShadowrocketのGlobal Routingには、一般にProxy、Direct、Config、Sceneがあります。Proxyは通信全体でプロキシ方針を使用し、Directは直接接続します。ConfigはConfig内のルールを上から順に判定し、Sceneは設定したシーンに従って処理します。調査時は、現在の状態が想定どおりか必ず確認してください。
Global RoutingがDirectの場合、該当するプロキシ通信を現在のノードは処理しません。Proxyの場合、本来DIRECTにすべきローカルリソースも迂回する可能性があります。通常Configを使う場合は、ルールの順序が特に重要です。Shadowrocketは条件に一致する最初のルールに到達すると、通常は以降のルールを確認しません。そのため、範囲の広いルールを前に置くと、後続の詳細なルールが適用されないことがあります。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
上記は判定順序を説明するための例です。example.comはDOMAIN-SUFFIXにより先にPROXYを使用し、ローカルネットワークのアドレスはIP-CIDRにより直接接続します。GEOIP条件に一致するその他の通信はDIRECTを使用し、前述のルールに一致しないリクエストは最終的にFINALへ到達します。実際の方針名は、自分のConfigで定義されているものと一致させてください。
DNS待機は、ドメインを初めて開くときだけ非常に遅く、同じページを更新すると速くなる現象として現れることがあります。調査時は、ドメインへのアクセスと、既知の利用可能なIPリソースへのアクセスを比較できますが、不明なDNSアドレスをむやみに入力しないでください。Configに、判定前に名前解決が必要なGEOIPまたはIP-CIDRルールがあるか、また名前解決を発生させる必要がない場面で`no-resolve`が使われているかも確認します。
- HomeでGlobal Routingが現在Proxy、Direct、Config、Sceneのどれになっているか確認し、テスト前の状態を記録します。
- Configを使う場合は、ルールの先頭から下へ、対象ドメインに一致する可能性がある最初のDOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINALを確認します。
- 初回リクエストだけが遅い場合は、DNS名前解決と最初のバイトの待機時間を記録します。接続確立後も速度が低い場合は、回線とサーバーのスループットを確認します。
- 調査が終わったら、元のGlobal Routingの状態に戻してください。一時的なProxyテストの状態を長期的な結論として扱わないでください。
現象:Connected but no traffic
原因と対処:システムトンネルは確立していますが、ルール、DNS、サーバーからの外向き通信のいずれかが有効な応答を返していません。まずGlobal Routingが誤ってDirectになっていないか確認し、Configで対象ドメインに対する最初の判定結果を1つずつ確認します。
決めた順序で再テストし、結論を記録する
1つの層の調整が終わったら、最初に固定したテスト対象へ戻ります。別のサイトに変えて主観で判断しないでください。日付、時刻、接続ネットワーク、ノードラベル、プロトコル、Global Routing、3回分のレイテンシ、初回応答、継続速度を記録することをおすすめします。記録項目をそろえれば、一時的な変動と安定した差を区別できます。
レイテンシが低いのに、なぜダウンロードは遅いのですか?
レイテンシは1回の往復時間を示すもので、サーバーの出口帯域幅や経路全体の継続スループットを示すものではありません。サイズが明確なファイルを1つ選び、3回連続でテストします。同時にノード負荷と混雑時間帯の回線状態も確認してください。
ノードを変えたらすぐ速くなりました。これだけで結論を出せますか?
まず同じネットワーク、同じGlobal Routing、同じテスト対象で3回繰り返します。元のノードだけが継続的に遅く、新しいノードが継続的に正常なら、原因を元のノードまたはその上流回線に絞り込めます。
Wi-Fiは遅いのにモバイル通信は正常な場合、どうすればよいですか?
Shadowrocketの設定を変えずにルーターへ近づいて再テストし、バックグラウンド同期を一時停止します。近距離で正常に戻るなら無線のカバレッジを確認し、それでも遅い場合はルーターの負荷とブロードバンド経路を確認してください。
サブスクリプションの更新に失敗すると、既存のノードに影響しますか?
既存の項目は一時的に残ることがありますが、サービス事業者側の設定変更を取得できません。まずHomeで下にスワイプして更新してください。「Failed to load subscription」と表示された場合は、自分のサービス事業者にURLとアクセス条件を確認します。
Proxyテストを長期間使い続けるべきですか?
Proxyは調査時に通信全体を同じプロキシ経路へ通す確認に適していますが、Configの分流結果を迂回します。テスト後は元の状態に戻し、DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINALが実際にどの順序で判定されるか確認してください。
- 現在のネットワークとノードで基準値を測定し、3回連続で結果を記録する。
- ノードだけを変更し、サーバー負荷またはノードの上流経路に異常があるか判断する。
- Wi-Fiとモバイル通信だけを切り替え、ローカル接続と回線の差を確認する。
- プロトコルパラメータを確認し、推測でポート、TLS、Transport、MTUを変更しない。
- Global Routing、Configのルール順序、DNSの初回応答を確認する。
- 元の設定に戻し、同じ対象で3回再テストして、中央値を結論として残す。
ShadowrocketはAppleプラットフォーム向けの有料商用アプリです。主な利用端末はiPhoneとiPadで、App Storeの互換性欄にはMac、Apple TV、Apple Visionが記載される場合もあります。システム要件はApp Storeページの表示に従ってください。入手先はApp Storeのみです。製品ページの開発者名はShadow Launch Technology Limited、アプリIDは932747118、購入方式は買い切りです。クライアントの購入と、自分で契約している回線サービスは別の事項です。