Shadowrocket
トラブル対処ガイド

01 / VPN CONFIGURATION

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

認証の問題か接続の問題かを切り分ける

Homeの接続スイッチがオンの状態を維持できない場合は、まずシステムでVPN構成の追加が許可されているか確認します。初回接続時には、VPN構成の追加を確認する画面が表示され、デバイスのパスコードまたはシステム認証が必要になることがあります。この認証はアプリがネットワーク接続を確立するためのもので、接続先サーバーの認証が完了したことを意味しません。確認画面をキャンセルした場合は、アプリに戻って接続を再度開始し、確認を完了してください。サーバーのパスワードを何度も変更する必要はありません。スイッチが確認前にオフになるのか、オンになってすぐオフになるのかを記録してください。症状によって確認箇所が異なります。

システムのSettingsを開き、VPN関連の設定にShadowrocketの構成があるか確認します。設定画面の場所はシステムによって異なるため、設定内の検索機能を利用してください。ほかのVPN接続が実行中でないかも確認します。一般的な個人用VPN接続は、複数の接続を同時に維持できない場合があります。ほかの接続を終了してから、Shadowrocketで再度テストしてください。用途が分からないままネットワーク構成をすべて削除しないでください。特に仕事用や学校用のデバイスでは、管理対象の構成が必要なアクセス制御を担っている場合があります。

元に戻せる手順で残った状態を解消する

1. 現在の接続を停止し、システムのVPN状態が解除されるのを待ってから、Shadowrocketを開き直します。
2. On Demandを一時的にオフにし、システムによる自動接続と手動テストが交互に起きないようにします。
3. 利用中のサーバーが選択されていることを確認し、設定を保存してから接続テストを一度だけ行います。
4. すぐに接続が終了する場合は、デバイスを再起動します。その後、同じネットワークで再テストし、結果を記録してください。

システムに構成があるのにセッションを確立できない場合は、構成のバックアップが完全であることを確認したうえで、Shadowrocketに属することが明確なVPN構成を削除し、アプリから再度追加を要求します。削除するのはシステムのネットワーク認証情報であり、接続先アカウントのリセットではありません。サービスの期限切れや設定ミスも解決できません。操作前に、既存の設定を再取得できることを確認してください。アプリの再インストールを最初に行うと、ローカルのサーバー情報、Config、診断記録が失われる可能性があります。

システムの制限と接続条件を確認する

管理対象デバイスでは、VPNの追加、ネットワーク設定の変更、特定のネットワーク拡張機能の実行が制限されている場合があります。システムのボタンが操作できない、組織による管理を示すメッセージが出る、構成が自動的に元に戻る場合は、デバイスの管理者にポリシーを確認してください。デバイスのパスコード、スクリーンタイムの制限、管理ポリシーはそれぞれ別の問題です。接続先サーバーの情報では、これらの制限を変更できません。個人用デバイスでも、ストレージの空き容量が不足していないか、ほかのアプリでも同様の問題が起きていないかを確認してから、ネットワーク拡張機能の起動失敗かどうかを判断してください。

On Demandは設定した条件に応じて接続を開始します。そのため、「オフにしても自動で再びオンになる」だけではスイッチの故障とは限りません。まずOn Demandを無効にし、手動接続が安定して維持されることを確認してから、接続条件を一つずつ戻します。Wi-Fiの切り替え、画面ロック、特定のネットワークから離れたときだけ問題が起きる場合は、具体的な操作を記録してください。「ときどき切れる」だけでは再現条件を特定できません。同じ条件で繰り返し確認することで、システムによるセッション再構築とアプリの予期しない終了を区別できます。

オンにできない場合は、デバイスのモデル、システム要件の確認結果、認証画面の内容、管理対象かどうか、再起動後の再現手順をまとめてください。アプリの入手方法とシステム要件は正規アプリの確認方法をご覧ください。システム要件はApp Storeの掲載内容をご確認ください。最初に表示されたエラーを見失うほど構成を繰り返し削除しないでください。最初のメッセージのほうが、直近の試行結果より原因の特定に役立つことがあります。

02 / REQUEST PATH

接続済みなのにWebページを開けない

まず接続をオフにした状態と比較する

まずShadowrocketの接続を停止し、現在のWi-Fiまたはモバイル通信で、普段アクセスできるページを開きます。接続を停止しても失敗する場合は、ネットワーク自体を確認してください。Wi-FiでWeb認証が必要か、ルーターがインターネットに接続できるか、モバイルデータ通信が許可されているか、電波が不安定な場所にいないかを調べます。公衆Wi-Fiの認証は、接続を停止した状態で必要になることがあります。認証後に再度テストしてください。ネットワーク自体が使えない状態でルールを変更しても、確認項目が増えるだけです。

