Shadowrocketのトラブルシューティング
接続・サブスクリプション・DNSの確認

01 · 接続が確立しない

スイッチがオンにならない：権限と接続状態を確認

まず、スイッチがまったく反応しない、タップ直後にオフへ戻る、接続表示になった後で切断される、の3つに分けて考えます。最初の2つは端末の権限や設定、3つ目はネットワークの切り替えやオンデマンド接続が関係している可能性があります。システム接続が確立する前にサーバーのパスワードを何度も変更するのは避けてください。この段階では、サーバー側の設定が失敗に関係していない場合があります。まずダイアログの表示内容、発生時刻、スイッチの状態を記録し、システム設定に該当する接続が表示されているか確認します。

初回の許可と既存の接続記録

初回起動時、システムからVPN構成の追加と端末認証を求められることがあります。これは端末の通信を制御するための許可であり、サブスクリプションへのログインではありません。自分で起動したShadowrocketからの要求であることを確認して、システムの案内に従ってください。キャンセルした場合は、アプリに戻って再度有効にし、もう一度確認します。学校や職場の管理対象端末では、管理ポリシーによって制限されている可能性があります。サブスクリプションを変更して回避しようとせず、この種のネットワーク構成が許可されているか管理者に確認してください。

許可済みなのにすぐオフへ戻る場合は、まず通信を制御している他のVPN接続を停止してから、Shadowrocketで再テストします。システムの一覧に複数の構成があっても、それらが同時に有効とは限らず、すべて削除する必要もありません。現在有効な項目とその提供元を確認し、明らかに自分のものと分かり、実際に異常がある記録だけを処理してください。システムの接続記録を削除する前に、アプリ内の設定を保存します。再作成するときは、アプリから許可を求めてください。提供元の不明な構成プロファイルはインストールしないでください。

一覧だけでなく、現在の選択項目を確認

Homeで、自分が用意した有効なサーバー情報が選択されていることを確認します。一覧に複数の名前があっても、現在の選択が正しいとは限りません。次にConfigを開き、実際に有効な構成ファイルを確認します。ファイルのインポート直後に問題が発生した場合は、まず起動できていた設定のコピーに戻し、追加されたポリシー名、参照関係、構文を比較してください。ルールをすべて削除するのは避けます。解析エラーが出た場合は、該当行の前後を残し、余分な句読点や未完のブロックがないか確認します。

スイッチをオフにしても自動でオンになる場合は、On Demandが引き続き動作していないか確認します。原因を切り分けるため、関連するオンデマンド条件を一時的にオフにして、手動で接続します。これはトリガーを特定するための一時的な操作で、恒久的な無効化を求めるものではありません。手動接続が安定する場合は、オンデマンド設定を戻す際にネットワークの種類と一致条件を一つずつ確認し、自動再接続をボタンの不具合と誤認しないようにします。システム内に他の接続構成がある場合は、その自動接続条件も確認してください。

再起動と接続の再作成を使うタイミング

上記を確認しても起動できない場合は、アプリを通常の手順で終了し、端末を再起動してから安定したネットワークで再テストします。再起動で一時的な状態が解消することはありますが、設定の構文エラーは修正されません。システムの接続記録を作り直す必要がある場合は、サブスクリプション、個別のサーバー項目、現在のConfigを復元できる状態にしてから行ってください。アプリの削除を最初の手段にしないでください。端末に保存された個別項目はサブスクリプションから再取得できない場合があり、写真に残したQRコードも現在有効とは限りません。

スイッチがオフに戻る際、ネットワークの切り替え、画面ロック、システム通知が関係しているか記録します。毎回同じ操作の後に発生するなら、その経路に沿って確認します。特定の設定ファイルでのみ発生する場合は、正常に起動できる比較用ファイルを残してください。この章での確認完了の基準は、システム接続が確立して維持されることです。Webページが必ず開けることではありません。スイッチが安定しているのに通信に失敗する場合は、次の章に進み、権限の確認を繰り返さないでください。

02 · 接続済み

通信できない：基本ネットワーク・ルーティング・対象リクエストを切り分ける

