Shadowrocketのトラブルシューティング｜接続・サブスクリプション・DNSの確認 · Shadowrocket サブスクリプション設定ガイド

01 / CONNECTION SWITCH

接続スイッチがオンのままにならない

スイッチをタップするとすぐオフに戻る、システムの許可が完了していない、接続してもすぐ切れる――これらはそれぞれ異なる症状です。まずShadowrocketを開き、Homeで、完全なパラメータが設定されたサーバーが選択されていることを確認してください。空のサブスクリプショングループを選んでいるだけではないことも確認します。スイッチが戻る前に警告が表示されたか、システム設定で該当するVPNの接続状態がどうなっているかを記録してください。この段階では、DNSの変更やルールの一括編集はしないでください。トンネルがまだ確立されていないため、その後の設定だけでは原因を説明できません。

システムの許可と選択中の項目を確認する

初めて接続するとき、システムからVPN構成の追加を許可するよう求められ、デバイスのロック解除で確認が必要になることがあります。ダイアログをキャンセルしたり、途中で閉じたり、確認を完了しなかったりすると、接続を続けられない場合があります。アプリに戻って操作をやり直し、システムの案内を最後まで読んでから許可してください。すでに構成が保存されている場合は、システム設定でVPNを検索し、現在の構成が存在するか、今回使うアプリに対応しているかを確認します。システム設定の場所はOSによって異なるため、デバイスに表示される項目を確認してください。決まったメニュー階層に当てはめる必要はありません。

許可を求める画面が表示されない場合は、アプリが未保存の編集画面にとどまっていないか確認してください。Homeに戻り、既存のサーバーを選び直して、もう一度接続します。失敗が一度あっただけでは、設定が壊れているとは判断できません。現在のネットワークの種類、直前に別のネットワークから切り替えたか、デバイスの時刻が自動設定かも記録してください。時刻が大きくずれていると、後続の証明書検証に影響することがあります。この問題を回避するために証明書検証を無効にしないでください。

自動接続と構成の競合を確認する

On Demandを一時的にオフにして、スイッチを手動で操作してみてください。On Demandは条件に応じて接続を開始する機能です。トラブルシューティング中も有効だと、手動で切断しても再び接続され、スイッチが故障したように見えることがあります。デバイスで別のVPN構成や組織管理のネットワークポリシーが動作していないかも確認してください。自分で把握しており、変更が許可されている接続だけを停止してください。提供元が不明な管理プロファイルは削除しないでください。管理対象デバイスの場合は、管理者に利用可能なネットワーク構成を確認してください。

続いてサーバーを変えず、インターネットに正常に接続できるWi-Fiとモバイル通信でそれぞれ試します。Web認証が必要なWi-Fiだけで問題が起きる場合は、Shadowrocketを切断し、そのネットワークへのログインや利用規約への同意を済ませてから、アプリに戻って接続してください。どのネットワークでも同じ段階で失敗し、システムの許可も済んでいる場合は、現在のサーバーパラメータ、設定の解析時に表示されたメッセージ、アプリのログを確認します。ネットワークを切り替えただけで直ったと判断しないでください。

最後にシステム構成を作り直す

まず接続を完全に終了してから、アプリを開き直してください。それでも異常が続く場合は、デバイスを再起動して再確認します。該当するVPN構成を削除して追加し直す必要がある場合は、サーバーと設定を保存済みで、再度許可を完了できることを先に確認してください。システムのVPN項目を削除しても、サブスクリプションは復元されず、サーバー側の問題も解決しません。再インストールを最初の手段にしないでください。ローカルデータが自動で戻るとは限らず、貴重なトラブルの手がかりも失われます。

この章の確認が完了したと判断できるのは、手動接続してもすぐにオフへ戻らず、システム上の接続状態が維持され、許可を求める画面が繰り返し表示されない場合です。それでも失敗する場合は、「タップしてから何秒で戻るか」「ダイアログの原文」「ネットワークの種類」「自動接続の有効・無効」を簡潔に記録してください。2種類のネットワークで同じエラーが再現するという記録は、「スイッチがオンにならない」という説明より原因の特定に役立ちます。購入や入手元に関する疑問は、正規版の確認方法をご覧ください。

02 / CONNECTED BUT OFFLINE

接続済みなのにインターネットにアクセスできない

システムにVPN接続済みと表示されているのにWebページを開けない場合は、「トンネルが存在すること」と「リクエストが成功すること」を分けて考えます。Webページへのアクセスでは、ドメイン名の解決、ルールの照合、サーバーへの接続、接続先サービスからの応答が順に行われます。どの段階で失敗しても、読み込み中のままになることがあります。まず普段問題なく開けるページをテスト対象として一つ決め、エラーの種類を正確に記録してください。次々にサイトを変えると、対象やアクセス条件が毎回変わるため比較が難しくなります。

直接接続とプロキシ接続を比較する

