Shadowrocket トラブル対処ガイド

接続スイッチがオンにならない：まずシステムの接続設定を確認

Homeでスイッチをオンにしてもすぐに戻る場合、接続の確立が完了していない可能性があります。スイッチはオンのままなのにウェブページを開けない問題とは異なります。まず、VPN構成の追加許可を求めるシステムの通知が表示されるか、具体的なエラーが出るか、タップ後どの段階で元に戻るかを確認してください。ステータスバーのアイコンだけで接続成功と判断しないでください。表示位置はシステムのレイアウトによって異なることがあります。Homeの状態とエラーの原文を確認し、スイッチを何度も素早くタップするのは避けてください。

許可待ち・構成の競合・接続失敗を切り分ける

初めて有効にするときは、VPN構成の追加をシステムで許可する必要があります。確認を取り消したことがある場合は、Shadowrocketに戻って再度操作し、システムの通知に従って許可してください。デバイスのパスコードはシステム画面で入力します。続いてシステムのSettingsでVPN構成が存在するか、どの構成が現在有効かを確認します。複数のVPN構成が残っていても問題とは限りませんが、別の接続を同時に開始すると現在の接続が中断される場合があります。ほかのVPN接続を停止し、Shadowrocketだけでテストしてください。ネットワーク設定をすべて削除する必要はありません。

学校や職場の管理対象デバイスで、許可スイッチを操作できない、構成を追加できない、または管理上の制限が表示される場合は、デバイス管理者にポリシーを確認してください。アプリを削除しても制限は解除されず、ローカル設定を失う可能性があります。個人所有のデバイスでは、自動接続ルールが有効になっていないか確認してください。手動で停止した直後に再びオンになる場合、スイッチの故障ではなくOn Demandが作動している可能性があります。条件を記録し、一時的に自動接続を無効にして確認してください。詳しくはバッテリー消費とOn Demandの章をご覧ください。

最小限の設定で問題の範囲を特定する

Homeで必要な項目がそろったサーバーがあり、それがデフォルトサーバーとして選択されていることを確認してください。リストに取り込んだだけでデフォルトを選んでいない場合、接続テストの条件が整っていません。ルールファイルの影響を減らすため、Global Routingを一時的にProxyにして起動します。それでもすぐに元に戻る場合は、許可設定、システムのネットワーク拡張機能の状態、サーバー情報の誤りを優先して確認してください。オンの状態を維持できる場合は、元のConfig設定やポリシー参照を確認します。テスト後は元のルーティング設定に戻してください。

現在の.confファイルと必要なサーバー情報を保存してから、アプリの接続を正常に切断し、アプリを開き直してテストできます。ネットワーク切り替え後に問題が起きた場合は、現在のWi-Fiでログイン認証が済んでいるか、またはモバイルデータで通常のウェブページにアクセスできるかを確認してください。ネットワークへのログインが必要な場合、認証が終わる前にプロキシ接続を開始すると失敗することがあります。先に接続を切って認証を済ませてから、Shadowrocketを起動してください。ログインページを開けないだけでサーバー障害と判断したり、不明な画面にサブスクリプションの認証情報を入力したりしないでください。

システム構成を再作成する場合

ネットワークが正常で、デフォルトサーバーが明確に選択されているにもかかわらず、許可手順に繰り返し問題が起きる場合に限り、Shadowrocketに対応するシステムのVPN構成を作り直します。操作前にアプリ内の設定をバックアップし、接続を停止してOn Demandをオフにしてください。システム設定で対象の構成を正確に特定します。その構成を削除してからアプリに戻り、接続を開始してシステムの許可を再度求めます。この操作で解決できるのはシステム接続構成の問題だけです。誤ったアドレス、ポート、パスワードは修正されないため、すべての問題に対する最初の手順にしないでください。

システムのアップデート後に初めて接続が元に戻るようになった場合は、再インストールを繰り返すのではなく、まずデバイスを再起動して最小限の設定で再確認してください。「許可の通知が表示されるか」「構成が作成されるか」「接続を維持できるか」の3点を記録すると、原因を絞り込みやすくなります。復旧後は、元のルール、自動接続、追加設定を1つずつ有効にしてください。設定を戻すたびにテストし、特定の項目を有効にした直後に再発した場合は、その項目の依存関係と設定内容を確認します。許可に関するよくある質問はFAQをご覧ください。

接続中なのにインターネットに接続できない：4つの層を順に確認