接続中の表示は、端末で通信制御が始まったことを示します。選択中のサーバーが目的の接続先に到達できることや、DNS、ルール、接続先サービスがすべて正常であることを示すものではありません。まず接続を停止し、通常のネットワークから普段アクセスできるページを開いて、Wi-Fiの認証が完了していること、モバイル通信が使えることを確認します。接続を切っても通信できない場合は、ルーター、電波、ネットワーク認証を先に確認してください。この段階でプロキシ設定を繰り返し変更すると、基本ネットワークとアプリの問題を切り分けられなくなります。

3つのモードで比較する

Global Routingでは、Config、Proxy、Directの3つのモードを切り替えて比較できます。Configは現在の設定ルールに従って通信経路を選び、Proxyはすべての通信にプロキシ経路を使い、Directは直接接続します。テスト前に元のモードを記録し、同じ対象、同じネットワーク、同じサーバーを選んで比較してください。Proxyにしてもサーバーの不具合が直るとは限らず、Directですべての接続先に到達できる保証もありません。各モードは、問題の範囲を絞るために使います。

Proxyでは正常でConfigでは失敗する場合、ルールの問題を隠すためにProxyを常用しないでください。まずリクエスト記録から先ほどの対象ドメインを探し、最終的に適用されたポリシーが想定どおりか確認します。ルールが参照するポリシー名は、実際に設定内に存在する必要があります。名前が似ていても同じ項目とは限りません。Webページはログイン、画像、APIなど複数のドメインに依存する場合があり、メインのページが開けても、関連するリクエストが同じ経路を通ったとは限りません。

すべての通信の失敗と一部だけの失敗を区別

特定のアプリだけで問題が起きる場合は、まずそのアプリを終了して再度開き、新しい接続記録が作られるか確認します。アプリによっては既存の接続を再利用するため、ルールを変更してすぐ更新しても、新しいポリシーが適用されたとは限りません。ブラウザーは正常で特定のアプリだけ失敗する場合は、そのアプリが使うドメイン、システムのネットワーク権限、サービス自体の状態を確認します。一つのアプリのエラーだけでサーバー接続全体が失敗したと判断しないでください。また、特定の対象のためにすべての通信を恒久的に同じ経路へ変更しないでください。

Wi-Fiとモバイル通信を切り替えて比較すると、ローカルネットワークや接続環境の違いを見分けやすくなります。切り替えるときは接続を停止し、新しいネットワーク自体が使えることを確認してから再接続し、同じ対象へアクセスしてください。Wi-Fiだけで問題が起きる場合は、認証ページ、ルーターのDNS、ローカルネットワークの制限、アドレスの競合を確認します。モバイル通信だけで問題が起きる場合は、アプリのモバイルデータ通信権限と電波状況を確認してください。比較中にサブスクリプションも更新すると、選択項目が変わる可能性があるため避けてください。

ログを明確な操作と対応させる

テストの前に時刻を記録し、対象へのリクエストを一度だけ実行してから、前後のログでドメイン、適用ルール、最終ポリシー、失敗した段階を確認します。ログに名前解決の失敗だけがある場合は、DNSの章を確認します。リモートとのハンドシェイクが始まっている場合は、プロトコル設定を確認します。接続先からアクセス拒否やログイン要求が返っているなら、少なくとも一部の通信は成立しています。完全に通信できない状態と混同しないでください。エラー表示は原因を絞る手掛かりであり、設定をすべて置き換える指示ではありません。

復旧時はGlobal Routingを元のモードに戻し、必要性を確認できた変更だけを残します。ルールや自動接続条件を一時的に無効にした場合は、その理由を記録し、テスト用の状態を日常設定として残さないようにしてください。原因を特定できない場合は、個人情報を隠したエラーの概要とネットワーク比較の結果をまとめてから、カテゴリ別FAQを確認します。「接続済みだが使えない」だけの説明より、これらの情報のほうが問題の発生箇所を把握しやすくなります。

03 · リモート接続に失敗

サーバーのタイムアウト：テスト方法とプロトコル設定を分けて確認

