Shadowrocket
トラブル対処ガイド

「スイッチがすぐオフに戻る」場合と「オンのままなのにリクエストが失敗する」場合を分けて考えます。前者はVPN設定やシステムの管理制限を優先して確認し、後者は次の章へ進みます。アプリを何度も削除しないでください。

再現性のある確認手順を用意する

Shadowrocketの接続スイッチをオフにし、ネットワークを制御する他のVPN設定を一時停止してから、ブラウザーで普段直接アクセスできるWebページを開きます。公衆Wi-Fiでは、インターネット接続の前にWeb認証が必要な場合があります。Wi-Fiのアイコンが表示されていても、インターネットに接続できているとは限りません。元のネットワークからアクセスできない場合は、認証を完了する、ネットワークに再接続する、またはネットワーク管理者に問い合わせてください。この段階では、サーバーの変更やルールの編集をしても根本的な接続問題は解決しません。Wi-Fiとモバイル通信のどちらを使っているか、問題の発生前にネットワークの切り替え、設定の復元、システム設定の変更をしたかも記録します。

最低限、デバイスの種類、ネットワークの種類、スイッチがオンのまま維持されるか、失敗した具体的な操作、表示されたエラーメッセージを記録します。「使えない」とだけ記録すると、インポート、接続、Webページのどの段階で失敗したのか分かりません。テスト中は、設定を確認できるサーバーと同じWebページを使い、不要なダウンロードは停止します。サーバー、設定、ネットワークを同時に変更すると、復旧しても原因を特定できず、次回も最初から試すことになります。

VPN設定の許可を確認する

iPhoneまたはiPadで初めて接続を有効にすると、システムからVPN構成の追加を求められます。デバイスの利用者が表示内容を確認して許可してください。以前にキャンセルした場合は、Shadowrocketで接続を再度オンにし、システムの確認ダイアログが表示されるか確認します。続いてシステムのSettingsでVPN構成を探し、該当する項目が一覧にあるか確認してください。設定画面の場所はシステムのバージョンによって異なる場合があります。設定内検索を使い、古いガイドの階層名だけで構成の有無を判断しないでください。職場や学校の管理対象デバイスでは、構成プロファイルによってVPNの追加が制限されていることがあります。管理者に権限を確認し、再インストールを繰り返して管理ポリシーを回避しようとしないでください。

許可した後もスイッチがすぐオフに戻る場合は、まずデバイスを再起動して再確認します。古いVPN項目がShadowrocketのものだと確認でき、アプリ内のデータもバックアップ済みの場合に限り、そのシステム構成を削除し、アプリから再作成を申請する方法を検討してください。システムのVPN構成とアプリ内のサーバー、Subscribe、Configは別々の項目です。ひとつを削除しても、他のデータがバックアップされたことにはなりません。すべてのプロファイルを一度に削除したり、用途の分からない証明書やデバイス管理項目を削除したりしないでください。

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

On Demandがネットワーク条件に応じて自動接続または切断を行っていないか確認します。自動設定の影響を避けるため、まず元の条件を記録し、自動接続を一時停止して手動スイッチだけでテストしてください。手動接続が正常なら、条件をひとつずつ戻し、特定のWi-Fiネットワーク名やネットワーク切り替え時だけ問題が起こるか確認します。システムに複数のVPN項目が保存されている場合は、実際に有効な項目を確かめてください。ステータスバーの接続アイコンだけで、Shadowrocketがリクエストを正常に処理しているとは判断できません。

アプリを開けない、または起動直後に終了する場合は、まずエクスポート可能な設定を保存し、デバイスの空き容量を確認してから、アプリのダウンロードページで入手方法を確認してください。iPhone / iPad版はApp Storeから入手できます。システム要件はApp Storeの掲載内容をご確認ください。Mac、Windows、Android、Linux版のインストール方法とシステムによる許可手順もダウンロードページにまとめています。接続トラブルの確認中に、出所の分からないインストーラーへ安易に差し替えないでください。アプリが安定して起動し、スイッチがオンのまま維持されるようになったら、ネットワークの確認に進みます。

まずDirectとProxyの結果を比較し、Configだけが失敗するかを確認します。接続アイコンが示すのはシステムにVPNセッションがあることだけで、すべてのリクエストが正常に完了することではありません。

3つのモードで問題の範囲を絞り込む

