Shadowrocket
トラブル対処ガイド

01 接続スイッチがオンにならない：まずシステム権限を確認

対象となる症状：Homeで接続スイッチをオンにしてもすぐ戻る、VPN構成の追加を何度も求められる、接続中と表示されても安定しない。こうした場合は、ルールを変更したり、すぐにサーバーの問題と決めつけたりしないでください。スイッチがオンの状態を維持できるかどうかは、ネットワーク拡張機能の利用がシステムで許可されているか、現在の構成が有効か、別の接続タスクが同じシステムの接続経路を使用していないかによって決まります。

スイッチが戻る前後の状況を記録する

まず、デバイスの機種、接続中のネットワーク、選択したサーバー、Global Routingの状態を記録してから、接続を一度試してください。システムの確認画面が表示されたか、デバイス認証が完了したか、何秒後にスイッチが戻ったか、画面にエラーが表示されたかを確認します。何度も素早く切り替えるより、1回の接続を最後まで観察するほうが有効です。前の接続が終了する前に次の接続を始めると、実際に失敗した段階が待機状態に隠れてしまうことがあります。

接続を切り、普段そのまま開けるページにブラウザからアクセスして、Wi-Fiまたはモバイル通信が利用可能か確認してください。Wi-FiでWeb認証が必要な場合は、先に認証を済ませてからテストします。Wi-Fiの電波が表示されていても、インターネットに接続できるとは限りません。ネットワーク認証が完了していないと、サブスクリプションの取得、サーバーとのハンドシェイク、通常のWeb閲覧がすべて失敗し、接続スイッチの不具合と誤解することがあります。

VPN構成の許可とシステムの状態を確認

初回接続時にVPN構成の追加を求められるのは、ネットワーク設定の変更を許可するためのシステム手順です。要求元がShadowrocketであることを確認し、システムの案内に従って許可してください。その後、システム設定でVPNを検索し、該当する構成と状態を確認します。メニューの階層はシステムによって異なるため、デバイスの画面表示を確認してください。画面上部のステータスアイコンだけで判断しないでください。デバイスや表示状況によっては、常に同じアイコンが表示されるとは限りません。

以前に許可を拒否した場合は、アプリから再度接続し、システムがもう一度確認を求めるか見てください。該当する構成を手動で削除した場合も、似た名前のシステム構成を自分で作成するのではなく、アプリから再作成してください。構成が残っているのにエラーが繰り返される場合は、アプリ内のサーバー情報とConfigを保存してから、Shadowrocket専用のシステムVPN構成だけを削除し、再度許可する方法を検討します。管理者が設定した構成など、所属が確認できないものは削除しないでください。

管理対象デバイスでは権限の範囲を確認

学校や職場の管理対象デバイスでは、VPN構成の変更が制限されている場合があります。システムに管理上の制限が明示されている場合は、デバイス管理者にポリシーを確認してください。制限を回避するために構成を何度も作り直さないでください。

接続の競合を除外し、最小限の条件でテスト

システムにほかの有効なVPN構成がないか、ネットワーク拡張機能によるフィルタリングが動作していないか確認します。内容を理解していて、一時停止しても問題のない機能だけを一時停止してからShadowrocketをテストしてください。これは接続経路の競合を調べるための手順であり、これらの機能に互換性がないと断定するものではありません。一時停止後に改善した場合は、機能を一つずつ再度有効にしてテストし、どの組み合わせで問題が起きるかを特定します。すべての保護機能を恒久的に無効にしないでください。

次に、Homeで有効なサーバーが選択されているか確認します。リストに項目があるだけでは不十分です。サービス提供元から現在提示されている情報を使い、利用権限があり必要な情報がそろったサーバーを一つ選び、On Demandを一時的にオフにして手動接続します。スイッチがオンのままでもページを開けない場合は、問題はデータ通信の段階にあります。次の章に進み、システム構成を削除し続けないでください。

アプリが応答しない場合は、通常の方法で終了してから再度開き、同じ手順でテストしてください。それでも接続できない場合は、デバイスを再起動します。再起動は一時的なシステム状態をリセットするためのもので、誤ったパスワード、無効なサブスクリプション、サーバー側の障害は修正できません。アプリを開き直した後は、選択中の項目が変わっていないことを確認し、次の操作に進む前に接続処理が終了するまで待ってください。バックグラウンドで未完了の処理を新たな障害と誤認するのを防げます。

解決したかを確認する

接続スイッチがオンの状態を保ち、システムで該当するVPNが接続済みと表示され、テストリクエストが完了すれば、この手順は解決です。それでもスイッチが戻る場合は、エラーの全文と発生した段階を記録し、VPN構成の追加画面についてを確認してください。問い合わせ時は必要なデバイス情報とエラー情報のみを伝え、パスワード、サブスクリプションの完全なURL、QRコード、アカウント情報を含む構成は送らないでください。

02 接続済みなのにインターネットに接続できない：ルーティングと出口を切り分ける

接続スイッチがオンの状態を保っていても、システムのトンネルが確立していることを示すだけで、すべてのリクエストに利用可能な出口があるとは限りません。問題を3段階に分けて確認します。デバイスの通常のネットワークでアクセスできるか、選択したサーバーが通信を転送できるか、現在のConfigがリクエストを想定したポリシーに振り分けているかです。まず現在の設定のコピーと選択中の項目を保存し、決めたテストページで比較してください。サーバー、DNS、ルールを同時に変更すると、復旧しても原因を特定できません。

