· トラブルシューティング · 約12分

Shadowrocketの通信速度が遅いときの対処法｜Wi-Fi・プロトコル・回線・ノードを順に確認

通信速度が遅い原因を、Wi-Fi／モバイル通信、プロトコル設定、回線品質、ノード負荷の4段階で切り分けます。ShadowrocketのConnectivity Testも活用し、ボトルネックを特定します。

この記事の概要

Shadowrocketの接続速度はリクエスト経路全体に左右され、Connectivity Testの遅延が小さくてもダウンロード速度が速いとは限りません。利用中のサービスとサブスクリプションがあり、接続はできるものの通信が遅い場合に向けて、ローカルネットワーク、ルーティングとプロトコル、回線品質、ノード負荷の順に確認します。一度に変更する条件は一つにし、結果を記録してから設定を維持するか元に戻すか判断してください。当サイトではノードやサブスクリプションの提供・販売・推奨は行っていません。

1. 遅延・スループット・接続失敗を区別する

「通信が遅い」には、Webページを開いてから表示まで時間がかかる、ファイルのダウンロード速度が低い状態が続く、接続が不安定になる、という少なくとも3つの症状があります。最初の症状はDNS検索や接続確立、接続先の応答に関係する可能性があります。2つ目は持続的なスループットの問題、3つ目はパケットロスやネットワーク切り替え、接続中断を確認します。まず症状を具体的に把握するほうが、すぐにプロトコルを変更するより効果的です。

ローカルネットワーク ルーティング判定 プロトコル接続 リモート出口 接続先サイト

この流れは診断のために論理的に段階分けしたもので、パケットが常にこの順序で処理されることを示すものではありません。DNS検索が行われる段階は状況によって異なります。HomeのConnectivity Testは、テスト先に到達できるかを確認し、テスト方式に応じた所要時間を参考にする機能です。ファイルのダウンロードテストの代わりにはならず、すべてのWebサイトや通信方式が正常であることを証明するものでもありません。

単位にも注意してください。8 Mbpsは約1 MB/sです。これはビットとバイトの換算であり、プロトコルのオーバーヘッドは含みません。速度測定サイトのMbpsとダウンロード画面のMB/sをそのまま比べると、正常な差を速度低下と誤認することがあります。

2. Wi-Fiとモバイル通信の基準値を確認する

まず端末からインターネットへの基本的な接続が正常か確認してから、プロキシ経由の経路を調べます。現在のネットワークから直接アクセスできるサイトを基準の接続先に選び、プロキシが必要なサイトを直接接続の比較対象にしないでください。テスト中はほかの端末での大容量通信を一時停止し、複数の速度測定を同時に実行しないようにします。

  1. 現在の設定を記録

    Homeで現在選択中のノードとGlobal Routingのモードを、Configで使用中の構成ファイルを記録します。以降は一度に条件を一つだけ変更し、テスト後に同じ基準へ戻せるようにします。

  2. 自動接続を一時停止

    Settings → On Demandを確認します。自動接続の条件が有効な場合は、関連するスイッチの状態を記録してから一時的にオフにします。続いてHomeに戻って接続スイッチをオフにし、テスト中に接続が再確立されないことを確認します。

  3. 直接接続を測定

    Wi-Fi接続中に基準の接続先へアクセスし、表示時間、ダウンロードの継続速度、中断の有無を記録します。3回続けて測定し、最速の結果だけではなく3回分を残します。

  4. ネットワークを切り替える

    Wi-Fiをオフにし、端末がモバイル通信を使用していることを確認してから、同じ接続先で同じ操作を繰り返します。データ通信量に注意し、ネットワークの切り替え中に計測しないでください。

  5. 接続を戻す

    Homeに戻り、元のノードを選択して接続をオンにします。まずConnectivity Testを実行し、その後、同じ接続先へのアクセスをテストします。すべての比較が終わったら、On Demandを元の設定に戻します。

接続をオフにしてもWi-Fiだけ遅く、モバイル通信は正常な場合は、Wi-Fiの電波状況、ルーターの上り帯域の使用状況、ローカルネットワークの品質を優先して確認します。どちらのネットワークでも直接接続は正常で、同じノードへの接続時に片方だけ遅くなる場合は、その接続ネットワークからノードまでの経路の違いを調べる価値があります。ただし、それだけでノード負荷が原因とは断定できません。

