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

接続スイッチをオンにできない：システムの許可を確認

Homeの接続スイッチがオンの状態を保てない、すぐオフに戻る、または初回接続時にシステムの許可画面で止まる場合に確認してください。まず「VPNトンネルを確立できない」状態と「トンネル確立後に通信できない」状態を区別します。前者はシステム権限と設定の読み込みを、後者はルーティングとサーバーを優先して確認します。画面上部にVPNの表示があるだけでは、すべてのリクエストが正常に処理されているとは限りません。

システムの確認画面と操作内容を確認

初めて接続するとき、VPN構成の追加を許可し、デバイスのパスコードまたは生体認証で確認するよう求められることがあります。これはネットワーク設定をシステムに保存するための許可であり、サブスクリプションの認証ではありません。画面の内容を確認してから許可してください。以前にキャンセルした場合は、Shadowrocketに戻って接続を再度開始し、表示を確認します。確認画面を処理する前にスイッチを何度もタップすると、どの操作が反映されたのか分かりにくくなります。

確認画面が表示されず、スイッチがすぐオフに戻る場合は、システムのSettingsを開き、VPNとデバイス管理に関する項目でShadowrocketの記録があるか確認します。システム項目の名称や配置は、言語やレイアウトによって異なる場合があります。実際の画面表示を確認し、既存の項目を記録してから操作してください。まとめて削除するのは避けましょう。管理対象デバイスのネットワーク制限は、設定を繰り返し作り直して回避しようとせず、管理者に確認してください。

設定の読み込みと接続の競合を確認

Homeに戻り、SERVERに選択可能なサーバーがあり、現在選択している項目が削除済みのサブスクリプションではないことを確認します。インポートが成功しても、情報が保存されたことを示すだけで、パラメーターがすべて正しいとは限りません。サブスクリプションの差し替え、グループの削除、Configの再インポート後は、選択中の項目が現在も有効か確認してください。編集直後に問題が起きた場合は、編集前のバックアップに戻してテストします。

ほかに有効なVPN構成がないか、システム管理ポリシーが接続を再確立していないかも確認します。ネットワークを制御する複数の構成が競合すると、スイッチがすぐ戻ったり、接続状態が変化し続けたりすることがあります。自分で管理できる構成については、ほかの接続を停止してからShadowrocketだけでテストしてください。原因を増やさないため、システムのネットワーク関連設定を一括でオフにするのは避けます。

On Demandも確認対象です。ネットワーク条件に応じて接続が自動で開始され、「手動でオフにしたのに再びオンになった」ように見えることがあります。トラブルシューティング中は、現在の条件を記録して自動接続を一時停止し、手動スイッチで再現するか確認します。手動接続は安定し、自動接続を戻したときだけ問題が起きるなら、サーバーのパスワードやプロトコルではなく、条件の一致を重点的に確認してください。

変更を最小限にして復旧を確認

現在のネットワークで通常のWebページにアクセスできることを確認し、接続を完全にオフにしてシステムのホーム画面に戻ってから、アプリを開き直してテストします。改善しない場合は、デバイスを再起動して一時的なシステムネットワーク状態を切り分けます。テストのたびに画面の状態変化が完了するまで待ちましょう。スイッチを連続して素早く切り替えても接続処理は早くならず、ログに手動中断だけが残って原因を見落とすおそれがあります。

最近Configを編集した場合は、まずコピーを保存し、以前に動作を確認した設定に切り替えます。設定の解析エラーとリモート接続エラーは別の段階で発生します。前者はトンネル確立前に止まることがあり、後者は通常、トンネルの起動後に発生します。アプリに表示される具体的なエラーを確認し、該当する内容から対処してください。「接続できない」という説明だけでルールとDNSを同時に書き換えないようにします。

バックアップを完了し、管理ポリシーによる制限ではないと確認した場合に限り、Shadowrocketの古いVPN構成を削除して、アプリからシステムの許可を再度求める方法を検討します。この操作で対処できるのはシステムの構成記録であり、期限切れのサブスクリプションや誤ったサーバー設定は修復されません。サブスクリプションURL、証明書、手動で追加した項目が別途バックアップされているか、操作前に一つずつ確認してください。再許可をデータ全体の復元と混同しないようにします。

この章の完了条件は、スイッチがオンの状態を保ち、システムから許可を繰り返し求められず、手動で接続をオフにできることです。ここまで正常でWebページが開かない場合は、次の章に進んでください。システムが構成の保存を拒否し続ける場合は、表示されたメッセージ全文、デバイスが管理対象かどうか、再起動後の結果を記録し、よくある質問の権限に関する説明も確認します。

接続中なのに通信できない：ルーティングと接続先の問題を切り分ける

接続スイッチがオンでも分かるのは、ローカルのトンネルが動作中ということだけです。各リクエストはルール判定、名前解決、リモート接続を経由します。まずShadowrocketをオフにし、現在のネットワークで普段使えるWebサイトを2つ開いてみてください。オフの状態でも失敗する場合は、Configを変更する前にWi-Fiの認証、モバイルデータの許可、基本ネットワークを確認します。基本状態を比較した後、接続をオンにして同じサイトを再確認してください。

