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

01 / VPN設定と接続状態

接続スイッチがオンにならない、またはすぐに切断される

許可されていない状態と、接続後に切断される状態を区別する

Homeで接続スイッチをオンにしたら、まずシステムがVPN構成の追加を求めるか、許可前にスイッチが反応しないのか、短時間接続した後にNot Connectedへ戻るのかを確認してください。この2つは問題の発生箇所が異なります。前者ではシステムの許可を、後者では現在の設定で接続を開始できるかを確認します。サーバー一覧をすぐに削除しないでください。発生時刻、使用中のネットワーク、画面に表示されたメッセージ全文を記録しておくと、システムの確認を完了していない状態をサーバーの障害と誤認せず、後から状況を再現しやすくなります。

初めてVPN構成の追加を許可する場合は、システムのダイアログで確認し、デバイスの指示に従って認証を完了してください。以前に要求をキャンセルした場合は、Shadowrocketに戻ってもう一度操作し、アプリが前面に表示されていることを確認します。次に、システムのSettingsでVPNを検索し、該当する構成があるか、ほかの接続が有効になっていないかを確認してください。メニューの場所はシステムによって異なるため、デバイスに表示される項目に従ってください。管理対象デバイスでは組織のポリシーによって変更が制限される場合があります。その際は、まずデバイス管理者に権限の範囲を確認してください。

変更を最小限にして接続環境を復旧する

まず現在の接続を切り、ほかに有効なVPNやネットワークフィルタリング機能がないか確認してください。複数の機能が同じ接続環境を取り合うのを防ぐため、一度に停止するのは一つだけにし、テスト後は元の状態に戻します。自宅のWi-Fiでは接続できるのに、別のネットワークでは接続できない場合は、そのネットワークでWeb認証が必要か確認してください。公共ネットワークのログインが完了していないと、接続要求が失敗し続けることがあります。接続を切った状態でネットワークへのログインを済ませてから再試行してください。ログインページが開かないことだけを理由に、設定が壊れていると判断しないでください。

必要な項目がそろったサーバー設定が一つあることを確認し、現在選択されている項目がまだ存在するかを確認してください。サブスクリプションの更新やグループの削除後、選択内容が変わっている場合があります。設定項目の誤りが明示された場合は、スイッチを何度も操作するのではなく、最近変更したファイルをメッセージに沿って確認してください。追加したRule、Rewriteなどの任意設定は一時的にバックアップ時の状態に戻し、基本的な接続条件を残します。これにより、問題が起動時の設定にあるのか、接続先にあるのかを切り分けられます。正常だった項目まで一緒に変更してしまうことも防げます。

システムに古いShadowrocketのVPN構成が残っている場合は、アプリ内の設定をバックアップしてから接続を停止し、該当するシステムVPN構成を削除して、アプリに戻って許可を求め直す方法があります。これはシステムの接続記録を整理する操作であり、サブスクリプションの内容を復元するものではなく、ローカルデータの復元を保証するものでもありません。アプリの削除を最初の手段にしないでください。バックアップがないまま再インストールすると、サーバー、ルール、診断に必要な情報も失われ、比較しながらの調査が難しくなることがあります。

スイッチが自動で切り替わる場合は発動条件を確認する

手動でオフにした後に自動で接続されたり、ネットワークの切り替え時に状態がすぐ変わったりする場合は、On Demandが有効になっていないか確認してください。On Demandは設定済みの条件に基づいて動作するため、手動スイッチを一度操作した結果とは分けて考えます。基準を確認するため、条件を記録して一時的に無効にし、手動での接続と切断をそれぞれテストしてください。状態が安定したら、条件を一つずつ戻します。特に、指定したWi-Fi、モバイル通信、ドメインによる発動条件の間で、相反する動作が設定されていないか確認してください。条件の詳細はOn Demandの設定方法をご覧ください。

03 / サーバーとプロトコルの接続

サーバーがタイムアウトする、接続がリセットされる

テスト結果と実際のサービス利用を分けて考える