タイムアウトは、制限時間内に操作が完了しなかったことを示します。ただし、その操作は遅延テスト、通信接続の確立、プロトコルのハンドシェイク、テスト対象へのアクセスのいずれかです。まず、タイムアウトがHomeのテスト結果なのか、実際に使ったときのリクエストログなのかを確認します。テスト先に到達できなくても項目は失敗と表示される一方、別のサービスにはアクセスできる場合があります。逆にテストに応答があっても、すべての通信が正常とは限りません。テスト結果と実際のリクエストを照らし合わせてください。

サーバーのアドレスとポートを確認

選択中の項目の編集画面を開き、利用者が持っている元のサーバー情報とアドレス、ポートを照合します。アドレス欄にWebページのパス、前後の空白、ポートの区切り記号が誤って含まれていないか確認してください。ポートは元の設定と一致させ、よく使われる数値から推測しないでください。サーバーがドメイン名で指定されている場合は、名前解決できることも確認します。IPアドレスの場合はアドレスファミリーを区別してください。サーバー側でドメインが変更された直後は、ローカルキャッシュや古い接続に以前のアドレスが残ることがあります。接続を作り直してから再確認します。

他の既存項目は正常で一つだけタイムアウトする場合は、その項目の設定やリモート側の状態に問題がある可能性が高くなります。同じ提供元の項目がすべて同時に失敗する場合は、基本ネットワーク、サブスクリプションの有効期限、リモート側の変更を確認してください。自分が持っている別の項目と比較してもかまいませんが、何度も一括テストを繰り返しても修復にはなりません。頻繁なテストは負荷を増やすだけでなく、実際の問題と無関係なリクエストをログに大量に混ぜることがあります。

ハンドシェイクの項目は一組ずつ確認

プロトコルの種類が違うと、アドレスとポートが正しくてもハンドシェイクを完了できないことがあります。Shadowsocksの暗号方式とパスワード、VMessとVLESSの認証情報、Trojanのパスワード、通信方式に関する項目を、元の設定と一つずつ照合してください。別のプロトコルの項目をそのまま流用しないでください。TLSや特定の通信方式を使う場合は、サーバー名、パス、関連するヘッダー項目もあわせて確認します。ドメイン名らしい値を一つだけ残しても不十分です。

ログに証明書関連のエラーがある場合は、まず端末の日付と時刻を確認し、次にサーバー名が設定要件と一致するか、最後にサーバー証明書の状態を確認します。警告を消すためだけに検証条件を緩めたままにしないでください。設定がUDP通信に依存する場合は、利用中のネットワークで該当する通信が許可されているかも結果に影響します。現在のネットワークで特定の通信方式が使えなくても、プロトコル名を変えれば直るとは限りません。サーバー側がその設定に対応している必要があります。

失敗した段階に応じて次の手順を決める

サーバーのドメインを名前解決できない場合は、端末側の名前解決経路を確認します。名前解決できても接続確立がタイムアウトする場合は、接続ネットワークとリモート側の待ち受け状態を確認します。すぐに接続拒否される場合は、ポートとサービスの状態を優先して確認します。接続後に認証に失敗する場合は、認証情報を照合してください。実装によってログの表現が異なるため、前後の記録も含めて判断し、英単語一つだけを根拠にしないでください。特定のネットワークでのみ発生するエラーは、ネットワーク比較の結果を残します。

サブスクリプションで管理している項目を手動で編集した場合、次回更新時に元の項目が再び反映されることがあります。一時的な比較が必要なら、独立したテスト項目としてコピーし、区別しやすい名前を付けてください。変更が保存されていないと誤解しにくくなります。確認後は不要なテスト項目を削除し、提供元が明確な正式項目を残します。接続復旧の基準は、想定した通信が成功し、ログに期待するポリシーが記録されることです。テストの数値が小さく見えることではありません。

04 · 取得と解析を分けて確認

サブスクリプションの取得失敗：リンク取得・内容解析・更新による上書きを切り分ける

サブスクリプションの更新失敗には、クライアントが応答を取得できない場合と、応答を受け取ったものの内容を解析できない場合があります。一覧が空に見えても、フィルター、折りたたまれたグループ、更新後の名称変更が原因かもしれません。元のサブスクリプションと利用可能な項目を残し、削除と追加を繰り返さないでください。更新前のグループ表示、エラー、ネットワークを記録し、Homeで一度手動更新して、ネットワーク要求とインポートのどちらで問題が起きるか確認します。

