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

1. テスト条件をそろえ、遅い箇所を確認する

接続スイッチがオンでも、システムのトンネルが確立したことを示すだけで、対象のリクエストが選択したノードを経由して正常に完了したとは限りません。Webページの初回表示が遅い場合、継続的なダウンロードが遅い場合、動画が頻繁にバッファリングする場合では、原因が異なります。初回表示の遅さにはDNSや接続確立が関係することがあり、後者では継続的なスループットと通信の安定性を確認する必要があります。

Homeで現在のノード、Global Routingの状態、ローカルネットワークを記録し、Configで使用中の設定を確認します。テスト中にサブスクリプションの更新、DNSの変更、プロトコルの切り替え、ルールの編集を同時に行わないでください。速度が戻っても、どの変更が有効だったのか判断できなくなります。

1. アクセス権があり、繰り返し読み込める固定のページまたはファイルを選び、対象名を記録します。異なるサイトのダウンロード速度をそのまま比較しないでください。
2. システムアップデート、写真の同期など、大容量通信を行うタスクを一時停止します。約30秒のテストを3回続けて行い、初回表示までの時間、継続速度、通信が中断するかを記録します。
3. 速度の単位をそろえます。1 MB/s は約 8 Mbps です。ファイルのダウンロード表示に使われる MB/s と、回線速度の公称値に使われる Mbps を同じ数値として扱わないでください。
4. 各テストでは条件を1つだけ変更し、できるだけ近い時間帯に比較します。モバイル通信でテストするとデータ通信量が発生するため、事前に契約プランの残量を確認してください。

2. ノード：接続できるか、通信速度が出るかを切り分ける

Homeで既存ノードのConnectivity Testを実行し、明らかに到達できない項目を先に除外します。遅延テストでわかるのは指定された方法での応答状況であり、ダウンロード帯域ではありません。テスト先、ハンドシェイクの手順、プロキシ経由の有無が数値に影響するため、最小のミリ秒数だけで使い勝手を判断しないでください。

既存のサブスクリプションからノードを2つ選び、できるだけ同じプロトコルで、同じ接続先・同じローカルネットワークを使って比較します。一方だけ継続的に遅い場合は、そのノードまたは経由する経路に問題を絞り込めます。ただし、それだけでサーバーの負荷が原因だとは断定できません。

3. 回線：時間帯とネットワークを組み合わせて比較する

回線は、ノード一覧にある独立したスイッチではありません。1回のアクセスには、ローカルネットワークからサーバーまでと、サーバーから接続先サイトまでの少なくとも2つの経路が関わります。ノード名と地域が同じでも、実際のルーティングや混雑状況、接続先コンテンツの配信状況は変わることがあります。地理的な距離が近くても、ネットワーク経路が短いとは限らず、混雑する時間帯に安定するとも限りません。

1. 同じノードでネットワークを変える：iPhoneでWi-Fiをオフにし、モバイル通信で同じ接続先にアクセスします。その後、Wi-Fiに戻して再テストします。それ以外の条件は変えません。
2. 同じネットワークで時間帯を変える：問題が起きる時間帯と、比較的空いている時間帯にそれぞれテストします。「夜は遅い」とだけ記録せず、時刻と継続速度を記録してください。
3. 同じノードで接続先を変える：互いに独立した2つのサイトでテストします。片方だけ遅い場合は、ローカルDNSを変更し続けるのではなく、出口からその接続先までの経路を確認します。
4. 複数条件の結果を整理する：「Wi-Fiは遅いが、モバイル通信は正常」「同じ時間帯にどちらのネットワークでも遅い」のように記録します。前者はWi-Fi接続とその上流経路を優先して確認し、後者はノードと接続先の結果も踏まえて判断します。

同じノードを2種類のネットワークで比較しても、「通信事業者の回線」と「ローカルの無線環境」を完全に切り分けることはできません。Wi-Fiであらゆるアクセスが遅い場合は、後述のローカルネットワークの確認を先に行います。特定のプロキシ経路だけが遅い場合は、回線の範囲をさらに絞り込みます。複数のノードが同じ上流経路を共有することもあるため、複数のノードが同時に遅くなっても、独立した障害が複数発生しているとは限りません。

