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

01 · システムの許可と接続状態

接続スイッチが入らない、または入れてもすぐ切れる

まず、どの段階で接続に失敗するか確認します。タップしても反応がない、システムの許可画面が表示されるが完了しない、接続してもすぐ切れる、の3つでは確認箇所が異なります。スイッチはシステムのネットワーク拡張を起動するもので、サーバー経由で通信できることを示すものではありません。接続を維持できる状態になって初めて、サーバーテストやWebページでの確認に意味が出ます。手動で状態を確認できるよう、トラブルシューティング中はOn Demandを一時的にオフにしてください。

まずシステムの許可を完了し、その後に設定を確認

初回起動時に、VPN構成の追加を許可するかシステムから確認される場合があります。操作のきっかけが、直前に起動したShadowrocketであることを確認し、画面の指示に従って許可とデバイス認証を完了してください。以前に確認画面をキャンセルした場合は、アプリに戻って再度接続を試し、確認画面が表示されるか見ます。学校や職場の管理対象デバイスでは、管理ポリシーによって許可が制限されることがあります。この制限はサーバー設定を変更しても解消できないため、ネットワーク構成の追加や実行が許可されているか確認してください。

システムのSettingsを開き、VPN関連の設定にShadowrocketの構成があるか確認します。また、ほかのネットワーク接続が有効になっていないかも確認してください。まずほかの接続を停止してからShadowrocketを試し、複数のネットワーク機能を同時に変更しないようにします。ステータスバーのアイコンだけで成功と判断しないでください。デバイスや表示状況によって一部の状態が表示されないことがあります。アプリ内の接続状態とシステムのVPN画面をあわせて確認してください。

設定の読み込み失敗とサーバーとの通信失敗を切り分ける

システムの許可が完了していてもスイッチがすぐ戻る場合は、Configで選択中の設定が正常に開けるか確認してください。直前に手動で編集した項目、未完了の設定の読み込み、参照先のポリシー名が残っているかに注意します。新しい設定を重ねるのではなく、保存しておいた変更前のコピーに戻してください。復元後に接続を維持できるなら、確認すべきなのは設定の差分です。すぐにアプリを削除したり、すべてのサーバー情報を作り直したりする必要はありません。

Homeに使用可能なサーバーが登録されていること、プロキシを使うモードで対象サーバーが選択されていることも確認します。サーバー一覧が空、グループ内の項目が参照切れ、設定が削除済みの名前を参照している、といった状態では接続結果が想定と異なることがあります。設定情報をご自身で確認済みのサーバーを1つ選び、必要最小限の条件でテストしてください。必要最小限にするのは設定への依存を減らすためであり、証明書の検証を無効にしたり、すべての通信を常に同じポリシーにしたりすることではありません。

元に戻せる手順でシステム側を確認する

まず接続を通常の方法で切り、編集中の画面を閉じてからアプリを再度開き、もう一度試してください。それでも失敗する場合はデバイスを再起動し、システムのネットワーク拡張を初期化します。再起動前に、保存していない設定変更を保存してください。ネットワークを切り替えた後だけ問題が起きる場合は、安定したWi-Fiで確認してから、モバイル通信の許可を別途確認します。デバイスの空き容量が不足している場合は、設定や診断記録の保存を妨げないよう必要な空き容量を確保してください。確認せずに設定ファイルを削除しないでください。

設定をバックアップし、サーバー情報を再読み込みでき、システム構成が破損していることを確認できた場合に限り、該当するVPN構成をシステムから削除してアプリに再作成させることを検討してください。操作前にOn Demandをオフにし、接続を停止します。削除後に自動接続が始まり、操作が中断されるのを防ぐためです。「ネットワーク設定をリセット」はほかのネットワーク情報にも影響し、設定値の誤りを直せるとは限らないため、最初の手段にしないでください。再度許可を完了したら、まずスイッチが安定してオンの状態を保てるか確認し、次の章で実際の通信をテストします。

02 · 基本ネットワーク、モード、ルール

接続済みと表示されるのにWebやアプリを利用できない

まずShadowrocketをオフにして、通常なら直接開けるWebページにアクセスし、デバイスがインターネットに接続されていることを確認します。公共Wi-Fiでは先にログインが必要な場合があります。また、ルーターがローカルネットワークには接続していても、外部ネットワークには接続できていないことがあります。基本のネットワーク接続が復旧していない状態では、プロキシ設定を変えても解決しません。ログインを完了するかネットワークを復旧した後、Shadowrocketをオンにして同じページを再確認します。できるだけ対象と時刻をそろえてテストしてください。

Global Routingで問題の範囲を絞る

Global RoutingのConfig、Proxy、Directは、原因を切り分けるうえで重要な区分です。Configは現在の設定ルールに従ってポリシーを選択し、Proxyは現在のプロキシ経路を確認するために使います。Directでは直接接続した場合の状態を確認できます。これらはネットワーク品質の段階を示すものではなく、すべての接続先にアクセスできることを保証するものでもありません。テスト前に元のモードを記録し、毎回変更するのは1項目だけにして、どの経路を確認しているか明確にしてください。テスト後に元の設定へ戻し忘れないよう注意します。

