症状から特定 · 段階的に確認

Shadowrocket トラブルシューティングガイド

このページでは、デバイスのネットワーク、接続スイッチ、サーバー設定、サブスクリプション、ルール、DNSを順に確認し、原因の範囲を絞り込みます。初回設定はまず Shadowrocket 使い方ガイドを読み、インポート後に問題が起きた場合は、本ページの該当する症状に沿って対処してください。

対象：iPhoneとiPad 画面上の用語は英語表記のまま システム要件はApp Storeの表示に準拠

1. 再現可能な確認の基準を作る

トラブルシューティングで最初に行うのは、設定をすぐ変更することではなく、問題がどの層で起きているかを確認することです。Shadowrocketが接続を確立する際は、現在のWi-Fiまたはモバイル通信、システムのVPN設定、選択したサーバー、プロトコルパラメータ、ルールのマッチ、DNS解決、接続先からの応答が順に関係します。どの層で失敗しても、表面上は「ウェブページが開かない」ように見えることがあります。層を分けずにスイッチを繰り返し切り替えると、明確だった問題が複数の変数が同時に変わる状態になりがちです。

印象ではなく症状を記録する

開始前に4項目を記録します。問題がWi-Fi、モバイル通信、または両方で起きるか、Shadowrocketをオフにした状態で通常のウェブページを開けるか、接続スイッチをオンのまま維持できるか、すべてのドメイン・特定のドメイン・特定のアプリだけで起きるかです。現在のGlobal RoutingがConfig、Proxy、Directのどれか、直前にサブスクリプションを更新したか、Configやサーバー、DNSを変更したかも記録してください。機密性の高いサーバー内容を保存する必要はなく、操作の順序と結果だけで十分です。

「接続できる」ことと「正しく通信できる」ことは同じではありません。システムのステータスバーにVPNの表示が出ても、システムが接続設定を受け入れたことを示すだけで、サーバーに到達できることや、ルールが想定したポリシーへリクエストを渡すことまでは保証しません。逆に、特定のウェブサイトが開けないからといって接続全体が失敗しているとは限りません。そのドメインがREJECTに一致した、DNSの応答に問題がある、接続先が応答を拒否した、現在のルールが利用できないポリシーへ渡した、といった可能性があります。

変数を最小限にした4つの比較を行う

  1. Shadowrocketをオフにし、現在のネットワークで普段から安定して開けるページを2つ表示して、ローカルネットワーク自体がデータを送受信できることを確認します。
  2. 同じネットワークと同じサーバーを維持し、Global Routingを一時的にProxyに設定して、問題が続くか確認します。
  3. 他の条件を変えずにGlobal RoutingをDirectへ変更し、接続をオンにした状態でもシステムの基本ネットワークが正常に動作するか判断します。
  4. パラメータが確認済みのサーバーを1つだけ変更して再テストし、特定サーバーの問題か全体設定の問題かを切り分けます。

この4つの結果から範囲をすばやく絞れます。Directは正常でProxyが異常なら、サーバーとプロトコルパラメータを確認します。Proxyは正常でConfigが異常なら、ルール、ポリシー名、DNSを確認します。接続をオフにすると正常でDirectも異常なら、システムのVPN設定、On Demand、その他のネットワーク拡張機能の競合を確認します。すべての状態で異常なら、まず現在のWi-Fiまたはモバイル通信を直します。比較が終わったら元のGlobal Routingに戻し、一時的なテスト状態を正式な設定として使い続けないようにします。

画面上の状態 主な役割 確認に適した問題
Config（設定） ルールを上から順にマッチング ルールの順序、ポリシー名、FINAL、DNSの振り分け
Proxy（プロキシ） リクエストを現在のProxyへ一括転送 選択したサーバーとプロトコルパラメータが利用可能か
Direct（直接接続） リクエストを現在のネットワークへ直接転送 ローカルネットワークとシステム接続設定が正常か

アプリの入手元と利用条件を確認する

デバイス上のアプリの入手元、購入履歴、アプリの識別情報を確認できない場合は、まず正規版の確認方法で、開発者がShadow Launch Technology Limitedであること、公式アイコン、アプリID 932747118を確認してください。Shadowrocketは買い切り型のクライアントですが、クライアントの買い切りと回線プランは別物です。接続には、ユーザー自身が用意したサブスクリプションまたはサーバー情報が必要です。本ガイドではクライアント内の診断方法のみを説明し、サービスの入手元を評価するものではありません。

確認中はConfigを頻繁に削除したり、既存データをまとめて上書きしたりしないでください。現在選択中のサーバーと設定名を控え、重要なカスタムルールはテキストで別に保存してから、項目ごとに変更するのが安全です。自分のサービス提供元へ問い合わせる場合は、少なくとも発生時刻、ネットワークの種類、プロトコル名、Connectivity Testの結果、特定サーバーだけの問題かどうかを伝えます。パスワード、完全なサブスクリプションURL、認証情報は通常のスクリーンショットに含めないでください。

2. 接続スイッチをオンにできない、またはすぐ戻る

Homeの接続スイッチをオンのまま維持できない場合、システムのVPN設定が未承認、既存のネットワーク拡張機能の状態異常、On Demandの繰り返し実行、またはアプリ設定がシステムに受け入れられていない可能性があります。この症状はサーバーのタイムアウトとは異なります。サーバーのタイムアウトではスイッチをオンのまま維持できてもリクエストが完了しないことがありますが、スイッチがすぐ戻る場合は、まずデバイス側の接続確立を確認し、ルールの調整は後に行います。

初回の承認とシステム状態を確認する

