Shadowrocket トラブルシューティングガイド

01 接続スイッチがオンにならない：VPN構成の許可を確認

まず、次の3つの状態を区別します。スイッチをタップするとシステムの許可画面が表示される、スイッチが一瞬オンになってすぐオフに戻る、画面上はオンでもシステム接続が安定しない、の3つです。それぞれ、許可が未完了、接続プロセスが終了する、接続状態の再確認が必要といった原因が考えられます。すべてを「サーバーの故障」と判断しないでください。動作中の別のVPN接続を終了し、ShadowrocketのHomeに戻って、有効なサーバーが選択されていることを確認してから再試行します。画面に表示されたメッセージは原文のまま記録してください。

許可画面が表示されたら、システムの確認を完了する

初回接続時には、VPN構成の追加をシステムに許可する必要があります。この画面はシステム管理の接続構成を作成するためのもので、サーバーへの接続成功を保証するものではありません。画面に表示されたアプリ名を読み、起動したばかりのShadowrocketからの操作であることを確認したうえで、システムの案内に従ってデバイス認証を完了してください。以前に画面をキャンセルした場合は、アプリに戻って接続を再度開始します。認証が済む前に設定を次々と切り替えると、許可の前後どちらで失敗したのか判断しにくくなります。

続いてシステムのSettingsを開き、VPN関連の画面に該当する構成があるか確認します。システムのバージョンによってメニュー名が異なる場合は、SettingsでVPNを検索してください。構成があることはシステムに接続項目が保存されたことを示すだけで、サーバーが利用可能であることの証明にはなりません。構成が見つからなければ、許可操作をもう一度行います。デバイスが組織によって管理され、関連項目を使用できない場合は、サーバーのパスワードを変更するのではなく、デバイス管理者に制限を確認してください。

スイッチがすぐオフに戻る場合：システムとConfigの問題を切り分ける

まずOn Demandをオフにして、手動で一度接続し、すぐ切断されるか確認します。オンデマンド条件はネットワークの変化に応じて接続状態を再判定するため、オフにすると自動動作の影響を切り分けやすくなります。使用中のConfig名を記録し、解析できない内容、存在しないポリシーへの参照、不完全な項目を最近編集していないか確認してください。不明な提供元の設定一式に入れ替えるのではなく、自分で保存した直近の正常な設定に戻すことを優先します。

これまで正常に動作しており、システムのVPN構成を削除した後に問題が起きた場合は、必要な設定のバックアップがあることを確認してから、アプリでシステムの許可を再度開始できます。システム構成の削除は最初に行う手順ではありません。サーバー設定の誤りを直すものでも、サブスクリプション情報を復元するものでもありません。再作成が必要な場合は、接続を停止してOn Demandの状態を記録し、Shadowrocketに対応する構成だけを扱ってください。仕事などで使用している他のシステム項目を誤って変更しないようにします。

状態を確認して、この段階の調査を終える

許可を完了したら、アプリを前面に表示したままシステムのVPN状態が安定するか確認し、以前アクセスできた一般的なWebページを開きます。スイッチが安定しているのにページを表示できない場合は、次の項目でルーティングとサーバーを確認してください。許可を繰り返し削除する必要はありません。スイッチがすぐオフになる場合は、エラーの原文、すべてのサーバーで起きるか、デバイスの再起動後にも再現するかを記録します。アプリを何度も強制終了するより、通常の方法で一度再起動してから再確認したほうが、原因を特定しやすくなります。

システム側の制限も個別に確認します。スクリーンタイム、デバイス管理ポリシー、他のネットワーク構成がVPN接続に影響することがあります。自分のデバイスに関係する許可状態だけを確認し、組織の構成をむやみに削除しないでください。デバイスの通常のネットワーク接続も使えない場合は、先にWi-Fiまたはモバイル通信を復旧します。VPNの許可が正常でも、基本ネットワークの代わりにはなりません。許可画面の詳細はVPN構成の追加画面についてを参照してください。

02 接続中なのにインターネットへアクセスできない：ルーティングと基本ネットワークを分けて確認

システムにVPN接続済みと表示されても、接続拡張機能が動作していることを示すだけで、すべてのリクエストが宛先に届くとは限りません。Shadowrocketをオフにし、同じネットワークでアクセス可能と分かっているWebページを開きます。オフにしても失敗する場合は、Wi-Fiの認証ページが必要か、モバイル通信が使えるか、ルーターが正常にインターネットへ接続しているかを確認してください。公衆Wi-Fiでは、ネットワークへのログインや利用規約への同意を済ませてから接続します。認証ページを開けない問題をルールの誤りと取り違えないようにしてください。