まずShadowrocketを切断し、現在のネットワーク自体でテストページにアクセスできることを確認します。切断後も失敗する場合は、Wi-Fiのログイン、モバイルデータ通信の権限、ルーター、接続先サービスを先に確認してください。基礎となるネットワークが正常なら、接続し直してGlobal Routingを確認します。比較テスト中はサーバーを変えず、変更するのはこの項目だけにしてください。テスト後は元のモードに戻し、切り分け用の一時的な状態をそのまま使い続けないようにします。

画面上の選択肢	主な動作	確認できること
Config	現在のConfigで設定されたルールに従ってリクエストを処理する	ルール、ポリシーグループ、Configの選択が正しいか
Proxy	テストリクエストをプロキシ経由で処理する	現在のプロキシ経路が使えるか
Direct	テストリクエストを直接接続で処理する	経路の違いを比較するための補助

ProxyではアクセスできるのにConfigではできない場合、まず有効なConfig、該当するルール、対応するポリシーを確認してください。すぐにサーバーの故障と決めつけないでください。DirectでアクセスできてProxyで失敗する場合は、選択中のサーバー、プロトコル設定、プロキシ経路を確認します。なお、接続中に行うDirectのテストは、アプリを完全に切断した状態とは同じではありません。DNS設定などの条件が異なる可能性があるため、あくまで補助的な情報として扱い、基礎ネットワークのテストの代わりにはしないでください。

実際に適用されたルールを確認する

Configの一覧で、インポートしただけで未選択のファイルではなく、想定したファイルが実際に有効になっていることを確認してください。ルールは通常、上から順に照合されます。先に一致した項目が後続の処理に影響するため、ファイル末尾にルールを追加しただけでは、既存の照合結果が変わらないことがあります。リクエストログでは、対象ドメイン、該当したルール、最終的なポリシーをあわせて確認してください。ポリシーグループを使っている場合は、グループ内で現在選ばれている項目も確認します。グループ名が正しくても、その中で利用可能なサーバーが選択されているとは限りません。

以下はルールの順序を理解するための簡略化した例です。完全なConfigではなく、使用中のファイルにそのまま上書きしないでください。1行目は例示ドメインだけに一致し、2行目は指定したプライベートアドレス範囲を処理し、最後の行はそれ以前のルールに一致しない場合の最終ポリシーを指定します。実際のトラブルシューティングでは、バックアップのコピーに最小限の変更を加え、その変更が現在有効なConfigに含まれていることを確認してください。

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

すべてのアクセスが失敗する場合と特定サービスだけが失敗する場合を分ける

すべてのページで失敗する場合は、サーバー、名前解決、デフォルトポリシーなど共通の経路を確認します。一つのサービスだけに問題がある場合は、そのサービスのドメイン、ログイン状態、接続先の制限、ほかに使用している接続を確認してください。1つのページが複数のドメインにアクセスすることがあります。トップページが開けても、画像、ログイン用API、メディアのリクエストが同じ経路を使っているとは限りません。ページ本体が表示されたことだけで、すべてのルールが正しいと判断しないでください。

テストのたびに接続先への接続を新しく確立してください。必要に応じて該当ページを閉じて開き直し、古い接続の再利用による誤判定を避けます。復旧したと判断するには、対象ページと主要機能が使えること、ログのポリシーが想定どおりであること、再テストでも成功することを確認してください。特定のアプリだけで発生する場合は、そのアプリのネットワーク権限とキャッシュを確認してからShadowrocketを調べます。接続の問題とアプリへのログインエラーを混同しないよう、よくある質問も参照してください。

03 / SERVER TIMEOUT

サーバーのタイムアウトとプロトコル設定

Connectivity Testの結果は、テスト方法とあわせて判断してください。タイムアウトは、今回のテスト条件で期待した応答を得られなかったことを示しますが、サーバーが恒久的に利用できないと証明するものではありません。応答を確認できても、実際のWebアクセスが成功するとは限りません。まずテスト方法とエラーメッセージを記録し、同じサーバーで実際のリクエストを試してください。テストが成功して実際の利用が失敗する場合は、対象、ルール、名前解決を確認します。両方失敗する場合は、サーバーの接続先とプロトコル設定を一つずつ確認してください。

アドレス、ポート、認証情報から確認する

該当項目の編集画面を開き、アドレス、ポート、プロトコルの種類を、ご自身のサーバー情報と一つずつ照合してください。アドレス欄にその項目とは無関係なパスや余分な空白が入っていないこと、ポートがサーバーで実際に待ち受けている番号と一致することを確認します。サブスクリプションから追加した項目も、リンクの有効期限切れや情報の変更によって古くなっている場合があります。偶然一度成功するまでクライアント側を繰り返し変更するのではなく、まず元の情報が現在も有効か確認してください。

認証欄は現在のプロトコルに合った内容である必要があります。Shadowsocksでは暗号方式とパスワード、VMessやVLESSなどではユーザー識別情報とサーバーが要求する通信設定、Trojanではパスワードとセキュア接続関連のパラメータを確認してください。プロトコル間で似ている項目があっても、そのまま流用できるとは限りません。コピー時は全角記号、改行、先頭と末尾の空白に注意してください。認証情報全体を他人に送るのではなく、各項目が一致しているかを伝えてください。