初めて接続をオンにすると、システムからVPN設定の追加を許可するよう求められ、デバイスのパスコード、Touch ID、Face IDでの確認が必要になる場合があります。承認途中でキャンセルした場合は、Homeに戻ってもう一度オンにし、確認画面を再表示します。承認後は、システム設定のVPN関連画面でShadowrocketに対応する設定が存在するか確認できます。システムによって画面の入口や名称は変わるため、固定されたメニュー経路ではなく、システム上で接続設定を確認できることを確認してください。

システム設定に長期間使っていないVPN設定が複数ある場合は、現在実際に使われているものを確認します。複数の接続ツールがシステムのVPN状態を連続して奪い合う状態にせず、他のネットワーク拡張機能をすべて切断してからShadowrocketをテストしてください。ネットワーク切り替え直後、デバイスのロック解除直後、通信の復旧直後は、システムが一時的な移行状態にあることがあります。10～20秒待ってから操作するほうが、スイッチを素早く連打するより判断しやすい結果を得られます。

On Demandを手動接続の問題から切り分ける

On Demandは設定されたネットワーク条件に応じて接続タイミングを決めます。条件の重複、現在のWi-Fi名の変化、接続と切断の動作を同時に含むルールにより、スイッチをオンにした直後に条件が再処理されることがあります。手動スイッチを確認するときは、SettingsでOn Demandを一時的にオフにし、Homeの手動スイッチだけをテストします。手動接続が復旧した場合、システムの承認と基本設定はおおむね利用可能です。次にOn Demandの条件を1つずつ確認し、サーバーを作り直すのは後にしてください。

条件を確認するときは、最も具体的なネットワーク条件から始めます。特定のWi-Fiを対象にした条件なら、スペースや大文字・小文字を含めて名前が完全に一致しているか確認します。ネットワーク種別に基づく条件なら、デバイスが実際にそのネットワークに接続しているか確認します。条件は一度に1つだけ有効にし、画面をロックして再度ロック解除した後、Wi-Fiとモバイル通信を切り替えてテストします。それぞれの条件が単独で動作してから組み合わせてください。

既存データを壊さずにシステム接続を作り直す

承認が完了し、On Demandも一時的にオフにしているのにスイッチがすぐ戻る場合は、まずShadowrocketを通常どおり終了して再度開きます。その後、機内モードを一度切り替えて、システムにネットワークインターフェースを再構築させます。特定のWi-Fiだけで起きる場合は、そのネットワークをいったん削除して再接続し、DHCPやローカルネットワークの状態が残っていないか確認します。Wi-Fiとモバイル通信の両方で同じなら、システム上のShadowrocket VPN設定の再作成を検討します。操作前にサーバー情報とConfigの信頼できるバックアップがあることを確認してください。

システム接続を作り直す目的は、システムにVPN設定を再度受け入れさせることであり、サブスクリプションやサーバーを削除することではありません。完了後はOn Demandをオフにし、パラメータが明確なサーバーを1つ選び、Global RoutingをProxyに設定して、通常のページを1つだけ確認します。スイッチをオンのまま維持できたら、「接続後も通信できない」の章へ進みます。それでもすぐ戻る場合はデバイスを再起動して再確認し、VPNの変更が制限される管理状態でないことを確認します。

デバイス管理とネットワーク制限を確認する

組織によって管理されているデバイスでは、VPN設定の追加や変更が制限されることがあり、承認時にシステムが通知する場合があります。この制限はShadowrocketのプロトコルパラメータを変更しても解決できず、デバイス管理者に許可されたネットワークポリシーを確認する必要があります。家庭内ネットワークのルーター制限では、通常スイッチがすぐ戻るのではなく、接続後にサーバーへ到達できない形で現れます。スイッチを安定してオンにできるかで区別してください。

最終確認では条件を単純にします。基本ネットワークが正常、On Demandがオフ、Global RoutingがProxy、サーバーは1つだけ、接続後に状態が安定するまで待つ、という状態です。これでスイッチが使えるようになったら、元の設定を1項目ずつ戻し、戻すたびにテストします。これにより、すべての設定を戻した後に同じ問題へ戻るのではなく、スイッチが戻る原因となった設定を正確に特定できます。

3. 接続成功後もウェブサイトやアプリが通信できない

スイッチがオンのままでシステムにもVPN状態が表示されるのに、ウェブサイトやアプリが通信できない場合は、特に原因が混同されやすい状態です。利用できないサーバー、プロトコルパラメータの誤り、ルールがすべてのリクエストを誤ったポリシーへ送っている、DNSが解決できない、ローカルネットワークのアドレスが誤って処理されている、といった原因が考えられます。まず「すべてのリクエストが失敗する」のか「一部だけ失敗する」のかを判断し、その後Proxy、Config、DNSのどこを確認するか決めます。

まずDirectとProxyで問題の層を分ける

Shadowrocketをオンにしたまま、Global RoutingをDirectに設定します。Directでも通常のページを開けない場合は、システムのネットワークインターフェース、ローカルネットワーク、接続設定に近い問題です。Wi-Fiとモバイル通信を切り替え、元のネットワークが通信できるか確認します。Directが正常ならProxyに戻します。Proxyですべて失敗する場合は、現在のサーバー、ポート、プロトコル、認証パラメータを確認します。Proxyは正常でConfigだけ失敗する場合、サーバー自体は主な原因ではないことが多く、ルールとポリシーの参照を確認します。

テスト中は対象ページを固定し、毎回異なるサイトを使わないでください。ブラウザがキャッシュを保持していたり、アプリが自動的に再試行したりするため、通常のHTTPSページを2つ用意し、状態を切り替えた後に接続が安定するまで待ってから更新します。片方だけ正常で、もう片方が失敗する場合は、失敗したドメインを記録し、Dataまたは接続ログで最終的にどのルールに一致したか確認します。「ネットワークが不安定」とだけまとめないでください。

Configのポリシー名とルール順序を確認する