Global Routingを切り替えて問題の層を特定する

基本ネットワークが正常であることを確認したら、現在のGlobal Routingを記録し、同じ宛先で一時的に比較します。Configは現在のルールに従って通信を振り分けます。Proxyは選択中のサーバーがリクエストを処理できるかの確認に適しています。Directはプロキシサーバーを経由しない場合の状態を比較するために使います。切り替えは診断のためで、恒久的な解決策ではありません。各テストが終わったら元の状態に戻し、一時的な設定によって後続のアプリ通信の経路が変わらないようにします。

比較する宛先は固定し、3つのモードでそれぞれ異なるWebサイトを開かないでください。1つのサイトが失敗しただけで接続全体が使えないと判断するのも避けてください。宛先のサイト自体に障害がある場合や、ページの表示に別のドメインが必要な場合があります。別の独立した宛先でも確認し、ページ全体が開かないのか、画像だけ失敗するのか、ログイン時に失敗するのかを記録します。Proxyでは使えてConfigでは使えない場合は、サーバーのプロトコルを次々に変えるのではなく、どのルールがリクエストに適用されたかを確認してください。

ルールは上から順に適用されるため、実際に適用された項目を確認する

現在有効なConfigを確認します。ファイル一覧で最後に編集したものだけを見ないでください。ルールは通常上から順に評価され、最初に一致した項目が処理方法を決めます。後ろにある広範なルールでは、先に一致した誤ったポリシーを修正できません。特にDOMAIN-KEYWORDの対象範囲が広すぎないか、REJECTで誤って遮断していないか、FINALが意図した設定かを確認します。以下はマッチングの構文と順序を示す例です。既存のConfigを丸ごと置き換えるためのものではありません。

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

ログを確認できる場合は、直前に開始したリクエストを選び、宛先ドメイン、適用されたルール、最終ポリシー、エラー結果を照合します。選択中のサーバー名だけでは判断できません。ルールやポリシーグループによって、実際の通信先が変わることがあります。REJECTに一致した場合は、そのドメインが本来遮断対象かを確認します。業務に必要なドメインであれば、該当する狭い範囲の項目だけを変更し、元の値を残してください。1つのページを開くためにルール全体を消去しないでください。

再現結果に応じて次の項目へ進む

どのモードでも失敗し、接続をオフにすると正常な場合は、DNSと接続プロセスを確認します。Proxyだけ失敗する場合は、サーバーのタイムアウトの項目へ進みます。Configだけ失敗する場合は、ルールとポリシー参照を中心に原因を絞ります。LANプリンターやルーターの管理画面にアクセスできない場合は、宛先アドレスが実際にローカルネットワーク内にあるか、既存のIP-CIDRがそのアドレスを含むかも確認してください。例示されたプライベートアドレス範囲を、すべての家庭内ネットワークを網羅する一覧と見なさないでください。

最終確認では、ページのタイトルが表示されるかだけでなく、最初に失敗した操作をもう一度行います。ページを再読み込みし、必要な通常のリクエストを送信して、システム接続が安定していることを確認してください。ログインや支払いを行う場合は、まずWebサイトのアドレスが正しいことを確認してから接続をテストします。Webページのエラーに対処するために、証明書の検証を無効にしないでください。原因を判断できない場合は、FAQで同じ症状を確認できます。その際も今回の3つのモードでの結果を残し、最初から試し直すことを避けてください。

03 サーバーのタイムアウト：アドレス、通信方式、認証を順に確認

タイムアウトは、所定の時間内に期待した応答がなかったことを示しますが、どの段階に問題があるかまでは分かりません。サーバードメインを名前解決できない、接続先ポートに到達できない、プロトコルのハンドシェイクが一致しない場合のほか、Connectivity Testのテスト先が一時的に利用できない場合もあります。テストを開始した場所、エラーの原文、特定のサーバーだけ失敗するか、通常のWebリクエストも失敗するかを記録してください。テスト結果は手掛かりであり、サーバー状態を完全に証明するものではありません。

まずAdd Serverの基本項目を確認

既存のサーバー項目を開き、自分が持っている元の情報と照らし合わせて、Type、Server、Port、認証項目を一つずつ確認します。Server欄にパス、空白、プロトコルの接頭辞など、その項目に不要な内容を含めないでください。Portはサーバーが実際に待ち受けているポートと一致させます。手動で入力する場合、表示名をサーバーアドレスと取り違えたり、サブスクリプションURLを単一サーバーの項目に入力したりしがちです。内容を変更する前に情報の種類を確認し、誤った入力欄への貼り付けを繰り返さないでください。