接続をオフにすると正常で、オンにすると失敗する場合は、問題の範囲を確認します。異なる接続先を2つテストし、すべてのリクエストが失敗するのか、特定のアプリだけか、特定のドメインだけかを切り分けてください。同じページで同じ操作を行い、一方はキャッシュ済みの内容、もう一方は新たな通信を必要とする内容、といった違いが出ないようにします。ブラウザーに以前のページが表示されていても、接続が正常とは限りません。ネットワーク通信が必要な内容を再読み込みし、アプリのリクエスト記録に該当するアクセスがあるか確認してください。

Global Routingで問題の場所を切り分ける

Global Routingは、リクエスト全体をどのように後続処理へ送るかを決めます。Configは現在のルールに基づいて判定し、Proxyは選択中のサーバーを経由する経路の確認に使い、Directはプロキシを使わない場合のアクセス状況を確認します。これらは短時間の比較テストに使うもので、万能な修復手段ではありません。テスト後は必要な状態に戻し、意図したConfigが現在有効になっていることを確認してください。ファイル一覧にConfigが存在するだけでは、実際に有効かどうかは分かりません。

Proxyでは正常でConfigでは失敗する場合は、失敗したリクエストにどのルールが適用され、最終的にどのポリシーが使われたかを確認します。広範囲に一致するDOMAIN-KEYWORD、早い位置にあるREJECT、想定外のDIRECTなどがリクエストの経路を変える可能性があります。ルールは通常、上から順に判定されます。実際に一致した行を特定し、その前により広い条件がないか確認してください。正しいルールをConfigの末尾に追加するだけでは、前のルールが先に一致している場合、問題は解決しません。

既存のConfigを上書きせず、最小限のルールで判定を確認する

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

ここに記載したexample.comは構文の説明用であり、接続テスト用のサービスではありません。DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。GEOIPはIPアドレスの地域情報に基づいて判定します。FINALは、それまでのルールに一致しなかったリクエストに適用する最終ポリシーです。試す場合は、既存のConfigを複製して別のテストファイルとして保存し、元のファイルを残してください。この3行だけであらゆる状況に対応できるわけではありません。DNS、ポリシー、その他必要な設定も一緒に削除しないでください。

ProxyとConfigのどちらも失敗し、Directでは正常な場合は、サーバー設定、接続先の状態、プロキシ経由のDNSを確認します。特定のアプリだけで失敗する場合は、独自の接続方式を使っていないか、古いセッションが残っていないか、システムでモバイルデータ通信が許可されているかを調べてください。必要に応じてアプリを完全に終了してから開き直し、新しい接続でテストします。対象アプリの再起動とVPNセッションの再確立は別々に行い、どの操作で結果が変わったかを確認してください。

REJECTに一致した場合は、まずそのドメインの用途を確認し、疑わしいルールだけを一時的に無効にして再テストしてください。ブロックルールをすべて削除する必要はありません。1つのページが複数のドメインに依存していると、そのうち1つのリクエストが拒否されただけで、一部が表示されなかったりログインに失敗したりすることがあります。詳しくはREJECTルールの設定と適用範囲をご覧ください。どの状態でも失敗し、ネットワーク自体は正常な場合は、失敗した時刻とエラーの種類を記録し、次の章へ進んでください。

03 / SERVER PARAMETERS

接続タイムアウトとプロトコルのハンドシェイク失敗

まずテスト結果を段階ごとに捉える

Connectivity Testやサーバーの遅延テストで分かるのは、その時点のネットワークで特定のテスト方法が完了したかどうかです。ブラウザーからのすべてのリクエストが正常とは限りません。テスト失敗には、サーバーアドレスの名前解決、ポートへの接続、プロトコルのハンドシェイク、テスト先などが関係する場合があります。テストに成功しても、すべての接続先にアクセスできるとは限りません。まず使用したテスト方法を記録し、実際に失敗するページも開いて確認します。比較には同じ方法を使い、異なるテストで得た数値をそのまま比べないでください。

サーバーアドレスを確認するときは、コピー時に空白、改行、句読点が混入していないか確認してください。アドレス欄は、利用中のサービスから提供された情報と一致している必要があります。ポートも現在のプロトコルの接続先に対応していなければなりません。ドメイン名を解決できてもポートに接続できるとは限らず、ポートに接続できても認証が成功するとは限りません。複数のポートや異なる通信方式が提供されている場合は、対応関係に沿って入力してください。一方の接続先のアドレスと、別の接続先のTLSや通信設定を組み合わせないでください。

