Shadowrocketの速度が遅いときの切り分け：ノード・経路・プロトコル・ローカルネットワークを4層で確認

始める前に：「遅い」を再現可能な現象にする

Shadowrocket（Shadowrocket）で接続済みと表示されても、システムのVPNトンネルが確立したことを示すだけで、すべてのリクエストが同じスループットになるわけではありません。ウェブページの初回表示、動画のバッファリング、ファイル転送の遅さ、アプリが一時的に読み込み中になる現象は、それぞれDNS応答、接続ハンドシェイク、持続帯域幅、パケットロスや揺らぎに関係する可能性があります。確認前に現象を具体化し、「なんとなく遅い」だけで記録しないようにします。

繰り返しアクセスできるウェブページ、自分で管理しているか長期間安定しているファイルの取得先、同じアプリ操作を1つずつテスト対象にします。各回は少なくとも60秒続け、3回連続で実行し、初回と後2回の結果が近いかを記録します。初回だけ遅く、その後回復する場合はDNS、TLSハンドシェイク、キャッシュの違いが考えられます。3回とも遅い場合は、スループットや経路の問題に近いと判断できます。

テスト条件を固定する

1. Homeで既存のノードを1つ選び、テスト中は頻繁に切り替えないでください。
2. Global Routingの現在の状態を確認し、結果を記録します。ルールの影響を確認する場合はProxyを比較用に使い、通常の設定ではConfigを維持します。
3. 実行中の大容量ファイル同期、システムアップデート、その他帯域幅を継続的に使用する処理を停止します。
4. Wi-Fiとモバイル通信のどちらを使っているか、テスト時刻、ノード名、プロトコル、3回連続で現れた現象を記録します。
5. テスト後は元のGlobal Routingに戻し、一時的な比較設定を通常設定として残さないようにします。

リクエストは実際には複数の段階を通過します。Homeの遅延テストが主に示すのは探測リクエストの往復時間であり、完全なダウンロード速度ではありません。低遅延と表示されるノードでも、継続転送時に負荷、混雑、パケットロスの影響を受けることがあります。逆に、遅延がやや大きいノードのほうが、継続スループットが安定する場合もあります。したがって遅延値は初期選別に使うもので、単独では結論にできません。

第1層：単一ノードの負荷かどうかを確認する

ノード層の問題は、同じネットワーク、同じ時間帯、同じテスト対象で、既存ノードの1つだけが3回連続で遅く、同じ設定内の他のノードは明らかに安定しているという形で現れます。比較するのはすでに保有しているノード項目であり、名前、地域ラベル、1回の遅延結果だけで判断してはいけません。

まずHomeで現在のノードの遅延テストを実行し、別の既存ノードを選んで同じ操作を繰り返します。切り替え後は接続状態が安定するまで待ち、テスト対象を再度開きます。すでにキャッシュされたページをそのまま使わないでください。2つのノードが同じプロトコルなら、ノード負荷に原因を絞り込みやすくなります。プロトコルも異なる場合は「ノードまたはプロトコル、未分離」と記録し、第3層で検証します。

ノード層での実際の確認手順

• Global Routing → Proxyを短時間の比較条件として維持し、異なるテストリクエストが別のポリシーに振り分けられる可能性を除外します。
• 自分が保有するノードを2〜3個選び、各ノードで同じテストを3回行います。テスト途中でサブスクリプションを更新しないでください。
• 「初回表示までの時間」と「継続転送が安定しているか」を同時に記録し、1つの評価にまとめないでください。
• 完了後にConfigへ戻し、ルールモードで結果が変わるか確認します。

第2層：時間帯と経路の混雑を見分ける

経路層の問題には、はっきりした時間的な特徴が現れることがあります。たとえば日中は安定しているのに夜間の決まった時間帯だけ低下する、または平日と週末で挙動が異なる場合です。ノード自体が変わっていなくても、ローカルネットワークからノード入口までの経路が特定の時間帯に混雑することがあります。この種の問題では、その場で設定を次々に変えると、一時的な回復を特定の項目の効果と誤認しやすくなります。

最小限の記録で構いません。朝、昼、夜に1回ずつ、同じネットワーク、ノード、対象、Global Routingでテストします。2日間続けて記録し、遅さが近い時間帯に集中し、Wi-Fiとモバイル通信で結果が異なるなら、まずローカルの接続経路を確認します。両方の接続方法が同じ時間帯に低下するなら、共通経路またはノード入口の負荷に近いと考えられます。

現象から時間帯の問題を見分ける

