遅延の数値が出ていても、通信速度が正常とは限りません。まず測定先を固定し、初回表示の遅さ、継続的な転送の遅さ、断続的な通信切断を分けて確認します。次に通信環境、利用中のノード、ノードまでの経路、プロトコル設定、ルールの適用状況を順に調べます。自身のサービス提供元とサブスクリプションをすでに利用している方向けの内容です。1回の検証で変更する条件は1つに絞り、結果を記録してから変更を維持するか判断してください。
まず確認：遅延・スループット・初回表示時間の違い
Shadowrocketの接続テストで分かるのは、特定の方法で測定した到達性や応答時間です。継続的なデータ転送の速度を示すものではありません。接続がすぐ確立しても、その後の通信は混雑やパケットロス、サーバー負荷、接続先サイトの制限などの影響を受けることがあります。測定方法が異なる遅延の数値を、そのまま比較するのも適切ではありません。
普段問題なく使えているサイトと、アクセス権がありサイズが一定のファイルを1つ選びます。初回応答はウェブページで、継続的なスループットはファイルで確認します。異なるサイトの結果を同じ経路の比較に使ったり、複数の転送を同時に実行したりしないでください。
| 確認できる症状 | 優先して確認する項目 | 確認方法 |
|---|---|---|
| 初回表示は遅いが、開いた後は正常 | DNS、接続の確立、接続先の応答 | 同じページの初回表示と再表示を比較 |
| ファイルの転送がずっと遅い | 経路、ノードの負荷、接続先の速度制限 | 同じファイルを30秒間続けて確認 |
| 転送が速くなったり止まったりする | パケットロス、無線の電波状況、混雑 | ノードを固定し、Wi-Fiとモバイル通信を比較 |
| 特定のサイトだけ遅い | サイト側の状態、ルール、接続先までの経路 | 同じノードで別のサイトにアクセス |
単位に注意してください。Mbpsは1秒あたりのメガビット数、MB/sは1秒あたりのメガバイト数です。単位換算では8 Mbps = 1 MB/sですが、実際の転送にはプロトコルのオーバーヘッドも含まれます。たとえば「遅延80 ms、ファイル転送速度0.5 MB/s」という記録もあり得ますが、この数値だけではノードの正常・異常は判断できません。記事中の数値は記録方法の説明であり、実測結果ではありません。
第1層：条件を固定してiPhoneの通信環境を確認
まず、速度低下がShadowrocket以外でも起きるか確認します。プロキシなしでアクセスできる同じ接続先を選び、接続を切って基準値を測定してください。このときは通信環境から直接アクセスするため、直接アクセスに適した接続先だけを選びます。基準値も遅い場合は、Wi-Fiやモバイル通信の電波状況、ネットワーク自体を先に確認します。
-
現在の状態を記録
Homeで選択中のノードを、Home → Global Routingで現在のモードを記録します。あわせてWi-Fiかモバイル通信か、測定先、時刻も記録してください。設定を先に消去する必要はありません。
-
自動接続を一時停止
Settings → On Demandを開き、現在の設定を記録してからOn Demandを一時的にオフにします。次にHomeに戻って接続をオフにしてください。プロキシ接続がすぐ再確立されていないことを確認し、プロキシ経由の通信を直接接続の基準値と取り違えないようにします。
-
通信環境の基準値を確認
端末上のほかの大容量通信を一時停止し、ルーターの近くで固定した接続先にアクセスします。Wi-Fiでログイン画面が必要な場合は、先に認証を済ませてください。電波表示の本数が多くても、外部への通信経路が混雑していないとは限りません。
-
接続するネットワークを切り替える
Shadowrocketの接続を再開し、同じノードを使ったまま、Wi-Fiとモバイル通信で同じ接続先をそれぞれ3回テストします。モバイル通信ではデータ通信量が発生するため、契約内容に応じて測定量を調整してください。
-
元の設定に戻す
結果を記録し、必要なGlobal RoutingとOn Demandの設定を元に戻します。特定の接続ネットワークだけ遅い場合は、そのネットワークを優先して確認してください。ノードのプロトコルとDNSを同時に変更するのは避けましょう。
Wi-Fiとモバイル通信を切り替えると、通信事業者の外部接続経路も変わります。そのため、この比較で特定できるのは「端末の接続環境と、その先の経路」であり、結果だけからルーターの故障とは判断できません。ルーターの近くで明らかに改善し、ほかの条件が同じなら、無線の電波が届く範囲や干渉を優先して確認します。
第2層：ノードの接続先と、そこまでの経路を切り分ける
ノードは接続先のサーバー、経路は端末からそのサーバーまで、さらにサーバーから接続先までのデータの通り道です。ノードの遅延が低くても、それは特定の測定で応答が速かったことを示すだけです。サーバーの利用可能な帯域幅や現在の負荷、接続先サイトまでの速度までは分かりません。地理的に近い場所でも、実際の経路が短いとは限りません。
- 同じネットワークで、利用中の別ノードを試す：Homeで、自身が利用しているサブスクリプションに含まれる別のノードを選びます。接続先とGlobal Routingは変えません。特定のノードだけ遅い状態が続く場合は、その接続先と接続先までの経路を重点的に確認します。
- 同じノードで、ネットワークを変える：ノードを変えずに、Wi-Fiでは遅くモバイル通信では正常なら、端末の接続ネットワークかノードまでの経路に違いがあると考えられます。ノード全体の性能が原因とは限りません。
- 同じノードで、時間帯を変える：条件をできるだけそろえ、混雑する時間帯と空いている時間帯の状態を記録します。特定の時間帯だけ速度が落ちる場合は、混雑が原因の可能性として確認できます。1回の測定だけで、サービス提供元による速度制限とは判断できません。
- 同じノードで、接続先を変える：複数の接続先のうち1つだけ遅い場合は、その接続先の応答、適用されているルール、ノードから接続先までの経路を確認します。すぐにすべての設定を入れ替える必要はありません。
サブスクリプションを更新すると、サービス提供元が公開したノード情報を再取得できますが、帯域幅が自動的に増えるわけではありません。自身のサービス提供元から接続先情報の変更を確認できた場合に限り、Homeで該当するサブスクリプションを更新し、選択中のノードが想定どおりか確認してください。更新の成功と速度の改善は別のことです。更新後は接続先も記録し、ノードの変更をほかの設定による効果と取り違えないようにします。
第3層：プロトコル設定を確認し、ポートをむやみに変更しない
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは、それぞれ接続や転送の仕組みが異なります。クライアントの設定は自身のサーバー設定と一致させる必要があります。これらは同じノードで自由に切り替えられる速度設定ではありません。サーバーが1種類のプロトコルしか提供していない場合、クライアントのTypeだけを変更すると、通常は接続できなくなります。
Homeで現在のノードの編集画面を開き、サービス提供元の案内に沿ってアドレス、ポート、認証情報と、使用中のプロトコルに該当するTLS、Server Name、転送パスなどの設定を確認します。現在のノードに関係する項目だけを確認し、速度向上を目的に不一致の設定を追加で有効にしないでください。
- ポートは速度を上げるスイッチではありません：
443はHTTPSでよく使われるポートですが、ノードのポートを443に変更しても、サーバーがそのポートで自動的に待ち受けるわけではなく、TLSも有効になりません。 - 下位の転送方式を確認：Hysteria2はUDPベースのQUICを使用し、WireGuardもUDPを使用します。現在のネットワークでUDPが制限されていると、ハンドシェイクに失敗したり、通信が繰り返し途切れたりすることがあります。自身のサービス提供元が用意している、ほかの利用可能な設定と比較してください。
- 証明書の検証を有効にする：証明書の検証は接続先が正しいことを確認するためのものです。検証エラーが出た場合は、システム時刻、Server Name、サーバー証明書を確認してください。検証をスキップして速度を上げようとするのは避けてください。
- MTUをむやみに調整しない：小さなリクエストは正常でも、大容量の転送が何度も停止する場合、経路上のMTUが関係している可能性があります。パケットロスや接続先の速度制限も考えられます。まず症状を記録し、サーバー側の根拠がある場合だけ関連する設定を変更して、元の値も控えてください。
プロトコルを比較する場合は、自身のサービス提供元が実際に提供している、必要なパラメーターがそろった接続だけを対象にしてください。接続先の地域、測定対象、ネットワーク、時間帯もできるだけそろえます。特定の条件で速かったとしても、その結果は今回の測定条件に限られ、すべてのネットワークで同じプロトコルが速いとは限りません。
第4層：Global Routingとルールの適用状況を確認
速度を調べる前に、リクエストが想定した経路を通っているか確認します。Home → Global Routingで、Proxyはプロキシ可能な通信をプロキシに渡し、Directは直接接続を使い、Configは現在の設定に従って処理します。Sceneを使っている場合は、現在のSceneでどの設定とポリシーが実際に適用されているか先に確認してください。Sceneを切り替えると、2回の測定条件がそろわなくなります。
同じ接続先に対して、ProxyとConfigを一時的に切り替えて比較できます。測定後は元の設定に戻してください。Proxyでは正常でConfigでは遅い場合、接続先に適用されたルール、使用されたポリシー、そのポリシーが最終的に選んだノードを優先して確認します。Proxyにしても、すべてのドメイン名の名前解決が必ず同じ動作になるとは限りません。DNS設定もあわせて確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY以下はルール行の構文例であり、既存の設定全体を置き換えるためのものではありません。DOMAIN-SUFFIXはドメインのサフィックスで、IP-CIDRはIPアドレスの範囲で、GEOIPはIPアドレスの地域情報で照合します。FINALは前のルールに一致しなかったリクエストを処理します。ルールは記載順に評価されます。また、カスタムポリシー名は設定全体に定義されている必要があります。
- Configで、一覧に設定が保存されているだけでなく、想定した設定が現在適用されていることを確認します。
- 接続ログで対象リクエストを確認し、適用されたルール、ポリシー、最終的な出力先を調べてください。Homeで選択中のノードだけを見て、すべてのリクエストの経路を判断しないようにします。
- 初回表示だけが遅い場合は、DNSクエリがタイムアウトしたり、何度も再試行されたりしていないか確認します。DNSは名前解決の段階に影響しますが、通常、接続確立後の継続的なスループット低下すべてを説明するものではありません。
- DNSアドレスを一度に複数変更しないでください。元の値を残し、まず1項目だけ変更して、同じ接続先の初回応答とその後の転送速度がそれぞれ改善するか観察します。
エラーログ：接続失敗と速度低下を分けて確認
実際の問題が接続の繰り返し失敗なら、速度を測る前に接続を復旧させてください。以下はネットワークログに表示される場合があるエラー例です。接続段階や下位層から返される情報によって表示は異なり、毎回同じ文言が出るとは限りません。エラーを記録する際は、発生時刻、ネットワーク、ノードもあわせて残してください。
エラー：i/o timeout
原因と対処：ネットワークの読み書き処理が所定の待ち時間を超えた状態です。パケットロスや経路の到達不能、接続先から応答がないことなどが原因として考えられます。名前解決、接続、転送のどの段階で発生したか確認し、ノードを固定して接続ネットワークを切り替えて比較してください。タイムアウトだけを理由に設定をリセットしないでください。
エラー：connection refused
原因と対処：接続先の端点、または経路上の機器によって接続要求が明示的に拒否されています。該当ポートでサービスが待ち受けていない場合によく起こります。現在のノードのアドレスとポートを確認し、接続先が利用可能か自身のサービス提供元に問い合わせてください。
エラー：no such host
原因と対処：名前解決で必要なホストのアドレスを取得できていません。ドメイン名の入力ミスやDNSレコード、リゾルバーに問題がある可能性があります。まずエラーに表示されたドメインがノードのものか接続先サイトのものか確認し、該当するドメイン名とDNS設定を調べてください。
記録を提出する前に、サブスクリプションのリンク、token、パスワード、秘密鍵などの認証情報を隠してください。プロトコル名、エラーの文言、ネットワークの種類、発生段階、比較結果は残せます。遅延の数値だけが写ったスクリーンショットより、原因を絞り込むのに役立つ情報です。
よくある質問：調査結果の見方
遅延が低いのに動画が止まるのはなぜ？
遅延で測れるのは測定リクエストへの応答だけです。動画の再生には継続的な帯域幅、パケットロス率、コンテンツサーバーの状態も影響します。同じノードを使い、別の動画とサイズが一定のファイルをそれぞれテストしてください。特定の配信元だけ遅い場合は、その配信元と適用ルールを先に確認します。低遅延を帯域幅の保証と考えないでください。
ノードを変えたらすぐ速くなりました。元のノードに問題があると判断できますか？
2つの接続で条件が異なることは分かりますが、ノードの負荷、経路、接続先への出口も変わる可能性があります。元のノードに戻して、接続先とネットワークをそろえて再度測定してください。違いを繰り返し確認できた場合に限り、記録を自身のサービス提供元に共有して確認を依頼するとよいでしょう。
接続を切っても自動で再接続されます。基準値を測るには？
Settings → On Demandを開き、設定を記録してから自動接続を一時的にオフにします。その後、Homeに戻って接続を切断してください。端末にほかの管理対象の接続ルールがある場合は、その状態も先に確認します。基準値を測り終えたら設定を元に戻し、普段の接続動作が変わらないようにしてください。
利用中のノードがすべて遅い場合、クライアントを買い直す必要はありますか？
クライアントの購入と通信経路の帯域幅は別のものです。まず通信環境の基準値と別の接続ネットワークでの比較を行い、共通して使っている設定と接続先も確認してください。クライアントの買い切り購入は通信経路のプランとは別です。再購入しても、経路、接続先、設定の確認の代わりにはなりません。
まとめ：再現できる比較記録を残す
調査後は、繰り返し確認して効果があった変更だけを残し、一時的に切り替えたモードや設定は元に戻してください。効果を確認できない変更は取り消し、複数の条件が重なって次回の問題と比較できなくなるのを防ぎます。以下の形式で記録できます。認証情報を記入する必要はありません。
測定対象：同じウェブページまたは固定サイズのファイル
測定条件：同じiPhone、ほかの大容量通信は一時停止
接続ネットワーク：Wi-Fi / モバイル通信
選択した接続：自身のノード名（認証情報は含めない）
Global Routing：Config / Proxy / Direct / Scene
実際の適用内容：ルール、ポリシー、最終的な出力先
測定時間：各回30秒、各条件で3回繰り返す
記録項目：初回応答、継続速度、通信切断の有無
変更した項目：今回変更した条件は1つだけ
復元の確認：設定、モード、On Demand信頼できる結論は、「同じノードはモバイル通信では正常だが、現在のWi-Fiでは継続的に通信が止まる」のように条件を明確にします。「アプリの速度が遅い」とだけ記録するのは避けてください。前者なら次に調べる箇所を絞れますが、後者では端末のネットワーク、経路、プロトコル、接続先サービスが混在し、再現が困難です。