プロトコルの設定項目間の関係を確認する

TLSで証明書を検証するためのサーバー名と、実際の接続に使うアドレスは、異なる役割を担う場合があります。利用中の設定に記載された情報に従ってください。通信方式のHost、パス、その他の項目も、名称だけから推測して入力しないでください。サーバー側の設定変更後は、古いサブスクリプションの情報を読み込めても、ハンドシェイクに失敗することがあります。まず利用中のサブスクリプションを更新し、更新の成功を確認してから、更新前後の項目を比較してください。似た名前の項目から古いものを誤って選ばないように注意します。

システムの日付、時刻、タイムゾーンを確認し、可能であれば自動設定を使用してください。時刻が大きくずれていると、証明書の検証や時刻制限のある認証に影響する場合があります。証明書エラーが起きても、検証を無効にする方法を恒常的な対処にしないでください。サーバー名、デバイスの時刻、接続先の証明書の状態を確認します。検証を回避すると本当の原因を覆い隠し、設定を直したのか、エラーを無視しただけなのか判断できなくなります。正しい検証設定に戻して再テストするまで、確認は完了していません。

ネットワークを比較して接続経路を特定する

サーバーと設定を変えずに、Wi-Fiとモバイル通信でそれぞれテストします。一方のネットワークだけで失敗する場合は、そのネットワークのアクセス制限、UDPの扱い、アドレスファミリーの違いを確認してください。この結果で分かるのはネットワーク経路の範囲までで、特定の機器の故障とは限りません。1台のサーバーだけが失敗し、同じサブスクリプション内のほかのサーバーが正常なら、まず元のサービス提供元に該当する接続先の状態を確認してください。クライアントの設定すべてを作り直す必要はありません。

WireGuardでは、Peerとの通信が確立できるかと、AllowedIPsが通過させたい接続先の範囲をカバーしているかの両方を確認します。ハンドシェイクとルーティングは別の問題です。ハンドシェイクが正常でも、ルーティングが正しいとは限りません。秘密鍵と接続先の公開鍵は入れ替えられません。診断情報を共有するときも、秘密鍵を公開しないでください。各項目の意味はWireGuardの設定項目の解説をご覧ください。経路の問題を調べるために鍵を手当たり次第に変更しないでください。

確認結果は、「あるネットワークで、あるプロトコルのハンドシェイクがタイムアウトし、別のネットワークではどうなったか」のようにまとめ、確認済みの項目の種類を添えてください。認証情報全体を送る必要はありません。確認の順序を詳しく知りたい場合は接続タイムアウトの確認リストをご覧ください。短時間に何度も再試行しても接続先の状態は改善せず、異なる時刻の結果が混在するおそれがあります。再現性のある結果を記録してから次の対応を決めてください。

04 / SUBSCRIPTION UPDATE

Subscribeの読み込み失敗・更新時の不具合

取得の失敗と内容の解析失敗を区別する

サブスクリプションの更新には、URLの取得、サーバーへのリクエスト、応答の受信、内容の解析といった段階があります。「更新に失敗しました」という表示だけでは、どの段階で止まったのか分かりません。応答が届かない場合と、内容を受信しても認識できない場合では、確認方法が異なります。前者ではネットワーク、URL、認証を、後者では応答内容がShadowrocketで認識できるサブスクリプション形式かどうかを確認します。比較に使えるよう、現在利用できる項目は残してください。更新に失敗するたびにサブスクリプショングループ全体を削除すると、以前の設定と比較できなくなります。

利用中のサービス情報からサブスクリプションURL全体をコピーし直し、前後の空白、改行、クエリ部分の欠落、中国語の句読点の混入を確認します。サブスクリプションURLにはアクセス用の認証情報が含まれることがあるため、公開するスクリーンショット、チャット、診断資料に載せないでください。リクエストの構造を示す必要がある場合は、ドメイン名と項目名だけを残し、値は削除します。確認のためにURL全体を複数のWebページへ貼り付けないでください。他人に取得されると、アカウントやサービスの利用に影響するおそれがあります。

応答内容に応じて確認方法を選ぶ

認証失敗、権限不足、アクセス拒否が表示される場合は、元のサービス提供元のアカウントページでサブスクリプションの状態、URLがリセットされていないか、アクセス制限がないかを確認してください。クライアントアプリを再購入しても、接続先の認証は復旧しません。アプリの買い切り購入と接続サービスの契約は別のものです。App Storeでの購入記録と、利用中のサービスの認証情報も別々に管理されます。購入については価格と買い切りについてをご覧ください。App Storeで購入済みと表示されていても、サブスクリプションが有効とは限りません。

