この記事は、Shadowrocketで接続はできるものの、Webページの読み込みが遅い、動画が頻繁に止まる、ダウンロード速度が安定しない場合に役立ちます。利用中のサービスとサブスクリプションを前提に、まずテスト対象とルーティングを確認し、ノード、回線、プロトコル、ローカルネットワークの順に比較します。一度に変更する条件は一つだけにし、再現できる症状と対処の方向性を特定しましょう。1回の遅延テストだけで設定をすべて変更するのは避けてください。
1. まず遅い箇所を切り分ける
接続をオンにしても、すべてのリクエストがプロキシ経由になるとは限らず、プロキシの出口に十分な帯域があるとも限りません。ページの初回表示が遅い、動画再生中に何度も止まる、ダウンロード速度がずっと低いといった症状は、それぞれDNS、接続確立、継続的な転送速度が関係している可能性があります。まず症状を具体的に整理してから比較しましょう。
この流れはトラブルシューティングの確認箇所を示すもので、すべてのプロトコルで内部処理が同じ順序になるという意味ではありません。DNSはルール判定や接続先の名前解決に関わることがあり、キャッシュによって初回と再訪時の所要時間も変わります。特定サイトの応答が遅いからといって、プロキシ回線全体が遅いと決めつけないでください。
- アクセス権があり、内容が比較的安定したWebページやダウンロード対象を一つ選び、すべての比較で同じ対象を使います。異なるサイトの速度テスト結果を比較しないでください。
- 現在の時刻、ローカルネットワークの種類、ノード名、プロトコル、Global Routingの状態、症状を記録します。記録上のノード名はA、Bのように置き換えて構いません。
- システムアップデート、クラウド同期など、大量の通信を行う処理を一時停止します。同じ操作を続けて3回行い、初回表示までの時間、転送速度、接続が中断したかをそれぞれ記録します。
- 初回アクセスと再アクセスを区別します。初回の名前解決やハンドシェイクに時間がかかり、2回目は明らかに速い場合と、継続的な転送がずっと遅い場合は、別の問題です。
たとえば80 Mbpsは、理論上およそ10 MB/sに相当します。これは単位換算の例であり、Shadowrocketの実測速度や性能を保証するものではありません。遅延は応答を待つ時間、ダウンロード速度は単位時間あたりの転送量を表すため、両者をそのまま換算することはできません。
2. ルーティングと接続状態を確認する
Homeで現在選択しているノードと接続スイッチを確認し、続けてGlobal Routingを確認します。Proxyはプロキシ経由のルーティング、Directは直接接続、Configは設定ファイルのルールに基づく振り分け、Sceneはシーン設定に基づく動作を表します。トラブルシューティングでは、対象のリクエストが実際にどの経路を通るかを確認してください。ステータスバーのアイコンだけでは判断できません。
- Config：現在使用中のConfigを開き、ルールの順序と適用されるポリシーを確認します。ノードを選択していても、そのドメインに必ずそのノードが使われるとは限りません。
- Proxy：一時的な比較として使い、対象への接続がプロキシ経由で改善するか確認できます。テスト後はGlobal Routingを元に戻し、ほかのアプリの通信経路に影響が残らないようにしてください。
- Direct：ローカルネットワークから対象へ直接接続した場合の状態を比較できます。対象に直接接続できない場合でも、それだけでローカル回線の速度が低いとは言えません。
- Scene：現在有効なシーンの条件とルーティング動作を確認します。比較条件を絞るには、一時的に動作が明確なConfigまたはProxyの状態にしてテストします。
以下はルール構文の例であり、既存の設定を置き換えられる完全なファイルではありません。example.comは例示用のドメインで、PROXYは実際に利用できるプロキシポリシーに対応させる必要があります。ルールは通常、上から順に照合され、FINALは末尾でフォールバックとして使います。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレス範囲、GEOIPはIPの地理情報に基づいて照合します。対象が誤ってDIRECTに一致する場合は、プロトコルを切り替えるのではなく、まずルールを修正してください。Proxyでは正常でConfigでは遅い場合、ルール、DNS、ポリシーの選択を優先して確認します。ルーティングの詳細はプロキシモードをご覧ください。
3. ノード：利用可否と負荷の兆候を確認
ノードとは、利用中の設定に登録された個々のサーバー接続先です。ノードの遅延が低くても、特定の条件でテストしたリクエストの往復が速いことしか分かりません。サーバー側の出口の混雑、アカウントの速度制限、接続先サイトによる出口への制限までは測定できません。同じノードで短いリクエストは成功しても、ダウンロードを続けると遅くなる場合は、負荷や速度制限が関係している可能性があります。
- Homeで選択中のノードに誤りがないか確認し、アドレス、ポート、プロトコルの種類がサービス提供元の案内と一致しているか調べます。ポートを一律に443へ変更しないでください。サーバーが実際にそのポートで待ち受けている場合にのみ使用できます。
- 利用可能なノードが複数ある場合は、ローカルネットワーク、Global Routing、テスト対象を同じ条件に保ち、ノードAとBだけを切り替えて3回ずつ記録します。
- 利用中のサブスクリプションの通信量と有効期限を確認します。Homeでサブスクリプションを更新した後、ノードのパラメーターに変更があるか確認してください。サブスクリプションとノードはサービス提供元から取得します。
- 特定の接続先だけで異常が続く場合は、ノードの識別名、発生時刻、エラー内容をサービス提供元に伝えてください。複数の接続先が同じ出口や中継経路を共有している場合、完全に独立した比較対象として扱わないでください。
結論：まず異常箇所を特定してから設定を変更
同じネットワークと対象でノードAだけ異常が続き、ノードBは正常な場合は、Aのエラー記録を保存し、サービスの状態を確認します。この段階でDNS、MTU、すべてのプロトコル設定を一括変更すると、正常に使える比較条件が失われます。
4. 回線：時間帯とネットワーク経路を比較
回線とは、デバイスから接続先まで、接続先から出口まで、さらに出口から目的地までの通信経路です。ノード名に含まれる地域名から経路全体が分かるわけではなく、低遅延や広帯域とも限りません。同じ接続先が夜間に遅くなり、混雑していない時間帯に回復する場合、共有回線の混雑が関係している可能性はあります。ただし、この現象だけで具体的な原因区間を特定することはできません。
| 比較条件 | 具体的な操作 | 絞り込める原因 |
|---|---|---|
| 同じノード、異なる時間帯 | 午前と夜間にそれぞれ3回測定し、対象とローカルネットワークは変えない | 特定の時間帯に繰り返し発生する混雑の有無を確認 |
| 同じノード、異なる接続方法 | Wi-Fiとモバイル通信を切り替え、接続し直す | ローカルの接続環境や通信事業者の経路の違いを特定 |
| 同じネットワーク、異なる接続先 | ノードは変えず、用意した2つのテスト対象にそれぞれアクセスする | 広範囲な転送異常と特定の接続先の応答異常を切り分ける |
| 同じ接続先、利用可能な別ノード | プロトコルやルーティングは変更せず、ノードだけを切り替える | 異常が特定の接続先や共有経路に関係するか判断 |
信頼できるパケットロステストの条件がある場合は、ICMPの調査用パケットと実際の通信を区別してください。中継ルーターが調査用パケットへの応答を制限することがあります。途中のホップでパケットロスが多く表示されても、最終接続先が正常なら、実際の通信も同じ割合で失われているとは限りません。重要なのは、最終接続先への通信が継続的に失敗するか、転送が何度も停止するか、同じ条件で再現するかです。
1回のテストでノード、DNS、プロトコルを同時に切り替えたり、ルーターを再起動したりしないでください。比較を1組終えたら、まず基準の状態に戻してから次の項目を変更します。そうしないと速度が回復しても、どの操作が有効だったのか特定できません。
5. プロトコル：名称だけでなく通信条件を確認
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは、サーバーのパラメーターや通信条件が異なります。プロトコルの変更は、既存ノードの種類の欄を別の名称に書き換えることではありません。対応する設定がサーバー側で提供されている場合にのみ、有効な比較ができます。
- Shadowsocks：サーバーアドレス、ポート、暗号化方式、パスワードを確認します。パラメーターの不一致を暗号化方式の変更で解決しようとしないでください。
- VMess / VLESS：認証情報に加えて、通信方式と関連フィールドを確認します。WebSocketを使う場合は、PathとHostをサーバーの指定に合わせてください。
- Trojan：パスワードやTLSサーバー名などのパラメーターを確認します。TLSハンドシェイクの失敗を隠すために、証明書の検証要件を緩めないでください。
- Hysteria2：QUICをベースとし、UDP通信を利用します。遅延が大きい、またはパケットロスがある環境に適する場合がありますが、ネットワークでUDPが制限されていると、有効な接続を確立できないことがあります。
- WireGuard：UDPをベースとしています。Endpoint、鍵、サーバー設定を確認してください。トンネルは確立できても大きなリクエストの一部が停止する場合は、経路のMTUを調査します。任意のMTU値を汎用的な高速化設定として使わないでください。
たとえばサーバー設定がUDP 443の場合、TCP 443に接続できることを確認しても、Hysteria2が使える証明にはなりません。ポート番号が同じでも、トランスポート層は異なります。TCPを使う通信とUDPを使う通信では、同じネットワークでも結果が異なることがあります。
エラー：connection refused
原因と対処：接続先のポートが接続を明示的に拒否しています。ポートの誤り、サービスの停止、中継機器による拒否などが考えられます。まずサービス提供元が案内するアドレスとポートを確認し、次にサービスの稼働状態を確認してください。速度テストを繰り返しても、接続拒否は解決しません。
エラー：i/o timeout
原因と対処：ネットワーク処理のいずれかが制限時間内に完了していません。名前解決、接続、データ読み取りの各段階で発生する可能性があります。エラーの前後の状況を確認し、同じノードのままローカルネットワークを切り替えて原因を絞り込みます。パスワードの誤りと決めつけないでください。
エラー：TLS handshake timeout
原因と対処：TLSハンドシェイクが時間内に完了していません。通信経路、サーバー負荷、ハンドシェイクのパラメーターが関係している可能性があります。まずシステム時刻、TLSサーバー名、サーバー設定を確認し、別のローカルネットワークでも失敗するか比較してください。
上記はネットワーク診断で見られるエラーメッセージの例です。実際のログには接頭辞、接続先アドレス、さらに詳しい原因が含まれる場合があります。失敗した段階を判断するためのものであり、Shadowrocketのすべてのプラットフォームで同じメッセージが表示されるとは限りません。
6. ローカルネットワーク：Wi-Fi、DNS、自動接続を確認
ローカルネットワークに問題があると、すべてのノードに影響することがあります。まず同じデバイスでWi-Fiとモバイル通信を比較し、その後で必要に応じてルーターを調べます。特定のデバイスだけで問題が起きる場合は、ネットワーク全体をリセットする前に、そのデバイス上の別のVPN、フィルタリングツール、省電力設定、バックグラウンドダウンロードを確認してください。
- Wi-Fiの電波強度と混雑を確認：ルーターの近くでテストを繰り返し、可能であれば異なる周波数帯も比較します。高い周波数帯がどの距離でも速いとは限りません。同じ場所での実際の安定性を基準に判断してください。
- DNSの状態を確認：主にWebページを開く最初の待ち時間が長く、その後のダウンロードは正常な場合は、DNS設定と名前解決の失敗記録を確認します。まず現在の設定を保存し、システムDNSまたは利用中のカスタムDNSと比較してください。複数のDNS設定を同時に変更しないでください。
- 時刻とネットワークへのログインを確認：システムの日付と時刻が正しいこと、公共Wi-Fiへのログインが完了していることを確認します。ネットワークへのログインが済んでいないと、すべてのノードがタイムアウトしたり、TLS接続に失敗したりすることがあります。
- 自動再接続を確認：Settings → On Demandを開き、自動接続の条件を確認します。比較のために手動で切断する際、すぐに自動接続が再実行されないことを確認してください。テスト後は元の設定に戻します。
- 基準条件を作り直す：Wi-Fiまたはモバイル通信を切り替えた後、再接続してから3回の比較を始めます。切り替え前の接続が切れるまでの時間を、安定時の速度に含めないようにしてください。
結論：再インストールを繰り返すより、ネットワークを比較
同じデバイス、ノード、接続先で、モバイル通信では正常なのにWi-Fiでは継続して異常が起きる場合は、まずWi-Fiの接続環境とその上流の経路を確認します。ルーターやアプリの設定を変更する前に、この差を示す記録を残してください。
7. よくある質問と問い合わせ時の記録
遅延が数十ミリ秒でも、動画が止まるのはなぜ？
遅延テストは継続的な帯域の測定とは異なります。動画と画質を一つ固定し、同じノードで再生を続けて比較した後、利用中の別ノードでも試します。短いリクエストは安定しているのに長時間の転送が何度も止まる場合は、スループットの変動と発生時刻を重点的に記録してください。
Hysteria2に変更すれば必ず速くなりますか？
必ず速くなるとは限りません。サーバーからHysteria2の設定が提供されていることと、ローカルネットワークで必要なUDP通信が許可されていることを確認し、同じ接続先と時間帯で比較してください。UDPを使うプロトコルだけが失敗し、利用中のTCP設定は正常な場合は、UDPの通信経路を調べます。帯域のパラメーターをむやみに増やし続けないでください。
サブスクリプションを更新しても遅い場合、何度も更新すべきですか？
サブスクリプションの更新は設定を同期するためのもので、サーバーの帯域が増えるわけではありません。1回更新した後、ノードのアドレス、ポート、プロトコルに変更があるか確認し、接続先を固定してテストします。パラメーターに変更がなく接続もできる場合は、ノードの負荷、回線、ローカルネットワークを確認してください。
Configだけ遅く、Proxyは正常な場合、どこを変更すべきですか？
まずConfigで対象に適用されるルールとポリシーを確認します。特に、上位にあるDOMAIN-SUFFIX、GEOIPと末尾のFINALを調べてください。次に、ドメインの名前解決がルールの照合に影響していないか確認します。すべてのルールを削除せず、バックアップを取って、明らかに誤っている項目だけを修正してください。
サービス提供元への問い合わせでは、「すべてのノードが遅い」と伝えるより、最小限の条件で再現できる情報を添える方が役立ちます。サブスクリプションのURL、認証鍵、パスワードを公開記録に含めないでください。スクリーンショットやログを共有する前に、これらの情報を隠してください。
- 発生条件：日付、具体的な時刻とタイムゾーン、ローカルネットワークがWi-Fiかモバイル通信か、特定の時間帯だけに起きるか。
- 設定の範囲：ノードの識別名、プロトコル、Global Routingの状態、使用中の設定。サブスクリプションのURLや鍵全体は共有しないでください。
- 再現手順：どの種類の接続先を開いたか、どのくらい待ったか、どの段階で停止したか。操作を3回繰り返した記録も添えてください。
- 比較結果：ノードの切り替えで改善したか、ローカルネットワークの切り替えで改善したか、Directで比較できる条件が整っていたか、正確なエラーメッセージ。
トラブルシューティング後は、一時的に変更したGlobal RoutingとOn Demandの設定を元に戻し、問題を安定して再現できる記録を保管してください。原因を特定できない場合は、トラブルシューティングガイドに沿って接続と設定を確認してください。当サイトはノードやサブスクリプションを提供、販売、推奨していません。関連する設定はサービス提供元から入手してください。