Shadowrocketの速度低下を段階別に切り分け：ノード・経路・プロトコル・ローカルネットワークを順に確認

テスト条件を固定し、速度測定の干渉を避ける

速度を切り分ける際に起こりやすいのは、Wi‑Fi、ノード、プロトコル、測定先を同時に変更してしまうことです。結果が速くなっても、何が効いたのか分かりません。端末、ネットワーク、測定先、時間帯を固定し、1回ごとに1つの変数だけを変更して、少なくとも3回繰り返してください。

まずShadowrocketを接続していない状態で、Webページの初回表示時間、ダウンロード速度、基本遅延など、ローカルネットワークの状態を記録します。その後Shadowrocketを有効にし、同じWi‑Fiと同じ測定先で再度記録します。ローカルの基準値自体が大きく変動する場合は、クライアント設定を変更する前に、ルーター、電波状態、接続回線を確認してください。

1. ローカルの基準値を記録する

   Shadowrocketの接続スイッチをオフにし、同じWi‑Fiで3回連続して測定します。遅延、ダウンロード速度、Webページの初回表示時間を記録し、最高値だけを残さないでください。

2. ノードを1つに固定する

   Homeに戻り、利用中のサービスにあるノードを1つ選択します。測定中は、測定対象が変わらないように、サブスクリプションの更新やノードの自動切り替えを行わないでください。

3. Configを使用する

   Home → Global RoutingでConfigを選択し、現在の設定ファイルのルールに従ってリクエストを処理します。切り分け中は設定名も記録し、ルールの変化を経路の変化と取り違えないようにしてください。

4. 3回の測定を繰り返す

   接続を有効にしたら、同じ測定先を3回連続して測定し、各回の間隔を約30秒空けます。結果が18 Mbps、76 Mbps、24 Mbpsなら、安定した速度制限ではなく、まず変動を疑います。

5. 一度に1項目だけ変更する

   ノードを変更して再測定し、ノード差を確認してからプロトコルや転送設定を比較します。同じ測定中にDNS、MTU、Global Routing、ノードを同時に変更しないでください。

第1層：ローカルネットワークと端末の接続を確認する

アプリから送信されたリクエストは、まず端末が接続しているネットワークを経由し、その後システムが確立したVPNトンネルに入ります。Wi‑Fiの電波が弱い、ルーターが混雑している、接続先が切り替わる、LANでパケットロスが発生すると、遠隔ノードに到達する前から遅延が生じます。この場合、プロトコルを変更しても根本原因は解決しません。

iPhoneまたはiPadでは、まず無線ルーターの近くで測定し、その後、安定している別のWi‑Fiに切り替えて再測定します。可能であればモバイル通信とも比較できますが、両方の測定で同じノードと同じ測定先を使ってください。特定のWi‑Fiですべてのノードが遅く、別のネットワークで正常に戻る場合は、ローカルの接続層に問題がある可能性が高くなります。

「接続直後は速いのに、数分後から徐々に遅くなる」現象にも注意してください。無線干渉、ルーターの負荷変化、端末が複数のアクセスポイント間で切り替わることなどが原因として考えられます。まず画面を点灯したまま短時間の測定を完了し、その後5〜10分の継続転送を行って、短時間の接続と長時間の接続の差を比較します。

• すべてのノードが同時に遅い：Wi‑Fiの電波、ルーターの負荷、現在の接続ネットワークを優先して確認します。
• 1つのノードだけ遅い：ローカルネットワークの可能性は低いため、ノードと経路を引き続き確認します。
• Webページの初回表示だけ遅く、その後は正常：DNS、接続確立、TLSハンドシェイクの段階を重点的に確認します。
• 小さいファイルは正常だが、大きいファイルの転送が徐々に遅くなる：経路のスループット、パケットロス、MTU、輻輳制御を重点的に確認します。
• ネットワークを切り替えるとすぐに回復する：既存のShadowrocket設定は保持し、まず元のネットワーク環境を確認します。

第2層：Pingと時間帯別テストでノードと経路を特定する

