Shadowrocket
トラブル対処ガイド

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

まず、Homeの接続スイッチをタップしても接続状態にならない場合と、接続後数秒で自動的に切断される場合を分けて考えます。前者ではシステムの許可、デバイスの制限、設定の有効性を優先して確認します。後者では、ほかのVPN設定、On Demandの条件、ネットワークの切り替わりも確認してください。タップ後に表示されたメッセージ、システムの確認画面が出たか、スイッチがいつ元に戻るかを記録します。「接続できない」という情報だけではサーバー障害とは判断できません。システムがローカルVPNセッションを確立する前に止まっている場合、サーバーを何度も切り替えても解決しないことがあります。

システムの許可とデバイスの制限を確認する

初めて接続するとき、VPN構成の追加を許可し、デバイスのパスコードやシステム認証で確認するよう求められる場合があります。現在開いているShadowrocketからの要求であることを確認してから続行してください。直前にキャンセルした場合は、アプリに戻って接続を再度実行し、許可画面が表示されるか確認します。システムのSettingsでVPN管理画面を開き、該当する構成があるか確認してください。設定画面の名称や階層はシステムによって異なるため、システム設定の検索機能も利用できます。構成が存在することは接続情報が保存されたことを示すだけで、サーバー認証の成功を意味するものではありません。

デバイスが職場や学校の管理下にある場合、管理ポリシーによってVPNの変更が制限されていることがあります。管理に関する通知がないか確認し、利用方法についてデバイス管理者に問い合わせてください。内容が分からない管理構成は削除しないでください。個人所有のデバイスでも、ほかのVPNサービスが接続中でないか確認します。該当サービスの設定から停止してから、Shadowrocketを試してください。確認前の状態を記録し、仕事用ネットワークの構成を安易に削除しないようにします。システム設定のスイッチもすぐに元へ戻る場合は、ルールを変更し続けるのではなく、まずシステムのメッセージを記録してください。

変更を最小限にして設定と自動接続を切り分ける

On Demandを一時的にオフにし、変更前の条件を記録してください。ネットワークが変わったときに接続が再開されると、「手動で停止しても再接続する」ため、スイッチの不具合のように見えることがあります。次に、Homeで必要なパラメータがそろったサーバーが選択されていることを確認し、Configで現在の設定ファイルを正常に読み込めるか確認します。設定を編集してから問題が起きた場合は、まずファイルをコピーし、直近の正常なコピーに戻してください。未確認の設定を大量に、唯一のコピーへ上書きしないでください。ルール、DNS、書き換え設定は個別に戻し、接続への影響を特定できるようにします。

現在の操作をいったん終了してアプリを開き直し、再度試してください。それでも失敗する場合は、作業内容を保存してからデバイスを再起動し、一時的なシステムのネットワーク拡張機能の状態を切り分けます。再起動はサーバーの修復方法ではありません。再起動後に一時的にしか復旧しない場合は、Wi-Fiからモバイル通信への切り替え、画面ロック解除後の再接続、別のVPNサービスの接続開始など、発生条件を調べてください。条件を一つずつ試し、発生時刻と状況を記録して、異なる問題を一つの障害として扱わないようにします。

復旧が安定しているか確認する

スイッチがオンのまま維持されることを確認したら、普段使えるWebサイトにアクセスし、画面をロックして解除した後にもう一度アクセスします。実際の通信を行わずスイッチの色だけを見ると、「セッションは確立したが通信できない」問題を見落とすことがあります。スイッチが安定しているのにWebページを開けない場合は、次の章へ進んでください。システムの許可エラーが再度表示された場合は、メッセージを記録し、デバイスの権限を確認します。アプリを再入手する場合は購入済み項目の復元方法をご覧ください。アプリのアップデートと復元はApp Storeから行います。システム要件はApp Storeのページをご確認ください。

問題を伝える際は、「手動接続の直後に切断する」のか「ネットワーク切り替え後に切断する」のかを明記し、システムに表示されたメッセージの概要を添えてください。設定名、ネットワークの種類、On Demandの有効・無効も再現に役立ちます。サーバーのパスワード、サブスクリプションURL、認証情報を公開するスクリーンショットに含めないでください。この記録は修復後の比較にも使えます。同じネットワークと操作条件で再テストして、初めて確認完了となります。

接続済みなのにWebサイトやアプリがインターネットに繋がらない