Directでテスト用のWebページにアクセスでき、Proxyでは失敗する場合は、すべてのルールをすぐに変更せず、まず選択中のサーバーを確認してください。Proxyでは正常でConfigだけ失敗する場合は、Configで対象に適用されたポリシーを確認します。早い段階でマッチしたREJECTや、プロキシが必要な対象をDIRECTに振り分けている可能性があります。3つのモードすべてで問題が起きる場合は、基本のネットワーク、DNS、システム接続も確認してください。Webページを一度開けなかっただけで、サブスクリプションが使えないと判断しないでください。

ルールの順序と実際の接続先を確認する

ルールは通常、上から順に照合されます。上位の広い条件が下位の具体的なルールに先に適用されることがあります。以下の例は、具体的な条件を先に指定し、最後にFINALを使う構成を示すもので、既存の設定をそのまま置き換えるためのものではありません。PROXYを使うには、現在の設定で参照できるポリシーが必要です。既存の設定で別のポリシー名を使っている場合は、実際の定義を確認してください。コピー上で編集し、記録でマッチした結果を確認します。ファイルの記述だけを見て、実際の経路を推測しないでください。

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

Webページは通常、複数のドメインにリクエストを送ります。ページ本体、画像、ログイン用API、メディアなどがそれぞれ別の接続先を使うことがあります。そのため、トップページは開けてもログインに失敗する場合、振り分けが一貫していない可能性があります。失敗したときの接続記録で、実際に失敗したドメインと適用されたポリシーを特定してから、ルールの変更が必要か判断してください。手間を省くために関係のないドメインまで同じポリシーに変更したり、ページタイトルだけを根拠にすべてのリクエストが同じ接続先を使うと考えたりしないでください。

アプリのセッションとローカルネットワークの影響を切り分ける

モードを切り替えても、既存の長時間接続が以前のセッションを使い続けることがあります。テスト中のアプリで関連画面を閉じ、新しいリクエストを開始してください。必要に応じて接続を通常の方法で一度切り、再接続してから結果を比較します。特定のアプリだけで問題が起きる場合は、ブラウザでも同じサービスを確認し、アプリのキャッシュやログイン状態、ネットワーク経路を切り分けます。サービス側のメンテナンス、認証失敗、アクセス制限でも読み込みが止まることがあります。「ほかのWebページは開ける」という理由だけで、ルールに問題がないと判断しないでください。

ルーターの管理画面、ローカルネットワーク上のデバイス、家庭内ストレージにアクセスする場合は、ローカルネットワークのセグメントが誤ってプロキシ経由になっていないか確認します。例のネットワーク範囲をそのまま使わず、現在のネットワークで割り当てられているアドレスを基準にしてください。接続記録でルールに問題がないのにドメインを解決できない場合はDNSの章へ、名前解決はできてもサーバーへの経路が確立できない場合はサーバーのタイムアウトの章へ進みます。この切り分けを行うことで、ルール、サブスクリプション、システム設定の間を何度も行き来して変更せずに済みます。

03 · 接続先、認証、通信方式

サーバーがタイムアウトする、またはConnectivity Testに失敗する

タイムアウトは、あるテストが所定の時間内に完了しなかったことを示すだけで、特定の設定項目が誤っていると直接示すものではありません。まずテストの種類を確認してください。ポート接続、プロキシ経由のWebリクエスト、DNSクエリ、アプリ内のConnectivity Testでは、確認している段階が異なります。ポートに接続できても認証やデータ転送が成功するとは限りません。Webテストの失敗も、テスト先が一時的に利用できないことが原因の場合があります。テスト対象とエラー内容を記録すると、何度もテストを繰り返すより原因を特定しやすくなります。

サーバーのアドレスとポートから確認する

該当するサーバー情報を開き、ご利用のサービス事業者から提供された情報とAddress、Portを照合します。Addressには通常、ホスト名またはアドレスを入力します。Webページの完全なURL、パス、余分な空白を一緒に貼り付けないでください。Portはサーバーの実際の待受ポートと一致させます。プロトコル名から推測しないでください。アドレスがドメイン名の場合は、まず名前解決できるか確認します。名前解決が完了していないなら、Passwordや通信設定を変更しても通常は意味がありません。

次にプロトコルの種類と認証項目を確認します。TrojanのPassword、VMessやVLESSの識別情報、Shadowsocksの暗号化方式とパスワードはそれぞれ役割が異なり、相互に置き換えることはできません。読み込みに成功したことは、テキストが認識されたことを示すだけで、接続先の設定が検証済みという意味ではありません。手動で入力した場合は、コピーした内容に改行、先頭や末尾の空白、全角の句読点が含まれていないか確認してください。変更を保存してから該当の情報を再選択し、編集した項目をテストしていることを確認します。

TLSと通信設定は個別に確認する