現在のConfigを複製し、ユーザーがすでにお持ちの、設定を確認できるサーバーをひとつ選びます。Global RoutingでConfig、Proxy、Directの順に切り替え、その都度、同じWebページへアクセスします。Directでは選択したプロキシサーバーを経由しない場合のアクセス結果、Proxyではそのサーバーでリクエストを処理できるか、Configではルール判定を含めた動作を確認します。この比較はトラブルの切り分けに使うもので、いずれかのモードを常時使うよう求めるものではありません。テスト後は、実際の利用に合った設定に戻してください。

Directは正常でProxyが失敗する場合は、サーバーの状態、プロトコル設定、接続先の応答を優先して確認します。Proxyは正常でConfigが失敗する場合は、設定の有効化、ルールの順序、ポリシーの割り当てを確認します。3つすべて失敗する場合は、Webページ自体が利用可能かを確認してから、元のネットワークとDNSを調べます。アプリによっては既存の接続を再利用するため、モードを切り替えた後は古いページを閉じて開き直してください。必要に応じてアプリの現在のセッションを終了して再テストし、古い接続による誤判定を避けます。

設定一覧ではなく、現在使っているConfigを確認する

Configで実際に有効なファイルを確認します。一覧にファイルがあっても、使用中とは限りません。Subscribeからサーバーをインポートしても、期待するルール設定に切り替わるわけではありません。現在のファイルを開き、Ruleの項目を上から順に確認してください。通常、最初に一致したルールでリクエストの行き先が決まるため、範囲の広いルールが前にあると、後の詳細なルールが適用されないことがあります。編集前にファイルを複製し、元の設定とテスト用の設定を区別できる名前を付けてください。

以下の例はルールの適用順を理解するためのものです。指定したドメインはPROXY、ローカルネットワークのアドレスはDIRECT、その他のリクエストはFINALで処理します。PROXYに対応するサーバーやポリシーが現在の環境で有効である必要があり、この例だけでサーバーが作成されるわけではありません。GEOIPの判定はIPアドレスや関連データにも依存するため、どのネットワークでもドメインの判定結果が同じとは限りません。必要なローカルルールを含むConfig全体に、この例をそのまま上書きしないでください。

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

一部のWebページだけ失敗する場合は適用ルールを確認する

ほとんどのWebページは使えるのに、特定のドメインやアプリだけ失敗する場合は、該当リクエストに実際に適用されたルール、最終的なポリシー、エラー内容を確認します。ひとつのページからメインのドメイン、画像用ドメイン、API用ドメインへ別々にリクエストが送られることがあります。ページの文字は表示されるのに画像だけ読み込まれない場合、「接続全体が切れた」とは限りません。まず、どのドメインで失敗したかを特定してから、個別のルールを変更する必要があるか判断してください。REJECTが適用されている場合は、拒否ルールをすべて削除するのではなく、そのルールの目的を確認します。元のConfigでは特定の種類のリクエストを拒否する必要があるかもしれません。

ローカルネットワークのデバイス、プリンター、社内向けWebページについては、接続先のアドレスが現在のネットワークに属しているか、リモートプロキシ経由になっていないか確認します。Wi-Fi側でデバイス間通信が制限されている場合、DIRECTルールを追加しても解決しないことがあります。特定のアプリだけがネットワークエラーを表示する場合は、システムのネットワーク権限とアプリ側のサービス状態も確認してください。復旧後は同じ接続先にConfigで再度アクセスし、診断用に追加した一時ルールを削除して、必要最小限の変更だけを残します。

タイムアウトは、待ち時間内にテストが完了しなかったことを示します。名前解決、通信の確立、プロトコルのハンドシェイク、接続先からの応答のいずれかで発生する可能性があります。まずテストの種類とエラーメッセージを確認してください。

特定のサーバーだけか、すべてのサーバーかを確認する

Homeで登録済みのサーバーにConnectivity Testを実行し、失敗する項目を記録してから、そのうちひとつで実際にWebページを開きます。テスト方法によって確認する段階は異なります。ポートに接続できても認証情報が正しいとは限らず、Webページを一度開けても、すべてのリクエストが正常とは限りません。ひとつだけ失敗する場合は、そのサーバーの設定と接続先の状態を優先して確認します。すべて同時に失敗する場合は、現在のネットワーク、ドメインの名前解決、デバイスの時刻、共通の通信設定を確認してください。すべてのサーバーを作り直す必要はありません。

可能であれば、同じデバイスで、利用可能と分かっている別のネットワークに切り替えます。サーバーとテスト対象は変えずに比較してください。ネットワークを変えると結果が変わる場合は、ローカルネットワークからサーバーまでの経路、またはネットワーク側での通信方式の制限が原因かもしれません。一度の成功だけで設定が正しいと判断せず、元のネットワークで認証が必要か、ルーターによるフィルタリングがあるか、混雑時間帯だけ失敗するかも記録します。偶然の成功より、再現できる違いのほうが診断に役立ちます。