Global Routingで短時間の比較テストを行う

Global RoutingのConfig、Proxy、Directは、それぞれ設定に従う接続、プロキシ接続、直接接続を表します。問題の切り分けには使えますが、どれでもよい「修復ボタン」ではありません。テスト前に目的を決めてください。Directは通常のネットワーク経路、Proxyは選択中のプロキシ経路、Configはルールによる振り分けを確認します。同じリクエストを短時間だけ比較し、終了したら必要なConfigに戻してください。

Directでも普段開けるページにアクセスできない場合は、接続を切り、Wi-Fiの認証、モバイルデータ通信の権限、現在のネットワーク状態を確認してください。Directでは正常でProxyでは失敗する場合は、サーバー情報と到達性を優先して確認します。Proxyでは正常でConfigでは失敗する場合は、適用されたルール、ポリシー名、Config内のDNS設定を確認してください。これらの判断は今回のテスト対象に限られます。1つのWebサイトの結果をすべてのアプリに当てはめないでください。

ルールは上から順に適用され、「より具体的に見える順」ではありません

通常、ルールは上から順に確認され、先に一致したルールが適用されると、後続のルールが同じリクエストのポリシーを再度決めることはありません。広い範囲に一致するDOMAIN-KEYWORDが上にあると、後ろの正確なドメイン指定より先に適用される場合があります。FINALは、前のルールに一致しなかった場合のフォールバックとして使います。接続ログで対象とポリシーを確認してからConfigの順序を見直してください。該当ルールが存在するか検索するだけでは不十分です。

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

上記はルールの構文と順序を示す例であり、現在の設定にそのまま適用できる完全なConfigではありません。PROXYは、現在のConfigと選択中のサーバーの使い方に対応している必要があります。カスタムポリシー名も、実際に定義されていなければなりません。example.comは説明用のドメインであり、特定のサービスに推奨するポリシーを示すものではありません。例をコピーする前に、どのリクエストが変わるかを確認してください。特に、見慣れない設定で使用中のConfig全体を上書きしないでください。

ルールを一つだけ変更し、新しい接続で確認

特定のドメインだけで問題が起きる場合は、ログイン、静的リソース、メディア用のサブドメインも必要か確認してください。メインのドメインが想定どおりに振り分けられていても、すべてのリソースが同じポリシーを使うとは限りません。接続ログから失敗した対象を見つけ、確認できたドメインだけを最小限変更します。変更後はリクエストを再実行してください。すでに確立した長時間接続は以前の経路を使い続ける場合があるため、古い接続の状態だけで新しいルールの適用を判断しないでください。

ローカルネットワークのデバイスにアクセスする場合は、デバイスのアドレスと現在のWi-Fiが同じ到達可能な範囲にあるかも確認してください。Configにプライベートアドレス向けのDIRECTルールがあっても、ゲストネットワークからほかのデバイスに接続できるとは限らず、モバイル通信から自宅のアドレスに到達できるとも限りません。まずローカルネットワークの基本的な接続を確認してから、ルールを調べます。すべての通信をProxyに切り替えても、ローカルネットワークの分離は解決しないことが多く、切り分けが難しくなる場合があります。

元に戻す条件も明確にする

問題のあるルールが見つかったら、変更前後の順序と、ルールが適用されたときの記録を残してください。Configを元に戻し、Webページ、ログイン、必要なローカルネットワークへのアクセスを再テストします。1つのページだけ直し、ほかの通信経路を変えてしまわないようにしてください。

ルールを調整しても失敗し、同じ対象がProxyでは正常な場合は、Configの名前解決とポリシー参照も確認してください。用語の意味は用語集、Global Routingの選び方は使い方ガイドをご覧ください。記録を取らずにルールを次々と追加しないでください。重複した項目や互いに上書きし合う項目が増えると、その後のトラブル対処で再現が難しくなります。

03 サーバーがタイムアウトする：到達性、ハンドシェイク、設定を切り分ける

タイムアウトは、待機時間内にある段階で期待した応答が得られなかったことを示します。サーバーが停止していると確定したわけではありません。ドメインの名前解決、接続の確立、プロトコルのハンドシェイク、接続先への転送のいずれかで止まっている可能性があります。まず、1台だけでタイムアウトするのか、サブスクリプション内の複数のサーバーで起きるのか、特定の接続先だけで起きるのかを確認します。問題の範囲が分かれば、デバイスのネットワーク、サービス提供元の情報、アプリの設定のどれを調べるべきか判断できます。

テストで何を測っているかを確認

Connectivity Testの結果は、テスト方法、接続先、ネットワーク環境によって変わります。ある方法でのテストが失敗しても、実際のWebアクセスが失敗するとは限りません。テストが成功しても、ログイン、動画再生、継続的な通信が正常とは限りません。テスト方法と接続先を確認したうえで、実際のサービスへのリクエストも試してください。リストに表示された一つの数値だけを見てサーバーを何度も切り替えたり、異なる方法の結果をそのまま比べたりしないでください。