Connectivity Testの結果は、指定したテスト方法と対象における一度の観測です。タイムアウトの原因には、サーバーに到達できない、テスト先が応答しない、プロトコルのハンドシェイクに失敗する、現在のネットワークが該当する通信に影響しているなど、複数の可能性があります。まず実際に使っているテスト方法と対象の設定を確認し、Webページへのアクセスでも比較してください。一度のテスト失敗だけで、利用中のサーバーが無効だとは判断できません。反対に、テストで数値が表示されても、ログイン、動画再生、その他のサービスが正常に利用できるとは限りません。テスト結果と実際の利用結果は、それぞれ異なる点を確認しています。

サーバーのアドレスとポートが、自分でお持ちの有効な情報と一致しているかを確認してください。コピー時に空白、改行、全角の句読点が混入していないかも確認します。アドレス欄には通常、ホスト名またはアドレスを入力します。サブスクリプションのURL全体を誤って入力しないでください。また、接続先のアドレス、TLSのサーバー名、転送層のHostは区別して確認します。設定によっては異なる値を使いますが、サーバー側の指定と一致している必要があります。見た目をそろえるために3つの項目を同じ値に変更すると、正しいルーティングや証明書の検証条件を損なうことがあります。

プロトコルごとに関連する項目をまとめて確認する

設定を確認するときは、複数の記録から項目を寄せ集めるのではなく、一つの設定全体を元の情報と照らし合わせてください。転送方式、パス、Host、TLSの組み合わせには依存関係があることが多く、そのうち一つだけ変更すると、接続後すぐに切断される場合があります。サブスクリプションからインポートした記録は、まずサブスクリプション内の該当項目を確認してから、手動編集が必要か判断してください。VMessなどの用語は用語集をご覧ください。この表は確認の順序を示すもので、プロトコル設定の全項目を網羅するものではありません。

証明書に関するエラーでは、デバイスの日付と時刻が正確か、ネットワーク認証が未完了でないか、サーバー名が正しいかも確認してください。証明書の検証を無効にする方法を一般的な修復策として使わないでください。アドレスの入力ミス、証明書の期限切れ、名前の不一致を見逃すおそれがあります。既存の情報で特定の名前が指定されている場合は、元の情報の提供元に正しい値を確認してください。デバイスの時刻と名前を確認してもエラーが続く場合は、エラーの種類と発生したネットワークを記録し、サーバーの管理者に証明書チェーンとサーバー側の待ち受け状態を確認してもらってください。

ネットワークを比較して接続先の問題を絞り込む

予期しない通信料金が発生しない範囲で、同じサーバー、同じテスト対象を使い、Wi-Fiとモバイル通信だけを切り替えてください。一方のネットワークでのみタイムアウトする場合は、そのネットワークの名前解決、通信制限、経路に関係する可能性が高くなります。複数のネットワークで失敗する場合は、接続先のサービス状態と認証情報を確認してください。一部のプロトコルはUDPに依存します。Webサイトに直接アクセスできても、その通信方式が使えるとは限りません。根拠のないままポートや転送方式を変更しないでください。サーバー側との対応が必要な項目です。

すでに複数の利用可能な設定をお持ちの場合は、正常と分かっている別の設定で一度だけ比較できます。ただし、その結果からサービス全体の品質を評価することはできません。連続して多数のテストを行うと、一時的な混雑と実際の設定ミスが混ざり、判断が難しくなります。調査後にサーバー管理者へ連絡する場合は、プロトコル、エラーが発生した段階、ネットワークの種類、個人情報を除いたエラーメッセージを伝えてください。パスワード、完全な識別情報、サブスクリプションURLを公開画像に含めないでください。認証は成功しているのに特定のアクセス先だけ失敗する場合は、認証項目を繰り返し入力するのではなく、ルールとDNSの章に戻ってください。

05 / 通信速度、遅延、アクセス先の違い

接続は正常だが通信速度が遅い

「遅い」を比較できる状態にする

速度が遅いという症状には、ページを開くまでの待ち時間が長い、継続的な通信速度が低い、動画が何度もバッファリングする、操作中の要求が時々止まるなど、少なくとも複数の種類があります。原因が共通とは限りません。具体的なアプリ、アクセス先のドメイン、ネットワークの種類、遅くなる段階を記録し、同じアクセス先で少数回のテストを繰り返してください。Connectivity Testの数値は、主にそのテスト条件での結果であり、実際の通信速度と同じではありません。テスト応答が速い設定でも、実際のアクセス先までの経路が混雑することがあります。日常的に使う接続先を一つのテスト結果だけで決めないでください。