アドレスにドメイン名を使っている場合、名前解決に失敗すると後続の接続を開始できません。同じネットワークで他のドメインが正常に解決されるか確認してから、DNSの項目を参照してください。ドメインを、どこかで見つけたランダムなIPアドレスに置き換えないでください。サーバーがSNI、証明書のドメイン名、特定のルーティングに依存している場合があります。サーバーとの対応関係を把握し、正しいTLS設定を維持できる場合に限り、アドレスの比較テストに意味があります。

同じプロトコルでも、追加設定が同じとは限りません

Shadowsocksでは暗号化方式とパスワードを確認します。VMessとVLESSでは識別情報と使用する通信方式を確認します。Trojanではパスワード、TLS、SNIを確認してください。Hysteria2では、現在のネットワークが必要なUDP通信に対応しているかも確認します。WebSocketなどの通信方式を使用する場合、HostとPathもサーバー側の設定と一致させる必要があります。Typeだけを変えて異なるプロトコルが相互に動作すると期待しないでください。また、ポート番号からプロトコルを推測しないでください。

証明書関連のエラーが表示された場合は、まずデバイスの日付、SNI、証明書のドメイン名が一致しているかを確認し、サーバー証明書が有効か確認してください。Allow Insecureを万能な修復方法として使わないでください。検証を回避すると、アドレスの誤りや異常な証明書を見逃すおそれがあります。TLSでポートに接続できても、認証成功や想定したサーバーへのリクエスト到達を意味するとは限りません。各項目の詳細はTrojanの設定とTLSの確認を参照してください。

必要最小限の比較でネットワークの問題箇所を絞る

可能であれば、同じサーバー設定を維持したままWi-Fiとモバイル通信でそれぞれテストします。特定のネットワークだけ失敗する場合は、認証情報一式を作り直すのではなく、接続環境や通信経路を優先して確認してください。逆に、同じネットワークで特定のサーバーだけ失敗する場合は、そのサーバーのアドレス、ポート、稼働状態を詳しく調べます。ネットワークを切り替えたら接続状態が安定するまで待ってから同じリクエストを行い、切り替え中の一時的な中断を継続的な障害と取り違えないようにしてください。

手動で追加した項目は使えるのに、サブスクリプション内の同じ項目が使えない場合は、両者の設定を一つずつ比較します。サブスクリプションの更新でローカルの変更が上書きされる場合があります。既存のサーバーがすべて失敗しても、クライアントの故障とは限りません。同じドメイン、認証情報、サーバー側の接続先を共有している可能性があります。利用しているサービスの提供元に問い合わせる際は、発生時刻、接続ネットワークの種類、プロトコル、認証情報を隠したエラーを伝え、完全な認証情報を公開の場に送らないでください。修正後は、テスト一覧に数字が表示されるだけでなく、実際のリクエストを再確認します。

04 Subscribeの失敗：取得・解析・上書きを切り分ける

サブスクリプションの問題は、少なくとも3段階に分けて確認します。クライアントが内容を取得できるか、取得した内容を認識できるか、読み込み結果が想定どおり一覧に反映されるかです。最初の段階で失敗している場合、サーバーのプロトコルを繰り返し変更しても解決しません。内容を読み込めたのに接続できない場合は、前の項目を確認してください。この項目では、利用者自身がサブスクリプションを用意していることを前提とします。サブスクリプションURLはアクセス認証情報の一部です。通常のURLに見えても、スクリーンショットや公開ログ、他人がコピーできる説明に掲載しないでください。

まずURLの完全性を確認し、次に取得経路を調べる

ConfigのSubscribe関連項目で登録済みのアドレスを確認し、コピー時にクエリパラメーターが欠けていないか、末尾が切れていないか、改行が混入していないかを調べます。アプリにサブスクリプション項目の編集・更新機能がある場合は、現在の画面に表示される名称を確認してください。項目名や配置は、インストール済みアプリの画面に従って確認します。サービスの説明ページ、アカウントのログインページ、単一サーバーの共有情報をサブスクリプションURLとして使わないでください。手元の情報がどの種類に当たるか、まず元の情報の提供元に確認してください。