テスト中はネットワーク、接続先、選択中のサーバーを固定し、前のテストが終わるまで待ちます。その後、Wi-Fiとモバイル通信だけを切り替えて再度試してください。モバイル通信を使えないiPadでは、ご自身が信頼できる別のネットワークを使えます。特定のネットワークだけで失敗する場合は、そのネットワークのルーティング、ポートへの到達性、プロトコルの条件を調べます。すぐにサーバーのパスワードを変更しないでください。すべてのネットワークで失敗する場合は、サーバー情報を再確認します。

プロトコルごとの必須項目を確認

Add Serverまたは対象サーバーの編集画面を開き、サービス提供元から受け取った情報と照合しながら、アドレス、ポート、プロトコルの種類、認証情報、転送パラメータを一つずつ確認してください。前後に余分な空白があるアドレス、誤ったポート、不完全にコピーされた識別子は、待ち状態やハンドシェイクの失敗につながることがあります。表示名が同じだからといって、各項目の確認を省略しないでください。表示名は識別用であり、接続パラメータが正しいことを証明するものではありません。

転送方式、Host、パス、サーバー名は互いに置き換えられる項目ではありません。サーバー側で特定の転送設定が使われている場合、クライアント側もそれに合わせる必要があります。TLSエラーが出ても、サーバー名を適当に変更しないでください。また、共有リンクに見慣れない項目が含まれていても、すべて削除しないでください。まずサービス提供元が現在案内している情報を再読み込みし、手動で追加した項目と比較します。差異を後から確認できるよう、古い項目も残してください。

TLSエラーとタイムアウトは分けて対処する

ログに証明書、サーバー名、時刻に関するエラーが明記されている場合は、まずデバイスの日付と時刻が正しいか確認し、サーバー名がサーバー側の指定と一致しているか調べます。証明書の検証失敗は通常の速度低下とは異なります。証明書の検証を無効にしても、一般的な解決策にはなりません。証明書の期限切れや設定の不一致はサーバー管理者が修正する必要があります。設定ミスを隠すために検証条件を緩めず、クライアント側では検証を維持してください。

以前は使えていたサーバーで、現在すべてのリクエストが失敗する場合は、サービス提供元でのアカウントの有効状態、サーバーの変更通知、現在の接続情報を確認してください。アプリを購入しても、リモートサービスが継続して利用できるとは限りません。サブスクリプションを更新しても、リモート側の問題が解消するとは限りません。サービス提供元に連絡する際は、「タイムアウト」とだけ伝えるより、発生時刻、ネットワークの種類、プロトコル、機密情報を伏せたエラー文を伝えると、ポート、認証、上流側の問題を判断しやすくなります。

手当たり次第に切り替えず、別の項目で問題の範囲を確認

ご自身が持つ情報の中に、動作確認済みの別の項目がある場合だけ、それを比較に使ってください。比較用の項目が正常で元の項目だけ失敗する場合は、元のサーバーを優先して調べます。すべて失敗する場合は、システム権限、基本的なネットワーク、DNSを確認してください。比較用の項目がなくても、ネットワークを切り替え、エラーが発生した段階を確認することで範囲を絞れます。診断のために、出所の分からない項目や公開された設定を一時的に読み込む必要はありません。

解決したら、接続の確立、接続先の表示、短時間の継続通信を続けて確認してください。テストが一度成功しただけでは、その時点で特定のテスト経路が使えたことしか分かりません。接続直後に切れる場合は、アイドル時、ネットワーク切り替え時、通信開始後のどのタイミングで切れたかを記録してください。接続の維持、ネットワーク切り替え、通信経路のどの問題か判断し、速度低下と接続の途切れの章に進みます。

04 サブスクリプションの更新に失敗する：取得、解析、読み込みを分けて確認

サブスクリプションの更新は、リモートから内容を取得し、項目として解析する処理です。サーバーに接続できるかを測るテストではありません。更新に失敗しても、すでに登録済みのサーバーは使える場合があります。更新に成功しても、認証、ネットワーク、リモート側の状態によって新しいサーバーに接続できない場合があります。内容の取得、形式の認識、項目の保存のどの段階で失敗したかを確認してから、アドレスを変更するか判断してください。サブスクリプションのアドレスはご自身のサービス提供元から入手してください。このサイトでは読み込みと設定方法を解説します。

現在使えている項目を先に保護

操作前に、サブスクリプション名、現在の項目数、選択中の項目、直近のエラー文を記録してください。現在の項目が使える場合は、サブスクリプションのグループ全体をすぐに削除したり、確認前に古いリンクを上書きしたりしないでください。元の情報を安全に保存したうえで比較用の項目を新しく追加し、新しいリンクが正しく読み込まれることを確認してから、古い項目を整理できます。グループを削除すると、項目や関連する選択状態も一緒に失われ、元の状態に戻せなくなることがあります。

単一サーバーの共有リンクとSubscribeで使うサブスクリプションアドレスを区別してください。単一サーバーのリンクは1台分の情報を示し、サブスクリプションアドレスは通常、更新可能な複数の項目を取得するために使います。異なる種類の情報をもう一方の読み込み画面に入力すると、リストが空になったり解析できなかったりすることがあります。コピー時に、チャットの説明文、改行、句読点、ページタイトルが混ざっていないか確認してください。アドレスのクエリ部分を独断で削除しないでください。アカウントの識別や形式の選択に使われている可能性があります。