まず接続を切り、基本ネットワークが安定しているか確認します。Wi-Fiの電波強度、ルーターの負荷、ほかのデバイスが大量の通信を行っていないかを確認してください。モバイル通信は電波、場所、ネットワークの切り替えにも影響されます。テスト中はデバイスの位置とネットワークを固定し、帯域を大きく使う同期処理を一時停止してください。基本ネットワークの状態が不安定な場合は、まず安定させてからプロキシ経路を評価します。そうしないと、テスト結果の違いが変更した設定ではなく、無線環境の変化によるものかもしれません。

名前解決の待ち時間と継続的な通信の問題を区別する

特定のドメインを初めて開くときだけ遅く、読み込み開始後は安定して通信できる場合は、DNSと接続の確立段階を優先して確認します。ページ内の文字はすぐ表示されるのに、画像や動画の読み込みが遅い場合は、アクセス先までの経路、接続先の負荷、実際の振り分け結果を確認してください。種類の異なるページを比較する場合は、ページごとのデータ量も異なる点を考慮します。軽いページが速く開いたからといって、すべて復旧したとは限りません。ブラウザーのキャッシュでも体感が変わるため、初回アクセスかキャッシュ済みの内容かを記録して再テストしてください。

Configで、遅い要求が想定したポリシーを使っているか確認してください。ページによっては複数のドメインに同時アクセスします。メインサイトがPROXYを使い、リソースのドメインがDIRECTになっていると、本文は表示されても画像の読み込みが止まることがあります。実際の要求記録から失敗しているリソースのドメインを特定し、必要なRuleを追加するか判断してください。範囲を広げるためだけにDOMAIN-KEYWORDを使うと、無関係なアクセス先にも影響し、不要な迂回が生じることがあります。特定サイトのRuleの書き方はDOMAIN-SUFFIXとFINALの例をご覧ください。

ProxyとConfigの両方で速度が遅い場合は、テスト対象を変えず、同じネットワークで自分がすでにお持ちの別の有効な設定と比較してください。結果から分かるのは今回の経路に違いがあることだけで、長期的な品質は判断できません。サーバーの負荷、アクセス先の速度制限、ネットワーク間の経路は時間とともに変化します。大容量のテストを繰り返すとデータ通信量が増え、ほかの要求にも影響します。必要な情報を得るための回数にとどめてください。継続的に測定する場合は、まず自分の通信条件を確認し、調査自体が新たな帯域消費にならないようにします。

根拠のないパラメーター変更で原因を探らない

接続が長時間止まる、大きなデータの一部だけ失敗し小さな要求は正常、といった場合は、経路や転送条件をさらに確認できます。ただし、MTU、同時接続数、プロトコルのパラメーターをむやみに変更しないでください。これらはネットワークとサーバー側の条件に左右され、値を小さくしても大きくしても副作用が生じることがあります。まず初期値または正常と分かっている値を維持し、問題が特定のネットワークだけで起きるか記録してください。明確なエラーの手がかりが得られた場合や、管理者から適合する値が示された場合に限り、一項目ずつ比較し、すぐ戻せるよう元の値を保存します。無関係な状況の設定をそのまま流用しないでください。

デバイスの発熱、低電力モード、バックグラウンド同期、アクセス先アプリのデコード処理によって、「ページの動作が重い」状態がネットワークの遅さに見えることもあります。別のアプリで同じような種類のコンテンツにアクセスし、ネットワーク待ちなのか画面操作の遅れなのかを比較してください。特定のアクセス先だけが常に遅く、ほかは正常な場合は、アクセス先のサービス状態も考慮し、クライアント設定を際限なく変更しないでください。修復後は、普段使うページ、継続的な通信、ネットワークの切り替えを確認し、短時間のキャッシュ効果ではないことを確かめてから、日常の設定とバックグラウンドタスクを元に戻してください。

07 / 使用時間と接続の繰り返し

バッテリー消費の増加とデバイスの発熱

同じ条件でバッテリー消費を比較する

システムのバッテリー画面に表示されるアプリの使用割合は、選択した期間の集計であり、あらゆる状況での固定的な消費量を示すものではありません。使用時間、画面の点灯時間、ネットワーク環境、ほかのアプリの動作によって割合は変わります。まず使用量とネットワークが近い時間帯同士で比較し、大量のデータ通信、接続の繰り返し、デバイスの継続的な発熱がないかを確認してください。割合が増えただけで異常とは限りません。ほかのアプリの使用が減ると、同じ動作でも全体に占める割合が高くなります。