応答がログインページ、メンテナンスのお知らせ、その他のWebページの場合、リクエストが完了していてもサブスクリプションの更新に成功したとは限りません。クライアントが必要とするのは、ブラウザーで表示できる任意の内容ではなく、認識可能なサブスクリプションデータです。リダイレクトがある場合は、最終的な応答が想定したサービスの処理フローに含まれているか確認してください。解析エラーを直すためにURLから認証情報を手動で削除しないでください。未ログイン状態のリクエストになり、問題がさらに複雑になることがあります。

現在の接続が使えない場合、サブスクリプションのリクエストも失敗する経路に送られている可能性があります。既存の項目を残したまま、接続停止時と利用可能な接続を使った場合の更新結果を比較し、現在のConfigでサブスクリプションのドメインがどう判定されるか確認してください。すべての更新リクエストが同じ経路を通るとは限りません。また、ブラウザーでサービスのページを開けても、アプリからの更新リクエストが必ず成功するわけではありません。セッション、認証、応答内容が異なる場合があります。

更新成功後も実際の変更内容を確認する

1. 更新操作が成功したことを確認し、表示メッセージだけでなく、サブスクリプショングループに実際に追加されたサーバーも確認します。
2. 現在選択中の項目が古い接続先を指していないか確認し、必要に応じて新しい既存項目を選び直します。
3. 名前が似たサーバーがどのサブスクリプショングループに属するか確認し、残っていた別の設定を誤ってテストしないようにします。
4. 接続テストが成功してから古い項目を整理し、あとで確認できるよう設定のコピーを残します。

更新後に項目数が減っても、読み込みに失敗したとは限りません。元のサービス側で項目、アカウント権限、サブスクリプション内容が変更された可能性や、フィルター条件で一部が非表示になっている可能性があります。応答内容とグループ内の結果を比較し、元データに想定した項目が含まれているか確認してください。名前が変わってもサーバー設定がすべて変わったとは限りません。反対に、名前が同じでもアドレス、ポート、認証情報が一致しているとは限りません。表示上の違いだけでなく、各設定項目を確認してください。

手動で追加したサーバーと、サブスクリプションで管理されるサーバーは分けて考えてください。サブスクリプションの項目を直接変更しても、次回の更新でサーバー側の内容に上書きされる場合があります。一時的に設定を確認する場合は、元の値を残し、変更理由を記録してください。更新のたびに項目を手作業で変更する運用を続けないでください。接続先から誤った設定が繰り返し返される場合は、元のサービス提供元に確認します。クライアント側の一時変更は確認材料にはなりますが、サブスクリプション元の問題を修復するものではありません。

追加手順が分からない場合は、はじめ方ガイドで既存サブスクリプションの追加方法を確認してください。アカウントと購入の違いについては、よくある質問をご覧ください。まず問題が起きた段階を特定してから設定を変更すると、URL、ルール、サーバーを同時に入れ替えるより原因を判断しやすくなります。

05 / PERFORMANCE BASELINE

速度低下、読み込みの停滞、ネットワーク切り替え

速度の問題を症状ごとに分ける

「遅い」と感じる状況には、ページを開くまでの待ち時間が長い、ダウンロード速度が低い、動画が断続的に止まる、ネットワーク切り替え後に復旧まで時間がかかる、といった違いがあります。それぞれDNS、接続確立、継続的なデータ転送、セッションの再確立が関係する可能性があり、遅延の数値一つでは説明できません。どの段階で遅くなるかを記録してから、対応するテストを選びます。データ転送が始まった後の速度と、リクエスト送信前の待ち時間は分けて確認してください。解析の問題を帯域不足と取り違えるおそれがあります。

比較テストでは、デバイスの位置、接続先の内容、ネットワーク、テストする時間帯をできるだけそろえます。まず接続を停止してネットワーク自体を確認し、次に同じ利用中のサーバーでテストします。その後、利用中の別の接続先だけに切り替えて比較してください。ネットワークとプロトコルを同時に変えると、どの変更で結果が変わったのか分かりません。実際の問題に近い内容をテストしてください。短いリクエストが一度正常でも、長時間の接続や大容量データの転送で問題が起きないとは限りません。

遅延、パケット損失、スループットを分けて確認する