Configはルールを上から順にマッチングし、最初に一致したルールが処理ポリシーを決めます。ルール末尾のPROXY、DIRECT、REJECT、カスタムポリシー名は、現在の設定に実際に存在するポリシーと一致していなければなりません。インポートしたConfigが存在しないポリシーグループを参照していると、リクエストが想定どおり処理されないことがあります。設定を入れ替えた後は、サーバーが残っていても、古いConfigのポリシー名が有効とは限りません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

上の例では、特定のドメインを先にPROXYへ渡し、ローカルネットワークのアドレスを直接接続し、その後GEOIPを処理し、最後にFINALで処理します。実際の設定では利用目的に合わせて順序を決めてください。FINALを途中に置くと、それより後のルールはマッチングされません。よく使うドメインを誤ってREJECTへ渡すと、特定サイトだけがすぐ失敗します。ローカルネットワークのアドレスにDirectのルールがないと、プリンター、ルーター管理画面、その他のローカルデバイスがShadowrocketのオン後に到達不能になることがあります。

リクエストが実際に送信されたか確認する

Dataで失敗したリクエストを確認するときは、総通信量だけでなく、ドメイン、接続結果、マッチしたルール、ポリシーを確認します。記録がまったくない場合は、アプリがリクエストを送っていない、キャッシュから処理された、システムネットワークがまだ復旧していない可能性があります。ドメインがあるのに解決できない場合はDNSの章へ進みます。接続先IPがあるのに接続確立がタイムアウトする場合は、サーバーまたは経路を確認します。すぐ拒否された場合はREJECTと接続先の応答を確認します。

一部のアプリは長時間接続を維持します。Global Routingやサーバーを切り替えても、古い接続がすぐ再構築されるとは限りません。テスト時は対象アプリを完全に終了して再度開くか、新しいセッションが確立されるまで待ちます。ブラウザで更新を繰り返すだけでは、すべてのアプリの動作を確認できません。ブラウザは正常で特定のアプリだけ異常なら、そのアプリが特殊な接続方式を使っていないか、古いDNSをキャッシュしていないか、ConfigにそのドメインやUSER-AGENTを対象としたルールがないか確認します。

ローカルネットワークと切り替えの境界を確認する

Wi-Fiからモバイル通信へ切り替えると、既存の接続はネットワークインターフェースの変化を経験します。Shadowrocketは通常セッションを再確立しますが、転送中のリクエストが一度失敗することがあります。状態が安定してから再テストし、切り替え直後の失敗を継続的な障害とみなさないでください。切り替えるたびに復旧できない場合は、On Demandが新しいネットワークで別の状態を選んでいないか、Configがローカルネットワークとモバイル通信で異なるDNSを使っていないか確認します。

ローカルネットワークのデバイスだけにアクセスできない場合は、アドレス範囲を確認し、適切なIP-CIDRルールでDIRECTへ渡します。範囲を無闇に広げると、本来ほかのポリシーで処理すべきパブリックアドレスまで含めることがあります。変更後はConfigを再読み込みし、具体的なローカルIPでテストします。ルールの上からのマッチングとFINALの詳しい説明は、カスタムルールと優先順位を参照してください。

4. サーバーがタイムアウトする、または接続テストに失敗する

サーバー一覧のタイムアウトは、テストリクエストが制限時間内に完了しなかったことを示しますが、「タイムアウト」だけでサーバーが応答を停止したとは判断できません。ドメイン解決の失敗、ポートへの到達不可、プロトコルパラメータの不一致、現在のネットワークのパケットロス、サービス側の制限、テスト先の応答遅延などでも同様の結果になります。「解決できるか」「ポートへ到達できるか」「プロトコル通信を完了できるか」「実際のリクエストを転送できるか」を分けて確認してください。

Connectivity Testの範囲を理解する

Connectivity Testは、現在の項目が指定されたテストを完了できるかをすばやく比較するための機能ですが、表示される数値だけで実際の使用感を判断することはできません。一時的なネットワークの揺らぎで結果が良くなることもあれば、短時間のパケットロスでタイムアウトすることもあります。同じネットワークで間隔を空けて数回テストし、タイムアウトが続くか確認したうえで、実際のHTTPSページでも検証します。一覧全体を短時間に何度もテストすると、ローカルネットワークとサーバー接続を同時に消費し、結果がかえって解釈しづらくなります。

1つの項目だけが継続的にタイムアウトし、同じサブスクリプションの他の項目が正常なら、その項目のサーバーアドレス、ポート、サービス状態を優先して確認します。すべての項目が同時にタイムアウトする場合は、まず基本ネットワークとDNSを確認し、別のローカルネットワークでも試します。Wi-Fiだけで全項目がタイムアウトし、モバイル通信が正常なら、現在のWi-Fi、ルーター、上流経路の可能性が高くなります。両方のネットワークで同じなら、インポート内容が完全か、サービス側に一括した変更がないか確認します。

プロトコルパラメータを項目ごとに確認する

サーバーを手動追加する場合、SERVER、ポート、パスワードまたは認証情報、プロトコル種別、その追加オプションは、ユーザーが保有するサーバー情報と一致している必要があります。Shadowsocksでは暗号化方式とパスワードを確認します。VMess、VLESS、Trojanではアドレス、ポート、認証情報に加え、TLS、トランスポート方式、Hostなどを確認します。WireGuardでは鍵、アドレス、ルート範囲を確認します。Hysteria2では対応する認証とトランスポートパラメータも確認します。異なるプロトコルの項目を経験だけで流用しないでください。

Scan QR CodeまたはImport from Cloud JSONでインポートした後も、項目を開いて主要フィールドがそろっているか確認します。QRコードを読み取れたことは、テキスト形式を解析できたことを示すだけで、サーバーパラメータが現在も有効とは限りません。サービス提供元がサーバー情報を変更している場合は、ユーザーが自身のサービス提供元から取得した最新情報を基準にします。意味を理解しないままTLSをオンにしたり、トランスポート方式を変更したり、Hostを書き換えたりしないでください。元々正しかった設定まで不一致になることがあります。