Global Routingで条件を比較する

元のGlobal Routingを記録したうえで、必要に応じてConfig、Proxy、Directを短時間だけ比較に使います。これらの項目はそれぞれ設定、プロキシ、直接接続に相当しますが、実際の画面では英語表記を使用します。リクエストの経路を切り替えるためのもので、あらゆるネットワーク問題を解決する汎用スイッチではありません。テスト後は必要な元の設定に戻し、一時的な検証設定をそのまま使い続けないようにします。

ProxyではアクセスできるのにConfigで失敗する場合は、失敗したリクエストに一致したルール、ポリシーの参照先、設定が実際に有効かを確認します。DirectではアクセスできるのにProxyで失敗する場合は、現在のサーバーとリモートまでの経路を確認します。トンネルをオフにした場合だけ復旧するときも、すぐにサーバーの障害と判断せず、トンネル内のDNS、システム権限、ほかのネットワーク設定との競合を確認してください。

設定全体を置き換えず、ルールの順序を確認

ルールは通常、設定に記載された順に判定されます。広い条件を先に置くと、別のポリシーを適用するはずのリクエストが先に一致することがあります。確認時は、まず対象ドメインに対応するルールを探し、その後にフォールバックのポリシーを確認してください。以下は判定順を理解するための例であり、すべての環境に使える完全な設定ではありません。使用前に、既存設定のポリシー名と実行環境が一致することを確認してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

例では、1行目が指定ドメインとそのサブドメインを処理し、2行目が地理的なIPアドレスを判定し、最後の行がそれまでに一致しなかったリクエストを処理します。範囲の広いルールを先に置くと、より具体的な条件が判定されないことがあります。変更するときは現在のConfigを複製し、コピー上で関連するルールを1つだけ調整して、同じリクエストで確認します。設定全体を一度に置き換えると、元に戻すのが難しくなります。

Webサイトのトップページは開くのに画像やログインが失敗する場合は、それぞれのリクエストを別の接続先として扱います。ページからメインドメイン、静的リソース用ドメイン、認証用ドメインへ同時にアクセスすることがあります。トップページのドメインだけにルールを設定しても、関連リソースが同じ経路を通るとは限りません。関連リクエストのドメインと適用されたポリシーを確認し、必要な条件だけ追加してください。1つのリソースを直すために、すべての通信を別の経路に変更するのは避けます。

ルール判定とサービスの応答を分けて考える

アプリに接続記録がある場合は、問題を一度再現してから、宛先ドメイン、適用されたルール、選択されたポリシー、エラーの種類を確認します。記録がバックグラウンド更新ではなく、直前の操作に対応していることを確かめてください。HTTPステータス、認証失敗、Webサイト側のアクセス拒否は、接続そのものができない状態とは異なります。リモート側から応答を受信できている場合は、単純なタイムアウトよりアプリケーション層に近い段階まで進んでいるため、応答内容に沿って調べます。

ルールがREJECTの場合、リクエストが明示的に拒否されるのは設定どおりの動作かもしれません。Webページの一部が表示されないときは、対象リソースが該当ルールに一致していないか確認してから、サーバーの障害かどうか判断します。許可が必要なら、該当条件だけを変更し、理由を記録してください。また、名前解決に失敗すると後続のアドレスベースの判定にも影響することがあります。そのような症状がある場合は、DNSの章も確認します。

この章の完了条件は、「どの宛先が、どのモードで、どのポリシーを通って失敗したか」を説明できることです。漠然とした接続状態のスクリーンショットより、結論を記録しておく方が役立ちます。Proxyですべての宛先がタイムアウトする場合は、サーバーのタイムアウトの章へ進みます。Configだけで問題が起きる場合はルールを詳しく確認し、すべての経路で名前解決に失敗する場合はDNSを優先して確認します。正常と確認済みのサーバー情報を何度も変更しないでください。

サーバーがタイムアウトする：サーバーとプロトコル設定を順に確認

Connectivity Testのタイムアウトは、所定の条件で期待した結果が得られなかったことを示し、すべての通信が必ず失敗するという意味ではありません。テスト方法によって対象やプロトコルが異なる場合があるため、実際のWebアクセスもあわせて確認してください。まず、1つの項目だけがタイムアウトするのか、同じサブスクリプション内の複数項目なのか、保存済みのすべての項目なのかを記録します。範囲によって確認箇所は異なり、1つの数値だけで利用可否を比較することはできません。

ネットワークの範囲から確認箇所を絞る

まず現在のネットワークで、以前に動作を確認した宛先をテストし、利用可能な別のネットワークでも繰り返します。同じサーバーがモバイルデータでは動作し、特定のWi-Fiでは失敗する場合、そのネットワークの認証状態、アクセス制限、出口の条件を確認します。すべてのネットワークで失敗する場合は、サーバーが稼働中か、ポートが正しいか、アカウントが有効か、サーバー側の設定に変更がないかを確認してください。