4. プロトコル：通信条件を確認し、むやみにポートを変更しない

プロトコル名は速度のランクを示すものではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは通信条件や設定項目が異なり、利用できるかどうかはサーバー側の実装によります。既存ノードのプロトコル選択欄を別の名称に変えるだけでは、プロトコルの比較テストにはなりません。

ポートが443だからといって、必ずTCPを使用するわけでも、通信が必ず成功するわけでもありません。Hysteria2はUDP 443を使用できますが、実際のポートはサーバー側の設定によります。ネットワークでUDPが制限されている場合、UDPに依存する接続は失敗したり不安定になったりする可能性があります。一方、UDPが利用できても、混雑時に高いスループットが得られるとは限りません。

• サービス提供元から案内されたサーバーアドレス、ポート、認証情報を確認します。TLSを使う場合は、サーバー名と証明書の検証設定も確認してください。検証を無効にして問題を回避しないでください。
• 既存の設定に比較可能な別プロトコルの接続先がある場合に限り、プロトコルを比較します。サーバーや回線も同時に変わる場合は「複数条件の比較」と記録し、差をすべてプロトコルの違いに帰さないでください。
• 小さなリクエストは正常でも、大きなファイルの転送が何度も止まる場合は、まずネットワークを変えてテストします。MTUやPath MTUが原因の可能性もありますが、記録を取らずに複数の値を続けて変更しないでください。

上記は接続ログに表示される場合がある低レベルのエラー文であり、すべての障害で必ず表示されるものではありません。最後の1行だけでなく、前後を含むログを記録することが重要です。

5. ローカルネットワークとルール：リクエストの実際の経路を確認する

Homeに戻り、Global Routingを確認します。Proxy、Direct、Config、Sceneはそれぞれ異なるルーティング方式です。ProxyとDirectは全体のプロキシ利用または直接接続の方針、Configは現在の設定に基づく処理、Sceneは選択中のシーンの設定に関係します。比較テストの前に元の状態を記録してください。一時的に切り替えた場合は、テスト後に戻し、診断のための変更をルーティング設定の戻し忘れにつなげないようにします。

1. ローカル接続を確認する：ルーターの近くで再テストし、Wi-FiのWeb認証待ちになっていないか確認します。デバイスのネットワーク環境が許し、接続先に直接接続できる場合は、短時間だけ接続をオフにして基準値を測ります。直接接続でも遅い場合は、まずネットワークへの接続自体を確認してください。
2. 適用されたポリシーを確認する：Configで使用中の設定を確認し、接続ログからテスト対象に適用されたルール、ポリシー、ノードを確認します。ノードを選択していても、すべてのリクエストがそのノードを経由するとは限りません。
3. ルールの順序を確認する：DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはアドレス範囲、GEOIPはIPの位置情報データに基づいて照合し、FINALは最終的なフォールバックに使われます。先行するルールに一致していないかを確認し、最後のルールだけを変更しないでください。
4. 自動再接続を確認する：テスト中に接続状態が自動で変わる場合は、Settings → On Demandを確認します。現在の条件を記録してから、関連する自動接続の動作を一時的にオフにし、手動テストの後に元の状態へ戻します。

DNSの確認は、症状から関連が考えられる場合に行います。たとえば、初回の読み込みには時間がかかる一方、接続確立後のダウンロードは正常な場合です。まず名前解決のタイムアウトや失敗、接続先アドレスの異常がないかを確認し、現在の設定にあるDNSを見直します。「DNSを変える」ことをあらゆる速度低下に対する万能策にしないでください。また、証明書の検証を無効にしたり、直接接続の範囲をむやみに広げたりしないでください。

6. よくある質問と、調査を終える目安

問い合わせに必要な情報は、発生時刻、Wi-Fiまたはモバイル通信の別、ノード識別情報、プロトコル、Global Routingの状態、接続先、速度の単位、比較結果です。調査の目的は「最速の設定」を見つけることではなく、どの層に問題があるか、どこに追加調査を依頼すべきかを判断することです。クライアント以外の接続環境やリモート経路で一貫した異常が見られる場合、ローカル設定を変更し続けても通常は解決しません。