Homeのノード一覧で利用可能な遅延テストやPingテストを実行する際は、1回の結果だけを見ないでください。1回だけ60 msでも、経路が安定しているとは限りません。58 ms、62 ms、61 msと連続する結果のほうが、35 ms、240 ms、90 msより予測しやすい場合があります。後者は最低値こそ優れていますが、変動が大きく、Webページや動画が途切れる可能性があります。

Pingは遠隔側の応答方針の影響も受けるため、入口となる指標にすぎません。遅延テストが正常なのに実際のアクセスが遅い場合は、実際の転送テストを行い、Logで接続確立、タイムアウト、リトライの時間分布を確認してください。遠隔側がPingに応答しなくても、そのサービスが利用できないとは限りません。

経路の時間帯も重要です。朝、夜、そして問題が発生する決まった時間帯に、同じノードで同じテストを行います。夜だけスループットが低下し、ローカルの基準値と他のノードが正常なら、その時間帯に特定の経路や遠隔リソースが混雑している可能性が高くなります。

第3層：Global Routing、ルール、DNSを確認する

ノード自体は正常なのに、一部のWebサイトだけ遅い、または特定のアプリだけ遅い場合は、Global Routingを確認します。Proxyは現在のプロキシ方針を一律に使い、Directは直接接続し、Configは設定ファイルのルールに従って処理し、Sceneは設定済みのシーンに応じて動作を選択します。日常設定を切り分ける際は、DirectやProxyに誤って留まっていないかではなく、まず想定したConfigになっているか確認してください。

Configモードでは、リクエストが上から順にルールと照合されます。DOMAIN-SUFFIXはドメインの末尾に、GEOIPは対象IPの地理データベースの結果に、IP-CIDRはアドレス範囲に基づいて照合し、FINALはそれまでのルールに一致しなかったリクエストを処理します。順序を誤ると、Directにすべきリクエストがプロキシに送られたり、プロキシが必要なリクエストが先にDirectへ一致したりします。

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

以下は照合順序を説明するための例であり、すべての設定に適しているわけではありません。1行目は指定した例示ドメインをPROXYに渡し、2行目はローカルネットワークのアドレスをDirectにし、3行目はGEOIPの結果に基づいてDirectにし、最後にFINALが残りのリクエストを受けます。実際のポリシー名は、現在のConfigに存在するものと一致させてください。

「Pingは正常なのにWebページが長時間真っ白」という場合は、DNSも確認してください。ドメイン解決は対象への接続確立より前に行われます。解決のタイムアウト、到達できないアドレスの返却、ネットワークごとにキャッシュ結果が異なることが、初回表示の遅さとして現れる場合があります。DNS設定を複数同時に変更せず、まず既知の動作する設定に戻してから、1項目ずつ比較してください。

• Homeで現在のノードとConfig名を確認します。
• Global Routingが意図せずDirectまたは全体Proxyになっていないか確認します。
• Configで、FINALだけでなく、対象ドメインが最初に一致するルールを確認します。
• 「ドメインは開けないがIPには接続できる」場合は、まずDNSの解決過程を確認します。
• ルールを変更したら接続を再確立し、既存接続のキャッシュ結果を新しいルールの結果と混同しないようにします。

第4層：プロトコルと転送設定を比較する

ShadowrocketはShadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどのプロトコルに対応しています。プロトコル名だけで速度が決まるわけではありません。実際の性能は、サーバー側の設定、暗号化方式、転送層、経路のパケットロス、CPU負荷、設定の一致状況にも左右されます。同じネットワークと、近い経路条件で比較して初めて、プロトコルの違いを評価できます。

変更前に、自分のサービス事業者から提供された元の設定値を保存してください。アドレス、ポート、パスワード、UUID、公開鍵、SNI、Transport、TLS、パスは一組で一致させる必要があります。アドレスとポートだけをコピーして他の項目を省くと、接続は確立しても再試行が続く、ハンドシェイクに失敗する、転送効率が異常になるといった問題が起こります。