大量のテストを連続して実行しても原因特定にはなりません。まず1つの項目を選び、テスト完了後に実際のアクセスを確認します。並列リクエストが結果に影響したり、リモート側の制限にかかったりするのを避けるためです。時刻とネットワークの種類を記録すると、継続的な障害と一時的な変動を区別しやすくなります。特定の時間帯だけ失敗するなら、その時間帯に繰り返し確認した結果を残し、1回成功しただけで完全復旧と判断しないでください。

サーバー側の元情報と項目ごとに照合

サーバーアドレスとポートが、自分のサーバー情報と一致していることを確認します。アドレスの前後に空白がある、コピー時に改行が混入した、ポートが誤っているといった点が接続失敗につながります。ポートを手当たり次第に試すのではなく、サーバーが実際に待ち受けているポートを指定してください。ドメインを使う場合は名前解決も確認します。アドレスを使って一時的に比較する場合も、必要なTLSホスト名の意味は維持してください。

転送層の設定がある項目は、サーバー側の情報と照らし合わせて転送方式、パス、関連するホスト名の項目も確認してください。アドレスはサーバーを特定するために使い、TLSホスト名は接続先の本人性を検証します。転送方式によっては、ホスト名の項目がリクエストのルーティングに使われます。これらは必ずしも同じ概念ではありません。サーバー側で一致が明示されている場合にだけ同じ値を入力し、複数のドメイン欄があるからといって機械的に同じ値をコピーしないでください。

証明書エラーには通常、「タイムアウト」より具体的なメッセージが表示されます。デバイスの日時、証明書の有効期限、名前の一致を確認してください。証明書検証を無効にするのは一般的な解決策ではありません。セキュリティ上の条件を変えるだけで、サーバーの証明書設定自体は修正されません。自分でサーバーを管理している場合は、該当する証明書とサーバー設定を修正します。既存のサービス情報を使っている場合は、推測で組み合わせを変えず、有効なパラメーターと照合してください。

通信方式の制限とサーバー側の問題を見分ける

一部のプロトコルや機能はUDPに依存します。通常のWebページにアクセスできても、関連する通信が必ず到達するとは限りません。特定のネットワークでのみ通信方式が失敗する場合は、ネットワークの違いとサーバーの要件をあわせて確認します。根拠なくMTU、Keep Alive、タイムアウトを変更しないでください。断片化、経路、アイドル状態の接続に関する証拠がなければ、1つの障害に設定変数を重ねることになります。

自分で管理するサーバーの場合は、サービスの稼働状況、待ち受けポート、ファイアウォール、同じ時間帯のサーバー記録を確認します。クライアントに接続切断と表示されても、リモート側が切断したのか、途中のネットワークが途切れたのかは、表示だけでは判断できません。クライアントとサーバーの時刻を照合し、リクエストが到達したか、どの段階で止まったかを確認してください。認証情報全体をトラブル記録にコピーする必要はありません。

サブスクリプション更新後に古い項目が消えたり、アドレスが変わったりした場合は、現在有効な情報を使って項目を選び直してください。すでに管理されていないローカル項目をテストし続けないようにします。サブスクリプション上の表示名は識別用であり、同じ名前でも基になるパラメーターが同一とは限りません。復旧したら、失敗したネットワーク、エラーの段階、修正した項目、実際のアクセス結果を記録します。サブスクリプションを更新できない場合は、次の章で取得と解析の経路を確認してください。

Subscribeの更新失敗：取得・解析・項目変更を切り分ける

サブスクリプション更新には、URLへのリクエスト、応答の取得、内容の解析、項目の反映という複数の段階があります。どの段階でも失敗する可能性があります。まず現在有効な項目を残し、削除してから更新を試すのは避けてください。一時的なリクエスト失敗で、利用可能なローカル情報まで消えるおそれがあります。具体的なメッセージを記録し、接続タイムアウト、異常なステータス、未対応の形式、更新成功後の項目数の変化を区別します。

URLを保護し、内容を確認

サブスクリプションURLにはアクセス認証情報が含まれる場合があるため、機密情報として扱ってください。コピー時に末尾のパラメーターが欠けていないか、空白、句読点、メッセージアプリが付加した改行が混入していないか確認します。URL全体を公開の掲示板に貼ったり、内容を不明なサイトで変換したりしないでください。構造を他者に説明する必要がある場合は、ドメインの種類とパラメーター名だけを示し、アカウントを特定できる値は隠します。

ブラウザーでURLを開けても、インポート可能な内容が返されているとは限りません。ブラウザーにログイン状態が残っていたり、Webページ、認証画面、アクセスエラーが表示されたりすることがあります。アプリのメッセージと自分のサブスクリプションの説明から、応答の種類を確認してください。応答の内容を確認する場合も、想定した形式かどうかを見るだけにし、認証情報を含む可能性のある全文を公開しないでください。

通信エラーと内容のエラーを区別