接続スイッチがオンのままでも、システム接続が動作していることを示すだけで、サーバーが通信を転送できるとは限りません。まずShadowrocketを切断し、同じネットワークで普段アクセスできるウェブページを開いて、基本ネットワーク、Wi-Fiの認証、モバイルデータの利用が正常か確認してください。その後再接続し、デフォルトサーバー、Global Routing、DNS、ルールの適用状況を順番に調べます。毎回同じ接続先を使い、失敗がタイムアウト、名前解決エラー、証明書の警告、サーバー側のエラーのどれに当たるか記録してください。それぞれ確認すべき箇所が異なります。

まずサーバーを確認し、3種類のルーティング設定を比較する

Homeでデフォルトサーバーが想定した項目を指しているか確認してください。サブスクリプションの更新、古い項目の削除、グループの切り替え後は特に注意が必要です。Connectivity Testで接続結果を確認できますが、1つのテスト結果だけで実際の通信がすべて可能だと判断しないでください。テストに成功しても目的のサイトを開けない場合、接続先への経路、DNS、プロトコルの通信方式が原因の可能性があります。ほかに利用可能なサーバーがあれば、デフォルトだけを切り替えて比較します。切り替えた後は接続し直し、以前の接続結果を新しいサーバーの結果と取り違えないようにしてください。

3種類の設定を試す目的は、どれか1つを常用することではなく、比較できる条件を作ることです。Directで通信できてProxyではできない場合、サーバー情報とネットワークからの到達性を確認してください。Proxyでは通信できてConfigではできない場合、ルールの順序、ポリシー名、有効な設定ファイルを確認します。どの設定でも通信できない場合は、追加のルールを作る前に基本ネットワークとDNSを確認してください。原因を特定したら、用途に合ったConfigに戻し、参照先のポリシーが存在することを確認します。

キーワードだけでなく、ルールの適用順を確認する

[Rule]は通常、上から順に判定されます。上位の範囲が広いルールが、下位の詳細なルールより先に適用されることがあります。次の説明は順序を示すためのものです。example.comはサンプル用ドメインであり、そのまま完全な設定の代わりにはできません。DOMAIN-SUFFIXは対象ドメインとそのサブドメインに適用されます。GEOIPは接続先IPの地域情報に基づいて判定します。FINALは、それより前のルールに一致しない場合の最終ルールです。名前解決の結果、ルールの適用範囲、実際のポリシーをあわせて確認してください。ファイルにPROXYがあるだけで、通信が必ずプロキシ経由になるとは限りません。

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

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

元の設定でカスタムポリシーグループを使っている場合は、グループ名のつづりが一致しているか、グループ内に利用可能な項目が残っているか、サブスクリプション更新後に選択内容が変わっていないか確認してください。ファイルを編集する前に別名で保存し、元に戻せる状態を残します。特定のサイトだけで問題が起きる場合は、そのドメインに対する一時的なルールで原因を検証します。検証後に正式な設定へ反映するか判断してください。問題を隠すために広範囲なDOMAIN-KEYWORDを使ったり、後続ルールを上書きする位置にFINALを移動したりしないでください。

ブラウザーのキャッシュとシステムの状態を分けて確認する

ブラウザーに以前のページ、接続、名前解決の結果が残っていることがあります。モードを切り替えた後は、以前の読み込み表示を見るだけでなく、新しいリクエストを送信してください。失敗したページを閉じて開き直し、必要なら未訪問のテスト先を使い、別のアプリでも比較します。1つのサイトだけで問題が起きる場合は、そのサイトの状態と証明書を確認してください。それだけを根拠にすべての接続をリセットしないでください。複数のドメインで失敗する一方、接続自体は維持されている場合は、次の手順でDNSを確認します。詳しくはDNSの章をご覧ください。

サーバーがタイムアウトする：設定値と通信経路を確認

タイムアウトは、制限時間内に期待した応答を受け取れなかったことを示します。パスワードが必ず間違っている、またはサーバーが停止しているという意味ではありません。名前解決、アドレスへの到達、ポート接続、TLSハンドシェイク、プロトコル認証のいずれかで止まっている可能性があります。まずテストの種類とエラーの原文を保存し、Connectivity Testでのタイムアウトか、実際のウェブページでのタイムアウトかを確認してください。サーバーによっては特定の確認方法に応答しないため、テスト失敗だけで設定を削除せず、実際のリクエストでも確認します。

登録済みのサーバー情報と項目ごとに照合する