登録済みの設定を項目ごとに照合する

Add Serverの編集画面を開き、ユーザーがすでにお持ちのサーバー情報と、プロトコルの種類、アドレス、ポート、認証情報をひとつずつ照合します。サーバーアドレスにはホスト名を入力し、Webリンクのパスまで貼り付けないでください。ポート番号はサーバー側の待ち受け設定と一致させます。パスワード、UUID、鍵などはプロトコルごとに異なる認証項目であり、相互に置き換えることはできません。コピー＆ペースト後は前後の空白、改行、全角記号に注意してください。チャットや文書からコピーした場合、見た目が似た文字でもハンドシェイクに失敗することがあります。

VMess、VLESS、Trojanなどの設定では、実際のサーバー側の要件に合わせてTLS、通信方式、関連項目を確認してください。必要なオプションは設定ごとに異なります。WebSocketを使う場合、パスとHostはサーバー側の指定に合わせます。パスの大文字・小文字や先頭のスラッシュも維持してください。Hysteria2やWireGuardを使う場合は、現在のネットワークでUDPがどう扱われるかも確認します。TCPのテストで結果が出ても、UDP通信が正常とは限りません。項目の意味が分からない場合は、元の設定の提供元に確認し、別のサーバーの値を推測で入力しないでください。

システム時刻とハンドシェイクの状態を確認する

システムの日付やタイムゾーンが正しくないと、証明書の有効期間の判定に影響し、時刻に依存する認証にも支障が出る場合があります。システムの日付と時刻を自動設定にして、表示が正しいことを確認してから再接続してください。証明書名の不一致や期限切れが表示された場合は、サーバー名、SNI、接続先の証明書を確認し、検証を無効にして問題を隠さないでください。アドレスに接続できてもハンドシェイクが繰り返し失敗する場合は、単なるタイムアウトより多くの手がかりがあります。証明書、認証、通信の応答のどれに関するエラーか、全文を記録します。

設定を確認しても、複数の正常なネットワークで同じサーバーが安定して失敗する場合は、プロトコルの種類、エラーが起きた段階、テストした時間帯、個人情報を除いたエラー内容を、ユーザーがすでに利用しているサービスの提供元へ伝え、待ち受け、認証、サービス状態を確認してもらいます。パスワード、UUID、サブスクリプションの完全なURL、設定のQRコードは公開しないでください。詳しい確認手順はサーバーのタイムアウト、プロトコル設定、システム時刻の確認方法をご覧ください。変更の効果を確認してから保存し、失敗した設定をそのまま残さないようにします。

サブスクリプションの更新は、URLへのリクエスト、内容の取得、形式の判定、一覧の更新という段階に分かれています。更新が成功してもサーバーが使えるとは限りません。また、サーバーへの接続失敗だけでサブスクリプションのURLが無効とは判断できません。

URLが完全で、現在もアクセスできるか確認する

ユーザーがすでに利用しているサービスの管理ページからサブスクリプションURLをコピーし直し、クエリパラメーターの欠落、チャットアプリによる切り詰め、前後の空白がないか確認します。URL内のトークンはアクセス情報に相当するため、公開スクリーンショット、問い合わせの件名、Web上のコメントに載せないでください。URLを再発行した場合、古いURLは使えなくなっている可能性があります。古い項目の更新を繰り返すのではなく、自分のアカウントで現在提供されているURLに差し替えてください。コピー後、アプリ内の入力内容を確認します。個人用トークンを含むURLをオンライン変換・検査サイトに送らないでください。

未認証またはアクセス拒否の応答がある場合は、アカウントのログイン状態、アクセス権限、サブスクリプションが再発行されていないか確認します。リソースが見つからないという表示の場合は、パスが完全かを確認してください。応答ステータスは手がかりにすぎません。最終的な意味は、ユーザーがすでに利用しているサービスの説明を確認してください。一時的なリダイレクトからURLをコピーすると、サブスクリプションの内容ではなくログインページを取得していることがあります。ブラウザーでページが開けても、Subscribeで読み取れるとは限りません。ブラウザーのセッションとアプリのリクエストでは、送信される状態が異なる場合があります。

内容を取得できない場合はアクセス経路を確認する

