Shadowrocketの通信速度が遅いときの原因と対処法｜ノード・回線・プロトコル・ローカルネットワークを順に確認

始める前に：テスト条件を固定し、遅延と通信速度を区別する

先に確認しておきたいのは、Connectivity Testの結果がそのままダウンロード速度を示すわけではないことです。遅延はテストリクエストの完了までにかかった時間を表します。継続的なデータ転送には、利用可能な帯域幅、パケットロス、混雑、接続先サーバーの速度制限なども影響します。テストへの応答が速いノードでも、大容量ファイルの転送には時間がかかることがあります。特定のWebページの表示が遅くても、接続全体が遅いとは限りません。

Homeで現在選択中のノードとGlobal Routingを記録します。普段Configを使用している場合は、比較の基準としてその設定を残してください。ルールの影響を切り分ける場合は、一時的にProxyへ切り替え、テスト対象のリクエストが選択したノードを経由していることを確認します。Sceneはシーン選択に関わるため、この比較中に同時に変更しないでください。Directはプロキシ回線の速度を測る条件にはなりません。

1. 普段アクセスする対象を1つ決め、初回表示、再表示、継続的なデータ転送をそれぞれ確認します。異なるサイト同士を比較対象にしないでください。
2. ほかのデバイスで大容量通信を行うタスクを一時停止し、テスト時刻、ネットワークの種類、ノード名、Global Routing、タイムアウトの有無を記録します。
3. 条件ごとに3回繰り返し、各回の結果または中央値を記録します。最速の結果だけを残さないでください。
4. 一度に変更するのは1項目だけにし、変更後は接続を再確立します。テストが終わったら、元のGlobal Routingに戻してください。

第1層：ノードが使えるか、テストへの応答だけが正常か

Homeで現在のノードにConnectivity Testを実行し、実際のリクエストでも接続を確認します。テスト成功は、そのテスト条件で接続できたことを示すにすぎません。失敗した場合は、サーバーに到達できないのか、認証エラーなのか、テスト対象に到達できないのかを切り分けます。ノードの診断の代わりにサブスクリプションを何度も更新しないでください。リストを更新しても、接続先の負荷や回線の混雑は解消されません。

1. ノードのアドレス、ポート、プロトコル、認証情報が、利用中のサービスから提供された内容と一致しているか確認します。ポートにはサービス側が指定した値を使用してください。よく見かける443であっても、ほかのポートを独断で変更してはいけません。
2. 同じネットワークとGlobal Routingのまま、登録済みリストから別のノードを選び、同じリクエストを再テストします。変数を減らすため、まずは同じプロトコルの項目を選んでください。
3. 特定のノードだけで失敗が繰り返される場合は、テスト時刻とエラーを記録します。すべてのノードで遅い場合は、共通する回線、ローカルネットワーク、テスト対象を引き続き確認してください。
4. ノード情報が変更された可能性がある場合は、元のSubscribeの更新操作を1回行い、選択中の項目を確認します。サブスクリプションの更新に成功したことと、ノードに接続できることを混同しないでください。

以下は接続ログによく見られるエラーの一部です。具体的な表記はプロトコルや接続環境によって異なります。原因を特定する唯一の根拠ではなく、切り分けの手掛かりとして使ってください。ドメイン名の解決、接続の確立、データ転送のどの段階で発生したかも確認しましょう。

第2層：回線の混雑とルールによる振り分けを切り分ける

ノードは接続先となるリモート側の入口です。回線にはローカルの接続環境、通信事業者の経路、ノードの出口、出口から接続先サイトまでの経路が含まれます。名前の異なる2つのノードが、経路の一部を共有している場合もあります。そのため、ノードを変えても遅いからといって、回線の問題を除外することはできません。同様に、ある接続先でテストが正常でも、すべての接続先で問題がないとは限りません。

Configでは現在の設定に基づいてリクエストの経路が決まり、Proxyはプロキシモードで比較する際に使用します。ただし、実際のリクエスト記録も確認してください。ルールは上から順に照合されるため、先に一致したルールによって、後続のルールが適用されないことがあります。以下は構文上の関係を示す例です。現在の設定と置き換えられる完全なファイルではなく、すべての接続先に適した方針を示すものでもありません。

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

DOMAIN-SUFFIXはドメインのサフィックスで照合します。IP-CIDRはIPアドレスの範囲で照合します。GEOIPはIPの地理情報を使って照合します。FINALはそれ以前のルールに一致しなかったリクエストを処理します。リクエストが実際にはDIRECTで接続されている場合、プロキシノードの遅延を測っても、そのリクエストが遅い理由はわかりません。まず適用されたルールを確認してください。

第3層：プロトコルの変更より、設定値の確認が重要

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは、通信方式や認証の仕組みが異なります。ノードのプロトコル名だけを変更しても、プロトコルを切り替えたことにはなりません。接続には、それぞれに対応したサーバーと完全な設定情報が必要です。利用中で動作確認済みの設定同士だけを比較してください。2つの設定でサーバーが異なる場合、測定結果の差をすべてプロトコルの違いに結びつけることはできません。