Add Serverから該当項目を開き、ご自身のサービス提供元から受け取った情報と1項目ずつ照合してください。サーバーアドレスにパス、空白、プロトコルの接頭辞を混ぜないでください。ポートは指定された接続先の要件に合わせます。パスワードやUUIDなどの認証情報は大文字・小文字や記号を含めて完全に保持し、コピー時に末尾の改行が入っていないか確認してください。見た目が似ていても別の項目を置き換えないでください。また、サブスクリプションURLをサーバーアドレス欄に入力しないでください。QRコードから取り込んだ場合も、プロトコルの種類と主要な項目を確認します。取り込みに成功したことは、現在のネットワークで設定が有効であることを意味しません。

この表は確認の方向を示すもので、汎用の入力テンプレートではありません。各項目に何を入力するかは、実際に設定されているサーバー情報に従ってください。詳しくはプロトコルと設定項目の概要をご覧ください。サーバー情報がサブスクリプション経由の場合は、まず通常の更新を試し、項目を比較してください。サブスクリプションから生成された項目を直接編集すると、次回の更新で上書きされ、一時的に解決した設定が再び変わることがあります。

TLS、通信方式、UDPを分けて確認する

TLSハンドシェイクや証明書に関するエラーが出る場合は、デバイスの日付と時刻が正しいか、サーバー名が提供された情報と一致しているか確認してください。接続先アドレスと証明書の検証名が異なることはありますが、実際の設定に従って入力する必要があります。エラーを回避するために証明書の検証を無効にしたまま使わないでください。名前の誤り、証明書の期限切れ、接続先の間違いを見逃す原因になります。特定の通信方式を使う場合は、Hostやパスなどもサーバー側の設定に合わせます。アドレスと認証情報だけでは十分に確認できません。

通常のウェブページで確認できるのは、そのページへの通信経路が使えることです。すべてのUDP通信が可能かどうかは分かりません。同じ設定でウェブ閲覧はできても、リアルタイム通信やUDPを使う機能に問題がある場合は、プロトコルの対応状況、サーバー側の条件、現在のネットワークで対象の通信が許可されているか確認してください。ほかの有効な設定と比較する場合は、変更する条件を1つに絞ります。たとえば、同じネットワークでサーバーだけを変えるか、同じサーバーでネットワークだけを変えます。プロトコル、ネットワーク、DNSを同時に変更して復旧しても、原因を特定できません。

ネットワークを比較して問題の範囲を特定する

Wi-Fiではタイムアウトするのにモバイルデータでは正常な場合、Wi-Fi側の名前解決、ポート、通信条件が関係している可能性があります。ただし、ネットワークごとに異なるアドレスへ接続している場合もあります。結論を出す前に、名前解決の結果と接続先を確認してください。複数のネットワークで同じサーバーだけが失敗し、ほかの登録済みサーバーは正常な場合は、サービス提供元に接続先の変更がないか確認します。問い合わせにはプロトコルの種類、エラーの原文、再現条件を伝えれば十分です。パスワード、鍵、サブスクリプションのトークン、全項目を含むQRコードは送らないでください。

サーバー情報が正しいと確認できたら、端末側のテストに戻ります。デフォルトサーバーを選択し、一時的にProxyを使って接続し直し、同じ接続先を開いてください。復旧した場合はConfigと自動接続を1つずつ戻します。引き続き失敗する場合は、「基本ネットワークは正常」「ほかのサーバーは利用できる」「このサーバーは2つのネットワークでタイムアウトする」という結果を記録してください。待ち時間を延ばし続けるより、原因の特定に役立ちます。待ち時間を長くしてもエラーが出るまでの時間が変わるだけで、到達できないアドレス、誤ったポート、通信設定の不一致は直りません。

サブスクリプションを更新できない：ダウンロードと解析を切り分ける

サブスクリプションの更新には、リモートの内容を取得する処理と、その内容をサーバー項目として解析する処理があります。サブスクリプションURLにアクセスできない場合、認証が無効になった場合、内容の形式が一致しない場合は、それぞれ別に対処します。開始前に利用可能な既存項目と設定を保存し、エラーの原文、既存項目が残っているか、手動更新と自動更新のどちらで失敗したかを記録してください。再試行のためにサブスクリプション全体を削除しないでください。リモートに一時的にアクセスできない場合、ローカルの内容を削除すると、最後に利用できた接続手段まで失うことがあります。

URLの完全性とアクセス条件を確認する

サブスクリプションURLは、ご自身のサービス提供元から入手し、クライアントへの取り込み用URLであることを確認してください。ログインページ、ヘルプページ、アカウントページのURLとは異なります。コピー時は先頭、パス、クエリパラメーターを照合し、画面に表示された一部だけをコピーしないようにします。サブスクリプション内のトークンはアクセスに使われるため、検索欄や公開メモ、公開スクリーンショットに載せないでください。URLが画面上で改行されていても問題とは限りませんが、コピー時に空白を入れたり、パラメーターを省いたり、句読点まで含めたりすると失敗します。