リクエストがタイムアウトする、またはドメインを名前解決できない場合は、ネットワークとDNSを確認します。認証エラーが明示されている場合は、URLの有効性、アカウントの状態、認証情報の変更を確認してください。リクエスト頻度が高すぎるというメッセージが表示されたら、更新を繰り返さず、応答に従って時間をおいてから再試行します。削除して再追加を繰り返してもアクセス権は回復しません。リモート側に同じリクエストが増え、状況の把握が難しくなることがあります。

サブスクリプションの取得に現在のプロキシが必要で、そのプロキシ自体が無効になったサブスクリプションに由来する場合、更新に必要な経路が途切れることがあります。まず、そのURLに現在のネットワークから直接アクセスできるか、アプリの現在の設定が更新リクエストをどのように処理するかを確認してください。別の利用可能な経路がすでにある場合は、一度だけ比較に使います。ない場合は、基本的な接続を復旧してから確認してください。更新1回ですべてのネットワーク問題が自動的に直るわけではありません。

形式エラーの場合は、サーバーから返された内容がShadowrocketで現在サポートされているインポート形式か確認します。WebページのURL、設定ファイルのURL、サーバー共有情報は別のものです。コピーできるからといって同じ入力欄に貼り付けられるとは限りません。元の情報に応じてSubscribeまたは該当するインポート操作を選択してください。初めて使うため入口が分からない場合は、クイックスタートで基本手順を確認します。

「更新成功」と表示された後の項目を確認

更新成功後にリストが空になった場合は、返された内容に有効な項目が含まれているか、フィルターが適用されていないかを確認します。項目数の減少は、サーバー側で項目が正常に削除された結果の場合もあり、クライアントのデータ消失とは限りません。現在の結果を保存し、自分のサブスクリプションの説明と照合して、名前のフィルター、グループの違い、一時的な応答異常がないか確認します。原因を調べる前に、唯一のローカルバックアップを何度も上書きしないでください。

サブスクリプションから作成した項目を手動編集しても、次回更新時にサーバーの情報で上書きされることがあります。試験用のパラメーターは、手動項目として別に保存し、元のサブスクリプションと区別してください。名前を分けておくと、変更が反映されていないと思い込み、別の項目をテストしていたという事態を防げます。確認後は一時的なコピーを整理し、後から古いテスト情報を選ばないようにします。

項目のインポートとConfigの有効化も別々に確認します。Subscribeはサーバー情報を更新するもので、すべてのルール、DNS、ポリシーが現在のネットワークに適合することを保証するものではありません。新しい項目がHomeに表示されても、有効なサーバーを選び、Global Routingを確認し、実際にアクセスできるかテストしてください。リストの更新に成功しても接続できない場合は、同じURLを繰り返しインポートせず、サーバーのタイムアウトの章へ進みます。

元に戻せる更新手順を習慣にする

大きな変更を行う前に、保管が必要な手動情報とConfigをバックアップし、何が含まれているか確認します。エクスポート方法によって保存されるデータの範囲は異なるため、「ファイルが1つある」ことと、すべての情報が保存済みであることは同じではありません。機密情報を含むバックアップは、自分で管理できる安全な場所に保管してください。問題を共有する際は、エラーの種類、発生時刻、認証情報を除いた必要最小限の構造だけを示します。

この章の完了条件は、リストが一度表示されることではありません。繰り返し更新でき、項目の内容が想定どおりで、選択した項目を実際に利用できることです。URL自体が無効になった場合は、自分が利用しているサービスの管理方法に従って情報を更新してください。アプリの購入とサブスクリプションの有効性は別の関係です。購入や購入済み項目の復元については購入済み項目の復元方法をご確認ください。サブスクリプションの問題を直すために、アプリを再購入しないでください。

通信速度が遅い：応答時間・転送速度・安定性を分けて確認

「遅い」には、初回表示まで時間がかかる、転送開始後の速度が低い、再生が何度も止まる、ネットワーク切り替え後に一時的に途切れるなど、複数の現象があります。まず症状を具体的に記録し、測定内容を決めてください。Connectivity Testの結果は特定のテスト条件だけを示し、大容量ファイルの転送速度やすべてのWebサイトの動作を直接表すものではありません。1回の低いテスト値でも、その後のパケットロスやリモート側の混雑は判断できません。

比較できるテスト条件をそろえる

普段アクセスできる宛先を1つ選び、同じデバイス、同じネットワーク、近い時間帯で比較します。まず接続をオフにした基本状態を確認し、次に現在の設定、最後に自分が保有する別の有効な項目を試します。一度に変える条件は1つだけにし、ほかのアプリのダウンロードや同期もなるべく同じ状態に保ちます。ネットワーク、サーバー、ルールを同時に変更すると、改善の原因を特定できず、安定して再現することも難しくなります。

遅さがどの段階で起きているかを確認します。アドレスを入力してから読み込みが始まるまで時間がかかる場合は、名前解決、接続の確立、ハンドシェイクが関係している可能性があります。転送が続いているのに速度が低い場合は、回線容量、パケットロス、サーバー負荷を確認します。ページ内の一部のリソースだけ表示が遅い場合は、関連ドメインに別のポリシーが適用されていることがあります。「開くのに時間がかかった」とだけ記録するより、段階を特定する方が原因を絞り込めます。

