Shadowrocket接続後のレイテンシ、Webページの初回表示時間、継続的な転送速度は、それぞれ異なる指標です。利用中のサービスやサブスクリプションがあり、設定を読み込めても通信が遅い場合に向けて、測定条件をそろえたうえでノード、経路、プロトコル設定、ローカルネットワークの順に確認し、接続ログから問題の箇所を絞り込みます。
1. レイテンシの高さ・初回表示の遅さ・転送速度の低下を見分ける
HomeのConnectivity Testでは、選択したテスト方法での接続性と応答時間を確認できます。回線帯域を証明するものではありません。テスト先や方法、実際にアクセスするWebサイトが異なれば、結果も変わります。リスト上のレイテンシが低くても、動画が途切れず再生できるとは限らず、大容量ファイルの転送が速いとも限りません。
まず、どのような遅さかを書き出します。すべてのWebサイトが遅いのか、特定のドメインだけなのか。初回表示まで待たされるのか、読み込み途中で止まるのか。一日中続くのか、決まった時間帯だけなのか。サブスクリプションの更新、DNSの変更、プロトコルの切り替え、ネットワークの変更を同時に行うと、改善しても原因を特定できません。
| 症状 | 優先して確認する項目 | 判断時の注意点 |
|---|---|---|
| 初回表示は遅いが、その後は正常 | DNS、接続確立、TLSハンドシェイク | キャッシュが2回目の結果に影響する場合があります |
| ページはすぐ表示されるが、大容量ファイルの転送が遅い | 経路のスループット、輻輳、接続先による速度制限 | 低レイテンシでも帯域が広いとは限りません |
| 特定のWebサイトだけ遅い | 対象ドメインに適用されるルールと接続先のサービス | それだけでノード全体の障害とは判断できません |
| すべてのリクエストがタイムアウトする | ローカルネットワーク、ノードへの到達性、認証設定 | まず接続が確立することを確認してから速度を調べます |
速度の単位もそろえて比較しましょう。8 Mbpsは、プロトコルのオーバーヘッドを考慮しない場合、約1 MB/sです。あるページがMbps、別のツールがMB/sで表示している場合、数値をそのまま比較できません。以降の記録には単位、測定時刻、接続先も残してください。
2. 測定条件をそろえ、実際の通信経路を確認する
Shadowrocketでは、Homeで接続とノード選択、Configで設定ファイル、Settingsでアプリの設定を確認できます。速度を調べる前に、現在のノードとGlobal Routingを確認し、適用中の設定をチェックしてください。システムにVPNの表示があっても、すべてのリクエストが選択中のプロキシノードを経由するとは限りません。
-
現在の状態を記録する
Homeで選択中のノード名とGlobal Routingの現在値を記録し、Configで使用中の設定ファイルを確認します。必要な設定は控えておきますが、記録にパスワードやサブスクリプションURL全体を含めないでください。
-
ルーティングモードを固定する
Home → Global Routingを開きます。Proxyはプロキシ経由、Directは直接接続の比較に使い、Configは設定に基づいて通信を振り分けます。Sceneを使用中の場合は、そのSceneに適用されるポリシーを確認してください。異なるモードでの結果を同じ条件の測定として扱わないようにします。
-
自動接続を確認する
Settings → On Demandで、設定済みの条件を確認します。テスト中に手動で接続を切る必要がある場合は、On Demandを一時的にオフにして元の状態を記録します。条件に応じた再接続で、Directとの比較が妨げられるのを防げます。
-
同じテストを繰り返す
HomeでConnectivity Testを使い、テスト方法を変えずに3回連続で結果を記録します。その後、同じ接続先にアクセスし、初回の読み込みと継続的な転送をそれぞれ確認します。大容量の通信を複数同時に実行しないでください。
-
元の設定に戻す
比較テストの一組が終わるごとに、一時的な変更を元に戻します。すべてのテストが終わったら、Global Routing、設定ファイル、On Demandを元の状態に戻し、診断用のProxyやDirectをそのまま使い続けないようにしてください。
3. ノードと経路を確認する：変更する条件は一度に一つ
ノードは接続先のエンドポイントです。経路は、現在のネットワークからそのエンドポイントを経由して、目的のサービスに届くまでの実際の通信ルートを指します。ノード名の地域表示だけでは、経路全体や現在の負荷は分かりません。同じノードでも、自宅のブロードバンドとモバイル通信で速度が異なる場合は、接続ネットワーク、経路の輻輳、UDPの到達性などが関係していることがあります。
- 登録済みのノードだけで比較：同じWi‑Fi、同じGlobal Routing、同じ接続先で、登録済みのノードAをノードBに切り替えます。それ以外の条件は変えず、接続性と継続的な転送速度をそれぞれ記録します。
- 時間帯も考慮：夜間だけ遅い場合は、別の時間帯にも同じテストを行います。一度の測定では、一時的な輻輳と継続的な障害を区別できません。
- 接続先ごとの差を確認：同じノードでほかの接続先には正常にアクセスでき、特定のサービスだけ遅い場合は、その接続先に適用されるルールとサービスの状態を確認します。ノード全体が使えないとすぐに判断しないでください。
- サブスクリプションの更新内容を確認：Homeで自分のサブスクリプションを下に引っ張って更新し、選択中の項目を確認します。更新によってアドレス、ポート、項目が変わることがあります。以前の記録をそのまま当てはめないでください。
以下は記録方法の例であり、本サイトで測定したデータではありません。同じ接続先、同じ時間帯で、ノードAはWi‑Fiで3回の応答時間が80 ms / 85 ms / 82 ms、転送速度は0.5 MB/sでした。一方、ノードBは応答時間が120 ms / 125 ms / 122 msでも、転送速度は3 MB/sでした。このように、応答時間と継続的なスループットは別々に判断する必要があります。最小レイテンシだけで順位を決めないでください。
Wi‑Fiでは登録済みのすべてのノードが遅く、モバイル通信では正常なら、まずローカルネットワークを確認します。特定のノードだけがどちらのネットワークでも失敗する場合は、そのエンドポイントと設定を優先して確認してください。利用中のサービス提供元に問い合わせる際は、「遅い」とだけ伝えるより、発生時刻、接続ネットワーク、識別情報を伏せたノード名、エラーメッセージを添えると原因を絞り込みやすくなります。
4. プロトコル設定を確認する：最適化の前に接続設定を正しくする
Typeをむやみに変更して速度を上げようとしないでください。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは、サーバー側の設定がそれぞれ異なり、相互に使い回せません。実際にサーバーが対応し、必要なパラメーターがすべて提供されているプロトコルだけを使用できます。既存の項目でプロトコル名だけを別のものに変更すると、通常は接続できなくなります。
| プロトコル | 重点的に確認する項目 | よくある誤認 |
|---|---|---|
| Shadowsocks | アドレス、ポート、暗号化方式、パスワード | 認証情報の不一致を、経路の遅さと誤認する |
| VMess / VLESS | UUID、転送方式、TLS、Host、Path | 転送方式やPathの不一致で接続を確立できない |
| Trojan | パスワード、ポート、TLS、SNI | SNIの誤りを一般的なタイムアウトと誤認する |
| Hysteria2 | 認証、TLS、SNI、UDPの到達性 | 接続ネットワークでUDPが制限され、再試行しても改善しない |
| WireGuard | 鍵、Endpoint、アドレス、Allowed IPs、MTU | ハンドシェイクは確認できても、ルーティングや大きなパケットの転送に問題がある |
ポートは使用中の設定と一致させてください。サーバー側が8443を使用している場合、443が一般的だからといって置き換えることはできません。ポート番号は速度を示すものではありません。TLSのSNIと証明書の検証もサーバーの指定に従って確認し、証明書検証を無効にして設定ミスを隠さないでください。
Hysteria2とWireGuardはUDPを使用します。特定のWi‑Fiで接続できず、同じ設定がモバイル通信では正常に動作する場合は、まずネットワーク環境を確認してください。一度の失敗だけでプロトコルが使えないと判断することはできません。どのネットワークにも当てはまるMTUの「最適値」もありません。小さなリクエストは通るのに大容量通信が停止するなど、明確な兆候がある場合に限り、既存の設定資料に従って一つの値だけを変更し、元の値も記録してください。
エラー：connection refused
原因と対処：接続先または途中の機器が接続を明示的に拒否しています。ポートで待ち受けていないか、アクセスがポリシーで拒否されている可能性があります。AddressとPortを確認し、利用中のサービス提供元にエンドポイントの状態を確認してください。DNSを何度も変更しても、ポートによる拒否は通常解決しません。
エラー：i/o timeout
原因と対処：処理が制限時間内に完了しませんでした。通信経路、接続先の応答、UDPの到達性などが関係している可能性があります。接続処理のどの段階でエラーが出たかを確認し、同じ設定のままWi‑Fiとモバイル通信を切り替えて比較してください。timeoutだけを根拠にパスワードを変更しないでください。
エラー：tls: handshake timeout
原因と対処：TLSハンドシェイクが制限時間内に完了していません。パケットロス、エンドポイントの状態、ハンドシェイク設定などが原因として考えられます。まずポート、TLS、SNIを確認してから、異なる接続ネットワークで比較してください。証明書検証の無効化を万能な解決策として扱わないでください。
これらは接続ログに現れる可能性があるエラーの原文です。外側のメッセージや前後の状況は異なる場合があります。関連する行を省略せずに保存し、接続先への接続失敗と最終的な接続先へのアクセス失敗を区別してください。共有する前に、認証情報、サブスクリプションのトークン、不要な個人のアクセス記録を削除します。
5. ローカルネットワーク、DNS、ルールの適用先を確認する
ローカルネットワークの確認は、変更を最小限にして進めます。ノードを変えず、同じ場所でWi‑Fiとモバイル通信を比較し、次に同じWi‑Fiのままルーターに近づいて再試行します。公共Wi‑FiでWeb認証が必要な場合は、先にネットワークへログインしてください。電波が弱い、ほかの機器が上り回線を使用している、ルーターが混雑しているといった要因で通信が遅くなることがあります。アプリを再インストールしても、これらの問題は解決しません。
上記は問題箇所を特定するための簡略化した流れです。DNSの名前解決は複数の段階に関わることがあります。Global RoutingがConfigの場合は、Configで使用中のファイルのルール順を確認し、接続ログから実際に適用されたポリシーを調べます。ルールは通常上から順に照合され、先に一致したルールが後続の通信経路に影響します。プロキシ経由だと思っていたWebサイトの通信が、実際にはDirectに一致しているケースは、よくある測定条件のずれです。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYこのコードはルールの照合構文を示すもので、そのまま置き換えて使える完全な設定ではありません。DOMAIN-SUFFIXはドメインの末尾に一致します。IP-CIDRはIPアドレスの範囲に一致し、例のno-resolveはこのルールのためにドメイン名の解決を行わないことを示します。GEOIPはIPアドレスの地域データベースに基づいて判定します。FINALは、それまでのルールに一致しなかったリクエストを受け持ちます。PROXYに対応するポリシーも、実際の設定で有効になっている必要があります。
- ドメインでのアクセスだけに問題がある：名前解決に失敗していないか、結果が現在のネットワーク環境に合っているかを確認します。HTTPSサイトをIPアドレスで直接開く方法は、確実な代替手段ではありません。証明書や仮想ホストがドメイン名を必要とする場合があります。
- Configでは遅く、Proxyでは正常：すぐにノードを変更せず、対象に適用されるルール、DNSの経路、ポリシーの選択を比較してください。
- すべてのネットワーク通信が遅い：本体または同じネットワーク内で、システムアップデートやクラウド同期などの通信が並行していないか確認してから、もう一度測定します。
- 特定の無線環境だけ遅い：まず電波強度と干渉を確認します。周波数帯を切り替えた後も接続先とノードを変えずに測定し、改善が無線区間によるものか判断してください。
6. 比較結果から問題の範囲を絞り込む
調査後は、問題を具体的な条件で説明できる状態を目指します。たとえば「同じノードと接続先でも、自宅のWi‑FiでのみUDP接続がタイムアウトする」なら、「設定をいろいろ変えても遅い」より次の対応を決めやすくなります。設定の破損を示す根拠がなければ、サブスクリプションを削除したり、すべてのルールを作り直したりする必要はありません。
Connectivity Testでは数十ミリ秒なのに、動画が途切れるのはなぜですか？
Connectivity Testの応答時間は、動画の接続先に対する継続的なスループットを示すものではありません。Homeでノードを変えずに、Global Routingとその接続先に適用されるルールを確認してから、読み込みを続けて観察します。そのサービスだけが途切れる場合は、接続先までの経路やサーバー側の制限を確認してください。
モバイル通信に切り替えると直るのはなぜですか？
同じ設定が、少なくとも別の接続環境では動作するということです。ノードとプロトコル設定はそのままにし、Wi‑Fiに戻してWeb認証、電波強度、並行通信、UDPの状態を確認してください。設定全体を一度に変更しないでください。
サブスクリプションを更新したら急に遅くなりました。削除して再読み込みすべきですか？
まずHomeで選択中の項目を確認し、更新後のアドレス、ポート、プロトコル設定と、Global Routingが元のモードかどうかを調べます。項目に変更があれば、内容を確認してください。削除して再読み込みすると手動のメモが失われる可能性がある一方、エンドポイントの問題が解決するとは限りません。
接続を切っても毎回自動で再接続します。Directでテストするにはどうすればよいですか？
Settings → On Demandで条件を確認し、一時的にオフにしてから手動で接続を切ります。ローカルネットワークの比較が終わったら元の設定に戻してください。自動再接続を、切断操作が効かなかったと誤解しないようにします。
問い合わせるとき、どの記録を添えればよいですか？
発生時刻、Wi‑Fiかモバイル通信か、Global Routing、識別情報を伏せたノード名、プロトコルの種類、Connectivity Testの3回分の結果、関連するエラー行を記載してください。サブスクリプションURL全体、パスワード、UUID、秘密鍵は公開の問い合わせに含めないでください。
最後に、診断中に変更したルーティングモード、On Demand、その他の設定を元に戻し、元の接続先で再測定します。問題が解消した場合は、有効だった変更と比較記録を残してください。続く場合は、問題がないと確認できた箇所を整理し、エンドポイント、経路、ローカルネットワークを引き続き調べます。
入手方法と購入について
Shadowrocketはクローズドソースの有料アプリで、買い切り形式です。App Storeから入手でき、主にiPhoneとiPadで利用できます。システム要件、互換性、購入対象の範囲はApp Storeのページをご確認ください。アプリの買い切り購入に回線プランは含まれません。本サイトではノードやサブスクリプションの提供、販売、推奨は行っていません。アプリの正規性を改めて確認する場合は、正規品の確認方法をご覧ください。アプリをお持ちの方は、基本的な接続手順をチュートリアルで確認できます。
正規品の確認方法を見る 使い方を見る