パラメータの分類	確認する項目	よくある症状
接続先	アドレス、ポート、現在の名前解決結果	接続を確立できない、または接続がタイムアウトする
認証	パスワード、ユーザー識別情報、暗号方式	サーバーには接続したが、リクエストが完了しない
TLS	サーバーが要求する名前、証明書、デバイスの時刻	セキュア接続の検証に失敗する
通信方式	通信方式、パス、関連するホスト欄	ハンドシェイクに失敗する、または接続直後に切断される

TLSのエラーと通信方式のエラーを分ける

サーバーアドレス、TLSで使用する名前、通信に必要なホスト欄は、それぞれ異なる場合があります。推測で入力せず、サーバー情報に基づいて設定してください。証明書エラーが発生した場合は、まずデバイスの時刻を正し、名前とサーバー証明書の状態を確認します。検証をスキップすることを通常の解決策にしないでください。一時的にエラー表示が変わっても、本人確認の不一致という根本原因は解決せず、セキュア接続の信頼性も低下します。

サーバー側で特定の通信方式を使っている場合、クライアントのパス、ホスト欄、関連するスイッチを一致させる必要があります。一つでも項目が欠けると、接続先には接続できても後続のハンドシェイクに失敗することがあります。複数のパスやセキュリティ設定を同時に試すのではなく、元の情報に記載された設定に戻して確認してください。エラーがタイムアウトから明確な認証エラーやハンドシェイクのメッセージに変わった場合も、失敗する段階が変化したという有効な手がかりです。

ネットワーク経路とサーバー側の問題を切り分ける

サーバー設定を変えずにネットワークを切り替え、一方のネットワークだけで失敗する場合は、ネットワークの種類とプロトコルの通信特性を記録してください。一部のプロトコルはUDPに依存し、ネットワークによってそのトラフィックの扱いが異なることがありますが、一度失敗しただけで原因を断定することはできません。Hysteria2についてはHysteria2プロトコルの基礎を参照してください。トラブルシューティングでは、実際のエラーと再現性のあるネットワーク比較を根拠にしてください。

ご自身が利用できるほかの有効な項目が同じネットワークで正常に動作し、現在の項目だけが複数のネットワークで失敗する場合は、元のサービス提供元にサーバーの待ち受け状態、認証、サービスの稼働状況を確認してください。クライアントのログだけでは、リモート側のプロセスが動作しているかを直接確認できず、サーバー側の設定も修正できません。問い合わせる際は、認証情報を伏せたうえで、失敗した段階、発生条件、テスト結果を伝えれば十分です。サブスクリプションの内容全体を公開する必要はありません。修正後は実際のリクエストで再確認し、再接続も成功することを確認してください。一度だけ成功したテストを復旧と見なさないようにします。

04 / SUBSCRIBE

サブスクリプションの追加・更新に失敗する

サブスクリプションの更新では通常、リンク先の内容取得、形式の認識、ローカル項目の置き換えという段階があります。内容を取得できない、形式を認識できない、更新は成功したがサーバーが使えない、という症状はそれぞれ別の問題です。まず表示されたメッセージがどの段階に当たるかを確認し、該当する箇所を調べてください。ご自身のサブスクリプションリンクは、元の情報から取得してください。サブスクリプションは設定データの取得元であり、アプリの購入証明ではありません。また、サブスクリプションの更新とShadowrocketアプリの更新は別の操作です。

認証情報を公開せずにリンクを確認する

Subscribeの項目でURLが完全か、特に「?」以降のパラメータを確認してください。共有方法によってはリンクが途中で切れたり、末尾に日本語の句読点、説明文、改行が付いたりすることがあります。元の情報から改めてコピーし、保存済みの内容と部分ごとに比較してください。ドメイン名が同じだけで一致していると判断しないでください。パスやパラメータが変われば、まったく別の内容を指すことがあります。以下のURLは構造の説明用であり、実際のサービスには使えません。クリックして取得するためのリンクでもありません。

https://example.com/sub?token=xxxx

サブスクリプションの完全なURLにはアクセス権限が含まれる場合があるため、パスワードと同じように慎重に扱ってください。見知らぬ変換ページに入力したり、問い合わせ用のスクリーンショットに表示したりしないでください。リンクが期限切れか確認する場合は、ご自身のサービス管理ページを確認するか、元のサービス提供元に問い合わせてください。リンクをコピーし直したら、まず既存のサブスクリプションを更新して結果を確認します。同じ名前のグループを次々と作成すると、どのデータが古いものか新しいものか判別しにくくなります。

取得・形式・項目の3段階で切り分ける

取得段階で失敗する場合は、現在のネットワーク、ドメインの名前解決、リンクのアクセス条件を確認してください。ネットワーク経路によってはアクセスできるリンクもあります。その場合は、切断中と接続中のどちらで更新したかを記録し、ほかの条件を変えずに比較します。ログインページがブラウザで開けても、サブスクリプションAPIがアプリに必要な内容を返すとは限りません。実際に返されたものがWebページ、エラーの説明、認証画面なら、更新を繰り返しても自動的にサーバー一覧へ変わることはありません。