ローカルネットワークと接続先の違いを切り分ける

Wi-Fiの電波強度表示だけでは、ネットワーク品質を十分に判断できません。距離、干渉、アクセスポイントの負荷、ブロードバンドの出口が転送に影響することがあります。アクセスポイントに近づいてテストし、同じネットワーク上で大量のバックグラウンド通信がないことを確認してから、モバイルデータと比較してください。特定のWi-Fiだけ遅い場合は、そのネットワークを優先して調べます。モバイルデータでも同様なら、低データモードやアプリのネットワーク権限を確認してください。

同じプロキシ項目でも、アクセス先によって速度が大きく異なることがあります。リモートの出口からWebサイトまでの経路が異なるためです。接続先自体の負荷、リソース配信サーバー、アカウント側の制限も結果に影響します。対象を1つに限定せず、複数の接続先で範囲を確認してください。ただし、大量の同時速度テストは不要です。特定のWebサイトで一度遅かっただけでは、クライアント全体の性能異常とはいえず、すべての設定を変更する根拠にもなりません。

ルール、再試行、バックグラウンド負荷を確認

Config内で一部のリソースがREJECTされたり、利用できないポリシーに振り分けられたりすると、Webページが再試行を待ってから表示され、速度が遅いように見えることがあります。まず、失敗したリクエストが特定のドメインやポリシーに集中していないか確認し、ルールの順序を調べます。Proxyではページ全体が表示され、Configでは明らかに遅れる場合は、関連するルールだけを比較してください。トラブルシューティングのために、すべてのリクエストの経路を長期間変更する必要はありません。

サブスクリプションの頻繁な更新、大量の接続テスト、診断記録の大量生成がないかも確認してください。根本原因ではない場合もありますが、ネットワークや処理リソースを使い、テスト結果を妨げることがあります。トラブルシューティング中は不要な操作を止め、必要な項目だけを観察します。目的なく詳細な記録を取り続けないでください。再現条件が見つかったら必要な部分だけ保存し、その後は通常の設定に戻します。

通信パラメーターは、既存のサーバー要件に基づいて設定します。根拠なく同時接続数を増やしたり、タイムアウトを短縮したり、MTUを変更したりしても速度が改善するとは限らず、接続の再確立や再送が増えることがあります。特定の問題を示す証拠がある場合だけ、関連するパラメーターをテストしてください。たとえば、特定のネットワークで大きなパケットだけ失敗し、小さなリクエストは正常な場合です。テスト前に元の値を保存し、改善と判断する条件、元に戻す条件を明確にします。

実際の利用場面で改善を確認

自分が持つ別の有効な項目に切り替えて改善した場合は、同じ条件で元の項目がまだ遅いか再確認し、時間帯の変化をサーバーの違いと誤認しないようにします。同じネットワークでどの項目も遅く、別のネットワークでは正常なら、ローカルネットワークの出口を調べます。すべてのネットワークで特定の接続先だけ遅い場合は、接続先のサービスとアクセス経路を確認してください。偶然の成功だけでなく、各結論を少なくとも1回は再度比較します。

デバイスの温度とバックグラウンド処理も考慮します。システムアップデート直後、写真の同期中、大量のコンテンツを索引中などは、デバイスが複数の処理を行っており、ページ表示の遅さを通信速度の遅さと誤認することがあります。「コンテンツのダウンロード完了」と「ページの表示完了」を分けて確認してください。デバイスが明らかに熱い場合は、高負荷の処理を止めてからテストします。充電しながら高負荷で使い続け、わずかな差を比べるのは避けてください。

最後に、最初に問題が起きた作業で確認します。連続して閲覧できるか、再生が止まらないか、ネットワーク切り替え後に復旧するかを見て、テスト値の小ささだけを目標にしないでください。説明に役立つ記録を2～3件残せば十分です。ドメインの初回解析で主に待たされる場合は次の章へ進み、速度の問題に明らかなバッテリー消費が伴う場合は、バックグラウンドでの再接続や診断処理をバッテリー消費の章で確認します。

DNSの問題：名前解決の経路とキャッシュを確認

DNSはドメイン名を、後続の接続に必要なアドレスへ変換します。名前解決が成功してもサービスに接続できるとは限らず、名前解決の失敗がサーバーの認証エラーを意味するわけでもありません。特定のドメインだけ開かない、初回アクセスに時間がかかる、ネットワーク切り替え後に一時的な問題が起きる、同じドメインでも経路によって結果が異なるといった症状があります。対象のドメインと具体的なエラーを記録し、実際に名前解決の段階で問題が起きているか確認してください。

システムDNS・カスタムDNS・暗号化DNSを区別

システムDNSは通常、現在のネットワークから取得します。カスタムDNSにすると、名前解決リクエストを利用するサービスが変わります。DNS over HTTPSはHTTPS経由で名前解決リクエストを送信しますが、基盤ネットワークへの接続、正しい証明書検証、利用可能なサービスアドレスが必要です。設定しただけであらゆる接続問題が直るわけではありません。方式は見た目だけで信頼性を判断せず、現在のネットワーク条件に合わせて選んでください。