リンクの完全性と用途を確認

自分が利用している設定の提供元からサブスクリプションリンクをコピーし直し、前後の空白、改行、チャットアプリが付けた句読点がないか確認します。アクセス権を区別するためのパラメーターを欠かしたり、パラメーター以降をメモと誤認して削除したりしないでください。Web管理画面、ログインページ、サブスクリプションではリンクの用途が異なります。Webページが開けても、インポートできる内容とは限りません。QRコードがサブスクリプションURLと個別のサーバー情報のどちらを含んでいるかも確認してください。

エラーが認証、権限、内容の不存在を示している場合は、元のアカウント画面でリンクの有効性、アクセス権の変更、再発行の必要性を確認します。新しいリンクを発行すると古いリンクが無効になる場合があるため、更新前に影響する端末を確認してください。アクセス用のパラメーターを含むURLを、公開の掲示板、オンライン変換ページ、見知らぬ診断ツールに貼り付けないでください。他の人に問題を説明するときは、ドメイン、エラーの種類、パラメーター名だけを残し、値を隠します。

内容を受信できても、正しい形式とは限らない

リクエストが成功しても、本文が実際にはログインページ、アクセス案内、通常のWebページである場合があります。この場合、ネットワーク通信は完了しており、問題は内容の種類または権限にあります。解析を成功させようとしてDNSを変更し続けないでください。形式が未対応、または一部の項目を認識できないと表示される場合は、提供元の内容がShadowrocketに対応しているか確認し、個別の共有情報、サーバー一覧、Config設定ファイルを区別します。インポート方法ごとに用途が異なるため、テキスト形式だからといって相互に置き換えられるわけではありません。

更新後に一部の項目だけがなくなった場合は、それらが異なるプロトコルや新しい設定を使っていないか確認し、元の説明と照合します。項目名が変わると、古いポリシーグループが旧名を参照したままになり、一覧に項目があってもルールから選べなくなることがあります。サブスクリプションの内容、グループのフィルター、Configのポリシー参照を分けて確認してください。自分でフィルターを設定している場合は、一時的に解除して一覧全体を確認し、提供元から内容が返っていないとすぐに判断しないでください。

更新リクエストが通る経路を確認

サブスクリプションURLへのアクセスもネットワークリクエストであり、現在のネットワークや設定の影響を受ける場合があります。選択中のサーバーが使えず、更新リクエストもそのサーバーに依存していると、自力で復旧できない状態になることがあります。まず基本ネットワークが使えることを確認し、利用可能と分かっている経路で取得を試し、元のモードも記録します。現在の経路が妨げになっていると分かっている場合に限り、一時的に切り替えてください。すべてのサブスクリプションを特定の経路に固定したり、DirectまたはProxyで必ず取得できると考えたりしないでください。

手動更新に成功したら、項目がすべて揃っているか、現在の選択項目が残っているか、設定内の名前参照を変更する必要があるかを確認します。自動更新の問題では、端末がオフラインだったか、アプリが実行できる状態だったか、システム上の制限がなかったかも確認してください。自動更新が実行されなかったことと、サーバーが空の内容を返したことを混同しないでください。更新間隔を短くしても権限や形式の問題は直らず、同じ失敗を繰り返すだけです。

サブスクリプションを作り直す場合は、まず個別の項目と現在のConfigを保存し、以前のグループの用途も記録します。新しいサブスクリプションをインポートしたら、その中の項目で接続を確認してから、元のポリシー参照を調整し、最後に重複したグループを削除します。復旧とは更新ボタンのエラーが消えるだけではなく、必要な項目が表示され、正しい項目が選択され、ルールから参照できる状態です。基本的なインポート手順は使い方ガイドで確認してください。この章では失敗の原因を分けて説明しています。

05 · リクエストが完了する

速度低下・接続切れ：比較できる条件を整える

速度低下は単一の指標では判断できません。ページを開くまでの待ち時間、ダウンロード速度の低下、動画のバッファリング、接続途中の切断では、原因となる段階が異なる場合があります。まず最も再現しやすい症状を特定し、問題のない身近な対象を選び、同じネットワークで近い時間帯に少数回テストします。異なるWebサイト、ファイルサイズ、画質の結果を直接比較しないでください。遅延テストだけで継続的な通信性能を判断することもできません。