3. Global Routingと実際に適用されたルールを確認

接続後に遅くても、通信が選択中のノードを実際に経由しているとは限りません。ルーティングモードはHome → Global Routingで設定し、Configのルールは対応するモードでのみ振り分けに使われます。現在のモードを確認してからルールを読み、適用されていない構成を変更しないようにします。

モード確認できること注意点
Proxyプロキシ経由の経路を比較し、ルールによる振り分けの影響を抑えます。短時間のテストに限って使用し、終了後は元のモードに戻します。
Direct直接接続した場合のアクセス結果を確認します。システムのVPN接続が切断されるわけではなく、接続を切った状態での基準テストの代わりにはなりません。
Config現在の構成に設定されたルールに基づいて動作します。現在の構成、ルールの適用順序、最終的なポリシーを確認します。
Scene設定済みのシーンに応じて、ルーティングの動作を決定します。ネットワーク状況に応じてテスト条件が変わらないよう、実際に適用されているシーンを先に確認します。

以下はルールの構文例であり、現在の構成を置き換えるための推奨設定ではありません。DOMAIN-SUFFIXはドメインとそのサブドメインに一致し、IP-CIDRはIPv4のアドレス範囲に一致します。GEOIPはIPアドレスの所在地データベースに基づいて判定し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。ルールは上から順に照合されるため、範囲の広いルールを先に置くと、後続の詳細なルールが適用されないことがあります。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

4. プロトコルの設定値を確認し、推測で速度を上げようとしない

Homeで登録済みノードの編集画面を開き、Type、サーバーアドレス、ポート、認証情報を確認します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardの設定値は互換性がありません。プロトコルは接続先の設定と一致させてください。Typeだけを変更してプロトコルごとの速度を比較することはできません。

たとえば、既存の設定でポート443が指定されている場合は、接続先で実際に待ち受けている通信方式を先に確認します。TCP 443に接続できても、UDP 443にも接続できるとは限りません。ポート番号が同じでも、使用するプロトコルが同じとは限りません。Hysteria2はQUICをベースとしており、UDPに依存します。WireGuardもUDPを使用するため、ネットワークによるUDPの制限が接続や継続的な通信に影響することがあります。

5. 比較結果から回線品質とノード負荷を切り分ける

回線品質とノード負荷はどちらも「夜になると遅い」という症状につながりますが、時間帯だけでは原因を判断できません。接続先サイトを固定し、まずノードを変えずに接続ネットワークを切り替え、次にネットワークを固定して利用中の別のノードに切り替えます。各条件で少なくとも3回測定し、同時に測定して帯域を奪い合わないよう、測定の間隔を空けます。

観察された結果まず疑う原因次に確認すること
同じノードでもWi-Fi接続時だけ遅いローカルのWi-Fi環境、またはその接続ネットワークからのリモート経路。ルーターに近づいて再測定し、モバイル通信の結果と比較します。
同じノードがどちらのネットワークでも遅く、ほかの利用中ノードは正常そのノードの入口、出口、またはリソースの制限。接続先サイトを2つに変えて、時間帯による違いも比較します。
すべてのノードで同じサイトへのアクセスが遅い接続先サイト、リソースサーバー、または共通して通過する経路。ノードを固定して、別の独立した接続先をテストします。
Connectivity Testは正常でも、継続的なダウンロードは遅いスループットの制限、パケットロス、接続先の速度制限、または接続先の応答性能。テストの所要時間だけでなく、継続中の速度を記録します。
タイムアウトが頻発し、結果のばらつきが大きいWi-Fiの干渉、混雑、パケットロス、または接続先の不安定さ。まずローカルネットワークの直接接続を比較し、その後ノード経由の経路を確認します。

遅延が小さいことから分かるのは、短いリクエストの往復や接続確立にかかる時間が短いという点です。帯域幅、パケットロス率、同時接続の制限によって、大容量ファイルの転送が遅くなることはあります。反対に、遠距離のノードは遅延が大きくても、継続的なダウンロード速度が低いとは限りません。接続先、時間、ネットワーク条件をそろえていない2枚の速度測定画面では、特定のプロトコルのほうが必ず速いとは証明できません。