更新が終わらない、またはネットワークエラーになる場合は、サブスクリプションのドメインを名前解決できるか、現在のGlobal Routingでそのリクエストがどの経路を通るか確認します。更新には利用可能なサーバーが必要なのに、一覧のサーバーがすべて使えない場合、「接続するには更新が必要だが、更新するには接続が必要」という状態になることがあります。作業前に古い一覧を残し、ユーザーがすでにお持ちの利用可能な接続方法を選ぶか、サブスクリプションURLに直接アクセスできるネットワークで更新してください。この状態を解消するために、出所の分からない設定をインポートしないでください。

デバイスの時刻とHTTPS証明書のエラーも確認します。公衆Wi-Fiだけで失敗する場合は、接続をオフにしてネットワーク認証を完了してから、もう一度取得してください。ネットワークから認証ページが返されている場合、アプリが取得するのはサブスクリプションの内容ではありません。応答が空か、リダイレクトされたか、Webページのテキストが返されたかは記録できますが、サーバーアドレスや認証情報が含まれている可能性があるため、応答全文を公開しないでください。ネットワーク経路を復旧してから一度更新すれば十分です。短時間に何度も更新ボタンを押しても、接続先の権限や内容の問題は解決せず、確認結果が分かりにくくなります。

内容を取得できるのに読み取れない場合は形式を確認する

インポート対象にはサーバーのサブスクリプション、単一サーバーの共有情報、完全なConfigファイルがあり、それぞれ用途が異なります。内容の種類に合ったインポート方法を使い、Shadowrocket向けにサービス提供元が指定している形式を確認してください。返された内容がログインページ、アカウント通知、エラー説明、または現在のインポート方法で認識できないテキストの場合、ダウンロードが完了してもインポートは失敗します。意味の分からない先頭部分を手で削除したり、内容を直すために文字コードを変更したりしないでください。正しい認証情報を壊すおそれがあり、後で元の状態を確認できなくなります。

更新後に一部のサーバーしか表示されない場合は、元のサブスクリプションにそれだけが含まれていたか確認し、現在の設定で認識できない項目やフィルター条件がないか調べます。名前が同じでも、インポート後の設定が同じとは限りません。手動で追加した項目とサブスクリプションの項目が両方ある場合は、更新したほうの項目が選択されているか確認してください。サブスクリプション由来のサーバーを編集する前に、別のテスト項目として複製します。次回の更新で手動の変更が上書きされることがあるため、一時的な変更を接続先にも反映済みだと思い込まないでください。

更新が成功しても、サーバーをひとつ選んでConnectivity Testを実行し、実際のWebページでも確認してください。取得と読み取りが正常で、すべてのサーバーへの接続だけが失敗する場合は、インポート方法を変え続けるのではなく、プロトコル設定や接続先の状態を確認します。アプリの買い切り料金と接続サービスのプラン料金は別です。iPhone / iPad版はApp Storeで$2.99の買い切り、Mac / Windows / Android / Linux版は無料です。アプリを購入しても、インポート可能なサブスクリプションが自動的に付属することはありません。

遅延、Webページの初回表示までの時間、ダウンロードの継続速度はそれぞれ異なる指標です。遅延の数値だけで速度を判断したり、複数の条件を同時に変えて比較したりしないでください。

「遅い」を確認できる現象に分ける

まず、どのように遅いかを具体的にします。URLを入力してから画面が長く空白になる、本文は表示されるのに画像が遅い、ダウンロード開始後に速度が下がる、画面ロックやネットワーク切り替え後に通信が切れる、といった状況です。初回表示の遅さには、DNS、接続の確立、TLSハンドシェイクが関係する場合があります。転送が続く間の遅さには、帯域、パケットロス、接続先の負荷、対象サービスが関係することがあります。ひとつのアプリやWebサイトだけで遅い場合は、他の接続先と比較してください。対象サービスの速度制限、アカウントの制限、ページ内リソースの問題を、すべてShadowrocketの原因と決めつけないでください。

デバイス、ネットワーク、サーバー、Global Routing、テスト用ファイルを固定し、他のデバイスやアプリによる大容量通信を止めてから、数回テストします。Directとプロキシの経路を比較するときは、どちらの経路でも正常にアクセスできる対象を選んでください。そうでなければ、失敗した結果を速度比較に使えません。おおよその時間帯と状況を記録し、一度のテストで一日の状態を決めつけないでください。Wi-Fiの干渉、家庭内ネットワークの混雑、接続先の負荷は時間とともに変わります。テストの目的はボトルネックの特定であり、単発の数値をよく見せることではありません。

ローカルネットワーク、通信経路、接続先の順に確認する

