Shadowrocketで接続済みと表示されていても、通信経路全体に十分な帯域があるとは限りません。ご自身で用意したサービスの設定またはサブスクリプションをお使いの方向けに、直接接続の基準値、Global Routing、プロトコル設定、ネットワーク間の経路、ノード負荷を順に確認します。テスト対象を固定し、一度に変更する条件を一つに絞ることで、ページを初めて開くときだけ遅い、ダウンロードが遅い、接続がタイムアウトするといった症状を切り分け、関係のない設定を繰り返し変更せずに済みます。
1. 遅延・スループット・接続失敗を区別する
通信速度は複数の要素で決まります。iPhoneからWi-Fiアクセスポイントや携帯電話基地局までの接続、ローカルの通信事業者から遠隔サーバーまでの経路、サーバーの処理能力、サーバーから目的のWebサイトまでの経路などです。Homeに表示される遅延値は、特定のテスト方法で測った応答時間に限られ、ダウンロード速度にそのまま換算できません。遅延が一度低かったからといって、長時間の転送中にパケットロスや輻輳がないとは言い切れません。
まず症状を整理してからテスト方法を選びます。ページを最初に開くときだけ止まり、表示後は正常なら、ドメイン名の解決や接続確立を確認します。ファイルのダウンロードが最初から遅いなら、帯域や経路を比較します。速度が頻繁に変わる場合は、Wi-Fiの干渉、パケットロス、共有回線の負荷を確認します。接続がタイムアウトし続ける場合は到達性の問題です。速度改善を試す前に、まず接続を復旧してください。
たとえば80 Mbpsは理論上10 MB/sに相当しますが、実際のファイル転送速度はプロトコルのオーバーヘッド、接続先の速度制限、ネットワークの変動にも左右されます。これは単位の換算であり、速度を保証するものではありません。比較できるよう、ネットワークの種類、選択したノード、ルーティングモード、接続先のWebサイト、時間帯を記録してください。
2. 第1段階：ローカルネットワークの直接接続を基準にする
まず、プロキシを使わなくても正常にアクセスできる同じWebサイトまたはファイルを基準にします。直接接続が安全かつ許可されている環境で、Shadowrocketの接続を一時停止してテストしてください。直接接続の時点で遅い場合、プロキシのプロトコルを調整しても解決しないことがあります。異なるWebサイトのダウンロード速度を比べて、プロキシが通信を遅くしていると判断しないでください。サーバーや帯域制限が異なる可能性があります。
-
現在の設定を記録する
Homeで選択中のノードとGlobal Routingの現在値を記録し、Settings → On Demandでオンデマンド接続の状態を確認します。診断中に手動で切断する場合は、既存の条件に基づいてシステムが再接続しないよう、On Demandを一時的に無効にしてください。
-
直接接続の基準値を測る
Homeで接続を停止し、接続状態が変わったことを確認します。Safariで同じテスト対象を開き、最初の読み込みと継続的なデータ転送の様子を記録してください。このとき、システムアップデート、写真の同期、大容量ファイルのアップロードを同時に実行しないでください。
-
接続ネットワークを切り替える
iPhoneのSettings → Wi-Fiで接続先を切り替え、Wi-Fiとモバイル通信の両方で同じ対象をテストします。モバイルデータ通信量に注意し、できるだけ近い時間帯に両方のテストを行ってください。
-
設定を戻して再テストする
Homeに戻り、同じノードとルーティング設定に戻して、同じネットワークで再テストします。終了後はOn Demandの条件も元に戻し、診断時の一時設定をそのまま使い続けないようにしてください。
Wi-Fiだけが遅い場合は、ルーターに近づき、異なる周波数帯の接続を比較し、大容量のアップロードが行われていないか確認します。アップロードで回線を使い切ると、Webページのリクエストも待たされることがあります。モバイル通信だけが遅い場合は、場所や時間帯を変えて比較し、契約中のデータプランに速度制限がないか確認してください。ステータスバーの電波表示だけで、十分な帯域があると判断しないでください。
3. 第2段階：ルーティングモードとプロトコル設定を確認する
ローカルネットワークに問題がなければ、テスト通信が実際にどの経路を通っているかを確認します。Home → Global RoutingのProxy、Direct、Config、Sceneは、それぞれ異なるルーティングモードです。Configは現在の設定に含まれるルールに従って通信先を決めます。Sceneは設定したシーンの条件に応じて設定を適用するもので、常時有効なグローバルプロキシではありません。対象のWebサイトにDIRECTルールが適用されている場合、そのテスト結果は選択中のプロキシノードの速度を測るものではありません。
| 設定項目 | 内容 | 確認すること |
|---|---|---|
| Proxy | プロキシ経由でルーティング | テスト中に選択中のプロキシやポリシーグループが切り替わっていないか確認します。 |
| Direct | 直接接続でルーティング | 経路の比較に使えますが、プロキシノードの速度を示すものではありません。 |
| Config | 現在の設定に従ってルールを適用 | 対象の接続に一致したルールと、最終的に適用されたポリシーを確認します。 |
| Scene | シーン設定に応じて条件を適用 | 現在のネットワークで適用されているシーンと、そのルーティング設定を確認します。 |
Configでは、次のルール例を使ってテスト対象の通信先を確認できます。これはルール構文の例であり、完全な設定ではありません。example.comはサンプルのドメイン名、PROXYはプロキシポリシーを表します。実際に使用する前に、現在の設定でポリシーがどう定義されているか確認してください。ルールは上から順に評価され、先に一致したルールで最終的な経路が決まる場合があります。
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT次にHomeで既存ノードの編集画面を開き、種類、アドレス、ポート、認証情報を確認します。Shadowsocksの暗号化方式、VMessまたはVLESSのIDとトランスポート設定、TrojanのパスワードとTLS設定は、いずれもサーバー側の設定と一致している必要があります。サーバーがTCPポート443を使っていても、任意のプロトコルに443を設定すれば動作するわけではありません。ポートが同じでも、通信内容が同じとは限りません。
- TLSとSNI：ご自身の設定に合わせて、サーバー名と証明書の検証条件を確認してください。証明書エラーを隠すために、安全でない検証を許可しないでください。また、iPhoneのSettings → General → Date & Timeを開き、システム時刻が正しいことも確認します。
- トランスポート設定：既存の設定でWebSocketを使用している場合、パスとHostはサーバー側の指定と一致している必要があります。フォームに保存できても、サーバーでパラメーターが検証されたとは限りません。
- UDPの条件：Hysteria2はQUIC上でUDPを使用し、WireGuardもUDPを使用します。現在のネットワークでUDPが制限されている場合、TCPを使う設定とは異なる動作になることがあります。プロトコル名だけで速度を判断しないでください。
- サブスクリプションの更新：サブスクリプションの読み込みや更新は設定を取得するためのもので、回線そのものの帯域を増やすものではありません。既存のサブスクリプションを更新した後は、選択中の項目を再確認してください。アドレスや設定値の変化を、単なる速度変動と取り違えないようにします。
エラー：certificate has expired
原因と対処：このTLSエラーは、証明書の有効期間の検証に失敗したことを示します。証明書の期限切れや、デバイスの時刻異常が原因となる場合があります。まずシステム時刻を合わせ、ご自身が利用するサービスの提供元に証明書の状態を確認してください。証明書の検証は有効のままにしてください。
エラー：Connection refused
原因と対処：接続先のエンドポイント、または経路上の機器によって接続が明示的に拒否されています。ポートで待ち受けていない場合や、アクセスがポリシーで拒否されている場合によく発生します。アドレス、ポート、プロトコルを確認し、速度テストを繰り返しても解決しないことに注意してください。
エラー：Operation timed out
原因と対処：制限時間内にリクエストが完了しませんでした。経路上のパケットロス、ポートへの到達不能、接続先から応答がないなどの原因が考えられます。まず同じ設定で接続ネットワークを変えてテストし、ご自身が利用するサービスの提供元に接続先の状態を確認してください。
ここでは、ネットワークやTLSの診断でよく見られるエラーの原文を紹介しています。実際の表示には追加情報が含まれる場合があります。エラー全文と発生時刻を記録し、名前解決、接続、ハンドシェイク、データ転送のどの段階で起きたかを切り分けてください。「タイムアウト」という一語だけで、ノード負荷が原因だと決めつけないでください。
4. 第3段階：ネットワークを切り替えて経路の問題を調べる
回線品質とは、ローカルネットワークから遠隔の接続先までの経路の状態を指し、往復遅延、ジッター、パケットロス、輻輳などが含まれます。サーバーまでの地理的な距離は関係しますが、距離だけで品質が決まるわけではありません。同じ地域名が付いた既存ノードでも、接続先までのネットワーク経路が大きく異なることがあります。ノード名は経路品質を示す証拠にはなりません。
ご自身がすでにお持ちの設定で比較テストを行います。まずノードを固定して接続ネットワークを切り替え、次に接続ネットワークを固定して既存ノードを切り替えます。テスト対象と方法は揃え、各条件で3回繰り返して中央値を記録してください。一時的なピークを持続速度とみなしたり、短時間に何度も同時テストを実行したりしないでください。テスト自体が接続を使い切る可能性があります。
| 観察された組み合わせ | 優先して確認する項目 | 次に行うこと |
|---|---|---|
| 同じノードでもWi-Fiでは遅く、モバイル通信では正常 | Wi-Fi接続またはその通信事業者の経路 | 直接接続の基準値と照らし合わせ、Wi-Fi側の問題か遠隔経路の違いかを切り分けます。 |
| 同じノードが両方のネットワークで遅く、他の既存ノードは正常 | 該当ノードの経路またはサーバーの状態 | ノードの設定を変えず、別の時間帯に再テストします。 |
| 特定のWebサイトだけ遅く、他の接続先は正常 | 接続先のWebサイト、ドメイン名の解決、またはノードから接続先までの経路 | 同じサイト内の別のリソースを比較し、実際に適用されたルーティングポリシーを確認します。 |
| すべてのノードと直接接続が同時に遅い | ローカルネットワークまたはテスト対象 | 他のデータ転送を停止し、固定した別のテスト対象で基準値を取り直します。 |
まとめ：条件を固定してからネットワークを切り替える
同じ設定が特定の接続ネットワークでのみ異常になる場合は、まずプロトコル設定を維持し、そのネットワークと遠隔経路を重点的に確認してください。DNS、ポート、プロトコルを同時に変更すると、どの変更が結果に影響したのかわからなくなります。
ページを最初に開くときだけ遅く、データ転送は正常な場合に限り、DNSを重点的に確認します。同じドメインの初回と再読み込み時の動作を比べ、接続ログで名前解決と接続にかかった時間を確認してください。2回目が速くても、ブラウザーのキャッシュが原因かもしれません。それだけでDNSの問題とは断定できません。名前解決先を不用意に変更すると、接続先の振り分けやルールの適用結果が変わることがあります。変更前に現在の設定をバックアップしてください。
5. 第4段階：ノード負荷と接続先の制限を見分ける
ノードの負荷には、サーバーの処理能力、外向き帯域、同時接続数、サーバー側の速度制限が関係します。クライアントから確認できるのは応答やデータ転送の状態であり、通常、遠隔サーバーのCPU使用率や回線の使用状況を直接取得することはできません。そのため、「遅延は低いのにダウンロードが遅い」という状態だけでは、遅延とスループットに差があることはわかっても、サーバー過負荷の証明にはなりません。
- 時間帯を比べる：同じネットワーク、ノード、接続先で、混雑する時間帯だけ遅く、別の時間帯には回復するなら、共有回線の輻輳や負荷変動の可能性があります。ただし、確定にはサーバー側の状態も確認する必要があります。
- 複数の接続先を比べる：同じノードから複数の異なる接続先へのアクセスが遅い場合、1つのWebサイトだけが遅い場合よりも、ノードの出口や共通する経路の確認が必要です。特定のサイトだけ遅い場合は、接続先側の速度制限も考えられます。
- 継続的な通信の状態を比べる：転送速度が一定の範囲に収まるのか、断続的に停止するのかを記録します。一定の上限が続く場合は速度制限、目立った停止がある場合はパケットロス、再送、接続切断などが考えられます。どちらもクライアントだけで原因を確定できるものではありません。
- サービスの状態を確認する：ご自身が利用するサービスの提供元に、現在のサービスに帯域、データ量、同時接続数などの条件があるか確認してください。状況を伝えるときは機密情報を伏せ、サブスクリプションURL、パスワード、認証情報は送らないでください。
速度測定の数値を上げるために、同時接続数を増やしたりダウンロードを長時間続けたりしないでください。複数接続でテストすると一時的に合計スループットが大きくなることがありますが、1つのWebリクエストが速くなるとは限らず、データ通信量も消費します。2つのプロトコルでサーバー、ポート、出口、経路が異なる場合、結果を「特定のプロトコルのほうが必ず速い」と一般化することはできません。
まとめ：根拠をもとに遠隔側のボトルネックを特定する
直接接続が正常で、設定が一致し、複数の接続先が遅く、異なる接続ネットワークでも再現する場合に限り、該当ノードの出口や負荷をサービス提供元に確認しましょう。時間帯と比較結果を添えると、クライアント設定を繰り返し変更するよりも原因を特定しやすくなります。
6. 記録を整理して通常の設定に戻す
一連の確認を終えたら、次の3点を説明できる状態を目指します。ローカルの直接接続は正常か、対象のリクエストに実際にどのポリシーが適用されたか、異常はノードまたは接続ネットワークの変更に追従するか。判断できない場合は、再現に必要な条件を最小限に絞って記録し、変更を重ねないでください。特に、サブスクリプションの更新、ルールの変更、プロトコルの調整を同時に行うと、元の問題との比較が難しくなります。
- iPhoneがWi-Fiとモバイル通信のどちらを使っていたか、各テストの日付、時刻、継続時間を記録します。外部に公開する必要がなければ、グローバルIPアドレスをすべて記載する必要はありません。
- Home → Global Routingの値、現在の設定、選択中のノード名（機密情報を伏せたもの）を記録し、テスト中に自動で切り替わったかどうかも記載します。
- 直接接続の基準値、同じノードでネットワークを切り替えた結果、同じネットワークで異なる既存ノードを試した結果を記録します。速度の単位がMbpsかMB/sかも明記してください。
- エラーの原文を残し、送信前にアドレスの機密情報、認証項目、サブスクリプションの認証情報を隠してください。
- 日常使用するConfig、ルール、Settings → On Demandの条件に戻し、よく使うWebサイトに想定どおりのルーティングが適用されていることを確認します。
ルールやルーティングモードをさらに確認したい場合は、技術リファレンスまたはプロキシモードの説明をご覧ください。ShadowrocketはAppleプラットフォーム向けのクローズドソースの商用アプリで、主にiPhoneとiPadで利用できます。システム要件はApp Storeの掲載内容をご確認ください。アプリの買い切り購入に回線プランは含まれません。この記事では、ユーザーがすでにお持ちの設定の確認方法を説明しており、ノードやサブスクリプションの提供、販売、推奨は行っていません。