サブスクリプションの内容を実際に取得できたか確認

アドレスが存在していても、正しい内容を取得できるとは限りません。サーバーからクライアントが解析できるデータではなく、アカウントの期限切れ案内、ログインページ、メンテナンスページ、エラー応答が返されることがあります。状態を示すメッセージが表示される場合は、サービス提供元の案内に従ってアカウントの有効性を確認してください。ログインフォームを含むWebページをサーバー設定と見なさないでください。プロトコルの種類を何度も変更して、サブスクリプションではないデータを解析しようとしないでください。

取得に失敗する原因は、現在のリクエスト経路にもあるかもしれません。サブスクリプションの更新に使うネットワーク経路は、特定のWebページを開く経路と異なる場合があります。まず通常のネットワークが利用できる状態で手動更新し、エラーを確認してください。その後、サービス提供元の案内に従い、利用可能な既存の接続を使う必要があるかを確認します。サブスクリプションを取得するために、すべての通信を別の接続モードに切り替えたままにしないでください。比較が終わったら元の設定に戻し、どの条件で取得できたかを記録します。

サブスクリプションアドレスは認証情報として保護

アドレス全体、QRコード、書き出した項目には認証情報が含まれることがあります。公開コメント、見知らぬ解析サイト、公開スクリーンショットに貼り付けないでください。問い合わせ時はエラーの種類と、機密情報を隠した必要最低限の項目だけを伝えてください。

更新は成功したが、リストが空または項目が不足

内容を取得したと表示されても、想定した項目が表示されない場合は、サービス提供元が案内する形式がShadowrocketに対応しているか、アカウントから実際にサーバー情報が返されているかを確認してください。ほかの形式のフィールド名を見て、手作業で変換方法を推測しないでください。サブスクリプションとConfigは別の種類のリソースです。ルール設定にサーバーが含まれるとは限らず、サーバーのサブスクリプションにルール一式が含まれるとも限りません。それぞれに対応する場所から読み込んでください。

更新後に一部の項目しか表示されない場合は、名前によるフィルタが有効になっていないか、未対応または不完全なフィールドがないかを確認し、サービス提供元が返却内容を変更していないか調べてください。項目数が変わっただけでは、クライアント側でデータが失われたとは限りません。元のサブスクリプションの案内と更新後の名前を比べ、サーバー名やグループが変更されたか確認します。数を合わせるために重複した項目を読み込まないでください。重複があると、その後の選択やテストに影響します。

自動更新だけに頼らず、手動更新で状況を確認

まず手動更新が安定して完了することを確認し、その後、アプリで利用できる自動更新の設定を有効にしてください。アプリを開いたときに自動更新が実行される条件は、アプリ内の説明を確認してください。デバイスがどのようなバックグラウンド状態でも更新が続くという意味ではありません。自動更新が行われない場合は、アプリを開いた時刻、そのときのネットワーク、手動更新の結果を記録します。システムがすべてのサブスクリプションへのアクセスを妨げていると、すぐに判断しないでください。

更新後は選択中のサーバーを再確認してください。項目名や識別情報が変わると、以前の選択が使えなくなる場合があります。Configで参照しているグループやポリシーとの対応も確認します。その後、実際のリクエストで動作を確認し、更新完了の表示だけで判断しないでください。詳しい操作手順と失敗時の対処はサブスクリプションの手動・自動更新について、リンク形式の違いはサーバーリンクの形式についてをご覧ください。

新しいサブスクリプションの更新に繰り返し失敗し、古い項目は使える場合は、古い項目を残したまま、アドレスがリセットされたか、アカウントが有効か、形式が変更されたかをサービス提供元に確認してください。リンクを何度もリセットすると、設定済みのほかのデバイスでも更新できなくなることがあります。最初に行うべき対処ではありません。修正後は、ご自身のほかのデバイスでも変更が必要か確認し、使わなくなった古いアドレスのコピーを整理して、混乱を防いでください。

05 速度低下と接続の途切れ：再現できる条件で比較

速度低下は、まず観察できる症状として整理します。最初のページ表示に時間がかかる、通信開始後の速度が遅い、動画が頻繁に読み込み中になる、しばらく操作しないと再接続が必要になる、などです。症状によって問題が起きている段階は異なります。接続リストに表示されるテスト時間は、継続的な通信速度や接続先の応答を示すものではありません。接続先、ネットワーク、サーバーを固定し、時間や内容が異なる体験をそのまま比べないでください。

名前解決の待ち時間、ハンドシェイクの待ち時間、通信の制限を区別

最初のアクセスが遅く、同じページを開き直すと速い場合は、ドメインの名前解決、接続の確立、キャッシュを確認してください。開始直後は速いのに大きなファイルの転送が遅い場合は、ネットワーク品質、リモート側の負荷、接続先サービスの制限を重点的に確認します。特定のアプリだけ遅い場合は、依存するドメイン、バックグラウンドでのダウンロード、想定したポリシーで通信しているかを見てください。動画が止まるからといって、すべての通信が同じ原因で制限されているとは限りません。