ログインページ、アクセス確認ページ、通常のウェブページが返される場合、リクエスト先の内容が想定したサブスクリプションではありません。Shadowrocketでプロトコルを何度も切り替えるのではなく、提供元の取り込み手順とアカウントの状態を確認してください。認証エラーが表示される場合も、URLが再発行されたか無効になっていないか確認します。クライアント側で、リモートサービスにより取り消されたトークンを復元することはできません。提供元へ問い合わせる場合は、エラーの状態と発生した時間帯を伝え、アクセスURL全体を公開の場に送らないでください。

更新に現在の接続が必要か確認する

現在の基本ネットワークから直接アクセスできないサブスクリプションURLでも、ご自身が利用できる接続を通すと内容を取得できる場合があります。切断時と接続時の更新結果を比べ、そのときに使用したデフォルトサーバーも記録してください。接続中だけ更新できる場合は、サブスクリプションのダウンロード経路に問題がある可能性があります。切断時だけ成功する場合は、プロキシ経路または名前解決がダウンロードに影響している可能性があります。この結果をすべてのサブスクリプションに当てはめず、現在のネットワークでの実際の動作に基づいて判断してください。

循環依存が起きている場合は、特に慎重に対処してください。リモートのサブスクリプションを一時的に取得できず、ローカルの項目もすべて無効になっている場合、更新ボタンを繰り返し押しても利用可能な情報は作成されません。ご自身が持っているサーバー情報から有効な項目を復元するか、元のサービス提供元にアクセス条件を確認してください。Shadowrocketは既存の情報を利用するアプリであり、接続サービスは提供しません。更新方法を設定する前に、手動更新ができることを確認してください。その後、自動更新の実行条件を調べます。自動更新の失敗だけで、サブスクリプション全体が壊れていると判断しないでください。

ダウンロード後に一覧がおかしい場合は形式を確認する

内容を取得できても、解析できない、項目が空、プロトコル情報が欠けていると表示される場合は、取り込み方法がサブスクリプションの形式に合っているか確認してください。サーバー情報を提供するサブスクリプションと、ルーティングやDNSなどの設定も含む場合がある.confファイルは用途が異なります。両者をそのまま置き換えたり、拡張子が似ているだけで取り込み先を選んだりしないでください。内容を手動で確認する場合は認証情報が含まれている可能性に注意し、必要な場合も構造だけを確認して全文を外部ツールにコピーしないでください。

更新後に項目数や名前が変わっても、必ずしも不具合とは限りません。リモートの内容が変更された可能性があります。まず新しい一覧に必要な項目があるか確認し、次にデフォルトサーバーとカスタムポリシーグループが有効か確認してください。ルールが削除済みの名前を参照している場合、更新は成功しても通信できないことがあります。その場合はルーティングのトラブル対処に進み、ダウンロードを繰り返さないでください。更新前後の違いを記録してから有効な参照先に戻すことで、連続して起きた2つの問題を同じ原因と取り違えずに済みます。

修復後は、復元できる設定ファイルを1つ保存し、ご自身のサブスクリプションの入手元に関する情報も適切に保管してください。バックアップは保護された場所に置き、公開文書と混在させないようにします。サブスクリプションURL全体を公開してしまった場合は、元のサービス提供元に連絡してトークンを変更し、クライアントのURLも更新してください。公開したスクリーンショットを削除するだけでは、古い認証情報が無効になるとは限りません。取り込みからの手順全体は使い方ガイドをご覧ください。この章ではダウンロード、解析、参照に関する問題を扱います。

速度低下・断続的な切断：比較できる条件を整える

速度が遅いという症状は、最初のページ表示に時間がかかる、ダウンロード速度が低い、動画が何度も停止する、ネットワーク切り替え時に一時的に切断されるなど、さまざまです。それぞれ別の現象なので、まず具体的な症状を整理してからテストしてください。Connectivity Testの遅延時間は、大容量ファイルの転送速度を直接示すものではありません。ウェブページが速く開いても、長時間の接続が安定するとは限りません。アクセス可能なテスト先を1つ決め、近い条件で比較してください。時間、サイト、ネットワークが異なる結果を混ぜて、サーバーの優劣を判断しないでください。

端末のネットワーク、サーバー、接続先の問題を切り分ける