• 毎日ほぼ同じ時間帯に遅くなる：テスト記録を残し、各回でプロトコルやルールを変更しないでください。
• Wi-Fiは遅いがモバイル通信は正常：ルーターとの距離、無線帯域、電波を遮るもの、同じネットワーク上の端末による使用量を優先的に確認します。
• 両方のネットワークが遅い：別の既存ノードで1回比較し、共通するノード入口の問題か判断します。
• 速度テストは正常だが特定のサイトだけ遅い：ルールの適用結果、DNSの結果、対象サイト自体の応答を確認し、経路全体の問題と決めつけないでください。

ピーク値と安定値も分けて見ます。開始数秒だけ高い値が出て、その後下がり続ける場合は、輻輳制御、パケットロス、サーバー側の速度制限が原因かもしれません。全体を通して安定しているものの上限が低い場合は、固定的な帯域条件に近いと考えられます。最高値を1つだけ書き写すより、推移を記録するほうが有用です。

第3層：プロトコルの特性と設定不一致を切り分ける

ShadowrocketはShadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどのプロトコルに対応していますが、「プロトコル名」だけで速度が決まるわけではありません。実際の結果は、トランスポート層、暗号方式、TLS、UDPの利用可否、MTU、サーバー設定、ローカルネットワークの品質にも左右されます。プロトコルを比較するときは、自分のサービス提供者が用意し、正しく設定した項目を使ってください。

Shadowsocksの挙動は、使用する暗号方式、サーバーの処理能力、TCPまたはUDPのトラフィックに左右されます。VMessとVLESSは異なるトランスポート方式と組み合わせられる場合があり、追加のカプセル化やTLSハンドシェイクが初回接続時間に影響します。TrojanはTLS over TCPの構成で使われることが多く、パケットロスがあると再送が目立つ場合があります。Hysteria2はQUICとUDPを基盤とするため、UDPへの対応状況とパケットロスの影響を受けます。WireGuardもUDPに依存し、MTUが適切でないと小さなリクエストは正常でも大容量通信が止まることがあります。

サーバー側に関係するパラメータを不用意に変更しない

プロトコルのパラメータはサーバー側と一致している必要があります。ポート、パスワード、UUID、キー、Server Name、Public Key、トランスポートパスのいずれかが一致しないと、接続失敗や再試行を繰り返す原因になります。速度の確認を、これらの項目を無作為に変更することから始めないでください。まず、読み込んだ項目がサービス提供者の元の設定と一致しているか確認します。

同じサービスで、目的地が近くプロトコルだけ異なる項目を自分が保有している場合は、ローカルネットワークとテスト対象を固定して比較できます。各プロトコルで同じテストを3回行い、初回応答と継続スループットを分けて記録します。プロトコルだけが主な変数である場合に限り、この比較に意味があります。

第4層：ローカルのWi-Fi、モバイル通信、システム接続条件を確認する

ローカルネットワークは最も見落とされやすい層です。Wi-Fiの電波表示が多くても、無線環境に干渉がないとは限りません。同じ部屋の別の端末が継続的にアップロードしていると、遅延が上がり、ダウンロード速度が低下することもあります。最も直接的な確認方法は、ノード、プロトコル、テスト対象を固定し、Wi-Fiとモバイル通信だけを切り替えることです。

モバイル通信は安定しているのにWi-Fiが大きく変動する場合は、まずルーターに近づいて再テストし、同じネットワーク上の大容量処理を一時停止します。近づくと回復するなら、電波減衰や無線干渉の可能性が高くなります。距離を変えても影響がなく、他の端末の転送を止めると回復するなら、ローカルネットワークの帯域使用量に近い問題です。逆にWi-Fiは正常でモバイル通信が遅い場合は、現在地の電波品質とモバイルネットワークの混雑を考慮します。

1. Homeで同じノードを維持し、設定を更新または切り替えないでください。
2. Wi-Fiで3回テストし、各回の初回応答と継続的な挙動を記録します。
3. Wi-Fiをオフにし、モバイル通信の状態が安定するまで待ってから、同じ対象で3回テストします。
4. 差が明らかな場合は、短時間の変動を除外するため元のネットワークに戻ってもう一度テストします。
5. 両方のネットワークが遅い場合は、ノード層または経路層に戻って確認を続けます。

On Demandによる接続切り替えを確認する

Settings → On Demandを開き、ネットワーク条件に応じて自動接続するルールが有効になっているか確認します。On Demandは主に接続を確立するタイミングを決める機能で、帯域幅を直接増やすものではありません。ただし条件が繰り返し一致すると、ネットワーク切り替え時に接続が再確立されることがあります。Wi-Fiからモバイル通信へ移動したとき、または特定のWi-Fiに再接続した後だけ遅い場合は、比較のため一時的にOn Demandをオフにしてテストし、その後元の設定に戻します。