接続表示はシステムのVPNセッションが確立したことを示しますが、すべての通信が目的のサーバーへ届くとは限りません。アクセスにはDNS、ルールの照合、サーバーへの接続、接続先からの応答などが関係します。まずShadowrocketを一時的に切断し、同じWebページにアクセスしてください。切断中も失敗する場合は、Wi-Fiのログイン認証、モバイル通信の利用許可、ルーター、接続先の状態を優先して確認します。公衆Wi-Fiでは、先にシステムの認証ページでログインが必要な場合があります。基本ネットワークでインターネットに接続できない状態でPROXYやDIRECTのルールを変更すると、確認項目が増えるだけです。

Global Routingで問題の範囲を切り分ける

現在のGlobal Routingの設定を記録し、各モードを短時間ずつ比較します。Configは現在の設定ファイルのルールに従って通信を処理します。Proxyは通常、選択したプロキシ経路に一般的な通信を送ります。Directは比較用に基本ネットワークへ直接接続します。これらは診断時のモードであり、独立した3台のサーバーではありません。システム通信、設定内の個別処理、機能ごとの挙動が結果に影響する場合もあります。一度の比較だけですべての通信経路を判断しないでください。切り替えるたびに新しくリクエストを行い、キャッシュ済みのページだけを見ないようにします。

ProxyではアクセスできるのにConfigでは失敗する場合は、現在実際に有効な設定ファイルを開き、対象のドメインに最初に適用されるルールを確認してください。広範囲に一致するルールが個別ルールより前にある、ポリシーの参照先が無効になっている、REJECTルールがアプリに必要なリソースを遮断している、といったケースがあります。トップページのドメインだけを検索しないでください。アプリを開くと、認証、画像、APIなど複数のドメインへ通信することがあります。通信記録で具体的な失敗項目を確認するほうが、すべての通信をProxyに固定するより原因を特定しやすくなります。

キーワードだけでなくルールを上から順に確認する

以下は照合順序を説明するための例であり、完全な設定ファイルの代わりにはなりません。ルールは通常上から順に照合され、最初に一致したルールで処理が決まります。FINALはそれ以前のルールに一致しなかった通信を処理します。例のプライベートネットワーク範囲は、LANへの直接接続を説明するためのものです。実際のネットワークと設定要件も確認してください。IP判定を行うルールはドメインの名前解決に関係するため、完全に独立した設定として扱うことはできません。

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

ConfigとProxyの両方で失敗し、Directでは正常な場合は、選択中のサーバーとプロキシ経路を確認してください。特定のWebサイトだけで失敗する場合は、接続先の障害、DNSの不適切な応答、ルールの誤適用、サーバー側によるアクセス拒否を切り分けます。ブラウザーで開けても、ほかのアプリでも正常とは限りません。アプリごとに使用するドメイン、接続方式、キャッシュが異なる場合があります。関連のない2つのWebサイトと普段使うアプリを比較すると、特定サービスの問題を全体的な通信障害と誤認しにくくなります。

元の設定に戻して実際の通信を確認する

確認が終わったら、Global Routingを元の設定に戻し、必要性を確認できたルール変更だけを残してください。再接続して新しいリクエストを行い、Webページの本文と関連リソースがすべて読み込まれるか確認します。ログインや画像のアップロードなど、以前失敗した操作もテストしてください。失敗が続く場合は、ドメイン、適用されたルール、ポリシー、エラーの種類を記録し、ルールによる振り分けの説明で内容を確認します。例外ルールを一度に大量に追加しないでください。一時的に直接接続する場合も、処理経路が変わるほかの通信に影響しないよう、確認済みの接続先に限定します。

「ドメインを開けないが、テスト結果は表示される」場合は、ルーティングモードの変更を続けず、DNSの問題の章を確認してください。接続テストと実際のWebアクセスでは通信経路が異なります。テストの成功が証明するのは、実際にテストされた範囲だけです。

サーバーがタイムアウトする、接続が拒否される、プロトコルのハンドシェイクに失敗する

エラーの種類を記録してから、サーバー設定を確認してください。タイムアウトは、テストの待機時間内に期待した応答が得られなかったことを示します。基本ネットワーク、サーバーのポート、プロトコルのハンドシェイク、接続先へのリクエストなど、さまざまな段階で発生します。接続拒否は、接続先のポートが接続を受け付けていない状況に近いエラーです。認証失敗の場合は、まず認証情報を確認します。テスト方法が異なれば結果も単純に比較できません。Connectivity Testの結果はテスト方法と併せて記録し、一つの数値だけでプロトコル全体が正常と判断しないでください。

選択した項目とアドレスの誤りを確認する