TLSを使う場合、AddressとSNIは同じとは限りません。Addressは接続先の端点を指定し、SNIはサーバー名の通知と証明書の検証に使われます。実際のサーバー設定に合わせて入力し、任意のドメインをSNIに指定しないでください。システムの日付、時刻、タイムゾーンが正しいか確認します。時刻のずれにより証明書の検証に失敗することがあります。記録に証明書名の不一致や期限切れが表示された場合は、接続先の設定を確認してください。検証を無視する設定を恒久的な対処にしないでください。

サーバーに別途通信方式の指定がある場合は、Host、Path、通信方式も確認します。Pathの先頭のスラッシュ、大文字と小文字、追加情報が経路に影響することがあります。「だいたい同じ」かどうかだけで判断しないでください。Hysteria2などUDPを使う接続では、現在のネットワークで該当する通信が許可されているかも確認します。TCPでWebページを開けても、UDPの経路が正常とは限りません。複数のプロトコル項目を同時に変えるより、ご自身が利用できる別のネットワークで比較するほうが、原因を特定しやすくなります。

条件を変えてローカル側と接続先側を切り分ける

同じサーバー情報を使い、Wi-Fiとモバイル通信でそれぞれテストします。次に同じネットワークのまま、ご自身が利用できる別のサーバー情報をテストします。前者はネットワークの違いを、後者は特定の接続先に問題があるかを判断するのに役立ちます。ネットワーク、サーバー、設定を同時に変えないでください。復旧しても原因を特定できなくなります。同じ接続先が複数のネットワークで失敗し、ほかの登録済み接続先は正常な場合は、元のサービス事業者に接続先の状態や設定変更の有無を確認してください。

サービス事業者に問題を伝える際は、機密情報を削除したエラーの種類、ネットワーク環境、テスト時刻を伝えてください。認証情報全体を公開しないでください。ポートに接続できても実際のWebリクエストに失敗する場合は、認証、通信方式、接続先の応答を続けて確認します。登録済みの接続先がすべて特定のネットワークだけで失敗する場合は、まずネットワークとルーターを確認してください。Trojanの各項目の意味については、ShadowrocketのTrojan設定項目もご覧ください。設定を試しに入力して済ませず、提供された情報と照合してください。

04 · データの取得、解析、ローカル一覧

サブスクリプションを更新できない、または読み込み後にサーバーが表示されない

サブスクリプションの更新には、URLへの接続、応答の取得、内容の判別、項目の解析、ローカル一覧の更新という複数の段階があります。一覧が空でも、URLに接続できないとは限りません。サーバーからログイン画面やエラーメッセージが返された場合、または現在の読み込み方法で認識できない内容だった場合もあります。まず更新時に表示されたエラーを記録し、URLと応答の段階を確認してください。既存の一覧を続けて削除しないでください。以前の項目がまだ使える場合があり、今回の更新との差を調べるための重要な比較対象にもなります。

サブスクリプションURLと単一サーバーの共有リンクを区別する

ご自身のサービス事業者に完全なサブスクリプションURLを確認し、コピー時にクエリパラメーター、末尾の文字、必要な認証情報が抜けていないか確認します。サブスクリプションURLと単一サーバーの共有リンクは用途が異なります。前者は通常、更新可能な複数の接続情報を取得し、後者は1つの接続先を表します。単一サーバーの情報をサブスクリプション更新の入力欄に貼り付けたり、設定ファイルのURLをサーバーのサブスクリプションとして扱ったりすると、認識に失敗することがあります。URLが長いかどうかだけで判断せず、内容に合った方法を選んでください。

コピーした内容に説明文、引用符、空白、改行が含まれていないかも確認します。共有機能によってはタイトルとURLが一緒にコピーされるため、実際のURLだけを残してください。サブスクリプションに含まれる認証情報は機密情報です。公開のURL確認ページに貼り付けたり、掲示板で代わりにテストしてもらうために送ったりしないでください。問題を説明する場合は、エラーの種類を伝え、URLから識別情報を完全に削除してください。数文字だけを隠す方法では不十分です。

リクエストの失敗と、応答内容の誤りを見分ける

ホスト名の解決、接続タイムアウト、TLSに関するエラーが表示された場合は、まずサブスクリプションのドメイン名の解決とリクエスト経路を確認します。更新リクエストがプロキシ経由になるかどうかは、設定や現在の構成によって異なります。Webページを開けても、更新リクエストも同じ経路を使うとは限りません。現在選択中のサーバーが利用できず、サブスクリプションのリクエストがそのサーバーに依存していると、更新に失敗し続ける場合があります。利用可能で許可されたネットワーク環境でリクエストを確認し、現在の設定を残してください。「接続先の変更」と「サブスクリプションの再取得」を一度に行わないでください。

アクセス拒否やリソースが見つからないというエラーの場合は、URLがサービス事業者によって変更されていないか、認証情報が無効になっていないか、アカウントで取得が許可されているかを優先して確認します。リダイレクトが発生した場合は、最終的な応答がサブスクリプションの内容なのか、ログインが必要なWebページなのかも確認してください。ブラウザでページが開けても、エラーの説明が表示されているだけの場合があります。反対に、ブラウザでテキストを取得・表示できても、含まれるすべてのサーバー情報を現在の読み込み方法で認識できるとは限りません。