暗号化DNSサービスの接続先にドメイン名を使う場合は、そのドメインのアドレスを最初にどう取得するか、リクエストがどの経路を通るかも考慮します。既存のプロキシが完全に利用できず、そのプロキシ経由でしか到達できない名前解決サービスに依存している場合、DNSも失敗する可能性があります。まず依存関係を整理してから、到達可能な方法を比較に使います。DNS、サーバー、すべてのルールを同時に変更して、原因の経路を複雑にしないでください。

1つのドメインで再現性のある確認を行う

繰り返し失敗するドメインを1つ選び、同じネットワークで接続をオフにした場合とオンにした場合をそれぞれ確認します。オンにしたときだけ失敗する場合は、現在のConfigのDNS設定と名前解決リクエストの経路を確認します。どちらでも失敗する場合は、ネットワーク側の名前解決と接続先自体の状態を調べます。必ず同じドメインでテストしてください。トップページのドメインと画像リソースのドメインの結果を、同じ比較として扱わないようにします。

「特定のアドレスに直接アクセスできた」ことだけで、ドメインの問題だと断定しないでください。HTTPSサービスはTLSホスト名や仮想ホストのルーティングに依存することがあり、アドレスを直接入力するとリクエストの意味が変わり、単純に比較できません。名前解決の記録、エラーが起きた段階、実際の接続記録をあわせて判断する方が確実です。アドレスを指定してテストする場合も、サービスが要求するホスト名を維持し、検証を無効にしないでください。

ルールと名前解決の相互作用を理解

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDはドメインの条件に基づいて判定します。IP-CIDR、IP-CIDR6、GEOIPはアドレスの条件を扱います。先に名前解決が必要か、どのアドレスが返るか、その後どう判定されるかは、実際のルールと設定によって異なります。トラブルシューティングでは、すべてのリクエストがドメインルールに一度だけ一致すると考えず、失敗したリクエストが実際にどのように処理されたか確認してください。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

上記のアドレス範囲はドキュメント用の例であり、自分の実際のネットワークに設定するためのものではありません。no-resolveは、アドレスルールの判定を目的としたドメインの名前解決を積極的に行わないことを示します。DNSを全体的に停止する意味ではありません。この違いを理解しておくと、1回の名前解決を減らすために設定全体の動作を変えてしまうのを防げます。例で学んだ後は使用中の設定に戻り、関連ルールを確認してください。現在の設定をそのまま置き換えないでください。

IPv4とIPv6の両方にも注意します。ネットワークがIPv6アドレスを返しても、その経路が安定して利用できるとは限りません。ほかのアドレスに切り替わるまで、一部のリクエストが待たされることがあります。まず異なるネットワークの結果を比較し、アドレスファミリーと接続記録を確認してください。根拠なくIPv6関連の設定をすべてオフにしないでください。アドレス選択を変えるとほかのリクエストにも影響するため、元に戻せる手段を残します。

キャッシュと設定の上書きを確認

DNS設定を変更しても、既存の接続、アプリのキャッシュ、システムキャッシュのために、短時間は結果が想定と異なることがあります。現在の接続を停止し、新たに接続してから新しいリクエストをテストしてください。必要に応じて、接続先アプリの古いセッションを終了してからアクセスします。必要な場合に限ってデバイスを再起動し、再起動後に一度復旧しただけで最終的な解決と判断しないでください。変化が続くか記録し、キャッシュの影響か、もともと断続的な問題かを見極めます。

デバイスにほかのDNS構成プロファイルが設定されていないか、現在のConfigがアプリ内の別の設定項目を上書きしていないかも確認します。設定画面に値が入力されていても、今回のリクエストで実際に使われているとは限りません。有効な設定と記録を基準に、上書きの関係を一つずつ確認してください。管理対象デバイスでは、組織から配布されたネットワーク設定を勝手に削除せず、管理要件と自分の操作権限を確認します。

この章の完了条件は、対象ドメインが適切に名前解決され、その後の接続が続き、ネットワークを切り替えても正常な動作を再現できることです。詳しい設定方法はShadowrocketのDNS設定ガイドをご覧ください。名前解決が正常でハンドシェイクに失敗する場合は、サーバー設定を再確認します。一部のリソースだけ拒否される場合はルールの章に戻り、正常と確認済みのDNSを再度変更しないでください。

バッテリー消費・アップデート後の不具合：バックグラウンド動作と設定変更を確認

バッテリー消費の増加とアップデート後の不具合は一緒に語られがちですが、別々に根拠を確認する必要があります。前者は観察時間中の実際の動作を調べ、後者は何が変わったのかを確認します。接続がオンでも大量のデータを常に転送しているとは限りません。システムのバッテリー使用状況でアプリの割合が高くても、消費電力のすべてがそのアプリ単独によるものとは限りません。まず比較できる利用条件をそろえ、継続的な異常があるか判断してください。