症状 優先して確認する項目 次の手順
特定の項目だけ継続的にタイムアウト アドレス、ポート、プロトコルパラメータ、サービス状態 元のサーバー情報とフィールドごとに照合
同じグループの項目がすべてタイムアウト サブスクリプションの内容、DNS、ローカルネットワーク ネットワークを切り替え、サブスクリプションの更新成功を確認
テストはタイムアウトするが実際には利用可能 テスト先と一時的なネットワークの揺らぎ 実際のリクエストを複数回行った結果を基準にする
Wi-Fiではタイムアウト、モバイル通信では正常 ルーター、Wi-FiのDNS、現在の経路 Wi-Fiに再接続し、ルーターの状態を確認

遅延、パケットロス、スループットを区別する

遅延は1往復に必要な時間を示し、パケットロスは再送と停止を引き起こします。スループットはサーバー負荷、経路容量、プロトコルのオーバーヘッド、ローカルネットワークの影響を受けます。遅延が小さい項目が継続通信でも速いとは限らず、遅延が大きい項目が使えないとも限りません。選択時はまず継続的なタイムアウトを除外し、その後、同じ作業で安定性を比較します。詳しい方法は遅延テストと実際の使用感の違いを参照してください。

テストが正常な状態から突然すべてタイムアウトするようになった場合は、変化の前にサブスクリプション、Config、DNS、ネットワークのどれを変更したか思い出してください。確認済みの前の状態に戻し、変更を1項目ずつ再適用します。アドレスとパラメータが正しいにもかかわらず、異なるネットワークや時間帯でもタイムアウトが続く場合は、テスト時刻、プロトコル名、匿名化した症状を自分のサービス提供元へ伝えてサービス側を確認してもらいます。クライアント内の無関係なルールを変更し続けないでください。

5. Subscribeの更新に失敗する、またはインポート後に空になる

Subscribeは、ユーザー自身が保有するサブスクリプションURLからサーバー一覧を読み込むための機能です。更新の失敗は、URLの入力、HTTPSアクセス、DNS、サービス側の応答、内容形式、ローカル一覧への書き込みのいずれの段階でも起こります。インポート後に空になる場合も、リクエストが失敗したとは限りません。Shadowrocketが認識できる項目を返していない、または既存のフィルターで項目が非表示になっている可能性があります。確認中は、専用の認証情報を含む可能性があるサブスクリプションURLを保護してください。

まずURLが完全か確認する

Subscribeで対象項目を開き、先頭部分、ドメイン、パス、クエリ部分が完全か確認します。コピー時によくある問題は、前後にスペースが混ざる、チャットアプリが長いURLを途中で切る、疑問符より前だけをコピーすることです。実際のURLを公開テストサイトへ貼り付けたり、スクリーンショットに完全なクエリ内容を表示したりしないでください。サービス提供元へ相談する場合は、ドメインとエラーメッセージだけを示し、アカウントを識別できるパス部分を隠します。

まずShadowrocketの接続をオフにし、現在の基本ネットワークからサブスクリプションのドメインへアクセスして、ドメインがHTTPS接続を確立できるか確認します。公開内容を確認する必要はなく、ローカルネットワークとドメイン解決を確認するための手順です。接続をオフにするとアクセスでき、オンにすると失敗する場合は、Configがサブスクリプションのドメインに誤ったポリシーを適用していないか確認します。ルールの上位にそのドメインへ正常に対応できるポリシーを指定してから再更新できますが、不明なドメインを広範囲のルールへ無闇に追加しないでください。

ネットワークの失敗と形式の失敗を分ける

ネットワークの失敗は、タイムアウト、ドメインを解決できない、接続が中断されるといった形で現れます。形式の失敗では、リクエストがすぐ完了するもののサーバー項目が生成されない、認識できない内容という通知が出ることがあります。前者はDNSとローカルネットワークの方向から確認し、後者はサービス側がShadowrocketに対応する現在のサブスクリプション形式を返しているか確認します。クライアントがURLを開けても、返されたテキストにインポート可能なデータが含まれるとは限りません。

同じURLが以前は更新でき、最近突然空になった場合は、古い一覧をすぐ削除しないでください。古い項目数と更新時刻を記録し、手動で一度更新して結果を確認します。新しい内容に異常がある場合、古いデータを残しておくと検証を続けやすくなります。サービス側の復旧を確認してから更新してください。すでに上書きした場合は、再インポートする前にURLが有効か確認します。サブスクリプションの内容はユーザー自身のサービス提供元が管理するため、空のテキスト、エラーページ、無効な認証情報をクライアント側で修復することはできません。

重複、名前変更、フィルターを処理する

同じURLを何度も追加するとSubscribe項目が複数作成され、更新が反映されていないように見えることがあります。実際には別の一覧を見ている可能性があります。サブスクリプション名とURLのドメインを確認し、必要な項目を残してから手動更新します。メモ、並べ替え、フィルターを使っている場合は、一時的にフィルターを解除し、新しい項目が書き込まれているか確認します。名前が変わると見慣れた項目が「消えた」ように見えることもあるため、表示名だけでなくサーバーアドレスとプロトコル種別で確認してください。

サブスクリプションの更新はサーバー情報を同期するだけで、現在のConfig内のすべてのポリシー名が新しい一覧と一致することを自動的に保証するものではありません。更新後にサーバーが存在していても、Configが参照するカスタムポリシーに利用可能なメンバーがないと、Config状態では通信できないことがあります。まずProxyで新しい項目を直接選んでテストし、項目自体が利用可能であることを確認してから、Configのポリシー関係を確認します。これにより、サブスクリプションの書き込み成功をルールの失敗と誤認したり、ルールの問題をサブスクリプションの問題と誤認したりするのを防げます。