一覧が空の場合は、フィルター、解析、上書きの有無を確認する

内容を受信したのに項目が表示されない場合は、まずHomeで検索条件を解除し、該当するグループを展開して、更新したサブスクリプションを表示しているか確認します。更新前後の項目数と名前を比べ、まったく解析されていないのか、一部のプロトコルや項目だけが認識されていないのかを判断します。サブスクリプション自体にフィルター条件がある場合は、すべての項目が除外されていないか確認してください。空のグループが1つあるだけで同じURLを何度も読み込むと、見分けにくい重複項目が増えることがあります。

サブスクリプションの更新で、管理対象のサーバー情報が再生成される場合があります。該当項目を手動で変更しても、次回の更新で変更が上書きされることがあります。長期的に残す必要がある変更は、管理方法を確認してコピーを保存してください。内容の問題とネットワークの問題を切り分けるには、ご自身が保有する完全なサーバー情報を手動で追加してテストできます。手動で追加した項目は正常なのに、同じ提供元のサブスクリプションを繰り返し解析できない場合は、サブスクリプションの形式や応答内容を重点的に確認します。システムのVPN許可を何度も変更する必要はありません。

読み込み方法を確認し直す場合は、サブスクリプションと単一サーバーの読み込み方法をご覧ください。内容の種類がわからない場合は、共有リンク形式の解説を参照してください。復旧後は更新が成功したときの状態を一度記録し、適切な更新間隔を設定します。頻繁な再試行で継続的なリクエストエラーを隠さないでください。また、更新ボタンはサーバーへの接続テストではありません。

05 · 応答待ちと継続的な通信

接続できるが、読み込みが遅い、または通信が不安定

「遅い」と感じる状況は、最初の応答までの待ち時間、Webページの読み込み、継続的な通信の3段階に分けて考えます。操作後に長時間応答がない場合は、名前解決、接続の確立、ハンドシェイクが関係していることがあります。ページの文字は表示されるのに画像がなかなか読み込まれない場合は、接続先ごとに経路が異なる可能性があります。最初は正常でも、通信を続けるうちに遅くなる場合は、混雑、パケットロス、サーバー負荷も考慮してください。特定の遅延値だけを見るより、どの段階で遅くなるかを特定するほうが診断に役立ちます。

条件をそろえて比較する

安定して再現できる接続先を1つ選び、近い時間帯、同じネットワーク、同じデバイス、同じサーバーで2～3回テストすれば十分です。テスト中は、システムによる大容量ファイルの同期、ほかのデバイスでの大量通信、関係のないバックグラウンド処理を一時停止してください。Webページの内容も変わるため、同じページで同じ操作を行うようにします。高負荷のテストを複数同時に実行しないでください。同じ接続を取り合うため、普段の通信速度ではなく、テスト同士が干渉した結果を測ることになります。

次にWi-Fiとモバイル通信、またはご自身が利用できる別のサーバーを比較します。毎回変更する条件は1つだけにしてください。すべてのサーバーが同じWi-Fiでだけ遅い場合は、ルーター、電波強度、ネットワークの負荷を確認します。特定のサーバーだけが遅い場合は、その接続先と接続先までの経路を優先して確認してください。特定のWebサイトだけが遅い場合は、サービスの応答やリソース配信も考慮します。そのサイトだけを根拠に、クライアント全体の性能の問題と判断しないでください。

遅延、帯域幅、実際の使い心地は別の指標

遅延が小さいと操作や短いリクエストには有利ですが、継続的なダウンロードが必ず速くなるわけではありません。遅延が大きくても、帯域幅が不足しているとは限りません。アプリ内テストの結果は、テスト先、リクエストの種類、タイムアウトの設定にも左右されます。使えるかどうかは、ログインを完了できるか、動画が途切れず再生できるか、ファイル転送が中断されないかなど、実際の用途で判断してください。1回のテスト結果だけでサーバーを何度も切り替えないでください。切り替えにより一部のセッションが終了し、新たなハンドシェイクが必要になります。

Global Routingも結果に影響します。Configでは一部のリソースだけがプロキシ経由になる場合がありますが、Proxyではより多くのリクエストが選択した経路を通ります。使用したモードを記録せずに行った2回のテストは、厳密な比較になりません。接続記録で、ログイン用API、メディアの分割データ、DNSリクエストなど、繰り返し失敗するリソースがないか確認します。リクエストが何度も再試行されるとページ全体が遅く見えますが、必要な対応は特定のルールやアクセスできないドメインの修正だけかもしれません。

経路の状態に応じて対応し、根拠なく設定を変えない

Wi-Fiの電波が弱い場合や、デバイスが複数のアクセスポイントを頻繁に切り替える場合は、通信速度の低下や接続の再確立が起きることがあります。まずアクセスポイントの近くでテストし、デバイスが複数のネットワーク間を自動で切り替えていないか確認します。ネットワークへのログインが必要な場合、セッションの期限切れでバックグラウンド接続が繰り返し失敗することもあります。UDPを使うプロトコルでは、現在のネットワークに制限やパケットロスがないか個別に比較してください。ほかのプロトコルが使えることは、別の通信経路が利用できることを示すだけで、すべての通信条件が同じとは限りません。