更新が一度失敗した場合は、接続をオフにしたときとオンにしたときのどちらで失敗したかを記録します。サブスクリプションの取得自体にもネットワーク経路が必要です。現在のサーバーが利用できないと、更新リクエストが届かない場合があります。基本ネットワークが使える状態で、接続を一時的にオフにして再更新できます。ただし、取得に既存の利用可能な経路が必要な場合は、すでに確認済みの項目を選んでください。短時間に何度も再試行すると、一時的な制限と元の問題が重なり、原因を特定しにくくなります。

取得成功でも、内容が有効なサブスクリプションとは限りません

ネットワークリクエストに応答があっても、返された内容がログインページ、有効期限の案内、認証ページ、エラー説明の場合があります。この場合の「解析できない」は、クライアント側で任意の形式変換が必要という意味ではなく、内容が想定したサーバー項目ではない可能性を示します。サブスクリプションが有効か、URLが変更されていないか、提供元が返却形式を変更していないかを確認してください。内容が分からないWebページを使用中のConfigに上書きしないでください。また、サブスクリプションの認証情報を見知らぬオンライン変換サイトに入力しないでください。

一部の項目だけ読み込まれない場合は、読み込まれない項目のプロトコル、設定の不足、アプリの対応状況を比較してください。パスワードや認証情報を推測して補ったり、エンコードを繰り返し変更したりしないでください。元の応答を公開するのではなく、認証情報を隠した項目名とエラー文で状況を説明できます。読み込み方法の違いはSubscribe、Add Server、QRコード、クリップボードからの読み込みを参照してください。

更新前にローカル編集を保護し、更新後に選択状態を確認

サブスクリプションには通常、リモートで管理される情報が含まれます。更新後に名前、並び順、アドレス、項目数が変わることがあります。ローカルで一時的に修正した設定が、更新後も保持されるとは限りません。更新前に変更した項目を記録し、必要に応じてアプリで対応しているConfigのバックアップを保存してください。更新後は、以前選択していたサーバーが残っているかを確認し、Global Routingと使用中のConfigも確認します。一覧の更新に成功したからといって、使用中の項目が利用可能になったとは限りません。

更新後に一覧が空になっても、すぐに過去の項目をすべて削除しないでください。更新対象を間違えていないか、サブスクリプションが空の内容を返していないか、アカウントの状態が変わっていないか、復元できるローカル記録がないかを確認します。手動で追加した項目が引き続き使える場合は、確認用の基準として残しておけます。削除して追加し直す方法は、必要な元情報がすべて揃い、内容を再取得できると確認できた場合に限って使います。すべての解析エラーに有効な解決策ではありません。

最後に、更新後のサーバーを1つ選び、必要な設定を確認してから、同じ一般的なWebページでテストします。サブスクリプションの更新に成功した後、サーバーがタイムアウトする場合は、Subscribeの再試行をやめて接続設定の項目へ進んでください。自動更新だけ失敗し手動更新は正常な場合は、失敗時のネットワーク状態と時刻の条件を確認します。バックグラウンド動作が壊れていると、すぐに結論づけないでください。アプリの買い切り購入と、利用者自身のサブスクリプションの有効期限は別の問題です。アプリを再購入しても、無効になったサブスクリプションURLは復旧しません。

05 通信速度が遅い：ハンドシェイク、転送速度、接続先を切り分ける

「遅い」といっても、ページを開く前に長く待たされる場合、大きなファイルの転送だけ遅い場合、画像や動画、特定のアプリだけに影響する場合があります。まず、同じ宛先を初めて開くまでの時間、再度開いたときに改善するか、ネットワークを切り替えると変化するかを、再現できる形で記録してください。Connectivity Testの結果をダウンロード速度と同一視しないでください。短いリクエストの応答時間と、継続的なデータ転送能力は異なる指標です。一度のテストでは、混雑、パケットロス、接続先の負荷を評価できません。

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

同じデバイス、同じ接続ネットワーク、同じ宛先を選び、できるだけ近い時間帯に比較します。ネットワークを使う他のタスクの影響を避けるため、実行中のクラウド同期、大容量ファイルの転送、アプリのアップデートを一時停止してください。使用中のサーバーとGlobal Routingを記録し、初回アクセスと再アクセスをそれぞれ確認します。初回は遅く、再度アクセスすると明らかに改善する場合は、DNS、TLSハンドシェイク、コンテンツのキャッシュが関係している可能性があります。転送を続けても遅い場合は、経路の品質、混雑、サーバーの実際の処理状況を確認してください。

サーバー、DNS、ルールを同時に切り替えてから比較しないでください。改善しても、どの変更が効いたか分からなくなります。自分で管理するサーバーが複数ある場合は、一度に1つだけ切り替え、同じリクエストで再テストします。ネットワークの切り替え中に起きた一時的な中断を、安定時の速度として扱わないでください。Wi-Fiまたはモバイル通信が安定し、システムの認証が進行中でないことを確認してから次のテストを始めると、結果を正しく比較できます。

