Shadowrocketが遅いときの対処法｜ネットワーク・プロトコル・経路・ノードを4段階で確認

遅延・初回表示・継続転送の遅さを区別する

「速度が遅い」には、接続確立まで時間がかかる、Webページの最初の表示が遅い、ファイル転送開始後も速度が低い、という少なくとも3つの症状があります。遅延テストで分かるのは、特定の方法と対象に対する応答時間であり、利用可能な帯域幅ではありません。HomeのConnectivity Testは到達性の確認に役立ちますが、テストに成功しても、すべてのWebサイトや大容量ファイルの転送が正常とは限りません。

自分がアクセスでき、内容量が一定のHTTPSリソースをテスト対象に選び、毎回同じものを使います。3回続けてテストし、開始時刻、最初のデータが表示されるまでの時間、安定した転送速度をそれぞれ記録します。以下は記録方法の例であり、製品の実測値や速度を保証するものではありません。

数値を比較する前に単位をそろえましょう。8 Mbpsは理論上約1 MB/sに換算できますが、実際の転送速度はプロトコルのオーバーヘッドにも左右されます。速度テストのMbpsとファイルのダウンロード速度のMB/sをそのまま比較しないでください。また、遅延が最も低いノードが、必ずしも最も速く転送できるとは限りません。

第1段階：ネットワーク環境とテスト条件を固定する

ネットワークの接続品質は、その後のすべての判断に影響します。Wi-Fiの電波が最大強度でも、ルーターの上り回線、家庭用インターネット回線、現在のネットワーク出口に混雑がないとは限りません。まず写真の同期、システムアップデート、その他の大容量通信を一時停止してから比較テストを始めます。

1. 現在の状態を記録する

   Homeで現在のノードとGlobal Routingの選択内容を記録し、Settings → On Demandで有効・無効の状態も確認します。接続を切った状態の基準値を測る場合は、自動接続が再び有効にならないよう、一時的に自動接続をオフにします。テスト後は元の設定に戻してください。

2. 基準値を測る

   Shadowrocketの接続を切り、現在のネットワークから直接アクセスできる同じリソースを3回テストします。この状態でも遅い場合は、プロトコルをすぐに変更せず、ルーター、無線干渉、インターネット回線を確認してください。

3. テスト条件を固定する

   Homeに戻り、Global Routingを開いて、現在の設定がProxy、Direct、Config、Sceneのどれか確認します。ルールの影響を切り分けるには、一時的にProxyを選び、同じノードに接続してテストします。終了後は元の設定に戻してください。

4. ネットワークを切り替えて比較する

   ノードとテスト対象を変えず、Wi-Fiとモバイル通信でそれぞれテストします。切り替え後はネットワークが安定してから再接続し、転送中には切り替えないでください。モバイル通信を使う前に、データ通信量の残りを確認しましょう。

同じノードでもモバイル通信では正常、Wi-Fiでは継続して遅い場合、問題はそのWi-Fiの接続環境や出口、またはノードまでの経路にある可能性が高く、ノードサーバーの故障を直接示すものではありません。どちらの接続でも遅い場合は、設定と通信経路を続けて確認します。On Demandは条件に応じて接続を確立する機能であり、帯域幅を増やす設定ではありません。

第2段階：プロトコル設定を項目ごとに確認する

設定の誤りは、接続できない、ハンドシェイクに失敗する、再試行を繰り返すといった症状につながりやすく、Webページの読み込みに長時間かかることもあります。まずHomeから現在のノードの編集画面を開き、自分が利用しているサービス提供元の設定と項目ごとに照合します。サブスクリプションから追加したノードは、先にサブスクリプションを更新してから再テストしてください。手動で変更する場合は、更新で変更内容が上書きされて結果を誤認しないよう、元の値を記録しておきます。

ポートは設定どおりに入力してください。たとえば、サーバーから指定されたポートが8443なら、TLSでよく使われる443に変更してはいけません。ポート番号だけで速度の等級が分かるわけでもありません。TLSを使用するノードでは証明書の検証を有効に保ち、速度低下への一般的な対策としてAllow Insecureを有効にしないでください。証明書に問題がある場合は、iPhoneまたはiPadのシステム時刻も確認しましょう。