根拠がないままMTU、同時接続数、プロトコルの詳細設定を変更しないでください。MTUの不一致が通信に影響する場合はありますが、同様の症状は接続先のサービス、無線ネットワーク、接続先の混雑でも起こります。問題を安定して再現でき、明確な設定要件があり、元の値を保存している場合に限り、項目を1つずつ変更して比較してください。変更しても安定した改善がない場合は元の値に戻します。複数の設定が残って互いの影響を覆い隠すと、次回の診断が難しくなります。

最後にデバイスの温度、バッテリーの状態、ローカルストレージの負荷を確認します。長時間の通信、画面収録、ほかの処理を同時に行うと、デバイス全体の性能変化が使い心地に影響することがあります。関係のない作業を停止してデバイスが通常の状態に戻ってから、同じ操作を再テストします。最初のアクセスだけ遅く、その後は正常な場合はDNSキャッシュや接続の再利用を確認します。継続的な通信だけが不安定な場合は、ネットワークの変動、接続先の状態、セッション切断の記録を重点的に確認してください。

06 · 名前解決と接続経路

DNSの名前解決に失敗する、または一部のドメインだけ開けない

DNSはドメイン名を接続に必要なアドレスへ変換します。「どのサーバーに接続するか」「どの振り分けポリシーを使うか」と関連しますが、別の段階です。ドメイン名を解決できないと、リクエストが接続先への接続段階に進まないことがあります。アドレスを取得できても、経路、ポート、接続先の応答に問題があれば失敗します。接続記録のエラーが名前解決、接続確立、TLSのどの段階に当たるか確認し、Webページを開けない問題をすべてDNSのせいにしないでください。逆に、名前解決の結果があるだけでDNS関連の違いを除外することもできません。

サーバーのドメイン名と接続先のドメイン名を分けて確認する

少なくとも、プロキシサーバーのドメイン名、サブスクリプションURLのドメイン名、アクセス先Webサイトのドメイン名の3種類を区別してください。プロキシサーバーのドメイン名を解決できないと、接続を確立できない場合があります。サブスクリプションのドメイン名で問題が起きると更新に影響しますが、既存のサーバー情報は使えることがあります。接続先のドメイン名で問題が起きると、一部のサービスだけが利用できないように見える場合があります。これらのリクエストは異なる設定や経路を使うことがあるため、サブスクリプションを更新できたからといって、すべての名前解決が正常とは限りません。

システムDNSは、現在のネットワークから提供される設定またはデバイスに指定された設定を使います。カスタムDNSは設定内の名前解決先を使い、DNS over HTTPSはHTTPS経由でクエリを送信します。暗号化されるのはクエリの通信経路です。接続先に到達できることや、現在のネットワークに適していることが自動的に保証されるわけではありません。DNS over HTTPSの接続先がドメイン名の場合は、最初の名前解決をどのように行うかも考慮してください。まだ確立されていない経路に名前解決を依存させないようにします。

既存の設定を読んでから、項目を1つずつ変更する

現在有効な設定を開き、dns-serverなど関連する項目があるか確認します。複数の場所に過去の変更が残っていないかも確認してください。以下の例は[General]とルール部分の構成を示すもので、systemはシステムの名前解決を使う設定です。すべてのネットワークに適用すべき設定という意味ではありません。既存のファイル末尾にそのまま追加し、同じセクションを重複させないでください。まず現在の設定を理解し、コピー上で該当項目を変更します。

[General]
dns-server = system

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

変更後に新しいテストリクエストを送り、キャッシュの影響を確認します。アプリによっては古い名前解決結果や既存の接続を保持するため、設定を変えても画面の状態がすぐに変わらないことがあります。関連するページを閉じて開き直し、必要に応じてShadowrocketを通常の方法で再接続してから記録を比較してください。名前解決先を次々に変えて結果を探らないでください。比較の基準を1つ残し、変更によって名前解決の参照先とリクエスト経路のどちらが変わったかを確認します。

アドレスの種類、ローカルネットワーク、ルールの整合性を確認する

同じドメイン名からIPv4とIPv6のアドレスが返されることがあります。現在のネットワークでどちらかのアドレスへの接続が不安定だと、接続できたりできなかったり、待ち時間の後に成功したりする場合があります。複数のアドレスが返されたこと自体を異常とみなさず、失敗記録にある実際の接続先アドレスを確認してください。不明な問題を隠すために、特定のアドレスファミリーを恒久的に無効にしないでください。一時的に比較する必要がある場合は、元の設定を記録し、テスト後に戻します。使用するサーバーとネットワークが該当する経路をサポートしているかも確認してください。

ローカルネットワーク内の名前解決は、ルーターや特定のローカル探索機能に依存する場合があります。遠隔の名前解決先に切り替えると、家庭内デバイスの名前を解決できなくても、正しいローカルアドレスを直接指定すれば接続できることがあります。この場合はローカルネットワークの名前解決とDIRECTルールの組み合わせを確認し、ローカルデバイスまでプロキシ経由にしないでください。一方、名前解決で得たアドレスと実際の接続経路が一致しない場合も、アクセス結果に影響することがあります。適用されたルールと名前解決先をあわせて確認してください。