安定した更新手順を作る

基本ネットワークが正常な状態で更新します。まず接続をオフにして通常のページへアクセスできることを確認し、次に1つのSubscribeだけを更新します。更新後に項目が変わったか確認し、1つの項目でConnectivity Testを実行し、最後に元のConfigを有効にします。自動更新の間隔を短くしすぎて利用中に頻繁に割り込ませないでください。接続のたびに大量のリクエストを同時に完了させる設計にも依存しないでください。特定のネットワークだけで更新に失敗する場合は、ネットワーク種別を記録してDNSの章へ進みます。

スキャンまたはファイルインポートでエラーが起きる場合、Scan QR Codeには完全で鮮明な内容が必要です。Import from Cloud JSONには、アプリが認識できる形式の構造が必要です。ファイルを選択できても、内容が正しいとは限りません。インポート前に元データを保存し、エラーが出たら情報の入手元から有効な内容を再取得してください。不足フィールドを推測して手入力しないでください。詳しい開始手順は使い方ガイドのインポート手順を参照してください。

6. 速度が遅い、動画が止まる、接続が不安定

速度の問題は、デバイスのローカルネットワーク、サーバー状態、通信経路、プロトコル特性、接続先の5層に分けて考えます。1回の速度測定値だけで継続的な使用感を判断できず、特定のアプリが停止したからといってサーバーのスループット不足とは限りません。同じデバイス、同じネットワーク、同じ時間帯、同じテスト内容で、変更する変数を1つだけにし、少なくとも2～3回繰り返して確認します。

まず基本ネットワークの上限を測る

Shadowrocketをオフにし、現在のWi-Fiまたはモバイル通信で基本テストを1回行い、明らかな揺らぎがないか確認します。基本ネットワーク自体が不安定なら、接続をオンにすると再送と遅延が増えるだけなので、最初にプロトコルを変更しないでください。Wi-Fiでは、ルーターとの距離、周波数帯の混雑、同じネットワーク上の他のデバイスによる大量通信、システム同期の実行状況も確認します。モバイル通信へ切り替えて再テストすると、問題が現在のWi-Fiだけに属するかをすばやく判断できます。

ダウンロード、ウェブページの表示、動画再生をテストするときは、「応答開始までの時間」と「継続転送の安定性」を分けて記録します。前者はDNS、ハンドシェイク、遅延の影響を受けやすく、後者はスループットとパケットロスに近い指標です。ページの初回表示だけ遅く、その後の転送が正常なら、解決やハンドシェイクの経路が長い可能性があります。開始は速いのに途中で何度も停止するなら、パケットロス、サーバー負荷、経路の変動を確認します。

他の条件をそろえてサーバーを比較する

ユーザー自身が保有し、パラメータが完全なサーバーを2つ選び、Global Routingを一時的にProxyに設定して、同じネットワークで同じ作業をテストします。サーバーを変えると同時にDNSやプロトコルオプションも変更しないでください。1つだけ継続的に遅いなら、そのサーバーまたは経路に近い問題です。すべてのサーバーが遅く、接続をオフにすると正常なら、関連プロトコルの通信品質、DNS、デバイス状態を確認します。接続をオフにしても遅いなら、まず基本ネットワークを確認します。

サーバーの地域は経路に影響する要素の1つにすぎず、名前だけで速度を判断できません。実際の経路は、時間帯、サービス側の負荷、接続先のアクセス地点にも左右されます。Connectivity Testの値が小さいことはテストの往復が速いことを示すだけで、継続スループットが高いとは限りません。一覧の最小値だけを追うのではなく、複数回のテストで安定し、実際の作業が継続し、エラー率が低い項目を優先します。

プロトコルと追加パラメータの一致を確認する

プロトコル設定の誤りは、速度低下だけでなく、再接続、ハンドシェイク失敗、完全な利用不能を伴うことがあります。接続はできるものの不安定なら、まずサービス側とパラメータが一致しているか確認し、その後にネットワーク特性を考えます。速度を上げる目的で、暗号化方式、TLS、トランスポート方式、UDP関連オプション、WireGuardのルート範囲を無闇に変更しないでください。クライアントとサービス側が一致していなければ、どのような「最適化」も信頼できる根拠を持ちません。

一部のリアルタイムアプリはUDPに依存し、ネットワークによってUDPの性能がTCPと異なる場合があります。ウェブページは正常なのにリアルタイム音声、ゲーム、ビデオ通話だけが異常なら、アプリの種類とネットワーク種別を記録し、自分のサーバー情報で許可される範囲でUDP対応を確認します。すべてのオプションを闇雲に切り替えて判断せず、プロトコルの要件に沿って項目ごとに確認してください。サービス側の能力を確認できない場合は、自分のサービス提供元に現在のサーバーが対応するパラメータを問い合わせます。

速度を4層で再確認するチェックリスト

ローカル層 接続をオフにしてWi-Fiとモバイル通信をテストし、基本ネットワークで継続的なパケットロスや大きな変動がないことを確認します。
サーバー層 Proxy状態とテスト内容を固定し、サーバーを1つだけ切り替えて繰り返し結果を比較します。
設定層 ProxyとConfigを比較します。Configだけ遅い場合は、ルール、DNS、ポリシーの経路を確認します。
接続先層 異なる2つの接続先で再テストし、特定サイトの速度制限、混雑、一時的な異常を除外します。

時間帯と切り替え後の一時的な変動に対処する