形式を認識できない場合は、管理画面のURLやWebページの共有URLではなく、サブスクリプションURLをコピーしたか確認してください。返された内容の文字コードをむやみに変更したり、理解できない項目を削除したりしないでください。まず元のサービス提供元が案内する形式がShadowrocketに対応しているか確認します。インポートできても一部の項目しか表示されない場合は、データ形式、項目の有効性、パラメータの認識に原因がある可能性があります。グループ全体を削除するのではなく、古いデータを残して項目ごとに比較してください。

更新後に選択状態と参照先を確認する

更新によってサーバー名、グループの内容、選択できる項目が変わることがあります。現在選択中の項目が削除済みの項目を参照していると、「更新後に使えなくなった」ように見える場合があります。Homeに戻って選択中の項目を確認し、Configに名前で参照しているポリシーやグループがないかも確認してください。まず更新後の有効な項目で直接接続をテストし、そのあと複雑なルールを戻すと、データの変更とルールの参照エラーを切り分けられます。

手動更新が安定してから、アプリ起動時の自動更新などを検討してください。自動更新を設定しても、アプリを開くたびに新しいデータを取得できるとは限りません。ネットワーク、リンクの有効期限、取得内容の影響を受けます。更新を何度も繰り返すと、元のサービス側でリクエスト制限がかかることもあります。案内されている更新頻度に従い、失敗したらメッセージを記録して適切な間隔を空けてください。診断の代わりにボタンを連打しないでください。詳しい手順はサブスクリプション更新ガイドをご覧ください。

この章の確認では、一連の操作を最後まで行ってください。正しいリンクを保存し、手動で更新し、項目の変化を確認して、サーバーを選び直し、対象に実際にアクセスします。古い項目は使えるのに更新だけ失敗する場合は、使える状態を保ったまま更新手順を確認してください。更新が正常なのに接続がすべて失敗する場合は、サーバーのタイムアウトの章に進みます。問い合わせでは「取得に失敗」「形式を認識できない」「更新後に接続できない」のように説明すると、「サブスクリプションがおかしい」だけの場合より原因を特定しやすくなります。

05 / PERFORMANCE

速度低下と接続の不安定さ

速度が遅いという症状は、最初のページが開くまで時間がかかる、転送中の速度が遅い、動画が断続的に止まる、Wi-Fi切り替え後に一時的に接続が切れるなど、さまざまです。これらを一つの問題として扱わないでください。まず「最初に開くときは時間がかかるが、転送開始後は正常」のように症状を具体的に定義し、それに合った確認を行います。応答時間、転送速度、安定性はそれぞれ異なる指標です。Connectivity Testを一度実行した結果だけで、使い心地全体を判断することはできません。

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

デバイス、ネットワーク、サーバー、対象コンテンツを固定し、大量のバックグラウンド転送を止めてから同じ操作を繰り返してください。基礎ネットワークの確認は、まずShadowrocketを切断して行います。この状態でも遅い場合は、電波状況、ルーターの負荷、ネットワーク自体を優先して確認します。時間帯を変えて比較するときは条件の変化も記録してください。対象サービスやリモート経路の負荷も変化します。別々の時間に異なるWebサイトで試した結果を、そのまま同じサーバーの評価に使わないでください。

Wi-Fiだけで遅い場合は、アクセスポイントに近づいて再テストし、電波が弱い場所や混雑した環境で使っていないか確認してください。モバイル通信は安定しているのに同じWi-Fiで頻繁に切断される場合は、まずWi-Fi側に原因を絞ります。反対にモバイル通信だけで問題がある場合は、電波状況、デバイスのデータ通信設定、ネットワーク切り替えのタイミングを確認してください。最初からすべてのネットワーク設定をリセットすると条件が大きく変わり、保存済みの情報も消えて比較が難しくなるため避けてください。

遅延が発生する段階に応じて切り分ける

最初の読み込みは遅いが、その後は正常な場合は、名前解決と接続確立の過程を確認してください。新しいドメインを開くたびに待たされ、同じページの再読み込みは速い場合、DNSや初回ハンドシェイクが関係している可能性があります。ただしキャッシュでも同様の差が出るため、複数回テストしてください。ページの読み込みはすぐ始まるのに、大きなファイルの転送が不安定な場合は、DNS設定だけを調整するのではなく、通信経路のパケットロス、リモート側の負荷、接続先の速度制限、ローカルで同時に流れている通信を確認します。

特定のアプリだけ遅い場合は、実際の接続先と適用されたルールを確認してください。メディア、画像、ログイン用APIが異なるドメインを使うことがあり、一部の処理だけ別のポリシーに振り分けられると、全体の動作にばらつきが出ます。Global Routingを切り替えて短時間の比較をする際は、接続先への新しい接続を確立し、既存のセッションが以前の経路を使い続けないようにしてください。Proxyは安定しているのにConfigでは不安定な場合は、ポリシーグループが自動切り替えされていないか、同じサービスの異なるドメインが別の出口に振り分けられていないかを確認します。

統計は補助として使い、数値だけで結論を出さない