接続をオフにしてローカルネットワークの安定性を確認し、Wi-Fiの電波が強い場所でもう一度試します。壁、混雑したチャンネル、ルーターの負荷が影響する場合があります。同じデバイスでDirect接続も明らかに遅い場合は、まずローカルネットワークを確認してください。プロキシ経由だけが遅い場合は、対象を変えずに、ユーザーがすでにお持ちの別のサーバーと比較します。複数のサーバーで同じ対象だけが遅い場合は、対象サービス側の制限も考えられます。デバイスの発熱、低電力モード、バックグラウンドでの大量同期も影響するため、近い使用状態で比較してください。

遅延が小さくても、転送速度が速いとは限りません。短いテストで送受信するデータは少なく、長時間の通信で起こる混雑や再送を反映しないことがあります。逆に、距離の遠いサーバーはハンドシェイクに時間がかかっても、継続的な転送は遅くない場合があります。最小の数値を追って頻繁に切り替えると、アプリの接続が何度も再確立されます。動画、リアルタイム通話、ファイルのダウンロードでは、バッファリング、継続性、実際の転送状況をそれぞれ確認し、ひとつの用途の結果をすべてに当てはめないでください。

通信が切れる条件を確認する

Wi-Fiからモバイル通信への切り替え時だけ切れる場合、古い接続を引き継げず、新しいリクエストの接続確立が必要になることがあります。まず接続が戻るまで待ち、対象のページを開き直してください。切り替えのたびに復旧しない場合は、スイッチの状態、On Demandの条件、サーバー接続のエラーを記録し、該当する章で確認します。特定のWi-Fiネットワークで切れる場合は、定期的な再認証、省電力機能、長時間接続の制限がないか確認してください。「しばらくすると切れる」というだけで、パスワードの誤りとは判断できません。認証エラーは通常、接続の確立時に発生します。

小さなリクエストは正常なのに、大きなファイルや特定のページが読み込み途中で止まる場合は、パケットロス、通信方式、経路上のフラグメントの問題を調べることもできます。ただし、ネット上で見つけたMTUの固定値をそのまま設定しないでください。ネットワーク、プロトコル、トンネルのカプセル化によって必要な値は異なり、不適切な変更で正常な通信まで影響を受けることがあります。再現条件を記録し、初期値を保存したうえで設定の用途を理解してから、ひとつずつ比較してください。改善しない場合は元に戻し、説明できない設定を残さないようにします。

ルールの記録から「一部の通信だけ遅い」原因を確認する

Configでは、ページ本文、画像、APIへのリクエストがそれぞれ別のポリシーに一致する場合があります。遅いリクエストのドメインと最終的な接続経路を確認してください。特定のルールに割り当てられたポリシーだけが遅い場合は、すべてのリクエストをProxyに変更するのではなく、そのサーバーが現在も使えるか確認します。接続記録に同じ失敗や再試行、名前解決のやり直しが繰り返し記録されている場合、単発の速度テストより体感速度の原因を説明できることがあります。診断後は不要な負荷テストを停止し、普段の設定に戻してください。速度テストを同時に複数実行すると帯域を消費し、その後の確認結果にも影響します。

DNSの問題は「アドレスが返るか」だけでは判断できません。どこから問い合わせたか、どの経路で名前解決したか、どのアドレスが返されたか、接続先としてどのアドレスが選ばれたかを確認します。

名前解決に失敗した証拠を確認する

ブラウザーにサーバーが見つからないと表示される、または接続記録に名前解決の失敗が記録されている場合は、ドメインの入力、元のネットワーク、現在のConfigのDNS設定を確認します。関係のない複数のドメインで同時に失敗する場合は、DNSサーバーへの接続を優先して確認してください。特定のドメインだけが失敗する場合は、そのドメインのレコード、キャッシュ、適用されるルールを確認します。IPアドレスで接続できてドメイン名では失敗することは手がかりになりますが、それだけでは結論を出せません。HTTPSのサービスは正しいホスト名と証明書を必要とすることが多く、ブラウザーにIPアドレスを直接入力した場合とは結果が異なることがあります。それだけでサーバーが正常かどうかを判断しないでください。

Configに手動で追加したDNS設定、静的マッピング、特定ドメインへの個別処理がないか確認します。まずコピーを保存して元の設定と比較し、用途が分からない項目を一度にすべて置き換えないでください。システムのDNSプロファイル、ルーターの設定、アプリ独自の名前解決経路が同時に存在する場合もあります。特定の問い合わせをどこが処理したかは、記録から確認する必要があります。システムにDNSサーバーを設定していても、すべてのプロキシリクエストが必ずそのサーバーを使うとは限りません。同様に、アプリ内の設定がデバイス上のすべてのリクエストに適用されるとも限りません。