日中は正常で特定の時間帯だけ遅い場合は、同じ時間帯に基本ネットワークと複数のサーバーを比較し、異なる時間帯の結果を比較しないでください。ネットワークの混雑には時間的な特徴があるため、接続をオフにした結果も同時に記録しなければ、ローカルアクセスの混雑とサーバー経路の変化を区別できません。Wi-Fi、モバイル通信、サーバーを切り替えた後は、古い接続がしばらく残ることがあります。対象アプリを再度開き、新しいセッションを確立してから判断します。

テスト後はConfigに戻し、速度の問題が特定のドメインだけに影響するか確認します。Proxyは正常でConfigだけ遅い場合、そのドメインがDirectで処理されている、またはDNSが適切でないアドレスを選んでいる可能性があります。この場合、サーバーのテストを増やしても意味がありません。ルールのマッチとDNSの結果を確認してください。より詳しい層別の事例は速度低下を4層で特定する方法を参照してください。

7. DNS解決に失敗する、ドメインが開けない、結果が異常

DNSはドメインをIPアドレスへ変換します。DNSの異常は、ドメインが開けない、IPを直接入力すると応答することがある、一部のドメインだけ不安定、ネットワーク切り替え後に短時間だけ古い結果が使われる、といった形で現れます。ルールも関係することがあります。Shadowrocketはまずドメインや接続先アドレスを把握し、その後DOMAIN-SUFFIX、GEOIP、IP-CIDRなどのルールでポリシーを決めます。解決と振り分けは同じ層ではありませんが、最終的な結果には相互に影響します。

まず解決の問題か判断する

失敗するドメインと正常なドメインを1つずつ選び、同じ状態でテストします。Dataの失敗リクエストに解決不能、接続先IPなし、DNS関連エラーの即時返却が表示される場合は、解決の問題である可能性が高くなります。接続先IPが得られているのに接続段階でタイムアウトするなら、サーバーまたは経路の確認に戻ります。ブラウザの「サーバーが見つかりません」という表示だけで判断しないでください。ブラウザが異なる低レベルエラーを同じ表示にまとめている場合があります。

Direct、Proxy、Configの結果を比較します。Directは正常でConfigが異常なら、Config内のDNS設定やルールが違いを生んでいる可能性があります。Proxyは正常でDirectが異常なら、現在のローカルネットワークのDNSが対象ドメインへ異常な応答を返している可能性があります。3つすべてが失敗する場合は、ドメイン自体、デバイスのネットワーク、キャッシュを確認します。切り替えるたびにブラウザのタブを開き直し、必要に応じて短時間ネットワークを切り替えて、システムに新しい解決処理を開始させます。

ConfigのDNSとHostを確認する

.confのGeneralセクションにはDNS関連の設定を含められ、Hostセクションでは特定のドメインにマッピングを指定できます。誤ったHost項目があると、外部DNSが正常でもドメインが常に誤ったアドレスを指します。確認時はまず失敗するドメインがHostセクションにあるか検索し、次にGeneralのDNS設定が信頼でき、現在到達可能なソースから取得されているか確認します。用途を理解していない解析オプションを複数同時に追加しないでください。

[General]
dns-server = system

[Host]
router.example.com = 192.168.1.1

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

例では説明用の設定としてsystemを使い、ローカルネットワークの例示ドメインにアドレスを指定しています。実際の設定は自身のネットワーク要件に応じて決めてください。Hostのマッピングには明確な上書き効果があり、アドレスが変わった後に更新しないと、安定しているように見えて誤った結果が返ります。不明なConfigを確認する場合は、まずコピーを保存し、失敗するドメインに関係するHost項目を一時的に削除して再テストします。設定ファイルの各セクション構造はGeneral、Rule、Host、URL Rewriteの説明を参照してください。

ドメインルールとIPルールの順序を理解する

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDはドメインに基づいてマッチし、IP-CIDR、IP-CIDR6、GEOIPは接続先アドレスに基づいてマッチします。ドメインルールに一致すると、通常は後続のIPルールがそのリクエストを決定しません。ドメインルールに一致しない場合は、解決されたIPがGEOIPまたはIP-CIDRの判定に使われることがあります。ルールの順序が不適切だと、リクエストが意図しないポリシーへ進み、DNSの誤応答のように見えても、実際にはマッチ結果が想定と異なるだけということがあります。

特定のドメインを確認するときは、上位に精密なDOMAINまたは適切なDOMAIN-SUFFIXルールを一時的に追加し、検証済みの利用可能なポリシーを指定します。問題が消えれば、元のルール経路を引き続き確認します。それでも失敗するならDNSと接続先への接続を確認します。一時ルールでの検証が終わったら正式なConfigに整理して戻し、互いに上書きし合う例外を長期的に増やさないでください。

キャッシュを順序立てて削除する

システム、ブラウザ、アプリはいずれもDNSをキャッシュすることがあります。DNSを変更してすぐに1回更新しても、新しい解決が行われるとは限りません。対象アプリを終了し、Shadowrocketを切断し、機内モードを一度切り替えてから再接続し、同じドメインをテストします。ルーターの再起動、Configの削除、サーバーの変更、アプリデータの消去を同時に行わないでください。複数の操作を重ねると、復旧しても原因を特定できません。

特定のWi-Fiだけで解決異常が起きる場合は、ルーターが配布するDNS、ローカルネットワークのカスタム解決、無効なローカルドメインマッピングがないか確認します。モバイル通信が正常でも、Configが正しいとは限りません。複数のネットワークで同じドメインが異常な結果になる場合は、Host、ルール、ドメイン自体を確認します。失敗したドメイン、マッチしたポリシー、IPを取得できたか、ネットワーク種別を記録すれば、通常は解決前、解決中、解決後のどの段階かを特定できます。

8. バッテリー消費の異常とApp Store更新後の不具合