接続を切り、現在のWi-Fiまたはモバイルネットワークにも明らかな遅延がないか確認します。Wi-Fiのアンテナ表示は無線状態の一部を示すだけで、上り速度、混雑、パケットロスが正常かどうかは分かりません。アクセスポイントに近づき、ほかのデバイスによる大容量通信を一時停止してから、同じ接続先を再度確認してください。直接接続でも遅い場合は、まずローカルネットワークを調べます。この段階でプロキシのプロトコルを切り替えたりルールを変更したりしても、無線干渉、基本帯域の不足、ネットワーク認証の未完了は通常解決しません。

基本ネットワークが正常なら、ネットワークと接続先を変えずに、ご自身が利用できる別のサーバーへ切り替えます。1台だけ遅い場合は、そのサーバーへの経路、負荷、サーバー側の制限を確認します。すべてのサーバーで同じ接続先が遅い場合は、接続先自体または共通の通信経路が原因かもしれません。サービス提供元に問い合わせる際は、ネットワークの種類、接続先のカテゴリ、特定の接続先だけで起きるかを伝えてください。認証情報全体を送る必要はありません。複数のテストを同時に大量実行すると、テスト自体が帯域を消費して結果に影響するため避けてください。

名前解決、接続確立、データ転送の遅れを切り分ける

最初の表示は遅いのに2回目は明らかに速い場合、DNSキャッシュ、接続の再利用、接続先のキャッシュが関係している可能性があります。すぐに帯域の問題と判断しないでください。遅れがページを開く前に起きるのか、読み込み開始後に起きるのかを確認します。初めて開く複数のドメインで読み込み開始前に停止する場合はDNSを確認します。名前解決後も長く待つ場合は、サーバーへの接続確立とTLSを確認してください。読み込みはすぐ始まるのに転送が遅い場合は、混雑、サーバーの転送能力、接続先の制限を調べます。

ConfigとProxyの比較も原因の特定に役立ちます。Proxyでは正常なのにConfigで特定の接続先が遅い場合、ルールによって別の経路に送られているか、カスタムポリシーグループで別の項目が選ばれている可能性があります。デフォルトサーバーの名前だけでなく、現在のファイルとポリシー参照を確認してください。接続先がDIRECTルールに一致している場合、一覧で選択したプロキシサーバーはそのリクエストに使われないことがあります。比較時は新しいリクエストを送り、既存の長時間接続が以前の経路を引き継いだために誤判定しないようにしてください。

ネットワーク切り替えと長時間接続の中断を確認する

Wi-Fiからモバイルデータに切り替えると、デバイスのアドレスや通信経路が変わり、既存の長時間接続を維持できないことがあります。一時的な復旧と、再接続できない状態が続く場合は分けて考えてください。切り替え後に新しいウェブページは開けるのに、以前からのセッションが停止している場合は、そのセッションを再接続します。すべてのリクエストが止まった場合は、Shadowrocketを切断して再接続してください。ネットワークを切り替えるたびに再現するか記録し、2種類のネットワーク間でOn Demandが繰り返し作動していないか確認します。

リアルタイム通信、ゲーム、その他の特定の用途だけが中断する場合は、その用途がUDPを使うか、サーバー、プロトコル、現在のネットワークが必要な条件を満たしているか確認してください。ウェブ閲覧が正常だからといって通信方式の違いを除外しないでください。また、根拠なくMTUなどの低レベル設定を変更しないでください。調整が必要な場合は、まず元の値を記録し、一度に1項目だけ変更して同じ用途で再確認します。改善を確認できなければ元に戻し、ほかの用途に長期的な影響を残さないようにしてください。

テストの結果は、「同じWi-Fi、同じ接続先で、サーバーAだけ転送が続かない」または「新しいドメインへの初回アクセスは遅いが、接続確立後の速度は正常」のように、明確な結論としてまとめます。次に確認すべきことが分かりやすくなります。最速値だけでは十分な情報になりません。繰り返しテストしたときの安定性、再接続の有無、バックグラウンド処理の影響も確認してください。テスト後は一時的な確認設定をオフにしてConfigを元に戻し、診断用の通信が日常利用に影響し続けないようにします。

DNSの問題：名前解決と接続の境目から判断

DNSはドメイン名を接続に必要なアドレスへ変換します。サーバー自体にも接続先のウェブサイトにもドメイン名が使われるため、名前解決の失敗はプロキシサーバーへの接続を妨げることも、特定のウェブサイトだけに影響することもあります。新しいドメインを開けない、既存の接続は使える、同じサーバーでもネットワークによって結果が異なる、といった症状が見られます。ブラウザーのエラーは手掛かりになりますが、「開けない」というだけでDNSの問題と断定しないでください。基本ネットワークとサーバーのポートに到達できるかを先に確認します。