一部のコンテンツだけ遅い場合は、ドメインとポリシーを確認

1つのページから、メインサイト、静的ファイル、画像、APIなど複数のドメインへリクエストが送られることがあります。メインページは速いのにリソースだけ遅い場合は、リソースのドメインに別のポリシーが適用されているか、範囲の広すぎるルールによって通信経路が変わった可能性があります。直前のリクエスト記録から、遅いリクエストの実際のドメインと適用ポリシーを確認してください。誤りが確認できたドメインだけを対象にルールを調整し、関連するドメインをすべて一律に同じ処理に変更しないでください。接続先は地域、アカウント、キャッシュによって異なるコンテンツを配信することもあります。サーバーのテストが正常だったというだけで、接続先側の違いを除外しないでください。

Configは遅いがProxyでは正常な場合、ポリシーグループ、ルールの順序、DNSの問い合わせ経路を確認します。両方が遅く、同じ宛先へDirectで正常にアクセスできる場合は、現在のサーバー経路をさらに調べます。ただし、Directで特定の宛先にアクセスできないことは、サーバーの速度を比較する根拠になりません。2つの経路で同じ宛先にアクセスできるとは限らないためです。比較するには、どちらの方法でも同じ操作を完了できることが前提です。

UDP、MTU、通信設定を根拠なく変更しない

リアルタイム通信、一部のストリーミング、特定のプロトコルはUDPに依存することがあり、一般的なWebページが表示できてもUDP経路が正常とは限りません。こうした機能だけに問題がある場合は、サーバーの対応状況と現在のネットワークの制限を確認してください。Hysteria2などのプロトコルでは、基本的な接続確認の代わりに帯域幅の値を変更しないでください。数値を大きくしても、実際の転送速度が上がるとは限りません。利用しているサーバーの設定説明に従い、元の値を残したうえで、一度に1項目だけを変えてテストします。

小さなリクエストは正常でも大きなリクエストが停止する場合、後続の調査項目としてPath MTUを検討できます。ただし、根拠なく何度も変更しないでください。パケットロス、接続先の速度制限、接続のリセットでも同様の現象が起こることがあります。特定のネットワークだけで発生するか、特定のプロトコルに限られるか、利用可能な既存サーバーに切り替えると解消するかを確認します。関連性を確認でき、元に戻す方法も分かっている場合に限り、実際の構成に合わせて設定を調整してください。

デバイスの発熱も、実際の使用感に影響します。長時間の高負荷通信、画面の点灯、バックグラウンドタスクが同時に発生している場合があります。テストを一時停止してデバイスが通常の状態に戻ってから、短時間のリクエストを再確認します。デバイスの温度が明らかに上がっているときに、速度テストを何度も続けないでください。最終的には、本来の用途でページを適切に表示できるか、動画の再生が止まらないか、ファイルを安定して転送できるかで判断します。テスト画面に小さい数値を表示させることだけを目標にしないでください。

06 DNSの異常：名前解決元とリクエストの経路を確認

DNSはドメイン名を接続に使うアドレスへ変換します。ドメイン名を解決できないと、プロキシのハンドシェイクが始まる前に失敗する場合があります。名前解決できても、現在の経路に適さないアドレスが返されると、タイムアウトしたり誤った接続先に到達したりすることがあります。複数のドメインが同時に失敗する、初回アクセスで長く待たされる、ネットワーク切り替え後に一部の宛先へアクセスできなくなる、といった状態が手掛かりです。特定のIPアドレスへアクセスできたからといって、すべてがDNSの問題だと判断しないでください。HTTPSではドメイン名、SNI、証明書の検証も関係します。

記憶にある設定ではなく、現在使用中のConfigを確認

現在使用しているConfigを開き、Generalのdns-serverと、名前解決に影響するマッピングやルールがほかにないか確認します。以下の例はシステムが提供する名前解決元を使用する設定を示すもので、構文の説明に限られます。すべてのネットワークに適するとは限りません。変更前に現在の値を保存してください。特に、既存のルールに基づくDNSの振り分けを、単一のアドレスで上書きしないでください。システムDNSの具体的な参照先は、Wi-Fi、モバイル通信、デバイス管理設定によって変わることがあり、固定とは限りません。

[General]
dns-server = system

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