Homeに戻り、最近開いた編集画面だけでなく、現在選択されているサーバーを確認します。サブスクリプションの更新後に似た名前の項目が追加されたり、古い項目が一覧に残ったりすることがあります。対象の編集画面を開き、プロトコル、サーバーのドメイン、ポートを一つずつ照合してください。コピー時に空白や全角記号が混入していないか、共有リンク全体をサーバーアドレス欄に入力していないかも確認します。ドメインとポートは役割が異なるため、通常はそれぞれの欄に入力します。名前の地域表示やメモだけで実際の接続先を判断しないでください。

同じ項目がWi-Fiではタイムアウトし、モバイル通信では正常な場合、接続ネットワークまたはサーバーまでの経路に問題がある可能性があります。ただし、これだけでサーバーが完全に正常とは断定できません。まず両方の基本ネットワークで通常のWebサイトを開けることを確認し、時間帯による負荷の違いを避けるため、近い時間に比較してください。同じネットワークで既存の項目すべてが失敗し、別のネットワークでは正常な場合は、ルーターの制限、ネットワーク認証、UDPの利用可否を確認します。手当たり次第に各項目のパスワードを変更しないでください。

プロトコルのハンドシェイクに必要なパラメータを確認する

TLSを使用する設定では、サーバーが指定するドメイン関連の項目、デバイスの日時、証明書の有効性を確認してください。デバイスの日時が大きくずれていると証明書の検証に影響するため、正しい日時に戻してからテストします。証明書検証を無効にすることを通常の解決方法にしないでください。接続先の本人確認の範囲が変わります。通信方式の設定があるプロトコルでは、Host、Path、TLS関連の名前がそれぞれ異なる階層で使われる場合があります。内容が似ていても相互に置き換えないでください。各項目の意味はプロトコルと入力項目の説明をご覧ください。

共有リンクから読み込んだ場合も、解析結果に必要な情報がすべて含まれているか確認してください。元の情報に通信パラメータがなければ、読み込みに成功しただけでは利用可能とは限りません。ほかの項目の設定を参考に推測せず、元情報の提供元に確認してください。サブスクリプションから生成された項目を手動で変更する前にコピーを作成します。そうしないと、次回の更新で変更が上書きされ、問題が再発する場合があります。「既存のサーバー情報を確認してPathを修正」のように、変更理由も記録しておくと後から確認しやすくなります。

実際の通信で確認し、テストを連続実行しない

パラメータを確認した項目を選んで一度テストし、実際に必要なWebサイトへアクセスします。失敗する場合はエラーの概要とネットワーク条件を保存し、少し時間を置いて再テストしてください。テストを大量に連続実行するとリクエストの負荷が増し、一時的な障害も観察しにくくなります。特定のサーバーだけ失敗し続ける場合は、エラーの種類、発生時刻、実施した比較をまとめて、利用中のサービス提供元に稼働状況を確認してください。問い合わせる前に認証情報、鍵、サブスクリプションURL全体を削除します。診断に必要なのは現象とパラメータの種類であり、認証情報を公開する必要はありません。

ハンドシェイクは成功するのに、大きなページやアップロードが失敗する場合は、速度の章で持続的な通信、パケットロス、MTUに関する点を確認してください。すべての問題をサーバーのタイムアウトとして扱わないようにします。障害がどの段階で起きているかを特定すると、適切な対処を選べます。

サブスクリプションの更新失敗、読み込み結果が空、項目の重複

サブスクリプションの処理には、アドレスの取得、サーバーへのリクエスト、内容の受信、形式の解析、ローカル一覧への保存など、複数の段階があります。更新に失敗しても、既存の項目が無効とは限りません。古い項目では接続でき、更新リクエストだけが失敗していることもあります。まず既存項目の件数と名前の範囲を記録し、復元できるコピーを保存してから、一度更新して表示内容を確認してください。サブスクリプションはご利用のサービス提供元から入手します。出所の分からないアドレスで既存の登録先を置き換えたり、認証に使うURL全体を公開の場に貼り付けたりしないでください。

読み込む内容と操作画面が合っているか確認する

単一サーバーの共有リンク、サーバー一覧のサブスクリプション、完全な設定ファイルはそれぞれ異なる形式です。共有リンクは一つの項目を示し、一覧のサブスクリプションは複数の項目を継続して取得するためのものです。設定ファイルにはルールやDNSが含まれる場合もあります。Webページのアドレスや設定ファイルのアドレスを、形式の合わない欄へ入力すると、「リクエストには成功したが、認識できる項目がない」という結果になることがあります。元の提供元による形式と入力先の説明を確認してから、はじめにに沿って操作してください。共有リンクの構造を確認するには、共有リンクとサブスクリプションURLの違いもご覧ください。