待ち時間を名前解決・ハンドシェイク・通信に分ける

初回アクセスだけが遅く、その後は正常な場合は、DNSと新しい接続の確立を確認します。ページはすぐ表示されても大きなファイルの転送が遅い場合は、帯域、混雑、接続先サービスの制限を確認します。一定時間ごとに停止して自動的に再開する場合は、ネットワークの切り替え、無線の電波状況、長時間接続の再確立を確認してください。ログからリクエストが再試行されているか分かることはありますが、クライアントのログだけでリモート経路の各区間の帯域を正確に推定することはできません。

テスト中は、クラウド同期、システムのダウンロード、大容量ファイルのアップロードなど、調査に関係しない大きな通信を端末で一時停止します。アップロードで利用可能な回線を使い切ると、通常のページ表示も遅くなることがあります。その後、端末を同じ場所に置き、自分が持っている別のサーバー情報と比較します。毎回変更するのは項目だけにし、DNS、ルール、プロトコル設定を同時に変えないでください。すべての項目で同時に遅くなる場合は、サーバー設定を一斉に変更せず、まず端末側のネットワークを確認します。

無線ネットワークと接続先サービスを別々に比較

Wi-Fiの電波が十分でも、チャンネルの混雑、ルーターの負荷、上り回線まで正常とは限りません。ルーターの近くで再テストし、可能ならモバイル通信とも比較します。ネットワークを切り替えたら接続を作り直し、以前の接続結果を新しいネットワークの評価に使わないでください。特定のローカルネットワークだけで遅い場合は、ルーターやネットワーク管理上の制限を確認します。根拠がないまま端末のネットワーク設定をすべてリセットしないでください。

特定のWebサイトだけ遅く、同じ種類の他のリクエストが正常な場合は、接続先のコンテンツ配信、アカウント状態、現在の接続元に対する制限などが関係している可能性があります。まず、遅いドメインに実際に適用されたポリシーを確認し、ページ本体とは異なる経路を通っていないか調べます。メディアの一部はメインページとは異なるドメインを使います。ルールは確認済みのリクエスト情報に基づいて動作するため、ページの見た目だけから関連データを同じ経路にすべきか自動で判断することはできません。ルールを変更した後は新しい接続で確認します。

通信切れ、UDP、パケットサイズの問題

テキストのページは開けても一部のリアルタイム通信が失敗する場合は、そのサービスがUDPに依存しているか、現在のプロトコルとネットワーク経路がその通信に対応しているか確認します。関連する項目を一つ有効にしただけで、サーバーも対応していると判断しないでください。短いリクエストは正常でも大きなリクエストが止まりやすい場合は、パケットサイズや経路の特性も確認しますが、見知らぬ数値をそのまま固定設定にしないでください。設定を試すときは元の値を記録し、一度に一項目だけ変更して、すぐ戻せるようにします。

長時間接続の切断には、画面ロック、Wi-Fiの切り替え、リモート側のタイムアウト、システムのリソース不足が関係する場合があります。切断前後の時刻と端末で行った操作を記録し、同じ条件で繰り返し起きるか確認してください。アクセスポイントの切り替え後に毎回切断する場合は、再接続で復旧するかを先に確認します。操作していないときも頻繁に再接続する場合は、リモートとのハンドシェイクと接続先からのエラーを確認してください。これらをすべて「速度が遅い」とまとめると、実際のきっかけを見落とすことがあります。

復旧後は、ネットワークの種類、現在の項目、Global Routingのモード、対象の種類、確認できた症状を基準として記録します。長時間にわたってテストする必要はなく、テストのために大量の通信を繰り返すのも避けてください。速度の変化が外部ネットワークや接続先サービスに起因する場合、クライアントの設定で解消できるとは限りません。この章では問題の範囲を切り分け、設定で改善できる部分を見つけます。一定の速度や安定時間を保証するものではありません。

06 · 名前解決とルールの照合

DNSの問題：名前解決の結果を確認してからルール経路を調べる