手動のHostマッピングや古いアドレスの記録がないか確認してください。設定があると、調査中の通常の名前解決経路を使わない場合があり、dns-serverを変更しても変化がないように見えることがあります。特定のドメインが古いアドレスに固定されている場合は、削除や修正を決める前に、自分が参照している元の設定情報と照合してください。公開の場で見つけたアドレスを、そのままマッピングに入力しないでください。ドメインとアドレスの対応は、地域、サービスの構成、時間によって変わることがあります。

暗号化DNSにも、到達可能な基本経路が必要

暗号化DNSを使う場合、名前解決サービス自体にも接続できなければなりません。そこへアクセスするために先にプロキシを確立する必要があり、プロキシサーバーのアドレスも同じ経路で解決する必要がある場合、起動時に依存関係の問題が生じることがあります。調査では、まずサーバードメインを初回に名前解決できるか確認し、その後で接続先のドメインを確認してください。名前解決サービスとプロキシアドレスを同時に変更すると、DNSの復旧とサーバー経路の変更を区別しにくくなります。

公衆Wi-Fiの中には、想定された名前解決や認証の手順だけを許可するものがあります。認証が終わる前にDNS設定を変更しても、効果がない場合があります。まず接続をオフにしてネットワークにログインし、その後、元の設定で接続を再確認してください。特定のネットワークだけで問題が起きる場合は、同じConfigを別の利用可能なネットワークで試します。Configを変えずに結果が変わるなら、すべてのドメインルールを書き換えるのではなく、ネットワークによるDNSリクエストの処理を優先して調べてください。

IPv4、IPv6、ルールの適用状況を合わせて確認

同じドメインからIPv4とIPv6のアドレスが返されることがあり、デバイスが選択する通信経路はネットワークの対応状況に左右されます。IPv6に対応したネットワークだけで問題が起きる場合は、名前解決の結果の種類、実際の接続先、失敗の状態を記録してください。関連機能をすぐに全体で無効にしないでください。IP-CIDRとIP-CIDR6はそれぞれ異なるアドレスファミリーを扱うため、前者だけのローカルルールでは後者を対象にできない場合があります。ドメインルールとアドレスルールでは適用されるタイミングも異なります。変更前に、リクエストに実際に適用されたルールを確認してください。

GEOIPの判定はアドレスの割り当て情報に基づくもので、各ドメインのサービス用途を正確に表すとは限りません。CDNのアドレスは変わることがあり、共用アドレスが複数のドメインに使われる場合もあります。少数の特定用途に対応する場合は、アドレス範囲をむやみに拡大するのではなく、より明確なDOMAINまたはDOMAIN-SUFFIXで指定できるかを確認してください。説明可能な既定の処理としてFINALを維持し、現在の用途に合ったポリシーであることを確認します。

変更後は、失敗したリクエストをもう一度実行してください。アプリやシステムがキャッシュを保持している場合があります。関連ページを閉じて開き直し、新しいリクエストを確認します。再接続が必要な場合は、切断前後の設定を記録してください。検証の代わりに、すべてのデバイスを何度も再起動しないでください。成功の判断基準は、宛先ドメインを適切に解決でき、想定したポリシーが適用され、リクエストが実際に完了したことです。解析キーワードの定義は用語集を参照してください。

07 バッテリー消費、発熱、頻繁な再接続：通信の発生源を確認

VPN接続を長時間維持しているだけで、必ずしもバッテリー消費の異常を意味するわけではありません。確認すべきなのは、通信量、再接続の頻度、デバイスの温度、同じ時間帯に動作していた他のアプリです。システムのバッテリー画面に表示されるのは一定期間の統計であり、1回のリクエストによる正確な消費量ではありません。異常に気づいた時刻、そのときのネットワークとアプリを記録し、近い時間、似たタスクで比較してください。1回の統計で比率が高かっただけで、クライアントが常に高負荷で動作していると判断しないでください。

まず継続的な通信とバックグラウンド処理を確認

写真の同期、大容量ファイルの転送、動画再生、アプリのアップデートが行われていないか確認します。これらの通信が接続を経由すると、ネットワーク拡張機能が継続して通信を処理する場合があります。その場合は、利用中のアプリと接続拡張機能の両方の統計を確認してください。関連タスクを一時停止し、他の条件は変えずにしばらく観察して、発熱が続くかを調べます。バッテリー消費の確認中にConnectivity Testを何度も実行しないでください。テスト自体が接続とデータ通信を発生させます。