特定のドメインだけが失敗する場合は、まず異なるネットワークでの動作を比較し、接続先のドメイン名、証明書、サービスの入口が変更されていないか確認します。一度の名前解決結果だけでサービスの状態を判断しないでください。多くのドメインで失敗し、サーバーには接続できる場合は、名前解決先への到達性と設定の依存関係を重点的に確認します。各項目の詳しい説明はShadowrocketのDNS設定ガイドをご覧ください。修復後は通常のWebページ、元の接続先、必要なローカルネットワーク上のリソースを再確認し、いずれか1種類だけが直った状態になっていないか確かめます。

07 · バックグラウンド処理と接続の繰り返し

バッテリー消費が増えた、デバイスが熱くなる、またはバックグラウンド動作が多い

まず「バッテリー画面で通信処理がShadowrocketの使用量として表示される場合」と「デバイスで実際に消費電力が増えている場合」を区別します。ネットワーク拡張は通過する通信を継続的に処理するため、システムの使用量表示に関連する動作が含まれることがあります。バッテリー消費の変化がすべてアプリの設定に起因するわけではありません。総バッテリー残量の減少、実行中のタスク、画面の使用時間、ネットワーク環境をあわせて比較してください。アプリ一覧の割合だけを見て判断しないでください。

条件をそろえた利用時のバッテリー消費を記録する

普段と同じ使い方を再現できる時間帯を選び、ネットワーク、画面の状態、主なタスクを記録します。連続した動画再生、ファイル同期、待機では通信量が大きく異なるため、直接比較できません。デバイスの温度、充電状態、電波強度も消費電力に影響します。モバイル通信の電波が弱い場合は、通信自体の消費電力が増えることがあります。まず電波が安定し、デバイスの温度が通常の環境で確認してから、異常がShadowrocketの接続と同時に起きるか判断してください。

確認のために、最初からすべての機能をオフにしないでください。写真の同期、ファイル転送、ほかのアプリからのバックグラウンドリクエストなど、大量の通信が続いていないか確認します。画面上で操作していない間も、これらの通信が現在の接続を通過することがあります。テストに関係のないタスクを一時停止し、通信量が明らかに減るか確認してください。減る場合は、通信の発生元とタスクの実行タイミングを調べます。通常のデータ転送を、接続していない間も大量に電力を消費している状態と誤解しないでください。

失敗の再試行と自動接続の繰り返しを確認する

ほとんど使っていないのにデバイスが熱くなり続ける場合は、接続記録で名前解決、ハンドシェイク、短時間の連続失敗が繰り返されていないか確認してください。使えなくなったサーバー、到達できないサブスクリプションURL、アプリが繰り返しリクエストするAPIが余分な動作を引き起こすことがあります。まず、最も頻繁に失敗する接続先を特定して対応してください。エラー記録を恒久的に非表示にして対処しないでください。記録が減ってもバックグラウンドでの再試行が止まったとは限らず、確認の手がかりを失うだけです。

On Demandでは、接続条件が日常のネットワークの変化と競合していないか重点的に確認します。デバイスがWi-Fiとモバイル通信の間を切り替える場合や、ネットワークへのログイン状態が変化した場合に、接続が繰り返し開始されることがあります。現在の条件を記録し、自動接続を一時的にオフにして、同じようなタスクを手動接続でしばらく確認します。繰り返しが止まった場合は、条件を1つずつ戻してください。「自動接続が頻繁に起きる」だけで機能の不具合と判断しないでください。条件が広すぎるか、互いに切り替わる条件が設定どおりに動作している場合もあります。

診断に必要な情報を残しながら、不要な処理を減らす

サブスクリプションの更新間隔や一括テストの頻度が高すぎないか確認します。自動更新やテストは実際にネットワークを使用します。画面を切り替えるたびに既存の内容を取得し直す必要はありません。用途に合わせて更新頻度を設定し、トラブルシューティング中は一覧全体の連続テストを避けてください。特定のサーバーだけを確認する場合は、個別にテストします。診断が終わったら、一時的に有効にした詳細ログを通常必要なレベルに戻し、不要な診断ファイルを削除してください。機密情報を含む記録を長期間残さないようにします。

接続維持、タイムアウト、プロトコル関連の設定は、使用中のサーバーの要件に従ってください。バッテリー消費を抑えるために、根拠なく極端な値にしないでください。タイムアウトが短すぎると接続が何度も再確立されることがあり、接続維持の通信間隔が短すぎてもバックグラウンド通信が増える可能性があります。ただし、設定の影響はプロトコル、接続先、ネットワーク環境によって異なるため、決まった数値をそのまま当てはめないでください。変更前の値を保存し、数分間のバッテリー残量だけでなく実際のタスクと待機時の状態を比較します。