設定変更、サブスクリプション更新、ネットワーク切り替え、アプリ更新のどれが発生した後から消費が増えたかを記録し、画面点灯中と待機中を区別してください。待機中に継続的なネットワーク通信がある場合は、写真の同期、ファイル転送、動画や音楽の再生などのタスクが接続を使っていないかを確認します。クライアントがほかのアプリのデータを処理すると負荷は発生しますが、実際に通信を発生させているのはバックグラウンドタスクの場合があります。確認時は、明らかな大容量通信を一時停止してから接続が安定するか観察してください。統計の項目名だけから消費の原因全体を判断しないでください。

On Demandとネットワークの頻繁な切り替えを確認する

Wi-Fiの電波が弱いとモバイル通信との切り替えが繰り返され、ハンドシェイクや接続の再確立が何度も発生することがあります。On Demandのルールで2つのネットワークに異なる動作が設定されている場合、切り替え時に状態がさらに変化します。まず電波の安定した場所で一つのネットワークに固定して比較し、自動で接続する条件を記録して一時的に無効にしたうえで、待機中の動作が大きく変わるか確認してください。テスト後は必要なルールを戻します。バッテリー消費を減らすために、必要な接続条件を永久に削除するのではなく、再発を引き起こしているネットワークやルールの組み合わせを特定してください。

サーバー認証が繰り返し失敗したり、接続先から何度も切断されたりすると、デバイスが復旧を繰り返すことがあります。まずサーバーのタイムアウトの章に沿って問題を解決してから、バッテリー消費を評価してください。画面をロックしただけでは、誤った認証条件は直りません。記録に短時間で同じエラーが繰り返し表示されていないか、ネットワークを切り替えた後に毎回発生していないかを確認してください。規則的な再試行のほうが、一度だけの電池残量の変化よりも問題を把握する手がかりになります。必要であれば現在の接続を停止し、成功の見込みがない状態で再試行が続かないようにして、個人情報を除いた記録を一定時間分保存してください。

調査自体が発生させる余分な動作を減らす

Connectivity Testの一括実行、サブスクリプションの頻繁な自動更新、詳細な接続記録の継続は、調査中の通信量や処理負荷を増やすことがあります。問題を特定するのに必要な範囲で診断レベルを有効にし、手がかりを得たら普段の設定に戻してください。バッテリー消費を調べるために複数のテストを同時に繰り返したり、多数の対象ページを続けて再読み込みしたりしないでください。一時的なタスクを停止した後に正常化した場合は、まずテスト頻度を調整します。安定して使えていたプロトコル設定まで変更する必要はありません。診断時の負荷と日常的な接続負荷は分けて評価してください。

デバイスの発熱は性能にも影響し、Webページの動作が遅く見えることがあります。大容量通信を停止し、デバイスが通常の温度に戻ってから比較してください。充電状態、画面の明るさ、周囲の温度も観察結果に影響するため、できるだけ条件をそろえます。本体の表面温度だけで特定の部品が故障したと判断しないでください。接続を切っても異常が続く場合は、システムのバッテリー画面でほかの動作を確認し、デバイスのシステムが案内する手順に従ってください。デバイスのバッテリーに関するすべての問題を、特定のネットワーク設定のせいにしないでください。

復旧の確認では、通常の使用を一度行い、それに近い条件で一定時間待機させて観察してください。特定の数値まで割合が下がることではなく、接続の繰り返しが止まり、バックグラウンドタスクが想定どおりに動作し、同じ使い方で異常な発熱が再発しないことが目安です。報告時には統計の期間、ネットワークの種類、On Demandの使用状況、大量のテストを行ったかを伝えてください。アクセス先のドメイン、サーバー情報、個人の利用状況が含まれる可能性があるため、接続記録をそのまま公開しないでください。異常が起きた時刻の前後で必要な部分だけを保存します。

09 / iPadのネットワークとマルチタスク

iPadの接続と復旧に関する確認

購入の復元と設定の移行を分けて考える