接続確立が速いことから分かるのは、そのテストで往復通信とハンドシェイクがスムーズだったことです。継続的なデータ転送能力が十分とは限りません。接続先の負荷、経路の混雑、接続先サービスの制限、Wi-Fiの干渉などもスループットに影響します。複数回のテストで待ち時間が大きく変わる場合は、移動中か、電波状況が変化していないか、デバイスがアクセスポイントを自動で切り替えていないか確認してください。ルーターから離れている場合、クライアントのルールより、無線の再送が増えていることを優先して調べる価値があります。

同じ経路でほかの接続先は正常なのに、特定の接続先だけ遅い場合は、その接続先への経路、コンテンツのキャッシュ、サービスの状態を確認します。ページによっては本文を表示した後に、別ドメインのリソースを読み込みます。追加のリクエストに誤ったポリシーが適用されたり、REJECTされたりすると、読み込みが続いているように見えることがあります。最後に待機または失敗したドメインをリクエスト記録で確認し、接続全体の速度不足と決めつけないでください。ルールの適用先を比較したら、同じページを再度テストします。

Config内のルールによってリクエストごとに異なるポリシーが適用されるため、同じデバイスでもアプリによって使用感が異なる場合があります。ProxyとConfigを短時間比較し、ルールによる経路の違いかどうか確認できます。テスト後は必要な設定状態に戻してください。Proxyで改善する場合は、一致したルールを特定します。Proxyをすべての状況で使う設定として固定しないでください。どちらの状態でも遅い場合はサーバーとネットワークの比較に戻し、ルールを次々に増やさないようにします。

MTUと長時間接続の設定は、根拠がある場合にだけ変更する

小さなリクエストは正常なのに大きなデータ転送が止まる場合や、特定のネットワークで特定のプロトコルの停止が続く場合は、MTUや経路に関する問題を確認します。MTUは一度に扱えるパケットのサイズに影響します。数値を大きくすれば速くなる、小さくすれば安定するというものではありません。まず、既存の設定で指定されている値またはアプリの標準動作を使用してください。試す場合は一度に一つの値だけを変更し、変更前後の状態を記録します。適切な値はプロトコルやネットワークによって異なるため、すべての項目に同じ値を設定しないでください。

Wi-Fiからモバイル通信へ切り替えると、以前の接続が使えなくなり、セッションの再確立が必要になる場合があります。切り替え後に既存のページだけが停止し、新しく開いたリクエストは正常なら、まず対象アプリの接続を更新してください。新しいリクエストもすべて失敗する場合は、Shadowrocketのセッションを再確立します。On Demandは自動復旧のタイミングに影響することがあるため、まず手動接続を確認してから自動接続の条件を調べます。切り替え前後のネットワークを記録し、短時間に何度も切り替えないようにしてください。

テスト中は、ほかの大容量通信、システムバックアップ、アプリのアップデートを控え、結果を比較しやすくします。低データモード、対象アプリの通信設定、デバイスの温度も確認してください。これらはアプリの動作に影響する場合があります。デバイスが熱くなっている場合は、通常の動作状態に戻ってから継続的なデータ転送をテストします。速度を調べるために診断項目や自動テストを増やし続けないでください。追加の処理がネットワークやバッテリー消費に影響し、元の症状が分かりにくくなることがあります。

新しいドメインへの初回アクセスだけが遅い場合は、DNSの章を確認してください。再接続が頻発する場合は、接続タイムアウトの章に戻ります。同じ条件で複数回比較しても特定の接続先だけで問題が起きる場合は、機密情報を削除し、発生時刻、接続先の種類、再現条件を元のサービス提供元に伝えて確認してください。クライアントの設定を手当たり次第に変更しないでください。

06 / NAME RESOLUTION

DNSの名前解決失敗とドメインへのアクセス異常

名前解決、接続、暗号化の検証は別の段階

ドメインにアクセスするには、通常、まず接続先のアドレスを取得し、次に接続を確立してから、上位プロトコルで通信します。ページが開かない原因はどの段階にもあり、DNSはその一つにすぎません。記録に名前解決のタイムアウト、利用可能なアドレスがない、異常な解決結果が明確に示されている場合に、この章の確認に進みます。WebページのドメインをIPアドレスに置き換える方法は、一般的なテストとして適切ではありません。HTTPSでは証明書のドメイン名や、サーバーがドメインに応じてコンテンツを選ぶ仕組みも関係するため、置き換え後のエラーが元の問題と無関係な場合があります。

まず、すべての新しいドメインで失敗するのか、特定のドメインだけか、Configの状態でだけ起きるのかを確認します。以前アクセスした接続先はキャッシュを使っている場合があり、短時間に開き直すだけでは名前解決が常に正常とは判断できません。同じドメインを繰り返しテストするときは、アプリとシステムがそれぞれキャッシュを保持する可能性があります。セッションを再確立しても、すべての階層のキャッシュが消えるとは限りません。ページの再読み込み速度だけで判断せず、実際のリクエスト記録も確認してください。

