Shadowrocketの接続後に速度が遅い場合は、測定対象・サーバー・時間帯を固定し、Wi-Fiとモバイル通信を比較します。次に、Global Routingのモード、使用中のプロトコル設定、回線の変動、サーバー負荷を確認します。すでに自分のサービス提供元から設定またはサブスクリプションを入手している方を対象に、「接続時の遅延が小さい」「Webページの表示が速い」「ダウンロードが安定して速い」を区別し、1項目ずつ条件を変えて原因を絞り込みます。1回のPing結果だけで設定をすべて変更することは避けましょう。
1. 「遅い」を接続・初回応答・継続転送に分ける
まず、Pingの数値が小さくても帯域幅が広いとは限らず、接続をオンにしても通信が想定どおりプロキシ経由になるとは限りません。調査を始める前に、Homeで現在のサーバー、Global Routingで現在のモードを記録し、Configで使用中の設定を確認します。設定のコピーを保存し、その後は毎回1項目だけ変更してください。
Webページの表示に時間がかかる場合は、DNS、接続確立、接続先の応答が関係している可能性があります。ページはすぐ開くのに大きなファイルの転送が遅い場合は、継続的なスループットの問題が考えられます。動画の再生開始は正常でも途中で頻繁に止まる場合は、速度の変動、パケットロス、接続先による速度制限を確認します。複数の症状が同時に起きることもあるため、プロトコルの速度だけが原因とは限りません。
- 自分がアクセスする権限を持ち、繰り返し測定できるWebページまたはファイルを1つ決め、測定ごとに接続先を変えないでください。
- 接続にかかった時間、ページの表示が始まるまでの時間、転送が安定した後の速度をそれぞれ記録します。
- Wi-Fiまたはモバイル通信の別、サーバー名、Global Routingのモード、測定時刻を記録します。
- 各条件で3回測定し、失敗した回数も記録します。最速の結果だけを残さないでください。
2. ローカルネットワーク：Wi-Fiとモバイル通信を比較する
サーバー、接続先、設定を同じにして、接続ネットワークだけを変更します。Wi-Fiでは遅く、モバイル通信では正常な場合、接続ネットワークまたはそのネットワークからサーバーまでの経路に差があると考えられますが、ルーターの故障とは断定できません。無線干渉、上り回線の逼迫、ネットワークの制限、通信事業者ごとの経路の違いなどが原因になることがあります。
- Wi-Fiで3回測定して結果を記録します。電波の弱さによる影響を除くため、無線アクセスポイントの近くで測定してください。
- Wi-Fiをオフにして、モバイル通信に切り替わったことを確認します。Shadowrocketの接続をいったん切り、再接続して新しいネットワーク経路を使用します。
- サーバーと接続先を変えずに、同じ測定を行います。ダウンロード測定ではモバイルデータ通信を消費するため、データ残量を事前に確認してください。
- Wi-Fiに戻してもう一度測定します。特定のアクセスポイントでのみ繰り返し問題が起きる場合は、そのネットワークの混雑や制限を確認してください。
通常のネットワーク接続に問題がないか調べるには、もともと直接アクセスできる接続先を選び、接続を一時的に切って比較します。このとき通信は、システム標準のネットワーク経路で送信されます。テスト中に再接続されないよう、Settings → On Demandで自動接続条件を記録して一時的にオフにし、テスト後に元に戻してください。直接アクセスできない接続先を使って、ローカルネットワークの問題を判断しないでください。
| 繰り返し発生する状況 | 優先して確認する項目 | 次の確認手順 |
|---|---|---|
| Wi-Fiでは遅く、モバイル通信では正常 | 無線品質、ネットワークの混雑、サーバーまでの経路 | 同じWi-Fiでアクセスポイントを変え、サーバーはそのままにして再測定 |
| どちらのネットワークでも遅いが、直接アクセスできる接続先は正常 | プロキシ経路、サーバー、接続先 | Global Routingのモードを確認してから、すでに利用できるサーバーを比較 |
| 直接接続でもプロキシ接続でも遅い | ローカルネットワークの通信量、接続先の応答 | バックグラウンド通信を停止し、直接アクセスできる接続先も追加して比較 |
3. ルーティング：同じ経路を測定しているか確認する
Home → Global Routingで現在のモードを確認します。Configは設定したルールに従ってリクエストを処理します。Proxyはプロキシ経由の比較に、Directは直接接続の比較に使います。Sceneは選択中のシーンに従って処理されるため、テスト時には具体的なシーンも確認してください。モードが異なる測定結果を混ぜて平均しないでください。
Configではルールが上から順に評価されます。DOMAIN-SUFFIXはドメインのサフィックスに一致し、IP-CIDRとGEOIPは該当するIP条件を処理し、FINALはそれまでのルールに一致しなかったリクエストを処理します。同じWebページに見えても、画像やメディアの読み込みに別のドメインが使われ、異なるルールが適用される場合があります。トップページが開くかどうかだけでなく、リクエストログの接続先と適用ルールを確認しましょう。
- Proxyに一時的に切り替えて同じ接続先を比較する前に、元のモードを記録してください。テスト後は元の設定に戻します。
- Proxyでは正常でConfigでは遅い場合は、適用されたルールやポリシーグループ、実際に選択されている項目を優先して確認します。すぐにプロトコル設定を変更しないでください。
- モードまたはサーバーを切り替えたら、テスト用の接続を再確立します。既存の長時間接続が測定に影響する場合があります。
- 初回の表示だけが遅く、その後の転送は正常な場合は、DNSの問い合わせと接続確立の段階を確認します。DNS、ルール、サーバーを同時に変更しないでください。
4. プロトコル：設定を確認し、プロトコル変更を万能策にしない
Homeで現在のサーバーの編集画面を開き、アドレス、ポート、プロトコル設定を自分の設定情報と1項目ずつ照合します。ポート番号は速度の段階設定ではありません。速度を上げようとして、任意のサービスのポートを443に変更しないでください。プロトコル、ポート、サーバー側の待ち受け設定は一致している必要があります。アドレスを名前解決できても、認証情報や暗号化設定が正しいとは限りません。
| プロトコル | 確認するポイント | 避ける操作 |
|---|---|---|
| Shadowsocks | サーバーアドレス、ポート、パスワード、暗号化方式、設定済みのプラグインパラメータ | 暗号化方式やパスワードを単独で変更する |
| VMess / VLESS | ユーザーID、転送方式、TLSを有効にしている場合はサーバー名などの設定 | 転送方式やパスを推測で変更する |
| Trojan | パスワード、ポート、TLSサーバー名 | 証明書検証を無効にしてハンドシェイクの問題を隠す |
| Hysteria2 | 認証情報、TLS設定、接続ネットワークからUDPに到達できるか | 設定の帯域幅の値を回線速度の保証とみなす |
| WireGuard | 鍵、ピアアドレス、ポート、トンネル関連の設定 | 理由を確認せずにMTUを変更したり鍵を差し替えたりする |
Hysteria2とWireGuardはUDPの通信条件に左右されます。その他のプロトコルの実際の転送方式も、設定に応じて確認してください。同じUDP設定が特定のWi-Fiでのみ繰り返しタイムアウトし、モバイル通信では正常な場合は、まず接続ネットワークでUDPが制限されていないか確認します。プロトコルを比較する意味があるのは、サーバー側で別の互換設定が提供されている場合に限られます。クライアント側のプロトコル名だけを変更しないでください。
5. 回線・サーバー：Ping、時間帯、継続転送を組み合わせて判断
Pingが示すのは通常、往復遅延であり、継続的なスループットではありません。ICMPに応答しないサーバーでは、Pingがタイムアウトしても実際の通信を確立できる場合があります。TCP接続テストも特定ポートの接続段階を確認するもので、ファイルのダウンロードテストとは異なります。HomeのConnectivity Testを使う場合は、測定方法と接続先を確認し、異なる方法の数値をそのまま順位付けしないでください。
回線品質には、ローカルネットワークからサーバーまでと、サーバーから接続先までの経路が関係します。サーバー負荷には、CPU使用率、利用可能な帯域幅、接続数、速度制限などが関係します。通常、クライアントでの1回の測定だけでは両者を完全に切り分けられません。状況を時間帯、接続ネットワーク、接続先とあわせて記録してください。
- サーバーを固定して時間帯を比較：問題が起きる時間帯と別の時間帯に、同じテストを繰り返します。特定の時間帯だけ遅くなる場合は、混雑や負荷との関連が考えられますが、どちら側の混雑かは断定できません。
- 接続先を固定して、すでに使えるサーバーを比較：自分が利用できる既存の設定だけを比較します。特定のサーバーだけ継続して遅く、ほかは正常であれば、そのサーバーまたは関連する経路に原因を絞り込めます。
- サーバーを固定して接続先を変更：特定の接続先だけ遅く、ほかは正常な場合は、接続先の速度制限、経路、適用されるルールの違いを確認します。
- 継続転送を観察：安定して転送できている時間と停止した回数を記録します。遅延が小さくても、頻繁に停止する場合はパケットロス、再送、サーバー側の待ち行列が原因の可能性があります。
「夜間はすべての接続先が遅い」「モバイル通信に切り替えても遅い」「別の既存サーバーでは回復する」という状況であれば、記録を自分のサービス提供元に伝えて、負荷や回線を確認してもらいましょう。ただし、この結果だけではサーバーリソース不足と共有出口の混雑を区別できません。特定にはサーバー側の監視が必要です。地理的に近いことやPingが最小であることだけを選択基準にしないでください。
6. エラーが出る場合：速度測定の前に接続失敗を解消する
エラーが続く場合、テストが安定した転送段階に達していない可能性があります。以下はネットワークログで見られる一般的なエラーの一部です。実際の表示内容は接続の仕組みやエラーの発生元によって異なり、すべてのプロトコルで同じ文言が表示されるわけではありません。自分のログに該当する情報がある場合にのみ参考にし、表示されていない問題をこれらの語句から推測しないでください。
エラー：i/o timeout
原因と対処：ネットワークの読み取りまたは書き込みが所定の時間内に完了しなかった状態です。接続先に到達できない、パケットロスがある、相手が応答しないなどの可能性があります。サーバーはそのままにしてWi-Fiとモバイル通信を切り替えて再測定し、接続時と転送時のどちらでタイムアウトするか確認してください。
エラー：connection refused
原因と対処：接続要求が接続先または途中のネットワーク機器に拒否されています。単なる帯域幅不足ではありません。アドレス、ポート、サービスが現在も有効かを確認し、該当ポートのサービス状況を自分のサービス提供元に問い合わせてください。
エラー：certificate has expired
原因と対処：証明書の有効期限が切れていると判定された状態です。デバイスの日付と時刻の異常も確認してください。まずシステムの日付と時刻を確認し、サービスの管理元に証明書を確認してもらいます。速度改善のために証明書検証を無効にしないでください。
自分のサブスクリプションで最近アドレスやポートが変更された場合は、Homeで該当するサブスクリプションを選んで更新し、現在選択中のサーバーを確認します。更新後は、ConfigとGlobal Routingが元のテスト条件に合っているか確認してください。サブスクリプションの更新は既存の設定を同期するもので、回線品質を保証するものではありません。繰り返し測定する間に同時に変更する項目にしないでください。
7. よくある質問と設定の復元
Pingが数十ミリ秒なのに、ダウンロードが遅いのはなぜですか？
遅延とスループットは別の指標です。現在のサーバーと接続先を維持したまま一定時間転送を測定し、速度の単位、停止の有無、時間帯を記録してから、別の接続先と比較してください。Pingだけで帯域幅の制限や接続先の速度制限を除外することはできません。
Wi-Fiでは遅く、モバイル通信では速い場合、プロトコルの選択を間違えていますか？
すぐには判断できません。同じプロトコルとサーバーを使い、接続ネットワークを切り替えた後に再接続します。差が繰り返し発生する場合は、Wi-Fiの混雑、UDPの制限、経路の違いを確認してください。プロトコルとネットワークを同時に変更しないでください。
MTUをすぐに変更したり、すべてのオプションを有効にしたりすべきですか？
まず現在の値を維持してください。小さなリクエストは正常でも大容量の転送が止まることは手がかりになりますが、それだけでMTUの問題とは断定できません。現在のトンネルに合った設定値、または明確な診断根拠を得てから、1項目ずつ変更して再測定してください。
測定後にどの設定を元に戻せばよいですか？
元のサーバー、Global Routingのモード、Configに戻します。Settings → On Demandで自動接続条件も元に戻してから再接続し、普段使う接続先を確認してください。テスト記録を削除する前に、最終的に有効だった設定を保存してください。
自分のサービス提供元に問い合わせる際は、接続ネットワーク、サーバー識別情報、プロトコル、測定時間帯、接続先の種類、繰り返し測定した結果を伝えます。スクリーンショットやログを共有する前に、サブスクリプションのtoken、パスワード、ユーザーID、鍵を隠してください。回線と負荷をまだ区別できない場合は、「クライアント側の比較ではまだ特定できない」と明記すると、「速度が遅い」とだけ伝えるよりも原因を調べやすくなります。
- 結論には、「同じサーバーでWi-Fiでは3回とも停止し、モバイル通信では3回とも正常」のように再現可能な状況を優先して記載し、推測を確定した原因のように書かないでください。
- ConfigとProxyのどちらで測定したか、接続を再確立したかを記載し、異なる経路の結果を比較しないようにします。
- 元のエラー文と発生時刻を保存します。ただし、サブスクリプションのリンクや認証情報をすべて公開しないでください。