バッテリー消費の変化がシステムアップデート、デバイスの移行、大量のファイル同期と同時に起きた場合は、バックグラウンド処理が終わってから比較します。デバイスの再起動で一時的な状態を解消できることはありますが、継続的な確認の代わりにはなりません。デバイスが明らかに過熱している場合は、高負荷の作業を停止し、温度が戻ってからテストしてください。長時間の速度テスト自体が新たな発熱の原因にならないようにします。タスク、ネットワークをそろえ、テストの繰り返しを止めても異常が続く場合は、接続頻度とエラーの種類を記録し、設定とシステムの状態をさらに確認してください。

08 · 設定の差分と元に戻せる操作

アプリまたはシステムのアップデート後に問題が発生する

問題がアップデートの後に起きたからといって、アップデートが原因とは限りません。同じ時期にサブスクリプションの内容が変わった、ネットワークを切り替えた、サーバーのメンテナンスがあった、設定が自動更新された可能性もあります。「最後に正常に使えた時」と「最初に問題が起きた時」の間に行った操作を記録し、アプリのアップデート、システムのアップデート、設定の更新を区別してください。すぐに再インストールするより、以前の設定と現在の設定を残して差分を確認するほうが有用です。復旧中に、唯一使用できる記録を失うことも防げます。

まず入手元と互換性を確認する

Shadowrocketはクローズドソースの商用アプリで、App Storeからのみ入手・更新できます。購入情報と正規品の確認方法はダウンロードページの確認項目をご覧ください。開発者のShadow Launch Technology Limited、公式アイコン、アプリID 932747118を確認します。システム要件はApp Storeページの記載をご確認ください。古い記事のシステム要件を根拠に現在のデバイスとの互換性を判断しないでください。アプリの購入履歴と、ローカルに設定が保存されているかどうかも別に確認してください。

アプリを開ける場合は、Homeで選択中のサーバー、Global Routingのモード、Configで有効になっている設定が以前と同じか確認します。アップデート後にメッセージが表示された場合は、具体的な内容を読んでから操作してください。サブスクリプションの更新で、以前選択していた項目が置き換わっただけの場合もあります。設定が残っていることを確認し、通常の方法で一度切断して再接続してから、以前と同じ対象でテストしてください。現在の状態を確認する前にバックアップを次々に読み込み、ファイル名やポリシー名をさらに混乱させないでください。

システム、アプリ、設定の3段階で比較する

まず接続をオフにして基本ネットワークを確認し、次にシステム接続を維持できるか、最後にプロキシ経由で実際にアクセスできるかをテストします。これにより、システムの許可に関する問題とルールの問題を切り分けられます。スイッチがすぐオフに戻る場合は第1章に戻ってください。接続を維持できるのにConfigだけ失敗する場合は、設定を優先して比較します。特定のサーバーが関連するすべてのモードのテストで失敗する場合は、同じ時期に設定が変更されたり、サービスが停止したりしていないか確認します。

設定を比較するときは、最近変更したDNS、ルールの順序、ポリシー名、リモート参照を重点的に確認します。ファイル全体を最初から書き直す必要はありません。以前のコピーは比較に使えますが、内容を確認せずにすべてを上書きしないでください。ファイル名が同じでも、リモート設定の内容が更新されている場合があります。読める形式でローカルコピーを保存してください。特定の項目を戻して問題が解消した場合は、結果を再現できることも確認します。ネットワークが偶然復旧しただけなのに、項目の変更が効いたと誤認しないようにしてください。

再作成や再インストールの前に、バックアップの範囲を確認する

アプリの購入情報の復元、サーバー情報の復元、設定の復元はそれぞれ別の作業です。App Storeから購入済みアプリを再取得できても、ローカルの項目、認証情報、手動変更した設定がすべて自動で戻るわけではありません。再インストールする前に、既存のサブスクリプションURLが使えること、手動で設定したサーバー情報を安全にバックアップできていること、設定のコピーを開けること、同期に依存するデータを把握していることを確認してください。完全な設定が残っている唯一のデバイスから、確認なしにデータを削除しないでください。

iCloudやファイル書き出しでバックアップする場合は、同期スイッチがオンになっているかだけでなく、移行先デバイスまたはバックアップファイルで実際に確認してください。認証情報とサブスクリプションURLは機密情報です。書き出したファイルは管理された場所に保存します。移行手順は設定のバックアップと機種変更後の復元をご覧ください。システムのVPN構成を作り直す場合は、まず第1章の手順に従います。通常はアプリのデータをすべて消去する必要はありません。

復旧後は、アプリを開けること、システムの許可が完了していること、設定が選択されていること、既存のサーバーを使えることを順番に確認します。その後、サブスクリプションの更新と普段使う接続先をテストしてください。各段階を確認してから次の自動処理を戻し、複数のバックグラウンド処理が同時に動かないようにします。問題が再現する場合は、システム環境、アプリ内で確認できる関連設定、最小限の再現手順、機密情報を削除したエラーを記録してください。問題を証明するために設定全体を公開しないでください。「アップデート後に壊れた」だけでなく、操作と結果を記録します。

09 · デバイスごとの設定、共有設定、ローカルネットワーク

iPhoneでは正常なのに、iPadで問題が起きる