比較テストには、利用権限があり、繰り返しテストできるコンテンツを選びます。ファイルサイズと操作方法をできるだけそろえ、デバイスで大量の同期が行われていないか確認してください。テスト前にWi-Fiやモバイル通信の電波状況が大きく変わっていないことも確認します。速度測定を大量に連続実行しないでください。測定自体が帯域を消費し、サーバー負荷やバッテリー消費を増やすため、テスト環境に影響することがあります。説明できる少数の繰り返しテストのほうが、大量のスクリーンショットより原因の特定に役立ちます。

ネットワークとサーバーを比較し、一度に両方は変えない

まずサーバーを固定したまま、ネットワークだけを切り替えます。同じサーバーが別のネットワークで明らかに改善する場合は、元のネットワークの電波干渉、上流の混雑、特定の通信条件を優先して確認してください。次にネットワークを固定し、ご自身が利用する項目の中から動作確認済みのものだけを比較用に選びます。比較用の項目が正常なら、元のサーバーまたはその出口経路に問題がある可能性があります。切り替えるたびに接続を確立し直し、同じ接続先で再テストしてください。古い接続が結果に影響しないようにします。

Wi-Fiでは、アクセスポイントから離れていること、同じ周波数帯の干渉、ネットワーク内のほかのデバイスによる通信が不安定さの原因になることがあります。まず安定した場所に移動し、通常のネットワーク接続にも同じ問題がないか確認してから、プロキシ経路を調べてください。モバイル通信だけで失敗する場合は、アプリのモバイルデータ通信の権限と電波状況も確認します。通信事業者やネットワーク間の違いを、アプリの設定ミスと決めつけないでください。条件を記録し、関係するサービス提供元に判断を依頼します。

接続が途切れるときは、発生のきっかけを記録

しばらく操作しないと切れる、画面ロック後に切れる、ネットワーク切り替え後に切れる、という症状はそれぞれ異なります。アイドル時の切断は接続維持やサーバー側のタイムアウト、ネットワーク切り替え後の切断は古い経路の接続が再確立されていない可能性があります。画面ロック後の挙動は、アプリがバックグラウンドで処理する方法にも左右されます。すべてのアプリが失敗するのか、長時間接続だけが切れるのか記録してください。新しいページは開けるのに古いセッションだけが止まる場合は、業務側の接続を再確立し、Config全体をすぐにリセットしないでください。

UDPに依存する通信では、通常のWebページが開けても、必要な経路が正常とは限りません。特定の通話、リアルタイム通信、プロトコルだけで問題が起きる場合は、サーバーが該当する通信に対応しているか、プロトコルの設定項目がすべてそろっているか、現在のネットワークで必要な通信が許可されているか確認してください。MTUを手当たり次第に変更したり、ネット上の固定値を適用したりしないでください。実際の経路とサーバーの要件に合わせる必要があります。変更前の値を記録し、同じ通信で確認してください。

速度テストの結果は、テスト条件を反映する

テスト対象、時刻、ネットワーク、サーバーが結果を左右します。テスト時間が短くても継続的な通信が速いとは限りません。混雑時間帯に一度遅くても、デバイスの設定が恒久的に無効になったとは言えません。

接続先サービスとローカル設定の問題を区別

特定の接続先だけが遅く、同様のほかのリクエストが正常な場合は、接続先サービス自体、アカウントの状態、リソースの読み込み状況を確認してください。アプリ内ブラウザと別のブラウザでは、キャッシュ、ログイン状態、接続の再利用方法が異なる場合があります。違いだけでルールによる振り分けが原因とは判断できません。接続ログで失敗したリソースを確認し、応答待ち、再試行の繰り返し、想定外のポリシー適用のどれに当たるかを特定してから、ルールの章に戻り最小限の変更を行います。

対処後は、初回の表示、短時間の継続利用、通常どおりのネットワーク切り替え後の状態を確認してください。最も速かった一度だけを再テストして終わりにしないでください。サービス提供元に連絡する場合は、接続先の種類、ネットワークの種類、発生した時間帯、比較結果をまとめ、認証情報全体は送らないでください。速度低下と同時にデバイスの発熱やバッテリー消費の増加が見られる場合は、バックグラウンド通信、再試行の繰り返し、診断頻度を確認します。サーバーを変えるだけより、根本原因の特定に役立つことがあります。

06 DNSの問題：ドメイン、名前解決の経路、ルールを確認

DNSはドメイン名をアドレスに変換しますが、Webページが開けない原因がすべてDNSとは限りません。まず、エラーが名前解決の段階で発生したと明示されているか確認し、サーバーのドメインと接続先サイトのドメインをそれぞれ解決できるか調べます。プロキシサーバー自体のドメインを解決できない場合は、接続が確立する前に停止します。接続先のドメインを解決できない場合は、トンネルが有効になった後に問題が起きることがあります。どちらもインターネットに接続できないように見えますが、確認すべき場所は異なります。

まず失敗するドメインを確認し、すぐにDNSを変更しない