システムのバッテリー画面に表示されるバックグラウンド動作は、実際の利用状況と合わせて判断してください。画面の点灯、弱いモバイル通信の電波、インターネット共有、高温環境も消費量を増やす場合があります。デバイスを通常の温度に戻し、安定したネットワークに接続してから比較すると、誤った判断を減らせます。接続をオフにしても発熱が続く場合は、デバイス自体や他のアプリの動作を先に確認してください。すべての問題をShadowrocketのルール設定のせいにしないでください。

On Demandとネットワーク切り替えを分けて確認

On Demandは、システムの条件に応じて接続を開始します。Wi-Fiとモバイル通信が頻繁に切り替わる場合や、アクセスポイントが一時的に切断される場合、接続と切断が何度も発生することがあります。まずオンデマンド条件を記録し、On Demandを一時的にオフにして、同じネットワークで手動接続を維持し、再接続が減るか確認してください。明らかに減った場合は、条件の重複や現在のネットワークの安定性を見直します。仕組みを理解していない設定を恒久的に維持しないでください。

スリープからの復帰、Wi-Fiの圏外への移動、ネットワーク認証の際に一時的な再接続が起きるのは、環境の変化が原因の場合があります。問題なのは、ネットワークが安定した後も繰り返し発生する状態です。ログを確認し、システムによる接続開始、サーバーのハンドシェイク失敗、アプリからのリクエスト再試行のどれに当たるかを確認してください。原因を分けることで、On Demandの変更、サーバーの確認、リクエストを繰り返すアプリの対処のどれが必要か判断できます。状態アイコンが点滅しているだけでは十分な情報になりません。

ログ、ルール、接続失敗による負荷

調査のために詳細なログを有効にした場合は、必要な記録が済んだら通常の記録レベルに戻してください。詳細なログを長時間残すと、ストレージと処理の負荷が増え、プライバシー情報が保存される可能性もあります。ログは短時間に発生した1回の再現を対象に収集すれば十分です。日常のリクエストをすべて継続して保存する必要はありません。共有前に、個人を特定できるドメイン情報、サーバーアドレス、認証情報を隠し、調査に必要なエラーの前後だけを残してください。

利用できないサーバーは、アプリのリクエストを何度も待たせたり再試行させたりすることがあります。現在のルールが日常的な通信の多くを利用できないポリシーに送っている場合、バックグラウンドのバッテリー消費に見えても、原因は通信の失敗かもしれません。まず実際に使用しているサーバーが利用可能か確認し、ドメインが誤って遮断されて再試行を繰り返していないか調べます。ルールの数が多いことだけでは、バッテリー消費の原因とは言えません。実際のリクエスト、失敗頻度、設定変更前後の比較結果を根拠に判断してください。

現在のネットワークで特定のプロトコルだけ再接続が続く場合は、利用可能な既存の別設定と比較し、宛先とタスクは変えずに確認します。プロトコル、サーバー、通信量を同時に変えて、特定の設定が原因だと結論づけないでください。WireGuardなど、サーバー側の設定に依存する項目では、Keepalive関連の値をむやみに変更しないでください。必要性と値は、サーバーとネットワーク環境に基づいて判断する必要があります。

確認を終えたら、通常のログ設定に戻し、On Demandが想定した状態になっているかを確認します。デバイスの温度とバッテリーの推移が改善したかを記録してください。タスクの一時停止、安定したネットワーク、利用可能なサーバーでも異常が続く場合は、情報を隠した記録を残して、アップデート後の項目へ進みます。システムのバッテリー統計には集計期間があります。変更後は比較できる時間だけ使い、スイッチを数秒切り替えただけで過去全体の比率が変わると期待しないでください。

08 アップデート後・iPadの問題：基準状態に戻して差分を確認

アップデート直後に問題が起きても、アップデートだけが原因とは限りません。アプリ、システム、サブスクリプションの更新、サーバーの変更、ネットワークの切り替えが、近い時期に重なっている可能性があります。最後に接続できた時点から最初に失敗した時点までに変わったことを列挙し、変更項目を最小限にして再テストしてください。現在のConfigと元のサーバー情報を残し、すぐにすべてのデータを消去しないでください。購入の復元で回復できるのはアプリの利用資格です。利用者がローカルで編集したすべての内容が自動的に戻るとは限りません。

アップデート後は選択中の項目とシステムの許可を確認

Homeを開き、選択中のサーバー、Global Routing、システムの接続状態を確認します。次に、有効なConfigが想定したファイルか確認してください。ポリシーグループを使用していた場合は、グループ内の選択が変わっていないか調べます。Configが一覧にあることは、現在有効であることを意味しません。名前が似ていても同じ内容とは限りません。まず自分で保存した正常な状態と比較し、違いを確認してから変更してください。すべての設定を初期値に戻して原因の特定に代えないでください。