アドレスをコピーするときは、表示されたタイトルだけをコピーしていないか、疑問符以降のパラメータが抜けていないか、メッセージアプリが改行を挿入していないか確認してください。アドレス内の大文字・小文字やエンコードされた文字を安易に変更しないでください。半角記号を全角の句読点に置き換えるのも避けます。リンクを再取得する場合は、元のサービス提供元から入手し、用途を確認してください。サブスクリプションURLにはアクセス認証情報が含まれることがあります。システムのクリップボード、スクリーンショット、閲覧履歴に残る可能性もあるため、診断後に不要なコピーを適切に削除し、複数のアプリ間で繰り返し共有しないでください。

ネットワークエラー、応答エラー、解析エラーを区別する

リクエストがタイムアウトする場合は、まずサブスクリプションのドメインが名前解決できるか、現在のネットワークからアクセスできるかを確認します。証明書エラーでは、デバイスの日時、ドメイン、証明書を確認してください。明確なHTTPステータスが表示される場合は、応答が一定段階まで届いていることを示します。401や403は認証、権限、アクセス制限に関連することが多いものの、具体的な理由はサーバー側で確認する必要があります。404はパスの変更や不完全なアドレス、429はリクエスト頻度の制限を示す場合があります。429が返された場合は連続更新をやめ、応答の指示に従って待ってください。最初に表示された有効なエラーを、繰り返し操作で見えなくしないようにします。

ログインページ、説明ページ、ネットワーク認証ページが返された場合、クライアントが受信しているのは期待するサブスクリプション内容ではなくHTMLの可能性があります。そのため「ブラウザーでは開ける」ことは「サブスクリプションとして解析できる」ことを意味しません。元のサービスに保護された内容を確認する方法があれば、その説明に従って応答形式を確認してください。サブスクリプションの認証情報を、見知らぬオンライン変換サイトに入力しないでください。クライアント形式を選べるサブスクリプションもあります。URLの末尾だけで判断せず、Shadowrocketが認識できる形式が選択されているか確認してください。

重複項目と更新後の変化を確認する

重複した項目がある場合、まず「同じサブスクリプションを複数回追加した」のか「サーバー側の項目名が重複している」のかを切り分けます。前者はバックアップと登録元を確認してから、必要な登録だけを残せます。後者は名前だけで削除せず、アドレス、ポート、プロトコルを比較してください。サブスクリプションの更新によって古い項目が削除されたり、名前が変わったりして、選択中の項目が変わる場合もあります。更新後はHomeに戻り、現在の選択項目が残っていて必要なパラメータもそろっていることを確認してから、実際にアクセスします。一覧に新しい名前が表示されただけで、更新が正常に完了したと判断しないでください。

ローカルの項目を手動で変更している場合は、更新前に独立した項目としてコピーし、用途を明記してください。サブスクリプションから生成された内容と個別に修正した内容を分けて管理すると、上書きによる問題の再発を防ぎやすくなります。更新リクエストだけが失敗し、古い項目は使える場合は、動作している状態を保ち、エラーと応答時間を記録してからサービス提供元に確認してください。修復の確認には、更新完了、項目の認識、正しい項目の選択、実際の通信成功が必要です。エラーメッセージが消えただけでは十分ではありません。

接続できるが、速度が遅い、または通信が不安定

「遅い」という症状を、再現可能な状況に分けてください。最初の読み込みに時間がかかる、ページの読み込み開始後も遅い、動画が途中で止まる、大きなファイルのアップロードが進まない、といった違いがあります。初回の待ち時間は名前解決やハンドシェイク、継続的な通信は接続ネットワーク、サーバーの負荷、接続先、パケットロス、通信方式などの影響を受けます。低遅延でも転送量が多いとは限らず、短時間の接続テストから長時間の通信速度も予測できません。一度のConnectivity Testの順位だけで、すべての用途におけるサーバーの速さを決めつけないでください。

同じ条件で比較する

内容とサイズが比較的安定した、利用可能なテスト対象を一つ選び、同じデバイス、同じネットワーク、近い時間帯で比較してください。ほかの大容量通信を一時停止し、Wi-Fiの電波状況とモバイルデータ通信の状態を確認してから、基本ネットワークと現在のプロキシ経路をそれぞれテストします。平均値一つだけではなく、読み込み開始までの待ち時間、読み込み中の速度、通信が中断したかを記録します。テスト自体も通信量を消費し、サーバーの負荷を変える可能性があります。再現に必要な回数にとどめ、大量の並列テストを続けないでください。