DNSはドメイン名をアドレスに変換し、ルールはリクエストに適用するポリシーを決定します。両者は関係しますが、同じ処理ではありません。名前解決に失敗する、結果が想定と異なる、誤った経路に接続されるなど、いずれもページが開かない症状につながります。まず、失敗したリクエストのドメインとエラーの段階を確認し、アドレスを取得できなかったのか、取得後の接続に失敗したのかを判断します。一度ページが開いたからといって、特定のDNSアドレスがすべてのネットワークに適しているとは限りません。

名前解決の経路が自分自身に依存しないようにする

編集したファイルだけでなく、現在有効なConfigとSettingsのDNS設定を確認します。DNSサービス自体をドメイン名で指定している場合、その名前を先に解決する基本経路が必要です。DNSリクエストがまだ確立していないプロキシを経由しなければならない場合は、起動時の依存関係が生じることもあります。元の設定を残したまま、DNSサービスのアドレスと到達経路を確認してください。提供元の分からないDNS設定を複数追加すると、どの設定が何を上書きしたのか特定できなくなります。

同じドメインから複数のIPv4またはIPv6アドレスが返されることがあり、ネットワークによって各アドレスへの到達性が異なる場合もあります。一部のリクエストだけ失敗する場合は、すぐに特定の機能を全体で無効にせず、実際に使われたアドレスファミリーを確認します。サーバードメインの名前解決と通信先の名前解決も分けて考えてください。前者に失敗するとプロキシ接続を確立できず、後者に失敗すると特定の接続先だけに影響する場合があります。変更後は接続を作り直し、古いキャッシュが変更を隠さないようにします。

最小限のルールでマッチの仕組みを確認

以下はルールの順序を説明するための例であり、既存ファイルを置き換える完全な設定ではありません。PROXYが参照するポリシーは、現在の設定内で有効でなければなりません。ルールは上から順に評価され、FINALは前のルールに一致しなかった場合に処理するため、末尾に置きます。FINALを前方に移動すると、それ以降のルールが適用されないことがあります。ドメイン例は構文の説明用で、特定のサービスに推奨する経路を示すものではありません。

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

リクエストがREJECTに一致した場合は、まず設定どおりの動作か確認します。ドメインルールで条件に一致したリクエストを拒否できますが、ページ内のすべての内容を判断できるわけではなく、リソースのアドレスが常に同じとも限りません。誤ってブロックしている場合は、ルール全体を削除せず、該当する範囲を狭めます。順序と機能の制約についてはREJECTルールの説明を確認し、ログで実際に一致した項目を検証してください。

設定を戻してキャッシュを確認

DNSやルールを変更した後は、接続をいったん停止して作り直し、テストするアプリも再起動して新しいリクエストが発生することを確認します。アプリがアドレスをキャッシュしたり、接続を再利用したりする場合があるため、一度更新しただけでは新しい設定が使われた証拠になりません。キャッシュを消すためにアプリを削除しないでください。まず影響の小さい再接続やアプリの再起動を試します。特定のローカルネットワークだけで失敗する場合は、そのネットワーク固有の名前解決要件や内部ドメインも確認してください。

確認には、名前解決の完了、想定したルールへの一致、接続先へのリクエスト成功のすべてが必要です。変更後に失敗段階が名前解決からハンドシェイクに移っただけなら、問題は解決していませんが、原因の特定は進んでいます。変更前後の設定差分を残し、効果のなかった変更を元に戻して、互いに上書きし合うDNS設定を蓄積しないようにしてください。よく使うキーワードの意味は用語集で、設定画面の詳しい説明は機能と設定のガイドで確認できます。

07 · 状態変化後の不具合

バッテリー消費・更新後の不具合：基準を残して差分を比較

バッテリー消費の増加と更新後の不具合を調べるには、正常時の基準が必要です。システムのバッテリー統計に表示される割合は相対値であり、同じ使い方をした場合の実際の消費増加を示すとは限りません。不具合の前に更新があったとしても、それだけで更新が原因とは言えません。端末の使用時間、画面の状態、ネットワークの種類、バックグラウンドタスクを記録し、最後に正常だったときの設定、サブスクリプション、システムの状態と比較します。設定のロールバック、サブスクリプションの再作成、ネットワークのリセットを同時に行うと、判断材料が失われます。

