利用中のサービスとサブスクリプションがあり、接続はできるものの通信が遅い場合を対象としています。まずHomeに表示されるノードとGlobal Routingを記録し、テスト先を固定して、ノード、経路、プロトコル、ローカルネットワークの順に比較します。変更は一度に1項目だけにし、ページ表示開始までの時間、継続通信、エラーログを手がかりに切り分けましょう。遅延の数値だけでダウンロード速度を判断しないことも大切です。
1. 接続経路と「遅い」の具体的な症状を確認する
ShadowrocketはAppleプラットフォーム向けの有料クライアントで、主にiPhoneとiPadで利用できます。入手先はApp Storeのみです。App Storeのページでデベロッパ名 Shadow Launch Technology Limited とアプリID 932747118を確認できます。アプリは買い切りで、システム要件とユニバーサル購入の対応状況はApp Storeの表示をご確認ください。アプリの購入と通信サービスの契約は別です。この記事では、すでに利用している接続の確認方法を説明します。ノードやサブスクリプションの提供、販売、推奨は行いません。
「接続済み」と表示されても、対象の通信が選択中のノードを経由しているとは限りません。Home → Global Routing の Proxy、Direct、Config、Sceneによって実際の経路が変わります。Proxyはプロキシ経由、Directは直接接続、Configは現在の設定ファイルに従った経路、Sceneは設定済みのシーンに応じた経路です。確認を始める前に現在の選択項目を記録してください。Configを使う場合は、有効になっている設定ファイルと関連するポリシーの選択も記録します。
症状を分けて記録すると、プロトコルを切り替えるより効果的に原因を絞れます。最初のページ表示に時間がかかる一方、その後の通信は安定している場合は、DNS、接続確立、接続先からの最初の応答が関係している可能性があります。ダウンロードが続くほど遅くなる場合は、経路の混雑、サーバー負荷、ローカルの無線環境を確認しましょう。特定のサイトだけ遅い場合は、まず該当リクエストに適用されたルールと接続先サービスの状態を確認します。
- ページ表示開始までの時間：同じページを使い、アクセス開始から主要な内容が表示されるまでの時間を記録します。初回と再アクセスを分けて確認してください。キャッシュによって結果が変わることがあります。
- 継続通信：アクセス権のある同じファイルを使い、少なくとも30秒間の転送状況を確認します。一時的なピーク値を安定した速度の代わりにしないでください。
- 接続エラー：発生時刻、接続先ドメイン、ログの原文を記録します。外部に共有する前に、サブスクリプションの認証情報、パスワード、個人の閲覧内容を削除してください。
2. ノード：低遅延でも通信速度が速いとは限らない
Homeの接続テストや遅延テストは、接続できない項目を見つけるのに役立ちますが、それだけで十分な帯域があるとは判断できません。短いリクエストへの応答が速くても、サーバーの外向き回線、長時間のデータ転送、接続先サイトまでの経路が正常とは限りません。一度のタイムアウトだけでノードが使えないと決めつけず、条件を揃えて再テストしましょう。
- Homeで現在のノード名、種類、接続状態を記録します。ポリシーグループを使っている場合は、利用可能なリクエスト記録で実際に選択された外向き接続を確認してください。Homeの選択表示だけでは判断できません。
- ネットワーク、テスト対象ファイル、Global Routingを変えずに、まず現在のノードを3回テストします。その後、利用中のサブスクリプションにある別の利用可能なノードに切り替えて、同じテストを繰り返します。
- 遅延、ページ表示開始までの時間、安定した転送速度をそれぞれ記録します。速度の単位は揃えてください。
1 MB/s = 8 Mbpsです。画面上の単位が異なる場合、数値の大小をそのまま比較できません。 - 特定のノードだけ継続して異常が見られる場合は、まずサーバーアドレス、ポート、認証情報を確認します。サブスクリプションで管理している場合は、臨時の手動変更を長期間残さないよう、サブスクリプションが更新済みかも確認してください。
結論：遅延が近い場合は、同じ接続先への継続通信を比較する
利用中の2つのノードで遅延がほぼ同じでも、3回の転送テストで一方だけ継続して止まる場合は、そのノードのテスト記録を整理しましょう。DNS、ルール、プロトコルを同時に変更するのは避けてください。
3. 経路：時間帯と接続先を比べて経路の違いを確認する
同じノードでも時間帯によって速度が異なる場合、接続ネットワークからサーバーまでの経路の混雑、サーバー側の外向き回線の負荷、接続先による速度制限などが考えられます。ノード名に含まれる地域だけでは実際のルーティングは判断できません。また、1つのサイトでの速度から経路全体の性能を推し量ることもできません。クライアントで症状を記録することはできますが、遠隔地の帯域や通信事業者の経路を直接改善することはできません。
| 比較条件 | 記録する症状 | 次の手順 |
|---|---|---|
| 同じノード・同じ接続先・異なる時間帯 | 特定の時間帯だけ継続的に速度が低下するか | 別の時間帯に再テストし、時刻と結果を利用中のサービス提供元に伝える |
| 同じノード・同じネットワーク・異なる接続先 | 特定のサイトやファイル配信元だけ遅いか | まず適用されたルールを確認し、接続先サービスの状態を調べる |
| 同じ接続先・同じネットワーク・異なる利用中のノード | 特定の出口だけ長時間停止するか | 正常時と異常時の両方を記録し、ノードの状態を確認する |
| 同じノード・同じ接続先・異なる接続ネットワーク | Wi-Fiとモバイル通信で明らかな差があるか | ローカルネットワークと接続経路の確認に進む |
たとえば、「同じ接続先でWi-Fiでは3回続けて通信が止まり、モバイル通信に切り替えると転送が続いた」という記録は、原因を絞る手がかりになります。ただし、接続先のサービス品質を示す結論ではありません。Wi-Fi、ルーター、ブロードバンド回線の出口、サーバーまでの経路がすべて変わっているため、さらに条件を分けて確認する必要があります。これは記録方法の例であり、本サイトでの実測結果ではありません。
4. プロトコル：通信条件を確認し、根拠なく設定を変えない
プロトコルは単独で速度を上げるスイッチではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは接続条件が異なります。実際の速度には、サーバー側の実装、暗号化処理、下位の通信方式、輻輳制御、ネットワークの制限も影響します。サービス提供元が複数のプロトコルを用意していても、出口や経路も同時に変わるなら、速度差をすべてプロトコルの違いに帰することはできません。
| プロトコルまたは通信方式 | 確認する条件 | 切り分けのポイント |
|---|---|---|
| Shadowsocks | サーバー、ポート、パスワード、暗号化方式を一致させる。UDPへの対応はサーバーと設定によって異なる | 認証情報や方式に誤りがあれば、何度も速度テストをするのではなく、接続情報を修正する |
| VMess / VLESS | ユーザーID、通信方式、TLS、関連する通信パラメーターをサーバー側の設定に合わせる | プロトコル名だけ変更して、互換性のない項目をそのまま流用しない |
| Trojan | パスワード、ポート、TLSのサーバー名、証明書の検証条件 | TLSの失敗はハンドシェイクの問題です。検証を無効にして隠さないでください |
| Hysteria2 | QUICを使用するため、UDP経路が利用できる必要があります。認証情報とサーバー側の要件を確認する | ネットワークでUDPが制限されていると接続できない場合があります。他のプロトコルより速いとは限りません |
| WireGuard | UDPエンドポイント、鍵、アドレス、ルーティング範囲 | ハンドシェイクが正常でも接続先への経路を確認し、他の設定のMTUを安易に流用しない |
TLSを使う場合、443はよく使われるポートですが、すべてのノードで固定されているわけではありません。利用中のサービス提供元が指定するポートを使用してください。Hysteria2の帯域パラメーターも、端末の通信速度を保証する値ではありません。むやみに大きく設定すると、混雑が悪化することがあります。サーバー側の案内やテスト結果に調整の根拠がない場合は、サブスクリプションで指定された値を維持してください。
ログの例：connection refused
原因と対処：接続先のエンドポイントまたは中間機器に接続を拒否されています。まずサーバーアドレス、ポート、サービスの稼働状況を確認してから再テストしてください。通常の帯域不足として扱わないようにします。
ログの例：i/o timeout
原因と対処：処理が制限時間内に完了していません。ログの前後関係を確認し、DNS、接続開始、読み込みのどの段階で発生したかを切り分けます。同じノードのまま接続ネットワークを切り替えて比較してください。
これらはネットワークエラーに表示されることがあるログの例で、失敗のたびに同じ文言が表示されるとは限りません。失敗した段階が分かるよう、実際のログを前後の情報ごと残してください。「タイムアウト」という文字だけでは、プロトコルの変更が必要かどうか判断できません。
5. ローカルネットワーク：Wi-Fi、モバイル通信、DNSを分けて確認する
ローカルの通信経路に問題があると、サブスクリプションの更新、ノードのテスト、Webページの表示すべてに影響します。Wi-Fi接続中にモバイルデータ通信をオフにしても、モバイル通信でのテストにはなりません。比較するには、システムのSettings → Wi-Fiで現在のWi-Fiを切断し、実際にモバイル通信を使用していることを確認してください。テストファイルによるデータ通信量にも注意しましょう。
- ローカル環境の基準を確認：端末の位置を変えず、他の大容量通信を一時停止します。直接アクセスできる同じ接続先を使い、通常のアクセスも遅いか確認してください。同じように遅い場合は、ルーターとブロードバンド回線の状態を先に調べます。
- 無線干渉を確認：ルーターの近くで再テストし、可能であれば2.4 GHzと5 GHzを比べます。周波数帯だけで速度が決まるわけではありません。距離、障害物、チャンネルの混雑も結果に影響します。
- 接続ネットワークを切り替える：同じノード、モード、接続先を使ったまま、モバイル通信に切り替えて3回テストします。安定した差が見られる場合は、すぐに設定を作り直すのではなく、接続ネットワークからサーバーまでの経路をさらに確認してください。
- DNSとデータ転送を切り分ける：ドメインを初めて開くときだけ待たされる場合は、Configで現在使っている設定の
[dns]項目と名前解決ログを確認します。接続確立後も速度が低い状態が続く場合、DNSだけを変更しても通常は転送速度の問題を解決できません。 - 自動接続を確認：Settings → On Demandで有効になっている条件を記録します。テスト中に接続が自動で再開される場合は、その条件が原因か確認してください。一時的に無効にする場合は、元の値を記録し、テスト後に戻します。
結論：実際の接続ネットワークを固定してから設定を比較する
端末がWi-Fiとモバイル通信の間で自動的に切り替わると、2回のテスト結果を比較できません。まずシステムが現在使っているネットワークを確認し、そのうえでShadowrocketの設定を変更するか判断してください。
6. ルールと再確認：通信が想定した出口を通っているか確認する
Configモードでは、通常ルールが上から順に照合されます。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレス範囲、GEOIPはIPの地理情報データベースを使って照合し、FINALはそれまでのルールに一致しなかったリクエストを処理します。ドメインの名前解決、ルールの順序、ポリシーグループの選択によって、最終的な経路が変わる場合があります。Homeで選択中のノードを変更しても、別のポリシーに固定されたリクエストの経路は変わらないことがあります。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYこのコードはルールの構文例です。example.comは例示用のドメインなので、既存の設定をそのまま置き換えないでください。no-resolveは、そのIPルールのためだけにドメインの名前解決が行われるのを避ける指定です。一般的な速度改善オプションではありません。現在の設定を複製して保存してから、問題のある接続先に適用されたルールと実際の外向き接続を確認しましょう。一時的にProxyへ切り替えて症状が変わった場合は、元の設定の経路を詳しく確認する必要があります。ただし、それだけでルール自体の誤りが証明されるわけではありません。
遅延は低いのに、動画がずっとバッファリングするのはなぜ？
短いリクエストの遅延と、継続的なデータ転送速度は別の指標です。同じ接続ネットワークで同じ動画またはファイル配信元を使って3回テストし、利用中の別のノードとも比較してください。対象のリクエストがルールによって別のポリシーに固定されていないかも確認します。
Proxyに切り替えると速くなります。このまま使い続けてよいですか？
まず差を記録し、Configに戻って接続先に適用されたルールとポリシーグループを確認します。Proxyは条件を揃えた比較に使えますが、他のリクエストのルーティングも変わります。テスト後は元のモードに戻し、対象に合わせて設定を修正してください。
サブスクリプションを更新すると速度は改善しますか？
サーバーアドレス、ポート、設定が変更された場合に限り、更新によって古い情報が修正されることがあります。Homeに戻り、利用中のサブスクリプションを更新して対象の情報が変わったか確認してください。更新が成功しても、経路の混雑が解消されたとは限りません。
どのプロトコルも遅い場合、アプリをリセットすべきですか？
まず同じノードでWi-Fiとモバイル通信を比較し、直接アクセスできる接続先も確認します。ローカル設定に問題があるとはっきり分かった場合にのみ、設定の復元を検討してください。リセットする前に設定と必要な記録を保存し、原因の特定に必要な情報を失わないようにします。
問い合わせ前に再現に必要な最小限の記録を残す
- 端末、接続ネットワーク、テスト時刻、Home → Global Routingの選択項目を記載します。
- ノードの種類、接続先の種類、3回分の結果、速度の単位を記載します。パスワード、鍵、サブスクリプションURL全体は送らないでください。
- 異常の前後で行った変更を1つずつ記載します。たとえば「同じノードでWi-Fiからモバイル通信に変更」のように書き、「すべて試した」だけで済ませないでください。
- 一時的に変更したモード、On Demandの条件、テスト用設定を元に戻し、普段使う接続先で再確認します。
段階的な切り分けで目指すのは、どんな場合にも使える設定値を見つけることではありません。問題がローカルの接続、サーバーまでの経路、サーバー側の通信条件、ルール、接続先の応答のどこで発生しているかを特定することです。原因を裏付ける情報が揃ってから該当箇所だけを最小限変更します。遠隔地のサービス状態が関係する場合は、個人情報を伏せた記録を利用中のサービス提供元に確認してもらいましょう。