すべてのWebサイトが遅い場合は、まず接続ネットワークと選択中のサーバーを確認します。一つのサービスだけが遅い場合は、そのサービスのリソース用ドメイン、ルーティング経路、サーバーの応答を確認してください。ページの本文はすぐ表示されるのに画像や動画だけが遅い場合、リソースごとにドメインや通信経路が異なる可能性があります。通信記録で時間がかかっている部分を調べ、Configでルールを確認します。複雑な設定ファイルへ丸ごと置き換えると、DNS、ルール、ほかの処理も同時に変わり、比較の基準が失われます。

ハンドシェイク、接続の繰り返し、通信経路の条件を確認する

頻繁な切断と再接続は、TLSなどのプロトコルのハンドシェイクを繰り返す原因となり、短いリクエストほど読み込みの遅さにつながることがあります。遅延と同時にタイムアウト、接続切断、ネットワーク切り替えが発生していないか確認してください。エレベーター、移動中、電波の弱いWi-Fiでのみ起きる場合は、まず接続環境を改善します。安定したネットワークで復旧するなら、ルール変更を優先する必要はありません。UDPを使用する通信では、現在のネットワークが必要な通信方式に対応しているかを確認します。通常のWebページを開けても、UDP経路の品質が良好とは限りません。

小さなページは正常なのに大きなデータ転送が止まる場合、パケットロス、経路MTU、サーバー側の制限が関係することがありますが、症状だけでは断定できません。複数の箇所に異なるMTU値をむやみに設定しないでください。使用中のプロトコルに該当する設定項目があり、元のサーバー情報や再現可能な根拠がある場合に限り、コピー上で一項目ずつ変更して比較します。WireGuardなどの設定では、許可するアドレス範囲と実際のルートも確認してください。元の値や既定値に戻す際も記録を残し、一時的な試験値が残らないようにします。

設定による追加の待ち時間を切り分ける

複雑なルール、リモートリソース、リクエストの書き換えが処理段階を増やすことはありますが、すべての機能が問題とは限りません。まず現在の設定をコピーし、そのコピーで最近追加した処理を一つだけ無効にして同じ通信をテストします。改善した場合は、項目を一つずつ減らして原因を絞り込みます。HTTPSの検査や書き換えを行う設定は通信の処理方法を変えます。目的と証明書の扱いを十分に理解してから操作し、速度向上のために処理範囲を広げないでください。設定ファイルの各セクションについては設定ファイルのセクション解説をご覧ください。

本来LANでアクセスするサービスをルールがプロキシ経由にしていないか、特定の経路が必要なリソースを直接接続にしていないかも確認してください。LANプリンターやファイルへのアクセスと通常のWebサイトでは、診断方法が異なります。対象を特定してルールを修正したら、元のGlobal Routingに戻して確認します。Proxyのままにするとルールの問題を回避できるだけで、設定自体は直っていない可能性があります。設定のコピーは確認項目を切り分けるためのもので、整理されていない複数のファイルにそれぞれ異なる役割を持たせるためのものではありません。

最後は実際の作業で確認します。ページの読み込み、一定時間のコンテンツ再生、アップロードなどを行い、同じ停止や遅延が続くか比較してください。特定の時間帯だけ遅い場合は、時間帯、接続ネットワーク、エラーの概要を記録し、利用中のサービス提供元に状況を確認します。一度速かっただけで修復完了と判断しないでください。接続先サイト側の速度制限をクライアントの設定が原因と決めつけるのも避けます。

DNSの名前解決に失敗する、特定のドメインだけ開けない

DNSはドメイン名を接続先アドレスに変換します。サーバーへの接続、ルール判定、接続先へのアクセスはいずれもDNSに依存する場合があります。よくある症状は、サーバーのドメインを解決できない、Webページにアドレスが見つからないと表示される、一部のリソースだけ読み込まれない、Connectivity Testは成功するのにWebページを開けない、といったものです。まず、解決に失敗しているのがサーバーのドメインかWebサイトのドメインかを確認します。問題が発生する段階が異なり、前者ではプロキシ接続自体を確立できないことがあります。確立済みのセッション後に発生する後者とは分けて確認してください。

現在有効な名前解決の設定元を確認する