比較可能な条件でバッテリーを観察

システムのSettingsでバッテリー使用状況を開き、同程度の時間帯を比較します。画面の点灯時間、電波状況、充電中かどうか、主な利用内容も記録してください。電波が弱い、動画を再生している、インターネット共有を使っている、バックグラウンド同期を行っていると、デバイス全体の消費電力が増えることがあります。片方は待機中で、もう片方は継続的に通信していた場合、2つの割合をそのまま比較できません。なるべく同じ作業を行い、傾向を確認します。

ネットワーク拡張機能は、トンネルを経由するほかのアプリの通信も処理します。システムの使用量は、全体の通信量とあわせて判断してください。Dataのアクティビティを比較し、想定していない大量通信がないか確認できます。ただし、統計上の分類だけで、特定のプロセスが空回りしていると断定しないでください。その時間に写真の同期、コンテンツのダウンロード、ほかのバックグラウンドリクエストがなかったか確認してから、Shadowrocketの設定を変更するか判断します。

繰り返しの再接続と診断負荷を確認

接続失敗後に再試行を繰り返すと、安定して接続している場合よりハンドシェイクやネットワークの起動が増えることがあります。電波が不安定なときに何度も再接続していないか、テスト頻度が高すぎないか、On Demandの条件が繰り返し適用されていないか確認します。元の設定を保存し、不要な自動テストと診断を一時停止して、同じ時間だけ観察してください。省電力だけを目的に、サーバーが要求するKeep Aliveを根拠なく変更すると、アイドル時の切断につながることがあります。

詳細ログは短時間の問題再現に適しており、目的なく長期間収集するものではありません。ログにはドメイン、アドレス、その他の利用情報が含まれる場合があるため、確認が終わったら通常の設定に戻し、必要に応じて機密情報を含む記録を削除してください。デバイスが明らかに熱い場合は、高負荷の作業を停止し、状態が落ち着いてから比較を再開します。高温が続く場合は、デバイスやシステム側の別の原因も確認してください。

どの層で変更が起きたかを特定

アプリのアップデート、システムのアップデート、サブスクリプションの更新、リモートConfigの更新は、それぞれ異なる変更です。最後に正常に使えた後の操作を思い出し、別々に記録してください。アプリのアップデートはApp Storeで確認します。システム要件はApp Storeのページに記載された内容を確認してください。サブスクリプションやリモート設定はアプリのアップデートとは別に変わる場合があります。時期が近いというだけで、すべての不具合をアップデートが原因だと決めつけないでください。

まず最小限の再テストを行います。現在のデータを残し、以前に有効と確認したサーバーと設定を使い、手動で接続して固定の宛先にアクセスしてください。サーバーが変わらずConfigが変わった場合は、ルール、DNS、ポリシー参照を優先して比較します。サブスクリプションの項目だけが変わった場合は、各フィールドを再確認します。情報に変更がないのにシステム権限の状態が変わっている場合は、接続スイッチの章に戻り、許可とシステム記録を確認してください。

設定を比較するときは、ファイル名ではなく実際の項目の差を確認します。同じ名前のリモートファイルでも内容が更新されている場合があり、名前が異なるローカルコピーでも内容は同じかもしれません。以前のコピーに戻すと原因の特定に役立ちますが、必要な調整まで長期間無視すべきという意味ではありません。故障の原因となった差を特定したら、その用途を理解したうえで修正するか元に戻してください。新しい設定をすべて削除するのは避けます。

再インストールは最初の手段ではありません

再インストールする前に、バックアップの範囲、サブスクリプションURL、手動項目の保存場所を確認し、App Storeの購入アカウントも確認してください。アプリを再取得できても、ローカル設定がすべて自動で戻るとは限りません。購入の復元については購入済み項目の復元をご覧ください。この手順で復元できるのはアプリの取得権であり、自分のサービス情報やリモートサーバーの利用可否は復元・変更されません。

環境を作り直す必要がある場合は、情報を一度にすべて戻さず、段階を分けてください。まず許可と基本接続を確認し、次に自分が持つ有効なサーバーを戻し、最後にルール全体と追加設定を戻します。これにより、どの段階で問題が再発するかを特定できます。バックアップをまとめてインポートしてすぐテストしても、問題が続いていることしか分からず、古い設定、ネットワーク条件、バックグラウンド動作のどれが原因か判断できません。

この章の完了条件は、異常な動作が減り、普段の作業が正常に行え、似た利用条件で同じ結果を再確認できることです。問題を説明するときは、システムの種類、ネットワークの種類、変更内容、機密情報を除いたエラーの抜粋を伝えれば十分です。バックアップ全体を公開する必要はありません。同じ情報をほかの自分のデバイスで使うと正常なのに、iPadだけで問題が起きる場合は、次の章でデバイスのネットワークと設定の違いを確認してください。

iPadでの確認事項：ネットワーク権限と設定の一致を確認