現在の経路からリゾルバーにアクセスできるか確認する

現在のConfigでDNS関連の設定を確認し、どの設定ファイルに由来するかも調べます。サブスクリプションのサーバー情報とConfig内の名前解決設定は、同時に更新されるとは限りません。サブスクリプションだけを更新しても、DNSの設定が変わるとは限りません。カスタムリゾルバーを使用する場合は、現在のネットワークとポリシーでアクセスできることを確認します。暗号化DNSでは、リゾルバーのドメイン名の初回名前解決、TLS検証、リクエストの経路も関係する場合があります。アドレスが正しく見えるだけで利用可能と決めつけないでください。

カスタムDNSを無効にすると復旧する場合、問題がカスタムの名前解決経路にある可能性はありますが、リゾルバーのサービス自体に障害があるとは限りません。異なるネットワークからそのリゾルバーに到達できるか、リクエストが誤ったポリシーで振り分けられていないか、現在のConfig内のほかの項目と設定が合っているかを続けて確認します。まず確認済みの設定に戻し、その後カスタム設定を一つずつ追加してください。出所の分からないアドレスを一度に複数入力すると、どの順序で失敗し、実際にどの設定が使われたか追跡しにくくなります。

ドメインルールとアドレスルールの違いを確認する

ドメインルールとアドレスルールでは、判定に使う情報が異なります。アドレスルールの動作は、名前解決が行われるかどうかや関連オプションの影響を受けることもあります。各リクエストが同じ手順で判定されると仮定せず、実際に使われたドメイン、アドレス、一致した行を確認してください。同じドメインから複数のアドレスが返され、その一部の経路に到達できない場合は、断続的に成功することがあります。名前解決の結果と接続失敗を対応づけ、一度の成功だけを記録として残さないでください。

IPv4とIPv6では到達性が異なる場合があります。ネットワークがIPv6に対応していても、現在のサーバー、接続先、途中のすべての経路がIPv6通信に対応しているとは限りません。アドレスファミリーに関連する問題なら、ほかの条件を変えずに、名前解決の結果と実際の接続状況を比較してください。根拠なく一方のアドレスファミリーを無効にし、恒久的な対処にしないでください。変更後に復旧した場合も、どの経路が改善し、以前使えていたほかの接続に影響がないか記録します。

ローカルネットワーク上の名前解決とルールの適用範囲

家庭や職場のネットワーク内にあるデバイス名は、ローカルの名前解決や検出機能に依存することがあります。すべてのDNSリクエストを外部のリゾルバーに送ると、そのリゾルバーではLAN内だけで使われる名前を解決できない場合があります。外部のWebページは開けるのにLAN内のデバイスへアクセスできない場合は、ローカルネットワークへのアクセス許可、LAN内の経路、該当ドメインの処理方法を確認してください。外部リゾルバーを次々に変更する必要はありません。LAN内の名前を解決できるかと、デバイスのアドレスへのアクセスが許可されているかは、個別に確認します。

修正後は、以前失敗したドメイン、新しく開始した接続、対象アプリでそれぞれ確認し、一時的に無効にした診断設定を元に戻します。ブラウザーだけが復旧し、ほかのアプリでは失敗が続く場合は、古いセッションが残っていないか、独自の名前解決を行っていないか確認します。DNSの変更ですべての接続エラーを解決できるわけではありません。名前解決が正常と分かったら、ポート、TLS、ポリシーの確認へ進み、キャッシュの削除を繰り返さないでください。

07 / ENERGY AND LIFECYCLE

バッテリー消費、発熱、再接続の繰り返し

同じ使用条件で変化を比較する

バッテリー消費の異常は、実際の使用状況と合わせて確認します。継続的なデータ通信、モバイル通信の電波が弱い場所、頻繁なネットワーク切り替え、動画再生、画面の点灯などは、同時に消費電力を増やすことがあります。システムのバッテリー画面に表示されるのは、特定の集計期間の使用状況です。あるアプリの割合が高いからといって、そのアプリだけが消費を増やしたとは限りません。まず同程度の時間、同じネットワーク、似た操作で比較してから、Shadowrocketの接続や設定の変更が関係するか判断します。

異常が始まる前に変更した設定を記録します。たとえば、On Demandの条件追加、詳細な診断の有効化、別の既存サーバーへの切り替え、新しいConfigの読み込みなどです。設定は一度に一つだけ以前の状態に戻し、十分な時間を置いて確認します。数分間の静置だけで一日のバッテリー状態を判断しないでください。また、充電しながら大量のデータを転送した状態と、充電せず軽く使った状態を比較しないでください。条件が大きく異なると、数値の変化を説明できません。