Dataでは、サーバー別やアプリ関連などの表示から通信状況を確認できます。ただし、統計の対象範囲、接続の再利用、システムの動作が数値に影響します。「リクエストが想定した経路を通ったか」の確認には役立ちますが、数値一つだけでリモート側の帯域を断定することはできません。詳しくはData画面の統計の見方を参照してください。通信量を記録する際は、今回のテスト時間も記録し、以前の接続から累積した値を今回の結果と取り違えないようにします。

「速くなるかもしれない」という理由でプロトコル設定をむやみに変更しないでください。通信方式、暗号方式、セキュリティ設定は、まずサーバー側の指定と一致させる必要があります。特にUDPを使うプロトコルでは、現在のネットワークが対象の通信を安定して扱えるかを考慮してください。あらゆるネットワークに共通する最適な設定はありません。特定のネットワークで特定のプロトコルだけが繰り返し失敗する場合は、同じネットワークでほかの有効な接続を試した結果を記録し、元のサービス提供元に確認してください。

実際の利用場面で最終確認してください。同じ種類のページを続けて閲覧する、実際にファイルを転送する、ネットワーク切り替え後にもう一度アクセスするなどの方法があります。一時的に高い数値が出たかだけでなく、同じ操作を繰り返しても目立った遅延がないことを確認します。特定の時間帯や接続先だけで問題が起きる場合は、時間帯と対象の種類を記録すれば十分です。クライアントの設定を際限なく増やさないでください。リモート側や基礎ネットワークの制限だと分かった後は、ローカルルールを変更し続けても根本原因の改善には通常つながりません。

06 / DNS AND ROUTING

DNSの名前解決とルールの経路

DNSはドメイン名を接続可能なアドレスに変換します。ただし、ドメイン名を解決できてもアドレスに到達できるとは限らず、アドレスに到達できてもセキュア接続やアプリのリクエストが成功するとは限りません。よくある症状には、ドメイン名の解決エラー、初回アクセスの遅延、特定ドメインだけの失敗、ルールの予期しない結果があります。まずエラーが名前解決に関係しているか記録し、現在有効なConfigとDNS設定の参照元を確認してください。Webページを開けない問題をすべてDNSのせいにしないでください。

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

現在のConfigと関連するDNS設定を確認し、システムのDNSを使っているのか、カスタムDNSなのか、DNS over HTTPSを含む方式なのかを確かめてください。編集したばかりのファイルを見るだけでなく、そのファイルが実際に有効になっていることも確認します。Configの複数箇所にDNS設定がある場合は、どの設定が優先されるかを把握してから変更してください。デバイスに組織管理のDNS設定が適用されていないかも確認します。異なる参照元が重なると、一つの項目を変更したつもりでも、実際のリクエスト経路が変わっていないことがあります。

まず元の設定を保存し、動作が確認できている最もシンプルな名前解決方式で基準状態を作ります。DNS over HTTPSを使う場合は、そのサーバーにアクセスする必要があるため、利用可能な接続と正しい名前の検証が前提になります。まだ確立していないプロキシ経路を通じてDNSサービスにアクセスするよう設定すると、相互依存が生じることがあります。ドメイン一つの失敗を解決しようとしてDNSアドレスを次々と追加すると、タイムアウトやフォールバックの過程が分かりにくくなります。

ドメインルールとアドレスルールを区別する

DOMAINやDOMAIN-SUFFIXなどのルールはドメイン名の情報に基づいて照合し、IP-CIDR、IP-CIDR6、GEOIPなどはアドレスに関係する条件で照合します。二種類のルールは使う場面が異なります。アドレスルールが適用されたからといって、それ以前のドメインルールが正しいとは限りません。反対に、ドメインルールに一致しても、最終的なアドレスが現在の経路に適しているとは限りません。まずリクエストログで実際に適用されたルールを確認し、名前解決の結果が問題なのか、ルールによって不適切なポリシーに振り分けられたのかを判断してください。

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

この例はルールの種類と順序を説明するためのもので、あらゆる環境に適するわけではありません。ここでは完全一致のドメインルールとサフィックスルールが競合する可能性があります。実際のConfigには、本当に必要な項目だけを残してください。FINALは最後に適用するポリシーであり、DNSを修復するスイッチではありません。切り分けるときは、コピー上で対象に関係する最小限のルールだけに絞り、まず接続先の経路を確認します。その後、元のルールを一つずつ戻し、追加するたびに再テストすると競合を特定しやすくなります。

条件の異なるテストから結論を出さない

ブラウザーに特定のアドレスを直接入力しても、元のドメイン名でアクセスするテストの代わりにはなりません。セキュア接続では正しいホスト名が必要になることが多く、Webサイトがホスト名によってサービスを振り分ける場合もあります。そのため、「アドレスを直接入力して失敗した」という結果だけでは、ネットワークに接続できないとは証明できません。別のデバイスで調べた名前解決の結果をConfigに長期間固定するのも避けてください。リモートのアドレスは変わることがあり、利用可能な経路もネットワークによって異なります。実際のリクエストに表示されたエラーと名前解決の記録を優先して確認してください。