iPadとiPhoneでは同じ種類のサーバー情報を使えますが、ネットワーク環境が同じとは限りません。Wi-Fiのみ、モバイルデータ対応、インターネット共有経由、管理対象ネットワーク設定の使用など、違いが考えられます。同じサブスクリプションが一方のデバイスで動作するからといって、もう一方のアプリが壊れているとは限りません。まず実際のネットワーク、選択中の項目、有効なConfigをそろえてから比較します。

基本ネットワークが実際に使えるか確認

公衆Wi-Fiに接続した後、ネットワーク独自の認証ページで手続きが必要な場合があります。ステータスバーに接続済みと表示されても、外部の宛先にアクセスできるとは限りません。まず接続をオフにして、ネットワークが求める通常の認証を完了し、一般のWebページが開くことを確認してください。基本ネットワークが復旧した後にShadowrocketをオンにします。認証セッションが切れている場合は、ネットワークへのログインを先に行います。サブスクリプションを何度更新しても、この問題は解決しません。

モバイルデータを使うデバイスでは、システムのSettingsでアプリのモバイルデータ通信が許可されているか、バックグラウンド動作を制限する設定が有効になっていないか確認します。Wi-Fiのみのデバイスで、存在しないモバイルデータの項目を探す必要はありません。システム要件と対応デバイスはApp Storeのページに記載された内容をご確認ください。初回の取得と許可の手順はiPadでの取得方法で確認できます。別のデバイスのメニュー位置から推測しないでください。

同じ名前でも同じ設定とは限らない

2台のデバイスを比較するときは、表示名だけでなく、サーバーアドレス、ポート、プロトコル、TLS、転送項目を一つずつ確認します。サブスクリプションの更新時期が異なる場合や、リスト内の同名項目が変更されている場合があります。その後、Global RoutingとConfigで実際にどの項目が選択されているかを確認します。一方がProxy、もう一方がConfigなら、結果の違いはデバイスの性能ではなく、ルールの違いによる可能性があります。

大きな画面では、リストや詳細の表示方法が異なることがあります。設定の詳細を開いただけでは、現在使用する項目に選択されたとは限りません。サーバーを編集しても、現在使用中の別の項目は変わらない場合があります。編集後は実際の選択画面に戻り、適用対象を確認してください。画面表示の用語が分からない場合は、Home・Config・Settingsの画面表示ガイドをご覧ください。

バックアップをインポートした後も、どの内容が復元されたかを確認してください。サーバー、サブスクリプションURL、ルールファイル、システムのVPN許可は別々の情報であり、ファイルを1つコピーすればすべて完了するとは限りません。初回接続時には、システムでの確認が必要な場合があります。「データがある、項目が選択されている、設定が有効、システムの許可がある、実際にアクセスできる」の順に確認し、各段階の結果が明確になってから次に進みます。

インターネット共有・ネットワーク切り替え・管理対象デバイス

iPadがほかのデバイスのインターネット共有を使う場合、通信経路は共有元デバイス自身のアプリ通信と同じとは限りません。共有元デバイスの接続状態だけを根拠に、iPadのリクエストも同じ経路を通っていると判断しないでください。iPad上で現在のネットワークと接続結果を個別に確認します。共有元の電波が不安定、省電力状態、上流ネットワークの変化も、通信が断続する原因になります。

Wi-Fiとモバイルデータを切り替えると、既存の接続を再確立する必要があったり、名前解決の結果が一時的に残ったりすることがあります。切り替えが完了するまで待ってから、新しいリクエストを送信してください。失敗が続く場合は接続を停止して再確立し、同じネットワークに安定して接続した場合と比較します。On Demandの条件も確認し、ネットワーク切り替え時に何度も実行されたり、想定外に再接続されたりしないようにします。

学校や組織が管理するiPadでは、ネットワークポリシー、証明書、構成プロファイル、VPNの使用ルールによる制限がある場合があります。まずデバイス管理の要件を確認し、自分で管理していない設定を削除しないでください。同じデバイスでも組織のネットワークだけで失敗する場合は、状況を記録して管理者に確認を依頼します。サーバー設定、システム権限、組織のポリシーは別々に対処し、権限の確認を認証項目の変更で代用しないでください。

複数条件で確認し、復旧手段を残す

相互に比較する場合は、自分が所有する2台のデバイスを利用可能な同じネットワークに接続し、それぞれに保存した同じ有効情報を使って、同じ宛先へ順番にアクセスします。大量の同時アクセスは避けてください。結果が異なる場合はデバイス設定を確認します。同じ結果でネットワークを変えると差が出る場合は、ネットワーク経路の違いが考えられます。自分が利用するサービスの同時接続制限にも注意し、テスト方法自体がリモート側の制限を引き起こして誤った結論にならないようにします。

最後に、普段の利用方法に戻し、前景でのアクセス、短時間ロックした後の復旧、通常のネットワーク切り替えを確認します。Connectivity Testが1回成功しただけで完了としないでください。利用可能なConfigの安全なコピーを残し、権限、パラメーター、ルール、ネットワーク条件のどれを修正したか記録します。次に問題が起きたとき、すべての操作を最初からやり直さず、変更点から確認できます。