接続ログに以下の英語のエラーが表示された場合は、内容を手がかりに原因を絞り込めます。接続段階によってエラー全文は異なるため、単語だけでサーバー側の障害と決めつけないでください。

第3段階：比較テストで通信経路の混雑やパケットロスを特定する

ここでいう「通信経路」とは、端末のネットワークからノードサーバーまでのデータ転送経路です。アクセス回線、ネットワーク間の接続、中継区間などを通ることがあり、経路の品質は時間によって変わります。一度接続に成功しても混雑がないとは限らず、特定の接続先だけ遅くても、経路全体の帯域幅が不足しているとは限りません。

• 同じノードで接続先を変更：ノードとリソースを固定し、Wi-Fiとモバイル通信だけを切り替えます。差が安定して再現する場合は、それぞれの接続出口からノードまでの経路の違いを優先して考えます。
• 同じ接続で時間帯を変更：比較的空いている時間帯と、普段問題が起きる時間帯にそれぞれ3回測定します。特定の時間帯に主に速度が低下するなら、プロトコルをすぐに変更するのではなく、混雑の可能性を検証します。
• 同じノードで接続先を変更：互いに独立した2つの固定リソースにアクセスします。片方だけ遅い場合は、接続先サイトの速度制限、地域別の振り分け、ノードから接続先サイトまでの経路を引き続き確認します。
• 同じ接続でノードを変更：自分がすでに利用しているサブスクリプションから、利用可能な別のノードを選びます。リソースとテスト方法は変えず、同時に複数のダウンロードを実行しないでください。余計な通信の競合が発生します。

Webページは開けるのに、動画や大容量ファイルが周期的に止まる場合は、最低遅延だけでなく、パケットロスと転送速度の安定性を確認します。UDPに依存するプロトコルで、別の接続に切り替えると改善する場合は、ネットワーク環境でUDPに到達できるかサービス提供元に確認してもらいましょう。MTU、DNS、通信設定をまとめて変更しないでください。複数の項目を同時に変えると、比較結果の原因を判断できなくなります。

第4段階：ノードのリソース、プランの制限、接続先の問題を見分ける

最初の3段階を確認したら、特定のノードを評価します。ノードに到達できても、出口の帯域幅、同時接続に使えるリソース、接続先までの通信が十分とは限りません。遅延は正常でも継続的な転送速度が低い場合、ノードの負荷、利用プランの速度制限、データ通信量の上限、接続先の制限などが考えられます。通常、クライアント側だけではサーバーのCPUや出口の使用状況といった内部状態を正確に測定できません。

1. 利用中のサービス提供元のアカウント情報で、有効期限、残りのデータ通信量、契約上の速度制限を確認します。制限を回避する目的でサブスクリプションを何度も更新しないでください。
2. 自分がすでに利用しているサブスクリプションを更新した後、同じノードをテストしていることを確認します。ノード名やアドレスが変わると、更新前後のデータを比較できなくなることがあります。
3. 同じネットワーク接続で、利用中のサブスクリプションにある2つのノードを比較します。片方だけが複数の接続先に対して継続的に遅い場合は、そのノードのテスト記録をサービス提供元に送ってください。
4. 複数のノードで特定のWebサイトだけ遅い場合は、ほかの接続先では正常だった比較結果も残し、接続先サイトと該当する出口経路を優先して確認します。

問い合わせ時には、テスト日時とタイムゾーン、Wi-Fiかモバイル通信か、プロトコル、Global Routingの設定、接続先の種類、3回分の結果、エラー内容を含めてください。サブスクリプションの完全なリンク、Password、秘密鍵、認証情報は送らないでください。スクリーンショットを共有する前に、これらの情報を隠しましょう。クライアントの購入証明と通信経路の状態は別の情報であり、購入状況から通信経路の速度制限を判断することはできません。

よくある質問：低遅延、自動接続、設定の復元

原因の切り分けは、単に速そうな設定を見つけることではなく、どの接続、ノード、接続先、時間帯で問題が起きるか再現できることが重要です。証拠が足りない場合は、設定と記録を保存してから、自分が利用しているサービス提供元に必要最小限の情報を伝えましょう。設定をすべて消して再追加するより、原因を特定しやすくなります。