Global Routingも記録対象にします。Proxyはリクエストを現在のプロキシポリシーに統一して通すため、短時間の比較に適しています。Directは直接接続のテストに使います。Configはルールに従って振り分け、Sceneは設定済みのシーンに基づいて処理します。ProxyとConfigの結果が異なる場合は、プロトコルをさらに変更するのではなく、ルールとDNSを確認します。

ルール、DNS、サブスクリプション更新：混同しやすい現象を切り分ける

4層の確認後、特定のドメインやアプリだけで速度問題が起きる場合は、Configのルール適用を確認します。Shadowrocketは設定の順番に従ってルールを処理し、先にあるルールが先に適用されます。DOMAIN-SUFFIXはドメインの末尾を、GEOIPはIPの地理情報を、IP-CIDRはアドレス範囲を照合し、FINALはそれまでに一致しなかったリクエストを処理します。

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

上記の断片は適用順を示すもので、既存の設定をそのまま置き換えるのに適しているとは限りません。Configでは遅いのにProxyへ切り替えると回復する場合は、まずDIRECT、適さないポリシー、または早い段階にある広範囲のルールに一致していないか確認します。どちらの状態でも遅いなら、ルールは主な変数ではありません。

DNSの問題は「アドレスを入力してから長く待つが、ページの読み込みが始まると速い」という形で現れることがあります。これは継続帯域の問題とは異なります。設定内のDNSを確認するときは、既存設定の説明に従い、複数の名前解決項目を同時に変更しないでください。ドメインルールとIPルールの結果は、名前解決されたアドレスの影響を受ける場合があるため、DNSとルールを組み合わせて確認します。

サブスクリプション更新と速度テストは分けて行う

サブスクリプション更新は、サービス提供者が用意したノード一覧と設定内容を取得する処理であり、速度を最適化する操作ではありません。テスト中に更新すると、ノード項目やパラメータが変わり、前後の結果を直接比較できなくなることがあります。まず固定した設定で一連のテストを完了し、その後に更新の問題を別途確認します。

サブスクリプション形式を手動で確認する場合、例のアドレスはhttps://example.com/sub?token=xxxxのようになります。ドメインとトークンはいずれもダミー値です。実際のリンクは自分のサービス提供者から取得してください。リンクには通常アクセス情報が含まれるため、公開や転送は避けます。

結論を出す：最小限の変更で一連の確認を完了する

有効な切り分けの目的は、一時的に最速となる組み合わせを探すことではなく、遅さがどの層で発生しているかを特定することです。ノード層では単一項目の異常、経路層では時間帯と経路、プロトコル層ではトランスポート特性とパラメータの一致、ローカルネットワーク層ではWi-Fi、モバイル通信、システム接続条件を確認します。4層には関連がありますが、変数を管理すれば範囲を段階的に絞り込めます。

1. 基準を固定：同じ対象、同じノード、同じプロトコル、同じGlobal Routingで3回連続テストします。
2. ノードだけ変更：単一ノードの負荷か判断し、1回の遅延値を継続テストの代わりにしないでください。
3. 時間帯だけ変更：朝、昼、夜に同じ条件で記録し、安定した時間的傾向があるか確認します。
4. プロトコルだけ変更：既存の正しいパラメータの項目を使い、初回応答と継続スループットを分けて記録します。
5. 接続方法だけ変更：Wi-Fiとモバイル通信を比較し、ローカルネットワークが主な変数か確認します。
6. Configに戻る：Proxyは正常なのにConfigで異常が出る場合は、ルールの順番、DNS、ポリシーの適用結果を確認します。

テスト完了後は、現象を説明できる調整だけを残し、比較のために一時変更した設定を元に戻します。問題がサブスクリプション内容、サーバーのパラメータ、ノード状態に集中している場合は、テスト時刻、ネットワーク種別、プロトコル、繰り返し結果を添えて自分のサービス提供者に問い合わせます。問題がローカルWi-Fiでのみ起きる場合は、ルーターの環境とローカルネットワークの使用量を引き続き確認します。

ShadowrocketはAppleプラットフォーム向けの有料商用クライアントです。主な利用端末はiPhoneとiPadで、Mac、Apple TV、Apple Visionの互換性とシステム要件はApp Storeページの記載に従います。アプリは買い切り方式で、開発者はShadow Launch Technology Limited、アプリIDは932747118です。クライアントの購入と、ユーザー自身が利用する通信サービスは別の内容です。