システムのVPN構成が削除された場合や、デバイスの移行後に再許可が必要な場合は、最初の項目に従ってシステムの画面を完了してください。アプリを開けても、すべての接続に失敗する場合は、現在のネットワークで接続をオフにして基本アクセスを確認し、以前利用できたサーバーでテストします。必要であればデバイスを通常の方法で再起動し、一度だけ再確認して結果を記録してください。アップデート履歴とシステム要件はApp Storeのページで確認します。古いスクリーンショットを掲載した記事を根拠に、現在の画面に機能が「ない」と判断しないでください。

iPadとiPhoneを比較する前に、条件をそろえる

同じサブスクリプションがiPhoneでは使えてiPadでは使えない場合、まず両方のデバイスが本当に同じサーバー、同じプロトコル設定、同じConfigを使っているか確認します。サブスクリプション名が同じでも、最近更新した内容が同じとは限りません。Global RoutingとDNSも確認してください。特に、どちらかのデバイスでローカル編集を保持している場合は注意が必要です。項目ごとに比較する前に、iPad固有の互換性問題だと決めつけないでください。

ネットワーク環境が異なる場合もあります。iPadはWi-Fiのみで、iPhoneはモバイル通信を使っている可能性があります。まず両方のデバイスを同じWi-Fiに接続し、同じ宛先でテストして結果を比較してください。iPadだけ失敗する場合は、VPNの許可、デバイス管理の制限、ネットワーク認証の状態、システムの日付を確認します。両方で失敗する場合は、共通のサーバー、サブスクリプション、ルーターを調べてください。タブレットの画面レイアウトを調査し続ける必要はありません。

iPadの横向き表示、Split View、ウィンドウレイアウトによって、機能の配置場所が変わる場合がありますが、同じ名前の項目でサーバー設定が別物になるわけではありません。Home、Config、Settingsなどの画面上の用語から機能を探してください。操作しにくい場合は、いったん操作しやすい大きさのウィンドウに戻して確認します。スマートフォンのスクリーンショットと同じ場所に項目が見つからないからといって、設定を重複して作成しないでください。初期設定ははじめにを参照し、このページでは違いと問題を扱います。

アプリを再入手する前に、バックアップと購入の範囲を確認

アプリを再入手する必要がある場合は、App Storeのみを利用してください。先に購入時のアカウントと購入済み項目を確認し、具体的な手順は購入済み項目の復元を参照してください。正規のアプリかどうかは、デベロッパ名のShadow Launch Technology Limited、公式アイコン、アプリID 932747118で確認します。Shadowrocketはクローズドソースの商用アプリです。システム要件と利用可能なデバイスはApp Storeのページで確認し、古い説明からすべてのデバイスが対象だと判断しないでください。

再インストールの前に、既存のサブスクリプションURL、手動で追加したサーバー設定、ローカルのConfigを、自分で復元できる方法で保存してください。バックアップにはパスワード、秘密鍵、アクセス認証情報が含まれる場合があります。自分で管理できる保存先を使い、公開ページに貼り付けないでください。アプリの購入履歴、システムのVPN構成、利用者自身の接続データはそれぞれ別のものです。購入を復元できても、後の2つが復元済みとは限りません。アプリを再度開いた後も、初回の許可と接続確認の手順を行ってください。

再現できるトラブル記録を作成

ここまでの手順で解決しない場合は、デバイスの種類、システムとアプリに表示される情報、ネットワークの種類、失敗した操作、認証情報を隠したエラーの原文、最後に正常だった操作、確認済みの比較結果を短くまとめてください。スイッチがオフに戻る、ドメインの名前解決に失敗する、ハンドシェイクに失敗する、特定の通信がタイムアウトする、といった状態を具体的に記載します。「アップデート後に使えない」だけで済ませないでください。また、関係のないスクリーンショットを大量に一度に提出し、実際の失敗手順を埋もれさせないでください。

サーバー認証、サブスクリプションの有効性、サーバー側のプロトコル設定については、自分が情報を入手した提供元に確認してください。システムの許可やデバイス管理の制限については、デバイス設定を確認します。復旧後は、On Demand、Global Routing、ログレベル、一時的に追加したテスト用ルールが想定した状態に戻っているかを確認してください。トラブルシューティングの完了は、たまたま1つのWebページが開いたことではありません。記録した正常な設定で、最初に失敗した操作を繰り返し完了できることが目安です。