DNSを変更しても、既存の接続やキャッシュが結果に影響することがあります。いったん切断して再接続し、対象のページを閉じてからもう一度試してください。必要なら該当アプリを再起動します。ページを一度再読み込みして変化がないだけで、変更が無効だと判断しないでください。また、デバイス全体の設定を繰り返し消去しないでください。特定のドメインだけが失敗する場合は、ドメイン名の入力、接続先サービスの状態、ほかのネットワークでの結果を確認します。すべてのドメインが失敗する場合は、DNSサービスへの接続と設定の参照元を確認してください。

LAN内の名前、デバイス検出、組織内ドメインを使う場合は、現在のネットワークが提供するDNSでなければ解決できない可能性も考慮してください。すべての名前解決を別の経路に統一すると、外部のWebサイトは正常でも内部サービスにアクセスできなくなることがあります。ルール全体を無効にするのではなく、必要な対象だけに最小限の例外を設定してください。システムDNS、カスタムDNS、DNS over HTTPSの違いはDNS設定の比較をご覧ください。その後、この章に戻り、同じ対象で確認してください。

07 / BATTERY AND BACKGROUND

バッテリー消費の異常とバックグラウンド接続

バッテリー消費を調べる際は、通信が続いているのか、再接続を繰り返しているのか、単に接続状態を維持しているだけなのかを分けて考えます。システムのバッテリー画面に表示されるアプリの割合は、特定の集計期間における相対値です。特定のスイッチが一定量の電力を必ず消費するという意味ではありません。期間中の画面使用時間、電波状況、バックグラウンド動作などによって数値は変わります。まず異常が起きた時間帯、デバイスの発熱の有無、大量の同期を直前に行ったかを記録し、Shadowrocketの接続動作とバッテリー消費が同時に起きているかを確認してください。

同じ条件で観察する

近い利用条件を選び、接続をオンにしたときとオフにしたときのデバイスの状態をそれぞれ記録します。比較の際は、画面の明るさ、ネットワーク、バックグラウンドタスク、使用時間をできるだけそろえてください。待機中と動画を連続視聴している状態を比較しても意味がありません。切断後もデバイスが明らかに発熱する場合は、システム更新後の処理、写真の同期、大量のファイル転送など、ほかの動作を確認してください。VPN接続が通信を運んでいるからといって、通信の発生元がプロキシクライアント自身とは限りません。

Dataとリクエストログを確認し、アイドル時にも大量の通信が続いていないか、同じ接続先で短時間に失敗が繰り返されていないかを確認します。ページの自動更新、クラウド同期、ほかのアプリのバックグラウンドタスクが接続を使い続けている場合があります。まず通信の発生元を特定してから、そのアプリのバックグラウンド動作を調整するか判断してください。統計上の割合を下げるために使用中の設定を削除すると、実際の通信経路を判断できなくなるため避けてください。

症状を隠すのではなく、再接続の原因を調べる

ログで接続と切断が繰り返されている場合は、まずネットワークの電波状況と現在のサーバーの安定性を確認してください。電波が弱い環境での再試行は、使い勝手を損なうだけでなく、デバイスの負荷も高めます。設定を変えずに安定したWi-Fiで様子を見てください。そこで正常になる場合は、元のネットワークの電波状況と切り替えの挙動を調べます。複数のネットワークで切断が繰り返される場合は、サーバーのタイムアウトの章に沿って認証、通信方式、リモート側の状態を確認してください。バッテリーだけの問題と決めつけないでください。

On Demandは条件を満たすと再接続するため、手動で切断した後に再び接続されても、必ずしも異常ではありません。比較テストを行う場合は、該当する自動接続条件を一時的にオフにし、元の設定を記録してください。テスト後は設定を戻します。条件の変化によって二つの状態を行き来するような設定では、接続の開始が繰り返されることがあります。どの種類のネットワークで接続し、どのネットワークで切断したままにするのかを明確にし、互いに矛盾する条件を残さないようにしてください。

診断の負荷と不要なリクエストを減らす

詳細なログは短期間の原因特定には役立ちますが、問題が解決した後も必要のない高負荷の診断を続けるべきではありません。追加のログ記録や頻繁なテストを有効にしていた場合は、必要な証拠を得た後に通常の状態へ戻してください。サブスクリプションの自動更新、ポリシーのテスト、自分で設定した定期動作が過度に頻繁でないかも確認します。必要な情報を得るための操作であり、頻繁に更新するほど安定するわけではありません。

画面をロックした後も通信がある場合、システムが必要な接続を維持しているだけなら正常なことがあります。予定していない通信がないのに大量のリクエストが繰り返し失敗している場合は、リクエストの発生元や誤った再試行ループを調べてください。一度失敗した後に少し再接続することと、異常が継続することは同じではありません。観察時間を考慮して判断してください。一瞬の発熱やバッテリー残量の変化だけで、アプリが長時間にわたって電力を消費していると結論づけないでください。