失敗した接続先とエラー文を記録し、1つのドメインだけなのか、特定のサブドメイン群なのか、すべてのドメインなのかを確認してください。1つのドメインだけで失敗する場合は、綴り、サービスの稼働状況、ログインの要否を調べます。Webサイトのトップページが開けても、すべてのリソースが正しく名前解決できるとは限りません。画像、認証、APIで異なるドメインを使う場合があります。すべてのDNS設定をすぐに変更するより、接続ログで失敗した対象を特定するほうが効果的です。

サーバーアドレスがドメイン名の場合は、期限切れや入力ミス、サービス提供元による変更がないか確認してください。名前解決で得たアドレスを、安易に固定値として設定しないでください。サーバー側で動的に振り分けていることがあり、TLSのサーバー名には元のドメインが引き続き必要な場合もあります。比較のためにアドレスを使う必要がある場合は、サービス提供元の案内に従い、サーバー名などの関連項目も維持してください。一時的なテストで証明書やルーティングの問題を新たに引き起こす可能性があります。

名前解決の設定はアクセス経路と合わせて確認

ConfigにカスタムDNS設定があるか、名前解決の動作を変える設定が読み込まれていないか、名前解決のリクエストが特定の出口を通る必要があるかを確認します。名前解決サービスに到達できなければ、設定の書式が正しくても結果は得られません。システム側にもネットワークの名前解決設定がある場合は、別々の条件として一つずつ確認してください。すべてを一度に削除しないでください。まず実際にどの層の設定が使われているかを特定し、重複や競合の有無を判断します。

暗号化された名前解決方式の中には、サーバーに到達して接続を確立する必要があるものもあります。現在のネットワークからその接続先に到達できない場合や、接続先へのアクセスに未完了の名前解決が必要な場合は、待機が連鎖することがあります。DNSアドレスをさらに追加するのではなく、現在のConfig全体の設計に戻り、初期化時の経路を確認してください。過去に動作確認済みの設定に戻すほうが、異なる場所から取得したDNS設定を混在させるより問題を特定しやすくなります。

ドメインルールとアドレスルールでは確認方法が異なる

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDはドメイン条件を参照します。一方、IP-CIDR、IP-CIDR6、GEOIPはアドレスに基づく判定に関係します。後者の結果は、アドレスがすでに取得されているか、アプリがどの種類のリクエストを行ったかによって変わる場合があります。ドメインの情報だけから、アドレスルールが必ず適用されると判断しないでください。サーバーは地域やアドレスの種類、コンテンツ配信経路に応じて異なる結果を返す場合があるため、実際の記録を確認してください。

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

ここでのno-resolveは、アドレスルールの判定のために積極的なドメイン解決を行わないことを示します。アプリ全体のDNSを無効にする意味ではありません。この例もルールの一部であり、完全なサーバーや名前解決の設定は定義していません。高速化のためにこのオプションをすべてのルールに追加しないでください。名前解決を行うかどうかで判定に使える情報が変わるため、ルールの目的とアプリが対応する構文を踏まえて使ってください。

IPv4、IPv6、キャッシュはそれぞれ別に確認

特定のネットワークでIPv6が使えても、すべてのサーバーや接続先で同じ経路が利用できるとは限りません。特定のネットワークだけで失敗する場合は、エラーが特定のアドレス種別に集中していないか、サービス提供元が現在どの方式に対応しているかを確認してください。特定のアドレス種別を恒久的に無効にするのではなく、実際に失敗している経路を特定し、設定の案内に沿って比較します。ローカルネットワークのデバイス検出やローカルドメインでは、Wi-Fiが提供する名前解決条件が必要な場合もあります。

名前解決の設定を直した後も、古いキャッシュや既存の接続がしばらく結果に影響することがあります。接続を切って再接続し、対象アプリを開き直して新しいリクエストを実行してください。必要であればキャッシュが自然に失効するまで待ちます。特定の操作であらゆる層のキャッシュが必ず消えると考えないでください。ブラウザ、システム、アプリ、リモート側のそれぞれでキャッシュされる場合があります。再テストでは、新しい接続の結果を記録し、処理中の同じリクエストを繰り返し更新しないでください。

プリンター、家庭内デバイス、内部ドメインへの接続に失敗する場合は、まず同じWi-Fiから直接アクセスできるか確認し、デバイスがローカルネットワークからの接続を許可しているか、ネットワークでクライアント間通信が制限されていないか調べてください。プライベートアドレスのルールは、ローカルドメインの名前解決の代わりにはなりません。最終確認では、サーバーのドメイン、通常の接続先ドメイン、実際に必要なローカルの接続先をそれぞれテストしてください。名前解決のテストで一度アドレスが返っただけではなく、必要な接続が回復したことを確認して完了です。

07 バッテリー消費の異常：通信量とOn Demandを確認

システムのバッテリー画面でShadowrocketの使用割合が高くても、アプリだけで同じ割合の通信が発生しているとは限りません。トンネル経由でほかのアプリのリクエストを処理すると、その使用状況が計上されることがあります。割合は同じ集計期間におけるほかのアプリの電力消費にも影響されます。割合だけで接続機能をすべて無効にせず、使用時間、画面の稼働状況、実際の通信内容を確認して判断してください。

同じ条件で比較できる時間帯を設ける