再接続の繰り返しと失敗するリクエストを確認する

接続の確立と切断が繰り返されると、ネットワークの動作が増えます。まずVPNセッションが安定しているか、画面ロック後、Wi-Fiの圏外、電波が弱くなったときに異常が集中するか確認してください。サーバー設定の誤りで接続失敗が続いている場合は、まず接続の問題を解決します。診断表示を減らして表面的な症状だけを処理しないでください。同じアプリが失敗するリクエストを何度も再試行していると、動作が増える場合があります。リクエストを送っているアプリと失敗の理由も確認してください。

On Demandは接続を開始する仕組みであり、接続後にリクエストへ適用されるルールとは別の階層です。実際の使い方に合わない条件が設定されていると、必要のないときにセッションが頻繁に確立されたり、ネットワーク切り替え後に再接続を繰り返したりする場合があります。まずOn Demandを無効にし、手動接続の安定性を確認してから、条件を一つずつ戻します。条件を一つ追加するたびに、画面ロックやネットワーク切り替えを含む通常の使い方でテストしてください。すべての条件を同時に戻してから、原因を推測しないようにします。

診断はトラブル確認中だけ有効にする

詳細ログ、頻繁なConnectivity Test、リクエスト記録の継続的な確認は、短時間の原因特定に役立ちますが、故障が心配だからといって常時実行する必要はありません。問題を再現できる記録が得られたら、日常の利用に必要な診断レベルに戻してください。ログには接続先のドメイン、アドレス、利用時刻が含まれる場合があります。保存や共有は必要最小限にしてください。追加の診断を無効にした後も同じ条件で再テストし、実際の通信を大量に止めたことだけが改善の理由ではないか確認します。

Configに頻繁に実行される自動処理や外部リソースに依存する処理がある場合は、繰り返し失敗していないか、本当に必要かを確認します。Configのコピーを作って比較し、追加した部分だけを一時的に無効にして、接続と基本のルールは残してください。Config全体を消去して消費が減ったからといって、特定のルールが原因とは限りません。通信経路や使い方も変わる可能性があります。一つの要素まで範囲を絞り、その要素を元に戻すと同じ症状が再現することを確認してください。

アイドル接続と実際のデータ通信を区別する

VPNの表示が続いていても、デバイスが常に同じ負荷で動作しているとは限りません。接続を維持しているだけの状態と大量のデータを処理する状態では、消費電力が異なります。バックグラウンドの同期で、操作していないように見えるデバイスが通信を続ける場合もあります。画面ロック後も発熱が続く場合は、まずシステムのバッテリー表示とネットワークの動作を確認し、不要なバックグラウンド処理を一つずつ停止してください。確認のために画面を何度も点灯したり、テストページを再読み込みしたりすると、普段と同じアイドル状態にならないことがあります。

プロトコル、ネットワーク、サーバー経路の組み合わせが消費電力に影響する場合はありますが、プロトコル名だけで一律に判断できません。接続先とほかの設定をできるだけそろえた比較に意味があります。利用中の別の接続先では、サーバーの場所、負荷、通信設定も異なることがよくあります。まず再接続、失敗するリクエスト、電波の弱さなど、確認できる原因に対処してください。原因を特定する前に、バックグラウンド接続をすべて無効にすると、通知や同期に影響するおそれがあります。

役立つバッテリー消費の記録には、観察時間、画面の使用状況、ネットワークの種類、充電中かどうか、On Demandの状態、接続が再確立されたかを含めます。アップデートや機種変更後に発生した場合は、これらの条件を記録して次の章へ進んでください。システムによる消費電力の推定には集計上の限界があります。バッテリー画面のスクリーンショット1枚では再現可能な比較の代わりにならず、一定の消費電力を保証する根拠にもなりません。

08 / RECOVERY AND IPAD

アップデート後の不具合とiPadでの確認

アップデート後は設定を残し、セッションを再確立する

システムやアプリのアップデート後に不具合が起きたら、まず最初に問題を確認したときの状況を記録し、アップデートですべての設定が変わったと決めつけないでください。接続先のサービス、現在のネットワーク、サブスクリプション内容が同時期に変わった可能性もあります。まず以前のセッションを終了してアプリを開き直し、接続を確立してください。問題が続く場合は、選択中のサーバー、Global Routing、現在のConfigを確認します。アップデート前に使えていたConfigのコピーを残しておくと、選択状態と設定内容の違いを確認しやすくなります。