iPadで利用を再開する際は、App Storeに該当する購入記録を持つアカウントでサインインしていることを確認し、iPadでの入手方法に従ってください。システム要件と購入の互換性はApp Storeのページでご確認ください。アプリを再び入手できても、以前のデバイスのサーバー設定やConfigが新しいデバイスに自動で表示されるわけではありません。購入記録とユーザー設定は別のものです。初回起動後は接続スイッチをすぐにオンにして接続の失敗を確認するのではなく、既存のサブスクリプション、サーバー情報、ファイルがそろっているかを一つずつ確認してください。

別のデバイスから設定を移行する場合は、自分で保存した有効なバックアップ、またはすでにお持ちの情報を使って再インポートし、選択中のサーバー、Global Routing、現在のConfigを確認してください。グループ名が同じでも、内容が完全に同一とは限りません。特にアドレス、認証パラメーター、ルール末尾のFINALを確認します。サーバー一覧だけをインポートし、対応するルールファイルを移行していないと、Configでの動作が以前のデバイスと異なることがあります。まずはじめにに沿って基本接続を確立してから複雑なRuleを戻すと、任意設定をすべて一度に移すより不足項目を特定しやすくなります。

複数のウィンドウは独立した接続環境ではない

iPadのSplit Viewや複数ウィンドウを使うと、マニュアルとアプリを並べて確認できますが、システムのネットワーク接続状態は共通です。ウィンドウを切り替えたり、サイズを変えたり、ホーム画面に戻ったりしても、独立したVPNセッションが新たに作成されるわけではありません。調査ではブラウザーのウィンドウとテスト対象を一つに固定してください。別のウィンドウにキャッシュ済みページが残っていると、状況が食い違って見えることがあります。一方のウィンドウでは正常で、もう一方では失敗する場合は、要求記録を調べる前に、アクセスしたドメイン、ログイン状態、ページを実際に再読み込みしたかを比較してください。ウィンドウの違いだけでルーティングルールの問題と判断しないでください。

iPadにはWi-Fiのみのモデルと、モバイル通信に対応するモデルがあります。モバイル通信が使えないデバイスでは、利用する権限のある別のWi-Fiネットワークで比較できます。ただし、インターネット共有を使う場合は、上流のネットワーク自体も変わる可能性があります。サーバーとテスト対象を変えず、接続方法を記録してください。公共Wi-Fiでは、まず認証ページでの手続きを完了してください。画面ロック後に復帰するとアクセスできない場合は、システムのVPN構成をすぐに削除するのではなく、Wi-Fiが接続されたままかを確認してからVPNの状態を確認します。

画面ロック、バックグラウンドタスク、管理対象デバイス

画面ロック後にダウンロードが止まっても、接続の障害とは限りません。対象アプリのバックグラウンド動作の条件によって、タスクの継続時間が変わることがあります。まず画面のロックを解除し、ブラウザーで新しい小さな要求を送って接続できるか確認してください。新しい要求が成功しても元のタスクが再開しない場合は、元のアプリのタスク状態を確認します。新しい要求がすべて失敗する場合は、On Demand、ネットワークの切り替え、サーバーの再接続記録を確認してください。一つのファイル転送が停止しただけでシステム全体のネットワークが切断されたと判断したり、原因を隠すために画面を点灯し続けたりしないでください。

学校、企業、その他の組織が管理するiPadでは、VPN構成、証明書、ネットワークフィルタリング、設定変更の権限が制限されている場合があります。システムに管理対象であることが表示されているか確認し、許可されている使い方を管理者に確認してください。内容が分からない管理設定や証明書を試しに削除しないでください。必要な業務やデバイスの権限に関係している可能性があります。個人所有の一般的なデバイスでも、操作前に既存のシステム設定を記録し、影響範囲を確認してください。VPNを追加できない問題は認証の章に戻って確認します。サーバーの認証パラメーターを変更して解決しようとしないでください。

同じWi-FiでもiPadと別のデバイスで動作が異なる場合、Wi-Fiが同じだからといってデバイス側の違いを除外せず、システム時刻、DNS、現在のConfig、サーバーの選択を一つずつ比較してください。ブラウザーのプライバシー設定、保存済みのネットワーク条件、対象アプリの権限も、要求経路や動作に影響する場合があります。同じアクセス先に同じ操作を行ってテストし、まずアプリの実際の要求記録から違いを確認してください。異なるアプリのトップページ同士だけを比較しても、信頼できるネットワーク上の結論は得にくくなります。