Shadowrocketはネットワーク拡張機能として通信を継続的に処理するため、接続中に一定の電力を消費するのは正常です。確認すべきなのは、同じ利用状況で消費量が突然大きく増えた、デバイスが継続的に発熱する、バックグラウンド通信が長時間減らない、App Store更新後に既存設定の動作が変わった、といった状態です。システムのバッテリー統計、Dataの通信活動、ネットワーク品質、最近変更した設定を組み合わせて判断し、特定の1時間の割合だけで判断しないでください。

クライアント処理とアプリ通信を分ける

システムのバッテリー統計では、ネットワーク拡張機能を経由した活動がShadowrocketに計上されることがありますが、実際に通信を継続しているのは、前面の動画、クラウド同期、写真のアップロード、その他のバックグラウンドアプリかもしれません。まずDataで接続に継続的なリクエストがあるか確認し、その後通信量の多いアプリを1つずつ停止します。該当アプリを停止して通信量と発熱がすぐ下がるなら、まず通信元を確認し、いきなりプロトコルを変更しないでください。

ネットワーク信号が弱いと、再送と無線通信の動作時間が増えます。モバイル通信の電波が弱い、Wi-Fiの端で利用している、ネットワークを頻繁に切り替えている場合、デバイスが接続を繰り返し再確立することがあります。安定したWi-Fiで同じサーバーとConfigを使い、一定時間再テストします。安定したネットワークで正常に戻るなら、消費電力は現在のアクセス環境に大きく関係しています。継続的にタイムアウトするサーバーも再試行を発生させるため、まず利用可能と確認済みの項目へ切り替えます。

On Demandとバックグラウンド動作の頻度を確認する

On Demandの条件が成立と不成立を繰り返すと、接続が頻繁に確立と切断を繰り返すことがあります。特定のWi-Fiを離れた後、画面をロック・解除した後、ネットワークを切り替えた後に集中しているか確認します。確認中はOn Demandを一時的にオフにし、手動で接続します。消費電力と発熱が下がるなら、条件を1つずつ再び有効にします。条件は明確で互いに競合しないようにし、同じネットワークが接続と切断の両方のロジックを満たさないようにします。

Subscribeの自動更新、Connectivity Test、大量の同時リクエストも短時間の活動を発生させます。更新間隔を短くしすぎず、バックグラウンドで全サーバーを連続テストしないでください。Configに複雑なスクリプト処理や大量のルールがある場合は、まず簡略化した設定で再テストし、特定の処理経路に関係するか判断します。簡略化する前に元のConfigを保存し、確認後に項目ごとに戻します。

更新後はまずConfigが完全か確認する

Shadowrocketの入手と更新の唯一の入口はApp Storeです。更新後に異常が起きても、すべてのデータをすぐ削除しないでください。現在のサーバーが選択されているか、Subscribe項目が残っているか、Configが以前使っていた項目か、Global Routingがテスト状態に変更されていないか、On Demandの条件が現在のネットワークに合っているかを順に確認します。画面の位置は変わることがあるため、現在のアプリ内に表示されるラベルを基準にしてください。

次に最小限のテストを行います。On Demandをオフにし、Global RoutingをDirectに設定して基本ネットワークを確認します。Proxyに変更して、パラメータが明確なサーバーを1つ選びます。最後にConfigへ戻します。DirectとProxyは正常でConfigだけ異常なら、設定の互換性とルールを確認します。Proxyが異常ならサーバーパラメータを再確認します。スイッチをオンに維持できないなら、2章へ戻ってシステムの承認とVPN設定を確認します。この順序により、更新後の1つの変化をすべてのデータが壊れたと誤認せずに済みます。

更新後に設定を戻す順序

  • App Storeでアプリの識別情報と購入履歴が正常であることを確認します。システム要件はApp Storeの表示に準拠します。
  • Homeで現在のサーバー、Global Routing、接続状態を確認し、元のConfigを先に上書きしないでください。
  • On Demandを一時的にオフにし、Direct、Proxy、Configの3つを順に比較します。
  • Subscribeを1つだけ更新し、新しい項目でConnectivity Testを実行できることを確認します。
  • カスタムルールを戻す前にテキストのコピーを保存し、元に戻せなくなる事態を防ぎます。

再起動または設定の再作成が必要な場合

更新後にシステムのネットワーク拡張機能の状態が正しく収束しない場合は、アプリを通常どおり終了してデバイスを再起動すると、一時的な状態を消去できます。再起動後も接続を確立できない場合に、システムのVPN設定の再作成を検討します。ただし、先にサーバーやサブスクリプションを削除しないでください。再作成後は最も単純な条件でテストし、成功してからOn Demandを戻します。管理対象デバイスでは、同じタイミングで管理ポリシーが変更されていないかも確認します。

バッテリー消費の問題が特定のプロトコル、特定のサーバー、特定のネットワークでだけ再現するなら、その3条件を固定して前後を比較します。異なるネットワークでもすべての設定が継続的に異常なら、システムのバッテリー統計の時間帯、Dataの活動、再現手順を記録し、App Storeで今後提供される更新説明を待ちます。本サイトではバージョン番号やリリース日を記載せず、実際の変更内容はApp Storeの表示を基準とします。

9. iPad固有：分割表示、ネットワーク切り替え、購入済みアプリの復元

iPad版のShadowrocketはiPhoneと基本概念を共有しますが、横向きの分割表示、マルチタスク、キーボード操作、Wi-Fiの利用割合、バックグラウンド状態によって症状が異なることがあります。iPhoneのタップ位置をそのまま当てはめず、現在の横向きまたは縦向きのレイアウトでHome、Config、Settings、Data、サーバー詳細がどこにあるか確認してください。システム要件と互換性は常にApp Storeの表示を基準とします。

まず購入情報とアプリの識別情報を確認する