ピーク時間帯だけ大きく速度が低下し、ローカルの直接接続が正常な場合は、症状、時間帯、接続ネットワーク、個人情報を隠した測定結果を利用中のサービス提供元に共有して確認できます。ノードのCPU、出口帯域幅、接続数はリモート側の指標であり、クライアントに表示された遅延だけから推定することはできません。

6. エラーが発生したら種類ごとに対処する

以下はネットワーク接続の診断で表示されることがある標準的なエラー文字列です。実際の表示内容はリクエストの記録を確認してください。テストによっては同じ文言が表示されない場合があります。エラーが示すのは失敗した段階であり、リモート側の根本原因が確定したわけではありません。接続を何度もオン・オフするより、エラーの原文と発生時刻を記録するほうが診断に役立ちます。

エラー：i/o timeout

原因と対処：指定された時間内にネットワークの読み書きが完了しなかった状態です。経路の不通、パケットロス、接続先の無応答などが考えられます。ノードを固定してWi-Fiとモバイル通信を切り替え、接続先のアドレス、ポート、対応する通信方式を確認します。タイムアウトをすぐに帯域不足と判断しないでください。

エラー：connection refused

原因と対処：接続要求が明示的に拒否されています。接続先のポートで該当サービスが待ち受けていない場合や、途中の機器が接続を拒否した場合によく発生します。利用中の設定のアドレスとポートを確認し、待ち受け状態をサービス提供元に確認してください。通常、MTUを変更してもこのエラーは解消しません。

エラー：no such host

原因と対処：現在の名前解決で必要なドメイン情報を取得できていません。ドメインの入力ミスや、名前解決環境の異常が考えられます。サーバーのドメイン名を確認し、接続ネットワークを切り替えて再テストしてから、現在の構成のDNS設定を確認します。確認できていないIPアドレスを長期間固定して使用しないでください。

エラーはなく速度が低いだけの場合は、存在しないエラーを探すのではなく、継続的なスループットを比較してください。記録を共有する前に、パスワード、Private Key、認証token、サブスクリプションURLを隠します。通常はプロトコルの種類、個人情報を除いた接続先、ポート、ネットワークの種類、時刻があれば症状を説明できます。

7. よくある質問と確認の仕上げ

遅延は数十ミリ秒なのに、ダウンロードが遅いのはなぜ？

Connectivity Testと継続的なダウンロードでは測定対象が異なります。Homeに戻って同じノードを維持し、固定したファイルを30秒以上ダウンロードして、MbpsとMB/sを混同していないか確認します。別の接続先でも再テストし、特定サイトの速度制限と経路のスループット問題を切り分けてください。

Proxyにすると正常なのに、Configでは通信が止まるのはなぜ？

まずHome → Global Routingで、2回のテストのモードが同じか確認します。次にConfigで、現在の構成にあるDOMAIN-SUFFIX、IP-CIDR、GEOIP、FINALの順序を確認します。リクエスト記録と照らし合わせて実際のポリシーを確認し、すべてのルールをすぐに削除しないでください。

ネットワークを切り替えた後に通信が止まります。毎回端末を再起動する必要がありますか？

新しいネットワークが安定するまで待ち、Homeで接続を一度オフにしてから再度オンにし、新しい経路で接続を確立します。Settings → On Demandが意図しない自動接続を実行していないか確認してください。ネットワーク切り替えとの関連を判断するのは、再現条件が明確になってからにします。

Hysteria2に変更すれば必ず速くなりますか？

必ず速くなるとは限りません。まず接続先がそのプロトコルに対応し、パラメーターがすべて正しく設定されていることを確認します。次に、現在のネットワークで必要なUDP通信が可能か確認してください。入口や出口が異なると、ほかの条件も変わります。プロトコル名だけで判断せず、接続先、接続ネットワーク、測定時間帯をできるだけそろえてください。

確認が終わったら、どの設定を元に戻せばよいですか？

Global Routing、現在の構成、On Demandを元の設定に戻し、改善につながらなかったMTUやDNSの変更を取り消します。最後に普段使うアプリでもう一度テストし、効果があった変更と結果を記録して、一時的なテスト設定を残さないようにします。

確認のゴールは「直接接続は正常だが、特定の接続ネットワークでは同じノードの継続的なダウンロードが遅い」のように、再現して検証できる結論を得ることです。「クライアントが遅い」と曖昧にまとめるのではなく、原因に応じた段階を調べることで、効果のない変更を減らせます。

App Storeの正規配信を確認