使い方が近い2つの時間帯を選び、ネットワークの種類、接続時間、主なアプリ、大量のアップロードやダウンロードがあったかを記録してください。システム更新後のバックグラウンド処理、写真の同期、メディア再生、電波の不安定さもバッテリー消費に影響します。一方が電波の強いWi-Fi、もう一方が電波の弱いモバイル通信であれば、特定のスイッチの効果を比べる条件として適切ではありません。まず環境をそろえると、設定変更に効果があったか確認しやすくなります。

デバイスが明らかに発熱していないか、接続と再接続を繰り返していないか、ログに失敗したリクエストが続けて記録されていないかも確認してください。設定ミスによる再試行の繰り返しは、待ち時間、通信量、処理負荷を増やすことがあります。その場合は接続を切るだけではなく、サーバー、DNS、ルールの問題を先に修正します。バックグラウンドで通信が続いている場合は、その処理を一時停止して様子を見るほうが、通信の発生源を特定しやすくなります。

On Demandは接続を開始する条件であり、省電力を保証する機能ではありません

On Demandは、設定された条件に基づいて接続を開始するための機能です。実際の動作はルールとシステムの起動条件によって異なります。システムが各アプリの利用目的を判断できるわけではなく、手動接続を常時維持するよりも常に省電力になるとは限りません。条件が広すぎると、通常のバックグラウンド通信でも接続が繰り返し開始されることがあります。条件が実際の使い方と合っていないと、必要なときに接続されない場合もあります。まず、いつ接続したいのかを明確にしてから条件を選んでください。

トラブル対処では、まず現在の条件を記録し、On Demandを一時的にオフにして手動接続を一度試します。手動接続は安定するのにOn Demandで接続のオン・オフが繰り返される場合は、ネットワークの変化に応じて条件が何度も適用・解除されていないか、ほかの自動接続設定がないか確認してください。条件を変えながらネットワークを素早く切り替えないでください。変更するたびにシステムが切断と再接続を完了するまで待ち、スイッチを切り替えた瞬間だけでなく、通常の使い方でも確認してください。

利用場面に合わせて接続方法を選ぶ

同じ通信を長時間続ける場合は、頻繁な接続と切断が適切とは限りません。短時間だけ使う場合は、作業後に手動で切断したり、理解したうえでOn Demandの条件を設定したりできます。すべてのデバイスに共通する固定の設定はありません。接続方法を利用目的に合わせ、ステータスアイコンを表示しないためにアプリが失敗と再試行を繰り返し、かえって通信が増える状況を避けることが重要です。

手動で接続を切っても再び自動接続する場合は、On Demandとシステム上の該当VPNのオンデマンド状態を確認してください。接続スイッチが故障したとは限りません。テスト用に自動接続の条件を無効にしてから切断し、接続が解除された状態を保てるか確認します。管理対象デバイスでは、管理者が設定した接続要件の有無も確認してください。所有者が分からない管理構成は削除しないでください。システムのポリシーとアプリの個人設定は分けて判断し、変更に必要な権限も異なる点に注意してください。

診断にも負荷がかかる

速度テストを頻繁に行う、詳細なログを長時間記録する、失敗するページを繰り返し更新する、といった操作は通信や処理を増やします。必要な情報を記録したら追加のテストを終了し、診断設定を必要に応じて戻してください。

クライアント側の処理とリモート接続の問題を区別

バッテリー消費と速度低下が同時に起きている場合は、大量の再送、ハンドシェイクの繰り返し、到達できない名前解決の接続先がないか確認してください。同じ通信を保ったまま、ご自身が利用する動作確認済みのサーバーに一時的に切り替え、発熱と安定性が一緒に改善するかを確認します。電波の弱いネットワークでどのサーバーも異常になる場合は、設定を次々と試すのではなく、まず基本的なネットワーク環境を改善してください。クライアント側でWi-Fi自体の消費電力をなくすことはできません。

改善したかどうかは、近い長さの使用時間での実際のバッテリー残量の変化、デバイスの温度、タスクが完了したかどうかを比べて判断します。アプリの使用割合が下がっても、ほかのアプリの電力消費が増えただけの場合があります。一定の省電力率を約束することはできません。また、割合を最小にするために必要な安定した接続をあきらめる必要もありません。接続が安定し、失敗時の再試行が減り、用途に見合った電力消費になれば有効な調整です。

利用場面ごとの設定の選び方はバックグラウンド接続とOn Demandについてをご覧ください。追加の診断を終了し、再試行の原因を修正しても異常が続く場合は、利用状況、システムのバッテリー記録、機密情報を伏せたエラーの概要を保存してから、アップデートまたは設定の復元を検討してください。バックアップなしにアプリを再インストールしないでください。トラブル対処に必要な記録だけでなく、サーバーやルールも失う可能性があります。

08 アップデート後の不具合とiPad：差分を残して復元

「アップデート後に不具合が始まった」という時間的な前後関係だけでは、アプリのアップデートが唯一の原因とは限りません。同じ時期に、システムのアップデート、サブスクリプションの更新、サーバーの変更、ネットワーク環境の変化が起きた可能性もあります。最後に正常だった時点から最初に失敗した時点までに起きたことを並べ、最小限の再現手順を確認してください。比較の手がかりを失わないよう、まず現在の設定のコピーとエラー情報を保存します。再インストールを急ぐと、判断材料が失われるだけでなく、以前の問題を新しい設定に持ち込むおそれがあります。