Configで現在使用中のファイルを確認し、[General]セクションと関連するDNS設定を確認してください。システムDNS、設定ファイルのDNS、暗号化DNSの設定が、リクエストごとに異なる影響を与えることがあります。一行にsystemと書かれているだけで、すべての名前解決が同じ経路を使うと判断しないでください。まず元の値を記録し、アプリ内でその項目の説明を読んでから、一項目ずつ比較します。以下の例はキーと値の書式を示すもので、すべてのネットワークに推奨される設定ではありません。設定ファイル全体を置き換えるためにも使わないでください。

[General]
bypass-system = true
dns-server = system
ipv6 = false

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

DNSを変更した直後に問題が発生した場合は、まず設定のコピーで以前使えていた値に戻し、再接続して新しいリクエストを行います。ブラウザー、システム、アプリはそれぞれ結果をキャッシュすることがあります。そのため、古いページが引き続き失敗したり、既存の接続が使えたりしても、変更が反映されていないとは限りません。進行中のリクエストを終了してから再アクセスし、必要に応じて影響を受けたアプリを再起動してください。キャッシュの削除を目的にデバイスの設定をすべてリセットするのは避けます。名前解決元または関連する項目を一度に一つだけ変更し、元に戻せるようにしてください。

タイムアウト、レコードなし、アドレスへの接続可否を区別する

名前解決のタイムアウトは、応答が時間内に得られなかったことを示します。DNSサービスまでの通信経路を確認してください。該当するレコードがないと明示される場合は、ドメイン名の入力、レコードの種類、接続先の状況を確認します。アドレスが返ってきても、そのアドレスへの接続がタイムアウトする場合、問題はルーティングや接続先に移っている可能性があり、DNSを変更し続けても解決しません。暗号化DNSでは、DNSサービスのアドレス自体をどう名前解決して接続するか、また未確立のプロキシ経路が必要かどうかも確認します。起動に必要な経路が互いに依存する状態を避けてください。

IPv6を有効にしたときだけ問題が発生する場合は、現在のネットワークに利用可能なIPv6経路があるか、接続先から返されたアドレスと実際の経路が一致しているか確認します。設定のコピーでIPv6を一度無効にして比較できますが、すべてのネットワークで無効にするべきだとは限りません。元に戻した後も実際のサービスでテストしてください。ネットワークが特定のアドレス変換方式に依存する場合、数字のアドレスへの直接アクセスや、片方のアドレスファミリーだけのテストは誤解を招くことがあります。「特定のネットワークで特定のアドレスファミリーが失敗する」と記録するほうが、「DNSの調子が悪い」とするより正確です。

ローカルのホスト設定とルールの連携を確認する

[Host]のローカルマッピングが通常の名前解決結果を上書きしている場合、古いアドレスが使えなくなると、特定のドメインだけ開けない症状が続くことがあります。設定内で該当ドメインのマッピングと関連ルールを検索し、以前のテストで追加した設定が残っていないか確認してください。削除前にコピーを保存し、元の用途も記録します。ドメインルールとIPルールには照合順序があります。IPを判定するルールには、先に名前解決が必要な場合があります。ドメインが前のルールで一致した場合、後続のGEOIPやIP-CIDRが同じリクエストに対する通常の次のルールとして照合されるわけではありません。

Webサイトのアドレスを一時的に解決した結果を、長期間[Host]に固定しないでください。CDNや動的アドレスを利用するサービスは、ネットワークや時間に応じて異なる結果を返すことがあります。アドレスを固定すると振り分けが損なわれ、証明書、リソース、接続性に問題が生じる可能性があります。また、HTTPSサイトをIPアドレスで直接開いても、同等のテストにはなりません。証明書名やサーバーの仮想ホスト選択がドメイン名に依存することがあります。テストでは、名前解決、ポートへの接続、サービスを実際に利用できるかのどれを確認するのか明確にしてください。

修復後はサーバーのドメイン、以前開けなかったWebサイト、関連リソースをそれぞれ確認し、Configで普段の使用モードに戻します。特定のWi-Fiだけで問題が起きる場合は、ルーターのDNSとネットワーク認証も確認してください。対処例はDNSの名前解決エラーへの対処をご覧ください。記録にはドメインの種類、名前解決エラー、適用されたポリシーを残せば十分です。リクエストURL全体に含まれる機密パラメータを公開しないでください。

バッテリー消費の増加、発熱、バックグラウンド動作の異常

システムのバッテリー画面でShadowrocketの動作時間が長く表示されても、消費電力のすべてがアプリ内の特定機能によるとは限りません。VPNはほかのアプリの通信も処理します。システムの統計は、前面での使用、バックグラウンド通信、接続時間にも左右されます。まず同じデバイス、近い時間帯、似た作業条件で比較し、画面の使用状況、接続ネットワーク、充電状態、通信中の作業を記録してください。動画再生中の統計をデバイスの待機中の統計と直接比べても、追加の消費電力の原因は特定できません。

