テスト対象、Global Routing、ローカルネットワークの条件を固定してから、サーバー、接続ネットワーク、プロトコルを順に切り替えます。利用中のサービスとサブスクリプションがあり、接続はできるものの通信が遅い方向けです。条件を一つずつ比較し、サーバー負荷、回線の混雑、プロトコルの接続問題、Wi-Fiの不具合を切り分け、再確認できる記録を残します。
1. まず「遅い」タイミングを確認する
Shadowrocketで接続が有効になっていても、接続状態が示されるだけで、目的のWebサイトまでの経路全体が正常とは限りません。ページの表示には、通常DNSの名前解決、接続の確立、TLSハンドシェイク、コンテンツの転送が必要です。どの段階で時間がかかっても、ページがなかなか表示されないことがあります。設定を変更する前に現象を記録し、名前解決の待ち時間を通信速度不足と取り違えないようにしましょう。
| 確認できる症状 | 優先して確認する項目 | 比較方法 |
|---|---|---|
| 最初の表示まで時間がかかるが、その後の転送は正常 | DNS、接続確立、TLS | 同じページを続けて開き、別の対象とも比較する。キャッシュの影響に注意 |
| ページは開くが、大きなファイルの転送が遅い | サーバー負荷、回線帯域、接続先による速度制限 | サーバーを固定し、テストが許可されている別のリソースを試す |
| 特定のWebサイトだけ遅い | 接続先サービス、ルールの適用、特定の出口経路 | 該当リクエストのポリシーを確認し、別の接続先にもアクセスする |
| Wi-Fiでは遅いが、モバイル通信では正常 | Wi-Fiの電波、ルーター、インターネット回線 | サーバーはそのままにして、接続ネットワークだけ切り替える |
遅延の数値はダウンロード速度ではありません。遅延テストは特定の確認処理にかかった時間を示すもので、実際の通信における継続的な転送速度とは異なります。1回のテスト失敗だけでサーバーが利用不能とは判断できません。動画の再生開始、Webページの初回表示、ファイル転送はそれぞれ別に確認し、一つの数値だけで全体の使い勝手を判断しないでください。
2. 基準条件をそろえる：まずGlobal Routingを確認
Homeで現在のサーバーとGlobal Routingを確認します。Proxy、Direct、Config、Sceneはそれぞれ異なるルーティング方式で、速度設定ではありません。ルールの影響を調べるには、ProxyとConfigを一時的に比較します。Proxyでは目的のサイトが回復し、Configでは遅いままなら、ルールやポリシーの振り分け先を優先して確認してください。Proxyを長期的に使う必要があるという意味ではありません。
-
現在の設定を記録
Homeで選択中のサーバーとGlobal Routingを記録し、Configで選択中の設定を確認します。元の値を控え、テスト後に戻してください。
-
テスト対象を固定
Safariで繰り返しアクセスできるWebページと、テストが許可されているファイルリソースを選びます。毎回同じ対象を使い、ほかの大容量通信は一時停止してください。
-
ルーティングを比較
Home → Global RoutingでProxyを一時的に選び、サーバーは変更せずにテストします。その後Configに戻して再確認し、対象への通信が想定したポリシーに振り分けられているか記録してください。
-
オンデマンド接続を確認
Settings → On Demandでオンデマンド接続の条件を確認します。切断状態を基準にテストする場合は、テスト中に自動再接続しないよう、該当する条件を一時的に無効にしてください。
-
設定を戻して再確認
比較テスト後はGlobal RoutingとOn Demandを元に戻します。同じ対象に再度アクセスし、別の接続状態ではなく、同じ問題が再現するか確認してください。
Directは、現在のネットワークから直接アクセスできる対象の確認に使えます。ただし、もともと直接接続できない対象を根拠に、ローカルネットワークの不具合と判断しないでください。Sceneの結果は対応するシーン設定にも左右されるため、方式名だけで実際の通信先を判断できません。ルールを確認する場合は、Configの並び順と実際のリクエストに適用されたルールを確認します。DOMAIN-SUFFIX、IP-CIDR、GEOIP、FINALはそれぞれ用途が異なります。DNSを変更しても、誤ったポリシーの選択が自動で修正されるわけではありません。
3. サーバー：同じネットワークでサーバーだけを切り替える
ここでいうサーバーとは、サービス提供元から提供された個別のサーバー設定を指します。Wi-Fi、テスト対象、ルーティング方式は変えず、自分が利用できるサーバー設定を2つ切り替えて比較します。プロトコルや関連パラメーターが同じ設定を選んでください。条件が異なるとプロトコルの差も結果に含まれ、サーバー負荷だけの影響を判断できません。
- 特定の設定だけ継続して遅い：該当する設定のアドレス、ポート、発生時刻を記録し、利用中のサービス提供元に負荷、メンテナンス、速度制限の状況を確認します。
- すべての設定が同時に遅い：共通の回線、ローカルネットワーク、接続先サービスを引き続き確認します。すぐにすべてのパラメーターを変更しないでください。
- 同じ設定でも速度が変動する：条件をそろえ、時間帯を変えて再テストします。夜間の遅さは混雑の手がかりにはなりますが、どの区間で混雑しているかまでは特定できません。
- 設定を切り替えると回復する：元の設定に戻してもう一度テストし、キャッシュ、一時的な回復、バックグラウンド処理の終了による誤判定を除外します。
サブスクリプションの内容は、サービス提供元によって変更されることがあります。アドレスやポートが変わった可能性がある場合は、Homeで自分のサブスクリプションを更新し、サーバーの各項目が同期されているか確認してください。サブスクリプションURLはサービス提供元から入手します。更新で解決できるのは設定の同期問題であり、サーバーの帯域が増えるわけではありません。また、更新成功だけで回線が正常だと判断することもできません。
結論：比較用の正常な設定を確保する
同じ作業を安定して完了できるサーバーが見つかったら、その設定をいったん維持します。それを基準にほかの設定を一つずつ比較し、設定の更新、プロトコルの変更、DNSの変更を同時に行わないでください。
4. 回線：Wi-Fiとモバイル通信を組み合わせて確認
回線には、端末からサーバーまでと、サーバーから接続先サービスまでの通信経路が含まれます。ローカルの接続ネットワークを切り替えても変わるのは経路の一部です。そのため、モバイル通信で改善しても、接続ネットワークやその経路に関係があることは示せますが、それだけでルーターの故障とは断定できません。モバイル通信を利用できないiPadでは、自分で管理できる別のWi-Fiやインターネット共有を使って比較してください。
| テストの組み合わせ | 固定する条件 | 記録する内容 |
|---|---|---|
| 元のWi-Fi + 元のサーバー | 対象リソース、ルーティング方式 | 初回表示までの時間、転送の可否、途中で止まるか |
| モバイル通信 + 元のサーバー | サーバーの設定、対象リソース | 接続ネットワークの切り替えで症状が解消するか |
| 元のWi-Fi + 比較用サーバー | 元のWi-Fi、対象リソース | サーバーの切り替えで改善するか |
| モバイル通信 + 比較用サーバー | 比較用サーバー、対象リソース | どちらの接続ネットワークでも安定するか |
上記はテスト方法の例であり、実測結果ではありません。各組み合わせで3回を目安に繰り返し、時刻と失敗回数を記録してください。大きなファイルのテストでは通信量を消費するため、モバイル通信では契約プランを事前に確認します。2つのサーバーが元のWi-Fiでのみ遅い場合は、Wi-Fi環境、ルーター、その接続回線を重点的に確認してください。一方、特定のサーバーがどちらのネットワークでも遅い場合は、そのサーバーと接続先までの経路を引き続き調べます。
特定のWebサイトだけが遅く、ほかの対象は正常な場合は、接続先のCDN割り当て、出口IPアドレスの制限、アプリ側の速度制限も考えられます。「地理的に近い」ことだけを根拠に判断せず、実際のルーティング、接続品質、負荷を含めてテストしてください。
5. プロトコル：設定を確認してから通信条件を調べる
プロトコル名だけで速度が保証されるわけではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは接続の仕組みがそれぞれ異なりますが、実際の性能はサーバーの構成やネットワーク環境にも左右されます。サービス提供元が用意した、必要なパラメーターがそろっている設定だけを比較してください。テスト目的で設定のTypeを別のプロトコルに変更しても、サーバー側がそのプロトコルに自動対応するわけではありません。
- アドレスとポート：サービス提供元から指定された値を使います。HTTPSでよく使われる
443ポートが、すべてのプロキシサービスに共通するわけではありません。接続が遅いからといって、一律に443へ変更しないでください。 - TLSとSNI：Trojanなどの設定では、証明書に対応するホスト名とSNIを確認します。証明書の検証エラーは接続上の問題です。高速化のためにAllow Insecureを有効にしないでください。
- 転送パラメーター：サービス提供元がWebSocketなどの転送方式を使っている場合、パスやHostなどのパラメーターをサーバー側と一致させる必要があります。サーバーのアドレスを名前解決できても、これらの設定が正しいとは限りません。
- UDPの利用条件：Hysteria2はQUICを基盤とし、WireGuardはUDPを使用します。接続ネットワークによるUDPの制限で、接続に失敗したり不安定になったりすることがあります。サービス提供元が用意している別の利用可能な設定と比較してください。
ログにエラーがある場合は、転送速度をテストする前にエラーへの対処を優先します。以下はネットワーク診断でよく見られるエラーの一部です。実際のプレフィックスや全文はログを確認してください。通信が遅いときに必ず表示されるメッセージではありません。
エラー：connection refused
原因：接続が明示的に拒否されています。接続先ポートで待ち受けていない場合や、途中の機器が拒否している場合によく発生します。対処：サーバーのアドレスとポートを確認し、利用中のサービス提供元に稼働状況を問い合わせてください。ポートをむやみに切り替えないでください。
エラー：no such host
原因：ドメイン名の名前解決で有効な結果が得られていません。まずサーバーのドメイン名か、接続先のドメイン名かを切り分けます。対処：ドメイン名の入力とサブスクリプションの更新結果を確認し、現在のネットワークからDNSに到達できるか調べてください。
エラー：context deadline exceeded
原因：処理が制限時間を超えています。このメッセージだけでは、どこでパケットが失われたかは特定できません。対処：前後のログから失敗した段階を確認し、サーバーを固定したまま接続ネットワークを切り替えて再テストしてください。
結論：設定が正しいことを確認してからプロトコルを比較
速度を比較する意味があるのは、両方の設定で安定して接続を確立し、同じ対象にアクセスできる場合です。ハンドシェイクの失敗と、接続後の転送速度の低下は分けて記録し、それぞれ対処してください。
6. ローカルネットワーク：Wi-Fi、DNS、バックグラウンド通信を確認
比較テストでローカル環境に問題がありそうな場合は、元に戻せる操作から試します。ルーターの近くで再テストし、ほかの端末による大容量通信を一時停止すれば、ネットワーク設定全体をリセットするより原因を特定しやすくなります。Wi-Fiの電波が強くても干渉が少ないとは限らず、ブロードバンド回線の出口で通信が滞っている可能性もあります。同じWi-Fiにつながる端末から大量にアップロードしている場合も、Webページの表示が遅くなることがあります。
- 接続品質を確認：サーバーは変えずにルーターの近くで再テストします。ルーターが複数の周波数帯に対応している場合は、条件をそろえてそれぞれ試し、接続したネットワークを記録してください。
- ほかの通信を一時停止：写真の同期、システムアップデート、ほかの端末での大容量ファイル転送を一時停止して、同じ対象にアクセスします。テスト後は元の処理を再開してください。
- 直接接続の基準を確認：On Demandによって自動再接続しないことを確認してから接続を切り、現在のネットワークから通常アクセスできるWebページを開きます。それでも遅い場合は、まずローカルの接続問題に対処してください。
- DNSと転送速度を切り分ける：初回接続だけ明らかに待たされる場合に、名前解決の設定を重点的に確認します。HTTPSのテストで、ドメイン名の代わりにWebサイトのIPアドレスを直接使わないでください。証明書、SNI、バーチャルホストがドメイン名に依存している場合があります。
- 再接続後の状態を確認：Wi-Fiとモバイル通信を切り替えたら、接続が安定するまで待ってからテストをやり直します。切り替え前の接続が切れたからといって、新しいネットワークからサーバーを利用できないとは限りません。
MTUの変更を最初に試す必要はありません。小さなリクエストは正常なのに、大きなデータの転送が繰り返し止まる場合は、追加の確認項目として検討できます。ただし、同じ症状はパケットロスや接続先の速度制限でも起こり得ます。設定に該当項目があり、サービス提供元から明確なパラメーターが示されている場合に限って変更してください。毎回元の値を記録し、ネット上の「汎用値」を一括で適用しないでください。
7. 結果を整理して、回復を確認する
確認のゴールは、1回の速度テストで数値が改善することではなく、普段の利用環境で同じ作業を安定して完了できることです。ConfigとOn Demandを元に戻したうえで、よく使うWebページやアプリを確認してください。Configに戻すと再び遅くなる場合は、サーバーを次々と切り替えるのではなく、ルールの適用先とポリシーの選択を確認します。
- 環境：iPhoneまたはiPad、接続ネットワークの種類、発生した時間帯、特定の対象だけで起きるかを記録します。
- 設定：Global Routing、使用中のプロトコル、サーバーのポート、選択中の設定を記録します。パスワード、鍵、サブスクリプションの認証情報は公開しないでください。
- 比較結果：「元のサーバーはどちらのネットワークでも遅い」「同じサーバーが元のWi-Fiでのみ遅い」のように記録すると、「速度が出ない」とだけ書くより原因を絞り込みやすくなります。
- 証拠：実際のエラー部分とテスト回数を残します。ログを共有する前に、認証パラメーター、サブスクリプションURL全体、個人のアクセス履歴が含まれていないか確認し、必要な情報を隠してください。
- 設定を戻す：一時的な変更を取り消して、元の対象で再テストします。繰り返し発生する問題は、未確認の設定を追加し続けるのではなく、利用中のサービス提供元に伝えてください。
ルールやDNSをさらに確認する場合は、Global Routingとルールによる振り分けのチュートリアルおよびDNSのトラブル対処ガイドを参照してください。これらはそれぞれ別の段階を確認するための手順です。テスト中にすべてを一度に変更せず、確認できた情報に基づいて一つずつ試してください。