• Shadowsocks：暗号化方式とパスワードを確認します。プラグインを使う場合は、サーバーで指定されているプラグインとパラメータも確認してください。
• VMess／VLESS：ユーザー情報、通信方式、TLSなどのパラメータを確認します。WebSocketまたはgRPCを使用する場合は、パスやサービス名もサーバー側と一致させてください。
• Trojan：パスワードとTLSのサーバー名を確認します。証明書の検証に失敗する場合は、時刻、ドメイン名、証明書チェーンを確認してください。速度を上げる目的で検証を無効にしないでください。
• Hysteria2：QUICをベースとしており、UDP経路が利用できる必要があります。使用中のネットワークでUDPが制限されている場合、ハンドシェイクの失敗や接続の不安定さにつながることがあります。どのネットワークでも速いと決めつけないでください。
• WireGuard：UDPを使用します。鍵、エンドポイント、ルーティング関連のパラメータを確認してください。小さなリクエストは正常なのに大きなデータ転送が止まる場合は、MTUも確認項目に加えます。ただし、先にパケットロスとサーバー側の問題を除外してください。

この流れからわかるように、「接続スイッチがオン」と「接続先のコンテンツを安定して転送できる」は同じ状態ではありません。ハンドシェイクで異常がある場合は、まず認証、TLS、下位の通信方式を確認します。ハンドシェイク完了後に遅くなる場合は、パケットロス、混雑、接続先の負荷、応答状況を確認してください。MTU、DNS、プロトコル、ノードを一度に変更すると、回復してもどの変更が効果をもたらしたのか判断できません。

第4層：Wi‑Fi、モバイル通信、DNSを確認する

同じノードと接続先を使い、Wi‑Fiとモバイル通信を順にテストするのが、ローカル接続環境の違いを見分ける直接的な方法です。切り替える前にデータ通信量に注意してください。切り替え後はネットワークが安定するまで待ち、接続を再確立します。ネットワークによって結果が異なる場合、接続環境や経路に差があることはわかりますが、ルーター、通信事業者、ノードのいずれかが原因だと断定はできません。

1. 基本のインターネット接続を確認：Shadowrocketを一時的に切断し、通常なら直接開けるWebページにアクセスします。基本の接続も遅い場合は、まずローカルの接続環境を確認してください。もともと直接アクセスできない接続先で、このテストを行わないでください。
2. Wi‑Fiの状態を確認：ルーターの近くで再テストし、ローカルネットワーク内の大容量通信を一時停止します。公衆Wi‑Fiでは、認証ページの手続きが完了していることも確認してください。電波のアンテナ表示だけでは、利用可能な帯域幅を正確に判断できません。
3. 名前解決とデータ転送を切り分ける：初回表示に時間がかかる一方、その後のデータ転送は正常な場合は、DNSリクエストがタイムアウトしたり、繰り返し再試行されたりしていないか確認します。この現象だけを根拠に、DNS設定をすべて変更しないでください。
4. 自動接続の影響を確認：Settings → On Demandで現在の条件を確認し、ネットワーク切り替え時に再接続が発生するか観察します。手動テストの基準を作るには、元の設定を記録してからOn Demandを一時的にオフにし、テスト後に元へ戻してください。
5. IPv6の情報を記録：特定のネットワークだけで問題が起きる場合は、名前解決の結果にIPv6アドレスが含まれるか、関連する接続が失敗するかを記録します。比較結果がないまま、IPv6を無効にすることを一般的な対処法にしないでください。

DNSの変更で変わるのは名前解決の方法と、その後に使用される可能性のあるアドレスです。回線の帯域幅が直接増えるわけではありません。ダウンロードが始まった後も安定して遅い場合、DNSを何度も変更しても帯域幅のボトルネックは特定できません。一方、名前解決の段階でリクエストが止まる場合は、プロトコルのパラメータではなく、名前解決の結果とリクエストの経路を確認します。

よくある質問：低遅延、サブスクリプションの更新、夜間の速度低下

結果をまとめる：再現可能な記録で切り分けを終える

4層に分けて確認する目的は、問題の範囲を絞ることであり、すべての設定をやり直すことではありません。比較が終わったら、元のGlobal RoutingとOn Demandに戻します。根拠の得られなかった変更も元に戻してください。利用中のサービスに問い合わせる場合は、必要な現象と接続情報だけを伝え、サブスクリプションのリンク全体、パスワード、秘密鍵、認証トークンを公開しないでください。

• 環境：iPhoneまたはiPad、Wi‑Fiまたはモバイル通信、発生時刻と継続時間。
• 接続：選択中のノードの識別名、プロトコル、Global Routing、同じ接続先で再テストしたかどうか。
• 結果：3回分のテスト記録、実際のアクセス状況、エラーの一部、別のネットワークまたは登録済みの別ノードとの比較結果。
• 実施した操作：変更した設定を1項目ずつ記録し、元に戻したかどうかも記載します。次回の確認を把握できている状態から始められます。