同じApple IDでShadowrocketを購入済みの場合は、iPadのApp Storeの購入済み項目から検索して再ダウンロードできます。ストアに表示される状態が想定と異なる場合は、現在ログインしているアカウント、ストアの地域、開発者Shadow Launch Technology Limited、アプリID 932747118を確認します。詳しい手順はiPadでの入手方法と購入済みアプリの復元方法を参照してください。

Shadowrocketは買い切り型のクライアントですが、クライアントの買い切りと回線プランは別物です。iPadでアプリを再ダウンロードしても、サーバー情報が自動的に作成されることはありません。ユーザー自身が保有するサブスクリプションまたはサーバー情報が必要です。iPhoneに既存の設定がある場合は、アプリが対応するインポート方法を使い、機密フィールドを確認してください。長い認証情報やプロトコルの追加パラメータは抜けやすいため、画面のスクリーンショットだけを頼りに再入力しないでください。

横向きの分割表示で「見つからない」状態を理解する

横向きでは一覧と詳細が同時に表示され、選択した項目の内容が別の列に表示されることがあります。Configやサーバー一覧をタップしても「開いていない」と感じた場合は、右側の詳細が変化していないか確認します。縦向きでは同じ内容が階層をたどって表示されることがあり、戻り方も異なります。向きを変えた後にレイアウトがすぐ更新されない場合は、画面の再配置を待ってからアプリを閉じて再度開きます。設定を削除する必要はありません。

外付けキーボードやトラックパッドはルールの動作を変えませんが、検索欄や編集フィールドにフォーカスが残り、スクロールやショートカット操作が想定と異なることがあります。サーバーパラメータを編集した後は、保存を完了して一覧へ戻り、現在の項目が選択されたままか確認します。iPadでは多くのフィールドを同時に表示できる一方、詳細欄の古い項目を現在の項目と取り違えやすくなります。テスト前にHomeへ戻り、実際に選択されているサーバー名を確認してください。

Split Viewとバックグラウンド復帰に対処する

Split Viewなどのマルチタスク状態では、アプリのウィンドウサイズが変わりますが、ネットワーク拡張機能はシステムが管理し続けます。ウィンドウを小さくしただけで接続が切れることはありませんが、対象アプリがバックグラウンドに入った、Wi-Fiからモバイル通信へ切り替わった、システムがリソースを回収した場合は、既存セッションの再構築が必要になることがあります。分割表示中に特定のアプリだけ通信できない場合は、まず両方のアプリをそれぞれ全画面でテストし、その後分割表示に戻します。全画面では正常で分割表示だけ異常なら、Shadowrocketのルールを変更する前に対象アプリのバックグラウンド動作とセッション復帰を確認します。

iPadを長時間ロックした後に再び開くと、ステータスバーに古い状態が一時的に表示され、その後ネットワークが復旧することがあります。Wi-FiアイコンとVPN状態が安定するまで待ってからテストしてください。On Demandが有効なら、現在のWi-Fi条件に応じて接続されるか確認します。接続されない場合はOn Demandを一時的にオフにして手動でオンにし、条件判定と接続自体を切り分けます。カバーの開閉による頻繁なロック切り替えも、条件設定の不整合を目立たせることがあります。

iPadでよくあるWi-Fi環境を確認する

iPadは同じWi-Fiで長時間使われることが多いため、DHCPアドレスの変化、ルーターの再起動、ローカルDNSキャッシュ、ローカルネットワーク機器へのアクセス問題が蓄積しやすくなります。Shadowrocketをオフにして基本ネットワークをテストし、次にDirectでシステム接続を確認し、最後にProxyでサーバーを確認します。プリンター、ファイル機器、ルーター画面だけにアクセスできない場合は、ローカルネットワークのIP-CIDRルールがDIRECTへ渡されているか確認し、リモートサーバーを入れ替えないでください。

ログイン確認が必要な公共Wi-Fiでは、まず接続をオフにし、ネットワーク自体のログイン手続きを完了します。通常のウェブページが使えることを確認してからShadowrocketをオンにしてください。ログインページの手続きが完了していないと、サーバーテストが一律にタイムアウトし、サブスクリプションやプロトコルの問題と誤認しやすくなります。同じ名前の別のWi-Fiへ移動した場合、On Demandは名前だけで処理することがありますが、実際の環境は異なるため、アドレスと到達性を合わせて再確認します。

Configの移行後に段階的に確認する

別のAppleデバイスからConfigをインポートした後は、[General]、[Rule]、[Host]、URL RewriteがiPadの現在のネットワークに合っているか確認します。固定されたローカルアドレス、特定Wi-Fi向けのDNS、元のネットワークだけで使えるHostマッピングは、iPadで違いを生むことがあります。追加処理をすべて一度に有効にせず、まずサーバー、次に基本ルール、最後にHostと書き換え項目を確認します。

確認の順序はDirect、Proxy、Configです。iPadでブラウザは正常なのに分割表示中の特定アプリだけ異常なら、そのアプリを終了して再度開き、新しい接続を確立させます。すべてのアプリが異常なら、Dataにリクエストとルールのマッチがあるか確認します。接続スイッチが戻るならシステムの承認を確認し、ドメインだけ失敗するならDNSを確認します。iPadでの購入済みアプリの再ダウンロードとレイアウトの違いは、iPadの再ダウンロードと横向き分割表示を参照してください。

このガイドでも原因を特定できない場合は、デバイスの種類、ネットワーク種別、Global Routing、プロトコル名、特定サーバーだけに影響するか、Connectivity Testの結果、マッチしたルール、エラー発生時刻など、再現可能な手順を整理してください。自分のサービス提供元へ伝えるときは匿名化した情報だけを使い、完全なサブスクリプションURL、パスワード、認証情報は表示しないでください。

クイックスタートに戻る → 設定ガイドを見る → App Storeの入手情報を確認 → 技術ノートをすべて読む →