復旧の手順は、ネットワークが正常か確認し、現在の選択項目を確認し、On Demandを一時的に無効にして手動で再接続し、このページの該当する章に沿ってエラーを確認する、という順番で進められます。デバイスの再起動は一時的な状態の解消に役立ちますが、設定の確認に代わるものではありません。再起動後に一時的にしか復旧しない場合は、再び失敗するまでに画面ロック、ネットワーク切り替え、サブスクリプションの更新など何が起きたかを記録してください。復旧までの時間やきっかけは、単に「再起動しても直らない」と記録するより原因の範囲を絞るのに役立ちます。

アプリのアップデートと再入手は、いずれもApp Storeから行います。システム要件はApp Storeの掲載内容をご確認ください。購入内容の確認と復元については、購入済みアイテムの復元方法をご覧ください。再インストールする前に、ローカルのサーバー情報、Config、必要な記録を保存し、利用中のサービス情報を再取得できることを確認してください。アプリの購入記録はローカル設定のバックアップではありません。購入済みアプリを復元しても、カスタム設定がすべて元の状態に戻るとは限りません。

iPadでは選択状態とネットワークの許可を確認する

iPadでは、同じ既存サブスクリプションを使っていても、選択中のサーバーとConfigを個別に確認してください。iPhoneで正常だからといって、2台の状態が同じとは限りません。大きな画面では一覧と詳細が同時に表示される場合があります。項目の詳細を表示しただけでは、現在の接続に使う項目として選択されているとは限りません。Homeに戻って実際の選択状態を確認し、新しいセッションで接続します。画面に表示されている内容を確認し、一覧上の位置や以前開いた詳細画面から接続先を推測しないでください。

iPadが現在Wi-Fiとモバイル通信のどちらを使っているか確認します。デバイスによって接続経路が異なる場合があります。モバイル通信に対応したデバイスでは、アプリによるモバイルデータ通信がシステムで許可されているかも確認してください。LAN内のデバイスへのアクセスだけ失敗する場合は、ローカルネットワークへのアクセス許可と該当ルールを調べます。iPhoneとiPadを比較するときは、同じネットワークに接続し、同じ設定、同じ接続先を使ってください。条件がそろっていないと、デバイスとネットワークの違いが混在し、アプリの問題とは判断できません。

画面ロック、マルチタスク、設定の移行

マルチタスクや画面分割中にアプリが前面に表示されているかどうかと、システムのVPNセッションが維持されているかどうかは別の問題です。ウインドウが更新されるかだけで判断せず、システムの状態と新しいリクエストの結果を確認してください。画面ロック後に復帰できない場合は、アプリ内の既存接続と新たに開始したリクエストを別々にテストします。既存接続だけが失敗するなら、まず対象アプリの接続を更新してください。すべてのリクエストが失敗する場合はVPNを再確立します。これにより、アプリのセッションの問題をデバイス全体の接続停止と取り違えずに済みます。

設定を移行するときは、サーバー情報、Config、システムのVPN認証を分けて扱います。前の2項目では読み込んだ内容と選択状態を確認し、VPN認証は通常、新しいデバイスで再度許可する必要があります。認証情報を含む設定は、ご自身が管理する安全な方法で保管し、一般的な例として公開しないでください。移行後は、まず既存サーバーの一つで接続を確認し、次にルールと自動接続を確認してから、ほかのカスタム設定を戻します。すべてを一度に読み込むと、原因を特定しにくくなります。

引き継ぎ可能なトラブル記録を作成する

同じ設定を使っていて、一方のデバイスでは正常、もう一方では異常な場合は、システムの権限、ネットワーク、時刻、アプリ設定、実際のリクエスト記録を項目ごとに比較してください。システムのネットワーク設定全体をそのままコピーしたり、今回の問題に関係のない管理設定を削除したりしないでください。iPadでの入手方法と初回起動についてはiPadのガイドをご覧ください。機種変更後に購入済みアプリを復元する手順は、機種変更後にアプリを復元する方法もご参照ください。

最後に、同じ問題を再現できる最短の手順としてまとめます。使用したネットワーク、選択した状態、実行した操作、発生したエラー、正常だった比較結果、直近で変更した項目を記載してください。個人情報を削除したエラーの種類と発生時刻を添えれば十分で、過去の記録をすべて送る必要はありません。復旧後に同じ症状が再発した場合は、確認済みの順序で調べ直します。症状が変わった場合は、該当する章に戻って基準となる状態を確認してください。一度有効だった対処法が常に適用できるとは限りません。