調整後は、基準を確認したときと同じネットワーク、同じ利用条件で再度観察し、再接続の回数が減ったこと、異常なリクエストが止まったこと、実際のアクセスが正常なことを確認します。クライアントを終了した後も同じバッテリー消費が続く場合は、問題の対象をシステムやほかのアプリに広げて確認してください。問い合わせる際は、集計期間、画面の使用状況、ネットワークの種類、認証情報を伏せた通信の特徴を伝えると役立ちます。閲覧履歴の全体や認証情報を含む設定を公開する必要はありません。

08 / CHANGE AND RECOVERY

更新後の不具合と設定の復旧

「更新後に使えなくなった」という場合、まず何を更新したのかを明確にしてください。App Storeのアプリ、システム、サブスクリプションの内容、Configファイルでは、それぞれ影響する段階が異なります。同じ日に変更が重なっていても、必ずしも原因は同じではありません。アプリを更新しても期限切れのサブスクリプションは直らず、サブスクリプションを更新してもルールの参照先が有効とは限りません。最後に正常に使えた時点から最初に異常が起きた時点までの変更を列挙し、実際に行った操作だけを記録してください。時期が近いという理由だけで、特定の変更を原因と決めつけないでください。

現状を保存してから、最小構成でテストする

変更を続ける前に、現在のConfigのコピー、選択中のサーバー名、Global Routingの状態を保存してください。バックアップファイルには機密情報が含まれる可能性があるため、自分で管理できる場所に保管します。すでにバックアップがある場合も、作成時点と含まれる内容を確認してください。サーバー一覧、ルールファイル、システムのVPN許可は、それぞれ別の情報です。どれか一つをバックアップしただけで、元の状態すべてを復元できるとは限りません。

まずアプリを再起動し、接続を再確立して、異常が続くか確認します。その後、現在有効なサーバーは変えず、シンプルな経路で実際にアクセスできるか試してください。Proxyでは正常で元のConfigでは失敗する場合は、Configの解析、ルールの順序、ポリシーグループの参照を重点的に確認します。どの経路でも失敗する場合は、サーバー、許可、基礎ネットワークを確認してください。最小構成でのテストは変数を減らすためのものであり、すべての用途に代わる設定を作るためではありません。

変更の種類に応じて確認する

サブスクリプションの更新後に異常が起きた場合は、選択中の項目が更新後の一覧に残っているか、元のポリシーグループが名前変更後の項目を参照していないか確認します。Configの更新後に異常が起きた場合は、インポート時のメッセージ、有効なファイル、最終ルールを確認し、新しいファイルが別の未選択コピーとして保存されていないか調べます。ご自身の元の設定を使っている場合は、新旧両方を比較できるように残してください。壊れた設定をファイル全体ごと戻してしまわないよう、一度に一部だけ復元します。

アプリまたはシステムの更新後に異常が起きた場合は、まずシステム上のVPN許可が引き続き正常に機能するか、デバイスが更新後の処理を実行中ではないかを確認します。接続に一度失敗しただけで、すべてのネットワーク設定をすぐに消去しないでください。問題を安定して再現できる場合は、具体的な手順とエラーメッセージを記録し、App Storeのページで現在のアプリの説明や関連情報を確認します。アプリの入手と更新はApp Storeで行います。入手元の確認については正規版の入手をご覧ください。

一度に上書きせず、項目ごとに確認しながら復旧する

バックアップから復元する場合は、保存されているサーバー情報が今も有効かを先に確認してください。古いConfigは構文が正しくても、アドレス、認証情報、参照先がすでに変わっている場合があります。まず必要なサーバーだけを復元してテストし、次に主要なルール、最後に自動接続やその他の任意設定を戻す方法がおすすめです。各段階で成功した状態を記録してください。次の手順で失敗しても、直前に復元した内容に原因を絞り込めるため、すべての設定を最初から調べ直さずに済みます。

直前に行った変更	優先して確認する項目	復旧後の確認基準
サブスクリプションの更新	現在の項目、名前による参照、認証情報	更新後の項目で実際にアクセスできる
Configの置き換え	有効なファイル、ルールの順序、ポリシーグループ	対象リクエストに想定したポリシーが適用される
アプリまたはシステムの更新	システムの許可、接続ログ、ネットワーク条件	再接続後もアプリを開き直した後も正常に動作する

必要な情報を保存し、復元手順を理解し、通常の切り分けでは先に進めない場合に限り、再インストールを検討してください。再インストールしても、リモートサーバーの停止や期限切れのリンクは直りません。購入済みアプリの復元とローカル設定の復元は別々に行います。前者はApp Storeの購入履歴に関係し、後者はご自身のバックアップが必要です。アプリを再入手すれば、ローカル設定もすべて自動で戻ると考えないでください。

問題が続く場合は、最小限の再現手順をまとめてください。デバイスの種類、ネットワークの種類、最後に正常だった状態、発生した変更、簡略化したConfigでの結果を記載します。認証情報や無関係な履歴は削除し、普段の通信ログ全体を送らないでください。復旧完了の確認には、アプリを開き直す、手動で再接続する、ネットワークを切り替えて再接続する、対象のサービスが正常に使える、自動接続の条件が想定どおりであることが含まれます。現在のセッションで一時的に使えただけでは、復旧したとは言えません。