比較できる観察時間を設定する

デバイスのバッテリー残量と温度が比較的安定しているときに、普段どおり使う時間を選んで観察し、その後システムのバッテリーと通信量の統計を確認します。特定の消費率に合わせる必要はありません。同じ種類の作業どうしで、目立った変化があるかを確認します。大容量ファイルの同期、動画の連続再生、インターネット共有など、通信量の多い作業を一時停止し、システムアップデートや写真の処理が同時に行われていないか確認してください。できるだけ同じネットワークで観察します。モバイル通信の電波が弱い場合、ルール処理よりも無線通信の負荷を先に確認すべきことがあります。

接続スイッチが頻繁に変化する場合や、通信記録で失敗と再試行が続く場合は、まず接続の問題を解決してください。再接続、名前解決のやり直し、ハンドシェイクの繰り返しは動作量を増やし、バックグラウンドで常に処理が行われているように見えることがあります。複数の自動接続条件が干渉していないか、ネットワーク切り替え後にOn Demandが何度も動作していないか、電波の不安定なWi-Fiの範囲に長時間とどまっていないか確認してください。自動接続をオフにして短時間比較する場合は、元の設定を記録します。診断後は必要に応じて設定を戻し、テスト状態のまま放置しないでください。

診断作業と継続的な通信を確認する

Connectivity Testの一括実行、頻繁なサブスクリプション更新、詳細な通信記録、長時間のデバッグはいずれも追加の処理です。診断後は不要なテストを停止し、通常の記録範囲に戻してから、システムの統計が安定するか確認してください。複数のテストを同時に実行してバッテリー消費を調べると、診断そのものが負荷になります。ログは原因特定に必要な範囲にとどめてください。長期間の記録にはアクセスしたドメインやリクエスト情報が含まれる場合があります。書き出しや共有の前に、機密情報がないか確認してください。

デバイスを使っていないときも通信が続く場合、ほかのアプリがバックグラウンドで同期していないか確認してください。システムで許可されている範囲で関連するバックグラウンド処理を一つずつ停止し、通信量の変化を比較します。確認せずにすべてのアプリのアクセス権をまとめてオフにしないでください。特定のアプリを開いたときだけ再試行が続く場合は、失敗しているリソースとルール経路を確認し、インターネット接続とDNSの章も参照します。クライアントのバックグラウンド動作を制限するだけでなく、通信失敗そのものを解決するほうが根本原因に近い対処です。

設定のコピーで追加処理の影響を切り分ける

設定内容を追加した直後に問題が発生した場合は、現在のファイルをコピーし、最近の変更のうち一種類だけをコピー側で取り消します。たとえば新しく追加した書き換えや、複雑なリクエスト処理を戻します。同じサーバー、同じGlobal Routing、同じ作業条件で発熱や動作を比較してください。サーバー、DNS、設定を同時に変更すると、改善しても原因が分かりません。設定の複雑さは行数だけでは判断できません。現在の通信にどの処理が適用されているか、新たなリクエストや再試行が継続して発生しているかを確認します。

特定のプロトコルの名前だけで、消費電力が少ない、または多いと決めつけないでください。接続ネットワークの品質、再送、接続数、通信内容によって結果は変わります。ご自身が利用中の複数の項目を比較する場合は、同じ作業を一つずつ実行し、どれも安定して通信できることを確認してください。失敗を繰り返す接続と正常な接続の消費電力の差は、まず利用可能性の違いを示すものであり、プロトコル固有の一定の特性とは限りません。

最終確認では普段の使用条件に戻し、一時的な記録を停止してもネットワーク機能が正常なままか、バックグラウンド動作の異常が続くかを確認します。サポートへ問い合わせる際は、システムのバッテリー画面に表示された時間帯、主な使用状況、充電の有無、ネットワークの種類、再接続の有無を伝えてください。割合だけのスクリーンショットでは不十分です。使用条件が分からない統計からは、アプリの処理、ほかのアプリの通信、無線ネットワークの負荷を確実に区別できません。

アップデート後の問題とiPadのトラブル対処