まず正常な名前解決の基準を確認する

変更する前に現在の設定を保存し、[General]内のDNS関連の設定を記録してください。以下の例では、診断の出発点としてシステムのDNSを使います。すべてのネットワークに適しているとは限らず、すべてのドメインの要件を満たすとも限りません。まず現在のネットワークでシステムの名前解決が正常か確認し、そのうえで継続使用するか判断してください。確認できていないDNS設定を複数追加しないでください。設定が複雑になると、どの経路を使ったのか、失敗の原因がDNSサーバーかDNSサーバーへの接続かを特定しにくくなります。

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

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

元の設定にリモートDNS、暗号化DNS、特定ドメイン向けの処理が含まれている場合、元に戻す際は各設定の依存関係に注意してください。1行だけ変更しても、別のセクションが結果に影響し続けることがあります。慣れていない項目は、まずファイルを複製してテスト用の設定を作り、1つずつ削除または復元してください。設定の構成は.confファイルのセクション解説を参考にできます。適用範囲を把握しないまま、複数の設定元から内容を貼り合わせないでください。

ブラウザーでIPアドレスを直接開く方法だけで判断しない

HTTPSサイトでは、正しいドメイン名、証明書の名前、リクエスト情報が必要です。ブラウザーにIPアドレスを直接入力して失敗しても、それだけではDNSの正常・異常を判断できません。特定のIPアドレスが開けても、元のドメイン名が正しく名前解決されるとは限りません。アプリで確認できるリクエスト情報や診断情報を使い、名前解決のエラーと接続確立のエラーを区別して複数の接続先を比較する方法が確実です。ログにはアクセス先のドメイン名が含まれる場合があります。共有前に必要に応じて隠してください。

同じドメインから複数のIPv4アドレスやIPv6アドレスが返されることがあり、ネットワークによって結果が異なる場合もあります。特定のネットワークだけで繰り返し失敗する場合は、実際に使われたアドレスの種類と接続結果を記録し、該当する経路を確認してください。IPv6が表示されただけで原因と断定したり、特定のアドレス種別を全体で無効にしたりしないでください。診断のための変更には比較と復元記録が必要です。1つの接続先の特定アドレスだけに到達できない場合は、すべてのリクエストの動作を変えるのではなく、その経路に絞って対処します。

Hostの上書き、ルール、キャッシュの影響を確認する

[Host]に静的なマッピングが設定されていると、外部DNSが変わっても特定のドメインが古いアドレスを使い続けることがあります。特定のドメインだけに問題がある場合は、関連するマッピングが存在するか、その設定元と用途を確認してください。一度の障害を回避するために、長期間使うIPアドレスのマッピングを安易に追加しないでください。接続先アドレスが変わり、証明書やサーバーの経路にも影響する可能性があります。一時的にマッピングを削除する場合は、先にバックアップを取り、再確認で改善したことを確かめてから恒久的に変更するか判断します。

ルールによっても、名前解決後の接続経路が変わります。DOMAIN系のルールはドメイン名で照合し、GEOIPやIP-CIDR系のルールはアドレスに関する情報で判定します。照合条件は異なります。ドメインが想定外のアドレス範囲に解決されると、その後に適用されるポリシーも変わる可能性があります。「どのアドレスに解決されたか」と「最終的にどのポリシーを通ったか」の両方を確認してください。GEOIPルールが1つあるだけで、すべての接続先が同じように振り分けられると判断したり、広範囲なルールで未特定の名前解決問題を覆い隠したりしないでください。

設定を変更した後は新しいリクエストを送って確認してください。既存の接続やキャッシュが古い結果を一時的に使い続ける場合があります。再接続し、テストページを開き直し、以前にアクセスしたことのないドメインと比較します。毎回デバイス全体のネットワーク設定をリセットする必要はありません。新しいリクエストが安定してから、必要なカスタムDNS設定を戻してください。用途が明確な最小限の設定だけを残し、各設定で解決した問題を記録しておくと、設定を移行する際に古い対処法まで持ち込まずに済みます。

バッテリー消費とOn Demand：継続的な動作の原因を確認

システムのバッテリー使用状況にShadowrocketの動作が表示されても、アプリが異常なタスクを続けているとは限りません。プロキシ接続中は、ほかのアプリが発生させる通信も処理されるため、使用時間、通信量、電波状況、接続が頻繁に再確立されていないかをあわせて確認してください。バッテリー消費が待機中、動画再生中、ファイル転送中、ネットワーク切り替え中のどの状況で起きたかを記録し、近い条件と比較します。日によって使用状況は大きく異なるため、バッテリー使用率だけでアプリによる追加消費を計算することはできません。