09 / IPAD CHECKLIST

iPadでの確認と復旧

iPadの基本的な接続手順はiPhoneと同じですが、大画面でのマルチタスク、異なるWi-Fi、LAN内のデバイス、デバイス間の移行など、使用状況は異なります。問題が起きたときに、別のデバイスでの結果をそのまま当てはめないでください。同じサブスクリプションが別のデバイスで使えても、正常なのは一部の条件だけかもしれません。このiPadで同じ設定が有効になっている証明にはなりません。システム要件、互換性、購入対象となるデバイスについては、App Storeのページに記載された情報を確認してください。デバイスの外観だけで対応状況を判断しないでください。

アプリの入手と設定の移行を分けて確認する

まずiPadに正しいShadowrocketがインストールされていることを確認してください。正規版かどうかは、デベロッパ名がShadow Launch Technology Limitedであること、公式アイコン、アプリID 932747118を確認します。入手方法はiPadでの入手方法をご覧ください。購入履歴からアプリを入手できても、別のデバイスのサブスクリプション、選択中の項目、ルール、自動接続条件が同期されているとは限りません。移行後は各項目を確認してください。リストが空だからといって、購入が反映されていないと判断しないでください。

ご自身のバックアップから設定を読み込む場合は、ファイルが完全で、このiPadで実際に有効になっている項目を確認してください。サーバー名が一覧に表示されていても、現在選択されているとは限りません。Configを読み込んでも、有効化されているとは限りません。iPadで基本手順を最初から確認することをおすすめします。有効な項目を選び、手動で接続し、決めた対象にアクセスしてから、ルールと自動接続を戻します。最初の許可設定はこのiPadで行ってください。別のデバイスで許可済みでも代わりにはなりません。

このiPadのネットワークと権限の違いを確認する

Wi-Fiのみで接続するiPadもあるため、モバイル通信と比較できない場合があります。利用が許可されている別のネットワークでテストできますが、まずそのネットワーク自体が正常に使えることを確認してください。学校、職場、公共のWi-Fiに接続するときは、Shadowrocketを切断して必要なWeb認証を完了します。管理対象デバイスには組織の設定が適用されている場合があります。関連する設定を自分で削除せず、管理者に確認してください。

Webページは正常なのにLAN内のデバイスにアクセスできない場合は、接続先のアドレスが現在のLANに属しているか、関連アプリに必要なローカルネットワークの権限があるか確認してください。印刷、画面共有、デバイス検出は通常のWebリクエストだけで動作するとは限りません。外部のWebページへのアクセス結果で代用しないでください。該当するプライベートアドレスに適切な経路が設定されているか、ルールを確認します。ただし、アドレスルールを一つ追加しただけでは、検出の仕組みやデバイス側の権限の問題まで解決できない場合があります。

マルチタスクとネットワーク切り替えを確認する

Split Viewの使用中やアプリの切り替え後に異常が起きた場合は、以前の画面表示だけで判断せず、Shadowrocketに戻って実際の接続状態を確認してください。ページに古い内容が残っていることや、対象アプリが既存のセッションを再利用することがあります。新しいリクエストを発生させてログに記録されるか確認し、適用されたポリシーを調べます。新しいリクエストがない場合は、対象アプリが読み込み中か、動作が一時停止していないかを確認してください。アプリがリクエストを送っていない状態を、プロキシが転送していない問題と取り違えないようにします。

画面ロックからの復帰時、Wi-Fi切り替え時、アクセスポイントから離れた後に一時的な失敗が起きる場合は、ネットワークが安定するまで待ってから、対象への接続を確立し直してください。画面を復帰するたびに切断される場合は、On Demandが有効か、元のネットワークで再認証が必要か、同じネットワークで基本的なアクセスが正常かを記録します。自動接続を一時的にオフにして手動で比較した後は、元の条件に戻してください。トラブルシューティングのために、利用目的に合わない設定を長期間残さないでください。

このiPadで一連の確認を済ませてから、通常の利用に戻す

まずSafariで決めたテストページを開き、基本的なアクセスを確認します。次に問題が起きたアプリをテストし、最後にLANやマルチタスクの利用状況を確認してください。各段階で成功した条件を記録します。特定の用途で失敗した場合は、すでに確認できた基準状態を維持して、その用途だけを調べてください。すべての設定を最初から変更し直す必要はありません。用語を確認する場合は用語集を、基本操作を最初からやり直す場合はクイックスタートガイドをご覧ください。

最終確認では、このiPadでアプリを開き直し、手動で再接続し、実際のサービスにアクセスし、よく使うネットワークへ切り替えた後にも再びアクセスできることを確認します。このiPadだけで失敗する場合は、ローカルの許可、ネットワーク、設定、権限の違いを記録してください。複数のデバイスで同じサーバーへの接続が同時に失敗する場合は、サーバーまたはサブスクリプションの状態を重点的に確認します。この順序で手がかりを整理すると、インポートや再インストールの繰り返しを減らし、次の問い合わせでも対応可能な問題の段階を明確に伝えられます。