名前解決と接続の依存関係を確認する

DNSサービスがドメイン名で指定されていて、そのサービスへのアクセスに未確立のプロキシ経路が必要な場合、起動時に依存関係の循環が起こることがあります。まずサーバーアドレスの名前解決方法を確認し、次にDNSサーバーへの接続経路、最後に対象ドメインの問い合わせ経路を確認します。切り分けには利用可能と分かっている基本設定を使い、複数の暗号化DNSや複雑なルーティングを一度に組み合わせないでください。どのDNSサーバーにもネットワーク上の到達条件があります。サーバーの追加で信頼性が上がるとは限らず、失敗の現れ方が不規則になることもあります。

暗号化DNSを使っている場合は、プロトコル、アドレス形式、ポート、証明書名が設定要件に合っているか確認し、現在のネットワークから接続できることを確かめます。一般的なWebページにHTTPSでアクセスできても、特定のDNSエンドポイントが使えるとは限りません。リクエストにプロキシが必要な場合は、割り当て先のポリシーも有効でなければなりません。Direct経由なら、その経路での到達性を確認します。時刻の誤りや名前の不一致を解消するために証明書検証を無効にせず、先にデバイスの時刻とアドレスを修正してから、問題が解消するか確認してください。

アドレスファミリー、ルール、キャッシュを切り分ける

同じドメインからIPv4とIPv6の両方のアドレスが返されることがあります。どちらかのアドレスファミリーで経路に問題があると、最初の接続に時間がかかったり、一部のリクエストだけ失敗したりする場合があります。実際に選択されたアドレスとエラーを確認し、名前解決段階と接続段階のどちらで失敗したかを見極めてください。問題が起きるたびにIPv6を恒久的に無効にする必要はありません。ルールのIP-CIDRとIP-CIDR6は異なるアドレスファミリーに対応します。アドレス判定に依存するルールは、名前解決の結果によって適用状況も変わることがあるため、ドメインルールだけではすべての経路を説明できない場合があります。

DNSやルールを変更した後も、古いキャッシュや再利用された接続が結果に影響することがあります。新しいリクエストを送り、必要ならVPNを再接続するか、テスト中のアプリを再起動してから記録を比較してください。キャッシュが更新される前に複数の設定を続けて変更しないでください。ローカルネットワークの内部ドメインは、そのネットワークのDNSサーバーでしか解決できないことがあります。外部のDNS経路に無理に送ると、かえって失敗する可能性があります。家庭や職場の内部サービスでは、名前解決とローカルネットワークのルーティングを両方確認し、現在のネットワークから名前解決後の内部アドレスにアクセスできることを確かめます。

最終確認では、一般的なWebページ、以前問題があったドメイン、アクセスが必要な内部サービスをそれぞれ試します。各接続先について、名前解決の結果、最終ポリシー、アクセス結果を記録してください。復旧を確認したら、テスト用の静的マッピングや一時ルールを削除します。アドレス変更後に再び使えなくなるのを防げます。DOMAIN-SUFFIX、IP-CIDR、FINALの関係は設定ガイドで確認できます。よくあるエラーの意味を確認したい場合は、よくある質問をご覧ください。

同じ時間帯の画面使用、ネットワークの通信状況、接続エラーを確認してから、バッテリー消費の原因を判断します。システムのバッテリー画面に表示される内訳が、アプリによる実際の消費量すべてを示すとは限りません。

比較できる時間帯を選ぶ

システムのバッテリー使用状況で問題が起きた時間帯を確認し、画面点灯中の高負荷と、待機中の継続的な動作を区別します。動画の再生、ファイルのダウンロード、写真の同期、アプリの更新はいずれも通信を発生させます。VPN経由の通信がシステムの使用状況の分類に影響する場合もあります。割合だけで判断しないでください。その割合は選択した時間帯における相対的な内訳であり、デバイスの総バッテリー残量が同じ割合だけ減ったことを示すとは限りません。比較のために、デバイスの発熱、電波の強さ、実際の使用内容も記録します。

比較するときは、画面の明るさ、ネットワーク、アプリの使用状況、時間をできるだけそろえ、接続をオンにした場合とオフにした場合をそれぞれ観察します。何もしていない待機状態と長時間の動画再生を比較したり、テストのために画面を点け続けたり、速度テストを繰り返したりしないでください。モバイル通信の電波が弱い、Wi-Fiが頻繁に切れる、バックグラウンドで大量の処理が行われていると、消費が大きく増える場合があります。接続をオフにしても異常が続く場合は、ルールを変更し続けるのではなく、システムや他のアプリも確認してください。