正常な通信と繰り返しの失敗を見分ける

継続的なアップロード、動画再生、クラウド同期はいずれもネットワーク通信を増やします。通信がShadowrocketを経由する設定では、関連する通信がシステムの統計に反映されることもあります。端末を使った時間が近い条件で比較し、一日分の統計と短時間の待機状態を直接比べないでください。画面をオフにしている間に主に発生する場合は、接続の失敗と再試行、頻繁なテストや更新タスクがないか確認し、ログから実際に通信が繰り返されているか調べます。

一時的に詳細ログをオフにし、不要な連続テストを停止すると、余計な処理を切り分けやすくなります。ただし、その前に現在の不具合に関係するログを保存してください。不安定なネットワークでOn Demandが再接続を繰り返していないか、Wi-Fiとモバイル通信の間を頻繁に切り替えていないかも確認します。統計上の割合を減らすために必要な機能を恒久的に停止するのではなく、どの動作が消費増加と一貫して関係しているかを確かめてから、該当する条件を調整します。

更新後は3種類の変化を確認

1つ目はアプリまたはシステムの更新で接続状態が変わり、権限の確認や接続の再作成が必要になったケースです。2つ目はサブスクリプションの内容が変わり、以前の項目やポリシー名がなくなったケースです。3つ目はConfigが更新され、ルール、DNS、外部参照が以前のファイルと異なるケースです。実際にどの変化が起きたかを特定して、該当する章を確認してください。特定のファイルだけに問題がある場合は、アプリを再インストールするより、保存しておいた設定のコピーに戻すほうが、ファイルの差分が原因か確認しやすくなります。

更新前に現在のConfig、個別のサーバー項目、必要なグループ構成を保存し、バックアップを読み込めることも確認してください。サブスクリプションリンクは完全なバックアップではありません。個別項目、手動ルール、一部の端末内設定は含まれない場合があります。更新後は元の選択状態を保ち、よく使う対象への通信を一つ確認してから、自動更新や一括操作を再開します。こうすれば問題が見つかっても変更範囲が小さく、複数の上書きが重なった状態ではなく、項目ごとに比較できます。

クライアントを再入手する際の注意

再入手する場合、iPhone / iPadではApp Storeで開発者名Shadow Launch Technology Limited、公式アイコン、アプリID 932747118を確認してください。システム要件はApp Storeの掲載内容をご確認ください。MacではAppleシリコンかIntelかを確認してから、該当するパッケージを選びます。その他のプラットフォームではダウンロードガイドから本サイトの/dl/インストーラーを利用してください。再入手してもリモート接続の問題が解決するとは限りません。操作前に端末内のデータを保存してください。

デスクトップ版とAndroid版を初めて起動すると、システムにブロックされる場合があります。入手元を確認したうえで、Macは「プライバシーとセキュリティ」でシステムの案内に従い「このまま開く」を選択できます。Windows SmartScreenでは、入手元を確認してから「詳細情報」を開き、「実行」を続けるか判断してください。Androidでは、インストールに使う入手元に限って必要に応じて不明なアプリのインストールを許可し、完了後に権限を取り消せます。Linuxでは選択したパッケージ形式に従ってください。AppImageには実行権限が必要です。詳しい条件はインストール時の許可に関する説明をご覧ください。入手元を確認せずに実行を許可しないでください。

接続を作り直し、設定を復元しても問題が続く場合は、更新前後の差分と最小限の再現手順をまとめます。操作した内容、期待した結果、実際の結果、発生頻度を記載し、完全な認証情報は含めないでください。正常に動作する設定のコピーを残し、必要な項目を一つずつ追加します。特定の項目が安定して不具合を引き起こすことが分かったら、それ以上変更範囲を広げないでください。こうすれば利用できる基準状態を保ち、一時的な復旧を問題全体の解決と誤認することも避けられます。

08 · 端末・ネットワーク別の確認

iPadの確認ポイント：ネットワーク切り替え・画面ロック・ローカルネットワーク

iPadの調査では専用のルールを作るのではなく、他の端末と比べて環境がどう違うかを確認します。同じサブスクリプションがiPhoneでは正常でiPadでは異常でも、確認できる差があるというだけで、iPadに別のプロトコルが必要だとは限りません。まず2台を同じネットワーク、同じ項目、同じConfig、同じGlobal Routingモードに揃えてから、リクエストの結果を比較します。端末と設定の違いを混同しないでください。