変化の原因がアプリ、システム、設定のどれかを確認

すべてのサーバー、ネットワーク、接続先で問題が起きるのか、それとも特定のConfigだけかを確認します。同じサーバーがProxyでは使えて、アップデート後のConfigでは失敗する場合は、ルール、ポリシー参照、名前解決の設定を比較してください。サブスクリプション更新後の項目だけで失敗する場合は、取得した接続情報を優先して確認します。アプリのアップデート、サブスクリプションの更新、Configの更新は別々の操作です。トラブル対処の記録ではそれぞれを明記し、すべてを単に「更新」とまとめないでください。

アプリのアップデートと再ダウンロードはApp Storeから行ってください。システム要件はApp Storeのページに記載された内容を確認してください。入手元を確認するには、デベロッパ名のShadow Launch Technology Limited、公式アイコン、アプリID 932747118を照合します。詳しい手順は正規アプリの確認方法をご覧ください。購入履歴で分かるのはアプリの入手状況です。設定が正しいことや、ご自身のリモートサーバーが現在利用可能であることを示すものではありません。

すべてのデータを消去せず、元に戻せる順番で復旧

まずアプリを通常の方法で終了してから開き直し、選択中のサーバー、Global Routing、Configが変わっていないか確認してください。必要であればデバイスを再起動してから再テストします。それでも解決しない場合は、出所の分からない設定一式を読み込まず、ご自身が保存した動作確認済みの設定コピーと比較してください。元の設定は残し、現在有効な項目だけを変更します。差異が見つかったら、必要なルールを一つずつ移し、ポリシー名とサーバーの対応が維持されているか確認してください。

システムのVPN構成が破損していると明確に疑われる場合に限り、第1章の手順で再度許可してください。再認証で修正されるのはシステム構成の層であり、削除されたサブスクリプション、パスワード、カスタムルールは復元されません。アプリの再インストールはさらに後の手順です。元のサブスクリプションアドレス、サーバー情報、必要な設定を安全に保存し、現在アプリから書き出せる内容を確認してください。書き出したファイルには認証情報が含まれる場合があるため、ご自身で管理する安全な場所に保管します。

iPadではアカウント、選択項目、ネットワークの違いを確認

iPhoneでは使えるのにiPadで失敗する場合は、両方のデバイスで同じ有効な情報、同じサーバー、同じGlobal Routingを使っているか確認してください。表示名が同じでも、内部の設定が一致するとは限りません。データ移行後に想定したConfigが有効になっていない場合もあります。それぞれのデバイスで選択中の項目、適用されたルール、エラーが起きた段階を確認してから、違いを比較してください。同じApple Accountを使っているだけで、アプリ内の設定がすべて自動で同期され、一致したままだと考えないでください。

iPadでは画面サイズや表示方法により、サイドバーが表示されたり、情報量が異なったりする場合があります。ボタンの画面上の位置を目印にせず、Home、Config、Settingsなどの画面名から操作箇所を探してください。Split Viewで表示領域が狭くなっても、設定が失われたわけではありません。表示を遮っている画面を閉じるか、対象の領域を展開し、サーバーの編集、Configの選択、システム権限のどれを操作しているか確認してください。場所を間違えたまま読み込みを繰り返さないでください。

Wi-Fiのみを使うiPadでは、デバイス自身のモバイル通信を使った比較はできません。ご自身が信頼できる別のネットワークを選んでください。iPhoneがモバイル通信を使い、iPadが認証を必要とするWi-Fiを使っている場合、両者は同じ条件での有効な比較になりません。現在のWi-Fiでデバイス間通信が制限されていないか、必要な機能にローカルネットワークの権限が適用されているかも確認します。通常のWebページが開けても、プリンターや内部ドメインにアクセスできるとは限りません。

購入済みアプリの再取得と設定の復元は別

アプリを再取得する場合は、実際の購入に使ったApple AccountでApp Storeを開き、購入済み項目から探してください。表示内容や適用範囲はApp Storeのページで確認します。iPadの互換性と購入の適用範囲も、App Storeのページに記載された内容が基準です。アプリの復元が完了したら、サブスクリプションとConfigが残っているか確認してください。アプリを再取得しても、すべての通信設定が復元されるわけではありません。手順は購入済み項目の復元方法をご覧ください。

最後に再現可能な結果を記録

症状、発生条件、変更した項目一つ、再テストの結果を記録してください。解決しない場合は、デバイスとネットワークの情報、機密情報を伏せたエラーの概要を添えます。サブスクリプションの全内容、鍵、書き出した設定全体は共有しないでください。

復元後は使い方ガイドに沿って、読み込み、Configの選択、接続の許可、実際のアクセスをそれぞれ確認し、On Demandと必要なローカルネットワークの利用も再確認してください。再発した場合は、該当する症状の章に戻って原因を絞り込み、設定全体を繰り返し消去しないでください。同じ操作で安定して成功し、一時的な回避策によって本来の用途が損なわれていないことを確認できれば解決です。再起動後に一度だけ正常に見えた状態では不十分です。