まず失敗の繰り返しを調べ、次に設定の複雑さを確認する

同じドメインへのリクエストが繰り返し失敗する、サーバーが何度も再接続する、サブスクリプションの更新が続いている、といった状況がないか確認します。短時間に再試行が繰り返されると、ネットワークと処理リソースを消費することがあります。サーバーの認証失敗、DNS問い合わせの未完了、アプリから拒否されるアドレスへの継続的なアクセスなど、再試行の原因を先に解消してください。記録を非表示にしても再試行は止まりません。大量のリクエストを送るアプリを一時停止し、通信活動が明らかに減るか確認すると、発生源を特定しやすくなります。

不要な高頻度テスト、頻繁すぎる自動更新、追加の診断記録が有効になっていないか確認します。テスト間隔や記録項目は用途に応じて設定してください。すべてのデバイスに適した固定の最適値はありません。問題の切り分けが終わったら、調査のために有効にした詳細記録をオフにし、データの蓄積や処理の増加を防ぎます。必要な情報はエクスポートして安全に保管し、個人用アドレスを含む一時ファイルは削除してください。デバイスの空き容量が不足している場合は、システムストレージも確認します。アプリの反応が遅い原因を、すべてネットワークやバッテリー消費の問題と決めつけないでください。

ネットワーク条件に応じたOn Demandの動作を確認する

On Demandは条件に応じて接続を開始しますが、設定によってはネットワークの切り替えや複数条件の入れ替わりに応じて、接続と切断を繰り返す場合があります。まず各条件の対象、順序、動作を記録し、自動接続を一時停止して、手動接続で同程度の利用時間を確認します。手動接続は安定していて、特定の条件を戻すと再接続が頻発する場合は、その条件が他の条件と重複していないか、頻繁に変わるネットワーク状態に依存していないか確認してください。条件を複数同時に追加・削除すると、どの変更が影響したか分からなくなります。

接続を長時間維持したい場合は、自動接続を繰り返して不安定な接続を補うのではなく、普段使うネットワークで選択したサーバーが安定していることを先に確認します。自宅への帰宅、職場からの移動、Wi-Fiからモバイル通信への切り替えなどの場面を重点的に確認してください。切り替え後にスイッチがオンのままか、リクエストが復旧するか、再試行が繰り返されるかを記録します。管理対象のデバイスやネットワークでは、システムポリシーによる切断と再接続も考慮してください。自動的な変化をすべてアプリ内の設定のせいにしないでください。

確認を終える条件と設定を戻す手順を決める

問題のあるアプリのリクエストを止める、サーバー設定を修正する、または自動接続の条件をひとつ調整した後、デバイスの温度や待機時の動作が改善した場合は、同じ条件で再テストして効果が再現するか確認します。消費が大きい状態が続く場合は、デバイスを再起動し、システムのバックグラウンド処理を確認してください。再起動直後の短時間の変化だけで、長期的な傾向を判断しないでください。充電中の発熱は、充電とタスクの実行による場合もあります。充電していない状態、使用状況が近い状態と分けて記録します。

確認が終わったら、必要なルールと接続ポリシーを元に戻し、診断用に一時設定した全リクエストのプロキシ経由、詳細記録、高頻度テストを解除します。記録には、問題が起きた時間帯、関連リクエスト、有効だった変更、再テストの結果を簡潔に残してください。再現性のある証拠がない場合、すべての設定を削除したり、デバイス全体をリセットしたりすることはおすすめしません。手間がかかるうえ、原因特定に必要な情報も失われることがあります。相談が必要な場合は、次の章の個人情報を除いた記録を使い、サブスクリプション全体を含むバックアップを送らないでください。

更新後は、現在使用中のサーバー、Config、システム権限を確認します。iPadだけ結果が異なる場合は、ネットワークと設定を比較してください。同じアカウントのデバイスなら状態も同一だと思い込まないでください。

更新前後を比較し、すぐに再インストールしない

変更する前に、保存可能なサーバーと設定をエクスポートし、バックアップの用途を判別できることを確認したうえで、現在のConfigのコピーを残します。バックアップには機密情報が含まれる場合があるため、本人が管理する場所に保存し、公開しないでください。更新後は、選択中のサーバーが変わっていないか、Global Routingが想定どおりか、元のConfigが現在も使用されているか、システムのVPN構成が残っているか確認します。アプリの更新とサブスクリプションの変更を同じものとして扱わないでください。近い時期に両方が起きていても、別々に確認します。