Wi-Fi・モバイル通信・テザリングの切り替え

Wi-FiのみのiPadとモバイル通信に対応した端末では、比較できる条件が完全に同じとは限りません。個人用ホットスポットを使う場合は、ホットスポットも異なる接続経路として個別に記録します。切り替えるたびに、システムが利用可能なネットワークを取得したことを確認してから、Shadowrocketを再接続してください。Web認証が必要な場合は先に完了します。端末に以前のネットワーク名が表示されたままの場合や、接続先が何度も変わる場合は、まずネットワークの安定性を確認してください。

自宅から職場のネットワークに移動すると、以前の長時間接続が一時的に使えなくなる場合があります。接続中と表示されていても、古い接続が新しいネットワークへ正常に移行したとは限りません。いったん切断して再接続し、同じ対象へリクエストを送ってください。再接続で復旧する場合は、切り替え操作とOn Demandの条件を記録します。再接続しても失敗する場合は、基本ネットワークとサーバーの到達性を確認してください。ネットワーク切り替え時に一度失敗しただけで、すべてのルールを恒久的に変更したり、サブスクリプションを削除したりしないでください。

画面ロック・マルチタスク・アプリの接続再利用

画面ロックから復帰した後、アプリが以前のセッションを使い続けることも、新しい接続を開始することもあります。復帰後の最初のリクエストだけで起きるのか、その後のリクエストもすべて失敗するのか確認してください。対象アプリを再起動すると復旧する場合は、アプリのセッション再利用をさらに調べます。すべてのアプリが同時に失敗する場合は、システムの接続状態を確認してください。2つのアプリを画面分割で使って同じWebページが表示されても、通信経路が同じとは限りません。それぞれのアプリが利用するドメインを確認してください。

バックグラウンドで長時間通信を続けられるかは、対象アプリとシステムのバックグラウンド実行条件にも左右されます。Shadowrocketの接続状態は、対象アプリがバックグラウンドで動作できることを保証しません。ダウンロードの一時停止をすべてルールの問題と決めつけないでください。まず対象アプリを前面に表示したまま通信が正常か確認し、その後、画面ロック中の動作と比較します。端末の温度、低バッテリー状態、システムのリソース不足も記録しますが、関連する症状だけで設定の問題だと断定しないでください。

ローカルネットワークへのアクセスと端末間の設定

接続後にプリンターが見つからない、ローカルの管理画面にアクセスできない、LAN上の端末につながらない場合は、まず接続を停止して基本状態と比較し、対象機器とiPadが同じLANにあるか確認します。名前による機器の検出と、アドレスを指定した直接アクセスは別のリクエストです。検出に失敗しても、ローカル接続がすべて失敗しているとは限りません。ローカルネットワークへの権限、実際の接続先アドレス、適用されたポリシーを確認し、現在のネットワーク構成に合わせて設定します。用途の分からないファイルに、すべてのプライベートアドレス範囲をそのまま追加しないでください。

他の端末から設定をコピーした場合は、ポリシー参照と個別項目が揃っているか再確認します。名前が同じでも内部の設定が同じとは限りません。設定ファイルが使えても、この端末でシステムの許可が完了しているとは限りません。サブスクリプションの更新で項目名が変わると、古いルールが以前の名前を参照したままになり、端末ごとに動作が異なることがあります。最初にインポートしたファイル名ではなく、現在有効な内容を比較してください。必要なら同じバックアップを復元し、条件を揃えてテストします。

この章では、日常的な3つの操作を確認します。通常使用時にリクエストが成功すること、利用可能なネットワークへ切り替えた後に接続を再確立できること、画面ロックから復帰した後に新しいリクエストが発生することです。いずれかで失敗する場合は、設定変更の範囲を広げず、発生したきっかけに対応する章へ戻ってください。原因を特定できない場合は、個人情報を隠したログの概要、モード、ネットワーク比較の結果を残します。基本操作は基本の使い方ガイド、用語は用語集、よくある質問はFAQをご覧ください。