アップデート後に初めて問題を確認した場合、発生時期がアップデートと近いことは分かりますが、アップデートだけが原因とは限りません。同じ時期にアプリ、システム、サブスクリプションの内容、接続ネットワークが変わった可能性があります。アプリを更新したか、システムを再起動したか、サブスクリプションが自動更新されたか、設定が置き換わったかなど、実際に起きた変更を記録し、同じ操作で再現するか確認してください。アップデート履歴とシステム要件はApp Storeのページをご確認ください。特定のバージョンで何が変わったかを記憶だけで推測しないでください。

以前の設定を残し、現在の選択内容を確認する

現在の設定と必要な個別項目をコピーし、認証情報を適切に保管してください。Homeに戻って使用中のサーバーを確認し、Configで有効なファイルを確認してから、Global RoutingとOn Demandを確認します。一覧に項目があるだけでは、以前と同じ項目が選択されているとは限りません。サブスクリプションの更新で項目名やパラメータが変更・削除され、アプリのアップデートと同時に発生したように見えることもあります。すべての設定をすぐにリセットするより、ローカルのコピーと現在の内容をセクションごとに比較するほうが、実際の差を見つけやすくなります。

古い設定だけで問題が起きる場合は、コピー上で直近の変更を取り消すか、動作確認済みの最小限の内容から段階的に戻してください。設定の読み込みで明確なエラーが出た場合は、該当行の書式、セクション、ポリシー参照を修正します。エラーを無視して別の設定を重ねないでください。アプリ内の説明を確認するときは英語の設定名をそのまま参照し、翻訳による誤認を避けます。設定を復元した後は実際の通信も確認してください。Configの画面を開けても、すべての項目が現在のネットワークに適しているとは限りません。

同じ購入履歴と同じネットワーク設定を区別する

iPadでは購入時に使用したApple IDでApp Storeを開き、購入済みの状態を確認してください。復元手順はiPadでの入手方法と購入済み項目の復元をご覧ください。購入履歴はアプリを入手する権利を確認するもので、ローカルのサーバー、サブスクリプション、設定がすべて自動で復元されるとは限りません。アプリに読み込みや同期の機能がある場合は、データの入手元、内容、現在有効なファイルを確認してください。デバイスにアプリ名が表示されているだけで、2台のネットワーク設定が完全に同じだと判断しないでください。

iPhoneとiPadを比較する場合は、まず両方を同じWi-Fi、同じ利用中のサーバー、同等の設定にして、同じ接続先へアクセスします。一方がモバイル通信、もう一方がWi-Fiを使っていると、結果にはネットワーク経路の違いが含まれます。iPadにキーボード、ドック、Ethernetアダプタが接続されているか、システムで別のネットワークサービスが使われていないかも確認してください。アクセサリによって接続経路が変わると、DNS、LANアクセス、On Demandの条件も元のWi-Fi環境とは異なる場合があります。

画面分割操作、スリープ復帰、LANアクセスを確認する

iPadでは画面分割や広いレイアウトにより、一覧と詳細を同時に表示することがあります。ファイルを編集しても、そのファイルが現在の設定として有効になったとは限りません。サーバーを表示しても、その項目が接続先として選択されたとは限りません。操作後はHomeとConfigに戻って実際の選択を確認してください。マルチタスクでアプリを切り替えたときは、「アプリのウインドウが再表示された」ことと「接続が再確立した」ことを区別します。前面にウインドウが表示されているかではなく、スイッチ、システムの状態、実際のリクエスト結果を併せて接続状態を判断してください。

スリープから復帰した後だけ失敗する場合は、スリープ前後のネットワーク、ログイン認証の有無、On Demandの状態を記録します。まず手動接続で復旧を確認し、その後、同じ条件で自動接続が動作するかを調べてください。LAN上のファイル、プリンター、デバイス検出に失敗する場合は、関連するアクセス許可と接続先が同じネットワークセグメントにあるかを確認します。一部の検出方式はマルチキャストに依存するため、通常のWebサイトへアクセスできてもLAN内の検出が正常とは限りません。一つのLAN機器のために、すべてのルーティングルールを削除しないでください。

再インストールは、バックアップを作成し、設定を比較し、本当に必要だと確認した後にのみ検討してください。ローカルの内容が削除されることがありますが、サーバー側のパラメータやサブスクリプションの権限は修復されません。アプリの入手はApp Storeから行ってください。正規品の確認には、デベロッパーのShadow Launch Technology Limited、公式アイコン、アプリID 932747118を照合できます。作業後は手動接続、画面ロック後の復帰、ネットワーク切り替え、以前失敗した操作をそれぞれテストします。有効だった手順を簡潔に記録し、ほかの設定は元のまま残すことで、次回の確認に使える基準を保てます。