再接続、接続テスト、大量通信の影響を確認する

電波が弱いネットワークでデバイスが頻繁に再接続している場合、接続の確立、再度の名前解決、セッションの復旧が繰り返されることがあります。まず接続が安定しているかを確認し、その後にルールの見直しを検討してください。比較する際は電波が安定したネットワークを選び、同じサーバーを使い、不要なダウンロードやクラウド同期を停止し、診断中に有効にした連続テストもオフにします。バッテリー消費を調べるために大量の速度テストを同時に実行しないでください。テスト自体が通信を発生させ、観察対象の条件を変えるため、通常の待機時の結果にはなりません。

ログの継続記録、頻繁な接続テスト、失敗後の大量の再試行も確認してください。問題調査のために記録レベルを上げていた場合は、原因特定後に通常の設定へ戻し、機密情報を含む記録を適切に扱います。特定のアプリがバックグラウンドで失敗するドメインへ繰り返し接続していないか、接続が不安定なため同期処理が何度もアップロードしていないか確認してください。この場合、単にプロキシスイッチの問題と判断せず、該当する通信の問題を先に解決します。リクエストの発生元と動作時間を照らし合わせることで、どの層を調整すべきか判断できます。

On Demandと手動スイッチの関係

On Demandは条件に応じて接続動作を開始します。手動でオフにしてすぐオンに戻る場合は、スイッチの不具合と判断する前に、条件が引き続き満たされていないか確認してください。設定されたネットワーク条件と、デバイスが頻繁にネットワークを切り替えていないかを記録します。比較のためにOn Demandを一時的にオフにし、ほかの設定は変えずに手動接続が安定するか確認してください。テスト後は必要に応じて元に戻し、トラブル対処後に自動接続をオフにしたまま忘れないようにしてください。

条件を設定し直す場合は、単純で動作を説明しやすいルールから始めます。対象のネットワークで作動し、対象外の条件では作動しないことを確認してから、ほかの条件を追加してください。複数のルールが重なると、想定と実際のシステムの判定が異なることがあります。ネットワーク名、作動条件、サーバー選択を同時に変更しないでください。どの変更で改善したか特定できなくなります。学校や職場の管理対象デバイスでは、管理ポリシーも確認し、システムによる強制動作と個人のOn Demand設定を混同しないでください。

再現できる条件でバッテリー消費を比較する

近い時間帯を選び、画面の使用状況、ネットワークの種類、サーバー、バックグラウンドタスクをできるだけそろえ、接続の安定性、発熱の有無、システムに表示される動作状況を記録してください。特定の機器に共通する割合を求めるのではなく、同じ傾向が繰り返し現れるかを確認します。特定のサーバーだけで頻繁に再接続する場合は、サーバーのタイムアウトの章をご覧ください。Wi-Fiの切り替え時だけ発生する場合は、ネットワーク切り替えと自動接続を確認します。すべての設定を最初に変更する必要はありません。

範囲が広すぎるルールは、本来直接接続できるリクエストもリモート経路に送る可能性があります。ただし変更前に、元の設定意図を確認してください。よく使う用途でどのルールが適用されるかを確認し、明らかな振り分け間違いを修正します。通信量を減らすために、すべてのリクエストを安易にDIRECTへ変更しないでください。プライバシーや接続経路に要件がある用途では、必要なポリシーを維持します。性能改善では、無意味な再試行と誤った経路を減らすことを目指し、正確さを損なって一時的に見栄えのよい統計を得ることは避けてください。

接続を切っても発熱やバッテリー消費が明らかに続く場合は、システムのアップデート処理、ほかのアプリの動作、バッテリーの状態などが関係している可能性があります。システム側から引き続き確認してください。Shadowrocketのスイッチがオンで、同時にバッテリーが減っているだけでは、因果関係を証明できません。安定したネットワーク、少ない通信量、診断テストをオフにした状態でも異常が再現する場合は、発生条件と機密情報を隠した記録を残し、最後の章に沿って設定を戻してください。記録のない再インストールを繰り返すより、再現可能な比較テストのほうが有効です。

アップデート後の不具合とiPad：基準を残してから復旧