iPhoneで正常だった結果をそのまま当てはめず、iPadを独立したデバイスとして確認します。2台のデバイスで別のWi-Fiに接続している、異なる名前解決先を使っている、別の設定やサーバーを選んでいる場合があります。サブスクリプション名が同じでも、最終更新日時や内容が異なることがあります。まず2台を同じネットワークに接続し、画面で確認できる設定を1項目ずつ比較して、デバイス環境と設定のどちらに違いがあるか確認してください。

購入情報、許可、デバイスのネットワーク環境を確認する

iPadでの入手方法はiPadでの購入と初回起動をご覧ください。購入済みアプリの再取得と利用可能な範囲はApp Storeページの記載をご確認ください。システム要件もApp Storeページの記載をご確認ください。アプリがインストール済みでも、システムのVPN許可が完了しているとは限りません。iPhoneで行った許可は、iPad本体の許可の代わりにはなりません。まずiPadのシステムVPN画面を確認し、スイッチをオンの状態に保てるかテストします。

管理対象のiPadでは、デバイスのポリシーで該当する接続が許可されているかも確認してください。モバイル通信対応モデルとWi-Fiのみのデバイスでは、利用できるテスト経路が異なります。別のネットワークで比較できないからといって、特定の設定が正しいと判断しないでください。利用が許可されている別の場所のWi-Fiで比較し、公共ネットワークではデバイスごとにログインが必要かも確認します。iPhoneでログインが完了していても、iPadのネットワークセッションも完了しているとは限りません。

設定全体を上書きせず、項目ごとに比較する

まずGlobal Routing、現在のConfig、選択中のサーバーを比較し、次にプロトコルの項目、DNS、ルールを比較します。サブスクリプション名が同じでもサーバー一覧が異なる場合は、片方のデバイスで更新が完了していない可能性があります。項目名が同じでも認証情報が異なる場合は、手動で変更されている可能性があります。比較のためにチャットアプリで認証情報全体を送らず、各デバイスでサービス事業者から提供された情報と照合してください。差が見つかったら該当する項目だけを修正します。異なるネットワーク環境で、iPhoneのローカルネットワーク専用ルールをそのままiPadにコピーしないでください。

横向き表示、画面分割、ウィンドウサイズの変化によってナビゲーションの表示方法が変わることはありますが、Config、Home、Settingsの機能が別の設定に変わるわけではありません。見慣れた位置にボタンがない場合は、検索を終了し、編集状態を解除して、現在のタブを確認します。同じ内容を何度も読み込まないでください。リストが長い場合は、フィルター条件とグループの展開状態も確認します。画面上の位置の変化とサーバーとの通信失敗は分けて確認してください。入口が見つからないだけで、設定が消えたと判断しないでください。

スリープ復帰後、ネットワーク切り替え後、ローカルネットワークへの接続を確認する

スリープから復帰した後だけ問題が起きる場合は、スリープ前後でネットワークが変わったか、On Demandによる再接続が発生したかを記録します。以前から開いたままのページには切断されたセッションが残っている場合があるため、新しいWebリクエストを開いて確認してください。再接続後に復旧した場合は、ネットワークの変化と自動接続の条件を引き続き確認します。画面を常時オンにして問題を隠さないでください。待機中の動作はバッテリーの章も参照し、画面上のスイッチの状態だけでなく接続の繰り返しを確認します。

iPadは家庭内ストレージ、画面共有デバイス、ほかのローカルネットワークサービスへのアクセスにもよく使われます。接続後にこれらの機能で問題が起きる場合は、実際に使用しているアドレスとローカルネットワークへのアクセス許可を確認し、該当するネットワーク範囲がDIRECTで処理されているか確認します。デバイスの検出にはブロードキャストやローカル探索機能が必要な場合があり、単一のドメインルールでは全体を処理できないことがあります。既知のローカルネットワークのアドレスへ直接アクセスできるか確認してから、名前の検出、アプリの許可、ネットワーク転送を切り分けます。関連する問題をすべてDNSのせいにしないでください。

設定の同期も個別に確認する必要があります。ファイルが別のデバイスに表示されても、現在有効なConfigになったとは限りません。サーバー情報があっても、選択されているとは限りません。移行後はiPadで短い手順で一通り確認します。設定を選択し、登録済みのサーバーを選び、モードを確認し、接続をオンにして、以前のテスト対象にアクセスします。すべて確認できてから自動更新とOn Demandを戻してください。問題が再発した場合に、どの段階で新しい条件が加わったか特定しやすくなります。

最後に同じ接続先を使って2台のデバイスを比較し、異なる設定を記録します。同じネットワーク、同じ設定でiPhoneは正常なのにiPadで失敗する場合は、iPad本体のシステム許可、名前解決の結果、エラーが起きる段階を引き続き確認してください。2台とも失敗する場合は、共通するネットワーク、サーバー、サブスクリプションを重点的に確認します。普段の操作を確認したい場合は使い方ガイドへ、設定項目の意味がわからない場合は用語集へ戻ってください。1つの問題を解決するために、設定全体を作り直す必要はありません。