• Shadowsocks：暗号化方式、パスワード、ポートを確認します。クライアントとサーバーの設定が一致しないと、通常はデータ交換を正常に完了できません。
• VMessとVLESS：UUID、Transport、TLS、Host、Path、SNIを確認します。WebSocketのPathまたはHostが誤っていると、ハンドシェイクに影響します。
• Trojan：パスワード、TLS、SNIを重点的に確認します。証明書名と対象名が一致しない場合、LogにTLS関連のエラーが表示されることがあります。
• Hysteria2：パケットロスが多いネットワークでの性能は、帯域幅、輻輳制御、サーバー側の制限に左右されます。サーバー側の設定を確認せずに帯域幅の値だけを入力しないでください。
• WireGuard：公開鍵、秘密鍵、Address、Endpoint、Allowed IPsを確認します。小さなリクエストは正常なのに大きな転送が停止する場合は、サービス事業者が許可している範囲でMTUを比較できます。たとえば1280、1380、1420を順に試し、毎回1つの値だけを変更してください。

MTUは小さければよいとは限りません。大きすぎると、一部の経路でフラグメント化や破棄が発生する可能性があります。小さすぎると、各パケットに載せられる有効データが減り、オーバーヘッドが増えます。MTUを試す際は同じノードと同じ転送タスクを使い、各回の変更後に再接続してください。サービス事業者が値を明示している場合は、その指定値を優先します。

On Demandは主にネットワーク条件に応じて接続を自動確立する機能であり、速度測定を高速化するスイッチではありません。切り分け中に接続が自動切断・切り替えされる場合は、Settings → On Demandで、SSID、ドメイン、ネットワーク状態によって既存ルールが発動していないか確認します。変更前に元の設定を記録し、テスト後は実際の利用条件に合わせて戻してください。

第5層：Logから接続のどの段階が遅いか判断する

Logの価値は、単に「速い」「遅い」と表示することではなく、リクエストが通過した段階を確認できることにあります。Settings → Logを開き、既存の記録を消去してから問題を1回再現し、時刻順にDNS、接続、TLS、ルール一致、リトライの情報を確認します。1回の再現だけを残すと、大量の履歴から探すより特定しやすくなります。

同じドメインが短時間に繰り返し解決され、その後に接続が確立する場合は、DNSを確認します。TCP確立後にTLS handshakeで長時間停止する場合は、システム時刻、SNI、TLS設定、遠隔側の応答を重点的に確認します。接続はすぐ確立するのに転送中にtimeoutやretryが連続する場合は、パケットロス、混雑、遠隔側の負荷が疑われます。

Logを読む際は、最後の1行だけでなく時間の関係に注目してください。たとえばDNSに20 ms、接続確立に70 msかかっていても、TLS段階で数秒待機しているなら、ボトルネックはドメイン解決ではありません。反対に、接続前からDNS timeoutが繰り返されている場合は、ノードを変更しても解決しない可能性があります。

1. 古い記録を消去する

   Settings → Logを開き、今回の測定と関係のない履歴を先に消去します。

2. 問題を1回再現する

   対象のアプリまたはWebページに戻り、遅くなる状態を安定して再現できる操作を1回だけ実行します。

3. 最初のリクエストを見つける

   ドメイン、対象アドレス、時刻からリクエストの起点を特定し、どのルールとポリシーに一致したか確認します。

4. 待機段階を確認する

   DNS、接続確立、TLS、データ転送の各時間間隔を比較し、最も長く停止している箇所を見つけます。

5. 単一変数で再測定する

   ネットワーク、ノード、または1つの設定値だけを変更して、もう一度再現します。該当するエラーが消えれば、問題の範囲を絞り込めます。

よくある速度問題を直接判断する

以上の段階別確認を終えると、現象の組み合わせから原因をすばやく分類できます。目的はすぐに共通の設定値を提示することではなく、次にどこを変更すべきか決めることです。利用中サービスの具体的なノード状態、ポート、転送設定は、自分のサービス事業者の情報を基準にしてください。