「アップデート後に問題が起きた」というのは発生順序を示すだけで、アップデート自体が原因とは限りません。同じ時期にサブスクリプションの更新、システムのアップグレード、デフォルトサーバーの変更、ネットワークの切り替えが起きている可能性もあります。実際に変わった項目を整理し、現在の設定とエラーの原文を保存してから最小限の設定で再確認してください。バックアップせずにアプリを削除しないでください。ローカルのサーバー情報、設定、個人用の調整が失われ、再インストール後に復元できない場合があります。復旧は元に戻せる操作から始め、再インストールは最後に検討します。

アプリ、システム、設定の変更を1つずつ切り分ける

まず基本ネットワークが正常であることを確認し、利用できることが分かっているサーバーを選択して、一時的にProxyに切り替え、実際のリクエストを送ってください。最小限の条件で通信できる場合は、Config、カスタムポリシー、DNS、On Demandを1つずつ戻します。どの項目を戻した後に再発したかを確認し、その項目を優先して調べてください。最小限の設定でも通信できない場合は、このページ前半の許可、タイムアウト、DNSに関する確認手順を続けます。原因が分からないまま古い設定全体をすぐに戻すと、未解決の問題まで再び持ち込むことになります。

iPhone / iPad版のアプリはApp Storeでアップデートします。システム要件はApp Storeのページに記載された内容をご確認ください。再入手する場合は、デベロッパー名Shadow Launch Technology Limited、公式アイコン、アプリID 932747118を確認してください。iPhone / iPad版はApp Storeで2.99米ドルの買い切りです。Mac / Windows / Android / Linux版は無料です。購入済みアプリの復元と各プラットフォームのダウンロード方法は購入済みアプリの復元方法をご覧ください。購入状況とローカル設定のバックアップは別々に確認してください。

デスクトップ版とAndroid版でインストールを許可する際の注意

Mac、Windows、Android、Linuxでインストーラーを再入手する場合は、全プラットフォームのダウンロードページでデバイスを選択してください。インストーラーは当サイトの /dl/shadowrocket/ から提供しています。Macでは「このMacについて」でチップを確認し、AppleシリコンとIntelを区別してください。外観だけで判断しないでください。再入手する前に既存の設定を保存し、ダウンロード元とファイルを確認してから操作します。サーバーの問題を調べる前に、インストーラーの変更で解決しようとしないでください。

これらのプラットフォーム向けインストーラーにはコード署名がないため、初回起動時にシステムによってブロックされることがあります。WindowsでSmartScreenが表示された場合は、当サイトから入手したファイルであることを確認してから「詳細情報 → 実行」を選択してください。Macでは「プライバシーとセキュリティ」で該当アプリの「このまま開く」を選択できます。Androidでは、実際にインストールするアプリに限って「不明なアプリのインストール」を許可し、インストール後にその権限を取り消せます。LinuxのAppImageには実行権限が必要です。詳しい通知とコマンドはインストール許可の一覧をご覧ください。個別ファイルの警告を解決するために、システムの保護機能全体を無効にしないでください。

iPadの横向き表示、購入状況、設定の移行

iPadを横向きにすると、リストと詳細が同時に表示されることがあります。編集している項目と、現在のデフォルトサーバーが一致しているか確認してください。項目の詳細を開いていても、その項目がデフォルトに選択されているとは限りません。縦向きと横向きを切り替えた後も、Homeでの実際の選択と接続状態を確認してください。詳細画面に表示されている項目から接続先を推測しないでください。画面レイアウトの変更で操作箇所が見つからない場合は、いったんリスト階層に戻り、クイックスタートガイドに沿って順番に確認してください。

iPhoneで購入済みの場合、iPadでは購入時に使用したApple IDでApp Storeの購入済み項目を確認してください。アプリの購入を復元しても、サーバー情報や.confファイルがすべて自動で移行されるわけではありません。2台のデバイスで接続するには、それぞれのサブスクリプション、デフォルトサーバー、ルーティング設定、システムの許可を確認します。別のデバイスで正常に動作しても、このデバイスの許可やネットワークの確認を省略しないでください。移行時は必要な情報を取り込み、接続をテストしてから追加設定を戻し、一度に多くの不明な違いを持ち込まないようにします。

同じWi-FiでiPadとiPhoneの結果が異なる場合は、まず両方のデバイスで実際に使われている設定とDNSを比較します。次に、モバイルデータの使用、異なる自動接続条件、システムの管理ポリシーが有効になっていないか確認してください。設定が一致していることを確認したら、同じ接続先と同じサーバーで再テストします。移行用のファイルやQRコードには認証情報が含まれることがあります。保護された個人用の方法で転送し、作業後は一時ファイルを削除してください。画面レイアウトと購入の詳細はiPadの使い方と設定の移行をご覧ください。