更新後に古いConfigで問題が起きた場合は、ユーザーがすでにお持ちの、設定が明確なサーバーをひとつ使い、最小限の接続テストを行います。最小構成で接続できれば、基本的な接続条件は動作しています。元のConfigのルール、DNS、自動接続設定をひとつずつ戻してください。最小構成でも失敗する場合は、システム権限、元のネットワーク、プロトコル設定を確認します。複雑なConfigを検証するために、ファイルを次々に上書きしないでください。必ず元に戻せるファイルを残し、現在テストしているファイル名を記録します。

入手方法と初回起動時の許可を確認する

iPhone / iPad版はApp Storeから更新・再入手できます。開発者がShadow Launch Technology Limitedであること、公式アイコン、アプリID 932747118を確認してください。システム要件はApp Storeの掲載内容をご確認ください。再インストールする前に、データがバックアップ済みであることを確認します。iPhone / iPad版はApp Storeで$2.99の買い切り、Mac / Windows / Android / Linux版は無料です。購入済みアプリの復元やアカウントの国・地域に関する問題は、再入手ガイドをご覧ください。アプリの入手状況と、すでに利用しているサブスクリプションのアクセス権限を混同しないでください。

その他のプラットフォームのインストーラーは、ダウンロードページから当サイトの /dl/shadowrocket/ 経由で入手できます。Macでは「このMacについて」でAppleシリコンかIntelかを確認し、対応するインストーラーを選びます。開発元を確認できないという警告が初回に表示された場合は、システムの「プライバシーとセキュリティ」で内容を確認してから「このまま開く」を選択してください。WindowsでSmartScreenが表示された場合は、当サイトの入手経路を確認したうえで「詳細情報」から「実行」を選びます。管理対象のデバイスでは組織のポリシーに従ってください。Androidでは、システムの案内に従って使用中のブラウザーからのアプリインストールを一時的に許可し、インストール後に権限を取り消すことができます。詳しくはインストール許可の手順をご覧ください。

iPadでの確認：ネットワーク、設定、利用状況を比較する

同じサブスクリプションがiPhoneでは正常でiPadでは失敗する場合、まず両方のデバイスが同じネットワークに接続されているか確認します。一方がモバイル通信、もう一方がWi-Fiを使っていることがあります。公衆Wi-Fiではデバイスごとに認証が必要な場合があり、iPhoneで認証済みでもiPadの認証が済んでいるとは限りません。選択中のサーバー、プロトコル設定、Global Routing、現在のConfigを比較し、一方だけ古い一覧のまま、もう一方は更新済みといった違いがないか確認します。一部の情報をデバイス間で同期できても、すべてのローカル設定やシステム権限が常に同じとは限りません。

Wi-Fi専用のiPadでは、モバイル通信に切り替えて比較することはできません。可能であれば、利用可能と分かっている別のWi-Fiネットワーク、または自分のデバイスのテザリングを使います。サーバーと対象のWebページは変えずに、問題がネットワークに応じて変化するか確認してください。Split Viewで片方のアプリが正常でも、もう片方が同じドメインや接続経路を使っているとは限りません。実際の接続先をそれぞれ記録します。内部のWebページやプリンターに接続する場合は、Wi-Fiでデバイス間通信が許可されていることを確認し、ローカルネットワークの分離をルールの誤りと取り違えないでください。

画面ロック後、長時間の待機後、またはスリープ解除後だけ失敗する場合は、スイッチがオンのままか、ネットワークで再認証が必要か、On Demandが復帰後に再度接続しているかを確認します。新しいリクエストを送ってから判断し、古いページに表示された読み込み中の表示だけを見て結論を出さないでください。VPN構成を作り直す必要がある場合は、先にバックアップを取り、用途が明確な項目だけを操作します。iPad専用のプロトコル設定を推測で作る必要はありません。同じサーバーには元の設定情報を使い、デバイスのネットワークとローカル状態から違いを探します。

再現確認に使える情報を個人情報を除いて整理する

解決しない場合は、デバイスとシステムの種類、ネットワークの種類、スイッチの状態、Global Routing、失敗した操作、エラーメッセージ、実施した比較テストの結果を整理します。「いつから、どの接続先に影響があり、接続をオフにすると復旧するか」を説明すると、更新後に使えないとだけ伝えるより原因を絞り込みやすくなります。スクリーンショットでは、サブスクリプションのトークン、認証情報、QRコード、公開したくないサーバーアドレスを隠してください。バックアップ全体を送らないでください。復旧後はクイックスタートガイドに沿ってインポート、接続、確認をもう一度行い、今回有効だった手順を次回参照できるように残します。